Mreža Amazon Web Services obuhvaća 69 zona širom sveta u 22 regiona: Sjedinjene Američke Države, Evropa, Azija, Afrika i Australija. U svakoj zoni se nalazi do 8 data centara. U svakom data centru su hiljade ili stotine hiljada servera. Mreža je izgrađena tako da uzima u obzir sve malo verovatne scenarije prekida rada. Na primer, svi regioni su međusobno izolovani, a dostupne zone su raspoređene na udaljenostima od nekoliko kilometara. Čak i ako se kabl preseče, sistem će preći na rezervne kanale, a gubici informacija biće minimalni. O principima na kojima se mreža zasniva i njenoj strukturi govoriće Vasiliy Pantiukhin.
Vasilij Pantjuhin započeo kao Unix administrator u .ru kompanijama, 6 godina se bavio velikim hardverom Sun Microsystem, 11 godina evangelizovao je datacentričnu prirodu sveta u EMC-u. Prirodno je evoluirao ka privatnim cloud rešenjima, a zatim prešao na javne. Sada, kao arhitekta Amazon Web Services, pruža tehničke savete kako da žive i razvijaju se u AWS cloudu.
U prethodnom delu trilogije o strukturi AWS-a, Vasiliy se dublje upustio u strukturu fizičkih servera i skaliranja baze podataka. Nitro kartice, prilagođeni hipervizor zasnovan na KVM-u, baza podataka Amazon Aurora — o svemu ovome piše u materijalu „“. Pročitajte da se uronite u kontekst ili pogledajte izlaganja.
U ovom delu će se govoriti o skaliranju mreže — jednom od najsloženijih sistema u AWS-u. Evolucija od ravne mreže do Virtual Private Cloud-a i njena struktura, unutrašnje usluge Blackfoot i HyperPlane, problem bučnog komšije, a na kraju — razmere mreže, backbone i fizički kablovi. O svemu ovome ispod.
Disklejmer: sve što sledi su lična mišljenja Vasiliyja i ona se možda neće poklapati sa stavovima Amazon Web Services.
Skaliranje omrežja
AWS cloud je lansiran 2006. godine. Njegova mreža je bila dovoljno primitivna — sa ravnom strukturom. Opseg privatnih adresa bio je zajednički za sve zakupce clouda. Kada biste pokrenuli novu virtuelnu mašinu, slučajno ste dobijali dostupnu IP adresu iz ovog opsega.
Ovakav pristup je bio jednostavan za implementaciju, ali je suštinski ograničavao korišćenje clouda. Konkretno, bilo je posebno teško razvijati hibridna rešenja koja su kombinovala privatne mreže na zemlji i u AWS-u. Najčešći problem bio je u preklapanju opsega IP adresa.
Virtual Private Cloud
Oblak se je izkazal za potreben. Prišel je čas, da razmislimo o razširljivosti in možnostih njegove uporabe za desetine milijonov najemnikov. Ravna omrežja so postala glavna ovira. Zato smo razmišljali, kako izolirati uporabnike drug od drugega na omrežni ravni tako, da bi lahko sami izbirali obsege IP.
Kaj vam najprej pride na misel, ko razmišljate o omrežni izolaciji? Seveda VLAN in VRF – Virtual Routing and Forwarding.
Na žalost to ni delovalo. VLAN ID je zgolj 12 bitov, kar nam daje le 4096 izoliranih segmentov. Tudi v največjih stikalu lahko uporabimo največ 1-2 tisoč VRF. Souporaba VRF in VLAN nam omogoča le nekaj milijonov podomrežij. To je zagotovo premalo za desetine milijonov najemnikov, od katerih mora imeti vsak možnost uporabe več podomrežij.
Poleg tega si preprosto ne moremo privoščiti nakupa potrebnega števila velikih naprav, na primer od Cisco ali Juniper. Dva razloga: to je noro drago in nočemo postati odvisni od njihove razvojne in popravne politike.
Eden zaključek je – skuhati svoje lastne rešitve.
Leta 2009 smo napovedali VPC — Virtual Private Cloud. Ime se je prijelo in zdaj ga uporabljajo tudi mnogi ponudniki oblakov.
VPC je virtualno omrežje SDN (Software Defined Network). Odločili smo se, da ne bomo izumljali posebnih protokolov na ravneh L2 in L3. Omrežje deluje na standardnem Ethernetu in IP. Za prenos prometa virtualnih naprav je promet enkapsuliran v ovoj našega lastnega protokola. V njem je naveden ID, ki pripada VPC najemnika.
Zveni preprosto. Vendar je treba rešiti nekaj resnih tehničnih izzivov. Na primer, kje in kako shraniti podatke o preslikavi virtualnih MAC/IP naslovov, VPC ID in ustreznih fizičnih MAC/IP. Na ravni AWS to predstavlja ogromno tabelo, ki mora delovati z minimalnimi zakasnitvami pri dostopu. Za to skrbi storitev preslikave, ki je razpršena po celotnem omrežju.
V napravah nove generacije se enkapsulacija izvaja z Nitro karticami na strojni ravni. V starejšen instancah so enkapsulacija in deenkapsulacija programski.
Poglejmo, kako to deluje v splošnem. Začnimo na ravni L2. Predpostavimo, da imamo virtualni stroj z IP 10.0.0.2 na fizičnem strežniku 192.168.0.3. Ta pošilja podatke virtualnemu stroju 10.0.0.3, ki deluje na 192.168.1.4. Oblikuje se ARP-poizvedba, ki pride na omrežno Nitro-karto. Za poenostavitev predpostavimo, da oba virtualna stroja obstajata v istem 'modrem' VPC.
Karta zamenja naslov pošiljatelja s svojim lastnim in posreduje ARP-okvir storitvi za preslikavanje.
Storitev za preslikavanje vrne informacije, ki so potrebne za prenos po fizičnem omrežju L2.
Nitro-karta v ARP-odgovoru zamenja MAC v fizičnem omrežju z naslovom v VPC.
Pri prenosu podatkov ovijemo logične MAC in IP v VPC-ovitek. Vse to prenesemo po fizičnem omrežju s pomočjo ustreznih IP Nitro-kart pošiljatelja in prejemnika.
Fizični stroj, za katerega je paket namenjen, izvede preverjanje. To je potrebno, da se prepreči možnost zamenjave naslovov. Stroj pošlje poseben poizvedbni na storitev za preslikavanje in vpraša: 'Iz fizičnega stroja 192.168.0.3 sem prejela paket, ki je namenjen 10.0.0.3 v 'modrem' VPC. Je legitimen?'
Storitev za preslikavanje preveri svojo tabelo dodeljevanja virov in omogoči ali zavrne prehod paketa. V vseh novih instancah je dodatna validacija vključena v Nitro-kartah. Te je teoretično nemogoče obiti. Zato spoofing na vire v drugem VPC ne deluje.
Nato se podatki pošljejo virtualnemu stroju, za katerega so namenjeni.
Storitev za preslikavanje deluje tudi kot logični usmerjevalnik za prenos podatkov med virtualnimi stroji v različnih podmrežah. Tam je konceptualno vse preprosto, ne bom podrobno razlagal.
Izkazalo se je, da se ob prenosu vsakega paketa strežniki obračajo na storitev za preslikavanje. Kako se boriti proti neizbežnim zamudam? Z predpomnjenjem, seveda.
Celo lepota je v tem, da ni potrebno predpomniti cele ogromne tabele. Na fizičnem strežniku živijo virtualni stroji iz razmeroma majhnega števila VPC. Predpomniti je potrebno informacije le o teh VPC. Prenos podatkov v druge VPC v 'privzeti' konfiguraciji kljub temu ni legitimen. Če se uporablja taka funkcionalnost, kot je VPC-peering, se v predpomnilnik dodatno naložijo informacije o ustreznih VPC.
S prenosom podatkov v VPC smo se že ukvarjali.
Blackfoot
Kako postupiti u slučajevima kada je potrebno prenijeti promet van, na primjer na Internet ili putem VPN-a? Tu nam pomaže Blackfoot — interna usluga AWS-a. Razvila ju je naša južnoafrička ekipa. Stoga se usluga zove po pingvinu koji živi u Južnoj Africi.
Blackfoot dekapsulira promet i čini s njim ono što treba. Podaci se šalju na Internet onakvi kakvi jesu.
Podaci se dekapsuliraju i ponovno omotavaju u IPsec omotnicu prilikom korištenja VPN-a.
Pri korištenju Direct Connect prometa se označava i proslijeđuje u odgovarajući VLAN.
HyperPlane
Ovo je interna usluga za kontrolu prometa. Mnoge mrežne usluge zahtijevaju kontrolu stanja protoka podataka. Na primjer, prilikom korištenja NAT-a, kontrola protoka mora jamčiti da svakom paru "IP: odredišni port" odgovara jedinstveni izlazni port. U slučaju balansiranja opterećenja NLB — Network Load Balancer, protok podataka uvijek mora biti usmjeren na istu ciljanju virtualnu mašinu. Security Groups su vatrozid s održavanjem stanja. Prati dolazni promet i neizravno otvara portove za izlazni protok paketa.
U AWS oblaku, zahtjevi za kašnjenjem prijenosa su izuzetno visoki. Zato HyperPlane je kritično za funkcionalnost cijele mreže.
Hyperplane je izgrađen na EC2 virtualnim mašinama. Ovdje nema nikakve magije, samo trik. Trik je u tome što su to virtualke s velikim RAM-om. Operacije su transakcijske i obavljaju se isključivo u memoriji. To omogućava kašnjenja od samo nekoliko mikrosekundi. Rad s diskom bi ubio cijelu učinkovitost.
Hyperplane je distribuirani sustav iz ogromnog broja takvih EC2 mašina. Svaka virtualka ima propusnost od 5 GB/s. Na razini cijele regionalne mreže to omogućava nevjerojatne terabite propusnosti i omogućava obradu milijuna veza u sekundi..
HyperPlane radi samo s tokovima. VPC inkapsulacija paketa za njega je potpuno prozirna. Potencijalna ranjivost u ovoj internoj usluzi i dalje ne bi dozvolila probijanje VPC izolacije. Sigurnost pokrivaju niži slojevi.
Noisy neighbor
Postoji još jedan problem šumnog susjeda — noisy neighbor. Predpostavimo da imamo 8 nodov. Ti nodi obdelujejo tokove vseh uporabnikov v oblak. Zdi se, da je vse v redu in obremenitev bi se morala enakomerno razporediti med vse nodi. Nodi so zelo zmogljivi in jih je težko preobremeniti.
Toda mi gradimo svojo arhitekturo, upoštevajoč celo nepričakovane scenarije.
Nizka verjetnost ne pomeni nemogoče.
Lahko si predstavljamo situacijo, v kateri bo en ali več uporabnikov generiralo preveliko obremenitev. V obdelavo te obremenitve so vključeni vsi nodi HyperPlane in drugi uporabniki lahko potencialno občutijo določeno znižanje zmogljivosti. To ruši koncept oblaka, v katerem nimajo najemniki možnosti, da vplivajo drug na drugega.
Kako rešiti problem hrupnega soseda? Prvo, kar pride na pamet – sharding. Naših 8 nod je logično razdeljenih na 4 sharde po 2 nodi v vsakem. Zdaj bo hrupni sosed motil le četrtino vseh uporabnikov, toda močno.
Poglejmo drugače. Vsakemu uporabniku bomo namenili po 3 nodi.
Trik je v tem, da dodelimo nodi različnim uporabnikom naključno. Na sliki spodaj se modri uporabnik prekriva z eno od dveh drugih uporabnikov – zelenim in oranžnim.
Pri 8 nodah in 3 uporabnikih je verjetnost prekrivanja hrupnega soseda z enim od uporabnikov 54%. Prav s to verjetnostjo bo modri uporabnik vplival na druge najemnike. Pri tem samo z delom svoje obremenitve. V našem primeru bo ta vpliv opazen le delno, in sicer le pri tretjini vseh uporabnikov. To je že precejšen rezultat.
Število uporabnikov, ki se bodo prekrili
Verjetnost v odstotkih
0
18%
1
54%
2
26%
3
2%
Približajmo situacijo realnosti – vzemimo 100 nod in 5 uporabnikov na 5 nodah. V tem primeru se nobena izmed nod ne bo prekrila z verjetnostjo 77%.
Število uporabnikov, ki se bodo prekrili
Verjetnost v odstotkih
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
V realni situaciji, pri ogromnem številu HyperPlane nod in uporabnikov, je potencialni vpliv hrupnega soseda na druge uporabnike minimalen. Ta metoda se imenuje mešano sharding — shuffle sharding. Minimalizira negativni učinek izpada nod.
Na podlagi HyperPlane je zgrajenih mnogo storitev: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Obsegi omrežja
Sedaj se bomo pogovorili o razsežnostih same mreže. Do oktobra 2019 AWS ponuja svoje storitve v 22 regijah, devet pa jih je še načrtovanih.
- Vsaka regija vsebuje več razpoložljivostnih con - Availability Zone. Skupaj jih je po svetu 69.
- Vsaka AZ sestavlja več podatkovnih centrov. Največ jih je 8.
- V podatkovnih centrih je nameščen ogromno število strežnikov, v nekaterih do 300.000.
Sedaj vse to povprečimo, pomnožimo in dobimo impresivno številko, ki prikazuje razsežnost oblaka Amazon..
Med razpoložljivostnimi conami in podatkovnimi centri je nameščenih veliko optičnih kanalov. V eni največjih naših regij je za povezovanje AZ med seboj in komunikacijskimi centri z drugimi regijami (Transit Centers) nameščenih 388 kanalov. To skupaj predstavlja noro 5000 Tbps..
Backbone AWS je zgrajen posebej za oblak in optimiziran za njegovo delovanje. Zgrajen je na kanalih 100 Gb/s.Ti kanali so v naši popolni kontroli, razen v regijah na Kitajskem. Promet se ne deli z obremenitvami drugih podjetij.
Seveda nismo edini ponudnik oblačnih storitev s svojo zasebno backbone mrežo. Vse več večjih podjetij se odloča za to pot. To potrjujejo neodvisni raziskovalci, na primer, od .
Na grafu je razvidno, da delež ponudnikov vsebin in oblačnih ponudnikov narašča. Zaradi tega delež Internet prometa ponudnikov backbone nenehno upada.
Pojasnil bom, zakaj se to dogaja. V preteklosti so bili večinoma spletni servisi dostopni in uporabljani neposredno iz Interneta. Danes je vse več strežnikov nameščenih v oblaku in dostopnih preko CDN — Content Distribution Network.Za dostop do vira uporabnik prehaja skozi Internet le do najbližjega CDN PoP - Point of Presence.Najpogosteje se to nahaja nekje v bližini. Potem zapusti javni Internet in po zasebni backbone leti čez Atlantik ter se neposredno poveže z virom.
Zanimivo, kako se bo Internet spremenil čez 10 let, če se bo ta trend nadaljeval?
Fizični kanali
Znanstveniki še niso našli načina, kako povečati hitrost svetlobe v vesolju, so pa močno napredovali pri metodah prenašanja po optičnih vlaknih. Trenutno uporabljamo kable s 6912 vlakni. To pomaga znatno optimizirati stroške njihovega polaganja.
V nekaterih regijah smo primorani uporabiti posebne kable. Na primer, v regiji Sydney uporabljamo kable s posebnim premazom proti termitom.
Nihče ni imun na težave, zato so včasih naši kanali poškodovani. Na sliki desno so optični kabli v eni izmed ameriških regij, ki so jih raztrgali gradbeniki. Zaradi nesreče je bilo izgubljenih le 13 paketov podatkov, kar je presenetljivo. Še enkrat – le 13! Sistem se je dobesedno takoj preklopil na rezervne kanale - obseg deluje.
Na hitro smo preleteli nekatere storitve in tehnologije oblaka Amazon. Upam, da imate zdaj vsaj osnovno predstavo o obsegu nalog, s katerimi se soočajo naši inženirji. Osebno me to zelo privlači.
To je zadnji del trilogije Vasilyja Pantyukhina o strukturi AWS. V delu so opisane optimizacije strežnikov in skaliranje podatkovnih baz, v – pa strežniške funkcije in Firecracker.
Na Novembra bo Vasily Pantyukhin delil nove podrobnosti o strukturi Amazona. On o razlogih za napake in načrtovanju distribucijskih sistemov v Amazonu. Do 24. oktobra je še mogoče kupiti karto po ugodni ceni, plačate pa kasneje. Čakamo vas na HighLoad++, pridite - pogovorimo se!
Izvor: habr.com
