Kuidas AWS oma elastseid teenuseid „keedab”. Võrgustiku skaleerimine

Amazon Web Services'i võrgustiku ulatus on 69 tsooni 22 piirkonnas üle kogu maailma: Ameerikas, Euroopas, Aasias, Aafrikas ja Austraalias. Igas tsoonis asub kuni 8 andmekeskust. Igas andmekeskuses on tuhandeid või kümneid tuhandeid servereid. Võrk on üles ehitatud nii, et kõik ebatõenäolised katkestused on ette nähtud. Näiteks on kõik piirkonnad üksteisest isoleeritud ning ligipääsus tsoonid on paigutatud kilomeetrite kaugusele. Ieven kui kaabel katkeb, läheb süsteem varukanalitele ning info kaotus on vaid mõne andmepaketi jagu. Lisainfot sellest, millistel põhimõtetel võrk põhineb ja kuidas see on üles ehitatud, räägib Vasili Pantjuhin.

Vasili Pantjuhin algas Unix-administraatorina .ru ettevõtetes, 6 aastat töötas suurte rauatootjate Sun Microsystems juures, 11 aastat levitas andmekeskuse keskset mõtteviisi EMC-s. Loomulikult on ta evolutsioneerunud privaatsetesse pilvedesse ja seejärel suundunud avalikesse. Täna, olles Amazon Web Services'i arhitekt, aitab ta tehniliste nõuannetega ellu jääda ja areneda AWS pilves.

Triloogia e AWS, Vasilii süvenes füüsiliste serverite ja andmebaasi skaleerimise toimimisse. Nitro-kaardid, KVM-põhine kohandatud hüperviisor, Amazon Aurora andmebaas — kõigest sellest artiklis "Kuidas AWS oma elastseid teenuseid "keedab". Serverite ja andmebaaside skaleerimine". Loe, et konteksti süveneda, või vaata videoklipp ettekandeid.

Selles osas räägitakse võrgu skaleerimisest — ühest kõige keerulisemast süsteemist AWS-is. Areng lapikust võrgust Virtuaalsesse Erakliendivõrku, selle struktuur, siseteenused Blackfoot ja HyperPlane, müra probleemi, ning lõpuks — võrgu ulatus, selgroog ja füüsilised kaablid. Kõigest sellest allpool.

Distsipliin: kõik, mis allpool on — Vasilii isiklik arvamus ja see ei pruugi kajastada Amazon Web Services'i seisukohti.

Võrgu skaleerimine

AWS pilv käivitati 2006. aastal. Selle võrk oli piisavalt primitiivne — lapiku struktuuriga. Privaatsete aadresside vahemik oli kõigi pilveüürnike jaoks ühine. Uue virtuaalse masina käivitamisel said sa juhuslikult saadaval oleva IP-aadressi sellest vahemikust.

See lähenemine oli lihtne teostada, kuid põhimõtteliselt piiras pilve kasutamist. Eelkõige oli äärmiselt keeruline arendada hübriidlahendusi, kus liideti maapealsed ja AWS-i eravõrgud. Levinum probleem oli IP-aadresside vahemike kattumine.

Virtuaalne Privaatsusväli

Pilv osutus nõutud. On aeg mõelda skaleeritavusele ja võimalusele seda kasutada kümnete miljonite üürnike poolt. Lame võrk oli peamine takistus. Seetõttu mõtlesime, kuidas isoleerida kasutajaid üksteisest võrgu tasandil, et nad saaksid iseseisvalt valida IP-vahemikke.

Mis esimene mõte tuleb pähe, kui mõtlete võrgu isoleerimisele? Loomulikult VLAN ja VRF — Virtuaalne Suunamine ja Edastamine.

Kahjuks see ei õnnestunud. VLAN ID on vaid 12 bittine, mis annab meile ainult 4096 isoleeritud segmenti. Isegi suurimates lülitites saab kasutada maksimaalselt 1-2 tuhat VRF-i. VRF-i ja VLAN-i jagamine annab meile vaid mõned miljonid alamvõrgud. Seda on kindlasti liiga vähe kümnete miljonite tenantide jaoks, kellel kõigil peab olema võimalus kasutada mitmeid alamvõrke.

Me ei saa endale lubada osta vajaliku arvu suuri seadmeid, näiteks Cisco või Juniperilt. Sellel on kaks põhjust: see on ülimalt kallis ja me ei taha sattuda sõltuvusse nende arendus- ja patchimisprotsessidest.

Kokkuvõte on – küpsetada omaenda lahendus.

2009. aastal kuulutasime välja VPC. — Virtuaalne Privaatsusväli. Nimi on juurdunud ja nüüd kasutavad seda ka paljud pilveteenuse pakkujad.

