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

Amazon Web Servicesi võrgu ulatus ulatub 69 tsooni kogu maailmas 22 regioonis: Ameerika Ühendriigid, Euroopa, Aasia, Aafrika ja Austraalia. Igas tsoonis asub kuni 8 andmekeskust. Igas andmekeskuses on tuhandeid või sadu tuhandeid servereid. Süsteem on üles ehitatud nii, et arvesse on võetud kõik ebatõenäolised katkestamise stsenaariumid. Näiteks on kõik regioonid teineteisest isoleeritud ning kättesaadavuse tsoonid paiknevad mitme kilomeetri kaugusel üksteisest. Isegi kui kaabel katkeb, suundub süsteem varuühendustele ning andmete kadu on minimaalne. Millistel muudel põhimõtetel võrku on ehitatud ja kuidas see toimib, räägib Vasili Pantjuhin.

Vassili Pantiuhin hakkas Unix-administraatorina töötama .ru ettevõtetes, tegeles 6 aastat suurte Sun Microsystem masinatega, 11 aastat propageeris ta andmekeskuste keskset rolli EMC-s. Loomulikult arenes ta välja erasektorisse, seejärel liikus avalikku. Praegu, Amazon Web Servicesi arhitektilt, annab ta tehnilisi nõuandeid, kuidas AWS-is elada ja areneda.

Triloogia eelmisel osal rääkis Vasili füüsiliste serverite ülesehitusest ja andmebaasi skaleerimisest. Nitro-kaardid, kohandatud KVM-põhine hüperviisor, Amazon Aurora andmebaas — kõigest sellest loe artiklis "Kuidas AWS «keedab» oma elastseid teenuseid. Serverite ja andmebaaside skaleerimine". Lugege, et süveneda konteksti, või vaata videomaterjal esitlusi.

Selles osas räägitakse võrgu skaleerimisest — ühest kõige keerulisemast süsteemist AWS-is. Evolutsioon tasapinnalisest võrgust Virtual Private Cloud'i ning selle ülesehitus, siseteenused Blackfoot ja HyperPlane, mürarikka naabri probleem ning lõpus — võrgu ulatused, backbone ja füüsilised kaablid. Kõigest sellest alapealkirja all.

Eemaldatud: kõik, mis allpool, on Vasili isiklik arvamus ja see ei pruugi kattuda Amazon Web Services'i seisukohaga.

Võrgu skaleerimine

AWS-i pilv käivitati 2006. aastal. Selle võrk oli suhteliselt primitiivne — tasapinnaline struktuur. Erakliendi aadresside ulatus oli kõigi pilve üürnike jaoks ühine. Uue virtuaalse masina käivitamisel said te juhuslikult ühe selle ulatuse IP-aadressi.

Selline lähenemine oli lihtne teostada, kuid piiras oluliselt pilve kasutamist. Eriti oli keeruline arendada hübriidlahendusi, kus ühendatakse maapealsed ja AWS-i eravõrgud. Levinud probleem oli IP-aadressi ulatuste kattumine.

Virtual Private Cloud

Pilv on osutunud nõudlikuks. On aeg mõelda skaleeritavusele ja võimalusele kasutada seda kümneid miljoneid üürnikke. Lame võrk on saanud peamiseks takistuseks. Seetõttu mõtleme, kuidas saaksime kasutajaid üksteisest võrgu tasandil isoleerida, et nad saaksid iseseisvalt valida IP-aadresse.

Mis tuleb esimesena meelde, kui mõtlete võrgu isoleerimisele? Loomulikult VLAN ja VRF — virtuaalne marsruutimine ja edastamine.

Kahjuks see ei töötanud. VLAN ID on vaid 12 bitti, mis annab meile kõigest 4096 isoleeritud segmenti. Isegi suurimatel lülititel 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 üürnike jaoks, kellel kõigil peab olema võimalus kasutada mitmeid alamvõrke.

Lisaks ei saa me endale lubada osta vajalike suurte kastide hulka, näiteks Cisco või Juniperi juures. Sellel on kaks põhjust: see on uskumatult kallis ja me ei soovi saada sõltuvaks nende arendus- ja värskenduspoliitikast.

Kokkuvõtteks – tuleb keeta oma lahendus.

Aastal 2009 kuulutasime me välja VPC — Virtual Private Cloud. Nimi on juurdunud ja nüüd kasutavad seda ka paljud pilveteenuse pakkujad.

