Amazon Web Services võrgu ulatus on 69 tsooni üle maailma 22 piirkonnas: USA, Euroopa, Aasia, Aafrika ja Austraalia. Igas tsoonis on kuni 8 andmekeskust – andmetöötluskeskust. Igal andmekeskusel on tuhandeid või sadu tuhandeid servereid. Võrk on projekteeritud nii, et arvesse võetakse kõiki ebatõenäolisi katkestusi. Näiteks on kõik piirkonnad üksteisest eraldatud ja ligipääsetavuse tsoonid on eraldatud mitme kilomeetri kaugusel. Isegi kaabli läbilõikamisel lülitub süsteem varukanalitele ja teabe kadu ulatub mõne andmepaketini. Vassili Pantjuhhin räägib, millistele põhimõtetele võrgustik veel üles ehitatakse ja kuidas see on üles ehitatud.
Vassili Pantjuhhin alustas Unixi administraatorina .ru ettevõtetes, töötas 6 aastat suure Sun Microsystemi riistvara kallal ja jutlustas 11 aastat EMC-s andmekeskset maailma. See arenes loomulikult privaatpilvedeks, seejärel liikus avalikesse pilvedesse. Nüüd annab ta Amazon Web Servicesi arhitektina tehnilist nõu, et aidata AWS-i pilves elada ja areneda.
AWS-i triloogia eelmises osas süvenes Vassili füüsiliste serverite disaini ja andmebaasi skaleerimist. Nitro-kaardid, kohandatud KVM-põhine hüperviisor, Amazon Aurora andmebaas - selle kõige kohta materjalis "" Lugege konteksti või vaadake kõned.
See osa keskendub võrgu skaleerimisele, mis on üks AWS-i kõige keerukamaid süsteeme. Areng tasasest võrgust virtuaalseks privaatpilveks ja selle disain, Blackfooti ja HyperPlane'i siseteenused, mürarikka naabri probleem ning lõpuks - võrgu, magistraal- ja füüsiliste kaablite ulatus. Sellest kõigest lõike all.
Kohustustest loobumine: kõik allpool on Vassili isiklik arvamus ja ei pruugi kattuda Amazon Web Services'i seisukohaga.
Võrgu skaleerimine
AWS-pilv käivitati 2006. aastal. Tema võrgustik oli üsna primitiivne – lameda struktuuriga. Privaatsete aadresside vahemik oli ühine kõigile pilveüürnikele. Uue virtuaalmasina käivitamisel saite kogemata sellest vahemikust saadaoleva IP-aadressi.
Seda lähenemist oli lihtne rakendada, kuid see piiras põhimõtteliselt pilve kasutamist. Eelkõige oli üsna keeruline välja töötada hübriidlahendusi, mis ühendasid privaatvõrgud kohapeal ja AWS-is. Kõige tavalisem probleem oli IP-aadressi vahemike kattumine.
Virtuaalne privaatpilv
Pilv osutus nõutuks. Käes on aeg mõelda mastaapsuse ja selle kasutusvõimaluse peale kümnete miljonite üürnike poolt. Tasapinnaline võrk on muutunud suureks takistuseks. Seetõttu mõtlesime, kuidas kasutajaid võrgu tasandil üksteisest isoleerida, et nad saaksid iseseisvalt IP-vahemikke valida.
Mis tuleb esimese asjana meelde, kui mõtlete võrgu isoleerimisele? Kindlasti VLAN и VRF – virtuaalne marsruutimine ja edastamine.
Kahjuks see ei õnnestunud. VLAN-i ID on ainult 12-bitine, mis annab meile ainult 4096 eraldatud segmenti. Isegi suurimad lülitid võivad kasutada maksimaalselt 1-2 tuhat VRF-i. VRF-i ja VLAN-i koos kasutamine annab meile vaid mõne miljoni alamvõrgu. Sellest ei piisa kindlasti kümnete miljonite üürnike jaoks, kellest igaüks peab saama kasutada mitut alamvõrku.
Samuti ei jõua me lihtsalt vajalikul hulgal suuri kaste osta näiteks Ciscost või Juniperist. Sellel on kaks põhjust: see on pööraselt kallis ja me ei taha olla nende arendus- ja lappimispoliitika meelevallas.
On ainult üks järeldus – tehke oma lahendus.
2009. aastal teatasime VPC - Virtuaalne privaatpilv. Nimi jäi külge ja nüüd kasutavad seda ka paljud pilvepakkujad.
VPC on virtuaalne võrk SDN (Tarkvara määratletud võrk). Otsustasime, et L2 ja L3 tasemel spetsiaalseid protokolle ei leiuta. Võrk töötab standardsel Ethernetil ja IP-l. Võrgu kaudu edastamiseks on virtuaalmasina liiklus kapseldatud meie enda protokolli ümbrisesse. See näitab ID-d, mis kuulub üürniku VPC-le.
Kõlab lihtsalt. Siiski on mitmeid tõsiseid tehnilisi väljakutseid, mis tuleb ületada. Näiteks kus ja kuidas salvestada andmeid virtuaalsete MAC/IP-aadresside, VPC ID ja vastava füüsilise MAC/IP kaardistamise kohta. AWS-i skaalal on see tohutu tabel, mis peaks töötama minimaalsete juurdepääsuviivitustega. Selle eest vastutav kaardistamisteenus, mis levib õhukese kihina üle kogu võrgu.
Uue põlvkonna masinates teostavad kapseldamist Nitro kaardid riistvara tasemel. Vanematel juhtudel on kapseldamine ja kapseldamine tarkvarapõhised.
Mõelgem välja, kuidas see üldiselt toimib. Alustame L2 tasemega. Oletame, et meil on virtuaalmasin IP 10.0.0.2 füüsilises serveris 192.168.0.3. See saadab andmed virtuaalsesse masinasse 10.0.0.3, mis töötab 192.168.1.4. ARP päring genereeritakse ja saadetakse võrgu Nitro kaardile. Lihtsuse huvides eeldame, et mõlemad virtuaalsed masinad elavad samas "sinises" VPC-s.
Kaart asendab lähteaadressi enda aadressiga ja edastab ARP-kaadri kaardistamisteenusele.
Kaardistamisteenus tagastab teabe, mis on vajalik üle L2 füüsilise võrgu edastamiseks.
Nitro kaart ARP vastuses asendab füüsilise võrgu MAC aadressiga VPC-s.
Andmete edastamisel mähime loogilise MAC ja IP VPC ümbrisesse. Seda kõike edastame üle füüsilise võrgu, kasutades selleks sobivaid allika ja sihtkoha IP Nitro kaarte.
Kontrolli teostab füüsiline masin, kuhu pakk on suunatud. See on vajalik aadressi võltsimise võimaluse vältimiseks. Masin saadab kaardistamisteenusele eripäringu ja küsib: “Füüsilisest masinast 192.168.0.3 sain sinises VPC-s paketi, mis on mõeldud 10.0.0.3 jaoks. Kas ta on legitiimne?
Kaardistamisteenus kontrollib oma ressursside eraldamise tabelit ja lubab või keelab paketi läbimise. Kõigil uutel juhtudel on Nitro kaartidele lisatud täiendav valideerimine. Sellest on võimatu isegi teoreetiliselt mööda minna. Seetõttu ei tööta mõne teise VPC ressursside võltsimine.
Järgmisena saadetakse andmed virtuaalmasinasse, mille jaoks need on mõeldud.
Kaardistamisteenus töötab ka loogilise ruuterina andmete edastamiseks erinevates alamvõrkudes olevate virtuaalmasinate vahel. Kõik on põhimõtteliselt lihtne, ma ei hakka detailidesse laskuma.
Selgub, et iga paketi edastamisel pöörduvad serverid kaardistamisteenuse poole. Kuidas tulla toime vältimatute viivitustega? Vahemällu salvestamine, muidugi.
Ilu on see, et te ei pea kogu tohutut tabelit vahemällu salvestama. Füüsiline server majutab virtuaalseid masinaid suhteliselt väikesest arvust VPC-dest. Peate ainult nende VPC-de kohta teabe vahemällu salvestama. Andmete edastamine teistele VPC-dele vaikekonfiguratsioonis ei ole ikka veel seaduslik. Kui kasutatakse selliseid funktsioone nagu VPC-peering, laaditakse vahemällu täiendavalt teave vastavate VPC-de kohta.
Korraldasime andmete edastamise VPC-sse.
Mustade koertega
Mida teha juhtudel, kui liiklust on vaja edastada väljapoole, näiteks internetti või VPN-i kaudu maapinnale? Aitab meid siin Mustade koertega — AWS-i siseteenus. Selle on välja töötanud meie Lõuna-Aafrika meeskond. Seetõttu on teenus nime saanud Lõuna-Aafrikas elava pingviini järgi.
Blackfoot dekapsuleerib liikluse ja teeb sellega, mida vaja. Andmed saadetakse Internetti sellisel kujul, nagu nad on.
VPN-i kasutamisel andmed kapseldatakse ja pakitakse uuesti IPseci.
Direct Connecti kasutamisel liiklus märgistatakse ja saadetakse vastavasse VLAN-i.
HüperPlane
See on sisemine vookontrolli teenus. Paljud võrguteenused nõuavad jälgimist andmevoo olekud. Näiteks NAT-i kasutamisel peab voo juhtimine tagama, et igal IP:sihtkoha pordi paaril oleks kordumatu väljuv port. Tasakaalustaja puhul NLB - Võrgu koormuse tasakaalustaja, tuleks andmevoog alati suunata samasse virtuaalmasinasse. Turvagrupid on olekupõhine tulemüür. See jälgib sissetulevat liiklust ja avab kaudselt pordid väljamineva paketivoo jaoks.
AWS-i pilves on edastuslatentsusnõuded äärmiselt kõrged. Sellepärast HüperPlane kriitiline kogu võrgu jõudluse jaoks.
Hyperplane on ehitatud EC2 virtuaalmasinatele. Siin pole maagiat, on ainult kavalus. Trikk seisneb selles, et need on suure RAM-iga virtuaalmasinad. Toimingud on tehingupõhised ja neid tehakse ainult mälus. See võimaldab teil saavutada vaid kümnete mikrosekundite pikkuseid viivitusi. Kettaga töötamine tapab kogu tootlikkuse.
Hyperplane on paljude selliste EC2 masinate hajutatud süsteem. Iga virtuaalmasina ribalaius on 5 GB/s. Kogu piirkondlikus võrgus pakub see uskumatut terabitti ribalaiust ja võimaldab töötlemist miljoneid ühendusi sekundis.
HyperPlane töötab ainult voogudega. VPC-pakettide kapseldamine on selle jaoks täiesti läbipaistev. Selle siseteenuse potentsiaalne haavatavus takistaks siiski VPC isolatsiooni katkemist. Turvalisuse eest vastutavad allpool olevad tasemed.
Lärmakas naaber
Ikka on probleem lärmakas naaber - lärmakas naaber. Oletame, et meil on 8 sõlme. Need sõlmed töötlevad kõigi pilve kasutajate vooge. Tundub, et kõik on korras ja koormus peaks olema kõigi sõlmede vahel ühtlaselt jaotunud. Sõlmed on väga võimsad ja neid on raske üle koormata.
Kuid me ehitame oma arhitektuuri isegi ebatõenäoliste stsenaariumide põhjal.
Madal tõenäosus ei tähenda võimatut.
Võime ette kujutada olukorda, kus üks või mitu kasutajat tekitaksid liiga palju koormust. Kõik HyperPlane'i sõlmed on selle koormuse töötlemisega seotud ja teised kasutajad võivad kogeda jõudlushäireid. See rikub pilve kontseptsiooni, mille puhul üürnikel puudub võimalus üksteist mõjutada.
Kuidas lahendada lärmaka naabri probleemi? Esimene asi, mis pähe tuleb, on killustamine. Meie 8 sõlme on loogiliselt jagatud neljaks killuks, millest igaühes on 4 sõlme. Nüüd häirib lärmakas naaber vaid veerandit kõigist kasutajatest, kuid häirib neid suuresti.
Teeme asju teisiti. Igale kasutajale eraldame ainult 3 sõlme.
Trikk seisneb sõlmede juhuslikus määramises erinevatele kasutajatele. Alloleval pildil lõikub sinine kasutaja sõlmed ühega kahest teisest kasutajast – rohelise ja oranži.
8 sõlme ja 3 kasutaja puhul on tõenäosus, et mürarikas naaber ristub ühe kasutajaga, 54%. Sellise tõenäosusega mõjutab sinine kasutaja teisi üürnikke. Samal ajal ainult osa selle koormusest. Meie näites on see mõju vähemalt mingil moel märgatav mitte kõigile, vaid ainult kolmandikule kõigist kasutajatest. See on juba hea tulemus.
Kasutajate arv, kes ristuvad
Tõenäosus protsentides
0
18%
1
54%
2
26%
3
2%
Toome olukorra reaalsusele lähemale – võtame 100 sõlme ja 5 kasutajat 5 sõlme peal. Sel juhul ei ristu ükski sõlm 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 HyperPlane'i sõlmede ja kasutajate hulk on tohutu, on mürarikka naabri võimalik mõju teistele kasutajatele minimaalne. Seda meetodit nimetatakse purustamise segamine - shuffle sharding. See minimeerib sõlme rikke negatiivset mõju.
Paljud teenused on üles ehitatud HyperPlane'i baasil: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Võrgu skaala
Räägime nüüd võrgu enda ulatusest. 2019. aasta oktoobriks pakub AWS oma teenuseid 22 piirkonda, ja plaanis on veel 9.
- Iga piirkond sisaldab mitut saadavuse tsooni. Neid on üle maailma 69.
- Iga AZ koosneb andmetöötluskeskustest. Kokku pole neid rohkem kui 8.
- Andmekeskuses on tohutul hulgal servereid, mõnes kuni 300 000.
Nüüd arvutame selle kõik keskmise, korrutame ja saame muljetavaldava näitaja, mis peegeldab Amazoni pilve skaala.
Saadavalolekutsoonide ja andmekeskuse vahel on palju optilisi linke. Ühes meie suurimas regioonis on rajatud 388 kanalit ainuüksi AZ-i omavaheliseks suhtluseks ja sidekeskusteks teiste piirkondadega (transiidikeskused). Kokku teeb see hulluks 5000 Tbit.
Backbone AWS on loodud spetsiaalselt pilve jaoks ja optimeeritud selle jaoks. Ehitame selle kanalitele 100 GB / s. Meie kontrollime neid täielikult, välja arvatud Hiina piirkonnad. Liiklust ei jagata teiste firmade koormatega.
Loomulikult pole me ainuke privaatse magistraalvõrguga pilveteenuse pakkuja. Üha enam suuri ettevõtteid läheb seda teed. Seda kinnitavad sõltumatud teadlased, näiteks aastast .
Graafik näitab, et sisupakkujate ja pilvepakkujate osakaal kasvab. Seetõttu väheneb selgroogsete pakkujate Interneti-liikluse osa pidevalt.
Selgitan, miks see juhtub. Varem oli enamik veebiteenuseid juurdepääsetav ja tarbitud otse Internetist. Tänapäeval asub üha rohkem servereid pilves ja on ligipääsetav selle kaudu CDN - Sisu levitamise võrk. Ressursile juurdepääsu saamiseks läheb kasutaja Interneti kaudu ainult lähimasse CDN-i PoP-sse - Kohaloleku punkt. Enamasti on see kuskil läheduses. Seejärel lahkub see avalikust Internetist ja lendab näiteks privaatse magistraalvõrgu kaudu üle Atlandi ookeani ja jõuab otse ressurssi.
Huvitav, kuidas muutub internet 10 aasta pärast, kui see trend jätkub?
Füüsilised kanalid
Teadlased pole veel aru saanud, kuidas universumis valguse kiirust suurendada, kuid nad on teinud suuri edusamme selle valguskiu kaudu edastamise meetodite osas. Praegu kasutame 6912 kiudkaableid. See aitab oluliselt optimeerida nende paigaldamise kulusid.
Mõnes piirkonnas peame kasutama spetsiaalseid kaableid. Näiteks Sydney piirkonnas kasutame termiitide vastu spetsiaalse kattega kaableid.
Keegi pole probleemide eest kaitstud ja mõnikord saavad meie kanalid kahjustatud. Parempoolsel fotol on ühe Ameerika piirkonna valguskaablid, mis ehitustööliste poolt rebenenud. Õnnetuse tagajärjel läks kaotsi vaid 13 andmepaketti, mis on üllatav. Taaskord - ainult 13! Süsteem lülitus sõna otseses mõttes koheselt varukanalitele – skaala töötab.
Galopisime läbi mõned Amazoni pilveteenused ja -tehnoloogiad. Loodan, et teil on vähemalt mingi ettekujutus ülesannete ulatusest, mida meie insenerid peavad lahendama. Isiklikult pean seda väga põnevaks.
See on Vassili Pantyukhini AWS-seadme triloogia viimane osa. IN osades kirjeldatakse serveri optimeerimist ja andmebaasi skaleerimist ning sisse - serverita funktsioonid ja Firecracker.
Edasi novembris jagab Vassili Pantjuhhin Amazoni seadme uusi üksikasju. Tema rikete põhjuste ja Amazoni hajutatud süsteemide disaini kohta. 24. oktoober on veel võimalik pilet hea hinnaga ja maksa hiljem. Ootame sind HighLoad++, tule vestleme!
Allikas: www.habr.com