Cómo AWS elabora sus servicios resistentes. Escala de red

La red de Amazon Web Services tiene 69 ubicaciones en todo el mundo en 22 regiones: Estados Unidos, Europa, Asia, África y Australia. En cada zona hay 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á construida 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 acceso están separadas por varios kilómetros. Incluso si corta el cable, el sistema cambiará a canales de respaldo y la pérdida de información equivaldrá a unidades de paquetes de datos. Sobre qué otros principios se construye la red y cómo se construye, le dirá a Vasily Pantyukhin.



Vasily Pantyukhin comenzó como administrador de Unix en empresas .ru, pasó 6 años en las grandes glándulas del microsistema solar y durante 11 años predicó la centralización de datos del mundo en EMC. Evolucionó naturalmente a nubes privadas, luego se hizo público. Ahora, como arquitecto de Amazon Web Services, el asesoramiento técnico lo ayuda a vivir y crecer en la nube de AWS.

En la parte anterior de la trilogía de dispositivos de AWS, Vasily profundizó en el dispositivo de servidores físicos y el escalado de bases de datos. Nitro-cards, hipervisor personalizado basado en KVM, base de datos de Amazon Aurora, todo esto en el artículo " Cómo AWS" cocina "sus servicios elásticos. Escalado de servidor y base de datos ". Lea para sumergirse en el contexto o vea un video de la presentación.

En esta parte, nos centraremos en el escalado de la red, uno de los sistemas más complejos de AWS. Evolución de una red plana a Virtual Private Cloud y su dispositivo, servicios internos 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 sigue es la opinión personal de Vasily, y puede no coincidir con la posición de los servicios web de Amazon.

Escala de red

AWS Cloud se lanzó en 2006. Su red era bastante primitiva, con una estructura plana. El rango de direcciones privadas era común a todos los inquilinos de la nube. Cuando inicia 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 el terreno y en AWS. El problema más común fue la intersección de rangos de direcciones IP.

Nube privada virtual

La nube estaba en demanda. Es hora de pensar en la escalabilidad y la posibilidad de su uso por decenas de millones de inquilinos. 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 puedan seleccionar independientemente los rangos de IP.



¿Qué le viene a la mente primero cuando piensa en el aislamiento de la red? Por supuesto, VLAN y VRF son enrutamiento y reenvío virtuales .

Lamentablemente, esto no funcionó. La ID de VLAN es de solo 12 bits, lo que nos da solo 4096 segmentos aislados. Incluso en los conmutadores más grandes, puede usar un máximo de 1-2 mil VRF. El uso combinado de VRF y VLAN nos da solo unos pocos millones de subredes. Esto definitivamente no es suficiente para decenas de millones de inquilinos, cada uno de los cuales debería poder usar varias subredes.

Aún así, simplemente no podemos permitirnos comprar la cantidad requerida de cajas grandes, por ejemplo, de Cisco o Juniper. Hay dos razones: es extremadamente costoso y no queremos depender de sus políticas de desarrollo y parches.

Solo hay una conclusión: cocinar tu propia decisión.

En 2009, anunciamos VPC - Virtual Private Cloud . El nombre ha echado raíces y ahora muchos proveedores de la nube también lo usan.

VPC es una red virtual de red definida por software ( SDN ). Decidimos no inventar protocolos especiales en los niveles L2 y L3. La red se ejecuta en Ethernet e IP estándar. Para la transmisión a través de una red, el tráfico de la máquina virtual se encapsula en un contenedor de nuestro propio protocolo. Indica la identificación que pertenece a la VPC de inquilinos.



Eso suena facil. Sin embargo, es necesario resolver varios problemas técnicos serios. Por ejemplo, dónde y cómo almacenar datos de mapeo para direcciones MAC / IP virtuales, ID de VPC y direcciones MAC / IP físicas correspondientes. En una escala de AWS, esta es una tabla enorme que debería funcionar con una latencia mínima. El servicio de mapeo , que está manchado con una capa delgada en toda la red, es responsable de esto.

En máquinas de nuevas generaciones, la encapsulación se realiza mediante tarjetas Nitro a nivel de hierro. En casos más antiguos, encapsulación y decapsulación de software.



Veamos cómo funciona esto en términos generales. Comencemos con 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 una máquina virtual 10.0.0.3 que vive en 192.168.1.4. Se genera una solicitud ARP, que cae en la tarjeta de red Nitro. Para simplificar, creemos que ambas máquinas virtuales viven en la misma VPC "azul".



La tarjeta reemplaza la dirección de origen con la suya y envía la trama ARP al servicio de mapeo.



El servicio de mapeo devuelve la información que se necesita para la transmisión a través de la red física L2.