VPC – see on virtuaalne võrk SDN (Tarkvara määratud võrk). Otsustasime mitte välja mõelda spetsiaalseid protokolle L2 ja L3 tasanditel. Võrk töötab standardse Etherneti ja IP-ga. Masinate liiklus pakitakse meie patenteeritud protokolli ümbrikku. Sellega määratakse ID, mis kuulub VPC üürnikule.

See kõlab lihtsalt. Kuid probleemide lahendamiseks tuleb lahendada mitmeid tõsiseid tehnilisi väljakutseid. Näiteks, kus ja kuidas hoida andmeid virtuaalsete MAC/IP-aadresse, VPC ID ja vastavaid füüsilisi MAC/IP. AWS ulatuses on see tohutu tabel, mis peab töötama minimaalsete viivitustega päringute korral. Selle eest vastutab mappauditeenuseid, mis on laiali jaotatud õhukese kihina kogu võrgus.

Uue põlvkonna masinates toimub pakettimine Nitro kaartide kaudu riistvaral tasandil. Vanemates instantsides toimub pakettimine ja dekapituleerimine tarkvaraliselt. 

Vaatame, kuidas see töötab üldiselt. Alustame L2 tasemelt. Oletame, et meil on virtuaalmasin, mille IP on 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-kaardile. Lihtsuse huvides oletame, et mõlemad virtuaalmasinad asuvad samas "sinises" VPCs.

Kaart asendab allika aadressi oma enda omaga ja edastab ARP-raami maapealse teenuse mapeerimisele.

Mapeerimisteenus tagastab teabe, mida vajatakse füüsilisel L2 võrgul andmete edastamiseks.

Nitro-kaart ARP-vastuses asendab füüsilise võrgu MAC-aadressi VPC aadressiga.

Andmete edastamisel pakime loogilised MAC ja IP VPC-katetesse. Edastame selle kõik füüsilisel võrgul vastava IP Nitro-kaardi allika ja sihtkoha kaudu.

Füüsiline masin, kellele paket on mõeldud, teostab kontrolli. See on vajalik aadresside valeleidmise välistamiseks. Masin saadab spetsiaalse päringu mapeerimisteenusele ja küsib: "Füüsiliselt masinast 192.168.0.3 sain paketi, mis on mõeldud 10.0.0.3 sinises VPCs. Kas see on legitiimne?" 

Mapeerimisteenus kontrollib oma ressursside asukoha tabelit ja kas lubab või keelab paketi edasiviimise. Kõikides uutes instantsides on Nitro-kaartidesse sisse ehitatud täiendav valideerimine. Selle tõkestamine ei ole isegi teoreetiliselt võimalik. Seega spoofing teistesse VPC-desse ei toimi.

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

Mapeerimisteenus töötab ka loogilise marsruuterina andmete edastamiseks erinevates alvõrkudes paiknevate virtuaalmasinate vahel. Seal on kontseptsiooniliselt kõik lihtne, ma ei hakka seda detailselt käsitlema.

Tuleb välja, et igal paketi edastamisel pöördub server maapeerse teenuse mapeerimise poole. Kuidas tulla toime vältimatute viivitustega? Vahemälu loomisega, loomulikult.

Kõige parem on see, et ei ole vaja vahemällu salvestada tervet tohutut tabelit. Füüsilisel serveril asuvad virtuaalmasinad suhteliselt väheste VPC-de seas. Vahemällu tuleb salvestada teave ainult nende VPC-de kohta. Andmete edastamine teistesse VPC-desse "vaikimisi" konfiguratsioonis ei ole ikkagi legitiimne. Kui kasutatakse sellist funktsionaalsust nagu VPC-leading, siis laaditakse vahemällu täiendavalt vastava VPC teave. 

Andmete edastamises VPC-s saime selgeks.

Blackfoot

Kuidas toimida olukordades, kui liiklust tuleb edastada väljapoole, näiteks Internetti või VPN kaudu maapinnale? Siin aitab meid Blackfoot — sisemine AWS teenus. See on välja töötatud meie Lõuna-Aafrika meeskonna poolt. Seetõttu on teenus nimetatud Lõuna-Aafrikas elava pingviini järgi.

Blackfoot dekapsuleerib liiklust ja teeb sellega, mida on vaja. Andmed saadetakse Internetti sellisena, nagu nad on.

Andmed dekapsuleeritakse ja pakendatakse uuesti IPsec-katte alla, kui kasutatakse VPN-i.

