Mreža Amazon Web Services obuhvata 69 zona širom svijeta u 22 regije: SAD, Evropa, Azija, Afrika i Australija. Svaka zona sadrži do 8 data centara - Data Processing Centers. Svaki data centar ima hiljade ili stotine hiljada servera. Mreža je dizajnirana na takav način da se uzmu u obzir svi malo vjerojatni scenariji kvara. Na primjer, sve regije su izolovane jedna od druge, a zone pristupačnosti su razdvojene na udaljenosti od nekoliko kilometara. Čak i ako presečete kabl, sistem će se prebaciti na rezervne kanale, a gubitak informacija iznosiće nekoliko paketa podataka. Vasilij Pantjuhin će govoriti o tome na kojim je drugim principima mreža izgrađena i kako je strukturirana.
Vasilij Pantjuhin započeo je kao Unix administrator u .ru kompanijama, radio na velikom Sun Microsystem hardveru 6 godina i propovijedao svijet usmjeren na podatke 11 godina u EMC-u. Prirodno je evoluirao u privatne oblake, a zatim se preselio u javne. Sada, kao arhitekta Amazon Web Services, pruža tehničke savjete kako bi pomogao u životu i razvoju u AWS oblaku.
U prethodnom dijelu AWS trilogije, Vasily se bavio dizajnom fizičkih servera i skaliranjem baze podataka. Nitro kartice, prilagođeni hipervizor baziran na KVM, baza podataka Amazon Aurora - o svemu tome u materijalu "" Pročitajte za kontekst ili pogledajte govori.
Ovaj dio će se fokusirati na mrežno skaliranje, jedan od najsloženijih sistema u AWS-u. Evolucija od ravne mreže do virtuelnog privatnog oblaka i njegovog dizajna, internih servisa Blackfoota i HyperPlanea, problem bučnog susjeda i na kraju - razmjera mreže, okosnica i fizičkih kablova. O svemu ovome pod rezom.
Odricanje od odgovornosti: sve ispod je Vasilijevo lično mišljenje i možda se ne poklapa sa stavom Amazon Web Services.
Mrežno skaliranje
AWS oblak je pokrenut 2006. Njegova mreža je bila prilično primitivna - s ravnom strukturom. Raspon privatnih adresa bio je zajednički za sve korisnike oblaka. Kada pokrećete novu virtuelnu mašinu, slučajno ste dobili dostupnu IP adresu iz ovog opsega.
Ovaj pristup je bio lak za implementaciju, ali je suštinski ograničio upotrebu oblaka. Konkretno, bilo je prilično teško razviti hibridna rješenja koja kombinuju privatne mreže na terenu i u AWS-u. Najčešći problem je bio preklapanje raspona IP adresa.
Virtualni privatni oblak
Pokazalo se da je oblak tražen. Došlo je vrijeme da se razmisli o skalabilnosti i mogućnosti da je koriste desetine miliona stanara. Ravna mreža je postala velika prepreka. Stoga smo razmišljali o tome kako izolirati korisnike jedne od drugih na nivou mreže kako bi mogli samostalno birati IP opsege.
Šta vam prvo padne na pamet kada pomislite na mrežnu izolaciju? Svakako VLAN и VRF - Virtualno usmjeravanje i prosljeđivanje.
Nažalost, nije uspjelo. VLAN ID je samo 12 bita, što nam daje samo 4096 izolovanih segmenata. Čak i najveći prekidači mogu koristiti najviše 1-2 hiljade VRF-ova. Korišćenje VRF-a i VLAN-a zajedno daje nam samo nekoliko miliona podmreža. Ovo definitivno nije dovoljno za desetine miliona stanara, od kojih svaki mora biti u mogućnosti da koristi više podmreža.
Takođe jednostavno ne možemo sebi priuštiti kupovinu potrebnog broja velikih kutija, na primjer, od Cisco-a ili Junipera. Dva su razloga: ludo je skupo, a mi ne želimo da budemo na milosti njihove politike razvoja i krpljenja.
Postoji samo jedan zaključak - napravite svoje rješenje.
2009. smo objavili VPC - Virtualni privatni oblak. Ime se zadržalo i sada ga koriste i mnogi provajderi oblaka.
VPC je virtuelna mreža SDN (Softverski definisana mreža). Odlučili smo da ne izmišljamo posebne protokole na L2 i L3 nivoima. Mreža radi na standardnom Ethernetu i IP-u. Za prijenos preko mreže, promet virtuelne mašine je inkapsuliran u naš vlastiti omotač protokola. Označava ID koji pripada VPC-u zakupca.
Zvuči jednostavno. Međutim, postoji nekoliko ozbiljnih tehničkih izazova koje treba savladati. 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 skali, ovo je ogromna tabela koja bi trebala raditi s minimalnim kašnjenjima pristupa. Odgovoran za ovo usluga mapiranja, koji se širi u tankom sloju po cijeloj mreži.
U mašinama nove generacije, enkapsulaciju obavljaju Nitro kartice na hardverskom nivou. U starijim slučajevima, enkapsulacija i dekapsulacija su softverski zasnovane.
Hajde da shvatimo kako to funkcionira općenito. Počnimo sa L2 nivoom. Pretpostavimo da imamo virtuelnu mašinu sa IP 10.0.0.2 na fizičkom serveru 192.168.0.3. Šalje podatke virtuelnoj mašini 10.0.0.3, koja živi na 192.168.1.4. ARP zahtjev se generiše i šalje mrežnoj Nitro kartici. Radi jednostavnosti, pretpostavljamo da obe virtuelne mašine žive u istom „plavom“ VPC-u.
Mapa zamjenjuje izvornu adresu svojom i prosljeđuje ARP okvir servisu za mapiranje.
Usluga mapiranja vraća informacije koje su neophodne za prijenos preko L2 fizičke mreže.
Nitro kartica u ARP odgovoru zamjenjuje MAC na fizičkoj mreži sa adresom u VPC-u.
Prilikom prijenosa podataka umotavamo logički MAC i IP u VPC omot. Sve to prenosimo preko fizičke mreže koristeći odgovarajuće izvorne i odredišne IP Nitro kartice.
Provjeru obavlja fizička mašina kojoj je paket namijenjen. Ovo je neophodno kako bi se spriječila mogućnost lažiranja adrese. Mašina šalje poseban zahtev servisu za mapiranje i pita: „Sa fizičke mašine 192.168.0.3 primio sam paket koji je namenjen za 10.0.0.3 u plavom VPC-u. Je li on legitiman?
Usluga mapiranja provjerava svoju tabelu alokacije resursa i dozvoljava ili odbija prolazak paketa. U svim novim slučajevima, dodatna validacija je ugrađena u Nitro kartice. Nemoguće ga je zaobići čak ni teoretski. Stoga lažiranje resursa u drugom VPC-u neće raditi.
Zatim se podaci šalju na virtuelnu mašinu za koju su namenjeni.
Usluga mapiranja također radi kao logički ruter za prijenos podataka između virtuelnih mašina u različitim podmrežama. Sve je konceptualno jednostavno, neću ulaziti u detalje.
Ispostavilo se da se pri prijenosu svakog paketa serveri okreću servisu mapiranja. Kako se nositi sa neizbježnim kašnjenjima? Keširanje, naravno.
Ljepota je u tome što ne morate keširati cijelu ogromnu tablicu. Fizički server ugošćuje virtuelne mašine iz relativno malog broja VPC-ova. Trebate samo keširati informacije o ovim VPC-ovima. Prijenos podataka na druge VPC-ove u “podrazumevanoj” konfiguraciji još uvijek nije legitiman. Ako se koristi funkcionalnost kao što je VPC-peering, tada se informacije o odgovarajućim VPC-ovima dodatno učitavaju u keš memoriju.
Sredili smo prenos podataka u VPC.
Blackfoot
Što učiniti u slučajevima kada je promet potrebno prenijeti van, na primjer na Internet ili preko VPN-a na zemlju? Pomaže nam ovdje Blackfoot — AWS interna usluga. Razvio ga je naš južnoafrički tim. Zato je usluga nazvana po pingvinu koji živi u Južnoj Africi.
Blackfoot dekapsulira saobraćaj i radi ono što je potrebno s njim. Podaci se šalju na Internet takvi kakvi jesu.
Podaci se dekapsuliraju i ponovo umotaju 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 praćenje stanja protoka podataka. Na primjer, kada se koristi NAT, kontrola toka mora osigurati da svaki par IP:odredišni port ima jedinstveni izlazni port. U slučaju balansera NLB - Mrežni balanser opterećenja, tok podataka treba uvijek biti usmjeren na istu ciljnu virtuelnu mašinu. Sigurnosne grupe su zaštitni zid sa stanjem. On prati dolazni saobraćaj i implicitno otvara portove za odlazni tok paketa.
U AWS oblaku, zahtjevi za kašnjenje prijenosa su izuzetno visoki. Zbog toga HyperPlane kritične za performanse cijele mreže.
Hyperplane je izgrađen na EC2 virtuelnim mašinama. Ovdje nema magije, samo lukavstva. Trik je u tome što su to virtuelne mašine sa velikom RAM memorijom. Operacije su transakcijske i izvode se isključivo u memoriji. Ovo vam omogućava da postignete kašnjenje od samo desetina mikrosekundi. Rad sa diskom bi ubio svu produktivnost.
Hyperplane je distribuirani sistem velikog broja takvih EC2 mašina. Svaka virtuelna mašina ima propusni opseg od 5 GB/s. U cijeloj regionalnoj mreži, ovo pruža nevjerovatne terabite propusnog opsega i omogućava obradu miliona veza u sekundi.
HyperPlane radi samo sa streamovima. Enkapsulacija VPC paketa je potpuno transparentna za njega. Potencijalna ranjivost u ovoj internoj usluzi i dalje bi spriječila da se VPC izolacija prekine. Nivoi ispod su odgovorni za sigurnost.
Bučan komšija
Još uvijek postoji problem bučni komšija - bučni komšija. 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 veoma moćni i teško ih je preopteretiti.
Ali mi gradimo našu arhitekturu na osnovu čak i malo vjerojatnih scenarija.
Mala vjerovatnoća ne znači i nemoguće.
Možemo zamisliti situaciju u kojoj bi jedan ili više korisnika generiralo previše opterećenja. Svi HyperPlane čvorovi uključeni su u obradu ovog opterećenja i drugi korisnici bi potencijalno mogli doživjeti neku vrstu smanjenja performansi. Ovo razbija koncept oblaka, u kojem stanari nemaju mogućnost da utiču jedni na druge.
Kako riješiti problem bučnog susjeda? Prva stvar koja vam pada na pamet je šaranje. Naših 8 čvorova logično je podijeljeno u 4 dijela od po 2 čvora. Sada će bučni susjed uznemiravati samo četvrtinu svih korisnika, ali će ih jako ometati.
Uradimo stvari drugačije. Svakom korisniku ćemo dodijeliti samo 3 čvora.
Trik je u nasumičnom dodjeljivanju čvorova različitim korisnicima. Na slici ispod, plavi korisnik siječe čvorove s jednim od druga dva korisnika - zelenim i narandžastim.
Sa 8 čvorova i 3 korisnika, vjerovatnoća da će se bučni susjed ukrstiti s jednim od korisnika je 54%. Sa ovom vjerovatnoćom će plavi korisnik utjecati na druge stanare. U isto vrijeme, samo dio svog opterećenja. U našem primjeru, ovaj utjecaj će barem nekako biti vidljiv ne svima, već samo trećini svih korisnika. Ovo je već dobar rezultat.
Broj korisnika koji će se ukrštati
Vjerovatnoća 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, nijedan od čvorova se neće preseći sa verovatnoćom od 77%.
Broj korisnika koji će se ukrštati
Vjerovatnoća u postocima
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
U stvarnoj situaciji, sa ogromnim brojem HyperPlane čvorova i korisnika, potencijalni utjecaj bučnog susjeda na druge korisnike je minimalan. Ova metoda se zove miješanje shardinga - shuffle shading. Minimizira negativan efekat kvara čvora.
Mnogi servisi su izgrađeni na bazi HyperPlane-a: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Mrežna skala
Sada razgovarajmo o skali same mreže. Za oktobar 2019. AWS nudi svoje usluge u 22 regiona, a planirano je još 9.
- Svaka regija sadrži nekoliko zona dostupnosti. Ima ih 69 širom svijeta.
- Svaki AZ se sastoji od centara za obradu podataka. Ukupno ih nema više od 8.
- Data centar ima ogroman broj servera, neki i do 300.
Hajde da sve ovo usredsredimo, pomnožimo i dobijemo impresivnu cifru koja odražava Razmjera Amazonskog oblaka.
Postoji mnogo optičkih veza između zona dostupnosti i data centra. U jednom od naših najvećih regiona postavljeno je 388 kanala samo za AZ komunikaciju između međusobno i komunikacionih centara sa drugim regionima (Tranzitni centri). Sve u svemu ovo daje ludilo 5000 Tbit.
Backbone AWS je napravljen posebno za oblak i optimizovan za njega. Mi to gradimo na kanalima 100 GB / s. Mi ih potpuno kontrolišemo, sa izuzetkom regiona u Kini. Saobraćaj se ne dijeli sa teretom drugih kompanija.
Naravno, mi nismo jedini provajder oblaka sa privatnom okosnom mrežom. Sve više velikih kompanija ide ovim putem. To potvrđuju nezavisni istraživači, na primjer iz .
Grafikon pokazuje da udio provajdera sadržaja i cloud provajdera raste. Zbog toga se udio internet saobraćaja okosnih provajdera konstantno smanjuje.
Objasniću zašto se to dešava. Ranije je većina web usluga bila dostupna i konzumirana direktno s interneta. Danas se sve više servera nalazi u oblaku i dostupno im je putem CDN - Mreža za distribuciju sadržaja. Da bi pristupio resursu, korisnik ide putem interneta samo do najbližeg CDN PoP - Point of Presence. Najčešće je negdje u blizini. Zatim napušta javni internet i leti kroz privatnu okosnicu preko Atlantika, na primjer, i dolazi direktno do izvora.
Pitam se kako će se Internet promijeniti za 10 godina ako se ovaj trend nastavi?
Fizički kanali
Naučnici još nisu shvatili kako da povećaju brzinu svjetlosti u svemiru, ali su napravili veliki napredak u metodama prijenosa kroz optičko vlakno. Trenutno koristimo 6912 fiber kablova. To pomaže u značajnoj optimizaciji troškova njihove instalacije.
U nekim regijama moramo koristiti posebne kablove. Na primjer, u regiji Sydney koristimo kablove sa posebnim premazom protiv termita.
Niko nije imun od nevolja 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 rezultat nesreće, izgubljeno je samo 13 paketa podataka, što je iznenađujuće. Još jednom - samo 13! Sistem se doslovno odmah prebacio na rezervne kanale - vaga radi.
Prošli smo kroz neke od Amazonovih cloud usluga i tehnologija. Nadam se da imate barem neku ideju o obimu zadataka koje naši inženjeri moraju riješiti. Lično, smatram da je ovo veoma uzbudljivo.
Ovo je završni dio trilogije Vasilija Pantjuhina o AWS uređaju. IN dijelovi opisuju optimizaciju servera i skaliranje baze podataka, i in — funkcije bez servera i Firecracker.
U u novembru Vasily Pantyukhin će podijeliti nove detalje o Amazon uređaju. On o uzrocima kvarova i dizajnu distribuiranih sistema u Amazonu. 24. oktobar je još uvijek moguć kartu po povoljnoj cijeni, a platite kasnije. Čekamo vas u HighLoad++, dođite i razgovarajmo!
izvor: www.habr.com