La tarjeta nitro en la respuesta ARP reemplaza el MAC en la red física con la dirección en la VPC.



Al transferir datos, envolvemos el MAC lógico y la IP en un contenedor VPC. Todo esto se transmite a través de la red física utilizando las tarjetas IP Nitro apropiadas de origen y destino.



La máquina física del paquete está destinada a realizar verificaciones. Esto es para evitar la posibilidad de falsificación. La máquina envía una solicitud especial al servicio de mapeo y pregunta: “Desde la máquina física 192.168.0.3 recibí un paquete diseñado para 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 todos los casos nuevos, la validación adicional se cose en las tarjetas Nitro. Es imposible moverse incluso teóricamente. Por lo tanto, la suplantación de recursos en otra VPC no funcionará.



Luego, los datos se envían a la máquina virtual para 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 allí, no lo analizaré en detalle.



Resulta que durante la transmisión de cada paquete, los servidores acceden al servicio de mapeo. ¿Cómo lidiar con los retrasos inevitables? Almacenamiento en caché , por supuesto.

Todo el encanto es que no necesita almacenar en caché toda la gran mesa. Las máquinas virtuales de un número relativamente pequeño de VPC viven en un servidor físico. La información solo debe almacenarse en caché sobre estas VPC. La transferencia de datos a otras VPC en la configuración "predeterminada" aún no es legítima. Si se utiliza la funcionalidad como el emparejamiento de VPC, la información sobre los VPC correspondientes se carga adicionalmente en la memoria caché.



Con la transferencia de datos a la VPC resuelto.

Blackfoot

¿Qué hacer en los casos en que el tráfico debe transmitirse al exterior, por ejemplo, en Internet o a través de una VPN al suelo? Aquí es donde Blackfoot , el servicio interno de AWS, nos ayuda. Está diseñado por nuestro equipo sudafricano. Por lo tanto, el servicio lleva el nombre del pingüino que vive en Sudáfrica.



Blackfoot decapsula el tráfico y hace lo que necesita con él. Los datos de Internet se envían tal cual.



Los datos se desencapsulan y se envuelven nuevamente en un contenedor IPsec cuando se usa una VPN.



Cuando se usa Direct Connect, el tráfico se etiqueta y se transmite a la VLAN correspondiente.

HyperPlane

Este es un servicio de control de flujo interno. Muchos servicios de red requieren monitorear el estado del flujo de datos . Por ejemplo, cuando se utiliza NAT, el control de flujo debe garantizar que cada par "IP: puerto de destino" tenga un puerto de salida único. En el caso del equilibrador NLB - Equilibrador de carga de red , el flujo de datos siempre debe dirigirse a la misma máquina virtual de destino. Grupos de seguridad es un firewall con estado. Supervisa el tráfico entrante y abre implícitamente puertos para la secuencia de paquetes salientes.



En la nube de AWS, los requisitos de latencia de transmisión son extremadamente altos. Por lo tanto, HyperPlane es crítico para la salud de toda la red.



Hyperplane está construido en máquinas virtuales EC2. Aquí no hay magia, solo astucia. El truco es que son máquinas virtuales con gran RAM. Las transacciones son transaccionales y se realizan exclusivamente en la memoria. Esto permite retrasos de solo decenas de microsegundos. Trabajar con un disco mataría todo el rendimiento.

Hyperplane es un sistema distribuido de una gran cantidad de tales máquinas EC2. Cada máquina virtual tiene un ancho de banda de 5 GB / s. En toda la red regional, esto produce terabits salvajes de ancho de banda y le permite procesar millones de conexiones por segundo .

HyperPlane solo funciona con hilos. La encapsulación de paquetes VPC es completamente transparente para él. La vulnerabilidad potencial en este servicio interno aún no permitirá romper el aislamiento de VPC. Por seguridad, los niveles a continuación son responsables.

Vecino ruidoso

También existe el problema vecino ruidoso . Supongamos que tenemos 8 nodos. Estos nodos procesan los hilos de todos los usuarios de la nube. Todo parece estar bien y la carga debe distribuirse uniformemente en todos los nodos. Los nodos son muy potentes y difíciles de sobrecargar.

Pero estamos construyendo nuestra arquitectura basada en escenarios incluso poco probables.

Baja probabilidad no significa imposibilidad.

Podemos imaginar una situación en la que uno o más usuarios generarán demasiada carga. Todos los nodos HyperPlane están involucrados en el procesamiento de esta carga, y otros usuarios pueden sentir algún tipo de degradación del rendimiento. Esto destruye el concepto de la nube, en el que los inquilinos no tienen forma de influenciarse entre sí.