VPC – see on virtuaalne võrk SDN (Software Defined Network). Otsustasime, et ei hakka leiutama spetsiaalseid protokolle L2 ja L3 tasanditel. Võrk töötab standardse Etherneti ja IP põhjal. Andmete edastamiseks virtuaalmasinate vahel kapseldatakse liiklus meie enda protokolli mähisesse. Selles määratakse ID, mis kuulub VPC tenantile.

Tundub lihtne. Siiski tuleb lahendada mitmeid tõsiseid tehnilisi ülesandeid. Näiteks, kus ja kuidas salvestada andmed virtuaalsete MAC/IP-aadresse, VPC ID-d ja vastavaid füüsilisi MAC/IP. AWS-i mastaabis on see hiiglaslik tabel, mis peab töötama minimaalse viivitusega päringute korral. Selle eest vastutab mappimise teenus, mis on laiali hajutatud üle kogu võrgu.

Uute põlvkondade masinates toimub kapseldamine Nitro kaartide kaudu riistvaratasemel. Vanemates instantsides on kapseldamine ja de-kapseldamine tarkvaraline. 

Vaatame üldiselt, kuidas see töötab. Alustame L2 tasemelt. Oletame, et meil on virtuaalmasin IP-iga 10.0.0.2 füüsilisel serveril 192.168.0.3. See saadab andmeid virtuaalmasinale 10.0.0.3, mis asub aadressil 192.168.1.4. Koostatakse ARP-päring, mis jõuab võrgu Nitro kaardini. Lihtsuse huvides eeldame, et mõlemad virtuaalmasinad elavad samas "sinises" VPC-s.

Kaart asendab lähteaadressi oma enda aadressiga ja edastab ARP-raami mappimise teenusele.

Mappimise teenus tagastab teabe, mis on vajalik füüsilises L2-võrgus edastamiseks.

Nitro-kaart ARP-vastuses asendab füüsilises võrgus MAC-aadressi VPC-aadressiga.

Andmete edastamisel pakime loogilised MAC ja IP VPC-kattes. Kõik see edastatakse füüsilises võrgus vastava IP Nitro-kaardi abil, kus allikas ja sihtkoht.

Füüsiline masin, kellele pakett on mõeldud, teeb kontrolli. See on vajalik, et vältida aadresside vale esitamist. Masin saadab spetsiaalse päringu kaardistamisteenusele ja küsib: "Füüsiliselt masinalt 192.168.0.3 sain paketi, mis on mõeldud 10.0.0.3 'sinisesse' VPC-sse. Kas see on legaalne?" 

Kaardistamisteenus kontrollib oma ressursipaigutuse tabelit ja lubab või keelab paketi edastamise. Kõikides uutest instantsidest on täiendav valideerimine Nitro-kaartidesse sisse ehitatud. Seda ei ole isegi teoreetiliselt võimalik mööda hiilida. Seetõttu ei toimi teiste VPC-de ressursside vale esitamine.

Seejärel saadetakse andmed virtuaalsesse masinasse, kellele need on mõeldud. 

Kaardistamisteenus toimib ka loogilise ruuterina andmete edastamiseks erinevates alamisvõrkudes asuvate virtuaalmasinate vahel. Seal on kõik kontseptuaalselt lihtne, ei hakka seda üksikasjalikult selgitama.

Seega, iga paketi edastamisel pöörduvad serverid kaardistamisteenuse poole. Kuidas leevendada vältimatuid viivitusi? Küsimusele aitab vastata vahemällu salvestamine, loomulikult.

Kogu ilu seisneb selles, et ei ole vaja salvestada kogu tohutut tabelit. Füüsilisel serveril elavad virtuaalsed masinad suhteliselt väikse arvu VPC-de seest. Vahemällu tuleb salvestada vaid nende VPC-de info. Andmete edastamine teistesse VPC-desse „vaikimisi” konfiguratsioonis ei ole siiski legit. Kui kasutada sellist funktsionaalsust nagu VPC-peering, lisatakse vahemällu lisainfos vastavad VPC-d. 

Andmete edastamisega VPC-sse saime hakkama.

Blackfoot

Kuidas olla olukordades, kus tuleb edastada liiklust väljaspoole, näiteks Internetti või VPN-i kaudu allapoole? Siin päästab meid Blackfoot — sisemine AWS-teenus. See on loodud meie Lõuna-Aafrika meeskonna poolt. Seetõttu on teenuse nimi pühendatud pingviinile, kes elab Lõuna-Aafrikas.

