Rozsah sítě Amazon Web Services je 69 zón po celém světě ve 22 regionech: USA, Evropa, Asie, Afrika a Austrálie. Každá zóna obsahuje až 8 datových center - Data Processing Centers. Každé datové centrum má tisíce nebo stovky tisíc serverů. Síť je navržena tak, aby byly brány v úvahu všechny nepravděpodobné scénáře výpadku. Například všechny regiony jsou od sebe izolovány a zóny dostupnosti jsou odděleny na vzdálenosti několika kilometrů. I když přestřihnete kabel, systém se přepne na záložní kanály a ztráta informací se rovná několika datovým paketům. Vasily Pantyukhin bude hovořit o tom, na jakých dalších principech je síť postavena a jak je strukturována.
Vasilij Pantyukhin začínal jako unixový administrátor ve společnostech .ru, 6 let pracoval na velkém hardwaru Sun Microsystem a 11 let kázal ve společnosti EMC data-centrický svět. Přirozeně se vyvinul do privátních cloudů, poté se přesunul do veřejných. Nyní jako architekt Amazon Web Services poskytuje technické poradenství, které pomáhá žít a rozvíjet se v cloudu AWS.
V předchozí části trilogie AWS se Vasily ponořil do návrhu fyzických serverů a škálování databází. Nitro karty, vlastní hypervizor založený na KVM, databáze Amazon Aurora – o tom všem v materiálu “" Přečtěte si kontext nebo sledujte projevy.
Tato část se zaměří na síťové škálování, jeden z nejsložitějších systémů v AWS. Evoluce od ploché sítě k virtuálnímu privátnímu cloudu a jeho designu, interní služby Blackfoot a HyperPlane, problém hlučného souseda a na konci - rozsah sítě, páteře a fyzických kabelů. O tom všem pod řezem.
Zřeknutí se odpovědnosti: vše níže je Vasilyho osobní názor a nemusí se shodovat s pozicí Amazon Web Services.
Škálování sítě
Cloud AWS byl spuštěn v roce 2006. Jeho síť byla docela primitivní – s plochou strukturou. Rozsah privátních adres byl společný pro všechny cloudové nájemce. Při spouštění nového virtuálního počítače jste omylem obdrželi dostupnou IP adresu z tohoto rozsahu.
Tento přístup byl snadno implementovatelný, ale zásadně omezoval využití cloudu. Zejména bylo poměrně obtížné vyvinout hybridní řešení, která by kombinovala privátní sítě na zemi a v AWS. Nejčastějším problémem byly překrývající se rozsahy IP adres.
Virtuální privátní cloud
Ukázalo se, že cloud je žádaný. Nastal čas zamyslet se nad škálovatelností a možností jejího využití desítkami milionů nájemců. Velkou překážkou se stala plochá síť. Proto jsme přemýšleli, jak od sebe izolovat uživatele na úrovni sítě, aby si mohli nezávisle volit rozsahy IP.
Co vás jako první napadne, když přemýšlíte o izolaci sítě? Rozhodně VLAN и VRF - Virtuální směrování a přeposílání.
Bohužel to nevyšlo. VLAN ID je pouze 12 bitů, což nám dává pouze 4096 izolovaných segmentů. I ty největší přepínače mohou využívat maximálně 1-2 tisíce VRF. Společné používání VRF a VLAN nám poskytuje pouze několik milionů podsítí. To rozhodně nestačí pro desítky milionů nájemců, z nichž každý musí umět využívat více podsítí.
Také si prostě nemůžeme dovolit koupit potřebný počet velkých krabic např. od Cisco nebo Juniper. Existují dva důvody: je to šíleně drahé a my nechceme být vydáni na milost a nemilost jejich politikám vývoje a záplatování.
Existuje pouze jeden závěr - udělejte si vlastní řešení.
V roce 2009 jsme oznámili VPC - Virtuální privátní cloud. Název uvízl a nyní jej používá i mnoho poskytovatelů cloudu.
VPC je virtuální síť SDN (Softwarově definovaná síť). Rozhodli jsme se nevymýšlet speciální protokoly na úrovni L2 a L3. Síť běží na standardním Ethernetu a IP. Pro přenos po síti je provoz virtuálního stroje zapouzdřen do našeho vlastního protokolu wrapper. Označuje ID, které patří k VPC nájemce.
Zní to jednoduše. Existuje však několik vážných technických problémů, které je třeba překonat. Například, kde a jak ukládat data o mapování virtuálních MAC/IP adres, VPC ID a odpovídající fyzické MAC/IP. V měřítku AWS se jedná o obrovskou tabulku, která by měla fungovat s minimálním zpožděním přístupu. Zodpovědný za to mapová služba, který je rozprostřen v tenké vrstvě po celé síti.
U strojů nové generace je zapouzdření prováděno pomocí Nitro karet na hardwarové úrovni. Ve starších případech je zapouzdření a dekapsulace založeno na softwaru.
Pojďme zjistit, jak to funguje obecně. Začněme úrovní L2. Předpokládejme, že máme virtuální stroj s IP 10.0.0.2 na fyzickém serveru 192.168.0.3. Odesílá data na virtuální stroj 10.0.0.3, který žije na 192.168.1.4. Je vygenerován požadavek ARP a odeslán na síťovou kartu Nitro. Pro jednoduchost předpokládáme, že oba virtuální stroje žijí ve stejném „modrém“ VPC.
Mapa nahradí zdrojovou adresu svou vlastní a předá rámec ARP mapovací službě.
Mapovací služba vrací informace, které jsou nezbytné pro přenos přes fyzickou síť L2.
Karta Nitro v odpovědi ARP nahradí MAC ve fyzické síti adresou ve VPC.
Při přenosu dat zabalíme logickou MAC a IP do VPC wrapperu. To vše přenášíme po fyzické síti pomocí příslušných zdrojových a cílových IP Nitro karet.
Fyzický stroj, kterému je balíček určen, provádí kontrolu. To je nezbytné, aby se zabránilo možnosti podvržení adresy. Stroj odešle speciální požadavek na mapovací službu a zeptá se: „Z fyzického stroje 192.168.0.3 jsem obdržel paket, který je určen pro 10.0.0.3 v modrém VPC. Je legitimní?
Mapovací služba zkontroluje svou tabulku přidělení zdrojů a povolí nebo zakáže průchod paketu. Ve všech nových případech je do Nitro karet zabudována další validace. Nedá se to obejít ani teoreticky. Spoofing zdrojů v jiném VPC proto nebude fungovat.
Dále jsou data odeslána na virtuální počítač, pro který jsou určena.
Mapovací služba funguje také jako logický router pro přenos dat mezi virtuálními stroji v různých podsítích. Vše je koncepčně jednoduché, nebudu zabíhat do detailů.
Ukázalo se, že při přenosu každého paketu se servery obracejí na mapovací službu. Jak se vypořádat s nevyhnutelným zpožděním? Ukládání do mezipaměti, samozřejmě.
Krása je v tom, že nemusíte ukládat do mezipaměti celý obrovský stůl. Fyzický server hostí virtuální stroje z relativně malého počtu VPC. Potřebujete pouze ukládat do mezipaměti informace o těchto VPC. Přenos dat na jiné VPC ve „výchozí“ konfiguraci stále není legitimní. Pokud se použije funkce, jako je VPC-peering, pak se informace o odpovídajících VPC dodatečně načtou do mezipaměti.
Vyřešili jsme přenos dat do VPC.
Blackfoot
Co dělat v případech, kdy je potřeba provoz přenášet ven, například na internet nebo přes VPN do země? Pomáhá nám tady Blackfoot — Interní služba AWS. Je vyvinut naším jihoafrickým týmem. Proto je služba pojmenována po tučňákovi, který žije v Jižní Africe.
Blackfoot dekapsuluje provoz a dělá s ním, co je potřeba. Data jsou odesílána do Internetu tak, jak jsou.
Při použití VPN jsou data dekapsulována a znovu zabalena do protokolu IPsec.
Při použití Direct Connect je provoz označen a odeslán do příslušné VLAN.
HyperPlane
Toto je služba interního řízení toku. Mnoho síťových služeb vyžaduje monitorování stavy datových toků. Například při použití NAT musí řízení toku zajistit, aby každý pár IP:cílový port měl jedinečný odchozí port. V případě balanceru NLB - Network Load Balancer, datový tok by měl vždy směřovat na stejný cílový virtuální stroj. Security Groups je stavový firewall. Monitoruje příchozí provoz a implicitně otevírá porty pro tok odchozích paketů.
V cloudu AWS jsou požadavky na latenci přenosu extrémně vysoké. Proto HyperPlane kritické pro výkon celé sítě.
Hyperplane je postaven na virtuálních strojích EC2. Není zde žádná magie, pouze mazanost. Trik je v tom, že se jedná o virtuální stroje s velkou RAM. Operace jsou transakční a provádějí se výhradně v paměti. To umožňuje dosáhnout zpoždění pouhých desítek mikrosekund. Práce s diskem by zabila veškerou produktivitu.
Hyperplane je distribuovaný systém velkého množství takových strojů EC2. Každý virtuální stroj má šířku pásma 5 GB/s. V celé regionální síti to poskytuje neuvěřitelné terabity šířky pásma a umožňuje zpracování miliony připojení za sekundu.
HyperPlane funguje pouze se streamy. Zapouzdření paketů VPC je pro něj zcela transparentní. Potenciální chyba zabezpečení v této interní službě by stále bránila prolomení izolace VPC. Za bezpečnost jsou zodpovědné níže uvedené úrovně.
Hlučný soused
Stále je tu problém hlučný soused - hlučný soused. Předpokládejme, že máme 8 uzlů. Tyto uzly zpracovávají toky všech uživatelů cloudu. Vše se zdá být v pořádku a zátěž by měla být rovnoměrně rozložena mezi všechny uzly. Uzly jsou velmi výkonné a je obtížné je přetížit.
Ale budujeme naši architekturu na základě i nepravděpodobných scénářů.
Nízká pravděpodobnost neznamená nemožné.
Dokážeme si představit situaci, kdy by jeden nebo více uživatelů generovalo příliš velké zatížení. Všechny uzly HyperPlane se podílejí na zpracování této zátěže a ostatní uživatelé mohou potenciálně zaznamenat nějaký druh zásahu do výkonu. Tím se nabourává koncept cloudu, ve kterém nájemci nemají možnost se navzájem ovlivňovat.
Jak vyřešit problém hlučného souseda? První, co mě napadne, je sharding. Našich 8 uzlů je logicky rozděleno na 4 fragmenty po 2 uzlech. Nyní bude hlučný soused rušit jen čtvrtinu všech uživatelů, ale bude je rušit velmi.
Dělejme věci jinak. Každému uživateli přidělíme pouze 3 uzly.
Trik je v náhodném přidělování uzlů různým uživatelům. Na obrázku níže modrý uživatel protíná uzly s jedním z dalších dvou uživatelů – zeleným a oranžovým.
S 8 uzly a 3 uživateli je pravděpodobnost, že se hlučný soused protne s jedním z uživatelů, 54 %. S touto pravděpodobností bude modrý uživatel ovlivňovat ostatní nájemníky. Přitom jen část jeho nákladu. V našem příkladu bude tento vliv alespoň nějak patrný ne všem, ale pouze třetině všech uživatelů. To už je dobrý výsledek.
Počet uživatelů, kteří se budou protínat
Pravděpodobnost v procentech
0
18%
1
54%
2
26%
3
2%
Pojďme situaci přiblížit realitě – vezměme 100 uzlů a 5 uživatelů na 5 uzlech. V tomto případě se žádný z uzlů neprotne s pravděpodobností 77 %.
Počet uživatelů, kteří se budou protínat
Pravděpodobnost v procentech
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
V reálné situaci s obrovským počtem uzlů a uživatelů HyperPlane je potenciální dopad hlučného souseda na ostatní uživatele minimální. Tato metoda se nazývá míchání stříhání - shuffle sharding. Minimalizuje negativní vliv selhání uzlu.
Mnoho služeb je postaveno na základě HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Síťové měřítko
Nyní si povíme něco o rozsahu samotné sítě. Od října 2019 nabízí AWS své služby v 22 regionůa 9 dalších je plánováno.
- Každá oblast obsahuje několik zón dostupnosti. Po celém světě jich je 69.
- Každý AZ se skládá z center zpracování dat. Celkem jich není více než 8.
- V datovém centru je umístěno obrovské množství serverů, některé mají až 300 000.
Nyní to vše zprůměrujme, vynásobíme a získáme působivé číslo, které odráží Cloudová škála Amazon.
Mezi zónami dostupnosti a datovým centrem existuje mnoho optických spojení. V jednom z našich největších regionů je vytyčeno 388 kanálů jen pro komunikaci AZ mezi sebou a komunikačními centry s ostatními kraji (Tranzitní centra). Celkově to dává šílené 5000 Tbit.
Páteřní AWS je vytvořeno speciálně pro cloud a optimalizováno pro něj. Stavíme to na kanálech 100 GB / s. Kontrolujeme je kompletně, s výjimkou regionů v Číně. Provoz není sdílen se zátěží jiných společností.
Nejsme samozřejmě jediným poskytovatelem cloudu s privátní páteřní sítí. Touto cestou se vydává stále více velkých společností. Potvrzují to nezávislí výzkumníci, např. z .
Z grafu je patrné, že podíl poskytovatelů obsahu a poskytovatelů cloudu roste. Z tohoto důvodu se podíl internetového provozu páteřních poskytovatelů neustále snižuje.
Vysvětlím, proč se to děje. Dříve byla většina webových služeb přístupná a využívaná přímo z internetu. V dnešní době je stále více serverů umístěno v cloudu a jsou přístupné přes CDN - Distribuční síť obsahu. Pro přístup ke zdroji se uživatel dostane přes internet pouze k nejbližšímu CDN PoP - Místo přítomnosti. Nejčastěji je to někde poblíž. Poté opustí veřejný internet a proletí soukromou páteří například přes Atlantik a dostane se přímo ke zdroji.
Zajímalo by mě, jak se změní internet za 10 let, pokud bude tento trend pokračovat?
Fyzické kanály
Vědci zatím nepřišli na to, jak zvýšit rychlost světla ve Vesmíru, ale udělali velký pokrok v metodách přenosu přes optické vlákno. V současné době používáme 6912 optických kabelů. To pomáhá výrazně optimalizovat náklady na jejich instalaci.
V některých regionech musíme použít speciální kabely. Například v regionu Sydney používáme kabely se speciálním povlakem proti termitům.
Nikdo není imunní vůči problémům a někdy se naše kanály poškodí. Na fotografii vpravo jsou optické kabely v jednom z amerických regionů, které přetrhli stavební dělníci. V důsledku nehody bylo ztraceno pouze 13 datových paketů, což je překvapivé. Ještě jednou - pouze 13! Systém se doslova okamžitě přepnul na záložní kanály - váha funguje.
Cválali jsme některými cloudovými službami a technologiemi Amazonu. Doufám, že máte alespoň nějakou představu o rozsahu úkolů, které musí naši inženýři vyřešit. Osobně to považuji za velmi vzrušující.
Toto je závěrečná část trilogie od Vasilije Pantyukhina o zařízení AWS. V části popisují optimalizaci serveru a škálování databáze a v — funkce bez serveru a Firecracker.
Na v listopadu se Vasily Pantyukhin podělí o nové podrobnosti o zařízení Amazon. On o příčinách poruch a návrhu distribuovaných systémů ve společnosti Amazon. 24. října je ještě možné lístek za dobrou cenu a zaplaťte později. Čekáme na vás v HighLoad++, pojďte si popovídat!
Zdroj: www.habr.com