Oblaki so kot čarobna škatla – vprašate, kaj potrebujete, virov pa se pojavi kar od nikoder. Virtualni stroji, baze podatkov, omrežje - vse to pripada samo vam. Obstajajo tudi drugi najemniki oblakov, vendar v vašem vesolju ste vi edini vladar. Prepričani ste, da boste vedno prejeli zahtevana sredstva, nikogar ne upoštevate in samostojno določate, kakšno bo omrežje. Kako deluje ta čarovnija, zaradi katere oblak elastično razporeja vire in popolnoma izolira najemnike drug od drugega?
Oblak AWS je mega-super kompleksen sistem, ki se evolucijsko razvija že od leta 2006. Del tega razvoja se je zgodil Vasilij Pantjuhin - Arhitekt spletnih storitev Amazon. Kot arhitekt dobi notranji pogled ne le na končni rezultat, temveč tudi na izzive, ki jih AWS premaga. Večje kot je razumevanje delovanja sistema, večje je zaupanje. Zato bo Vasily delil skrivnosti storitev v oblaku AWS. Spodaj je zasnova fizičnih strežnikov AWS, razširljivost elastične baze podatkov, Amazonova baza podatkov po meri in metode za povečanje zmogljivosti virtualnih strojev ob hkratnem znižanju njihove cene. Poznavanje Amazonovih arhitekturnih pristopov vam bo pomagalo učinkoviteje uporabljati storitve AWS in vam lahko dalo nove ideje za gradnjo lastnih rešitev.
O govorniku: Vasilij Pantyukhin () je začel kot skrbnik Unixa v podjetjih .ru, 6 let delal na veliki strojni opremi Sun Microsystem in 11 let pri EMC pridigal o svetu, osredotočenem na podatke. Seveda se je razvil v zasebne oblake, leta 2017 pa se je preselil v javne. Zdaj nudi tehnične nasvete za pomoč pri življenju in razvoju v oblaku AWS.
Izjava o omejitvi odgovornosti: vse spodaj je Vasilijevo osebno mnenje in morda ne sovpada s stališčem Amazon Web Services. Poročilo, na katerem temelji članek, je dostopno na našem YouTube kanalu.
Zakaj govorim o napravi Amazon?
Moj prvi avto je imel ročni menjalnik. Bilo je super zaradi občutka, da lahko vozim avto in imam popoln nadzor nad njim. Všeč mi je bilo tudi, da sem vsaj približno razumel princip njegovega delovanja. Seveda sem si strukturo škatle predstavljal precej primitivno - nekaj podobnega menjalniku na kolesu.
Vse je bilo super, razen ene stvari - zastoja v prometnih zastojih. Zdi se, kot da sediš in ne delaš ničesar, a nenehno menjaš prestave, pritiskaš na sklopko, plin, zavoro - to te res utrudi. Problem prometnih zamaškov je bil delno rešen, ko je družina dobila avtomatski avto. Med vožnjo sem imel čas razmišljati o nečem in poslušati zvočno knjigo.
V mojem življenju se je pojavila še ena skrivnost, ker sem popolnoma prenehal razumeti, kako deluje moj avto. Sodoben avtomobil je zapletena naprava. Avto se hkrati prilagaja na desetine različnih parametrov: pritisk na plin, zavore, način vožnje, kakovost ceste. Ne razumem več, kako to deluje.
Ko sem začel delati na oblaku Amazon, je bil tudi zame uganka. Samo ta skrivnost je za red velikosti večja, saj je v avtomobilu samo en voznik, v AWS pa jih je na milijone. Vsi uporabniki hkrati krmilijo, pritiskajo na plin in zavirajo. Neverjetno, da gredo, kamor hočejo – zame je to čudež! Sistem se samodejno prilagaja, skalira in elastično prilagaja vsakemu uporabniku tako, da se mu zdi, da je sam v tem vesolju.
Čarovnija je nekoliko popustila, ko sem kasneje prišel delat kot arhitekt pri Amazonu. Videla sem, s kakšnimi težavami se soočamo, kako jih rešujemo in kako razvijamo storitve. Z večjim razumevanjem delovanja sistema se pojavi več zaupanja v storitev. Zato želim deliti sliko tega, kar je pod pokrovom oblaka AWS.
O čem naj govorimo
Izbrala sem raznolik pristop – izbrala sem 4 zanimive storitve, o katerih je vredno govoriti.
Optimizacija strežnika. Efemerni oblaki s fizično utelešenjem: fizični podatkovni centri, kjer so fizični strežniki, ki brnijo, segrevajo in utripajo z lučkami.
Funkcije brez strežnika (Lambda) je verjetno najbolj razširljiva storitev v oblaku.
Skaliranje baze podatkov. Povedal vam bom o tem, kako gradimo lastne razširljive baze podatkov.
Omrežno skaliranje. Zadnji del, v katerem bom odprl napravo našega omrežja. To je čudovita stvar - vsak uporabnik oblaka verjame, da je sam v oblaku in drugih najemnikov sploh ne vidi.
Opomba. Ta članek bo razpravljal o optimizaciji strežnika in skaliranju baze podatkov. V naslednjem članku bomo obravnavali skaliranje omrežja. Kje so funkcije brez strežnika? O njih je bil objavljen ločen prepis "" Govori o več različnih metodah skaliranja in podrobno obravnava rešitev Firecracker - simbiozo najboljših lastnosti virtualnega stroja in vsebnikov.
Strežniki
Oblak je minljiv. Toda ta minljivost ima še vedno fizično utelešenje - strežnike. Sprva je bila njihova arhitektura klasična. Standardni nabor čipov x86, omrežne kartice, Linux, hipervizor Xen, na katerem so bili poganjani virtualni stroji.
Leta 2012 se je ta arhitektura precej dobro spopadla s svojimi nalogami. Xen je odličen hipervizor, vendar ima eno veliko pomanjkljivost. Dovolj ima visoki stroški za emulacijo naprave. Ko so na voljo nove, hitrejše omrežne kartice ali pogoni SSD, postanejo ti stroški previsoki. Kako se spopasti s to težavo? Odločili smo se, da bomo delali na dveh frontah hkrati - optimizirati strojno opremo in hipervizor. Naloga je zelo resna.
Optimizacija strojne opreme in hipervizorja
Narediti vse naenkrat in to dobro ne bo delovalo. Tudi kaj je bilo "dobro", je bilo sprva nejasno.
Odločili smo se za evolucijski pristop – en pomemben element arhitekture spremenimo in ga vržemo v proizvodnjo.
Stopimo na vse grablje, prisluhnemo pritožbam in predlogom. Nato spremenimo drugo komponento. Tako v majhnih korakih radikalno spremenimo celotno arhitekturo na podlagi povratnih informacij uporabnikov in podpore.
Transformacija se je začela leta 2013 z najbolj kompleksno stvarjo – omrežjem. IN S3 V primerih je bila standardni omrežni kartici dodana posebna kartica Network Accelerator. Povezan je bil dobesedno s kratkim povratnim kablom na sprednji plošči. Ni lepo, a v oblaku se ne vidi. Toda neposredna interakcija s strojno opremo je bistveno izboljšala tresenje in prepustnost omrežja.
Nato smo se odločili izboljšati dostop do blokovnega shranjevanja podatkov EBS - Elastic Block Storage. Je kombinacija omrežja in pomnilnika. Težava je v tem, da medtem ko so kartice Network Accelerator obstajale na trgu, ni bilo možnosti za preprost nakup strojne opreme Storage Accelerator. Zato smo se obrnili na startup Laboratoriji Annapurna, ki je za nas razvil posebne ASIC čipe. Omogočili so namestitev oddaljenih nosilcev EBS kot naprav NVMe.
V primerih C4 rešili smo dve težavi. Prvi je, da smo uvedli osnovo za prihodnost obetavne, a takrat nove tehnologije NVMe. Drugič, močno smo razbremenili centralni procesor s prenosom obdelave zahtevkov v EBS na novo kartico. Dobro se je izkazalo, tako da je zdaj Annapurna Labs del Amazona.
Do novembra 2017 smo ugotovili, da je čas za spremembo samega hipervizorja.
Novi hipervizor je bil razvit na podlagi spremenjenih modulov jedra KVM.
Omogočil je temeljito zmanjšanje režijskih stroškov emulacije naprave in neposredno delo z novimi ASIC-ji. Primerki S5 so bili prvi virtualni stroji z novim hipervizorjem, ki deluje pod pokrovom. Poimenovali smo ga Nitro.
Razvoj instanc na časovnici.
Vse nove vrste virtualnih strojev, ki so se pojavile od novembra 2017, delujejo na tem hipervizorju. Primerki Bare Metal nimajo hipervizorja, imenujejo pa se tudi Nitro, saj uporabljajo specializirane Nitro kartice.
V naslednjih dveh letih je število vrst primerkov Nitro preseglo nekaj ducatov: A1, C5, M5, T3 in drugi.
Vrste primerkov.
Kako delujejo sodobni stroji Nitro
Imajo tri glavne komponente: hipervizor Nitro (o katerem smo govorili zgoraj), varnostni čip in kartice Nitro.
Varnostni čip integriran neposredno v matično ploščo. Nadzoruje številne pomembne funkcije, kot je nadzor nad nalaganjem gostiteljskega OS.
Nitro kartice - Obstajajo štiri vrste. Vse so razvili Annapurna Labs in temeljijo na običajnih ASIC-jih. Nekatera njihova vdelana programska oprema je prav tako pogosta.
Štiri vrste kartic Nitro.
Ena od kartic je zasnovana za delo omrežjeVPC. To je tisto, kar je vidno v virtualnih strojih kot omrežna kartica ENA - Elastični omrežni adapter. Prav tako enkapsulira promet, ko ga prenaša prek fizičnega omrežja (o tem bomo govorili v drugem delu članka), nadzoruje požarni zid varnostnih skupin in je odgovoren za usmerjanje in druge omrežne stvari.
Izbrane kartice delujejo z blokovnim pomnilnikom EBS in diski, ki so vgrajeni v strežnik. Gostujočemu virtualnemu stroju se prikažejo kot NVMe adapterji. Odgovorni so tudi za šifriranje podatkov in spremljanje diska.
Sistem Nitro kartic, hipervizorja in varnostnega čipa je integriran v SDN omrežje oz Programsko definirano omrežje. Odgovoren za upravljanje tega omrežja (nadzorna ravnina) kontrolna kartica.
Seveda nadaljujemo z razvojem novih ASIC-jev. Na primer, konec leta 2018 so izdali čip Inferentia, ki vam omogoča učinkovitejše delo z nalogami strojnega učenja.
Čip procesorja strojnega učenja Inferentia.
Razširljiva baza podatkov
Tradicionalna baza podatkov ima večplastno strukturo. Za veliko poenostavitev ločimo naslednje ravni.
- SQL — na tem delajo odpremniki strank in zahtev.
- Določbe transakcije - tukaj je vse jasno, ACID in vse to.
- Predpomnjenje, ki ga zagotavljajo medpomnilniška področja.
- Sečnja — omogoča delo z dnevniki redo. V MySQL se imenujejo Bin Logs, v PosgreSQL - Write Ahead Logs (WAL).
- Skladiščenje – neposredno snemanje na disk.
Večplastna struktura baze podatkov.
Obstajajo različni načini za povečanje podatkovnih baz: razrezovanje, arhitektura Shared Nothing, skupni diski.
Vendar vse te metode ohranjajo isto monolitno strukturo baze podatkov. To bistveno omejuje skaliranje. Da bi rešili ta problem, smo razvili lastno podatkovno bazo − Amazonska Aurora. Združljiv je z MySQL in PostgreSQL.
Amazonska Aurora
Glavna arhitekturna zamisel je ločiti ravni shranjevanja in beleženja od glavne baze podatkov.
Če pogledam naprej, bom rekel, da smo tudi raven predpomnjenja naredili neodvisno. Arhitektura preneha biti monolit, pridobimo dodatne stopnje svobode pri skaliranju posameznih blokov.
Ravni beleženja in shranjevanja so ločeni od baze podatkov.
Tradicionalni DBMS zapisuje podatke v sistem za shranjevanje v obliki blokov. Pri Amazon Aurora smo ustvarili pametno shrambo, ki govori jezik ponavljanje dnevnikov. V notranjosti shramba spremeni dnevnike v podatkovne bloke, spremlja njihovo celovitost in samodejno varnostno kopira.
Ta pristop vam omogoča izvajanje tako zanimivih stvari, kot so kloniranje. Deluje bistveno hitreje in bolj ekonomično zaradi dejstva, da ne zahteva ustvarjanja popolne kopije vseh podatkov.
Shranjevalni sloj je implementiran kot porazdeljen sistem. Sestavljen je iz zelo velikega števila fizičnih strežnikov. Vsak redo dnevnik se obdela in shrani hkrati šest vozlov. To zagotavlja zaščito podatkov in uravnoteženje obremenitve.
Skaliranje branja je mogoče doseči z uporabo ustreznih replik. Porazdeljeno shranjevanje odpravlja potrebo po sinhronizaciji med glavno instanco baze podatkov, preko katere zapisujemo podatke, in preostalimi replikami. Zagotovljeno je, da so ažurni podatki na voljo vsem replikam.
Edina težava je predpomnjenje starih podatkov na prebranih replikah. Toda ta problem se rešuje prenos vseh redo dnevnikov na replike prek notranjega omrežja. Če je dnevnik v predpomnilniku, je označen kot nepravilen in prepisan. Če ni v predpomnilniku, se preprosto zavrže.
Uredili smo skladišče.
Kako povečati stopnje DBMS
Tukaj je horizontalno skaliranje veliko težje. Pa gremo po uhojeni poti klasično navpično skaliranje.
Predpostavimo, da imamo aplikacijo, ki komunicira z DBMS prek glavnega vozlišča.
Pri navpičnem skaliranju dodelimo novo vozlišče, ki bo imelo več procesorjev in pomnilnika.
Nato preklopimo aplikacijo s starega glavnega vozlišča na novo. Pojavijo se težave.
- To bo zahtevalo precejšen čas nedelovanja aplikacije.
- Novo glavno vozlišče bo imelo hladen predpomnilnik. Zmogljivost baze podatkov bo največja šele, ko se predpomnilnik segreje.
Kako izboljšati stanje? Nastavite proxy med aplikacijo in glavnim vozliščem.
Kaj nam bo to dalo? Zdaj vseh aplikacij ni treba ročno preusmeriti na novo vozlišče. Preklop lahko izvedete pod proxyjem in je bistveno hitrejši.
Zdi se, da je težava rešena. Ampak ne, še vedno trpimo zaradi potrebe po ogrevanju predpomnilnika. Poleg tega se je pojavila nova težava - zdaj je proxy potencialna točka okvare.
Končna rešitev z Amazon Aurora brez strežnika
Kako smo rešili te težave?
Pustil proxyja. To ni ločen primerek, ampak celotna porazdeljena flota posrednikov, prek katerih se aplikacije povezujejo z bazo podatkov. V primeru okvare je mogoče katero koli od vozlišč zamenjati skoraj v trenutku.
Dodana skupina toplih vozlišč različnih velikosti. Če je torej treba dodeliti novo vozlišče večje ali manjše velikosti, je le-to takoj na voljo. Ni vam treba čakati, da se naloži.
Celoten postopek skaliranja nadzoruje poseben nadzorni sistem. Spremljanje nenehno spremlja stanje trenutnega glavnega vozlišča. Če na primer zazna, da je obremenitev procesorja dosegla kritično vrednost, obvesti skupino toplih primerkov o potrebi po dodelitvi novega vozlišča.
Porazdeljeni proxyji, tople instance in spremljanje.
Na voljo je vozlišče z zahtevano močjo. Medpomnilniška področja se kopirajo vanj in sistem začne čakati na varen trenutek za preklop.
Običajno pride trenutek za zamenjavo precej hitro. Nato je komunikacija med posrednikom in starim glavnim vozliščem začasno prekinjena, vse seje se preklopijo na novo vozlišče.
Delo z bazo podatkov se nadaljuje.
Graf kaže, da je vzmetenje res zelo kratko. Modri graf prikazuje obremenitev, rdeči koraki pa momente skaliranja. Kratkoročni padci na modrem grafu so ravno ta kratka zamuda.
Mimogrede, Amazon Aurora vam omogoča, da popolnoma prihranite denar in izklopite bazo podatkov, ko ni v uporabi, na primer ob vikendih. Po prenehanju obremenitve DB postopoma zmanjšuje moč in se za nekaj časa izklopi. Ko se obremenitev vrne, se bo spet gladko dvignila.
V naslednjem delu zgodbe o napravi Amazon bomo govorili o skaliranju omrežja. Naročite se in ostanite z nami, da ne zamudite članka.
Na Vasilij Pantyukhin bo podal poročilo "" Kakšne vzorce oblikovanja za porazdeljene sisteme uporabljajo razvijalci Amazona, kakšni so razlogi za napake pri storitvah, kaj je arhitektura, ki temelji na celicah, Constant Work, Shuffle Sharding - zanimivo bo. Manj kot mesec dni do konference - . 24. oktober končna podražitev.
Vir: www.habr.com