Blackfoot dekapsuleerib liiklust ja teeb sellega, mis on vajalik. Andmed saadetakse Internetti sellisena nagu nad on.

Andmed dekapsuleeritakse ja keeratakse taas IPsec-i ümbrisesse, kui kasutatakse VPN-i.

Direct Connecti kasutamisel märgistatakse ja edastatakse liiklus vastavasse VLAN-i.

HyperPlane

See on sisevoogude jälgimise teenus. Paljud võrguteenused nõuavad voogude kontrollimist andmete voogude olek. Näiteks NAT-i kasutamisel peab voogude juhtimine tagama, et igale "IP: sihtport" paarile vastab ainulaadne väljuv port. Koos tasakaalustajaga NLB — Võrgutasakaalu tasandaja, peab andmevoog alati suunama samasse sihtvirtuaalmasinasse. Turvagrupp on olekusäilitav tulemüür. See jälgib sissetulevat liiklust ja avab vaikimisi sadamad väljuvatele pakettidele.

AWS-s on edastusviivituse nõudmised äärmiselt kõrged. Seetõttu HyperPlane on see kogu võrgu toimimise jaoks kriitiline.

Hyperplane on üles ehitatud EC2 virtuaalmasinatele. Siin pole mingit imet, vaid vaid petmine. Petmine seisneb selles, et need on virtuaalmasinad suure mälu mahuga. Tehingud viiakse läbi eranditult mälus. See võimaldab saavutada viivitusi vaid kümnete mikrosekunditega. Töö ketas oleks tapnud kogu jõudluse. 

Hyperplane on hajutatud süsteem, mis koosneb suurest hulgast EC2-masinatest. Igal virtuaalmasinal on läbilaskevõime 5 GB/s. Kogu piirkondliku võrgu ulatuses annab see metsiku terabittide läbilaskevõime ja võimaldab töötleda miljoneid ühendusi sekundis.

HyperPlane töötab ainult voogude põhjal. VPC pakettide inkapsuleerimine on selle jaoks täiesti läbipaistev. Potentsiaalne haavatavus selles siseteenuses ei võimalda ikkagi VPC isolatsiooni murda. Turvalisuse tagavad madalamad tasemed.

Noisy neighbor

On veel üks probleem mürarikka naabri — noisy neighbor. Ütleme, et meil on 8 sõlme. Need sõlmed töötlevad kõigi pilv kasutajate vooge. Tundub, et kõik on korras ja koormus peaks olema ühtlaselt jaotatud kõikidele sõlmedele. Sõlmed on väga võimsad ja neid on keeruline üle koormata.

Aga me ehitame oma arhitektuuri isegi vähem tõenäoliste stsenaariumide põhjal. 

Madala tõenäosuse ei tähenda, et see oleks võimatu.

Me võime ette kujutada olukorda, kus üks või mitu kasutajat genereerivad liiga suurt koormust. Selle koormuse töötlemises on kaasatud kõik HyperPlane'i sõlmed ja teised kasutajad võivad potentsiaalselt tunda mingit jõudluse langust. See rikub pilve kontseptsiooni, kus tenantidel ei ole võimalik üksteisele mõju avaldada.

Kuidas lahendada müra tegeva naabri probleem? Esimene asi, mis pähe tuleb – shardimine. Meie 8 sõlme jagunevad loogiliselt 4 shardiks, igas 2 sõlmega. Nüüd häirib müra tegeva naabri tegevus vaid neljandikku kõigist kasutajatest, kuid siiski oluliselt.

Teeme teisiti. Igaühele jagame vaid 3 sõlme. 

Nipp on määrata erinevate kasutajate sõlmed juhuslikult. Alloleval pildil ristuvad sinise kasutaja sõlmed ühe kahel teisel kasutajal – rohelisel ja oranžil.

8 sõlme ja 3 kasutajaga on mürarikka naaberi sissetungi tõenäosus ühe kasutaja osas 54%. Just sellise tõenäosusega avaldab sinine kasutaja mõju teistele üürnikele. Samas on see mõju märgatav vaid kolmandikule kõikidest kasutajatest. See on juba korralik tulemus.

Kasutajate arv, kes ristuvad

Tõenäosus protsentides

0

18%

1

54%

2

26%

3

2%

Lähendame olukorda reaalsusele — võtame 100 sõlme ja 5 kasutajat 5 sõlmes. Sellisel juhul ei ristu ükski sõlm tõenäosusega 77%. 

Kasutajate arv, kes ristuvad

Tõenäosus protsentides

0

77%

1

21%

2

1,8%

3

0,06%

4

0,0006%

5

0,00000013%

