L'escala de la xarxa d'Amazon Web Services és de 69 zones arreu del món en 22 regions: EUA, Europa, Àsia, Àfrica i Austràlia. Cada zona conté fins a 8 centres de dades: centres de processament de dades. Cada centre de dades té milers o centenars de milers de servidors. La xarxa està dissenyada de manera que es tinguin en compte tots els escenaris d'interrupció poc probables. Per exemple, totes les regions estan aïllades les unes de les altres i les zones d'accessibilitat estan separades en distàncies de diversos quilòmetres. Fins i tot si talleu el cable, el sistema canviarà als canals de còpia de seguretat i la pèrdua d'informació suposarà uns quants paquets de dades. Vasily Pantyukhin parlarà sobre quins altres principis es basa la xarxa i com s'estructura.
Vasili Pantiukhin va començar com a administrador Unix en empreses .ru, va treballar en un gran maquinari Sun Microsystem durant 6 anys i va predicar un món centrat en dades durant 11 anys a EMC. Naturalment, va evolucionar cap a núvols privats, després es va traslladar a núvols públics. Ara, com a arquitecte d'Amazon Web Services, proporciona assessorament tècnic per ajudar a viure i desenvolupar-se al núvol AWS.
A la part anterior de la trilogia AWS, Vasily va aprofundir en el disseny de servidors físics i l'escala de bases de dades. Targetes Nitro, hipervisor personalitzat basat en KVM, base de dades d'Amazon Aurora: sobre tot això al material "" Llegeix per context o mira discursos.
Aquesta part se centrarà en l'escalat de la xarxa, un dels sistemes més complexos d'AWS. L'evolució d'una xarxa plana a un núvol privat virtual i el seu disseny, serveis interns de Blackfoot i HyperPlane, el problema d'un veí sorollós i, al final, l'escala de la xarxa, la columna vertebral i els cables físics. Sobre tot això sota el tall.
Exempció de responsabilitat: tot el que es mostra a continuació és l'opinió personal de Vasily i pot no coincidir amb la posició d'Amazon Web Services.
Escalat de la xarxa
El núvol AWS es va llançar el 2006. La seva xarxa era força primitiva, amb una estructura plana. La gamma d'adreces privades era comuna a tots els inquilins del núvol. Quan inicieu una màquina virtual nova, heu rebut accidentalment una adreça IP disponible d'aquest rang.
Aquest enfocament va ser fàcil d'implementar, però va limitar fonamentalment l'ús del núvol. En particular, va ser bastant difícil desenvolupar solucions híbrides que combinessin xarxes privades sobre el terreny i en AWS. El problema més comú va ser la superposició d'intervals d'adreces IP.
Núvol privat virtual
El núvol va resultar ser molt demandat. Ha arribat el moment de pensar en l'escalabilitat i la possibilitat que desenes de milions de llogaters puguin utilitzar-lo. La xarxa plana s'ha convertit en un obstacle important. Per tant, vam pensar com aïllar els usuaris els uns dels altres a nivell de xarxa perquè poguessin triar intervals IP de manera independent.
Què és el primer que us ve al cap quan penseu en l'aïllament de la xarxa? Certament VLAN и VRF - Enrutament i reenviament virtual.
Malauradament, no va funcionar. L'ID de VLAN només té 12 bits, cosa que ens ofereix només 4096 segments aïllats. Fins i tot els interruptors més grans poden utilitzar un màxim d'1-2 mil VRF. L'ús de VRF i VLAN junts ens ofereix només uns quants milions de subxarxes. Definitivament, això no és suficient per a desenes de milions d'inquilins, cadascun dels quals ha de poder utilitzar diverses subxarxes.
Tampoc no ens podem permetre el luxe de comprar el nombre necessari de caixes grans, per exemple, a Cisco o Juniper. Hi ha dos motius: és boig car i no volem estar a mercè de les seves polítiques de desenvolupament i pedaç.
Només hi ha una conclusió: feu la vostra pròpia solució.
El 2009 vam anunciar VPC - Núvol privat virtual. El nom es va quedar enganxat i ara molts proveïdors de núvol també l'utilitzen.
VPC és una xarxa virtual SDN (Xarxa definida per programari). Vam decidir no inventar protocols especials als nivells L2 i L3. La xarxa funciona amb Ethernet i IP estàndard. Per a la transmissió a la xarxa, el trànsit de màquines virtuals s'encapsula al nostre propi embolcall de protocol. Indica l'identificador que pertany a la VPC del llogater.
Sona senzill. Tanmateix, hi ha diversos reptes tècnics seriosos que cal superar. Per exemple, on i com emmagatzemar les dades sobre l'assignació d'adreces MAC/IP virtuals, ID de VPC i MAC/IP físic corresponent. A escala AWS, aquesta és una taula enorme que hauria de funcionar amb retards d'accés mínims. Responsable d'això servei de cartografia, que s'estén en una capa fina per tota la xarxa.
A les màquines de nova generació, l'encapsulació es realitza mitjançant targetes Nitro a nivell de maquinari. En casos més antics, l'encapsulació i la decapsulació es basen en programari.
Anem a veure com funciona en termes generals. Comencem pel nivell L2. Suposem que tenim una màquina virtual amb IP 10.0.0.2 en un servidor físic 192.168.0.3. Envia dades a la màquina virtual 10.0.0.3, que viu a 192.168.1.4. Es genera una sol·licitud ARP i s'envia a la targeta Nitro de xarxa. Per simplificar, suposem que ambdues màquines virtuals viuen al mateix VPC "blau".
El mapa substitueix l'adreça d'origen per la seva pròpia i reenvia la trama ARP al servei de mapes.
El servei de mapes retorna la informació necessària per a la transmissió a través de la xarxa física L2.
La targeta Nitro a la resposta ARP substitueix el MAC de la xarxa física per una adreça a la VPC.
Quan transferim dades, emboliquem MAC i IP lògics en un embolcall de VPC. Tot això ho transmetem per la xarxa física utilitzant les targetes Nitro IP d'origen i de destinació adequades.
La màquina física a la qual va destinat el paquet realitza la comprovació. Això és necessari per evitar la possibilitat de falsificació d'adreces. La màquina envia una sol·licitud especial al servei de mapes i pregunta: "De la màquina física 192.168.0.3 he rebut un paquet destinat a 10.0.0.3 al VPC blau. És legítim?
El servei de mapes comprova la seva taula d'assignació de recursos i permet o denega que el paquet passi. En tots els casos nous, la validació addicional s'incorpora a les targetes Nitro. És impossible evitar-ho ni tan sols teòricament. Per tant, la falsificació de recursos en un altre VPC no funcionarà.
A continuació, les dades s'envien a la màquina virtual a la qual estan destinades.
El servei de mapes també funciona com un encaminador lògic per transferir dades entre màquines virtuals en diferents subxarxes. Tot és conceptualment senzill, no entraré en detalls.
Resulta que quan transmeten cada paquet, els servidors recorren al servei de mapes. Com afrontar els retards inevitables? Emmagatzematge a la memòria cau, és clar.
La bellesa és que no cal emmagatzemar a la memòria cau tota la gran taula. Un servidor físic allotja màquines virtuals d'un nombre relativament petit de VPC. Només cal que emmagatzemeu la informació a la memòria cau sobre aquestes VPC. Transferir dades a altres VPC amb la configuració "predeterminada" encara no és legítim. Si s'utilitza una funcionalitat com ara el peering de VPC, la informació sobre els VPC corresponents es carrega addicionalment a la memòria cau.
Hem resolt la transferència de dades al VPC.
Peus negres
Què fer en els casos en què el trànsit s'ha de transmetre a l'exterior, per exemple a Internet o a terra mitjançant VPN? Ens ajuda aquí Peus negres - Servei intern d'AWS. Està desenvolupat pel nostre equip sud-africà. És per això que el servei porta el nom d'un pingüí que viu a Sud-àfrica.
Blackfoot descapsula el trànsit i fa el que calgui amb ell. Les dades s'envien a Internet tal com estan.
Les dades es descapsulen i es tornen a embolicar a IPsec quan s'utilitza una VPN.
Quan s'utilitza la connexió directa, el trànsit s'etiqueta i s'envia a la VLAN adequada.
HiperPlan
Aquest és un servei de control de flux intern. Molts serveis de xarxa requereixen supervisió estats de flux de dades. Per exemple, quan s'utilitza NAT, el control de flux ha de garantir que cada parell IP:port de destinació tingui un port de sortida únic. En el cas d'un equilibrador NLB - Equilibrador de càrrega de xarxa, el flux de dades s'ha de dirigir sempre a la mateixa màquina virtual de destinació. Security Groups és un tallafoc amb estat. Supervisa el trànsit entrant i implícitament obre ports per al flux de paquets sortints.
Al núvol AWS, els requisits de latència de transmissió són extremadament alts. Aixo es perqué HiperPlan fonamental per al rendiment de tota la xarxa.
Hyperplane es basa en màquines virtuals EC2. Aquí no hi ha màgia, només astúcia. El truc és que es tracta de màquines virtuals amb gran memòria RAM. Les operacions són transaccionals i es realitzen exclusivament a la memòria. Això us permet aconseguir retards de només desenes de microsegons. Treballar amb el disc mataria tota la productivitat.
Hyperplane és un sistema distribuït d'un gran nombre d'aquestes màquines EC2. Cada màquina virtual té una amplada de banda de 5 GB/s. A tota la xarxa regional, això proporciona terabits increïbles d'ample de banda i permet el processament milions de connexions per segon.
HyperPlane només funciona amb fluxos. L'encapsulació de paquets VPC és completament transparent per a això. Una vulnerabilitat potencial en aquest servei intern encara impediria que es trenqui l'aïllament de la VPC. Els nivells següents són els responsables de la seguretat.
Veí sorollós
Encara hi ha un problema veí sorollós - veí sorollós. Suposem que tenim 8 nodes. Aquests nodes processen els fluxos de tots els usuaris del núvol. Sembla que tot va bé i la càrrega s'ha de distribuir uniformement entre tots els nodes. Els nodes són molt potents i és difícil sobrecarregar-los.
Però construïm la nostra arquitectura a partir d'escenaris fins i tot poc probables.
Baixa probabilitat no vol dir impossible.
Ens podem imaginar una situació en què un o més usuaris generarien massa càrrega. Tots els nodes d'HyperPlane participen en el processament d'aquesta càrrega i altres usuaris podrien experimentar algun tipus d'impacte de rendiment. Això trenca el concepte del núvol, en què els llogaters no tenen capacitat d'influència entre ells.
Com resoldre el problema d'un veí sorollós? El primer que em ve al cap és el fragment. Els nostres 8 nodes es divideixen lògicament en 4 fragments de 2 nodes cadascun. Ara un veí sorollós molestarà només una quarta part dels usuaris, però els molestarà molt.
Fem les coses d'una altra manera. Assignarem només 3 nodes a cada usuari.
El truc és assignar nodes aleatòriament a diferents usuaris. A la imatge següent, l'usuari blau creua els nodes amb un dels altres dos usuaris: verd i taronja.
Amb 8 nodes i 3 usuaris, la probabilitat que un veí sorollós es talli amb un dels usuaris és del 54%. És amb aquesta probabilitat que un usuari blau influirà en altres inquilins. Al mateix temps, només una part de la seva càrrega. En el nostre exemple, aquesta influència es notarà almenys d'alguna manera no per a tothom, sinó només per a un terç de tots els usuaris. Aquest ja és un bon resultat.
Nombre d'usuaris que es creuaran
Probabilitat en percentatge
0
18%
1
54%
2
26%
3
2%
Apropem la situació a la realitat: posem 100 nodes i 5 usuaris en 5 nodes. En aquest cas, cap dels nodes es tallarà amb una probabilitat del 77%.
Nombre d'usuaris que es creuaran
Probabilitat en percentatge
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
En una situació real, amb un gran nombre de nodes i usuaris d'HyperPlane, l'impacte potencial d'un veí sorollós en altres usuaris és mínim. Aquest mètode s'anomena barreja de fragments - remenar fragments. Minimitza l'efecte negatiu de la fallada del node.
Molts serveis es construeixen a partir d'HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Escala de xarxa
Ara parlem de l'escala de la pròpia xarxa. Per a l'octubre de 2019, AWS ofereix els seus serveis a 22 regions, i 9 més estan previstes.
- Cada regió conté diverses zones de disponibilitat. N'hi ha 69 arreu del món.
- Cada AZ consta de centres de processament de dades. No n'hi ha més de 8 en total.
- El centre de dades allotja un gran nombre de servidors, alguns amb fins a 300.
Ara fem la mitjana de tot això, multipliquem i obtenim una xifra impressionant que reflecteixi Escala del núvol d'Amazon.
Hi ha molts enllaços òptics entre les zones de disponibilitat i el centre de dades. En una de les nostres regions més grans, s'han establert 388 canals només per a la comunicació AZ entre ells i els centres de comunicació amb altres regions (centres de trànsit). En total això dóna bogeria 5000 Tbit.
Backbone AWS està dissenyat específicament i optimitzat per al núvol. Ho construïm als canals 100 GB / s. Els controlem completament, amb l'excepció de les regions de la Xina. El trànsit no es comparteix amb les càrregues d'altres empreses.
Per descomptat, no som l'únic proveïdor de núvol amb una xarxa troncal privada. Cada cop són més les grans empreses que segueixen aquest camí. Això ho confirmen investigadors independents, per exemple de .
El gràfic mostra que la quota de proveïdors de contingut i proveïdors de núvol està creixent. A causa d'això, la quota de trànsit d'Internet dels proveïdors de backbone està en constant disminució.
Explicaré per què passa això. Anteriorment, la majoria dels serveis web eren accessibles i consumits directament des d'Internet. Avui en dia, cada cop hi ha més servidors que es troben al núvol i són accessibles mitjançant CDN - Xarxa de distribució de contingut. Per accedir a un recurs, l'usuari passa per Internet només al CDN PoP més proper - Punt de presència. Molt sovint es troba en algun lloc proper. Aleshores surt d'Internet pública i vola a través d'una columna vertebral privada a través de l'Atlàntic, per exemple, i arriba directament al recurs.
Em pregunto com canviarà Internet d'aquí a 10 anys si aquesta tendència continua?
Canals físics
Els científics encara no han descobert com augmentar la velocitat de la llum a l'Univers, però han avançat molt en els mètodes de transmissió a través de la fibra òptica. Actualment utilitzem cables de fibra 6912. Això ajuda a optimitzar significativament el cost de la seva instal·lació.
En algunes regions hem d'utilitzar cables especials. Per exemple, a la regió de Sydney fem servir cables amb un recobriment especial contra tèrmits.
Ningú és immune als problemes i, de vegades, els nostres canals es fan malbé. La foto de la dreta mostra cables òptics en una de les regions americanes que van ser esquinçats pels treballadors de la construcció. Com a conseqüència de l'accident, només es van perdre 13 paquets de dades, la qual cosa és sorprenent. Un cop més, només 13! El sistema va canviar literalment a l'instant als canals de còpia de seguretat: l'escala funciona.
Hem galopat per alguns dels serveis i tecnologies al núvol d'Amazon. Espero que tingueu almenys una idea de l'escala de les tasques que els nostres enginyers han de resoldre. Personalment, ho trobo molt emocionant.
Aquesta és la part final de la trilogia de Vasily Pantyukhin sobre el dispositiu AWS. EN les parts descriuen l'optimització del servidor i l'escala de la base de dades, i en — Funcions sense servidor i Firecracker.
En al novembre Vasily Pantyukhin compartirà nous detalls del dispositiu Amazon. Ell sobre les causes dels errors i el disseny de sistemes distribuïts a Amazon. El 24 d'octubre encara és possible entrada a bon preu, i pagar més tard. T'esperem a HighLoad++, vine i xerrem!
Font: www.habr.com