Debesys yra tarsi stebuklinga dėžutė – paklausi, ko tau reikia, o resursai tiesiog atsiranda iš niekur. Virtualios mašinos, duomenų bazės, tinklas – visa tai priklauso tik jums. Yra ir kitų debesų nuomininkų, bet jūsų Visatoje jūs esate vienintelis valdovas. Esate tikri, kad visada gausite reikiamus išteklius, į nieką neatsižvelgiate ir patys nustatote, koks bus tinklas. Kaip veikia ši magija, dėl kurios debesis elastingai paskirsto išteklius ir visiškai izoliuoja nuomininkus vienas nuo kito?
AWS debesis yra nepaprastai sudėtinga sistema, kuri evoliuciškai vystosi nuo 2006 m. Dalis šios plėtros įvyko Vasilijus Pantyukhinas – „Amazon Web Services“ architektas. Būdamas architektas, jis gali pažvelgti ne tik į galutinį rezultatą, bet ir į AWS įveikiamus iššūkius. Kuo geriau supranti, kaip veikia sistema, tuo didesnis pasitikėjimas. Todėl Vasilijus pasidalins AWS debesijos paslaugų paslaptimis. Žemiau pateikiamas fizinių AWS serverių dizainas, elastingas duomenų bazės mastelio keitimas, tinkinta „Amazon“ duomenų bazė ir metodai, skirti padidinti virtualių mašinų našumą, kartu mažinant jų kainą. Žinios apie „Amazon“ architektūrinius metodus padės efektyviau naudotis AWS paslaugomis ir gali suteikti naujų idėjų, kaip kurti savo sprendimus.
Apie pranešėją: Vasilijus Pantyukhinas () pradėjo kaip Unix administratorius .ru įmonėse, 6 metus dirbo su didele Sun Microsystem technine įranga ir 11 metų skelbė apie duomenis orientuotą pasaulį EMC. Jis natūraliai išsivystė į privačius debesis, o 2017 metais persikėlė į viešuosius. Dabar jis teikia techninius patarimus, padedančius gyventi ir tobulėti AWS debesyje.
Atsakomybės apribojimas: visa žemiau yra asmeninė Vasilijaus nuomonė ir gali nesutapti su Amazon Web Services pozicija. Ataskaitą, kuria remiasi straipsnis, rasite mūsų „YouTube“ kanale.
Kodėl aš kalbu apie „Amazon“ įrenginį?
Mano pirmasis automobilis turėjo mechaninę pavarų dėžę. Tai buvo puiku dėl jausmo, kad galiu vairuoti automobilį ir visiškai jį valdyti. Patiko ir tai, kad bent apytiksliai supratau jo veikimo principą. Natūralu, kad dėžės struktūrą įsivaizdavau gana primityvią – kažką panašaus į dviračio pavarų dėžę.
Viskas buvo puiku, išskyrus vieną dalyką – įstrigo kamščiuose. Atrodo, kad sėdi ir nieko nedarai, bet nuolat perjungiate pavaras, spaudžiate sankabą, dujas, stabdžius – tai tikrai jus vargina. Kamščių problema iš dalies buvo išspręsta, kai šeima gavo automatinį automobilį. Važiuodamas turėjau laiko kažką pagalvoti ir pasiklausyti audioknygos.
Mano gyvenime atsirado dar viena paslaptis, nes visiškai nustojau suprasti, kaip veikia mano automobilis. Šiuolaikinis automobilis yra sudėtingas įrenginys. Automobilis vienu metu prisitaiko prie dešimčių skirtingų parametrų: dujų spaudimo, stabdžių, vairavimo stiliaus, kelio kokybės. Aš nebesuprantu, kaip tai veikia.
Kai pradėjau dirbti su Amazon debesiu, man tai taip pat buvo paslaptis. Tik ši paslaptis yra eilės tvarka didesnė, nes automobilyje yra vienas vairuotojas, o AWS jų – milijonai. Visi vartotojai vienu metu vairuoja, spaudžia dujas ir stabdo. Nuostabu, kad jie eina kur nori – man tai stebuklas! Sistema automatiškai prisitaiko, keičia mastelį ir elastingai prisitaiko prie kiekvieno vartotojo taip, kad jam atrodytų, jog jis yra vienas šioje Visatoje.
Magija šiek tiek išblėso, kai vėliau atėjau dirbti „Amazon“ architektu. Mačiau, su kokiomis problemomis susiduriame, kaip jas sprendžiame, kaip vystome paslaugas. Vis geriau suprantant, kaip sistema veikia, atsiranda daugiau pasitikėjimo paslauga. Taigi noriu pasidalinti nuotrauka, kas yra po AWS debesies gaubtu.
Apie ką kalbėsime
Pasirinkau diversifikuotą požiūrį – atrinkau 4 įdomias paslaugas, apie kurias verta kalbėti.
Serverio optimizavimas. Trumpalaikiai debesys su fiziniu įsikūnijimu: fiziniai duomenų centrai, kuriuose yra fizinių serverių, kurie dūzgia, įkaista ir mirksi šviesomis.
Funkcijos be serverio (Lambda) yra turbūt labiausiai keičiamo dydžio paslauga debesyje.
Duomenų bazės mastelio keitimas. Papasakosiu apie tai, kaip mes kuriame savo keičiamo dydžio duomenų bazes.
Tinklo mastelio keitimas. Paskutinė dalis, kurioje atidarysiu mūsų tinklo įrenginį. Tai nuostabus dalykas – kiekvienas debesies vartotojas tiki, kad debesyje yra vienas ir visiškai nemato kitų nuomininkų.
Pastaba. Šiame straipsnyje bus aptariamas serverio optimizavimas ir duomenų bazės mastelio keitimas. Tinklo mastelio keitimą apsvarstysime kitame straipsnyje. Kur yra be serverio funkcijos? Apie juos buvo paskelbta atskira nuoraša ““ Jame kalbama apie kelis skirtingus mastelio keitimo metodus ir išsamiai aptariamas Firecracker sprendimas – geriausių virtualios mašinos ir konteinerių savybių simbiozė.
Serveriai
Debesis yra trumpalaikis. Tačiau šis efemeriškumas vis dar turi fizinį įsikūnijimą – serverius. Iš pradžių jų architektūra buvo klasikinė. Standartinis x86 mikroschemų rinkinys, tinklo plokštės, Linux, Xen hipervizorius, kuriame buvo paleistos virtualios mašinos.
2012 metais ši architektūra gana gerai susidorojo su savo užduotimis. „Xen“ yra puikus hipervizorius, tačiau jis turi vieną didelį trūkumą. Jam užtenka didelės pridėtinės išlaidos įrenginio emuliacijai. Kai atsiranda naujų greitesnių tinklo plokščių arba SSD diskų, šios papildomos išlaidos tampa per didelės. Kaip spręsti šią problemą? Mes nusprendėme dirbti dviem frontais vienu metu - optimizuoti aparatinę įrangą ir hipervizorių. Užduotis labai rimta.
Aparatinės įrangos ir hipervizoriaus optimizavimas
Viską daryti iš karto ir gerai daryti nepavyks. Kas buvo „geras“, iš pradžių taip pat buvo neaišku.
Nusprendėme laikytis evoliucinio požiūrio – keičiame vieną svarbų architektūros elementą ir metame jį į gamybą.
Užlipame ant kiekvieno grėblio, išklausome nusiskundimų ir pasiūlymų. Tada keičiame kitą komponentą. Taigi, atsižvelgdami į vartotojų atsiliepimus ir palaikymą, mažais žingsneliais radikaliai keičiame visą architektūrą.
Transformacija prasidėjo 2013 m. nuo sudėtingiausio dalyko – tinklo. IN С3 atvejų prie standartinės tinklo plokštės buvo pridėta speciali Network Accelerator kortelė. Jis buvo sujungtas pažodžiui trumpu atgaliniu kabeliu priekiniame skydelyje. Tai nėra gražu, bet debesyje to nesimato. Tačiau tiesioginė sąveika su aparatine įranga iš esmės pagerino virpesį ir tinklo pralaidumą.
Toliau nusprendėme pagerinti prieigą prie blokinių duomenų saugyklos EBS – Elastic Block Storage. Tai tinklo ir saugyklos derinys. Sunkumas yra tas, kad nors rinkoje buvo tinklo greitintuvo kortelės, nebuvo galimybės tiesiog nusipirkti Storage Accelerator aparatinės įrangos. Taigi mes kreipėmės į startuolį Annapurnos laboratorijos, kuris mums sukūrė specialius ASIC lustus. Jie leido nuotolinius EBS tomus montuoti kaip NVMe įrenginius.
Tais atvejais C4 išsprendėme dvi problemas. Pirmasis yra tai, kad įdiegėme perspektyvios, bet tuo metu naujos NVMe technologijos ateities pagrindą. Antra, gerokai apkrovėme centrinį procesorių, perkeldami EBS užklausų apdorojimą į naują kortelę. Pasirodė gerai, todėl dabar „Annapurna Labs“ yra „Amazon“ dalis.
2017 m. lapkričio mėn. supratome, kad atėjo laikas pakeisti patį hipervizorių.
Naujasis hipervizorius buvo sukurtas remiantis modifikuotais KVM branduolio moduliais.
Tai leido iš esmės sumažinti įrenginio emuliacijos išlaidas ir dirbti tiesiogiai su naujais ASIC. Atvejai С5 buvo pirmosios virtualios mašinos su nauju hipervizoriumi, veikiančiu po gaubtu. Mes jį pavadinome Nitro.
Atvejų raida laiko juostoje.
Šiame hipervizoriuje veikia visi nauji virtualių mašinų tipai, kurie pasirodė nuo 2017 m. lapkričio mėn. Bare Metal egzemplioriai neturi hipervizoriaus, bet jie taip pat vadinami Nitro, nes naudoja specializuotas Nitro korteles.
Per ateinančius dvejus metus Nitro egzempliorių tipų skaičius viršijo porą dešimčių: A1, C5, M5, T3 ir kt.
Pavyzdžių tipai.
Kaip veikia šiuolaikinės Nitro mašinos
Jie turi tris pagrindinius komponentus: Nitro hipervizorių (aptartą aukščiau), saugos lustą ir Nitro korteles.
Apsaugos lustas integruota tiesiai į pagrindinę plokštę. Jis valdo daug svarbių funkcijų, pavyzdžiui, pagrindinio kompiuterio OS įkėlimo valdymą.
Nitro kortelės – Jų yra keturios rūšys. Visi jie yra sukurti „Annapurna Labs“ ir yra pagrįsti įprastais ASIC. Kai kurios jų programinės įrangos taip pat yra dažnos.
Keturių tipų Nitro kortelės.
Viena iš kortelių skirta darbui tinkloVPC. Tai matoma virtualiose mašinose kaip tinklo plokštė ENA – elastingas tinklo adapteris. Ji taip pat apima srautą perduodant jį per fizinį tinklą (apie tai kalbėsime antroje straipsnio dalyje), valdo Security Groups ugniasienę ir yra atsakinga už maršruto parinkimą ir kitus tinklo dalykus.
Pasirinktos kortelės veikia su blokų saugykla EBS ir diskai, kurie yra įmontuoti serveryje. Svečio virtualiajai mašinai jie atrodo kaip NVMe adapteriai. Jie taip pat yra atsakingi už duomenų šifravimą ir disko stebėjimą.
Nitro kortelių, hipervizoriaus ir apsaugos lusto sistema yra integruota į SDN tinklą arba Programinės įrangos nustatytas tinklas. Atsakingas už šio tinklo valdymą (Control Plane) valdiklio kortelę.
Žinoma, mes ir toliau kuriame naujus ASIC. Pavyzdžiui, 2018 m. pabaigoje jie išleido „Inferentia“ lustą, leidžiantį efektyviau dirbti su mašininio mokymosi užduotimis.
Inferencia mašininio mokymosi procesoriaus lustas.
Keičiama duomenų bazė
Tradicinė duomenų bazė turi daugiasluoksnę struktūrą. Siekiant labai supaprastinti, išskiriami šie lygiai.
- SQL — su juo dirba klientų ir užklausų dispečeriai.
- Nuostatos sandorius - Čia viskas aišku, RŪGŠTIS ir visa kita.
- talpykloje, kurią teikia buferiniai baseinai.
- Miško ruoša - suteikia darbą su perdarymo žurnalais. MySQL jie vadinami Bin Logs, PosgreSQL - Write Ahead Logs (WAL).
- Sandėliavimas - tiesioginis įrašymas į diską.
Sluoksniuota duomenų bazės struktūra.
Yra įvairių duomenų bazių mastelio keitimo būdų: dalijimasis, bendrinamos nieko architektūra, bendrinami diskai.
Tačiau visi šie metodai palaiko tą pačią monolitinę duomenų bazės struktūrą. Tai žymiai apriboja mastelio keitimą. Norėdami išspręsti šią problemą, sukūrėme savo duomenų bazę − „Amazon Aurora“. Jis suderinamas su MySQL ir PostgreSQL.
„Amazon Aurora“
Pagrindinė architektūrinė idėja yra atskirti saugojimo ir registravimo lygius nuo pagrindinės duomenų bazės.
Žvelgdamas į ateitį, pasakysiu, kad mes taip pat padarėme nepriklausomą talpyklos lygį. Architektūra nustoja būti monolitine, ir mes įgyjame papildomų laisvės laipsnių keisdami atskirus blokus.
Registravimo ir saugojimo lygiai yra atskirti nuo duomenų bazės.
Tradicinė DBVS įrašo duomenis į saugojimo sistemą blokų pavidalu. „Amazon Aurora“ sukūrėme išmaniąją saugyklą, kuri gali kalbėti kalba perdaryti žurnalus. Viduje saugykla žurnalus paverčia duomenų blokais, stebi jų vientisumą ir automatiškai sukuria atsargines kopijas.
Šis požiūris leidžia įgyvendinti tokius įdomius dalykus kaip klonavimas. Jis veikia iš esmės greičiau ir ekonomiškiau dėl to, kad nereikia sukurti pilnos visų duomenų kopijos.
Saugojimo sluoksnis įgyvendinamas kaip paskirstyta sistema. Jį sudaro labai daug fizinių serverių. Kiekvienas perdarymo žurnalas apdorojamas ir išsaugomas vienu metu šeši mazgai. Tai užtikrina duomenų apsaugą ir apkrovos balansavimą.
Skaitymo mastelį galima pakeisti naudojant atitinkamas kopijas. Paskirstyta saugykla pašalina poreikį sinchronizuoti pagrindinį duomenų bazės egzempliorių, per kurį rašome duomenis, ir likusių kopijų. Garantuojama, kad naujausi duomenys bus prieinami visoms kopijoms.
Vienintelė problema yra senų duomenų kaupimas skaitytų kopijų talpykloje. Tačiau ši problema sprendžiama visų perdarymo žurnalų perkėlimas replikoms per vidinį tinklą. Jei žurnalas yra talpykloje, jis pažymimas kaip neteisingas ir perrašomas. Jei jo nėra talpykloje, jis tiesiog išmetamas.
Sutvarkėme saugyklą.
Kaip pakeisti DBVS pakopas
Čia horizontalus mastelio nustatymas yra daug sunkesnis. Taigi eikime pramintu keliu klasikinis vertikalus mastelio keitimas.
Tarkime, kad turime programą, kuri palaiko ryšį su DBVS per pagrindinį mazgą.
Didinant mastelį vertikaliai, skiriame naują mazgą, kuriame bus daugiau procesorių ir atminties.
Tada perjungiame programą iš senojo pagrindinio mazgo į naują. Iškyla problemų.
- Tam reikės didelių programų prastovų.
- Naujasis pagrindinis mazgas turės šaltąją talpyklą. Duomenų bazės našumas bus maksimalus tik sušilus talpyklai.
Kaip pagerinti situaciją? Nustatykite tarpinį serverį tarp programos ir pagrindinio mazgo.
Ką tai mums duos? Dabar visų programų nereikia rankiniu būdu peradresuoti į naują mazgą. Perjungimas gali būti atliekamas naudojant tarpinį serverį ir yra iš esmės greitesnis.
Atrodo, kad problema išspręsta. Bet ne, mes vis dar kenčiame dėl būtinybės sušildyti talpyklą. Be to, atsirado nauja problema – dabar tarpinis serveris yra potencialus gedimo taškas.
Galutinis sprendimas su Amazon Aurora be serverio
Kaip mes išsprendėme šias problemas?
Paliko tarpinį serverį. Tai nėra atskiras egzempliorius, o visas paskirstytas tarpinių serverių, per kuriuos programos jungiasi prie duomenų bazės, parkas. Gedimo atveju bet kurį iš mazgų galima pakeisti beveik akimirksniu.
Pridėtas įvairaus dydžio šiltų mazgų baseinas. Todėl, jei reikia skirti naują didesnio ar mažesnio dydžio mazgą, jis iš karto pasiekiamas. Nereikia laukti, kol jis bus įkeltas.
Visas mastelio keitimo procesas yra kontroliuojamas specialia stebėjimo sistema. Stebėjimas nuolat stebi esamo pagrindinio mazgo būseną. Jei, pavyzdžiui, aptinkama, kad procesoriaus apkrova pasiekė kritinę reikšmę, ji praneša šiltų atvejų telkiniui apie būtinybę skirti naują mazgą.
Paskirstyti tarpiniai serveriai, šilti egzemplioriai ir stebėjimas.
Galimas reikiamos galios mazgas. Į jį nukopijuojami buferiniai telkiniai, o sistema pradeda laukti saugaus momento persijungti.
Paprastai perjungimo momentas ateina gana greitai. Tada ryšys tarp tarpinio serverio ir senojo pagrindinio mazgo sustabdomas, visi seansai perjungiami į naują mazgą.
Tęsiamas darbas su duomenų baze.
Grafike matyti, kad pakaba išties labai trumpa. Mėlyna diagrama rodo apkrovą, o raudoni žingsniai rodo mastelio keitimo momentus. Trumpalaikiai kritimai mėlynoje diagramoje yra būtent toks trumpas delsimas.
Beje, „Amazon Aurora“ leidžia visiškai sutaupyti ir išjungti duomenų bazę, kai ji nenaudojama, pavyzdžiui, savaitgaliais. Sustabdžius apkrovą, DB palaipsniui mažina savo galią ir kuriam laikui išsijungia. Kai apkrova grįš, ji vėl sklandžiai kils.
Kitoje istorijos apie „Amazon“ įrenginį dalyje kalbėsime apie tinklo mastelio keitimą. Prenumeruoti ir sekite naujienas, kad nepraleistumėte straipsnio.
Apie Vasilijus Pantyukhinas skaitys pranešimą ““ Kokius paskirstytų sistemų dizaino modelius naudoja „Amazon“ kūrėjai, kokios yra paslaugų gedimų priežastys, kas yra „Cell-based“ architektūra, „Constant Work“, „Shuffle Sharding“ – bus įdomu. Iki konferencijos liko mažiau nei mėnuo - . spalio 24 d. galutinis kainų padidinimas.
Šaltinis: www.habr.com