Amploarea rețelei Amazon Web Services este de 69 de zone din întreaga lume, în 22 de regiuni: SUA, Europa, Asia, Africa și Australia. Fiecare zonă conține până la 8 centre de date - Centre de procesare a datelor. Fiecare centru de date are mii sau sute de mii de servere. Rețeaua este proiectată astfel încât să fie luate în considerare toate scenariile de întrerupere improbabile. De exemplu, toate regiunile sunt izolate unele de altele, iar zonele de accesibilitate sunt separate pe distanțe de câțiva kilometri. Chiar dacă tăiați cablul, sistemul va trece la canalele de rezervă, iar pierderea de informații se va ridica la câteva pachete de date. Vasily Pantyukhin va vorbi despre ce alte principii este construită rețeaua și cum este structurată.
Vasily Pantyukhin a început ca administrator Unix în companii .ru, a lucrat la hardware-ul mare Sun Microsystem timp de 6 ani și a predicat o lume centrată pe date timp de 11 ani la EMC. A evoluat în mod natural în cloud-uri private, apoi s-a mutat în cele publice. Acum, în calitate de arhitect Amazon Web Services, oferă consiliere tehnică pentru a vă ajuta să trăiți și să vă dezvoltați în cloudul AWS.
În partea anterioară a trilogiei AWS, Vasily sa aprofundat în proiectarea serverelor fizice și în scalarea bazelor de date. Carduri Nitro, hypervisor personalizat bazat pe KVM, bază de date Amazon Aurora - despre toate acestea în material "" Citiți pentru context sau vizionați discursuri.
Această parte se va concentra pe scalarea rețelei, unul dintre cele mai complexe sisteme din AWS. Evoluția de la o rețea plată la un Virtual Private Cloud și designul acestuia, serviciile interne ale Blackfoot și HyperPlane, problema unui vecin zgomotos, iar la final - amploarea rețelei, a cablurilor vertebrale și a cablurilor fizice. Despre toate acestea sub tăietură.
Disclaimer: totul de mai jos este opinia personală a lui Vasily și este posibil să nu coincidă cu poziția Amazon Web Services.
Scalarea rețelei
Cloud-ul AWS a fost lansat în 2006. Rețeaua lui era destul de primitivă - cu o structură plată. Gama de adrese private a fost comună tuturor chiriașilor cloud. Când porniți o nouă mașină virtuală, ați primit accidental o adresă IP disponibilă din acest interval.
Această abordare a fost ușor de implementat, dar a limitat în mod fundamental utilizarea cloud-ului. În special, a fost destul de dificil să se dezvolte soluții hibride care să combine rețele private pe teren și în AWS. Cea mai frecventă problemă a fost suprapunerea intervalelor de adrese IP.
Cloud privat virtual
Norul s-a dovedit a fi solicitat. A sosit momentul să ne gândim la scalabilitate și la posibilitatea utilizării acesteia de către zeci de milioane de chiriași. Rețeaua plată a devenit un obstacol major. Prin urmare, ne-am gândit cum să izolăm utilizatorii unii de alții la nivel de rețea, astfel încât aceștia să poată alege în mod independent intervalele IP.
Care este primul lucru care vă vine în minte când vă gândiți la izolarea rețelei? Cu siguranță VLAN и VRF - Rutare și redirecționare virtuală.
Din păcate, nu a funcționat. ID-ul VLAN este de numai 12 biți, ceea ce ne oferă doar 4096 de segmente izolate. Chiar și cele mai mari switch-uri pot folosi maximum 1-2 mii VRF-uri. Utilizarea VRF și VLAN împreună ne oferă doar câteva milioane de subrețele. Acest lucru cu siguranță nu este suficient pentru zeci de milioane de chiriași, dintre care fiecare trebuie să poată utiliza mai multe subrețele.
De asemenea, pur și simplu nu ne permitem să cumpărăm numărul necesar de cutii mari, de exemplu, de la Cisco sau Juniper. Există două motive: este nebun de scump și nu vrem să fim la cheremul politicilor lor de dezvoltare și corecție.
Există o singură concluzie - fă-ți propria soluție.
În 2009 am anunțat VPC - Cloud privat virtual. Numele a rămas și acum mulți furnizori de cloud îl folosesc și ei.
VPC este o rețea virtuală SDN (Rețea definită de software). Am decis să nu inventăm protocoale speciale la nivelurile L2 și L3. Rețeaua rulează pe Ethernet și IP standard. Pentru transmisia prin rețea, traficul mașinii virtuale este încapsulat în propriul nostru pachet de protocol. Indică ID-ul care aparține VPC-ului chiriașului.
Sună simplu. Cu toate acestea, există câteva provocări tehnice serioase care trebuie depășite. De exemplu, unde și cum să stocați datele despre maparea adreselor MAC/IP virtuale, ID-ul VPC și MAC/IP-ul fizic corespunzător. La scara AWS, acesta este un tabel uriaș care ar trebui să funcționeze cu întârzieri minime de acces. Responsabil pentru asta serviciu de cartografiere, care este răspândit într-un strat subțire în întreaga rețea.
La mașinile de nouă generație, încapsularea este realizată de carduri Nitro la nivel hardware. În cazuri mai vechi, încapsularea și decapsularea sunt bazate pe software.
Să ne dăm seama cum funcționează în termeni generali. Să începem cu nivelul L2. Să presupunem că avem o mașină virtuală cu IP 10.0.0.2 pe un server fizic 192.168.0.3. Trimite date către mașina virtuală 10.0.0.3, care trăiește pe 192.168.1.4. O solicitare ARP este generată și trimisă către cardul Nitro de rețea. Pentru simplitate, presupunem că ambele mașini virtuale trăiesc în același VPC „albastru”.
Harta înlocuiește adresa sursă cu propria sa și trimite cadrul ARP către serviciul de cartografiere.
Serviciul de cartografiere returnează informații care sunt necesare pentru transmiterea prin rețeaua fizică L2.
Cardul Nitro din răspunsul ARP înlocuiește MAC-ul din rețeaua fizică cu o adresă în VPC.
Când transferăm date, împachetăm MAC și IP logic într-un pachet VPC. Transmitem toate acestea prin rețeaua fizică folosind cardurile IP Nitro sursă și destinație corespunzătoare.
Aparatul fizic căruia îi este destinat coletul efectuează verificarea. Acest lucru este necesar pentru a preveni posibilitatea falsării adresei. Mașina trimite o cerere specială serviciului de cartografiere și întreabă: „De la mașina fizică 192.168.0.3 am primit un pachet care este destinat pentru 10.0.0.3 în VPC-ul albastru. Este el legitim?
Serviciul de mapare verifică tabelul de alocare a resurselor și permite sau interzice trecerea pachetului. În toate cazurile noi, validarea suplimentară este încorporată în cardurile Nitro. Este imposibil să o ocoliți chiar și teoretic. Prin urmare, falsificarea resurselor dintr-un alt VPC nu va funcționa.
Apoi, datele sunt trimise la mașina virtuală pentru care sunt destinate.
Serviciul de cartografiere funcționează și ca un router logic pentru transferul de date între mașinile virtuale din diferite subrețele. Totul este simplu din punct de vedere conceptual, nu voi intra în detalii.
Se pare că atunci când transmit fiecare pachet, serverele apelează la serviciul de cartografiere. Cum să faceți față întârzierilor inevitabile? Memorarea în cache, desigur.
Frumusețea este că nu trebuie să păstrați în cache întreaga masă uriașă. Un server fizic găzduiește mașini virtuale dintr-un număr relativ mic de VPC-uri. Trebuie doar să memorați în cache informații despre aceste VPC-uri. Transferarea datelor către alte VPC-uri în configurația „implicit” încă nu este legitimă. Dacă se utilizează o funcționalitate cum ar fi VPC-peering, atunci informațiile despre VPC-urile corespunzătoare sunt încărcate suplimentar în cache.
Am rezolvat transferul de date către VPC.
Blackfoot
Ce trebuie făcut în cazurile în care traficul trebuie transmis în exterior, de exemplu către Internet sau prin VPN la sol? Ne ajută aici Blackfoot - serviciu intern AWS. Este dezvoltat de echipa noastră din Africa de Sud. De aceea, serviciul poartă numele unui pinguin care trăiește în Africa de Sud.
Blackfoot decapsulează traficul și face ceea ce este necesar cu el. Datele sunt trimise pe Internet așa cum sunt.
Datele sunt decapsulate și împachetate din nou în IPsec atunci când utilizați un VPN.
Când utilizați Direct Connect, traficul este etichetat și trimis către VLAN-ul corespunzător.
HyperPlane
Acesta este un serviciu de control intern al fluxului. Multe servicii de rețea necesită monitorizare stări ale fluxului de date. De exemplu, când se utilizează NAT, controlul fluxului trebuie să se asigure că fiecare pereche IP:port de destinație are un port unic de ieșire. În cazul unui echilibrator NLB - Network Load Balancer, fluxul de date ar trebui să fie întotdeauna direcționat către aceeași mașină virtuală țintă. Security Groups este un firewall cu stare. Monitorizează traficul de intrare și implicit deschide porturi pentru fluxul de pachete de ieșire.
În cloud-ul AWS, cerințele privind latența transmisiei sunt extrem de mari. De aceea HyperPlane critică pentru performanța întregii rețele.
Hyperplane este construit pe mașini virtuale EC2. Nu există magie aici, doar viclenie. Trucul este că acestea sunt mașini virtuale cu memorie RAM mare. Operațiunile sunt tranzacționale și sunt efectuate exclusiv în memorie. Acest lucru vă permite să obțineți întârzieri de numai zeci de microsecunde. Lucrul cu discul ar distruge toată productivitatea.
Hyperplane este un sistem distribuit al unui număr mare de astfel de mașini EC2. Fiecare mașină virtuală are o lățime de bandă de 5 GB/s. În întreaga rețea regională, aceasta oferă terabiți incredibili de lățime de bandă și permite procesarea milioane de conexiuni pe secundă.
HyperPlane funcționează numai cu fluxuri. Încapsularea pachetelor VPC este complet transparentă pentru aceasta. O potențială vulnerabilitate în acest serviciu intern ar împiedica în continuare ruperea izolației VPC. Nivelurile de mai jos sunt responsabile de securitate.
Vecin zgomotos
Mai este o problemă vecinul zgomotos - vecinul zgomotos. Să presupunem că avem 8 noduri. Aceste noduri procesează fluxurile tuturor utilizatorilor de cloud. Totul pare să fie în regulă și sarcina ar trebui să fie distribuită uniform pe toate nodurile. Nodurile sunt foarte puternice și este dificil să le supraîncărcați.
Dar ne construim arhitectura pe baza chiar și pe scenarii improbabile.
Probabilitate scăzută nu înseamnă imposibil.
Ne putem imagina o situație în care unul sau mai mulți utilizatori ar genera prea multă sarcină. Toate nodurile HyperPlane sunt implicate în procesarea acestei încărcări, iar alți utilizatori ar putea experimenta un fel de afectare a performanței. Acest lucru rupe conceptul de cloud, în care chiriașii nu au capacitatea de a se influența reciproc.
Cum să rezolvi problema unui vecin zgomotos? Primul lucru care îmi vine în minte este fragmentarea. Cele 8 noduri ale noastre sunt împărțite logic în 4 fragmente a câte 2 noduri fiecare. Acum un vecin zgomotos va deranja doar un sfert din toți utilizatorii, dar îi va deranja foarte mult.
Să facem lucrurile altfel. Vom aloca doar 3 noduri fiecărui utilizator.
Trucul este să atribuiți aleatoriu noduri diferiților utilizatori. În imaginea de mai jos, utilizatorul albastru intersectează nodurile cu unul dintre ceilalți doi utilizatori - verde și portocaliu.
Cu 8 noduri și 3 utilizatori, probabilitatea ca un vecin zgomotos să se intersecteze cu unul dintre utilizatori este de 54%. Cu această probabilitate un utilizator albastru va influența alți chiriași. În același timp, doar o parte din sarcina sa. În exemplul nostru, această influență va fi cel puțin vizibilă nu pentru toată lumea, ci doar pentru o treime din toți utilizatorii. Acesta este deja un rezultat bun.
Numărul de utilizatori care se vor intersecta
Probabilitate în procente
0
18%
1
54%
2
26%
3
2%
Să apropiem situația de realitate - să luăm 100 de noduri și 5 utilizatori pe 5 noduri. În acest caz, niciunul dintre noduri nu se va intersecta cu o probabilitate de 77%.
Numărul de utilizatori care se vor intersecta
Probabilitate în procente
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Într-o situație reală, cu un număr mare de noduri și utilizatori HyperPlane, impactul potențial al unui vecin zgomotos asupra altor utilizatori este minim. Această metodă se numește amestecarea fragmentelor - amestecați amestecul. Minimizează efectul negativ al eșecului nodului.
Multe servicii sunt construite pe baza HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Scara de rețea
Acum să vorbim despre amploarea rețelei în sine. Pentru octombrie 2019, AWS își oferă serviciile în 22 de regiuni, iar încă 9 sunt planificate.
- Fiecare regiune conține mai multe Zone de Disponibilitate. Sunt 69 de ei în întreaga lume.
- Fiecare AZ este format din centre de procesare a datelor. Nu sunt mai mult de 8 în total.
- Centrul de date găzduiește un număr mare de servere, unele cu până la 300.
Acum să facem o medie a tuturor acestor lucruri, să înmulțim și să obținem o cifră impresionantă care să reflecte Amazon cloud scară.
Există multe legături optice între zonele de disponibilitate și centrul de date. Într-una dintre cele mai mari regiuni ale noastre, au fost create 388 de canale doar pentru comunicarea AZ între ele și centrele de comunicare cu alte regiuni (centre de tranzit). În total, asta dă nebunie 5000 Tbit.
Backbone AWS este construit special și optimizat pentru cloud. Îl construim pe canale 100 GB / s. Le controlăm complet, cu excepția regiunilor din China. Traficul nu este împărțit cu încărcăturile altor companii.
Desigur, nu suntem singurul furnizor de cloud cu o rețea backbone privată. Din ce în ce mai multe companii mari urmează această cale. Acest lucru este confirmat de cercetători independenți, de exemplu de la .
Graficul arată că ponderea furnizorilor de conținut și a furnizorilor de cloud este în creștere. Din această cauză, ponderea traficului de internet a furnizorilor de backbone este în scădere constantă.
O să explic de ce se întâmplă asta. Anterior, majoritatea serviciilor web erau accesibile și consumate direct de pe Internet. În zilele noastre, tot mai multe servere sunt situate în cloud și sunt accesibile prin intermediul CDN - Rețeaua de distribuție a conținutului. Pentru a accesa o resursă, utilizatorul trece prin Internet doar la cel mai apropiat CDN PoP - Punct de prezență. Cel mai adesea este undeva în apropiere. Apoi părăsește internetul public și zboară printr-o coloană vertebrală privată peste Atlantic, de exemplu, și ajunge direct la resursă.
Mă întreb cum se va schimba internetul în 10 ani dacă această tendință va continua?
Canale fizice
Oamenii de știință nu și-au dat seama încă cum să crească viteza luminii în Univers, dar au făcut progrese mari în metodele de transmitere a acesteia prin fibra optică. În prezent folosim cabluri de fibră 6912. Acest lucru ajută la optimizarea semnificativă a costului instalării acestora.
În unele regiuni trebuie să folosim cabluri speciale. De exemplu, în regiunea Sydney folosim cabluri cu o acoperire specială împotriva termitelor.
Nimeni nu este imun la necazuri și uneori canalele noastre sunt deteriorate. Fotografia din dreapta arată cabluri optice într-una dintre regiunile americane care au fost rupte de muncitorii în construcții. În urma accidentului s-au pierdut doar 13 pachete de date, ceea ce este surprinzător. Încă o dată - doar 13! Sistemul a trecut literalmente instantaneu la canalele de rezervă - scala funcționează.
Am galopat prin unele dintre serviciile și tehnologiile cloud ale Amazon. Sper că aveți măcar o idee despre amploarea sarcinilor pe care inginerii noștri trebuie să le rezolve. Personal, mi se pare foarte interesant.
Aceasta este ultima parte a trilogiei lui Vasily Pantyukhin despre dispozitivul AWS. ÎN părțile descriu optimizarea serverului și scalarea bazei de date și în — funcții fără server și Firecracker.
Pe în noiembrie, Vasily Pantyukhin va împărtăși noi detalii despre dispozitivul Amazon. El о причинах отказов и проектировании распределенные систем в Amazon. 24 октября еще можно bilet la un preț bun și plătiți mai târziu. Te așteptăm la HighLoad++, vino și hai să stăm pe chat!
Sursa: www.habr.com