Direct Connecti kasutamisel liigitatakse liiklus ja edastatakse vastavasse VLAN-i.

HyperPlane

See on sisemine voo juhendamise teenus. Paljud võrguteenused nõuavad voo juhtimist andmevoo seisundi. Näiteks NAT-i kasutamisel peab voo juhtimine tagama, et iga «IP: sihtport» paar vastab unikaalsele väljaminevale pordile. Koormuse tasakaalu puhul NLB — Võrgu Koormuse Tasakaalustaja, peab andmevoog alati olema suunatud ühte ja samasse sihtvirtualmasinasse. Turvarühmad on olekuga tulemüür. See jälgib sissetulevat liiklust ja avab automaatselt pordid väljamineva andmevoo jaoks.

AWS pilves on edastuslatentsusohtlikud nõuded äärmiselt kõrged. Seetõttu HyperPlane on kriitiline kogu võrgu töökindluse jaoks.

Hyperplane on üles ehitatud EC2 virtuaalmasinatele. Siin pole mingit maagiat, vaid ainult trikk. Trikk seisneb selles, et need on virtuaalmasinad suure RAM-i mahuga. Tehingud on ja need toimuvad eranditult mälus. See võimaldab saavutada viivitusi vaid kümnendik mikrosekundeid. Töö kettaga hävitaks kogu jõudluse. 

Hyperplane on jagatud süsteem, mis koosneb tohutust arvust sellistest EC2 masinatest. Igal virtuaalmasinal on läbilaskevõime 5 GB/s. Terve piirkonna võrgu perspektiivis annab see massiivse terabitti läbilaskevõime ja võimaldab töödelda miljoneid ühendusi sekundis.

HyperPlane töötab ainult andmevoogudega. VPC pakettide kapseldamine on selle jaoks täiesti läbipaistev. Selle sisemise teenuse potentsiaalne haavatavus ei võimalda siiski VPC-isolatsiooni läbida. Turvalisuse eest vastutavad madalamad tasemed.

Häiritud naaber

On veel probleem häiriva naabri — häiriv naaber. Oletame, et meil on 8 nodi. Need noded töötlevad kõikide pilvekasutajate vooge. Tundub, et kõik on hästi ja koormus peaks olema ühtlaselt jaotatud kõigi nodide vahel. Nodid on väga võimsad ja neid on raske ületäita.

Kuid me ehitame oma arhidektuuri isegi vähetõenäolistest stsenaariumidest lähtuvalt. 

Madala tõenäosus ei tähenda võimatust.

Saame ette kujutada olukorda, kus üks või mitu kasutajat genereerivad liiga suurt koormust. Kõik HyperPlane nodid on seotud selle koormuse töötlemisse ja teised kasutajad võivad kogeda mingisugust jõudluse langust. See rikub pilve kontseptsiooni, kus üürnikud ei saa teineteisele mõju avaldada.

Kuidas lahendada lärmakate naabrite probleem? Esimene asi, mis pähe tuleb - shardimine. Meie 8 nodi jagunevad loogiliselt 4 shardiks, igas 2 nodi. Nüüd segab lärmakas naaber vaid neljandikku kõikidest kasutajatest, kuid selle mõju on siiski tugev.

Teeme teistmoodi. Igaühele kasutajale eraldame vaid 3 nodi. 

Nipin on määrata nodid erinevatele kasutajatele juhuslikult. Alloleval pildil on sinine kasutaja ühenduses ühe teise kasutajaga - rohelise ja oranžiga.

8 nodi ja 3 kasutaja korral on lärmakate naabrite tõenäosus teiste kasutajatega seonduda 54%. Just selle tõenäosusega mõjutab sinine kasutaja teisi üürnikke. Samuti ainult osa oma koormusest. Meie näites on see mõju märgatav vaid kolmandikule kõikidest kasutajatest. See on juba hea tulemus.

Kasutajate arv, kes ristuvad

Tõenäosus protsentides

0

18%

1

54%

2

26%

3

2%

Läheneme olukorrale reaalsetele tingimustele - võtame 100 nodi ja 5 kasutajat 5 nodit. Sellisel juhul ei ühildu ükski nod 77% tõenäosusega. 

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, kus on tohutult palju HyperPlane nodi ja kasutajaid, on lärmakate naabrite potentsiaalne mõju teistele kasutajatele minimaalne. Seda meetodit nimetatakse shuffle sharding — . See minimeerib negatiivseid mõjusid nodide rikete korral.HyperPlane'i baasil on ehitatud palju teenuseid: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.

