Pilved on nagu maagiline karp — ütled, mida vajad, ja ressursid ilmuvad lihtsalt tühjusest. Virtuaalmasinad, andmebaasid, võrk — kõik need kuuluvad ainult sulle. On ka teisi pilvekaaslasi, kuid oma Universumis oled sa ainus valitseja. Sa oled kindel, et saad alati vajalikud ressursid, ei pea kellegagi arvestama ja määrad ise, milline sinu võrk on. Kuidas toimub see maagia, mis sunnib pilve paindlikult ressursse jaotama ning täielikult eraldama kaaslasi üksteisest?
AWS pilv on superkeeruline süsteem, mis on arenemas alates 2006. aastast. Osa sellest arengust tabas Vasili Pantjuhin — Amazon Web Servicesi arhitekt. Arhitektina näeb ta mitte ainult lõpptulemust, vaid ka keerulisi küsimusi, mida AWS ületab. Mida rohkem ta süsteemi tööpõhimõtteid mõistab, seda rohkem usaldust see tekitab. Seetõttu jagab Vasili AWS-i pilveteenuste saladusi. Allpool on arutletud AWS-i füüsiliste serverite ülesehitust, paindlikku andmebaasi skaleeritavust, kohandatud Amazon-i andmebaasi ja meetodeid virtuaalmasinate jõudluse tõstmiseks ning samal ajal nende hindade alandamiseks. Amazon-i arhitektuuri põhimõtete tundmine aitab AWS-i teenuseid efektiivsemalt kasutada ja võib-olla pakub uusi ideid oma lahenduste loomisel.
Esinejast: Vasili Pantjuhin () alustas Unix-administraatorina .ru ettevõtetes, töötas 6 aastat suurte Sun Microsystemi masinatega ning 11 aastat propageeris andmekeskuse keskset lähenemist EMC-s. Loomulikul teel on ta arenenud privaatsete pilvede suunas ning 2017. aastal kolis avalikesse pilvedesse. Praegu aitab ta tehniliste nõuannetega elada ja areneda AWS-i keskkonnas.
Eritingimus: kõik, mis järgneb, on isiklik arvamus Vasili poolt ja ei pruugi kattuda Amazon Web Servicesi seisukohtadega. ettekandest, mille põhjal see artikkel loodud, on saadaval meie YouTube'i kanalil.
Miks ma räägin Amazonist?
Minu esimene auto oli manuaalkäigukastiga. See oli suurepärane tunne, et saan autot juhtida ja seda täielikult kontrollida. Mulle meeldis ka see, et ma vähemalt suurusjärgus mõistsin, kuidas see töötab. Loomulikult kujutasin ma käigukasti seadet üsna primitiivselt — umbes nagu jalgratta käigukast.
Kõik oli suurepärane, välja arvatud üks asi — ummikutes seismine. Tundub, et istud ja ei tee midagi, kuid pidevalt lülitad käike, vajutad sidurit, gaasi ja pidurit — sellest väsib päriselt ära. Probleem ummikutes osaliselt kadus, kui peresse tuli automaatkäigukastiga auto. Rohul on nüüd aega millegi üle mõelda ja kuulata audioraamatuid.
Veel tuli mu ellu mõistatus, sest ma ei saanud enam üldse aru, kuidas mu auto töötab. Kaasaegne auto on keeruline seade. Auto kohandub korraga kümnete erinevate parameetritega: gaasi, piduri vajutamine, sõidustiil, tee kvaliteet. Ma ei saa enam aru, kuidas see töötab.
Kui ma esmakordselt Amazon Cloudiga tegelema hakkasin, oli see ka minu jaoks mõistatus. Ainult et see müsteerium on omamoodi kõrgema taseme, sest masinas on üks juht, aga AWS-is on neid miljoneid. Kõik kasutajad juhivad samaaegselt, vajutavad gaasile ja pidurile. Imeline, et nad jõuavad sinna, kuhu soovivad — see on minu jaoks imetabane! Süsteem kohandub automaatselt, skaleerub ja paindlikult kohandub igale kasutajale nii, et tal tundub, et ta on üksi selles universumis.
Magi hakkas veidi hajuma, kui ma hiljem Amazonis arhitektina tööle asusin. Nägin, milliste probleemidega me silmitsi seisame, kuidas me neid lahendame ja kuidas teenuseid arendame. Kui arusaamine süsteemi toimimisest suureneb, suureneb ka usaldus teenuse vastu. Seetõttu tahan jagada pilti sellest, mis AWS-i pilve all toimub.
Millest räägime
Valisin mitmekesise lähenemise — valisin 4 huvitavat teenust, millest tasub rääkida.
Serverite optimeerimine. Efemeersed pilved füüsilise kujundusega: füüsilised andmekeskused, kus asuvad füüsilised serverid, mis humisevad, kuumenevad ja vilguvad tuledega.
Serverless-funktsioonid (Lambda) — ilmselt kõige skaleeritavam teenus pilves.
Andmebaasi skaleerimine. Räägin, kuidas me oma skaleeritavaid andmebaase ehitame.
Võrgu skaleerimine. Viimane osa, kus avan meie võrgu seadistust. See on imeline asi — iga pilvekasutaja arvab, et ta on üksi pilves ja ei näe teisi kliente.
Märkus. Selles artiklis käsitletakse serverite optimeerimist ja andmebaaside skaleerimist. Võrgu skaleerimist arutame järgmises artiklis. Kus on serverivabad funktsioonid? Nende kohta ilmus eraldi selgitus «». Selles räägitakse mitmest erinevast skaleerimisviisist ning põhjalikult analüüsitakse Firecrackeri lahendust — parimate virtuaalmasina ja konteinerite omaduste sümbioos.
Serverid
Pilv on efemeerne. Kuid selle efemeersusel on siiski füüsiline kehastus — serverid. Alguses oli nende arhitektuur klassikaline. Tavaline x86 kiibistik, võrkaartid, Linux, hüpervisor Xen, millel käivitatud virtuaalmasinad.
2012. aastal täitis selline arhitektuur täiesti oma ülesandeid. Xen on suurepärane hüpervisor, kuid ühe tõsise puudusega. Tal on piisavalt kõrged seadmete emuleerimise kulud. Uute kiiremate võrgukaartide või SSD-diskide ilmumisega muutuvad need kulud liiga kõrgeks. Kuidas selle probleemiga toime tulla? Otsustasime töötada korraga kahel rindel — optiimimine nii riistvarale kui ka hüperviisorile. Ülesanne on väga tõsine.
Riistvara ja hüperviisori optimeerimine
Kõiki asju korraga hästi teha ei õnnestu. Mis on 'hästi', ei olnud alguses samuti selge.
Otsustasime kasutada evolutsioonilist lähenemist — muudame ühe olulise arhitektuuri elemendi ja viime selle tootmisse.
Astume kõikidele komistuskividele, kuulame kaebusi ja ettepanekuid. Seejärel muudame teist komponenti. Nii, väikeste sammudega, muudame kogu arhitektuuri, tuginedes kasutajate ja toe tagasisidele.
Muudatused algasid 2013. aastal kõige keerulisemast — võrgust. C3 instantsidesse lisati tavalisest võrguadapterist eraldi kaart Network Accelerator. See ühendati sõna otseses mõttes lühikese loopback-kaabliga seadme esipaneelil. Kole, aga pilves ei ole seda näha. Küll aga parandas otsene kapcsolat riistvaraga oluliselt jitterit ja võrgu läbilaskevõimet. standarda võrkaartide instantsidesse on lisatud spetsiaalne kaardimoodul Network Accelerator. See oli ühendatud lühikese loopback-kaabliga esiarmatuuri. Ükski ei tundu ilus, aga pilves ei ole seda näha. Otsene suhtlemine riistvaraga on põhimõtteliselt parandanud jitter'i ja võrgu läbilaskevõimet.
Edasi liikusime EBS-i (Elastic Block Storage) andmesalvestuse parendamise nimel. See on võrgu ja salvestuse kombinatsioon. Probleemiks oli, et turul olid olemas Network Accelerator'i kaardid, kuid Storage Accelerator'i riistvara ostmiseks võimalusi polnud. Seetõttu pöördusime idufirma Annapurna Labs, mis arendas meile spetsiaalsed ASIC kiibid. Need võimaldasid kaugtehnoloogiate EBS-i ühendamist NVMe seadmetena.
Instance'ides C4 lahendasime kaks ülesannet. Esiteks - valmistusime ära tulevikuks NVMe lubava, kuid toona uue tehnoloogia jaoks. Teiseks - vabastasime oluliselt keskprotsessori koormust, suunates EBS-i päringute töötlemise uuele kaardile. See õnnestus, mistõttu on Annapurna Labs nüüd Amazon'i osa.
Novembri 2017. aastaks mõistsime, et on aeg vahetada ka hüperviisor.
Uus hüperviisor loodi KVM-i (Kernel-based Virtual Machine) täiustatud moodulite põhjal.
See võimaldas oluliselt vähendada seadmete emulatsioonikulutusi ja töötada otse uute ASIC-idega. Instantsid C5 olid esimesed virtuaalmasinad, mille all töötas uus hüperviisor. Nimeks panime selle Nitro.
Instantside evolutsioon ajaskaalal.
Kõik uued virtuaalmasinate tüübid, mis ilmusid novembris 2017, töötavad selle hüperviisori peal. Raudse Bare Metal instantsidel ei ole hüperviisorit,kuid neid nimetatakse samuti Nitroks, kuna nad kasutavad spetsialiseeritud Nitro-kaarte.
Järgmisel kahel aastal ületas Nitro-instantside tüüpide arv paari tosinat: A1, C5, M5, T3 ja teised.
Instantside tüübid.
Kuidas on tänapäeva Nitro-masinad üles ehitatud
Nendel on kolm põhikomponenti: Nitro-hüperviisor (millest rääkisime varem), turvakiip ja Nitro-kaardid.
Turvakiip on integreeritud otse emaplaati. See kontrollib paljusid olulisi funktsioone, näiteks host-OS-i käivitamise kontrolli.
Nitro-kaardid — neid on neli tüüpi. Kõik on välja töötanud Annapurna Labs ja põhinevad ühistel ASIC-idel. Osaliselt on nende püsivara samuti ühine.
Neli tüüpi Nitro-kaarti.
Üks kaart on ette nähtud töötamiseks võrgugaVPC.Just seda nähakse virtuaalmasinates kui võrguadapterit. ENA — Elastic Network Adaptor.Samuti kapseldab see liiklust, kui see edastatakse füüsilise võrgu kaudu (sellest räägime artikli teises osas), kontrollib Security Groups tulemüüre, vastutab marsruutimise ja teiste võrguasjade eest.
Üksikud kaardid töötavad plokkhoidla süsteemiga EBS ja ketastega, mis on serverisse integreeritud. Külalisvirtuaalmasinas esitatakse need kui NVMe-adapterid. Need vastutavad ka andmete krüpteerimise ja ketaste jälgimise eest.
Nitro-kaartide süsteem, hüperviisor ja turvakiip on ühendatud SDN või Software Defined Network. Selle võrgu (Control Plane) haldamise eest vastutab kontrollerkaart.
Loomulikult jätkame uute ASIC-ide arendamist. Näiteks 2018. aasta lõpus esitlesime Inferentia kiipi, mis võimaldab tõhusamalt tegeleda masinõppe ülesannetega.
Inferentia masinõppeprotsessor.
Skaleeritav andmebaas
Traditsiooniline andmebaas omab kihilist struktuuri. Kui väga lihtsustada, siis eristuvad järgmised tasemed.
- SQL — seal töötavad kliendi ja päringu haldajad.
- Tehingute tagamine — siin on kõik selge, ACID ja kõik selline.
- Vahemälu, mida tagavad puhverpaisud.
- Logimine — tagab redo-logide töötamise. MySQL-is nimetatakse neid Bin Logs, PostgreSQL-is — Write Ahead Logs (WAL).
- Hoidmine – otsene salvestamine kettale.
Andmebaasi kihiline struktuur.
Andmeid saab skaleerida mitmeti: sharding, jagatud arhitektuur, jagatud kettad.
Siiski, kõik need meetodid säilitavad sama monoliitse andmebaasi struktuuri. See piirab oluliselt skaleeritavust. Selle probleemi lahendamiseks oleme välja töötanud oma andmebaasi — Amazon Aurora. See on ühilduv MySQL ja PostgreSQL-ga.
Amazon Aurora
Peamine arhitektuurne idee on eraldada salvestus- ja logimiskiht põhiteenusest.
Käesolevaga ütlen, et ka vahemälu tase on meil iseseisev. Arhitektuur ei ole enam monoliitne ja saame individuaalsete plokkide skaleerimisel lisavabadust.
Logimis- ja salvestuskiht on andmebaasist eraldatud.
Traditsiooniline andmebaasisüsteem salvestab andmed salvestussüsteemi plokkidena. Amazon Aurora-s oleme loonud „nutika“ salvestuse, mis suudab rääkida redo-logide. Salvestus muudab logid andmeplokkideks, jälgib nende terviklikkust ja teeb automaatseid varukoopiaid.
See lähenemine võimaldab ellu viia palju huvitavaid asju nagu kloneerimine. Selle on põhimõtteliselt kiiremate ja ökonoomsemate tulemuste saavutamine, kuna see ei nõua kõigi andmete täieliku koopia loomist.
Salvestustase on rakendatud hajutatud süsteemina, mis koosneb väga suurest hulgast füüsilistest serveritest. Iga redo-log töödeldakse ja salvestatakse samaaegselt kuue sõlmega.See tagab andmete kaitse ja koormuse jaotamise.
Lugemise skaleerimist saab tagada vastavate koopiate abil. Hajutatud salvestus elimineerib vajaduse sünkroonimise järele peamise andmebaasi instantsi vahel, mille kaudu andmeid kirjutame, ja teiste koopiate vahel. Aktuaalsed andmed on igal juhul kõigile koopiatele kergesti kättesaadavad.
Ainus probleem on vanade andmete vahemälus hoidmine lugemis koopiates. Kuid selle ülesande lahendamine on võimalik kõikide redo-logide edastamisega koopiatesse sisevõrgu kaudu. Kui logi on vahemikus, märgitakse see vigaseks ja kirjutatakse üle. Kui seda vahemällus ei ole, siis visatakse see lihtsalt kõrvale.
Salvestusega oleme valmis.
Kuidas skaleerida SÜT tasemeid
Siin on horisontaalne skaleerimine palju keerulisem. Seetõttu liigume tuttavat rada pidi. klassikalise vertikaalse skaleerimise.
Kujutame ette, et meil on rakendus, mis suhtleb andmebaasiga läbi peakõrva.
Vertikaalse skaleerimise korral määrame uue sõlme, millel on rohkem protsessoreid ja mälu.
Seejärel lülitame rakenduse vanalt peakõrvest uuele. Tuleb probleeme.
- See nõuab märkida rakenduse seadistamisest allakäiku.
- Uuel peakõrval on külm vahemälu. Andmebaasi jõudlus on maksimaalne alles pärast vahemälu soojendamist.
Kuidas olukorda parandada? Asetame rakenduse ja peakõrva vahele vaheproksi.
Mida see meile annab? Nüüd ei pea kõiki rakendusi käsitsi uuele sõlm kohta suunama. Üleminek on võimalik vaheproksi all ja märksa kiirem.
Tundub, et probleem on lahendatud. Kuid ei, me kannatame ikka veel vahemälu soojendamise vajaduse all. Lisaks on tekkinud uus probleem — nüüd on vaheproksi potentsiaalne rike.
Lõplik lahendus Amazon Aurora serverlessiga
Kuidas me need probleemid lahendasime?
Jätkame vaheproksi kasutamist. See ei ole mingi eraldi instants, vaid terve jaotatud prokside laevastik, mille kaudu rakendused saavad andmebaasi ühenduda. Ükskõik milline sõlm on praktiliselt kohe asendatav, kui see ebaõnnestub.
Lisatud erineva suurusega sooje sõlmi.. Seetõttu on vajadusel suurema või väiksema suurusega uue sõlme eraldamine kohe saadaval. Ei pea ootama, et see käivitataks.
Kogu skaleerimisprotsessi kontrollib spetsiaalne jälgimisseade. Jälgimine jälgib pidevalt praeguse peamisõlme seisundit. Kui see tuvastab näiteks, et protsessori koormus on kriitilisele tasemele jõudnud, teavitab see sooja instantside gruppi vajadusest uue sõlme eraldamiseks.
Jaotatud proksid, soe instants ja jälgimine.
Nõutud jõudlusega sõlm on saadaval. Sellele kopeeritakse vahemälu grupid ja süsteem hakkab ootama ohutut hetke üleminekuks.
Ülemineku hetk saabub tavaliselt piisavalt kiirelt. Siis peatatakse suhtlus proksi ja vana peamisõlme vahel, kõik sessioonid lülitatakse uuele sõlmele.
Töö andmebaasiga jätkub.
Kraanil on näha, et peatamine on tõesti väga lühike. Sinisel graafikul on koormus, punastel astmetel on skaleerimise momendid. Lühiajalised kukkumised sinisel graafikul ongi see lühike viivitus.
Ühe lisana, Amazon Aurora võimaldab suurelt kokku hoida ja kustutada andmebaasi, kui seda ei kasutata, näiteks nädalavahetustel. Pärast seiskamist vähendab andmebaas järk-järgult oma võimsust ja lülitub mõneks ajaks välja. Kui koormus naaseb, tõuseb see jälle sujuvalt.
Järgmises osas rääkides Amazonist räägime võrgustiku skaleerimisest. Liituge meie uudiskirjaga ja jälgige uuendusi, et mitte jääda ilma artiklist.
VDS-l on võimalik installida: Vasili Pantiuhin esitab ettekande „.” Milliseid jaotatud süsteemide disainimustreid kasutavad Amazon kõik, millised on teenuste tõrke põhjused, mis on rakenduslik arhitektuur, Constant Work, Shuffle Sharding — see on huvitav. Konverentsini on vähem kui kuu — . 24. oktoobril kehtib viimase hinna tõus.
Allikas: habr.com
