La escala de la red de Amazon Web Services es de 69 zonas en todo el mundo en 22 regiones: EE. UU., Europa, Asia, África y Australia. Cada zona contiene hasta 8 centros de datos - Centros de Procesamiento de Datos. Cada centro de datos tiene miles o cientos de miles de servidores. La red está diseñada de tal manera que se tienen en cuenta todos los escenarios improbables de interrupción. Por ejemplo, todas las regiones están aisladas unas de otras y las zonas de accesibilidad están separadas a lo largo de distancias de varios kilómetros. Incluso si corta el cable, el sistema cambiará a canales de respaldo y la pérdida de información ascenderá a unos pocos paquetes de datos. Vasily Pantyukhin hablará sobre otros principios sobre los que se basa la red y cómo está estructurada.
Vasily Pantyukhin Comenzó como administrador de Unix en empresas .ru, trabajó en hardware Sun Microsystem de gran tamaño durante 6 años y predicó un mundo centrado en datos durante 11 años en EMC. Naturalmente, evolucionó hacia nubes privadas y luego pasó a las públicas. Ahora, como arquitecto de Amazon Web Services, brinda asesoramiento técnico para ayudar a vivir y desarrollarse en la nube de AWS.
En la parte anterior de la trilogía de AWS, Vasily profundizó en el diseño de servidores físicos y el escalado de bases de datos. Tarjetas Nitro, hipervisor personalizado basado en KVM, base de datos Amazon Aurora: sobre todo esto en el material "" Leer para conocer el contexto o mirar actuaciones.
Esta parte se centrará en el escalado de la red, uno de los sistemas más complejos de AWS. La evolución de una red plana a una Nube Privada Virtual y su diseño, los servicios internos de Blackfoot e HyperPlane, el problema de un vecino ruidoso y, al final, la escala de la red, la red troncal y los cables físicos. Sobre todo esto bajo el corte.
Descargo de responsabilidad: todo lo que aparece a continuación es la opinión personal de Vasily y puede no coincidir con la posición de Amazon Web Services.
Escalado de red
La nube de AWS se lanzó en 2006. Su red era bastante primitiva, con una estructura plana. La gama de direcciones privadas era común a todos los inquilinos de la nube. Al iniciar una nueva máquina virtual, accidentalmente recibió una dirección IP disponible de este rango.
Este enfoque fue fácil de implementar, pero limitó fundamentalmente el uso de la nube. En particular, fue bastante difícil desarrollar soluciones híbridas que combinaran redes privadas en tierra y en AWS. El problema más común era la superposición de rangos de direcciones IP.
Nube privada virtual
La nube resultó tener demanda. Ha llegado el momento de pensar en la escalabilidad y la posibilidad de que decenas de millones de inquilinos la utilicen. La red plana se ha convertido en un gran obstáculo. Por lo tanto, pensamos en cómo aislar a los usuarios entre sí a nivel de red para que pudieran elegir rangos de IP de forma independiente.
¿Qué es lo primero que te viene a la mente cuando piensas en el aislamiento de la red? Ciertamente VLAN и VRF: enrutamiento y reenvío virtual.
Desafortunadamente, no funcionó. La ID de VLAN tiene solo 12 bits, lo que nos da solo 4096 segmentos aislados. Incluso los conmutadores más grandes pueden utilizar un máximo de 1 a 2 VRF. El uso conjunto de VRF y VLAN nos proporciona sólo unos pocos millones de subredes. Definitivamente esto no es suficiente para decenas de millones de inquilinos, cada uno de los cuales debe poder utilizar múltiples subredes.
Tampoco podemos permitirnos comprar la cantidad necesaria de cajas grandes, por ejemplo, de Cisco o Juniper. Hay dos razones: es muy caro y no queremos estar a merced de sus políticas de desarrollo y parches.
Sólo hay una conclusión: cree su propia solución.
En 2009 anunciamos VPC - Nube privada virtual. El nombre se quedó y ahora muchos proveedores de la nube también lo utilizan.
VPC es una red virtual SDN (Red definida por software). Decidimos no inventar protocolos especiales en los niveles L2 y L3. La red funciona con Ethernet e IP estándar. Para la transmisión a través de la red, el tráfico de la máquina virtual se encapsula en nuestro propio contenedor de protocolo. Indica el ID que pertenece a la VPC del inquilino.
Suena sencillo. Sin embargo, hay varios desafíos técnicos serios que deben superarse. Por ejemplo, dónde y cómo almacenar datos sobre la asignación de direcciones MAC/IP virtuales, ID de VPC y MAC/IP física correspondiente. En la escala de AWS, esta es una tabla enorme que debería funcionar con retrasos de acceso mínimos. Responsable de esto servicio de mapeo, que se extiende en una fina capa por toda la red.
En las máquinas de nueva generación, el encapsulado se realiza mediante tarjetas Nitro a nivel de hardware. En casos más antiguos, la encapsulación y desencapsulación se basaban en software.
Averigüemos cómo funciona en términos generales. Empecemos por el nivel L2. Supongamos que tenemos una máquina virtual con IP 10.0.0.2 en un servidor físico 192.168.0.3. Envía datos a la máquina virtual 10.0.0.3, que reside en 192.168.1.4. Se genera una solicitud ARP y se envía a la tarjeta Nitro de la red. Para simplificar, asumimos que ambas máquinas virtuales viven en la misma VPC "azul".
El mapa reemplaza la dirección de origen por la suya propia y reenvía la trama ARP al servicio de mapas.
El servicio de mapeo devuelve información necesaria para la transmisión a través de la red física L2.
La tarjeta Nitro en la respuesta ARP reemplaza la MAC en la red física con una dirección en la VPC.
Al transferir datos, encapsulamos MAC e IP lógicas en un contenedor VPC. Todo ello lo transmitimos a través de la red física utilizando las tarjetas Nitro IP de origen y destino adecuadas.
La máquina física a la que está destinado el paquete realiza la comprobación. Esto es necesario para evitar la posibilidad de suplantación de direcciones. La máquina envía una solicitud especial al servicio de mapeo y pregunta: “De la máquina física 192.168.0.3 recibí un paquete destinado a 10.0.0.3 en la VPC azul. ¿Es legítimo?
El servicio de mapeo verifica su tabla de asignación de recursos y permite o niega el paso del paquete. En todas las instancias nuevas, la validación adicional está integrada en las tarjetas Nitro. Es imposible evitarlo ni siquiera en teoría. Por lo tanto, la suplantación de recursos en otra VPC no funcionará.
A continuación, los datos se envían a la máquina virtual a la que están destinados.
El servicio de mapeo también funciona como un enrutador lógico para transferir datos entre máquinas virtuales en diferentes subredes. Todo es conceptualmente simple, no entraré en detalles.
Resulta que al transmitir cada paquete, los servidores recurren al servicio de mapas. ¿Cómo afrontar los retrasos inevitables? Almacenamiento en cachépor supuesto
Lo bueno es que no es necesario almacenar en caché toda la enorme tabla. Un servidor físico aloja máquinas virtuales de una cantidad relativamente pequeña de VPC. Solo necesita almacenar en caché información sobre estas VPC. Transferir datos a otras VPC en la configuración "predeterminada" todavía no es legítimo. Si se utiliza una funcionalidad como el emparejamiento de VPC, la información sobre las VPC correspondientes se carga adicionalmente en la caché.
Resolvimos la transferencia de datos al VPC.
Pie negro
¿Qué hacer en los casos en que el tráfico debe transmitirse al exterior, por ejemplo a Internet o mediante VPN al suelo? Nos ayuda aquí Pie negro — Servicio interno de AWS. Está desarrollado por nuestro equipo sudafricano. Por eso el servicio lleva el nombre de un pingüino que vive en Sudáfrica.
Blackfoot decapsula el tráfico y hace lo necesario con él. Los datos se envían a Internet tal cual.
Los datos se desencapsulan y se vuelven a empaquetar en IPsec cuando se utiliza una VPN.
Cuando se utiliza Direct Connect, el tráfico se etiqueta y se envía a la VLAN adecuada.
Hiperplano
Este es un servicio de control de flujo interno. Muchos servicios de red requieren monitoreo estados de flujo de datos. Por ejemplo, cuando se utiliza NAT, el control de flujo debe garantizar que cada par de puerto IP:destino tenga un puerto de salida único. En el caso de un equilibrador NLB - Balanceador de carga de red, el flujo de datos siempre debe dirigirse a la misma máquina virtual de destino. Security Groups es un firewall con estado. Supervisa el tráfico entrante e implícitamente abre puertos para el flujo de paquetes salientes.
En la nube de AWS, los requisitos de latencia de transmisión son extremadamente altos. Es por eso Hiperplano crítico para el rendimiento de toda la red.
Hyperplane se basa en máquinas virtuales EC2. Aquí no hay magia, sólo astucia. El truco es que se trata de máquinas virtuales con mucha RAM. Las operaciones son transaccionales y se realizan exclusivamente en memoria. Esto le permite lograr retrasos de sólo decenas de microsegundos. Trabajar con el disco acabaría con toda la productividad.
Hyperplane es un sistema distribuido de una gran cantidad de máquinas EC2 de este tipo. Cada máquina virtual tiene un ancho de banda de 5 GB/s. En toda la red regional, esto proporciona increíbles terabits de ancho de banda y permite procesar millones de conexiones por segundo.
HyperPlane solo funciona con transmisiones. La encapsulación de paquetes VPC es completamente transparente para ello. Una vulnerabilidad potencial en este servicio interno aún evitaría que se rompa el aislamiento de la VPC. Los niveles siguientes son responsables de la seguridad.
vecino ruidoso
todavía hay un problema vecino ruidoso - vecino ruidoso. Supongamos que tenemos 8 nodos. Estos nodos procesan los flujos de todos los usuarios de la nube. Todo parece estar bien y la carga debería distribuirse uniformemente entre todos los nodos. Los nodos son muy poderosos y es difícil sobrecargarlos.
Pero construimos nuestra arquitectura basándonos en escenarios incluso improbables.
Baja probabilidad no significa imposible.
Podemos imaginar una situación en la que uno o más usuarios generarían demasiada carga. Todos los nodos de HyperPlane participan en el procesamiento de esta carga y otros usuarios podrían experimentar algún tipo de pérdida de rendimiento. Esto rompe el concepto de nube, en el que los inquilinos no tienen capacidad de influirse entre sí.
¿Cómo solucionar el problema de un vecino ruidoso? Lo primero que me viene a la mente es fragmentación. Nuestros 8 nodos están lógicamente divididos en 4 fragmentos de 2 nodos cada uno. Ahora un vecino ruidoso molestará sólo a una cuarta parte de todos los usuarios, pero les molestará mucho.
Hagamos las cosas de manera diferente. Asignaremos solo 3 nodos a cada usuario.
El truco consiste en asignar nodos aleatoriamente a diferentes usuarios. En la imagen siguiente, el usuario azul cruza nodos con uno de los otros dos usuarios: verde y naranja.
Con 8 nodos y 3 usuarios, la probabilidad de que un vecino ruidoso se cruce con uno de los usuarios es del 54%. Es con esta probabilidad que un usuario azul influirá en otros inquilinos. Al mismo tiempo, sólo una parte de su carga. En nuestro ejemplo, esta influencia será, al menos de alguna manera, perceptible no para todos, sino sólo para un tercio de todos los usuarios. Este ya es un buen resultado.
Número de usuarios que se cruzarán
Probabilidad en porcentaje
0
18%
1
54%
2
26%
3
2%
Acerquemos la situación a la realidad: tomemos 100 nodos y 5 usuarios en 5 nodos. En este caso, ninguno de los nodos se cruzará con una probabilidad del 77%.
Número de usuarios que se cruzarán
Probabilidad en porcentaje
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
En una situación real, con una gran cantidad de nodos y usuarios de HyperPlane, el impacto potencial de un vecino ruidoso en otros usuarios es mínimo. Este método se llama mezclando fragmentos - fragmentación aleatoria. Minimiza el efecto negativo de la falla del nodo.
Muchos servicios se basan en HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Escala de red
Ahora hablemos de la escala de la red en sí. Para octubre de 2019 AWS ofrece sus servicios en 22 regionesy están previstos 9 más.
- Cada región contiene varias zonas de disponibilidad. Hay 69 de ellos en todo el mundo.
- Cada AZ consta de Centros de Procesamiento de Datos. En total, no hay más de 8.
- El centro de datos alberga una gran cantidad de servidores, algunos de ellos con hasta 300.
Ahora promediemos todo esto, multipliquemos y obtengamos una cifra impresionante que refleje Escala de nube de Amazon.
Hay muchos enlaces ópticos entre las zonas de disponibilidad y el centro de datos. En una de nuestras regiones más grandes, se han instalado 388 canales solo para la comunicación AZ entre sí y los centros de comunicación con otras regiones (Centros de Tránsito). En total esto da locura 5000 Tbit.
Backbone AWS está diseñado y optimizado específicamente para la nube. Lo construimos en los canales. 100 GB / s. Los controlamos completamente, a excepción de las regiones de China. El tráfico no se comparte con las cargas de otras empresas.
Por supuesto, no somos el único proveedor de nube con una red troncal privada. Cada vez más grandes empresas siguen este camino. Así lo confirman investigadores independientes, por ejemplo de .
El gráfico muestra que la proporción de proveedores de contenidos y proveedores de nube está creciendo. Debido a esto, la proporción del tráfico de Internet de los proveedores troncales disminuye constantemente.
Te explicaré por qué sucede esto. Anteriormente, la mayoría de los servicios web eran accesibles y consumidos directamente desde Internet. Hoy en día, cada vez más servidores están ubicados en la nube y son accesibles a través de CDN - Red de distribución de contenido. Para acceder a un recurso, el usuario navega por Internet únicamente hasta el CDN PoP más cercano. Punto de presencia. La mayoría de las veces se encuentra en algún lugar cercano. Luego sale de la Internet pública y vuela a través de una red troncal privada a través del Atlántico, por ejemplo, y llega directamente al recurso.
Me pregunto cómo cambiará Internet dentro de 10 años si esta tendencia continúa.
Canales fisicos
Los científicos aún no han descubierto cómo aumentar la velocidad de la luz en el Universo, pero han logrado grandes avances en los métodos de transmisión a través de fibra óptica. Actualmente utilizamos cables de fibra 6912. Esto ayuda a optimizar significativamente el coste de su instalación.
En algunas regiones tenemos que utilizar cables especiales. Por ejemplo, en la región de Sydney utilizamos cables con un revestimiento especial contra las termitas.
Nadie está inmune a los problemas y, en ocasiones, nuestros canales se dañan. La foto de la derecha muestra cables ópticos en una de las regiones de América que fueron arrancados por trabajadores de la construcción. Como resultado del accidente, sólo se perdieron 13 paquetes de datos, lo cual es sorprendente. Una vez más, ¡sólo 13! El sistema literalmente cambió instantáneamente a canales de respaldo: la báscula está funcionando.
Galopamos a través de algunos de los servicios y tecnologías en la nube de Amazon. Espero que tenga al menos una idea de la magnitud de las tareas que deben resolver nuestros ingenieros. Personalmente, esto me parece muy emocionante.
Esta es la parte final de la trilogía de Vasily Pantyukhin sobre el dispositivo AWS. EN Las partes describen la optimización del servidor y el escalado de la base de datos, y en — funciones sin servidor y Firecracker.
En En noviembre Vasily Pantyukhin compartirá nuevos detalles del dispositivo de Amazon. Él sobre las causas de las fallas y el diseño de sistemas distribuidos en Amazon. El 24 de octubre todavía es posible. billete a buen precio, y pagar después. Te esperamos en HighLoad++, ¡ven y charlemos!
Fuente: habr.com