Mreža Amazon Web Services obuhvaća 69 zona diljem svijeta u 22 regije: SAD, Europa, Azija, Afrika i Australija. Svaka zona sadrži do 8 podatkovnih centara - Data Processing Centers. Svaki podatkovni centar ima tisuće ili stotine tisuća poslužitelja. Mreža je projektirana na način da se uzmu u obzir svi malo vjerojatni scenariji ispada. Na primjer, sve su regije izolirane jedna od druge, a zone pristupačnosti razdvojene su na udaljenosti od nekoliko kilometara. Čak i ako presječete kabel, sustav će se prebaciti na rezervne kanale, a gubitak informacija iznosit će nekoliko paketa podataka. Vasily Pantyukhin govorit će o tome na kojim je još principima izgrađena mreža i kako je strukturirana.
Vasilij Pantjuhin započeo je kao Unix administrator u .ru tvrtkama, radio na velikom hardveru Sun Microsystema 6 godina i propovijedao svijet usredotočen na podatke 11 godina u EMC-u. Prirodno je evoluirao u privatne oblake, a zatim se preselio u javne oblake. Sada, kao arhitekt Amazon Web Services, pruža tehničke savjete kako bi pomogao živjeti i razvijati se u AWS oblaku.
U prethodnom dijelu AWS trilogije, Vasily se zadubio u dizajn fizičkih poslužitelja i skaliranje baze podataka. Nitro kartice, prilagođeni hipervizor temeljen na KVM-u, baza podataka Amazon Aurora - o svemu tome u materijalu "" Čitajte za kontekst ili gledajte govorima.
Ovaj dio će se fokusirati na mrežno skaliranje, jedan od najsloženijih sustava u AWS-u. Evolucija od ravne mreže do Virtual Private Cloud-a i njegov dizajn, interne usluge Blackfoota i HyperPlane-a, problem bučnog susjeda i na kraju - veličina mreže, okosnice i fizičkih kabela. O svemu ovome pod rezom.
Izjava o odricanju od odgovornosti: sve ispod je Vasilijevo osobno mišljenje i ne mora se poklapati sa stavom Amazon Web Services.
Mrežno skaliranje
AWS oblak je pokrenut 2006. godine. Njegova je mreža bila prilično primitivna – s ravnom strukturom. Raspon privatnih adresa bio je zajednički svim zakupcima oblaka. Prilikom pokretanja novog virtualnog stroja slučajno ste primili dostupnu IP adresu iz ovog raspona.
Ovaj je pristup bilo lako implementirati, ali je fundamentalno ograničio korištenje oblaka. Konkretno, bilo je prilično teško razviti hibridna rješenja koja kombiniraju privatne mreže na zemlji i u AWS-u. Najčešći problem bilo je preklapanje raspona IP adresa.
Virtualni privatni oblak
Pokazalo se da je oblak tražen. Došlo je vrijeme za razmišljanje o skalabilnosti i mogućnosti da je koriste deseci milijuna stanara. Ravna mreža postala je velika prepreka. Stoga smo razmišljali kako izolirati korisnike jedne od drugih na mrežnoj razini kako bi mogli samostalno birati IP raspone.
Što vam prvo padne na pamet kada pomislite na mrežnu izolaciju? Sigurno VLAN и VRF - Virtualno usmjeravanje i prosljeđivanje.
Nažalost, nije uspjelo. VLAN ID je samo 12 bita, što nam daje samo 4096 izoliranih segmenata. Čak i najveći prekidači mogu koristiti maksimalno 1-2 tisuće VRF-ova. Korištenje VRF-a i VLAN-a zajedno daje nam samo nekoliko milijuna podmreža. To definitivno nije dovoljno za desetke milijuna stanara, od kojih svaki mora moći koristiti više podmreža.
Također jednostavno ne možemo priuštiti kupnju potrebnog broja velikih kutija, na primjer, od Cisca ili Junipera. Postoje dva razloga: ludo je skupo i ne želimo biti prepušteni na milost i nemilost njihovoj politici razvoja i krpanja.
Zaključak je samo jedan - napravite svoje rješenje.
2009. smo najavili VPC - Virtualni privatni oblak. Naziv se zadržao i sada ga koriste i mnogi pružatelji usluga oblaka.
VPC je virtualna mreža SDN (Softverski definirana mreža). Odlučili smo ne izmišljati posebne protokole na razinama L2 i L3. Mreža radi na standardnom Ethernetu i IP-u. Za prijenos preko mreže, promet virtualnog stroja je kapsuliran u naš vlastiti omotač protokola. Označava ID koji pripada VPC-u stanara.
Zvuči jednostavno. Međutim, postoji nekoliko ozbiljnih tehničkih izazova koje je potrebno prevladati. Na primjer, gdje i kako pohraniti podatke o mapiranju virtualnih MAC/IP adresa, VPC ID-a i odgovarajućeg fizičkog MAC/IP-a. Na AWS ljestvici, ovo je ogromna tablica koja bi trebala raditi s minimalnim kašnjenjima pristupa. Odgovoran za ovo usluga kartiranja, koji se u tankom sloju razmazuje po cijeloj mreži.
U strojevima nove generacije enkapsulaciju obavljaju Nitro kartice na hardverskoj razini. U starijim slučajevima, enkapsulacija i dekapsulacija se temelje na softveru.
Hajde da shvatimo kako to funkcionira općenito. Počnimo s razinom L2. Pretpostavimo da imamo virtualni stroj s IP 10.0.0.2 na fizičkom poslužitelju 192.168.0.3. Šalje podatke virtualnom stroju 10.0.0.3 koji živi na 192.168.1.4. ARP zahtjev se generira i šalje mrežnoj Nitro kartici. Radi jednostavnosti, pretpostavljamo da oba virtualna računala žive u istom "plavom" VPC-u.
Karta zamjenjuje izvornu adresu vlastitom i prosljeđuje ARP okvir servisu za mapiranje.
Usluga mapiranja vraća informacije koje su potrebne za prijenos preko L2 fizičke mreže.
Nitro kartica u ARP odgovoru zamjenjuje MAC na fizičkoj mreži adresom u VPC-u.
Prilikom prijenosa podataka omatamo logički MAC i IP u VPC omotač. Sve to prenosimo putem fizičke mreže koristeći odgovarajuće izvorne i odredišne IP Nitro kartice.
Fizički stroj kojem je paket namijenjen obavlja provjeru. Ovo je neophodno kako bi se spriječila mogućnost krivotvorenja adrese. Stroj šalje poseban zahtjev servisu za mapiranje i pita: “Od fizičkog stroja 192.168.0.3 primio sam paket koji je namijenjen za 10.0.0.3 u plavom VPC-u. Je li on legitiman?
Usluga mapiranja provjerava svoju tablicu raspodjele resursa i dopušta ili odbija prolazak paketa. U svim novim slučajevima, dodatna provjera valjanosti ugrađena je u Nitro kartice. Nemoguće ga je zaobići ni teoretski. Stoga lažiranje resursa u drugom VPC-u neće funkcionirati.
Zatim se podaci šalju na virtualni stroj za koji su namijenjeni.
Usluga mapiranja također radi kao logički usmjerivač za prijenos podataka između virtualnih strojeva u različitim podmrežama. Sve je konceptualno jednostavno, neću ići u detalje.
Ispada da se prilikom prijenosa svakog paketa poslužitelji okreću kartografskoj usluzi. Kako se nositi s neizbježnim kašnjenjima? Predmemoriranje, naravno.
Ljepota je u tome što ne morate keširati cijelu ogromnu tablicu. Fizički poslužitelj ugošćuje virtualne strojeve s relativno malog broja VPC-ova. Trebate samo predmemorirati informacije o tim VPC-ovima. Prijenos podataka na druge VPC-ove u "zadanoj" konfiguraciji još uvijek nije legitiman. Ako se koristi funkcija kao što je VPC-peering, tada se informacije o odgovarajućim VPC-ovima dodatno učitavaju u predmemoriju.
Prijenos podataka u VPC smo riješili.
Blackfoot
Što učiniti u slučajevima kada promet treba prenijeti van, na primjer na internet ili putem VPN-a na zemlju? Pomaže nam ovdje Blackfoot - interni AWS servis. Razvio ga je naš južnoafrički tim. Zato je servis nazvan po pingvinu koji živi u Južnoj Africi.
Blackfoot dekapsulira promet i radi ono što je potrebno s njim. Podaci se šalju na Internet takvi kakvi jesu.
Podaci se dekapsuliraju i ponovno omotaju u IPsec kada se koristi VPN.
Kada koristite Direct Connect, promet se označava i šalje na odgovarajući VLAN.
HyperPlane
Ovo je interna usluga kontrole protoka. Mnoge mrežne usluge zahtijevaju nadzor stanja protoka podataka. Na primjer, kada koristite NAT, kontrola protoka mora osigurati da svaki par IP:odredišni port ima jedinstveni izlazni port. U slučaju balansera NLB - Mrežni balanser opterećenja, protok podataka uvijek bi trebao biti usmjeren na isti ciljni virtualni stroj. Sigurnosne grupe vatrozid je s praćenjem stanja. Nadzire dolazni promet i implicitno otvara portove za protok odlaznih paketa.
U AWS oblaku zahtjevi za kašnjenjem prijenosa su izuzetno visoki. Zato HyperPlane ključni za izvedbu cijele mreže.
Hyperplane je izgrađen na EC2 virtualnim strojevima. Ovdje nema magije, samo lukavstva. Trik je u tome što su to virtualni strojevi s velikim RAM-om. Operacije su transakcijske i izvode se isključivo u memoriji. To vam omogućuje da postignete kašnjenja od samo nekoliko desetaka mikrosekundi. Rad s diskom ubio bi svu produktivnost.
Hyperplane je distribuirani sustav ogromnog broja takvih EC2 strojeva. Svaki virtualni stroj ima propusnost od 5 GB/s. U cijeloj regionalnoj mreži to osigurava nevjerojatne terabitne propusnosti i omogućuje obradu milijuni veza u sekundi.
HyperPlane radi samo sa streamovima. Enkapsulacija VPC paketa je potpuno transparentna za njega. Potencijalna ranjivost u ovoj internoj usluzi ipak bi spriječila probijanje VPC izolacije. Niže navedene razine odgovorne su za sigurnost.
Bučan susjed
Još uvijek postoji problem bučni susjed - bučni susjed. Pretpostavimo da imamo 8 čvorova. Ovi čvorovi obrađuju tokove svih korisnika oblaka. Čini se da je sve u redu i opterećenje bi trebalo biti ravnomjerno raspoređeno na sve čvorove. Čvorovi su vrlo moćni i teško ih je preopteretiti.
Ali mi gradimo našu arhitekturu na temelju čak i malo vjerojatnih scenarija.
Mala vjerojatnost ne znači nemoguće.
Možemo zamisliti situaciju u kojoj bi jedan ili više korisnika generirali preveliko opterećenje. Svi HyperPlane čvorovi uključeni su u obradu ovog opterećenja i drugi bi korisnici potencijalno mogli doživjeti neku vrstu pada performansi. Time se ruši koncept oblaka u kojem stanari nemaju mogućnosti utjecati jedni na druge.
Kako riješiti problem bučnog susjeda? Prvo što pada na pamet je šarding. Naših 8 čvorova logično je podijeljeno u 4 segmenta od po 2 čvora. Sada će bučni susjed smetati samo četvrtini svih korisnika, ali će ih jako smetati.
Učinimo stvari drugačije. Svakom korisniku ćemo dodijeliti samo 3 čvora.
Trik je u nasumičnom dodjeljivanju čvorova različitim korisnicima. Na donjoj slici plavi korisnik presijeca čvorove s jednim od druga dva korisnika - zelenim i narančastim.
S 8 čvorova i 3 korisnika, vjerojatnost bučnog susjeda koji se križa s jednim od korisnika je 54%. S tom vjerojatnošću će plavi korisnik utjecati na ostale stanare. Istovremeno, samo dio svog opterećenja. U našem primjeru, ovaj utjecaj će biti barem nekako primjetan ne svima, već samo trećini svih korisnika. Ovo je već dobar rezultat.
Broj korisnika koji će se presijecati
Vjerojatnost u postocima
0
18%
1
54%
2
26%
3
2%
Približimo situaciju stvarnosti – uzmimo 100 čvorova i 5 korisnika na 5 čvorova. U ovom slučaju niti jedan od čvorova neće se presijecati s vjerojatnošću od 77%.
Broj korisnika koji će se presijecati
Vjerojatnost u postocima
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
U stvarnoj situaciji, s ogromnim brojem HyperPlane čvorova i korisnika, potencijalni utjecaj bučnog susjeda na druge korisnike je minimalan. Ova metoda se zove miješanje sharding - shuffle šarding. Minimizira negativan učinak kvara čvora.
Mnoge usluge izgrađene su na temelju HyperPlane-a: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Mrežna skala
Razgovarajmo sada o veličini same mreže. Za listopad 2019. AWS nudi svoje usluge u 22 regije, a u planu je još 9.
- Svaka regija sadrži nekoliko zona dostupnosti. Ima ih 69 diljem svijeta.
- Svaki AZ sastoji se od centara za obradu podataka. Ukupno ih nema više od 8.
- Podatkovni centar sadrži ogroman broj poslužitelja, neki do 300.
Hajde sada sve ovo uprosječiti, pomnožiti i dobiti impresivnu brojku koja odražava Amazonska skala oblaka.
Postoje mnoge optičke veze između zona dostupnosti i podatkovnog centra. U jednoj od naših najvećih regija postavljeno je 388 kanala samo za međusobnu AZ komunikaciju s komunikacijskim centrima s drugim regijama (Tranzitni centri). Sveukupno ovo daje ludilo 5000 Tbit.
Backbone AWS izgrađen je posebno za oblak i optimiziran za njega. Gradimo ga na kanalima 100 GB / s. U potpunosti ih kontroliramo, s izuzetkom regija u Kini. Promet se ne dijeli s gomilom drugih tvrtki.
Naravno, mi nismo jedini pružatelj usluga oblaka s privatnom okosnicom mreže. Tim putem ide sve više velikih tvrtki. To potvrđuju neovisni istraživači, primjerice iz .
Grafikon pokazuje da raste udio pružatelja sadržaja i cloud pružatelja usluga. Zbog toga se udio internetskog prometa backbone providera konstantno smanjuje.
Objasnit ću zašto se to događa. Prije je većina web usluga bila dostupna i konzumirana izravno s Interneta. Danas se sve više poslužitelja nalazi u oblaku i dostupni su putem CDN - Mreža za distribuciju sadržaja. Za pristup resursu, korisnik ide putem Interneta samo do najbližeg CDN PoP-a - Točka prisutnosti. Najčešće je negdje u blizini. Zatim napušta javni internet i leti preko privatne okosnice preko Atlantika, na primjer, i dolazi izravno do izvora.
Pitam se kako će se internet promijeniti za 10 godina ako se ovaj trend nastavi?
Fizički kanali
Znanstvenici još nisu otkrili kako povećati brzinu svjetlosti u svemiru, ali su jako napredovali u metodama njezinog prijenosa optičkim vlaknima. Trenutno koristimo 6912 fiber kabele. To pomaže značajno optimizirati troškove njihove instalacije.
U nekim regijama moramo koristiti posebne kabele. Na primjer, u regiji Sydneya koristimo kabele s posebnim premazom protiv termita.
Nitko nije imun na probleme i ponekad se naši kanali oštete. Slika desno prikazuje optičke kablove u jednoj od američkih regija koje su pokidali građevinski radnici. Kao posljedica nesreće izgubljeno je samo 13 paketa podataka, što je iznenađujuće. Još jednom - samo 13! Sustav se doslovno odmah prebacio na rezervne kanale - vaga radi.
Progalopirali smo kroz neke Amazonove usluge i tehnologije u oblaku. Nadam se da imate barem neku predodžbu o opsegu zadataka koje naši inženjeri moraju riješiti. Osobno, ovo smatram vrlo uzbudljivim.
Ovo je završni dio trilogije Vasilija Pantjuhina o uređaju AWS. U dijelovi opisuju optimizaciju poslužitelja i skaliranje baze podataka, i in — funkcije bez poslužitelja i Firecracker.
Na u studenom će Vasily Pantyukhin podijeliti nove detalje o uređaju Amazon. On o uzrocima kvarova i dizajnu distribuiranih sustava u Amazonu. 24. listopada je još uvijek moguć kartu po povoljnoj cijeni, a platite naknadno. Čekamo te u HighLoad++, dođi da popričamo!
Izvor: www.habr.com