A escala da rede de Amazon Web Services é de 69 zonas en todo o mundo en 22 rexións: Estados Unidos, Europa, Asia, África e Australia. Cada zona contén ata 8 centros de datos: centros de procesamento de datos. Cada centro de datos ten miles ou centos de miles de servidores. A rede está deseñada de forma que se teñan en conta todos os escenarios de interrupción improbables. Por exemplo, todas as rexións están illadas unhas das outras e as zonas de accesibilidade están separadas en distancias de varios quilómetros. Aínda que corte o cable, o sistema cambiará ás canles de copia de seguridade e a perda de información suporá uns poucos paquetes de datos. Vasily Pantyukhin falará sobre que outros principios está construída a rede e como se estrutura.
Vasily Pantyukhin comezou como administrador de Unix en empresas .ru, traballou en hardware de gran tamaño Sun Microsystem durante 6 anos e predicou un mundo centrado nos datos durante 11 anos en EMC. Evolucionou naturalmente a nubes privadas, despois pasou a outras públicas. Agora, como arquitecto de Amazon Web Services, ofrece asesoramento técnico para axudar a vivir e desenvolverse na nube de AWS.
Na parte anterior da triloxía de AWS, Vasily afondou no deseño de servidores físicos e no escalado de bases de datos. Tarxetas Nitro, hipervisor personalizado baseado en KVM, base de datos Amazon Aurora: todo isto no material "" Le para contexto ou mira discursos.
Esta parte centrarase no escalado da rede, un dos sistemas máis complexos de AWS. A evolución dunha rede plana a unha Virtual Private Cloud e o seu deseño, os servizos internos de Blackfoot e HyperPlane, o problema dun veciño ruidoso e, ao final, a escala da rede, a columna vertebral e os cables físicos. Sobre todo isto baixo o corte.
Descargo de responsabilidade: todo a continuación é a opinión persoal de Vasily e pode non coincidir coa posición de Amazon Web Services.
Escalado da rede
A nube AWS lanzouse en 2006. A súa rede era bastante primitiva, cunha estrutura plana. O rango de enderezos privados era común a todos os inquilinos da nube. Ao iniciar unha nova máquina virtual, recibiu accidentalmente un enderezo IP dispoñible deste intervalo.
Este enfoque foi fácil de implementar, pero limitaba fundamentalmente o uso da nube. En particular, foi bastante difícil desenvolver solucións híbridas que combinasen redes privadas no terreo e en AWS. O problema máis común foi a superposición de intervalos de enderezos IP.
Nube privada virtual
A nube resultou ser demandada. Chegou o momento de pensar na escalabilidade e na posibilidade do seu uso por decenas de millóns de inquilinos. A rede plana converteuse nun gran obstáculo. Polo tanto, pensamos en como illar os usuarios uns dos outros a nivel de rede para que puidesen escoller de forma independente os intervalos de IP.
Cal é o primeiro que se che ocorre cando pensas no illamento da rede? Certamente VLAN и VRF - Enrutamento e reenvío virtual.
Desafortunadamente, non funcionou. A ID de VLAN é de só 12 bits, o que nos proporciona só 4096 segmentos illados. Incluso os interruptores máis grandes poden usar un máximo de 1-2 mil VRF. Usar VRF e VLAN xuntos ofrécenos só uns poucos millóns de subredes. Isto definitivamente non é suficiente para decenas de millóns de inquilinos, cada un dos cales debe poder usar varias subredes.
Tamén simplemente non podemos permitirnos o luxo de comprar o número necesario de caixas grandes, por exemplo, de Cisco ou Juniper. Hai dúas razóns: é moi caro e non queremos estar a mercé das súas políticas de desenvolvemento e parche.
Só hai unha conclusión: fai a túa propia solución.
En 2009 anunciamos VPC - Nube privada virtual. O nome quedou atascado e agora moitos provedores de nube tamén o usan.
VPC é unha rede virtual SDN (Rede definida por software). Decidimos non inventar protocolos especiais nos niveis L2 e L3. A rede funciona con Ethernet e IP estándar. Para a transmisión pola rede, o tráfico da máquina virtual encápsulase no noso propio envoltorio de protocolo. Indica o ID que pertence ao VPC do inquilino.
Parece sinxelo. Non obstante, hai varios retos técnicos serios que deben superarse. Por exemplo, onde e como almacenar os datos sobre a asignación de enderezos MAC/IP virtuais, ID VPC e MAC/IP físico correspondente. A escala de AWS, esta é unha táboa enorme que debería funcionar con atrasos de acceso mínimos. Responsable disto servizo de cartografía, que se espalla nunha capa fina por toda a rede.
Nas máquinas de nova xeración, a encapsulación realízase mediante tarxetas Nitro a nivel de hardware. En casos máis antigos, a encapsulación e a decapsulación baséanse en software.
Imos descubrir como funciona en termos xerais. Imos comezar co nivel L2. Supoñamos que temos unha máquina virtual con IP 10.0.0.2 nun servidor físico 192.168.0.3. Envía datos á máquina virtual 10.0.0.3, que vive en 192.168.1.4. Xérase unha solicitude ARP e envíase á tarxeta Nitro de rede. Para simplificar, supoñemos que ambas as máquinas virtuais viven no mesmo VPC "azul".
O mapa substitúe o enderezo de orixe polo seu propio e envía a trama ARP ao servizo de cartografía.
O servizo de cartografía devolve a información necesaria para a transmisión pola rede física L2.
A tarxeta Nitro na resposta ARP substitúe o MAC na rede física por un enderezo no VPC.
Ao transferir datos, envolvemos o MAC e o IP lóxicos nun envoltorio VPC. Todo isto transmitimos pola rede física utilizando as tarxetas IP Nitro de orixe e destino adecuadas.
A máquina física á que está destinado o paquete realiza a comprobación. Isto é necesario para evitar a posibilidade de suplantación de enderezos. A máquina envía unha solicitude especial ao servizo de cartografía e pregunta: “Da máquina física 192.168.0.3 recibín un paquete destinado a 10.0.0.3 no VPC azul. É lexítimo?
O servizo de mapeo verifica a súa táboa de asignación de recursos e permite ou denega o paso do paquete. En todos os casos novos, incorpórase unha validación adicional nas tarxetas Nitro. É imposible evitalo incluso teoricamente. Polo tanto, a suplantación de recursos noutro VPC non funcionará.
A continuación, os datos envíanse á máquina virtual á que están destinados.
O servizo de mapeo tamén funciona como un enrutador lóxico para transferir datos entre máquinas virtuais en diferentes subredes. Todo é conceptualmente sinxelo, non vou entrar en detalles.
Resulta que ao transmitir cada paquete, os servidores recorren ao servizo de mapeo. Como facer fronte aos atrasos inevitables? Almacenamento en caché, por suposto.
A beleza é que non precisa almacenar na caché toda a enorme mesa. Un servidor físico alberga máquinas virtuais dun número relativamente pequeno de VPC. Só precisa almacenar na memoria caché a información destes VPC. A transferencia de datos a outras VPC na configuración "predeterminada" aínda non é lexítima. Se se usa unha funcionalidade como o peering de VPC, a información sobre as VPC correspondentes cárgase adicionalmente na caché.
Resolvemos a transferencia de datos ao VPC.
Pé negro
Que facer nos casos en que o tráfico necesite transmitirse ao exterior, por exemplo a Internet ou a través dunha VPN ao chan? Axúdanos aquí Pé negro - Servizo interno de AWS. Está desenvolvido polo noso equipo sudafricano. É por iso que o servizo leva o nome dun pingüín que vive en Sudáfrica.
Blackfoot decapsula o tráfico e fai o necesario con el. Os datos envíanse a Internet tal e como están.
Os datos son decapsulados e volven envolver en IPsec cando se usa unha VPN.
Cando se utiliza a conexión directa, o tráfico é etiquetado e enviado á VLAN adecuada.
Hiperplano
Este é un servizo de control de fluxo interno. Moitos servizos de rede requiren supervisión estados de fluxo de datos. Por exemplo, ao usar NAT, o control de fluxo debe garantir que cada par IP:porto de destino teña un porto de saída único. No caso dun equilibrador NLB - Balanceador de carga de rede, o fluxo de datos debe dirixirse sempre á mesma máquina virtual de destino. Security Groups é un firewall con estado. Monitoriza o tráfico entrante e abre implicitamente portos para o fluxo de paquetes saíntes.
Na nube de AWS, os requisitos de latencia de transmisión son moi altos. Por iso Hiperplano fundamental para o rendemento de toda a rede.
Hyperplane está construído en máquinas virtuais EC2. Aquí non hai maxia, só astucia. O truco é que se trata de máquinas virtuais con gran memoria RAM. As operacións son transaccionais e realízanse exclusivamente na memoria. Isto permítelle conseguir atrasos de só decenas de microsegundos. Traballar co disco mataría toda a produtividade.
Hyperplane é un sistema distribuído dun gran número de tales máquinas EC2. Cada máquina virtual ten un ancho de banda de 5 GB/s. En toda a rede rexional, isto proporciona terabits incribles de ancho de banda e permite o procesamento millóns de conexións por segundo.
HyperPlane só funciona con fluxos. A encapsulación de paquetes VPC é completamente transparente para iso. Unha vulnerabilidade potencial neste servizo interno impediría aínda que se rompa o illamento da VPC. Os niveis seguintes son responsables da seguridade.
Veciño ruidoso
Aínda hai un problema veciño ruidoso - veciño ruidoso. Supoñamos que temos 8 nodos. Estes nodos procesan os fluxos de todos os usuarios da nube. Todo parece estar ben e a carga debe estar distribuída uniformemente en todos os nodos. Os nodos son moi poderosos e é difícil sobrecargalos.
Pero construímos a nosa arquitectura baseándonos incluso en escenarios improbables.
Baixa probabilidade non significa imposible.
Podemos imaxinar unha situación na que un ou máis usuarios xerarían demasiada carga. Todos os nodos de HyperPlane están implicados no procesamento desta carga e outros usuarios poderían experimentar algún tipo de impacto no rendemento. Isto rompe o concepto da nube, no que os inquilinos non teñen capacidade de influír entre eles.
Como resolver o problema dun veciño ruidoso? O primeiro que se me ocorre é a fragmentación. Os nosos 8 nodos están loxicamente divididos en 4 fragmentos de 2 nodos cada un. Agora un veciño ruidoso molestará só a un cuarto de todos os usuarios, pero molestará moito.
Fagamos as cousas doutro xeito. Asignaremos só 3 nodos a cada usuario.
O truco é asignar aleatoriamente nodos a diferentes usuarios. Na imaxe de abaixo, o usuario azul cruza os nós cun dos outros dous usuarios: verde e laranxa.
Con 8 nodos e 3 usuarios, a probabilidade de que un veciño ruidoso se cruce cun dos usuarios é do 54%. É con esta probabilidade que un usuario azul influirá noutros inquilinos. Ao mesmo tempo, só unha parte da súa carga. No noso exemplo, esta influencia será, polo menos dalgún xeito, perceptible non para todos, senón para só un terzo de todos os usuarios. Este xa é un bo resultado.
Número de usuarios que se cruzarán
Probabilidade en porcentaxe
0
18%
1
54%
2
26%
3
2%
Acheguemos a situación á realidade: levemos 100 nodos e 5 usuarios en 5 nodos. Neste caso, ningún dos nodos se cruzará cunha probabilidade do 77%.
Número de usuarios que se cruzarán
Probabilidade en porcentaxe
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Nunha situación real, cun gran número de nodos e usuarios de HyperPlane, o impacto potencial dun veciño ruidoso sobre outros usuarios é mínimo. Este método chámase mestura de fragmentos - barallar fragmentos. Minimiza o efecto negativo da falla do nodo.
Moitos servizos están construídos en base a HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Escala de rede
Agora imos falar da escala da propia rede. Para outubro de 2019, AWS ofrece os seus servizos en 22 rexións, e están previstos 9 máis.
- Cada rexión contén varias Zonas de Dispoñibilidade. Hai 69 en todo o mundo.
- Cada AZ consta de centros de procesamento de datos. Non son máis de 8 en total.
- O centro de datos alberga un gran número de servidores, algúns con ata 300.
Agora fagamos unha media de todo isto, multipliquemos e obtengamos unha cifra impresionante que reflicta Escala na nube de Amazon.
Hai moitas conexións ópticas entre as Zonas de Dispoñibilidade e o centro de datos. Nunha das nosas rexións máis grandes, establecéronse 388 canles só para a comunicación entre AZ e os centros de comunicación con outras rexións (centros de tránsito). En total isto dá unha tolemia 5000 Tbit.
Backbone AWS está construído específicamente e optimizado para a nube. Construímolo nas canles 100 GB / s. Controlámolos por completo, con excepción das rexións de China. O tráfico non se comparte coas cargas doutras empresas.
Por suposto, non somos o único provedor de nube cunha rede troncal privada. Cada vez son máis as grandes empresas que seguen este camiño. Isto é confirmado por investigadores independentes, por exemplo de .
O gráfico mostra que a proporción de provedores de contido e provedores de nube está crecendo. Debido a isto, a porcentaxe de tráfico de Internet dos provedores de backbone está a diminuír constantemente.
Vou explicar por que ocorre isto. Anteriormente, a maioría dos servizos web eran accesibles e consumíanse directamente desde Internet. Hoxe en día, cada vez máis servidores están situados na nube e son accesibles a través CDN - Rede de distribución de contidos. Para acceder a un recurso, o usuario pasa por Internet só ata o CDN PoP máis próximo - Punto de presenza. A maioría das veces está nalgún lugar preto. Logo abandona a Internet pública e voa por unha columna vertebral privada a través do Atlántico, por exemplo, e chega directamente ao recurso.
Pregúntome como vai cambiar Internet en 10 anos se esta tendencia continúa?
Canles físicas
Os científicos aínda non descubriron como aumentar a velocidade da luz no Universo, pero fixeron grandes avances nos métodos de transmisión a través da fibra óptica. Actualmente utilizamos cables de fibra 6912. Isto axuda a optimizar significativamente o custo da súa instalación.
Nalgunhas rexións temos que usar cables especiais. Por exemplo, na rexión de Sidney usamos cables cun revestimento especial contra as termitas.
Ninguén é inmune aos problemas e ás veces as nosas canles danan. A foto da dereita mostra cables ópticos nunha das rexións americanas que foron rasgadas polos traballadores da construción. Como consecuencia do accidente, só se perderon 13 paquetes de datos, o que é sorprendente. Unha vez máis: só 13! O sistema cambiou literalmente instantáneamente ás canles de copia de seguridade: a escala funciona.
Galopamos por algúns dos servizos e tecnoloxías na nube de Amazon. Espero que teñas polo menos unha idea da escala das tarefas que os nosos enxeñeiros teñen que resolver. Persoalmente, paréceme moi emocionante.
Esta é a parte final da triloxía de Vasily Pantyukhin sobre o dispositivo AWS. EN as partes describen a optimización do servidor e o escalado da base de datos, e en — funcións sen servidor e Firecracker.
En en novembro Vasily Pantyukhin compartirá novos detalles do dispositivo Amazon. El sobre as causas dos fallos e o deseño de sistemas distribuídos en Amazon. O 24 de outubro aínda é posible billete a bo prezo, e pagar máis tarde. Agardámoste en HighLoad++, ven falar!
Fonte: www.habr.com