Rozsah siete Amazon Web Services je 69 zón po celom svete v 22 regiónoch: USA, Európa, Ázia, Afrika a Austrália. Každá zóna obsahuje až 8 dátových centier – Data Processing Centers. Každé dátové centrum má tisíce alebo stovky tisíc serverov. Sieť je navrhnutá tak, aby sa zohľadnili všetky nepravdepodobné scenáre výpadkov. Napríklad všetky regióny sú od seba izolované a zóny dostupnosti sú oddelené na vzdialenosti niekoľkých kilometrov. Aj keď prestrihnete kábel, systém sa prepne na záložné kanály a strata informácií bude predstavovať niekoľko dátových paketov. Vasily Pantyukhin bude hovoriť o tom, na akých ďalších princípoch je sieť postavená a ako je štruktúrovaná.
Vasilij Pantyukhin začínal ako správca Unixu v spoločnostiach .ru, 6 rokov pracoval na veľkom hardvéri Sun Microsystem a 11 rokov v EMC kázal dátovo-centrický svet. Prirodzene sa vyvinul do súkromných cloudov, potom sa presunul do verejných. Teraz ako architekt Amazon Web Services poskytuje technické poradenstvo, ktoré pomáha žiť a rozvíjať sa v cloude AWS.
V predchádzajúcej časti trilógie AWS sa Vasily ponoril do dizajnu fyzických serverov a škálovania databáz. Nitro karty, vlastný hypervízor založený na KVM, databáza Amazon Aurora – o tom všetkom v materiáli “" Prečítajte si kontext alebo sledujte prejavy.
Táto časť sa zameria na škálovanie siete, jeden z najkomplexnejších systémov v AWS. Evolúcia od plochej siete k virtuálnemu privátnemu cloudu a jeho dizajnu, interné služby Blackfoot a HyperPlane, problém hlučného suseda a na konci - rozsah siete, chrbtica a fyzické káble. O tom všetkom pod rezom.
Vyhlásenie: všetko nižšie je Vasilyho osobný názor a nemusí sa zhodovať s pozíciou Amazon Web Services.
Škálovanie siete
Cloud AWS bol spustený v roku 2006. Jeho sieť bola dosť primitívna – s plochou štruktúrou. Rozsah súkromných adries bol spoločný pre všetkých cloudových nájomcov. Pri spustení nového virtuálneho počítača ste omylom dostali dostupnú IP adresu z tohto rozsahu.
Tento prístup bol ľahko implementovateľný, no zásadne obmedzoval využitie cloudu. Najmä bolo dosť ťažké vyvinúť hybridné riešenia, ktoré by kombinovali privátne siete na zemi a v AWS. Najčastejším problémom boli prekrývajúce sa rozsahy IP adries.
Virtuálny súkromný cloud
Ukázalo sa, že cloud je žiadaný. Nastal čas zamyslieť sa nad škálovateľnosťou a možnosťou jej využitia desiatkami miliónov nájomníkov. Veľkou prekážkou sa stala plochá sieť. Preto sme premýšľali o tom, ako izolovať používateľov od seba na úrovni siete, aby si mohli nezávisle vybrať rozsahy IP.
Čo vám ako prvé napadne, keď sa zamyslíte nad izoláciou siete? určite VLAN и VRF - Virtuálne smerovanie a preposielanie.
Žiaľ, nepodarilo sa. VLAN ID má iba 12 bitov, čo nám dáva iba 4096 izolovaných segmentov. Aj tie najväčšie prepínače môžu využívať maximálne 1-2 tisíc VRF. Spoločné používanie VRF a VLAN nám dáva len niekoľko miliónov podsietí. To rozhodne nestačí pre desiatky miliónov nájomníkov, z ktorých každý musí mať možnosť využívať viacero podsietí.
Taktiež si jednoducho nemôžeme dovoliť kúpiť potrebný počet veľkých krabíc napríklad od Cisco alebo Juniper. Existujú dva dôvody: je to šialene drahé a my nechceme byť vydaní na milosť a nemilosť ich politikám vývoja a záplatovania.
Existuje len jeden záver - urobte si vlastné riešenie.
V roku 2009 sme oznámili VPC - Virtuálny súkromný cloud. Názov sa zasekol a teraz ho používa aj veľa poskytovateľov cloudu.
VPC je virtuálna sieť SDN (Softvérom definovaná sieť). Rozhodli sme sa nevymýšľať špeciálne protokoly na úrovni L2 a L3. Sieť beží na štandardnom Ethernete a IP. Pre prenos cez sieť je prevádzka virtuálneho stroja zapuzdrená v našom vlastnom obale protokolu. Označuje ID, ktoré patrí k VPC nájomcu.
Znie to jednoducho. Existuje však niekoľko vážnych technických problémov, ktoré je potrebné prekonať. Napríklad, kde a ako ukladať údaje o mapovaní virtuálnych MAC/IP adries, VPC ID a zodpovedajúcej fyzickej MAC/IP. V meradle AWS ide o obrovskú tabuľku, ktorá by mala fungovať s minimálnym oneskorením prístupu. Zodpovedný za to mapovacia služba, ktorý je rozprestretý v tenkej vrstve po celej sieti.
V strojoch novej generácie je zapuzdrenie vykonávané kartami Nitro na hardvérovej úrovni. V starších prípadoch je zapuzdrenie a dekapsulácia založené na softvéri.
Poďme zistiť, ako to funguje vo všeobecnosti. Začnime úrovňou L2. Predpokladajme, že máme virtuálny stroj s IP 10.0.0.2 na fyzickom serveri 192.168.0.3. Posiela dáta do virtuálneho stroja 10.0.0.3, ktorý žije na 192.168.1.4. Vygeneruje sa požiadavka ARP a odošle sa na sieťovú kartu Nitro. Pre jednoduchosť predpokladáme, že oba virtuálne stroje žijú v rovnakom „modrom“ VPC.
Mapa nahradí zdrojovú adresu svojou vlastnou a prepošle rámec ARP mapovacej službe.
Mapovacia služba vracia informácie, ktoré sú potrebné na prenos cez fyzickú sieť L2.
Karta Nitro v odpovedi ARP nahrádza MAC vo fyzickej sieti adresou vo VPC.
Pri prenose dát zabalíme logickú MAC a IP do VPC wrapperu. To všetko prenášame po fyzickej sieti pomocou vhodných zdrojových a cieľových IP Nitro kariet.
Fyzický stroj, ktorému je balík určený, vykoná kontrolu. Je to potrebné, aby sa predišlo možnosti falšovania adresy. Stroj odošle mapovacej službe špeciálnu požiadavku a spýta sa: „Z fyzického stroja 192.168.0.3 som dostal paket, ktorý je určený pre 10.0.0.3 v modrom VPC. Je legitímny?
Mapovacia služba skontroluje svoju tabuľku prideľovania zdrojov a povolí alebo zakáže prechod paketu. Vo všetkých nových prípadoch je do Nitro kariet zabudovaná ďalšia validácia. Nedá sa to obísť ani teoreticky. Spoofing zdrojov v inom VPC preto nebude fungovať.
Potom sa údaje odošlú na virtuálny počítač, pre ktorý sú určené.
Mapovacia služba funguje aj ako logický smerovač na prenos údajov medzi virtuálnymi strojmi v rôznych podsieťach. Všetko je koncepčne jednoduché, nebudem zachádzať do detailov.
Ukazuje sa, že pri prenose každého paketu sa servery obrátia na mapovaciu službu. Ako sa vysporiadať s nevyhnutným oneskorením? Ukladanie do vyrovnávacej pamäte, samozrejme.
Krása je v tom, že nemusíte ukladať do vyrovnávacej pamäte celý obrovský stôl. Fyzický server hostí virtuálne stroje z relatívne malého počtu VPC. Do vyrovnávacej pamäte potrebujete iba uložiť informácie o týchto VPC. Prenos údajov do iných VPC v „predvolenej“ konfigurácii stále nie je legitímny. Ak sa použije funkcia, ako je VPC-peering, informácie o zodpovedajúcich VPC sa dodatočne načítajú do vyrovnávacej pamäte.
Vyriešili sme prenos dát do VPC.
blackfoot
Čo robiť v prípadoch, keď je potrebné prenášať prevádzku von, napríklad na internet alebo cez VPN do zeme? Pomáha nám tu blackfoot — Interná služba AWS. Je vyvinutý naším juhoafrickým tímom. Aj preto je služba pomenovaná po tučniakovi, ktorý žije v Južnej Afrike.
Blackfoot dekapsuluje premávku a robí s ňou, čo je potrebné. Dáta sa odosielajú na internet tak, ako sú.
Pri použití VPN sa údaje dekapsulujú a znova zabalia do protokolu IPsec.
Pri použití priameho pripojenia sa prevádzka označí a odošle do príslušnej siete VLAN.
HyperPlane
Toto je interná služba riadenia toku. Mnohé sieťové služby vyžadujú monitorovanie stavy dátového toku. Napríklad pri použití NAT musí riadenie toku zabezpečiť, aby každý pár IP:cieľový port mal jedinečný odchádzajúci port. V prípade balancéra NLB - Nástroj na vyrovnávanie zaťaženia siete, tok údajov by mal byť vždy smerovaný na rovnaký cieľový virtuálny stroj. Security Groups je stavová brána firewall. Monitoruje prichádzajúcu prevádzku a implicitne otvára porty pre odchádzajúce pakety.
V cloude AWS sú požiadavky na latenciu prenosu extrémne vysoké. Preto HyperPlane rozhodujúce pre výkon celej siete.
Hyperplane je postavený na virtuálnych strojoch EC2. Nie je tu žiadna mágia, iba prefíkanosť. Trik je v tom, že ide o virtuálne stroje s veľkou RAM. Operácie sú transakčné a vykonávajú sa výlučne v pamäti. To vám umožní dosiahnuť oneskorenia iba v desiatkach mikrosekúnd. Práca s diskom by zabila všetku produktivitu.
Hyperplane je distribuovaný systém obrovského množstva takýchto strojov EC2. Každý virtuálny stroj má šírku pásma 5 GB/s. V celej regionálnej sieti to poskytuje neuveriteľné terabity šírky pásma a umožňuje spracovanie milióny pripojení za sekundu.
HyperPlane funguje iba so streammi. Zapuzdrenie paketov VPC je preň úplne transparentné. Potenciálna zraniteľnosť v tejto internej službe by stále bránila narušeniu izolácie VPC. Nižšie uvedené úrovne sú zodpovedné za bezpečnosť.
Hlučný sused
Stále je tu problém hlučný sused - hlučný sused. Predpokladajme, že máme 8 uzlov. Tieto uzly spracúvajú toky všetkých používateľov cloudu. Zdá sa, že všetko je v poriadku a zaťaženie by malo byť rovnomerne rozdelené medzi všetky uzly. Uzly sú veľmi výkonné a je ťažké ich preťažiť.
Ale budujeme našu architektúru na základe aj nepravdepodobných scenárov.
Nízka pravdepodobnosť neznamená nemožné.
Vieme si predstaviť situáciu, v ktorej by jeden alebo viacerí používatelia generovali príliš veľkú záťaž. Všetky uzly HyperPlane sú zapojené do spracovania tejto záťaže a iní používatelia môžu potenciálne zaznamenať nejaký zásah do výkonu. Tým sa narúša koncept cloudu, v ktorom nájomníci nemajú možnosť sa navzájom ovplyvňovať.
Ako vyriešiť problém hlučného suseda? Prvá vec, ktorá vás napadne, je sharding. Našich 8 uzlov je logicky rozdelených na 4 časti po 2 uzloch. Hlučný sused teraz vyruší len štvrtinu všetkých užívateľov, no bude ich rušiť značne.
Robme veci inak. Každému používateľovi pridelíme iba 3 uzly.
Trik je v náhodnom prideľovaní uzlov rôznym používateľom. Na obrázku nižšie modrý používateľ pretína uzly s jedným z ďalších dvoch používateľov – zeleným a oranžovým.
Pri 8 uzloch a 3 užívateľoch je pravdepodobnosť, že sa hlučný sused pretne s jedným z užívateľov, 54%. S touto pravdepodobnosťou bude modrý užívateľ ovplyvňovať ostatných nájomníkov. Zároveň len časť jeho nákladu. V našom príklade bude tento vplyv aspoň nejakým spôsobom viditeľný nie pre každého, ale iba pre tretinu všetkých používateľov. To už je dobrý výsledok.
Počet používateľov, ktorí sa budú pretínať
Pravdepodobnosť v percentách
0
18%
1
54%
2
26%
3
2%
Priblížme situáciu realite – zoberme si 100 uzlov a 5 používateľov na 5 uzloch. V tomto prípade sa žiadny z uzlov nepretína s pravdepodobnosťou 77%.
Počet používateľov, ktorí sa budú pretínať
Pravdepodobnosť v percentách
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
V reálnej situácii s obrovským počtom uzlov a používateľov HyperPlane je potenciálny vplyv hlučného suseda na ostatných používateľov minimálny. Táto metóda sa nazýva miešanie strúhanie - shuffle sharding. Minimalizuje negatívny vplyv zlyhania uzla.
Mnohé služby sú postavené na báze HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Sieťová mierka
Teraz si povedzme o rozsahu samotnej siete. Od októbra 2019 AWS ponúka svoje služby v 22 krajova 9 ďalších je plánovaných.
- Každý región obsahuje niekoľko zón dostupnosti. Na celom svete ich je 69.
- Každý AZ pozostáva z centier spracovania údajov. Celkovo ich nie je viac ako 8.
- V dátovom centre sa nachádza obrovské množstvo serverov, niektoré majú až 300 000.
Teraz to všetko spriemerujme, vynásobme a získame pôsobivé číslo, ktoré odráža Cloudová škála Amazon.
Medzi zónami dostupnosti a dátovým centrom je veľa optických prepojení. V jednom z našich najväčších regiónov je vybudovaných 388 kanálov len pre AZ komunikáciu medzi sebou a komunikačnými centrami s ostatnými regiónmi (Centrá tranzitu). Celkovo to dáva šialené 5000 Tbit.
Chrbtica AWS je vytvorená špeciálne a optimalizovaná pre cloud. Staviame to na kanáloch 100 GB / s. Kontrolujeme ich úplne, s výnimkou regiónov v Číne. Premávka nie je zdieľaná s nákladmi iných spoločností.
Samozrejme, nie sme jediným poskytovateľom cloudu s privátnou chrbticovou sieťou. Touto cestou sa vydáva stále viac veľkých spoločností. Potvrdzujú to nezávislí výskumníci, napríklad z .
Z grafu vyplýva, že podiel poskytovateľov obsahu a poskytovateľov cloudu rastie. Z tohto dôvodu neustále klesá podiel internetovej prevádzky chrbticových poskytovateľov.
Vysvetlím, prečo sa to deje. Predtým bola väčšina webových služieb dostupná a využívaná priamo z internetu. V súčasnosti sa čoraz viac serverov nachádza v cloude a sú prístupné cez CDN - Distribučná sieť obsahu. Na prístup k zdroju sa používateľ dostane cez internet iba k najbližšiemu CDN PoP - Prítomný bod. Najčastejšie je to niekde nablízku. Potom opustí verejný internet a preletí súkromnou chrbticou napríklad cez Atlantik a dostane sa priamo k zdroju.
Zaujímalo by ma, ako sa internet zmení o 10 rokov, ak bude tento trend pokračovať?
Fyzické kanály
Vedci ešte neprišli na to, ako zvýšiť rýchlosť svetla vo vesmíre, ale urobili veľký pokrok v metódach prenosu cez optické vlákno. V súčasnosti používame 6912 optických káblov. To pomáha výrazne optimalizovať náklady na ich inštaláciu.
V niektorých regiónoch musíme použiť špeciálne káble. Napríklad v regióne Sydney používame káble so špeciálnym náterom proti termitom.
Nikto nie je imúnny voči problémom a naše kanály sa niekedy poškodia. Fotografia vpravo ukazuje optické káble v jednom z amerických regiónov, ktoré roztrhali stavební robotníci. V dôsledku nehody sa stratilo iba 13 dátových paketov, čo je prekvapujúce. Ešte raz - len 13! Systém sa doslova okamžite prepol na záložné kanály - váha funguje.
Cválali sme cez niektoré cloudové služby a technológie Amazonu. Dúfam, že máte aspoň nejakú predstavu o rozsahu úloh, ktoré musia naši inžinieri vyriešiť. Osobne to považujem za veľmi vzrušujúce.
Toto je záverečná časť trilógie od Vasilija Pantyukhina o zariadení AWS. IN časti popisujú optimalizáciu servera a škálovanie databázy a v — funkcie bez servera a Firecracker.
Na v novembri sa Vasily Pantyukhin podelí o nové podrobnosti o zariadení Amazon. On o príčinách porúch a návrhu distribuovaných systémov v Amazone. 24. október je ešte možný lístok za dobrú cenu a zaplaťte neskôr. Čakáme na vás v HighLoad++, príďte si pokecať!
Zdroj: hab.com