Obseg omrežja Amazon Web Services je 69 območij po vsem svetu v 22 regijah: ZDA, Evropa, Azija, Afrika in Avstralija. Vsaka cona vsebuje do 8 podatkovnih centrov – Data Processing Centers. Vsak podatkovni center ima na tisoče ali sto tisoče strežnikov. Omrežje je zasnovano tako, da so upoštevani vsi malo verjetni scenariji izpada. Na primer, vse regije so izolirane druga od druge, območja dostopnosti pa so ločena na razdaljah več kilometrov. Tudi če prerežete kabel, bo sistem preklopil na rezervne kanale, izguba informacij pa bo znašala nekaj paketov podatkov. Vasily Pantyukhin bo govoril o tem, na katerih drugih principih je omrežje zgrajeno in kako je strukturirano.
Vasilij Pantjuhin začel kot skrbnik Unixa v podjetjih .ru, 6 let delal na veliki strojni opremi Sun Microsystem in 11 let pri EMC pridigal o svetu, osredotočenem na podatke. Seveda se je razvil v zasebne oblake, nato pa se je preselil v javne. Zdaj, kot arhitekt Amazon Web Services, nudi tehnične nasvete za pomoč pri življenju in razvoju v oblaku AWS.
V prejšnjem delu trilogije AWS se je Vasilij poglobil v načrtovanje fizičnih strežnikov in skaliranje baze podatkov. Kartice Nitro, hipervizor na osnovi KVM po meri, baza podatkov Amazon Aurora - o vsem tem v gradivu "" Preberite za kontekst ali si oglejte govori.
Ta del se bo osredotočil na skaliranje omrežja, enega najbolj zapletenih sistemov v AWS. Evolucija od ravnega omrežja do virtualnega zasebnega oblaka in njegova zasnova, interne storitve Blackfoot in HyperPlane, problem hrupnega soseda in na koncu - obseg omrežja, hrbtenice in fizičnih kablov. O vsem tem pod rezom.
Izjava o omejitvi odgovornosti: vse spodaj je Vasilijevo osebno mnenje in morda ne sovpada s stališčem Amazon Web Services.
Omrežno skaliranje
Oblak AWS je bil predstavljen leta 2006. Njegovo omrežje je bilo precej primitivno - s ploščato strukturo. Razpon zasebnih naslovov je bil skupen vsem najemnikom oblaka. Pri zagonu novega virtualnega stroja ste pomotoma prejeli razpoložljiv naslov IP iz tega obsega.
Ta pristop je bil enostaven za implementacijo, vendar je bistveno omejil uporabo oblaka. Predvsem je bilo precej težko razviti hibridne rešitve, ki združujejo zasebna omrežja na terenu in v AWS. Najpogostejša težava je bilo prekrivanje obsegov naslovov IP.
Navidezni zasebni oblak
Izkazalo se je, da je povpraševanje po oblaku. Prišel je čas za razmislek o razširljivosti in možnosti, da jo uporablja več deset milijonov najemnikov. Ravno omrežje je postalo velika ovira. Zato smo razmišljali, kako uporabnike med seboj izolirati na omrežni ravni, da bi lahko samostojno izbirali obsege IP.
Kaj je prva stvar, ki vam pride na misel, ko pomislite na izolacijo omrežja? Vsekakor VLAN и VRF - Virtualno usmerjanje in posredovanje.
Na žalost ni šlo. VLAN ID je samo 12 bitov, kar nam daje le 4096 izoliranih segmentov. Tudi največja stikala lahko uporabljajo največ 1-2 tisoč VRF-jev. Skupna uporaba VRF in VLAN nam daje le nekaj milijonov podomrežij. To vsekakor ni dovolj za več deset milijonov najemnikov, od katerih mora imeti vsak možnost uporabe več podomrežij.
Prav tako si preprosto ne moremo privoščiti nakupa potrebnega števila velikih škatel, na primer pri Ciscu ali Juniperju. Obstajata dva razloga: noro je drago in ne želimo biti prepuščeni na milost in nemilost njihovi politiki razvoja in popravkov.
Zaključek je le en - naredite svojo rešitev.
Leta 2009 smo objavili VPC - Navidezni zasebni oblak. Ime se je obdržalo in zdaj ga uporabljajo tudi številni ponudniki oblakov.
VPC je virtualno omrežje SDN (Programsko definirano omrežje). Odločili smo se, da ne bomo izumljali posebnih protokolov na nivojih L2 in L3. Omrežje deluje na standardnem Ethernetu in IP. Za prenos po omrežju je promet navideznega stroja enkapsuliran v našem lastnem ovoju protokola. Označuje ID, ki pripada najemnikovemu VPC.
Sliši se preprosto. Vendar pa obstaja več resnih tehničnih izzivov, ki jih je treba premagati. Na primer, kje in kako shraniti podatke o preslikavi virtualnih naslovov MAC/IP, ID VPC in ustreznega fizičnega MAC/IP. Na lestvici AWS je to ogromna tabela, ki bi morala delovati z minimalnimi zamudami pri dostopu. Odgovoren za to storitev kartiranja, ki je v tanki plasti razpršen po celotni mreži.
V strojih nove generacije enkapsulacijo izvajajo kartice Nitro na nivoju strojne opreme. V starejših primerih enkapsulacija in dekapsulacija temeljita na programski opremi.
Ugotovimo, kako deluje na splošno. Začnimo s stopnjo L2. Predpostavimo, da imamo virtualni stroj z IP 10.0.0.2 na fizičnem strežniku 192.168.0.3. Podatke pošilja virtualnemu stroju 10.0.0.3, ki živi na 192.168.1.4. Zahteva ARP se ustvari in pošlje na omrežno kartico Nitro. Zaradi poenostavitve predpostavljamo, da oba virtualna stroja živita v istem "modrem" VPC.
Zemljevid zamenja izvorni naslov s svojim in posreduje okvir ARP storitvi za preslikavo.
Storitev preslikave vrne informacije, ki so potrebne za prenos preko fizičnega omrežja L2.
Kartica Nitro v odgovoru ARP nadomesti MAC v fizičnem omrežju z naslovom v VPC.
Pri prenosu podatkov zavijemo logični MAC in IP v VPC ovoj. Vse to prenašamo preko fizičnega omrežja z uporabo ustreznih izvornih in ciljnih IP Nitro kartic.
Fizični stroj, ki mu je paket namenjen, opravi preverjanje. To je potrebno za preprečitev možnosti ponarejanja naslovov. Stroj pošlje posebno zahtevo kartografski storitvi in vpraša: »S fizičnega stroja 192.168.0.3 sem prejel paket, ki je namenjen 10.0.0.3 v modrem VPC. Ali je legitimen?
Storitev preslikave preveri svojo tabelo dodeljevanja virov in dovoli ali zavrne prehod paketa. V vseh novih primerih je v kartice Nitro vdelana dodatna validacija. Nemogoče ga je obiti niti teoretično. Zato lažno predstavljanje virov v drugem VPC ne bo delovalo.
Nato se podatki pošljejo na virtualni stroj, za katerega so namenjeni.
Storitev preslikave deluje tudi kot logični usmerjevalnik za prenos podatkov med virtualnimi stroji v različnih podomrežjih. Konceptualno je vse preprosto, ne bom šel v podrobnosti.
Izkazalo se je, da se pri prenosu vsakega paketa strežniki obrnejo na storitev preslikave. Kako ravnati z neizogibnimi zamudami? Predpomnjenje, seveda.
Lepota je v tem, da vam ni treba predpomniti celotne ogromne tabele. Fizični strežnik gosti virtualne stroje iz relativno majhnega števila VPC-jev. Predpomniti morate le informacije o teh VPC-jih. Prenos podatkov na druge VPC v »privzeti« konfiguraciji še vedno ni zakonit. Če se uporablja funkcionalnost, kot je VPC-peering, se informacije o ustreznih VPC-jih dodatno naložijo v predpomnilnik.
Uredili smo prenos podatkov v VPC.
Črnonogec
Kaj storiti v primerih, ko je treba promet prenesti navzven, na primer na internet ali prek VPN-ja na tla? Pomaga nam tukaj Črnonogec — Notranja storitev AWS. Razvila ga je naša ekipa iz Južne Afrike. Zato je storitev poimenovana po pingvinu, ki živi v Južni Afriki.
Blackfoot dekapsulira promet in z njim naredi, kar je potrebno. Podatki se pošiljajo v internet takšni, kot so.
Pri uporabi VPN se podatki dekapsulirajo in ponovno zavijejo v IPsec.
Pri uporabi Direct Connect je promet označen in poslan v ustrezen VLAN.
HyperPlane
To je storitev notranjega nadzora pretoka. Številne omrežne storitve zahtevajo nadzor stanja pretoka podatkov. Na primer, pri uporabi NAT mora nadzor pretoka zagotoviti, da ima vsak par IP:ciljna vrata edinstvena izhodna vrata. V primeru balanserja NLB - Izravnalnik obremenitve omrežja, mora biti tok podatkov vedno usmerjen na isti ciljni virtualni stroj. Varnostne skupine so požarni zid s spremljanjem stanja. Spremlja dohodni promet in implicitno odpira vrata za pretok odhodnih paketov.
V oblaku AWS so zahteve za zakasnitev prenosa izjemno visoke. Zato HyperPlane ključnega pomena za delovanje celotnega omrežja.
Hyperplane je zgrajen na virtualnih strojih EC2. Tu ni čarovnije, samo zvijača. Trik je v tem, da so to virtualni stroji z velikim RAM-om. Operacije so transakcijske in se izvajajo izključno v pomnilniku. To vam omogoča, da dosežete zamude le desetine mikrosekund. Delo z diskom bi uničilo vso produktivnost.
Hyperplane je porazdeljen sistem ogromnega števila takih strojev EC2. Vsak virtualni stroj ima pasovno širino 5 GB/s. V celotnem regionalnem omrežju to zagotavlja neverjetne terabite pasovne širine in omogoča obdelavo milijone povezav na sekundo.
HyperPlane deluje samo s tokovi. Enkapsulacija paketov VPC je zanj popolnoma transparentna. Morebitna ranljivost v tej notranji storitvi bi še vedno preprečila prekinitev izolacije VPC. Spodnje ravni so odgovorne za varnost.
Hrupni sosed
Še vedno je problem hrupni sosed - hrupni sosed. Predpostavimo, da imamo 8 vozlišč. Ta vozlišča obdelujejo tokove vseh uporabnikov oblaka. Zdi se, da je vse v redu in obremenitev mora biti enakomerno porazdeljena po vseh vozliščih. Vozlišča so zelo močna in jih je težko preobremeniti.
Toda svojo arhitekturo gradimo na podlagi celo malo verjetnih scenarijev.
Majhna verjetnost ne pomeni nemogoče.
Lahko si predstavljamo situacijo, v kateri bi eden ali več uporabnikov ustvarilo preveliko obremenitev. Vsa vozlišča HyperPlane so vključena v obdelavo te obremenitve in drugi uporabniki bi lahko doživeli nekakšen udarec v zmogljivosti. To ruši koncept oblaka, v katerem najemniki nimajo možnosti vplivanja drug na drugega.
Kako rešiti problem hrupnega soseda? Prva stvar, ki mi pride na misel, je šarding. Naših 8 vozlišč je logično razdeljenih na 4 drobce po 2 vozlišči. Zdaj bo hrupni sosed motil le četrtino vseh uporabnikov, a jih bo močno motil.
Naredimo stvari drugače. Vsakemu uporabniku bomo dodelili samo 3 vozlišča.
Trik je v naključnem dodeljevanju vozlišč različnim uporabnikom. Na spodnji sliki modri uporabnik seka vozlišča z enim od drugih dveh uporabnikov – zelenim in oranžnim.
Pri 8 vozliščih in 3 uporabnikih je verjetnost, da se hrupni sosed križa z enim od uporabnikov, 54 %. S to verjetnostjo bo modri uporabnik vplival na druge najemnike. Hkrati le del njegove obremenitve. V našem primeru bo ta vpliv vsaj nekako opazen ne vsem, ampak le tretjini vseh uporabnikov. To je že dober rezultat.
Število uporabnikov, ki se bodo križali
Verjetnost v odstotkih
0
18%
1
54%
2
26%
3
2%
Približajmo situacijo realnosti – vzemimo 100 vozlišč in 5 uporabnikov na 5 vozliščih. V tem primeru se nobeno od vozlišč ne bo sekalo z verjetnostjo 77%.
Število uporabnikov, ki se bodo križali
Verjetnost v odstotkih
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
V resnični situaciji z ogromnim številom vozlišč in uporabnikov HyperPlane je potencialni vpliv hrupnega soseda na druge uporabnike minimalen. Ta metoda se imenuje mešanje drobljenja - shuffle sharding. Minimizira negativni učinek okvare vozlišča.
Številne storitve so zgrajene na osnovi HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Merilo omrežja
Zdaj pa se pogovorimo o samem obsegu omrežja. Za oktober 2019 AWS ponuja svoje storitve v 22 regij, predvidenih pa je še 9.
- Vsaka regija vsebuje več območij razpoložljivosti. Po svetu jih je 69.
- Vsaka AZ je sestavljena iz centrov za obdelavo podatkov. Skupaj jih ni več kot 8.
- V podatkovnem centru je ogromno strežnikov, nekateri do 300.
Zdaj pa vse to povprečimo, pomnožimo in dobimo impresivno številko, ki odraža Amazonova lestvica v oblaku.
Obstaja veliko optičnih povezav med conami razpoložljivosti in podatkovnim centrom. V eni naših največjih regij je položenih 388 kanalov samo za komunikacijo AZ med seboj in komunikacijskimi centri z drugimi regijami (Tranzitni centri). Na splošno je to noro 5000 Tbit.
Backbone AWS je izdelan posebej za oblak in optimiziran zanj. Gradimo ga na kanalih 100 GB/s. Popolnoma jih nadzorujemo, z izjemo regij na Kitajskem. Promet se ne deli s kopico drugih podjetij.
Seveda pa nismo edini ponudnik oblakov z zasebnim hrbteničnim omrežjem. Vse več velikih podjetij gre po tej poti. To potrjujejo neodvisni raziskovalci, denimo iz .
Iz grafa je razvidno, da narašča delež ponudnikov vsebin in ponudnikov oblakov. Zaradi tega se delež internetnega prometa hrbteničnih ponudnikov nenehno zmanjšuje.
Pojasnil bom, zakaj se to zgodi. Prej je bila večina spletnih storitev dostopna in uporabljena neposredno iz interneta. Dandanes se vse več strežnikov nahaja v oblaku in so dostopni prek CDN - Omrežje za distribucijo vsebine. Za dostop do vira gre uporabnik prek interneta samo do najbližjega CDN PoP - Točka prisotnosti. Najpogosteje je nekje v bližini. Nato zapusti javni internet in preleti na primer zasebno hrbtenico čez Atlantik ter pride neposredno do vira.
Zanima me, kako se bo internet spremenil čez 10 let, če se bo ta trend nadaljeval?
Fizični kanali
Znanstveniki še niso ugotovili, kako povečati hitrost svetlobe v vesolju, so pa zelo napredovali pri metodah njenega prenosa po optičnih vlaknih. Trenutno uporabljamo 6912 optične kable. To pomaga znatno optimizirati stroške njihove namestitve.
V nekaterih regijah moramo uporabiti posebne kable. Na primer, v regiji Sydney uporabljamo kable s posebnim premazom proti termitom.
Nihče ni imun pred težavami in včasih se naši kanali poškodujejo. Desna fotografija prikazuje optične kable v eni od ameriških regij, ki so jih strgali gradbeni delavci. Zaradi nesreče je bilo izgubljenih le 13 podatkovnih paketov, kar je presenetljivo. Še enkrat - samo 13! Sistem je dobesedno takoj preklopil na rezervne kanale - tehtnica deluje.
Galopirali smo skozi nekatere Amazonove storitve in tehnologije v oblaku. Upam, da imate vsaj malo predstave o obsegu nalog, ki jih morajo rešiti naši inženirji. Osebno se mi zdi to zelo razburljivo.
To je zadnji del trilogije Vasilija Pantjuhina o napravi AWS. IN deli opisujejo optimizacijo strežnika in skaliranje baze podatkov ter v — brezstrežniške funkcije in Firecracker.
Na novembra bo Vasily Pantyukhin delil nove podrobnosti o napravi Amazon. On o vzrokih za okvare in načrtovanju porazdeljenih sistemov pri Amazonu. 24. oktober je še možen vstopnico po ugodni ceni, plačate pa kasneje. Čakamo te na HighLoad++, pridi in poklepetajmo!
Vir: www.habr.com