Pilved on nagu võlukast – küsid, mida vajad, ja ressursid ilmuvad lihtsalt eikuskilt. Virtuaalsed masinad, andmebaasid, võrk – kõik see kuulub ainult teile. Pilve rentnikke on teisigi, kuid teie Universumis olete ainuvalitseja. Olete kindel, et saate alati vajalikud ressursid, te ei arvesta kellegagi ja määrate iseseisvalt, milline võrk saab olema. Kuidas toimib see maagia, mis paneb pilve elastselt ressursse eraldama ja üürnikke üksteisest täielikult isoleerima?
AWS-pilv on mega-ülikompleksne süsteem, mis on evolutsiooniliselt arenenud alates 2006. aastast. Osa sellest arengust toimus Vassili Pantjuhhin - Amazoni veebiteenuste arhitekt. Arhitektina näeb ta mitte ainult lõpptulemust, vaid ka väljakutseid, mida AWS ületab. Mida suurem on arusaam süsteemi toimimisest, seda suurem on usaldus. Seetõttu jagab Vassili AWS-i pilveteenuste saladusi. Allpool on toodud füüsiliste AWS-serverite disain, elastne andmebaasi skaleeritavus, kohandatud Amazoni andmebaas ja meetodid virtuaalmasinate jõudluse suurendamiseks, vähendades samal ajal nende hinda. Amazoni arhitektuuriliste lähenemisviiside tundmine aitab teil AWS-i teenuseid tõhusamalt kasutada ja võib anda teile uusi ideid oma lahenduste loomiseks.
Kõneleja kohta: Vassili Pantyukhin () alustas Unixi administraatorina .ru ettevõtetes, töötas 6 aastat suure Sun Microsystemi riistvara kallal ja jutlustas 11 aastat EMC-s andmekeskset maailma. See arenes loomulikult privaatpilvedeks ja 2017. aastal liikus see üle avalikesse pilvedesse. Nüüd annab ta tehnilist nõu, et aidata AWS-i pilves elada ja areneda.
Kohustustest loobumine: kõik allpool on Vassili isiklik arvamus ja ei pruugi kattuda Amazon Web Services'i seisukohaga. Artikli aluseks olev aruanne on saadaval meie YouTube'i kanalil.
Miks ma räägin Amazoni seadmest?
Minu esimesel autol oli manuaalkäigukast. Suurepärane oli tunne, et saan autot juhtida ja oman selle üle täielikku kontrolli. Mulle meeldis ka see, et sain selle toimimise põhimõttest vähemalt umbkaudu aru. Loomulikult kujutasin ma karbi ülesehitust ette üsna primitiivsena - umbes nagu jalgratta käigukast.
Kõik oli suurepärane, välja arvatud üks asi – ummikutesse kinni jäänud. Näib, et istud ega tee midagi, aga vahetad pidevalt käike, vajutad sidurit, gaasi, pidurit – see väsitab sind tõesti. Ummikuprobleem lahenes osaliselt, kui pere sai endale automaatse auto. Sõidu ajal oli aega millegi üle mõelda ja audioraamatut kuulata.
Minu ellu ilmus veel üks mõistatus, sest ma ei mõistnud täielikult, kuidas mu auto töötab. Kaasaegne auto on keeruline seade. Auto kohandub samaaegselt kümnete erinevate parameetritega: gaasi vajutamine, pidur, sõidustiil, tee kvaliteet. Ma ei saa enam aru, kuidas see töötab.
Kui hakkasin Amazoni pilvega tegelema, oli see ka minu jaoks mõistatus. Ainult see mõistatus on suurusjärgu võrra suurem, sest autos on üks juht ja AWS-is on neid miljoneid. Kõik kasutajad juhivad korraga, vajutavad gaasi ja pidurdavad. See on hämmastav, et nad lähevad, kuhu tahavad – see on minu jaoks ime! Süsteem kohandub, mastaabib ja kohandub elastselt automaatselt iga kasutajaga nii, et talle tundub, et ta on selles Universumis üksi.
Võlu kadus veidi, kui hiljem tulin Amazoni arhitektina tööle. Nägin, milliste probleemidega me silmitsi seisame, kuidas neid lahendame ja kuidas teenuseid arendame. Süsteemi toimimise mõistmisel suureneb usaldus teenuse vastu. Seega tahan jagada pilti sellest, mis on AWS-i pilve kapoti all.
Millest me räägime
Valisin mitmekülgse lähenemise – valisin välja 4 huvitavat teenust, millest tasub rääkida.
Serveri optimeerimine. Füüsilise kehastusega lühiajalised pilved: füüsilised andmekeskused, kus on füüsilised serverid, mis ümisevad, kuumenevad ja vilguvad tuledega.
Serverita funktsioonid (Lambda) on ilmselt kõige skaleeritavam teenus pilves.
Andmebaasi skaleerimine. Ma räägin teile, kuidas me oma skaleeritavaid andmebaase loome.
Võrgu skaleerimine. Viimane osa, milles avan meie võrgu seadme. See on imeline asi – iga pilve kasutaja usub, et on pilves üksi ega näe teisi rentnikke üldse.
Märge. Selles artiklis käsitletakse serveri optimeerimist ja andmebaasi skaleerimist. Järgmises artiklis käsitleme võrgu skaleerimist. Kus on serverita funktsioonid? Nende kohta avaldati eraldi ärakiri "" Räägitakse mitmest erinevast skaleerimismeetodist ning käsitletakse üksikasjalikult Firecrackeri lahendust – virtuaalmasina ja konteinerite parimate omaduste sümbioos.
Serverid
Pilv on lühiajaline. Kuid sellel efemeersusel on ikkagi füüsiline kehastus - serverid. Algselt oli nende arhitektuur klassikaline. Standardne x86 kiibistik, võrgukaardid, Linux, Xen hüperviisor, millel virtuaalmasinaid käivitati.
2012. aastal tuli see arhitektuur oma ülesannetega päris hästi toime. Xen on suurepärane hüperviisor, kuid sellel on üks oluline puudus. Tal on küllalt suured üldkulud seadme emuleerimiseks. Kui saadavale tulevad uued kiiremad võrgukaardid või SSD-draivid, muutub see üldkulu liiga suureks. Kuidas selle probleemiga toime tulla? Otsustasime töötada kahel rindel korraga - optimeerida nii riistvara kui ka hüperviisorit. Ülesanne on väga tõsine.
Riistvara ja hüperviisori optimeerimine
Kõike korraga ja hästi tehes ei õnnestu. Mis oli "hea", oli samuti esialgu ebaselge.
Otsustasime kasutada evolutsioonilist lähenemist – muudame üht olulist arhitektuuri elementi ja viskame selle tootmisse.
Astume iga reha otsa, kuulame kaebusi ja ettepanekuid. Seejärel muudame teist komponenti. Seega muudame kasutajatelt ja toel saadud tagasiside põhjal väikeste sammude kaupa radikaalselt kogu arhitektuuri.
Ümberkujundamine algas 2013. aastal kõige keerulisema asjaga – võrguga. IN С3 juhtudel lisati standardsele võrgukaardile spetsiaalne Network Acceleratori kaart. See ühendati sõna otseses mõttes lühikese loopback-kaabliga esipaneelil. See pole ilus, kuid seda pole pilves näha. Kuid otsene suhtlemine riistvaraga parandas oluliselt värinat ja võrgu läbilaskevõimet.
Järgmisena otsustasime parandada juurdepääsu plokkide andmesalvestusele EBS - Elastic Block Storage. See on võrgu ja salvestusruumi kombinatsioon. Raskus seisneb selles, et kuigi Network Acceleratori kaardid olid turul olemas, ei olnud võimalust Storage Acceleratori riistvara lihtsalt osta. Seega pöördusime idufirma poole Annapurna laborid, kes töötas meie jaoks välja spetsiaalsed ASIC-kiibid. Need võimaldasid kaug-EBS-i köiteid paigaldada NVMe-seadmetena.
Juhtudel C4 lahendasime kaks probleemi. Esimene on see, et võtsime kasutusele paljulubava, kuid tol ajal uue NVMe tehnoloogia tuleviku aluse. Teiseks laadisime oluliselt maha keskprotsessori, viies EBSi päringute töötlemise uuele kaardile. See osutus hästi, nii et nüüd on Annapurna Labs osa Amazonist.
2017. aasta novembriks saime aru, et on aeg vahetada hüperviisor ise.
Uus hüperviisor töötati välja muudetud KVM-i tuumamoodulite põhjal.
See võimaldas oluliselt vähendada seadme emuleerimise üldkulusid ja töötada otse uute ASIC-idega. Juhtumid С5 olid esimesed virtuaalmasinad, mille kapoti all töötas uus hüperviisor. Me panime talle nime Nitro.
Juhtumite areng ajateljel.
Kõik uut tüüpi virtuaalmasinad, mis on ilmunud alates 2017. aasta novembrist, töötavad sellel hüperviisoril. Bare Metal eksemplaridel ei ole hüperviisorit, kuid neid nimetatakse ka Nitroks, kuna nad kasutavad spetsiaalseid Nitro kaarte.
Järgmise kahe aasta jooksul ületas Nitro eksemplaride tüüpide arv paarikümne piiri: A1, C5, M5, T3 jt.
Eksemplari tüübid.
Kuidas kaasaegsed Nitro masinad töötavad
Neil on kolm põhikomponenti: Nitro hüperviisor (seda käsitleti eespool), turvakiip ja Nitro kaardid.
Turvakiip integreeritud otse emaplaadile. See juhib paljusid olulisi funktsioone, nagu näiteks hosti OS-i laadimise juhtimine.
Nitro kaardid - Neid on nelja tüüpi. Kõik need on välja töötatud Annapurna Labsi poolt ja põhinevad tavalistel ASIC-idel. Mõned nende püsivara on samuti levinud.
Nelja tüüpi Nitro kaarte.
Üks kaartidest on mõeldud kasutamiseks võrkuVPC. See on virtuaalmasinates võrgukaardina nähtav ENA – elastne võrguadapter. Samuti kapseldab see liiklust füüsilise võrgu kaudu edastamisel (sellest räägime artikli teises osas), juhib turvagruppide tulemüüri ning vastutab marsruutimise ja muude võrguasjade eest.
Valitud kaardid töötavad plokisalvestusega EBS ja serverisse sisseehitatud kettad. Need kuvatakse külalise virtuaalmasinale kui NVMe adapterid. Nad vastutavad ka andmete krüptimise ja ketta jälgimise eest.
Nitro kaartide, hüperviisori ja turvakiibi süsteem on integreeritud SDN võrku või Tarkvaraga määratletud võrk. Selle võrgu haldamise eest vastutav (juhttasand) kontrolleri kaart.
Loomulikult jätkame uute ASIC-ide väljatöötamist. Näiteks 2018. aasta lõpus lasid nad välja Inferentia kiibi, mis võimaldab masinõppe ülesannetega tõhusamalt töötada.
Inferencia masinõppeprotsessori kiip.
Skaleeritav andmebaas
Traditsioonilisel andmebaasil on kihiline struktuur. Suureks lihtsustamiseks eristatakse järgmisi tasemeid.
- SQL — selle kallal töötavad kliendi- ja tellimuse dispetšerid.
- Eraldised tehingud - siin on kõik selge, HAPE ja kõik muu.
- vahemällu salvestamine, mida pakuvad puhverbasseinid.
- Logimine — annab tööd ümbertegemise logidega. MySQL-is nimetatakse neid prügilogideks, PosgreSQL-is - WAL (Write Ahead Logs).
- Ladustamine - otse salvestamine kettale.
Kihiline andmebaasi struktuur.
Andmebaaside skaleerimiseks on erinevaid viise: sharding, Shared Nothing arhitektuur, jagatud kettad.
Kuid kõik need meetodid säilitavad sama monoliitse andmebaasi struktuuri. See piirab oluliselt skaleerimist. Selle probleemi lahendamiseks töötasime välja oma andmebaasi − Amazonase Aurora. See ühildub MySQL-i ja PostgreSQL-iga.
Amazonase Aurora
Peamine arhitektuurne idee on eraldada põhiandmebaasist salvestus- ja logitasemed.
Tulevikku vaadates ütlen, et muutsime ka vahemälu taseme sõltumatuks. Arhitektuur lakkab olemast monoliit ja me saame täiendavaid vabadusastmeid üksikute plokkide skaleerimisel.
Logimise ja salvestustasemed on andmebaasist eraldi.
Traditsiooniline DBMS kirjutab andmed salvestussüsteemi plokkide kujul. Amazon Auroras lõime nutika salvestusruumi, mis suudab keelt rääkida redo-logs. Sees muudab salvestuslogid andmeplokkideks, jälgib nende terviklikkust ja varundab automaatselt.
See lähenemine võimaldab teil rakendada selliseid huvitavaid asju nagu kloonimine. See töötab põhimõtteliselt kiiremini ja ökonoomsemalt, kuna see ei nõua kõigist andmetest täieliku koopia loomist.
Salvestuskiht on rakendatud hajutatud süsteemina. See koosneb väga suurest hulgast füüsilistest serveritest. Iga korduslogi töödeldakse ja salvestatakse samaaegselt kuus sõlme. See tagab andmekaitse ja koormuse tasakaalustamise.
Lugemise skaleerimist saab saavutada sobivate koopiate abil. Jaotatud salvestusruum välistab vajaduse sünkroonida peamise andmebaasi eksemplari, mille kaudu me andmeid kirjutame, ja ülejäänud koopiate vahel. Ajakohased andmed on garanteeritud kõigile koopiatele.
Ainus probleem on vanade andmete vahemällu salvestamine loetud koopiatele. Kuid see probleem on lahendatud kõigi redo logide ülekandmine koopiatele sisevõrgu kaudu. Kui logi on vahemälus, märgitakse see ebaõigeks ja kirjutatakse üle. Kui seda vahemälus pole, visatakse see lihtsalt ära.
Korraldasime panipaiga.
DBMS-i tasandite skaleerimine
Siin on horisontaalne skaleerimine palju keerulisem. Nii et lähme mööda läbimõeldud teed klassikaline vertikaalne skaleerimine.
Oletame, et meil on rakendus, mis suhtleb DBMS-iga peasõlme kaudu.
Vertikaalselt skaleerimisel eraldame uue sõlme, millel on rohkem protsessoreid ja mälu.
Järgmisena lülitame rakenduse vanalt põhisõlmelt uuele. Probleemid tekivad.
- See nõuab märkimisväärset rakenduse seisakut.
- Uuel põhisõlmel on külm vahemälu. Andmebaasi jõudlus on maksimaalne alles pärast vahemälu soojenemist.
Kuidas olukorda parandada? Seadistage puhverserver rakenduse ja põhisõlme vahel.
Mida see meile annab? Nüüd ei pea kõiki rakendusi käsitsi uude sõlme ümber suunama. Ümberlülitamist saab teha puhverserveri all ja see on põhimõtteliselt kiirem.
Tundub, et probleem on lahendatud. Aga ei, me kannatame endiselt vahemälu soojendamise vajaduse all. Lisaks on ilmnenud uus probleem - nüüd on puhverserver potentsiaalne tõrkekoht.
Lõplik lahendus Amazon Aurora serverita
Kuidas me need probleemid lahendasime?
Jättis puhverserveri. See ei ole eraldiseisev eksemplar, vaid terve hajutatud puhverserver, mille kaudu rakendused andmebaasiga ühenduse loovad. Rikke korral saab mis tahes sõlme peaaegu kohe välja vahetada.
Lisatud erineva suurusega soojade sõlmede kogum. Seega, kui on vaja eraldada uus suurema või väiksema suurusega sõlm, on see kohe saadaval. Pole vaja oodata, kuni see laaditakse.
Kogu skaleerimisprotsessi juhib spetsiaalne jälgimissüsteem. Jälgimine jälgib pidevalt praeguse peasõlme olekut. Kui see tuvastab näiteks, et protsessori koormus on jõudnud kriitilise väärtuseni, teavitab see soojade eksemplaride kogumit vajadusest eraldada uus sõlm.
Jaotatud puhverserverid, soojad eksemplarid ja jälgimine.
Vajaliku võimsusega sõlm on saadaval. Sellesse kopeeritakse puhverkogumid ja süsteem hakkab ootama üleminekuks ohutut hetke.
Tavaliselt saabub üleminekuhetk üsna kiiresti. Seejärel peatatakse side puhverserveri ja vana põhisõlme vahel, kõik seansid lülitatakse üle uuele sõlmele.
Töö andmebaasiga jätkub.
Graafik näitab, et vedrustus on tõepoolest väga lühike. Sinine graafik näitab koormust ja punased sammud skaleerimismomente. Lühiajalised langused sinisel graafikul on just see lühike viivitus.
Muide, Amazon Aurora võimaldab teil täielikult raha säästa ja andmebaasi välja lülitada, kui seda ei kasutata, näiteks nädalavahetustel. Pärast koormuse peatamist vähendab DB järk-järgult oma võimsust ja lülitub mõneks ajaks välja. Kui koormus tagasi tuleb, tõuseb see uuesti sujuvalt.
Amazoni seadme loo järgmises osas räägime võrgu skaleerimisest. Telli ja olge kursis, et te artiklist ilma ei jääks.
Edasi Vassili Pantjuhhin annab ettekande "" Milliseid hajutatud süsteemide disainimustreid kasutavad Amazoni arendajad, mis on teenusetõrgete põhjused, mis on rakupõhine arhitektuur, pidev töö, segajagamine - see on huvitav. Vähem kui kuu aega konverentsini - . 24. oktoober lõplik hinnatõus.
Allikas: www.habr.com