¿Cómo resolver el problema de un vecino ruidoso? Lo primero que viene a la mente es fragmentar. Nuestros 8 nodos están divididos lógicamente en 4 fragmentos con 2 nodos en cada uno. Ahora, un vecino ruidoso se verá obstaculizado por solo una cuarta parte de todos los usuarios, pero mucho más.



Hagámoslo de manera diferente. A cada usuario se le asignan solo 3 nodos.



El truco es asignar nodos a diferentes usuarios al azar. En la imagen a continuación, el usuario azul cruza los 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 el usuario azul afectará a otros inquilinos. Además, solo una parte de su carga. En nuestro ejemplo, esta influencia será al menos de alguna manera imperceptible para todos, pero solo un tercio de todos los usuarios. Este ya es un buen resultado.

Acerquemos la situación a la real: tome 100 nodos y 5 usuarios en 5 nodos. En este caso, ninguno de los nodos se cruza con una probabilidad del 77%.

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 shuffle sharding . Minimiza el efecto negativo de la falla del nodo.

Basado en HyperPlane, se crean muchos servicios: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.

Escala de red

Ahora hablemos de la escala de la red misma. Para octubre de 2019, AWS ofrece sus servicios en 22 regiones , y se planean 9 más.

• Cada región contiene varias zonas de disponibilidad. Hay 69 de ellos en el mundo.
  
• Cada AZ consta de centros de procesamiento de datos. No hay más de 8 de ellos.
  
• En el centro de datos hay una gran cantidad de servidores, algunos de hasta 300,000.
  

Ahora todo esto se promedia, multiplica y obtiene una cifra impresionante que muestra la escala de la nube de Amazon .

Entre las zonas de acceso y el centro de datos, se colocan muchos canales ópticos. En una de nuestras regiones más grandes, solo se han establecido 388 canales para la comunicación de AZ entre ellos y los centros de comunicación con otras regiones (Centros de tránsito). En total, esto da un loco 5000 Tbit .



Backbone AWS está construido específicamente para la nube y optimizado para trabajar con él. Lo construimos en canales de 100 GB / s . Los controlamos completamente, con la excepción de las regiones de China. El tráfico no se comparte con las cargas de otras compañías.



Por supuesto, no somos el único proveedor de la nube con una red troncal privada. Cada vez más empresas grandes van por este camino. Esto es confirmado por investigadores independientes, por ejemplo, de Telegeography .



El gráfico muestra que la proporción de proveedores de contenido y proveedores en la nube está creciendo. Debido a esto, la proporción del tráfico de Internet de los proveedores de red troncal está disminuyendo constantemente.

Explicaré por qué sucede esto. Anteriormente, la mayoría de los servicios web estaban disponibles y se consumían directamente desde Internet. Ahora, cada vez más servidores se encuentran en la nube y están disponibles a través de CDN - Content Distribution Network . Para acceder al recurso, el usuario pasa por Internet solo hasta el punto de presencia CDN más cercano. Muy a menudo está en algún lugar cercano. Luego deja el Internet público y vuela a través del Atlántico a través de una red troncal privada, por ejemplo, y llega directamente al recurso.

Me pregunto cómo cambiará Internet en 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 hecho grandes avances en los métodos de transmisión a través de la fibra óptica. Actualmente estamos utilizando cables de fibra 6912. Esto ayuda a optimizar significativamente el costo de su instalación.

En algunas regiones tenemos que usar cables especiales. Por ejemplo, en la región de Sydney, utilizamos cables con un recubrimiento especial contra las termitas.



Nadie está a salvo de problemas y, a veces, nuestros canales están dañados. La foto de la derecha muestra cables ópticos en una de las regiones estadounidenses que fueron rasgados por los constructores. Como resultado del accidente, solo se perdieron 13 paquetes de datos, lo cual es sorprendente. Una vez más, ¡solo 13! El sistema literalmente cambió instantáneamente a canales de respaldo: la báscula funciona.

Galopamos sobre algunos servicios y tecnologías en la nube de Amazon. Espero que tenga al menos alguna idea de la escala de las tareas que nuestros ingenieros tienen que resolver. Personalmente, estoy muy interesado en esto.

Esta es la parte final de la trilogía de Vasily Pantyukhin sobre el dispositivo AWS. La primera parte describe la optimización del servidor y el escalado de la base de datos, y la segunda describe las funciones sin servidor y Firecracker.

En HighLoad ++ en noviembre, Vasily Pantyukhin compartirá nuevos detalles del dispositivo Amazon. Hablará sobre las causas de fallas y el diseño de sistemas distribuidos en Amazon. El 24 de octubre, aún puede reservar un boleto a un buen precio y pagar más tarde. ¡Te esperamos en HighLoad ++, ven y habla!