Az Amazon Web Services hálózat 69 zónából áll a világ 22 régiójában: USA-ban, Európában, Ázsiában, Afrikában és Ausztráliában. Minden zóna legfeljebb 8 adatközpontot – adatfeldolgozó központot – tartalmaz. Minden adatközpont több ezer vagy százezer szerverrel rendelkezik. A hálózatot úgy tervezték meg, hogy minden valószínűtlen kimaradási forgatókönyvet figyelembe vegyenek. Például minden régió el van szigetelve egymástól, és a megközelíthetőségi zónák több kilométeres távolságra vannak elválasztva. Ha el is vágja a kábelt, a rendszer átvált tartalék csatornákra, és az információvesztés néhány adatcsomagot tesz ki. Vaszilij Pantyuhin arról fog beszélni, hogy a hálózat milyen egyéb elvekre épül, és hogyan épül fel.
Vaszilij Pantyukhin Unix adminisztrátorként kezdett .ru cégeknél, 6 évig dolgozott nagy Sun Microsystem hardvereken, és 11 évig adatközpontú világot hirdetett az EMC-nél. Természetesen privát felhőkké fejlődött, majd nyilvános felhőkké vált. Most az Amazon Web Services építészeként technikai tanácsokat ad az AWS felhőben való éléshez és fejlődéshez.
Az AWS-trilógia előző részében Vaszilij a fizikai szerverek tervezésében és az adatbázis-skálázásban mélyedt el. Nitro kártyák, egyedi KVM alapú hypervisor, Amazon Aurora adatbázis - mindezekről az anyagban "" Olvassa el a szövegösszefüggést, vagy nézze meg beszédeket.
Ez a rész a hálózati skálázásra összpontosít, amely az egyik legösszetettebb rendszer az AWS-ben. Az evolúció a lapos hálózatból a virtuális magánfelhővé és annak kialakítása, a Blackfoot és a HyperPlane belső szolgáltatásai, a zajos szomszéd problémája, és a végén - a hálózat, a gerinc és a fizikai kábelek mérete. Mindezekről a vágás alatt.
Jogi nyilatkozat: az alábbiakban leírtak Vaszilij személyes véleménye, és nem feltétlenül esnek egybe az Amazon Web Services álláspontjával.
Hálózati méretezés
Az AWS felhő 2006-ban indult. Hálózata meglehetősen primitív volt – lapos szerkezetű. A privát címek tartománya minden felhőbérlő számára közös volt. Egy új virtuális gép indításakor véletlenül kapott egy elérhető IP-címet ebből a tartományból.
Ez a megközelítés könnyen megvalósítható volt, de alapvetően korlátozta a felhő használatát. Különösen nehéz volt olyan hibrid megoldásokat kifejleszteni, amelyek egyesítették a magánhálózatokat a helyszínen és az AWS-ben. A leggyakoribb probléma az IP-címtartományok átfedése volt.
Virtuális privát felhő
Kiderült, hogy a felhő keresett. Eljött az idő, hogy elgondolkodjunk a méretezhetőségen és annak lehetőségén, hogy bérlők tízmilliói használhatják. A lapos hálózat komoly akadályt jelent. Ezért elgondolkodtunk azon, hogyan lehet hálózati szinten elszigetelni a felhasználókat egymástól, hogy önállóan válasszanak IP-tartományt.
Mi az első dolog, ami eszedbe jut, ha a hálózati elszigetelésre gondol? Biztosan VLAN и VRF – Virtuális útválasztás és továbbítás.
Sajnos nem sikerült. A VLAN azonosító csak 12 bites, ami csak 4096 elszigetelt szegmenst ad. A legnagyobb kapcsolók is maximum 1-2 ezer VRF-et tudnak használni. A VRF és a VLAN együttes használata csak néhány millió alhálózatot eredményez. Ez határozottan nem elegendő több tízmillió bérlő számára, amelyek mindegyikének több alhálózatot kell használnia.
Egyszerűen nem engedhetjük meg magunknak, hogy megvásároljuk a szükséges számú nagy dobozt, például a Ciscótól vagy a Junipertől. Két oka van: őrülten drága, és nem akarunk kiszolgálni a fejlesztési és javítási politikájukat.
Csak egy következtetés van: készítsen saját megoldást.
2009-ben bejelentettük VPC - Virtuális privát felhő. A név megragadt, és most már sok felhőszolgáltató is használja.
A VPC egy virtuális hálózat SDN (Szoftver által meghatározott hálózat). Úgy döntöttünk, hogy nem találunk ki speciális protokollokat az L2 és L3 szinteken. A hálózat szabványos Etherneten és IP-n fut. A hálózaton keresztüli átvitelhez a virtuális gép forgalmat saját protokollcsomagolónkba foglaljuk. Azt az azonosítót jelzi, amely a bérlő VPC-jéhez tartozik.
Egyszerűen hangzik. Azonban számos komoly technikai kihívást kell leküzdeni. Például hol és hogyan kell tárolni a virtuális MAC/IP-címek, VPC-azonosítók és a megfelelő fizikai MAC/IP-címek leképezési adatait. Az AWS skálán ez egy hatalmas táblázat, amelynek minimális hozzáférési késleltetéssel kell működnie. Felelős ezért térképészeti szolgáltatás, amely vékony rétegben szétterül a hálózaton.
Az új generációs gépekben a tokozást Nitro kártyák végzik hardver szinten. Régebbi esetekben a tokozás és a dekapszulálás szoftver alapú.
Nézzük meg, hogyan működik általánosságban. Kezdjük az L2 szinttel. Tegyük fel, hogy van egy virtuális gépünk 10.0.0.2 IP-vel a 192.168.0.3 fizikai szerveren. Adatokat küld a 10.0.0.3 virtuális gépre, amely a 192.168.1.4-en él. A rendszer egy ARP kérést generál, és elküldi a hálózati Nitro kártyára. Az egyszerűség kedvéért feltételezzük, hogy mindkét virtuális gép ugyanabban a „kék” VPC-ben él.
A térkép lecseréli a forráscímet a sajátjára, és továbbítja az ARP keretet a leképezési szolgáltatásnak.
A leképezési szolgáltatás olyan információkat ad vissza, amelyek az L2 fizikai hálózaton keresztüli átvitelhez szükségesek.
Az ARP válaszban szereplő Nitro kártya lecseréli a fizikai hálózat MAC-ját a VPC-ben található címre.
Adatátvitelkor a logikai MAC-ot és az IP-t VPC burkolóba csomagoljuk. Mindezt a fizikai hálózaton keresztül továbbítjuk a megfelelő forrás és cél IP Nitro kártyák segítségével.
Az ellenőrzést az a fizikai gép végzi, amelyre a csomagot szánják. Erre azért van szükség, hogy elkerüljük a címhamisítás lehetőségét. A gép külön kérést küld a leképezési szolgálatnak, és azt kérdezi: „A 192.168.0.3 fizikai gépről kaptam egy csomagot, amely a 10.0.0.3-hoz készült a kék VPC-ben. Ő legitim?
A leképezési szolgáltatás ellenőrzi az erőforrás-allokációs táblát, és engedélyezi vagy megtagadja a csomag áthaladását. Minden új esetben további érvényesítés van beágyazva a Nitro kártyákba. Ezt még elméletileg sem lehet megkerülni. Ezért a másik VPC-ben lévő erőforrásokkal való hamisítás nem működik.
Ezután az adatokat a rendszer arra a virtuális gépre küldi, amelyre szánták.
A leképezési szolgáltatás logikai útválasztóként is működik a különböző alhálózatokban lévő virtuális gépek közötti adatok átviteléhez. Koncepcionálisan minden egyszerű, nem részletezem.
Kiderült, hogy az egyes csomagok továbbításakor a szerverek a leképezési szolgáltatáshoz fordulnak. Hogyan kezeljük az elkerülhetetlen késéseket? Gyorsítótárazás, természetesen.
A szépség az, hogy nem kell gyorsítótáraznia az egész hatalmas asztalt. Egy fizikai szerver viszonylag kis számú VPC-ről tárol virtuális gépeket. Csak ezeket a VPC-ket kell gyorsítótáraznia. Az adatok átvitele más VPC-kre az „alapértelmezett” konfigurációban továbbra sem jogos. Ha olyan funkciókat használnak, mint például a VPC-peering, akkor a megfelelő VPC-kről szóló információk is betöltődnek a gyorsítótárba.
Rendeztük az adatátvitelt a VPC-hez.
feketeláb
Mi a teendő olyan esetekben, amikor a forgalmat kifelé kell továbbítani, például az internetre vagy VPN-en keresztül a földre? Itt segít nekünk feketeláb — AWS belső szolgáltatás. Dél-afrikai csapatunk fejlesztette ki. Ezért nevezték el a szolgáltatást egy Dél-Afrikában élő pingvinről.
A Blackfoot lebontja a forgalmat, és megteszi vele, amit kell. Az adatok úgy kerülnek az Internetre, ahogy vannak.
VPN használatakor az adatokat kicsomagolják és újra IPsec-be csomagolják.
Közvetlen kapcsolat használatakor a forgalom címkézésre kerül, és a megfelelő VLAN-ra kerül.
Hipersík
Ez egy belső áramlásszabályozási szolgáltatás. Számos hálózati szolgáltatás figyelést igényel adatfolyam állapotok. Például NAT használatakor az áramlásvezérlésnek biztosítania kell, hogy minden IP:cél port pár egyedi kimenő porttal rendelkezzen. Egyensúlyozó esetén NLB - Hálózati terheléselosztó, az adatfolyamot mindig ugyanarra a virtuális célgépre kell irányítani. A Security Groups egy állapotfüggő tűzfal. Figyeli a bejövő forgalmat, és implicit módon nyit portokat a kimenő csomagok áramlásához.
Az AWS felhőben az átviteli késleltetési követelmények rendkívül magasak. Ezért Hipersík kritikus a teljes hálózat teljesítménye szempontjából.
A Hyperplane EC2 virtuális gépekre épül. Itt nincs varázslat, csak ravaszság. A trükk az, hogy ezek nagy RAM-mal rendelkező virtuális gépek. A műveletek tranzakciós jellegűek, és kizárólag a memóriában hajthatók végre. Ez lehetővé teszi, hogy csak több tíz mikroszekundumos késést érjen el. A lemezzel való munka megölné az összes termelékenységet.
A Hyperplane hatalmas számú ilyen EC2 gép elosztott rendszere. Minden virtuális gép 5 GB/s sávszélességgel rendelkezik. A teljes regionális hálózaton ez hihetetlen terabites sávszélességet biztosít, és lehetővé teszi a feldolgozást millió kapcsolat másodpercenként.
A HyperPlane csak adatfolyamokkal működik. A VPC csomagok tokozása teljesen átlátszó számára. A belső szolgáltatás esetleges sebezhetősége továbbra is megakadályozná a VPC-leválasztás megszakítását. Az alábbi szintek felelősek a biztonságért.
Zajos szomszéd
Még mindig van egy probléma zajos szomszéd - zajos szomszéd. Tegyük fel, hogy 8 csomópontunk van. Ezek a csomópontok feldolgozzák az összes felhőfelhasználó folyamatát. Úgy tűnik, hogy minden rendben van, és a terhelést egyenletesen kell elosztani az összes csomópont között. A csomópontok nagyon erősek, és nehéz őket túlterhelni.
De építészetünket még valószínűtlen forgatókönyvek alapján is építjük.
Az alacsony valószínűség nem azt jelenti, hogy lehetetlen.
Elképzelhetünk olyan helyzetet, amelyben egy vagy több felhasználó túl sok terhelést generál. Az összes HyperPlane csomópont részt vesz ennek a terhelésnek a feldolgozásában, és más felhasználók is tapasztalhatnak valamilyen teljesítménycsökkenést. Ez megtöri a felhő fogalmát, amelyben a bérlők nem képesek befolyásolni egymást.
Hogyan lehet megoldani a zajos szomszéd problémáját? Az első dolog, ami eszünkbe jut, az a szilánkolás. A 8 csomópontunk logikailag 4 darabra van felosztva, mindegyik 2 csomópontból. Most egy zajos szomszéd csak az összes felhasználó negyedét zavarja, de nagyon zavarja őket.
Csináljuk másképp a dolgokat. Minden felhasználóhoz csak 3 csomópontot osztunk ki.
A trükk az, hogy véletlenszerűen hozzárendelünk csomópontokat különböző felhasználókhoz. Az alábbi képen a kék felhasználó metszi a csomópontokat a másik két felhasználó egyikével - zöld és narancssárga.
8 csomópont és 3 felhasználó esetén 54% annak a valószínűsége, hogy egy zajos szomszéd metszi az egyik felhasználót. Ezzel a valószínűséggel egy kék felhasználó hatással lesz a többi bérlőre. Ugyanakkor a terhelésének csak egy része. Példánkban ez a hatás legalább valamilyen módon nem mindenki, hanem csak a felhasználók egyharmada számára lesz észrevehető. Ez már jó eredmény.
Azon felhasználók száma, akik keresztezik egymást
Valószínűség százalékban
0
18%
1
54%
2
26%
3
2%
Közelítsük a helyzetet a valósághoz – vegyünk 100 csomópontot és 5 felhasználót 5 csomóponton. Ebben az esetben egyik csomópont sem metszi egymást 77%-os valószínűséggel.
Azon felhasználók száma, akik keresztezik egymást
Valószínűség százalékban
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Valós helyzetben, hatalmas számú HyperPlane csomópont és felhasználó mellett, a zajos szomszéd potenciális hatása a többi felhasználóra minimális. Ezt a módszert hívják szilánkolás keverése - shuffle sharding. Minimalizálja a csomópont meghibásodásának negatív hatását.
Sok szolgáltatás a HyperPlane alapján épül fel: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Hálózati skála
Most beszéljünk magának a hálózatnak a méretéről. 2019 októberében az AWS itt kínálja szolgáltatásait 22 régióban, és további 9 terv van.
- Minden régió több elérhetőségi zónát tartalmaz. 69 van belőlük szerte a világon.
- Mindegyik AZ adatfeldolgozó központokból áll. Összesen nem több, mint 8 db.
- Az adatközpontban rengeteg szerver található, némelyikben akár 300 000 is.
Most átlagoljuk mindezt, szorozzuk meg, és kapjunk egy lenyűgöző ábrát, amely tükrözi Amazon felhő skála.
Számos optikai kapcsolat van az elérhetőségi zónák és az adatközpont között. Az egyik legnagyobb régiónkban 388 csatornát fektettek le csak az AZ egymás közötti kommunikációra és a kommunikációs központok más régiókkal (Transit Centers) való kommunikációjára. Összességében ez őrültséget okoz 5000 Tbit.
A Backbone AWS kifejezetten a felhőhöz készült és arra optimalizált. A csatornákra építjük 100 GB / s. Teljes mértékben ellenőrizzük őket, kivéve Kína régióit. A forgalmat nem osztják meg más cégekkel.
Természetesen nem mi vagyunk az egyetlen felhőszolgáltató, amely privát gerinchálózattal rendelkezik. Egyre több nagyvállalat követi ezt az utat. Ezt független kutatók is megerősítik, például a .
A grafikonon látható, hogy a tartalomszolgáltatók és a felhőszolgáltatók aránya nő. Emiatt a gerinchálózati szolgáltatók internetes forgalmának aránya folyamatosan csökken.
Elmagyarázom, miért történik ez. Korábban a legtöbb webszolgáltatás közvetlenül az internetről volt elérhető és fogyasztható. Manapság egyre több szerver található a felhőben, és ezen keresztül érhető el CDN - Tartalomelosztó hálózat. Az erőforrás eléréséhez a felhasználó az interneten keresztül csak a legközelebbi CDN PoP-hoz megy - Jelenlét pontja. Leggyakrabban valahol a közelben van. Ezután elhagyja a nyilvános internetet, és egy privát gerinchálózaton keresztül repül át például az Atlanti-óceánon, és közvetlenül az erőforráshoz jut.
Kíváncsi vagyok, hogyan fog változni az internet 10 év múlva, ha ez a tendencia folytatódik?
Fizikai csatornák
A tudósok még nem találták ki, hogyan lehet növelni a fénysebességet az Univerzumban, de nagy előrelépést értek el az optikai szálon keresztül történő továbbítás módszereiben. Jelenleg 6912 szálas kábeleket használunk. Ez segít jelentősen optimalizálni a telepítési költségeket.
Egyes régiókban speciális kábeleket kell használnunk. Például Sydney régióban speciális bevonattal ellátott kábeleket használunk a termeszek ellen.
Senki sem mentes a bajoktól, és néha a csatornáink megsérülnek. A jobb oldali fotón az egyik amerikai régióban az építőmunkások által elszakított optikai kábelek láthatók. A baleset következtében mindössze 13 adatcsomag veszett el, ami meglepő. Még egyszer - csak 13! A rendszer szó szerint azonnal átváltott tartalék csatornákra – a mérleg működik.
Végigvágtattunk az Amazon néhány felhőszolgáltatásán és technológiáján. Remélem, van legalább némi elképzelése a mérnökeink által megoldandó feladatok mértékéről. Személy szerint ezt nagyon izgalmasnak tartom.
Ez Vaszilij Pantyukhin trilógiájának utolsó része az AWS eszközről. BAN BEN részei leírják a szerver optimalizálását és az adatbázis méretezését, és in — szerver nélküli funkciók és Firecracker.
tovább novemberben Vaszilij Pantyuhin új részleteket oszt meg az Amazon készülékről. Ő a hibák okairól és az Amazon elosztott rendszereinek tervezéséről. Október 24-e még lehetséges jegyet jó áron, és fizessen később. Várunk benneteket a HighLoad++-ban, gyertek és csevegjünk!
Forrás: will.com