Võrgumahud

Võrgu ulatus

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

• Iga piirkond sisaldab mitmeid kätte saadavuse tsoone — Availability Zone. Kokku on neid maailmas 69.
• Iga AZ koosneb Andmekeskustest. Kokku on neid kuni 8.
• Andmekeskustes asub suur hulk servereid, mõnedes kuni 300 000.

Nüüd koondame need keskmised numbrid, korrutame ja saame muljetavaldava arvu, mis näitab Amazonase pilve ulatust.

Kätte saadavuse tsoonide ja Andmekeskuste vahel on paigaldatud palju optilisi kanaleid. Ühes meie suurimas piirkonnas on AZ-devaheliseks ja teiste piirkondade seotud keskuste (Transit Centers) ühendamiseks paigaldatud 388 kanalit. Kokku annab see uskumatud 5000 Tbit.

AWS selgroog on ehitatud spetsiaalselt pilve jaoks ja optimeeritud selle töötamiseks. Me ehitame seda kanaleid pidi 100 Gbps. Me kontrollime neid täielikult, välja arvatud Hiina piirkondades. Traffik ei jagune teiste ettevõtete koormustega.

Muidugi, me ei ole ainus pilveteenuse pakkuja, kellel on privaatne selgroo võrgu. Üha rohkem suuri ettevõtteid järgib seda rada. Seda kinnitavad sõltumatud uurijad, näiteks ettevõttest Telegeography.

Graafikult on näha, et sisuteenuse ja pilveteenuse pakkujate osakaal kasvab. Seetõttu pidevalt vähendab selgroo teenuse pakkujate osakaal Interneti-traffikus.

Selgitan, miks see nii on. Varem olid enamik veebiteenuseid kergesti kätte saadavad ja neid tarbiti otse Internetist. Nüüd asub üha rohkem servereid pilves ja need on kergesti ligipääsetavad läbi CDN — Content Distribution Network. Ressursile pääsemiseks jõuab kasutaja Internetisse ainult lähima CDN PoP -ni — Point of Presence. Enamasti asub see kuskil lähedal. Edasi väljub see avalikust Internetist ja reisib privaatse selgroo kaudu näiteks läbi Atlandi, jõudes otse ressursile.

Huvitav, kuidas muutub Internet 10 aasta pärast, kui see trend jätkub?

Füüsilised kanalid

Teadlased ei ole veel leidnud, kuidas valguse kiirus Universumis suurendada, kuid nad on teinud suuri edusamme selle edastamise meetodites kiudoptilistes kaablites. Praegu kasutame kaableid, millel on 6912 kiudu. See aitab oluliselt optimeerida nende paigaldamise kulu.

Mõnes piirkonnas peame kasutama spetsiaalseid kaableid. Näiteks Sydney piirkonnas kasutame kaableid, millel on spetsiaalne kate_termite vastu. 

Kehast ei ole keegi kaitstud ja mõnikord meie kanalid purunevad. Paremal pildil on optilised kaablid ühes Ameerika piirkonnas, mida ehitajad lõhkusid. Õnnetuse tulemusena kadus kokku vaid 13 paketti andmeid, mis on üllatav. Kordame – kokku vaid 13! Süsteem lülitus sõna otsese mõttes koheselt varukanalitele – skaala töötab.

Me jalutasime kiiresti läbi mõnede Amazon Cloud'i teenuste ja tehnoloogiate. Loodan, et teil on tekkinud vähemalt mingisugune ettekujutus ülesannetest, millega meie insenerid peavad tegelema. Isiklikult on see mind väga paelunud. 

See on Vasily Pantyukhini teose AWS trilogia viimane osa. esimene Osas on kirjeldatud serverite optimeerimist ja andmebaasi skaleerimist, aga teises serverless-funktsioone ja Firecrackerit.

Pealehe HighLoad++ Novembris jagab Vasily Pantyukhin uusi detaile Amazon'i seadmete kohta. Ta populaarsetest sihtkohtadest kolimiseks: Uus-Meremaalt kuni Kalatši Võrooblast. räägib tõrgete põhjustest ja jaotatud süsteemide projekteerimisest Amazonis. 24. oktoobril on veel võimalik osta broneerima pilet hea hinnaga, maksa hiljem. Ootame teid HighLoad++-le, tulge — räägime!

Allikas: habr.com