Retë janë si një kuti magjike - ju pyesni se çfarë ju nevojitet, dhe burimet thjesht shfaqen nga askund. Makinat virtuale, bazat e të dhënave, rrjeti - e gjithë kjo ju përket vetëm juve. Ka qiramarrës të tjerë të reve, por në Universin tuaj ju jeni sunduesi i vetëm. Jeni të sigurt që gjithmonë do të merrni burimet e kërkuara, nuk merrni parasysh askënd dhe përcaktoni në mënyrë të pavarur se si do të jetë rrjeti. Si funksionon kjo magji që e bën renë të ndajë në mënyrë elastike burimet dhe të izolojë plotësisht qiramarrësit nga njëri-tjetri?
Reja AWS është një sistem mega-super kompleks që ka evoluar në mënyrë evolucionare që nga viti 2006. Një pjesë e këtij zhvillimi ndodhi Vasily Pantyukhin - Arkitekt i Shërbimeve të Uebit të Amazon. Si arkitekt, ai merr një vështrim të brendshëm jo vetëm në rezultatin përfundimtar, por edhe në sfidat që kapërcen AWS. Sa më i madh të kuptohet se si funksionon sistemi, aq më i madh është besimi. Prandaj, Vasily do të ndajë sekretet e shërbimeve cloud AWS. Më poshtë është dizajni i serverëve fizikë AWS, shkallëzueshmëria elastike e bazës së të dhënave, një bazë të dhënash me porosi Amazon dhe metoda për rritjen e performancës së makinave virtuale duke ulur njëkohësisht çmimin e tyre. Njohja e qasjeve arkitekturore të Amazon do t'ju ndihmojë të përdorni shërbimet AWS në mënyrë më efektive dhe mund t'ju japë ide të reja për ndërtimin e zgjidhjeve tuaja.
Rreth folësit: Vasily Pantyukhin () filloi si administrator i Unix-it në kompanitë .ru, punoi në pajisje të mëdha Sun Microsystem për 6 vjet dhe predikoi një botë të përqendruar te të dhënat në EMC për 11 vjet. Ajo evoluoi natyrshëm në retë private, dhe në vitin 2017 u zhvendos në ato publike. Tani ai ofron këshilla teknike për të ndihmuar në jetën dhe zhvillimin në renë AWS.
Mohim përgjegjësie: gjithçka më poshtë është mendimi personal i Vasily dhe mund të mos përkojë me pozicionin e Shërbimeve Ueb Amazon. Raporti mbi të cilin bazohet artikulli është i disponueshëm në kanalin tonë në YouTube.
Pse po flas për pajisjen Amazon?
Makina ime e parë kishte një transmision manual. Ishte e mrekullueshme për shkak të ndjenjës se mund ta drejtoja makinën dhe të kisha kontroll të plotë mbi të. Më pëlqeu gjithashtu që të paktën e kuptova përafërsisht parimin e funksionimit të tij. Natyrisht, e imagjinova strukturën e kutisë të ishte mjaft primitive - diçka si një kuti ingranazhi në një biçikletë.
Gjithçka ishte e mrekullueshme, përveç një gjëje - të mbërthyer në bllokime trafiku. Duket sikur jeni ulur dhe nuk bëni asgjë, por po ndryshoni vazhdimisht marshin, duke shtypur tufën, gazin, frenën - kjo ju bën vërtet të lodhur. Problemi i bllokimit të trafikut u zgjidh pjesërisht kur familja mori një makinë automatike. Gjatë vozitjes, kisha kohë të mendoja për diçka dhe të dëgjoja një libër audio.
Një tjetër mister u shfaq në jetën time, sepse nuk e kuptoja plotësisht se si funksionon makina ime. Një makinë moderne është një pajisje komplekse. Makina përshtatet njëkohësisht me dhjetëra parametra të ndryshëm: shtypja e gazit, frena, stili i drejtimit, cilësia e rrugës. Nuk e kuptoj më si funksionon.
Kur fillova të punoja në renë e Amazonës, ishte gjithashtu një mister për mua. Vetëm ky mister është një rend i madhësisë më i madh, sepse ka një shofer në makinë, dhe në AWS ka miliona prej tyre. Të gjithë përdoruesit drejtojnë, shtypin gazin dhe frenojnë njëkohësisht. Është e mahnitshme që ata shkojnë ku të duan - kjo është një mrekulli për mua! Sistemi automatikisht përshtatet, shkallëzohet dhe përshtatet në mënyrë elastike për çdo përdorues, në mënyrë që t'i duket se është i vetëm në këtë Univers.
Magjia u shua pak kur më vonë erdha të punoja si arkitekt në Amazon. Pashë me çfarë problemesh përballemi, si i zgjidhim dhe si i zhvillojmë shërbimet. Me rritjen e të kuptuarit se si funksionon sistemi, shfaqet më shumë besim në shërbim. Kështu që unë dua të ndaj një foto të asaj që është nën kapuçin e resë AWS.
Për çfarë të flasim
Zgjodha një qasje të larmishme - zgjodha 4 shërbime interesante për të cilat ia vlen të flitet.
Optimizimi i serverit. Retë kalimtare me një mishërim fizik: qendra fizike të të dhënave ku ka serverë fizikë që gumëzhin, nxehen dhe vezullojnë me drita.
Funksionet pa server (Lambda) është ndoshta shërbimi më i shkallëzuar në re.
Shkallëzimi i bazës së të dhënave. Unë do t'ju tregoj se si ne ndërtojmë bazat tona të të dhënave të shkallëzueshme.
Shkallëzimi i rrjetit. Pjesa e fundit në të cilën do të hap pajisjen e rrjetit tonë. Kjo është një gjë e mrekullueshme - çdo përdorues i cloud beson se ai është vetëm në re dhe nuk sheh fare qiramarrës të tjerë.
Shënim. Ky artikull do të diskutojë optimizimin e serverit dhe shkallëzimin e bazës së të dhënave. Ne do të shqyrtojmë shkallëzimin e rrjetit në artikullin vijues. Ku janë funksionet pa server? Një transkript i veçantë u botua rreth tyre "" Ai flet për disa metoda të ndryshme shkallëzimi dhe diskuton në detaje zgjidhjen Firecracker - një simbiozë e cilësive më të mira të një makine virtuale dhe kontejnerëve.
Serverat
Reja është kalimtare. Por kjo kalueshmëri ka ende një mishërim fizik - serverë. Fillimisht, arkitektura e tyre ishte klasike. Chipset standard x86, kartat e rrjetit, Linux, hipervisor Xen në të cilin funksiononin makinat virtuale.
Në vitin 2012, kjo arkitekturë i përballoi mjaft mirë detyrat e saj. Xen është një hipervizor i shkëlqyeshëm, por ka një pengesë të madhe. Ai ka mjaft shpenzime të larta për emulimin e pajisjes. Ndërsa kartat e reja, më të shpejta të rrjetit ose disqet SSD bëhen të disponueshme, kjo shpenzim i përgjithshëm bëhet shumë i lartë. Si të merreni me këtë problem? Ne vendosëm të punonim në dy fronte njëherësh - optimizoni si harduerin ashtu edhe hipervizorin. Detyra është shumë serioze.
Optimizimi i harduerit dhe hipervizorit
Të bësh gjithçka menjëherë dhe ta bësh mirë nuk do të funksionojë. Ajo që ishte "e mirë" ishte gjithashtu e paqartë fillimisht.
Ne vendosëm të marrim një qasje evolucionare - ne ndryshojmë një element të rëndësishëm të arkitekturës dhe e hedhim atë në prodhim.
Ne shkelim çdo grabujë, dëgjojmë ankesat dhe sugjerimet. Pastaj ndryshojmë një komponent tjetër. Pra, në rritje të vogla, ne ndryshojmë rrënjësisht të gjithë arkitekturën bazuar në reagimet nga përdoruesit dhe mbështetjen.
Transformimi filloi në 2013 me gjënë më komplekse - rrjetin. NË S3 Në raste të tilla, një kartë speciale Network Accelerator iu shtua kartës standarde të rrjetit. Ajo ishte e lidhur fjalë për fjalë me një kabllo të shkurtër mbrapa në panelin e përparmë. Nuk është e bukur, por nuk është e dukshme në re. Por ndërveprimi i drejtpërdrejtë me harduerin përmirësoi rrënjësisht nervozizmin dhe xhiron e rrjetit.
Më pas vendosëm të përmirësojmë aksesin në bllokimin e ruajtjes së të dhënave EBS - Elastic Block Storage. Është një kombinim i rrjetit dhe ruajtjes. Vështirësia është se ndërsa kartat e Përshpejtuesit të Rrjetit ekzistonin në treg, nuk kishte asnjë mundësi për të blerë thjesht pajisje të Përshpejtuesit të Storage. Kështu që ne iu drejtuam një startup Laboratorët e Annapurnës, i cili zhvilloi çipa të veçantë ASIC për ne. Ata lejuan që vëllimet e largëta EBS të montoheshin si pajisje NVMe.
Në raste C4 zgjidhëm dy probleme. E para është se ne kemi zbatuar një themel për të ardhmen e teknologjisë premtuese, por të re në atë kohë, NVMe. Së dyti, ne kemi shkarkuar ndjeshëm procesorin qendror duke transferuar përpunimin e kërkesave në EBS në një kartë të re. Doli mirë, kështu që tani Annapurna Labs është pjesë e Amazon.
Deri në nëntor 2017, kuptuam se ishte koha për të ndryshuar vetë hipervizorin.
Hipervizori i ri u zhvillua bazuar në modulet e modifikuara të kernelit KVM.
Ai bëri të mundur reduktimin rrënjësor të shpenzimeve të përgjithshme të emulimit të pajisjes dhe punës direkt me ASIC të reja. Instancat S5 ishin makinat e para virtuale me një hipervizor të ri që funksiononte nën kapuç. Ne e emërtuam atë Nitro.
Evoluimi i rasteve në afatin kohor.
Të gjitha llojet e reja të makinave virtuale që janë shfaqur që nga nëntori 2017 funksionojnë në këtë hipervisor. Instancat e Bare Metal nuk kanë një hipervizor, por quhen edhe Nitro, pasi përdorin karta të specializuara Nitro.
Gjatë dy viteve të ardhshme, numri i llojeve të instancave Nitro tejkaloi disa duzina: A1, C5, M5, T3 dhe të tjerët.
Llojet e shembullit.
Si funksionojnë makinat moderne Nitro
Ato kanë tre komponentë kryesorë: hipervizorin Nitro (të diskutuar më lart), çipin e sigurisë dhe kartat Nitro.
Çip sigurie integruar direkt në motherboard. Ai kontrollon shumë funksione të rëndësishme, të tilla si kontrolli i ngarkimit të sistemit operativ pritës.
Kartat nitro - Janë katër lloje të tyre. Të gjitha ato janë zhvilluar nga Annapurna Labs dhe bazohen në ASIC të zakonshme. Disa nga firmware-et e tyre janë gjithashtu të zakonshme.
Katër lloje të kartave Nitro.
Një nga kartat është krijuar për të punuar me të rrjetVPC. Kjo është ajo që është e dukshme në makinat virtuale si një kartë rrjeti ENA - Përshtatës elastik i rrjetit. Ai gjithashtu përfshin trafikun kur e transmeton atë përmes një rrjeti fizik (ne do të flasim për këtë në pjesën e dytë të artikullit), kontrollon murin e zjarrit të Grupeve të Sigurisë dhe është përgjegjës për rrugëtimin dhe gjërat e tjera të rrjetit.
Kartat e zgjedhura funksionojnë me ruajtjen e bllokut EBS dhe disqet që janë ndërtuar në server. Ata i shfaqen makinës virtuale të ftuar si Përshtatësit NVMe. Ata janë gjithashtu përgjegjës për enkriptimin e të dhënave dhe monitorimin e diskut.
Sistemi i kartave Nitro, hipervizorit dhe çipit të sigurisë është i integruar në një rrjet SDN ose Rrjeti i përcaktuar me softuer. Përgjegjës për menaxhimin e këtij rrjeti (Plani i kontrollit) kartën e kontrolluesit.
Sigurisht, ne vazhdojmë të zhvillojmë ASIC të reja. Për shembull, në fund të 2018 ata lëshuan çipin Inferentia, i cili ju lejon të punoni në mënyrë më efikase me detyrat e mësimit të makinerive.
Çipi i procesorit të mësimit të makinerisë Inferentia.
Baza e të dhënave e shkallëzuar
Një bazë të dhënash tradicionale ka një strukturë të shtresuar. Për ta thjeshtuar shumë, dallohen nivelet e mëposhtme.
- SQL — klienti dhe dispeçerët e kërkesave punojnë në të.
- Dispozitat transaksionet - gjithçka është e qartë këtu, ACID dhe gjithçka.
- caching, e cila sigurohet nga pishina buferike.
- Prerjet — ofron punë me regjistrat e ribërjes. Në MySQL quhen Bin Logs, në PosgreSQL - Write Ahead Logs (WAL).
- ruajtje – regjistrim i drejtpërdrejtë në disk.
Struktura e bazës së të dhënave me shtresa.
Ka mënyra të ndryshme për të shkallëzuar bazat e të dhënave: sharding, arkitekturë Shared Nothing, disqe të përbashkëta.
Megjithatë, të gjitha këto metoda ruajnë të njëjtën strukturë monolitike të bazës së të dhënave. Kjo kufizon ndjeshëm shkallëzimin. Për të zgjidhur këtë problem, ne zhvilluam bazën tonë të të dhënave − Amazon Aurora. Është në përputhje me MySQL dhe PostgreSQL.
Amazon Aurora
Ideja kryesore arkitekturore është ndarja e niveleve të ruajtjes dhe regjistrimit nga baza e të dhënave kryesore.
Duke parë përpara, do të them se ne gjithashtu e bëmë të pavarur nivelin e memorizimit. Arkitektura pushon së qeni një monolit dhe ne fitojmë shkallë shtesë lirie në shkallëzimin e blloqeve individuale.
Nivelet e regjistrimit dhe ruajtjes janë të ndara nga baza e të dhënave.
Një DBMS tradicionale shkruan të dhëna në një sistem ruajtjeje në formën e blloqeve. Në Amazon Aurora, ne krijuam hapësirë të zgjuar që mund të flasë gjuhën redo-logs. Brenda, hapësira ruajtëse i kthen regjistrat në blloqe të dhënash, monitoron integritetin e tyre dhe rezervon automatikisht.
Kjo qasje ju lejon të zbatoni gjëra të tilla interesante si klonimi. Funksionon thelbësisht më shpejt dhe më ekonomikisht për faktin se nuk kërkon krijimin e një kopjeje të plotë të të gjitha të dhënave.
Shtresa e ruajtjes zbatohet si një sistem i shpërndarë. Ai përbëhet nga një numër shumë i madh i serverëve fizikë. Çdo regjistër i ribërjes përpunohet dhe ruhet njëkohësisht gjashtë nyje. Kjo siguron mbrojtjen e të dhënave dhe balancimin e ngarkesës.
Shkallëzimi i leximit mund të arrihet duke përdorur kopje të përshtatshme. Ruajtja e shpërndarë eliminon nevojën për sinkronizim midis shembullit kryesor të bazës së të dhënave, përmes të cilit ne shkruajmë të dhënat, dhe kopjeve të mbetura. Të dhënat e përditësuara garantohen të jenë të disponueshme për të gjitha kopjet.
Problemi i vetëm është ruajtja e të dhënave të vjetra në kopjet e lexuara. Por ky problem po zgjidhet transferimi i të gjitha regjistrave të ribërjes te replikat përmes rrjetit të brendshëm. Nëse regjistri është në cache, ai shënohet si i pasaktë dhe i mbishkruar. Nëse nuk është në cache, thjesht hidhet poshtë.
Ne zgjidhëm ruajtjen.
Si të shkallëzoni nivelet e DBMS
Këtu, shkallëzimi horizontal është shumë më i vështirë. Pra, le të shkojmë në rrugën e rrahur shkallë klasike vertikale.
Le të supozojmë se kemi një aplikacion që komunikon me DBMS përmes një nyje master.
Kur shkallëzojmë vertikalisht, ne ndajmë një nyje të re që do të ketë më shumë procesorë dhe memorie.
Më pas, ne e kalojmë aplikacionin nga nyja kryesore e vjetër në atë të re. Problemet dalin.
- Kjo do të kërkojë ndërprerje të konsiderueshme të aplikacionit.
- Nyja kryesore e re do të ketë cache të ftohtë. Performanca e bazës së të dhënave do të jetë maksimale vetëm pasi cache të jetë ngrohur.
Si të përmirësohet situata? Vendosni një përfaqësues ndërmjet aplikacionit dhe nyjes kryesore.
Çfarë do të na japë kjo? Tani të gjitha aplikacionet nuk kanë nevojë të ridrejtohen manualisht në nyjen e re. Ndërrimi mund të bëhet nën një përfaqësues dhe është thelbësisht më i shpejtë.
Duket se problemi është zgjidhur. Por jo, ne ende vuajmë nga nevoja për të ngrohur cache. Për më tepër, është shfaqur një problem i ri - tani përfaqësuesi është një pikë e mundshme dështimi.
Zgjidhja përfundimtare me Amazon Aurora pa server
Si i zgjidhëm këto probleme?
Lënë një përfaqësues. Ky nuk është një shembull i veçantë, por një flotë e tërë e shpërndarë proxies përmes të cilave aplikacionet lidhen me bazën e të dhënave. Në rast dështimi, çdo nyje mund të zëvendësohet pothuajse menjëherë.
Shtoi një grup nyjesh të ngrohta të madhësive të ndryshme. Prandaj, nëse është e nevojshme të ndani një nyje të re me madhësi më të madhe ose më të vogël, ajo është menjëherë e disponueshme. Nuk ka nevojë të prisni që të ngarkohet.
I gjithë procesi i shkallëzimit kontrollohet nga një sistem i veçantë monitorimi. Monitorimi monitoron vazhdimisht gjendjen e nyjes kryesore aktuale. Nëse zbulon, për shembull, që ngarkesa e procesorit ka arritur një vlerë kritike, ai njofton grupin e rasteve të ngrohta për nevojën për të caktuar një nyje të re.
Proxies të shpërndara, instanca të ngrohta dhe monitorim.
Ekziston një nyje me fuqinë e kërkuar. Pishinat e tamponit kopjohen në të dhe sistemi fillon të presë për një moment të sigurt për të kaluar.
Zakonisht momenti për të kaluar vjen mjaft shpejt. Pastaj komunikimi midis përfaqësuesit dhe nyjes së vjetër kryesore pezullohet, të gjitha seancat kalohen në nyjen e re.
Puna me rifillimin e bazës së të dhënave.
Grafiku tregon se pezullimi është me të vërtetë shumë i shkurtër. Grafiku blu tregon ngarkesën dhe hapat e kuq tregojnë momentet e shkallëzimit. Uljet afatshkurtra në grafikun blu janë pikërisht ajo vonesë e shkurtër.
Nga rruga, Amazon Aurora ju lejon të kurseni plotësisht para dhe të fikni bazën e të dhënave kur nuk është në përdorim, për shembull, gjatë fundjavave. Pas ndalimit të ngarkesës, DB gradualisht zvogëlon fuqinë e saj dhe fiket për ca kohë. Kur ngarkesa të kthehet, ajo do të ngrihet përsëri pa probleme.
Në pjesën tjetër të tregimit për pajisjen Amazon, do të flasim për shkallëzimin e rrjetit. Abonohu dhe qëndroni të sintonizuar që të mos e humbisni artikullin.
Mbi Vasily Pantyukhin do të japë një raport "" Cilat modele të projektimit për sistemet e shpërndara përdoren nga zhvilluesit e Amazon, cilat janë arsyet e dështimeve të shërbimit, çfarë është arkitektura e bazuar në qelizë, Puna e vazhdueshme, Shuffle Sharding - do të jetë interesante. Më pak se një muaj deri në konferencë - . Rritja përfundimtare e çmimit më 24 tetor.
Burimi: www.habr.com