„Amazon Web Services“ tinklo mastas – 69 zonos visame pasaulyje 22 regionuose: JAV, Europoje, Azijoje, Afrikoje ir Australijoje. Kiekvienoje zonoje yra iki 8 duomenų centrų – duomenų apdorojimo centrų. Kiekvienas duomenų centras turi tūkstančius ar šimtus tūkstančių serverių. Tinklas suprojektuotas taip, kad būtų atsižvelgta į visus mažai tikėtinus gedimų scenarijus. Pavyzdžiui, visi regionai yra izoliuoti vienas nuo kito, o pasiekiamumo zonos yra atskirtos kelių kilometrų atstumu. Net ir nutraukus laidą, sistema persijungs į atsarginius kanalus, o informacijos praradimas sieks kelis duomenų paketus. Vasilijus Pantyukhinas kalbės apie tai, kokiais kitais principais kuriamas tinklas ir kaip jis struktūrizuotas.
Vasilijus Pantyukhinas pradėjo kaip Unix administratorius .ru įmonėse, 6 metus dirbo su didele Sun Microsystem technine įranga ir 11 metų skelbė į duomenis orientuotą pasaulį EMC. Jis natūraliai išsivystė į privačius debesis, tada perėjo į viešuosius. Dabar, kaip „Amazon Web Services“ architektas, jis teikia techninius patarimus, padedančius gyventi ir tobulėti AWS debesyje.
Ankstesnėje AWS trilogijos dalyje Vasilijus gilinosi į fizinių serverių dizainą ir duomenų bazės mastelį. Nitro kortelės, pritaikytas KVM pagrįstas hipervizorius, „Amazon Aurora“ duomenų bazė - apie visa tai medžiagoje ““ Perskaitykite kontekstą arba žiūrėkite kalbos.
Šioje dalyje pagrindinis dėmesys bus skiriamas tinklo mastelio keitimui, vienai sudėtingiausių AWS sistemų. Evoliucija nuo plokščio tinklo iki virtualaus privataus debesies ir jo dizainas, vidinės Blackfoot ir HyperPlane paslaugos, triukšmingo kaimyno problema, o pabaigoje - tinklo, magistralinio ir fizinių kabelių mastelis. Apie visa tai po pjūviu.
Atsakomybės apribojimas: visa žemiau yra asmeninė Vasilijaus nuomonė ir gali nesutapti su Amazon Web Services pozicija.
Tinklo mastelio keitimas
AWS debesis buvo paleistas 2006 m. Jo tinklas buvo gana primityvus – plokščios struktūros. Privačių adresų diapazonas buvo bendras visiems debesų nuomininkams. Pradėdami naują virtualią mašiną netyčia gavote galimą IP adresą iš šio diapazono.
Šis metodas buvo lengvai įgyvendinamas, tačiau iš esmės apribojo debesies naudojimą. Visų pirma, buvo gana sunku sukurti hibridinius sprendimus, kurie derintų privačius tinklus žemėje ir AWS. Dažniausia problema buvo persidengę IP adresų diapazonai.
Virtualus privatus debesis
Debesis pasirodė paklausus. Atėjo laikas pagalvoti apie mastelį ir galimybę juo pasinaudoti dešimtys milijonų nuomininkų. Plokščias tinklas tapo pagrindine kliūtimi. Todėl galvojome, kaip atskirti vartotojus vienas nuo kito tinklo lygiu, kad jie galėtų savarankiškai pasirinkti IP diapazonus.
Kas pirmiausia ateina į galvą, kai galvojate apie tinklo izoliaciją? Žinoma VLAN и VRF – virtualus maršruto parinkimas ir persiuntimas.
Deja, nepavyko. VLAN ID yra tik 12 bitų, o tai suteikia mums tik 4096 izoliuotus segmentus. Net didžiausi jungikliai gali naudoti daugiausia 1-2 tūkstančius VRF. Naudojant VRF ir VLAN kartu gauname tik kelis milijonus potinklių. To tikrai neužtenka dešimtims milijonų nuomininkų, kurių kiekvienas turi turėti galimybę naudotis keliais potinkliais.
Taip pat tiesiog negalime sau leisti nusipirkti reikiamo kiekio didelių dėžių, pavyzdžiui, iš „Cisco“ ar „Juniper“. Yra dvi priežastys: tai beprotiškai brangu, ir mes nenorime būti nuo jų kūrimo ir pataisymo politikos malonės.
Išvada tik viena – spręskite patys.
2009 m. paskelbėme VPC - Virtualus privatus debesis. Pavadinimas įstrigo ir dabar daugelis debesų paslaugų teikėjų jį taip pat naudoja.
VPC yra virtualus tinklas SDN (Programinės įrangos nustatytas tinklas). Mes nusprendėme nesugalvoti specialių protokolų L2 ir L3 lygiuose. Tinklas veikia standartiniu eternetu ir IP. Norint perduoti tinklu, virtualios mašinos srautas yra įtrauktas į mūsų pačių protokolo paketą. Tai nurodo ID, kuris priklauso nuomininko VPC.
Skamba paprastai. Tačiau yra keletas rimtų techninių iššūkių, kuriuos reikia įveikti. Pavyzdžiui, kur ir kaip saugoti virtualių MAC/IP adresų atvaizdavimo duomenis, VPC ID ir atitinkamą fizinį MAC/IP. AWS mastu tai yra didžiulė lentelė, kuri turėtų veikti su minimaliais prieigos vėlavimais. Už tai atsakingas kartografavimo paslauga, kuris plonu sluoksniu pasklinda visame tinkle.
Naujos kartos mašinose inkapsuliavimas atliekamas Nitro kortelėmis aparatūros lygiu. Senesniais atvejais inkapsuliavimas ir dekapsuliavimas yra pagrįsti programine įranga.
Išsiaiškinkime, kaip tai veikia bendrais bruožais. Pradėkime nuo L2 lygio. Tarkime, kad fiziniame serveryje 10.0.0.2 turime virtualią mašiną su IP 192.168.0.3. Jis siunčia duomenis į virtualią mašiną 10.0.0.3, kuri veikia 192.168.1.4. Sugeneruojama ARP užklausa ir siunčiama į tinklo Nitro kortelę. Paprastumo dėlei darome prielaidą, kad abi virtualios mašinos gyvena tame pačiame „mėlyname“ VPC.
Žemėlapis pakeičia šaltinio adresą savo ir persiunčia ARP rėmelį žemėlapių tarnybai.
Žemėlapio paslauga grąžina informaciją, kuri reikalinga perduoti L2 fiziniu tinklu.
Nitro kortelė ARP atsakyme pakeičia MAC fiziniame tinkle adresu VPC.
Perkeldami duomenis loginį MAC ir IP įvyniojame į VPC pakuotę. Visa tai perduodame fiziniu tinklu naudodami atitinkamas šaltinio ir paskirties IP Nitro korteles.
Patikrinimą atlieka fizinė mašina, kuriai skirta pakuotė. Tai būtina siekiant išvengti adresų klastojimo. Mašina siunčia specialią užklausą žemėlapių tarnybai ir klausia: „Iš fizinės mašinos 192.168.0.3 gavau paketą, kuris skirtas 10.0.0.3 mėlyname VPC. Ar jis teisėtas?
Susiejimo paslauga tikrina savo išteklių paskirstymo lentelę ir leidžia arba neleidžia paketui praeiti. Visais naujais atvejais į Nitro korteles įdėtas papildomas patvirtinimas. To apeiti neįmanoma net teoriškai. Todėl apgaulingi ištekliai kitame VPC neveiks.
Tada duomenys siunčiami į virtualią mašiną, kuriai jie skirti.
Susiejimo paslauga taip pat veikia kaip loginis maršrutizatorius duomenims perduoti tarp virtualių mašinų skirtinguose potinkliuose. Viskas konceptualiai paprasta, nesileisiu.
Pasirodo, kiekvieną paketą perduodami serveriai kreipiasi į žemėlapių tarnybą. Kaip susidoroti su neišvengiamu vėlavimu? Talpykla, žinoma.
Gražumas yra tas, kad jums nereikia talpinti visos didžiulės lentelės. Fizinis serveris talpina virtualias mašinas iš palyginti nedidelio skaičiaus VPC. Jums tereikia talpykloje saugoti informaciją apie šiuos VPC. Duomenų perkėlimas į kitus VPC naudojant „numatytąją“ konfigūraciją vis dar nėra teisėtas. Jei naudojama tokia funkcija kaip VPC-peering, tada informacija apie atitinkamus VPC papildomai įkeliama į talpyklą.
Sutvarkėme duomenų perdavimą į VPC.
Blackfoot
Ką daryti tais atvejais, kai srautą reikia perduoti išorėje, pavyzdžiui, į internetą arba per VPN į žemę? Padeda mums čia Blackfoot — AWS vidinė paslauga. Jį sukūrė mūsų Pietų Afrikos komanda. Štai kodėl paslauga pavadinta Pietų Afrikoje gyvenančio pingvino vardu.
Blackfoot dekapsuluoja srautą ir daro tai, ko reikia. Duomenys į internetą siunčiami tokie, kokie yra.
Naudojant VPN, duomenys dekapsuliuojami ir iš naujo suvyniojami į IPsec.
Naudojant „Direct Connect“, srautas pažymimas ir siunčiamas į atitinkamą VLAN.
Hiperplanas
Tai vidinio srauto valdymo paslauga. Daugelį tinklo paslaugų reikia stebėti duomenų srauto būsenos. Pavyzdžiui, naudojant NAT, srauto valdymas turi užtikrinti, kad kiekviena IP:paskirties prievadų pora turėtų unikalų išeinantį prievadą. Balansuotojo atveju NLB - Tinklo apkrovos balansavimo priemonė, duomenų srautas visada turėtų būti nukreiptas į tą pačią tikslinę virtualią mašiną. Apsaugos grupės yra būseną atitinkanti ugniasienė. Jis stebi įeinantį srautą ir netiesiogiai atidaro prievadus išeinančiam paketų srautui.
AWS debesyje perdavimo delsos reikalavimai yra labai dideli. Štai kodėl Hiperplanas labai svarbus viso tinklo veikimui.
„Hyperplane“ sukurta EC2 virtualiose mašinose. Čia nėra magijos, tik gudrumas. Apgaulė ta, kad tai virtualios mašinos su didele RAM. Operacijos yra transakcinės ir atliekamos tik atmintyje. Tai leidžia pasiekti tik dešimčių mikrosekundžių vėlavimą. Darbas su disku sumažintų visą produktyvumą.
„Hyperplane“ yra daugybės tokių EC2 mašinų paskirstyta sistema. Kiekvienos virtualios mašinos pralaidumas yra 5 GB/s. Visame regioniniame tinkle tai suteikia neįtikėtiną terabitų pralaidumą ir leidžia apdoroti milijonai jungčių per sekundę.
„HyperPlane“ veikia tik su srautais. Jai VPC paketų kapsuliavimas yra visiškai skaidrus. Galimas šios vidinės paslaugos pažeidžiamumas vis tiek neleistų nutraukti VPC izoliacijos. Žemiau esantys lygiai yra atsakingi už saugumą.
Triukšmingas kaimynas
Vis dar yra problema triukšmingas kaimynas - triukšmingas kaimynas. Tarkime, kad turime 8 mazgus. Šie mazgai apdoroja visų debesies naudotojų srautus. Atrodo, kad viskas gerai ir apkrova turėtų būti tolygiai paskirstyta visuose mazguose. Mazgai yra labai galingi ir juos sunku perkrauti.
Tačiau savo architektūrą kuriame remdamiesi net mažai tikėtinais scenarijais.
Maža tikimybė nereiškia, kad neįmanoma.
Galime įsivaizduoti situaciją, kai vienas ar keli vartotojai generuotų per daug apkrovos. Visi „HyperPlane“ mazgai dalyvauja apdorojant šią apkrovą, todėl kiti vartotojai gali patirti tam tikrą našumą. Tai pažeidžia debesies koncepciją, kurioje nuomininkai negali daryti įtakos vieni kitiems.
Kaip išspręsti triukšmingo kaimyno problemą? Pirmas dalykas, kuris ateina į galvą, yra smulkinimas. Mūsų 8 mazgai logiškai suskirstyti į 4 fragmentus po 2 mazgus. Dabar triukšmingas kaimynas trukdys tik ketvirtadaliui visų vartotojų, tačiau jiems labai trukdys.
Darykime dalykus kitaip. Kiekvienam vartotojui skirsime tik 3 mazgus.
Triukas yra atsitiktinai priskirti mazgus skirtingiems vartotojams. Žemiau esančiame paveikslėlyje mėlynas vartotojas kerta mazgus su vienu iš kitų dviejų vartotojų – žaliu ir oranžiniu.
Turint 8 mazgus ir 3 vartotojus, tikimybė, kad triukšmingas kaimynas susikirs su vienu iš vartotojų, yra 54%. Su tokia tikimybe mėlynasis vartotojas turės įtakos kitiems nuomininkams. Tuo pačiu metu tik dalis jo apkrovos. Mūsų pavyzdyje ši įtaka bus bent kažkaip pastebima ne visiems, o tik trečdaliui visų vartotojų. Tai jau geras rezultatas.
Naudotojų, kurie susikirs, skaičius
Tikimybė procentais
0
18%
1
54%
2
26%
3
2%
Priartinkime situaciją prie realybės – paimkime 100 mazgų ir 5 vartotojus ant 5 mazgų. Šiuo atveju nė vienas mazgas nesusikirs su 77% tikimybe.
Naudotojų, kurie susikirs, skaičius
Tikimybė procentais
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Realioje situacijoje, kai yra daug HyperPlane mazgų ir vartotojų, galimas triukšmingo kaimyno poveikis kitiems vartotojams yra minimalus. Šis metodas vadinamas maišymo skeldinimo - shuffle sharding. Tai sumažina neigiamą mazgo gedimo poveikį.
Daugelis paslaugų yra sukurtos HyperPlane pagrindu: tinklo apkrovos balansavimo priemonė, NAT šliuzas, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Tinklo skalė
Dabar pakalbėkime apie paties tinklo mastą. 2019 m. spalio mėn. AWS siūlo savo paslaugas 22 regionai, ir planuojami dar 9.
- Kiekviename regione yra kelios prieinamumo zonos. Visame pasaulyje jų yra 69.
- Kiekvieną AZ sudaro duomenų apdorojimo centrai. Iš viso jų yra ne daugiau kaip 8.
- Duomenų centre yra daugybė serverių, kai kuriuose jų yra iki 300 000.
Dabar apskaičiuokime visa tai vidurkį, padauginkime ir gaukime įspūdingą figūrą, kuri atspindi Amazon debesų skalė.
Yra daug optinių ryšių tarp prieinamumo zonų ir duomenų centro. Viename iš didžiausių mūsų regionų buvo nutiesti 388 kanalai, skirti vien AZ komunikacijai tarp kitų ir ryšių centrų su kitais regionais (tranzito centrai). Iš viso tai sukelia beprotybę 5000 Tbit.
Backbone AWS sukurtas specialiai debesims ir optimizuotas jai. Mes statome jį ant kanalų 100 GB / s. Mes juos visiškai kontroliuojame, išskyrus Kinijos regionus. Eismas nėra dalijamas su kitų įmonių kroviniais.
Žinoma, nesame vienintelis debesų tiekėjas, turintis privatų pagrindinį tinklą. Šiuo keliu eina vis daugiau didelių įmonių. Tai patvirtina nepriklausomi tyrinėtojai, pavyzdžiui, iš .
Grafike matyti, kad turinio tiekėjų ir debesų tiekėjų dalis auga. Dėl šios priežasties stuburinių tiekėjų interneto srauto dalis nuolat mažėja.
Paaiškinsiu, kodėl taip nutinka. Anksčiau dauguma interneto paslaugų buvo pasiekiamos ir vartojamos tiesiogiai iš interneto. Šiuo metu vis daugiau serverių yra debesyje ir yra pasiekiami per CDN - Turinio platinimo tinklas. Norėdami pasiekti šaltinį, vartotojas internetu eina tik į artimiausią CDN PoP - Buvimo taškas. Dažniausiai tai yra kažkur netoliese. Tada jis palieka viešąjį internetą ir, pavyzdžiui, perskrenda per privatų stuburą per Atlantą ir patenka tiesiai į šaltinį.
Įdomu, kaip internetas pasikeis po 10 metų, jei tokia tendencija išliks?
Fiziniai kanalai
Mokslininkai dar neišsiaiškino, kaip padidinti šviesos greitį Visatoje, tačiau jie padarė didelę pažangą, taikydami šviesos perdavimo būdus. Šiuo metu naudojame 6912 pluošto kabelius. Tai padeda žymiai optimizuoti jų įrengimo išlaidas.
Kai kuriuose regionuose turime naudoti specialius kabelius. Pavyzdžiui, Sidnėjaus regione naudojame kabelius su specialia danga nuo termitų.
Niekas nėra apsaugotas nuo bėdų ir kartais mūsų kanalai pažeidžiami. Dešinėje esančioje nuotraukoje matyti optiniai kabeliai viename iš Amerikos regionų, kuriuos suplėšė statybininkai. Dėl avarijos buvo prarasta tik 13 duomenų paketų, kas stebina. Dar kartą – tik 13! Sistema akimirksniu persijungė į atsarginius kanalus – svarstyklės veikia.
Mes šuoliavome per kai kurias „Amazon“ debesies paslaugas ir technologijas. Tikiuosi, kad bent kiek įsivaizduojate užduočių, kurias turi išspręsti mūsų inžinieriai, mastą. Asmeniškai man tai labai įdomu.
Tai paskutinė Vasilijaus Pantyukhino trilogijos apie AWS įrenginį dalis. IN dalyse aprašomas serverio optimizavimas ir duomenų bazės mastelio keitimas - funkcijos be serverio ir „Firecracker“.
Apie lapkritį Vasilijus Pantyukhinas pasidalins naujomis „Amazon“ įrenginio detalėmis. Jis apie gedimų priežastis ir paskirstytų sistemų „Amazon“ dizainą. Dar galima spalio 24 d bilietą už gerą kainą ir mokėkite vėliau. Laukiame jūsų HighLoad++, ateik ir pabendraukite!
Šaltinis: www.habr.com