Oblaci su poput čarobne kutije - pitate što vam treba, a resursi se pojavljuju niotkuda. Virtualni strojevi, baze podataka, mreža - sve to pripada samo vama. Postoje i drugi stanari oblaka, ali u svom svemiru vi ste jedini vladar. Sigurni ste da ćete uvijek dobiti potrebna sredstva, ne uzimate u obzir nikoga i sami određujete kakva će mreža biti. Kako funkcionira ta magija koja tjera oblak da elastično alocira resurse i potpuno izolira stanare jedne od drugih?
AWS oblak je mega-super kompleksan sustav koji se evolucijski razvija od 2006. godine. Dio ovog razvoja se dogodio Vasilij Pantjuhin - Amazon Web Services Architect. Kao arhitekt, on dobiva iznutra pogled ne samo na krajnji rezultat, već i na izazove koje AWS svladava. Što je veće razumijevanje kako sustav funkcionira, to je veće povjerenje. Stoga će Vasily podijeliti tajne AWS cloud usluga. Ispod je dizajn fizičkih AWS poslužitelja, elastična skalabilnost baze podataka, prilagođena Amazon baza podataka i metode za povećanje performansi virtualnih strojeva uz istovremeno smanjenje njihove cijene. Poznavanje Amazonovih arhitektonskih pristupa pomoći će vam da učinkovitije koristite usluge AWS-a i može vam dati nove ideje za izgradnju vlastitih rješenja.
O govorniku: Vasily Pantyukhin () počeo je kao Unix administrator u .ru tvrtkama, radio je na velikom hardveru Sun Microsystema 6 godina i propovijedao svijet usmjeren na podatke u EMC-u 11 godina. Prirodno je evoluirao u privatne oblake, a 2017. prešao u javne. Sada pruža tehničke savjete kako bi pomogao živjeti i razvijati se u AWS oblaku.
Izjava o odricanju od odgovornosti: sve ispod je Vasilijevo osobno mišljenje i ne mora se poklapati sa stavom Amazon Web Services. Izvješće na kojem se temelji članak dostupno je na našem YouTube kanalu.
Zašto govorim o Amazon uređaju?
Moj prvi auto je imao ručni mjenjač. Bilo je super zbog osjećaja da mogu voziti auto i imati potpunu kontrolu nad njim. Također mi se svidjelo što sam barem približno shvatio princip njegovog rada. Naravno, strukturu kutije sam zamislio prilično primitivnom - nešto poput mjenjača na biciklu.
Sve je bilo super, osim jedne stvari - zaglavljivanja u prometnim gužvama. Čini se kao da sjedite i ne radite ništa, ali stalno mijenjate brzine, pritiskate kvačilo, gas, kočnicu - to vas stvarno umara. Problem prometne gužve djelomično je riješen kada je obitelj dobila automobil s automatikom. Tijekom vožnje imao sam vremena razmišljati o nečemu i poslušati audio knjigu.
Još jedna misterija se pojavila u mom životu, jer sam potpuno prestao razumjeti kako moj auto radi. Moderan automobil je složen uređaj. Automobil se istovremeno prilagođava desecima različitih parametara: pritiskanju gasa, kočnice, stilu vožnje, kvaliteti ceste. Više mi nije jasno kako to funkcionira.
Kad sam počeo raditi na Amazonovom oblaku, i on je za mene bio misterij. Samo što je taj misterij za red veličine veći, jer u autu je jedan vozač, a u AWS-u ih ima na milijune. Svi korisnici istovremeno upravljaju, pritišću gas i koče. Nevjerojatno je da idu gdje hoće – meni je to čudo! Sustav se automatski prilagođava, skalira i elastično prilagođava svakom korisniku tako da mu se čini da je sam u ovom Svemiru.
Čarolija je malo popustila kad sam kasnije došao raditi kao arhitekt u Amazonu. Vidio sam s kakvim se problemima susrećemo, kako ih rješavamo i kako razvijamo usluge. S povećanjem razumijevanja kako sustav funkcionira, pojavljuje se više povjerenja u uslugu. Stoga želim podijeliti sliku onoga što se nalazi ispod haube AWS oblaka.
O čemu ćemo razgovarati
Odabrao sam raznolik pristup - odabrao sam 4 zanimljive usluge o kojima vrijedi razgovarati.
Optimizacija poslužitelja. Efemerni oblaci s fizičkim utjelovljenjem: fizički podatkovni centri gdje postoje fizički poslužitelji koji bruje, zagrijavaju se i trepću svjetlima.
Funkcije bez poslužitelja (Lambda) je vjerojatno najskalabilnija usluga u oblaku.
Skaliranje baze podataka. Reći ću vam kako gradimo vlastite skalabilne baze podataka.
Mrežno skaliranje. Zadnji dio u kojem ću otvoriti uređaj naše mreže. Ovo je divna stvar - svaki korisnik oblaka vjeruje da je sam u oblaku i da uopće ne vidi druge stanare.
Bilješka. Ovaj članak govori o optimizaciji poslužitelja i skaliranju baze podataka. Razmotrit ćemo mrežno skaliranje u sljedećem članku. Gdje su funkcije bez poslužitelja? O njima je objavljen poseban transkript “" Govori o nekoliko različitih metoda skaliranja, te se detaljno raspravlja o Firecracker rješenju - simbiozi najboljih kvaliteta virtualnog stroja i spremnika.
poslužitelji
Oblak je prolazan. Ali ova kratkotrajnost još uvijek ima fizičko utjelovljenje - poslužitelje. U početku je njihova arhitektura bila klasična. Standardni x86 čipset, mrežne kartice, Linux, Xen hipervizor na kojem su pokrenuti virtualni strojevi.
U 2012. godini ova se arhitektura prilično dobro nosila sa svojim zadacima. Xen je izvrstan hipervizor, ali ima jedan veliki nedostatak. On ima dovoljno visoki troškovi za emulaciju uređaja. Kako nove, brže mrežne kartice ili SSD diskovi postaju dostupni, ovo opterećenje postaje preveliko. Kako se nositi s ovim problemom? Odlučili smo raditi na dva fronta odjednom - optimizirati i hardver i hipervizor. Zadatak je vrlo ozbiljan.
Optimiziranje hardvera i hipervizora
Raditi sve odjednom i to dobro neće uspjeti. Što je "dobro" također je bilo nejasno u početku.
Odlučili smo se za evolucijski pristup - mijenjamo jedan važan element arhitekture i puštamo ga u proizvodnju.
Stajemo na sve grablje, slušamo pritužbe i prijedloge. Zatim mijenjamo drugu komponentu. Dakle, u malim koracima, radikalno mijenjamo cjelokupnu arhitekturu na temelju povratnih informacija korisnika i podrške.
Transformacija je započela 2013. s najkompleksnijom stvari – mrežom. U S3 Na primjer, standardnoj mrežnoj kartici dodana je posebna kartica Network Accelerator. Bio je spojen doslovno s kratkim loopback kabelom na prednjoj ploči. Nije lijepo, ali se ne vidi u oblaku. Ali izravna interakcija s hardverom bitno je poboljšala podrhtavanje i mrežnu propusnost.
Zatim smo odlučili poboljšati pristup blok pohrani podataka EBS - Elastic Block Storage. To je kombinacija mreže i pohrane. Poteškoća je u tome što iako su kartice mrežnog akceleratora postojale na tržištu, nije postojala opcija da se jednostavno kupi hardver za akcelerator pohrane. Pa smo se okrenuli startupu Laboratoriji Annapurne, koji je za nas razvio posebne ASIC čipove. Omogućili su montiranje udaljenih EBS jedinica kao NVMe uređaja.
U primjerima C4 riješili smo dva problema. Prvi je da smo implementirali temelj za budućnost obećavajuće, ali nove u to vrijeme, NVMe tehnologije. Drugo, značajno smo rasteretili središnji procesor prebacivanjem obrade zahtjeva prema EBS-u na novu karticu. Pokazalo se dobro, pa je sada Annapurna Labs dio Amazona.
U studenom 2017. shvatili smo da je vrijeme za promjenu samog hipervizora.
Novi hipervizor razvijen je na temelju modificiranih modula KVM kernela.
Omogućio je temeljno smanjenje troškova emulacije uređaja i izravan rad s novim ASIC-ovima. Instance S5 bili su prvi virtualni strojevi s novim hipervizorom koji je radio ispod haube. Nazvali smo ga Nitro.
Evolucija instanci na vremenskoj traci.
Sve nove vrste virtualnih strojeva koje su se pojavile od studenog 2017. rade na ovom hipervizoru. Bare Metal instance nemaju hipervizor, ali se zovu i Nitro, jer koriste specijalizirane Nitro kartice.
U sljedeće dvije godine broj vrsta Nitro instanci premašio je nekoliko desetaka: A1, C5, M5, T3 i drugi.
Vrste instanci.
Kako rade moderni Nitro strojevi
Imaju tri glavne komponente: Nitro hipervizor (o kojem se govori gore), sigurnosni čip i Nitro kartice.
Sigurnosni čip integriran izravno u matičnu ploču. Upravlja mnogim važnim funkcijama, kao što je kontrola učitavanja glavnog OS-a.
Nitro kartice - Ima ih četiri vrste. Sve ih je razvila Annapurna Labs i temelje se na uobičajenim ASIC-ovima. Neki od njihovih firmware-a su također uobičajeni.
Četiri vrste Nitro kartica.
Jedna od kartica je dizajnirana za rad mrežaVPC. To je ono što je vidljivo u virtualnim strojevima kao mrežna kartica ENA - Elastični mrežni adapter. Također enkapsulira promet kada ga prenosi kroz fizičku mrežu (o tome ćemo govoriti u drugom dijelu članka), kontrolira vatrozid sigurnosnih grupa i odgovoran je za usmjeravanje i druge mrežne stvari.
Odabrane kartice rade s blok pohranom EBS i diskovi koji su ugrađeni u poslužitelj. Oni se gostujućem virtualnom stroju pojavljuju kao NVMe adapteri. Oni su također odgovorni za šifriranje podataka i nadzor diska.
Sustav Nitro kartica, hipervizora i sigurnosnog čipa integriran je u SDN mrežu odn Softverski definirana mreža. Odgovoran za upravljanje ovom mrežom (kontrolna razina) kartica kontrolera.
Naravno, nastavljamo razvijati nove ASIC-ove. Na primjer, krajem 2018. izdali su čip Inferentia koji vam omogućuje učinkovitiji rad sa zadacima strojnog učenja.
Čip procesora strojnog učenja Inferentia.
Skalabilna baza podataka
Tradicionalna baza podataka ima slojevitu strukturu. Da bismo uvelike pojednostavili, razlikuju se sljedeće razine.
- SQL — klijent i otpremnici zahtjeva rade na tome.
- Odredbe transakcije - tu je sve jasno, ACID i sve to.
- predmemoriranje, koji osiguravaju međuspremnici.
- Sječa drva — omogućuje rad s redo zapisima. U MySQL-u se zovu Bin Logs, u PosgreSQL-u - Write Ahead Logs (WAL).
- Skladištenje – izravno snimanje na disk.
Slojevita struktura baze podataka.
Postoje različiti načini skaliranja baza podataka: dijeljenje, Shared Nothing arhitektura, dijeljeni diskovi.
Međutim, sve ove metode održavaju istu monolitnu strukturu baze podataka. Ovo značajno ograničava skaliranje. Kako bismo riješili ovaj problem, razvili smo vlastitu bazu podataka − Amazonska Aurora. Kompatibilan je s MySQL i PostgreSQL.
Amazonska Aurora
Glavna arhitektonska ideja je odvojiti razine pohrane i zapisivanja od glavne baze podataka.
Gledajući unaprijed, reći ću da smo također osamostalili razinu predmemoriranja. Arhitektura prestaje biti monolit, a dobivamo dodatne stupnjeve slobode u skaliranju pojedinih blokova.
Razine zapisivanja i pohrane odvojene su od baze podataka.
Tradicionalni DBMS zapisuje podatke u sustav za pohranu podataka u obliku blokova. U Amazon Aurori stvorili smo pametnu pohranu koja može govoriti jezikom redo-logs. Unutra, pohrana pretvara zapise u podatkovne blokove, nadzire njihov integritet i automatski izrađuje sigurnosnu kopiju.
Ovaj pristup vam omogućuje implementaciju tako zanimljivih stvari kao kloniranje. Radi bitno brže i ekonomičnije zbog činjenice da ne zahtijeva stvaranje potpune kopije svih podataka.
Sloj pohrane implementiran je kao distribuirani sustav. Sastoji se od vrlo velikog broja fizičkih poslužitelja. Svaki zapis ponavljanja obrađuje se i sprema istovremeno šest čvorova. To osigurava zaštitu podataka i ravnotežu opterećenja.
Skaliranje čitanja može se postići korištenjem odgovarajućih replika. Distribuirana pohrana eliminira potrebu za sinkronizacijom između glavne instance baze podataka, kroz koju upisujemo podatke, i preostalih replika. Zajamčeno je da će ažurni podaci biti dostupni svim replikama.
Jedini problem je spremanje starih podataka u predmemoriju na pročitanim replikama. Ali ovaj problem se rješava prijenos svih redo dnevnika na replike preko interne mreže. Ako je zapisnik u predmemoriji, označen je kao netočan i prebrisan. Ako nije u cacheu, jednostavno se odbacuje.
Sredili smo skladište.
Kako skalirati razine DBMS-a
Ovdje je horizontalno skaliranje mnogo teže. Pa krenimo utabanom stazom klasično okomito skaliranje.
Pretpostavimo da imamo aplikaciju koja komunicira sa DBMS-om preko glavnog čvora.
Pri okomitom skaliranju dodjeljujemo novi čvor koji će imati više procesora i memorije.
Zatim prebacujemo aplikaciju sa starog glavnog čvora na novi. Nastaju problemi.
- To će zahtijevati značajan prekid rada aplikacije.
- Novi glavni čvor imat će hladnu predmemoriju. Performanse baze podataka bit će maksimalne tek nakon što se predmemorija zagrije.
Kako poboljšati stanje? Postavite proxy između aplikacije i glavnog čvora.
Što će nam to dati? Sada sve aplikacije ne moraju biti ručno preusmjerene na novi čvor. Prebacivanje se može izvršiti pod proxyjem i bitno je brže.
Čini se da je problem riješen. Ali ne, još uvijek patimo od potrebe za zagrijavanjem predmemorije. Osim toga, pojavio se novi problem - sada je proxy potencijalna točka kvara.
Konačno rješenje s Amazon Aurora bez poslužitelja
Kako smo riješili te probleme?
Ostavio proxy. Ovo nije zasebna instanca, već cijela distribuirana flota proxyja putem kojih se aplikacije povezuju s bazom podataka. U slučaju kvara, bilo koji od čvorova može se zamijeniti gotovo trenutno.
Dodan skup toplih čvorova različitih veličina. Stoga, ako je potrebno dodijeliti novi čvor veće ili manje veličine, on je odmah dostupan. Nema potrebe čekati da se učita.
Cijeli proces skaliranja kontrolira poseban sustav nadzora. Monitoring stalno prati stanje trenutnog glavnog čvora. Ako otkrije, na primjer, da je opterećenje procesora doseglo kritičnu vrijednost, obavještava skup toplih instanci o potrebi dodjele novog čvora.
Distribuirani proxyji, tople instance i nadzor.
Dostupan je čvor s potrebnom snagom. Međuspremnici se kopiraju u njega i sustav počinje čekati siguran trenutak za prebacivanje.
Obično trenutak za promjenu dođe vrlo brzo. Zatim se obustavlja komunikacija između proxyja i starog glavnog čvora, sve sesije prebacuju na novi čvor.
Rad s bazom nastavlja.
Grafikon pokazuje da je ovjes doista vrlo kratak. Plavi grafikon prikazuje opterećenje, a crveni koraci pokazuju momente skaliranja. Kratkoročni padovi na plavom grafikonu su upravo to kratko kašnjenje.
Usput, Amazon Aurora vam omogućuje da potpuno uštedite novac i isključite bazu podataka kada se ne koristi, na primjer, vikendom. Nakon zaustavljanja opterećenja, DB postupno smanjuje svoju snagu i isključuje se neko vrijeme. Kada se teret vrati, ponovno će se glatko podići.
U sljedećem dijelu priče o Amazon uređaju govorit ćemo o mrežnom skaliranju. Pretplatite se i ostanite s nama kako ne biste propustili članak.
Na Vasilij Pantjuhin će održati izvještaj “" Koje obrasce dizajna za distribuirane sustave koriste programeri Amazona, koji su razlozi kvarova usluga, što je Cell-based arhitektura, Constant Work, Shuffle Sharding - bit će zanimljivo. Manje od mjesec dana do konferencije - . 24. listopada konačno poskupljenje.
Izvor: www.habr.com