Reaalses olukorras, kui HyperPlane sõlmi ja kasutajaid on suur hulk, on mürarikka naabri mõju teistele kasutajatele minimaalne. Seda meetodit nimetatakse segavaks shardinguks — shuffle sharding. See minimeerib sõlmede rikke negatiivset mõju.

HyperPlane'i põhjal on loodud palju teenuseid: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.

Võrgu ulatused

Nüüd räägime võrgu ulatusest. Oktoobris 2019 pakub AWS oma teenuseid 22 piirkonnas, lisaks on plaanis veel 9.

• Igas regioonis on mitu kättesaadavuse ala – Availability Zone. Kokku on neid maailmas 69.
• Iga AZ koosneb Andmetöötluskeskustest. Kokku ei ole neid rohkem kui 8.
• Andmetöötluskeskustes asub tohutult servereid, mõnes kuni 300 000.

Nüüd keskmistame, korrutame ja saame muljetavaldava numbri, mis kajastab Amazonase pilve ulatust.

Kättesaadavuse alade ja Andmetöötluskeskuste vahel on palju optilisi kanaleid. Ühes meie suurimas regioonis on ainult AZ-de vaheline ja teiste piirkondade ühenduspunktidega (Transit Centers) ühendamiseks rajatud 388 kanalit. Kokku annab see meeletu 5000 Tbitt.

AWS selgroog on ehitatud spetsiaalselt pilve jaoks ja optimeeritud selle tegevuseks. Me rajame seda kanalites 100 Gbit/s. Me kontrollime neid täielikult, välja arvatud Hiina piirkondades. Liiklust ei jagata teiste ettevõtete koormustega.

Muidugi, me ei ole ainus pilveteenuse pakkuja, kellel on privaatne selgroog. Üha rohkem suuri ettevõtteid järgib sama teed. Seda kinnitavad sõltumatud teadlased, näiteks Telegeography.

Graafikult on näha, et sisuteenuse ja pilveteenuse pakkujate osakaal kasvab. Selle tõttu vähenevad backbone-pakkujate Interneti-trafiku osakaal pidevalt.

Selgitan, miks see nii on. Varem olid enamus veebiteenuseid otseselt juurdepääsetavad ja tarbitavad Internetist. Nüüd asub üha enam servereid pilves ja on kättesaadavad läbi CDN — Content Distribution Network. Kasutaja pääseb ressursile ligi läbi Interneti vaid lähima CDN PoP-i — Point of Presence. Enamasti on see kuskil lähedal. Edasi lahkub ta avalikust Internetist ja liikudes privaatse backbone'i kaudu, näiteks Atlantika kohal, jõuab ta otse ressursini.

Huvitav, kuidas Internet 10 aasta pärast välja näeb, kui see suundumus jätkub?

Füüsilised kanalid

Teadlased ei ole veel mõelnud, kuidas valguse kiirus universumis suurendada, kuid nad on palju edusamme teinud selle edastamise meetodite osas läbi optiliste kiudude. Praegu kasutame kaableid, millel on 6912 kiudu. See aitab oluliselt optimeerida nende paigaldamise maksumust.

Mõnes piirkonnas peame kasutama spetsiaalseid kaableid. Näiteks Sydney piirkonnas kasutame termiitide vastu kaitstud kaableid. 

Keegi ei ole kaitstud probleemide eest ja mõnikord on meie kanalid kahjustatud. Paremal pildil on optilised kaablid ühes Ameerika piirkonnas, mille lõhkasid ehitajad. Õnnetuse tulemusena kadus ainult 13 andmepaketti, mis on üllatav. Veel kord – ainult 13! Süsteem lülitus koheselt varukanalitele – mastaap töötab.

Me jooksime läbi mõned Amazon Web Services'i teenused ja tehnoloogiad. Loodan, et teil on nüüd vähemalt mingisugune arusaam ülesannete mastaabist, millega meie insenerid peavad tegelema. Isiklikult on see mulle väga huvitav. 

See on Vasiliy Pantjušina triloogia viimane osa AWS-i seadistamisest. esimese osades on kirjeldatud serverite optimeerimist ja andmebaasi skaleerimist, aga teine – serverless-funktsioonid ja Firecracker.

VDS-l on võimalik installida: HighLoad++ Novembris jagab Vasiliy Pantjušin uusi üksikasju Amazonist. Ta sellest räägib tõrgete põhjustest ja jaotatud süsteemide projekteerimisest Amazonis. 24. oktoobril on veel võimalik broneerida pilet soodsa hinnaga, tasuda saab hiljem. Ootame teid HighLoad++ üritusele, tulge – räägime!

Allikas: habr.com