La escala de la red de Amazon Web Services consiste en 69 zonas en todo el mundo, distribuidas en 22 regiones: EE. UU., Europa, Asia, África y Australia. En cada zona hay hasta 8 centros de datos (CD). En cada CD hay miles o cientos de miles de servidores. La red está diseñada para considerar todos los escenarios poco probables de interrupción. Por ejemplo, todas las regiones están aisladas entre sí, y las zonas de disponibilidad están separadas por distancias de varios kilómetros. Incluso si se cortara un cable, el sistema cambiaría a canales de respaldo, y la pérdida de información sería de solo unos pocos paquetes de datos. Sobre otros principios en los que se basa la red y su funcionamiento, hablará Vasili Pantyukhin.
Vasili Pantiukhyn empecé como administrador de Unix en empresas .ru, estuve 6 años trabajando con grandes equipos de Sun Microsystems, y durante 11 años promoví la centralidad de los datos en EMC. Evolucioné naturalmente hacia las nubes privadas y luego hice la transición a las públicas. Actualmente, como arquitecto de Amazon Web Services, ofrezco consejos técnicos para ayudar a vivir y desarrollarse en la nube de AWS.
En la parte anterior de la trilogía sobre la arquitectura de AWS, Vasili profundizó en la estructura de los servidores físicos y la escalabilidad de la base de datos. Las tarjetas Nitro, el hipervisor personalizado basado en KVM, la base de datos Amazon Aurora: sobre todo esto se habla en el material "". Léelo para sumergirte en el contexto, o mira la de la presentación.
En esta parte se hablará de la escalabilidad de la red, uno de los sistemas más complejos en AWS. La evolución de una red plana a la Virtual Private Cloud y su estructura, los servicios internos Blackfoot y HyperPlane, el problema del vecino ruidoso, y al final, la escala de la red, el backbone y los cables físicos. Todo esto está bajo el siguiente enlace.
Descargo de responsabilidad: todo lo que sigue es la opinión personal de Vasili y puede no coincidir con la postura de Amazon Web Services.
Escalabilidad de red
AWS se lanzó en 2006. Su red era bastante primitiva, con una estructura plana. El rango de direcciones privadas era compartido por todos los inquilinos de la nube. Al iniciar una nueva máquina virtual, accidentalmente obtenías una dirección IP disponible de este rango.
Este enfoque era fácil de implementar, pero limitaba fundamentalmente el uso de la nube. En particular, era bastante difícil desarrollar soluciones híbridas que combinaran redes privadas en tierra y en AWS. El problema más común era la intersección de los rangos de direcciones IP.
Virtual Private Cloud
La nube se ha vuelto popular. Ha llegado el momento de considerar la escalabilidad y la posibilidad de su uso por decenas de millones de inquilinos. La red plana se ha convertido en el principal obstáculo. Por eso, hemos pensado en cómo aislar a los usuarios unos de otros a nivel de red, para que puedan elegir rangos de IP por sí mismos.
¿Qué es lo primero que se te viene a la mente cuando piensas en aislamiento de red? Por supuesto, VLAN y VRF — Enrutamiento y Conmutación Virtual.
Desafortunadamente, esto no funcionó. El ID de VLAN son solo 12 bits, lo que nos da solo 4096 segmentos aislados. Incluso en los conmutadores más grandes, se pueden utilizar un máximo de 1-2 mil VRF. La combinación 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 debe tener la posibilidad de utilizar varias subredes.
Además, simplemente no podemos permitirnos comprar la cantidad requerida de grandes equipos, por ejemplo, de Cisco o Juniper. Hay dos razones: es extremadamente caro y no queremos depender de su política de desarrollo y parches.
La conclusión es clara: hay que elaborar nuestra propia solución.
En 2009, anunciamos VPC — Virtual Private Cloud. El nombre se ha arraigado y ahora muchos proveedores de nube también lo utilizan.
VPC es una red virtual SDN (Red Definida por Software). Decidimos no inventar protocolos específicos en los niveles L2 y L3. La red funciona con Ethernet e IP estándar. Para la transmisión por la red, el tráfico de las máquinas virtuales se encapsula en una envoltura de nuestro propio protocolo. En él se especifica el ID que pertenece al inquilino de la VPC.
Suena simple. Sin embargo, es necesario resolver varias tareas técnicas serias. Por ejemplo, dónde y cómo almacenar los datos sobre la mapeo de direcciones MAC/IP virtuales, ID de VPC y las correspondientes MAC/IP físicas. A escala de AWS, se trata de una enorme tabla que debe funcionar con mínimos retrasos al acceder. Esto está a cargo de el servicio de mapeo, que se distribuye en toda la red en una capa delgada.
En las máquinas de nueva generación, la encapsulación se realiza mediante tarjetas Nitro a nivel de hardware. En las instancias más antiguas, la encapsulación y la desencapsulación son procesos 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. Esta envía datos a la máquina virtual 10.0.0.3, que reside en 192.168.1.4. Se genera una solicitud ARP que llega a la tarjeta Nitro de red. Para simplificar, asumimos que ambas máquinas virtuales están en el mismo VPC "azul".
La tarjeta reemplaza la dirección de origen por la suya y reenvía el marco ARP al servicio de mapeo.
El servicio de mapeo devuelve la 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 por la dirección en el VPC.
Al transmitir datos, encapsulamos las MAC y IP lógicas en un envoltorio VPC. Todo esto se envía por la red física utilizando las IP correspondientes de las tarjetas Nitro de origen y destino.
La máquina física, a la que se destina el paquete, realiza una verificación. Esto es necesario para evitar la suplantación de direcciones. La máquina envía una solicitud especial al servicio de mapeo y pregunta: "Desde la máquina física 192.168.0.3 he recibido un paquete que está destinado a 10.0.0.3 en el VPC 'azul'. ¿Es legítimo?"
El servicio de mapeo verifica su tabla de ubicación de recursos y permite o deniega el paso del paquete. En todas las nuevas instancias, se ha implementado una validación adicional en las tarjetas Nitro. No se puede eludir, ni siquiera teóricamente. Por lo tanto, el spoofing de recursos en otro 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 la transmisión de datos entre máquinas virtuales en diferentes subredes. Conceptualmente, es todo bastante simple; no entraré en detalles.
Así que, al enviar cada paquete, los servidores consultan al servicio de mapeo. ¿Cómo lidiar con las inevitables latencias? Mediante el almacenamiento en caché., por supuesto.
Lo maravilloso es que no es necesario almacenar en caché toda la enorme tabla. En el servidor físico residen máquinas virtuales de una cantidad relativamente pequeña de VPC. Solo es necesario almacenar en caché la información sobre esos VPC. La transmisión de datos a otros VPC en la configuración "predeterminada" sigue sin ser legítima. Si se utiliza una funcionalidad como VPC-peering, la información sobre los VPC correspondientes se carga adicionalmente en la caché.
Hemos comprendido la transmisión de datos en el VPC.
Blackfoot
¿Cómo manejar situaciones en las que el tráfico necesita ser transmitido externamente, como a Internet o a través de una VPN hacia la tierra? Aquí es donde nos ayuda Blackfoot un servicio interno de AWS. Ha sido desarrollado por nuestro equipo de Sudáfrica. Por eso, el servicio lleva el nombre de un pingüino que vive en Sudáfrica.
Blackfoot desacapsula el tráfico y hace lo que es necesario. Los datos se envían a Internet tal como están.
Los datos se desacapsulan y se vuelven a encapsular en una envoltura IPsec al usar la VPN.
Al utilizar Direct Connect, el tráfico se etiqueta y se transmite en el VLAN correspondiente.
HyperPlane
Es un servicio interno de control de flujo. Muchos servicios de red requieren controlar el estado del flujo de datos. Por ejemplo, al usar NAT, el control de flujo debe garantizar que cada par «IP: puerto de destino» tenga un puerto de salida único. En el caso del balanceador de carga NLB — Balanceador de Carga de Red, el flujo de datos siempre debe dirigirse a la misma máquina virtual objetivo. Los Grupos de Seguridad son un firewall con estado. Supervisan el tráfico entrante y abren puertos implícitamente para el flujo 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 el funcionamiento de toda la red.
Hyperplane se basa en máquinas virtuales EC2. Aquí no hay magia, solo astucia. La astucia radica en que estas son máquinas virtuales con mucha RAM. Las operaciones son transaccionales y se realizan exclusivamente en memoria. Esto permite lograr latencias de solo decenas de microsegundos. Trabajar con disco arruinaría todo el rendimiento.
Hyperplane es un sistema distribuido compuesto por una gran cantidad de estas máquinas EC2. Cada máquina virtual tiene un ancho de banda de 5 GB/s. A nivel de toda la red regional, esto da increíbles terabits de capacidad y permite procesar millones de conexiones por segundo.
HyperPlane solo trabaja con flujos. La encapsulación de paquetes en VPC es completamente transparente para él. Una posible vulnerabilidad en este servicio interno aún no permitirá romper la aislamiento del VPC. La seguridad es responsabilidad de los niveles inferiores.
Vecino ruidoso
También hay otro problema del vecino ruidoso — vecino ruidoso. Supongamos que tenemos 8 nodos. Estos nodos manejan el tráfico de todos los usuarios de la nube. Parece que todo está bien y la carga debería distribuirse uniformemente entre todos los nodos. Los nodos son muy potentes y es difícil sobrecargarlos.
Pero estamos construyendo nuestra arquitectura teniendo incluso en cuenta escenarios poco probables.
Una baja probabilidad no significa imposibilidad.
Podemos imaginar una situación en la que uno o varios usuarios generen una carga excesiva. Todos los nodos de HyperPlane están involucrados en manejar esta carga y otros usuarios podrían sentir una disminución en el rendimiento. Esto socava el concepto de la nube, donde los inquilinos no deberían influir entre sí.
¿Cómo resolver el problema del vecino ruidoso? Lo primero que se me ocurre es el sharding. Nuestros 8 nodos se dividen lógicamente en 4 shards de 2 nodos cada uno. Ahora, el vecino ruidoso solo afectará a una cuarta parte de todos los usuarios, pero de manera significativa.
Hagámoslo de otra manera. Asignaremos solo 3 nodos a cada usuario.
La clave está en asignar nodos a diferentes usuarios aleatoriamente. En la imagen de abajo, el usuario azul se superpone en nodos con uno de los otros dos usuarios: el verde y el naranja.
Con 8 nodos y 3 usuarios, la probabilidad de que el vecino ruidoso se superponga con uno de los usuarios es del 54%. Es con esta probabilidad que el usuario azul influirá en otros inquilinos. Además, será solo con una parte de su carga. En nuestro ejemplo, esta influencia será perceptible solo para un tercio de todos los usuarios. Ya es un buen resultado.
Número de usuarios que se superpondrán
Probabilidad en porcentaje
0
18%
1
54%
2
26%
3
2%
Acercando la situación a la realidad: tomemos 100 nodos y 5 usuarios en 5 nodos. En este caso, la probabilidad de que ninguno de los nodos se superponga es del 77%.
Número de usuarios que se superpondrán
Probabilidad en porcentaje
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
En la situación real, con una gran cantidad de nodos de HyperPlane y usuarios, la influencia potencial del vecino ruidoso sobre otros usuarios es mínima. Este método se llama shuffle sharding — . Minimiza el efecto negativo de la falla de nodos.Sobre HyperPlane se han construido muchos servicios: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Escalas de la red
Escalabilidad de la red
Ahora hablemos de la magnitud de la red misma. A octubre de 2019, AWS ofrece sus servicios en 22 regiones, y se han planeado otras 9.
- Cada región contiene varias zonas de disponibilidad — Availability Zone. En total, hay 69 en el mundo.
- Cada AZ consiste en Centros de Datos. En total, no hay más de 8.
- En los CED se ubica una gran cantidad de servidores; en algunos, hasta 300,000.
Ahora promediemos todo esto, multipliquemos y obtendremos una cifra impresionante que refleja la magnitud de la nube de Amazon.
Entre las zonas de disponibilidad y los CED hay numerosos canales ópticos. En nuestra mayor región, solo para la conexión entre AZ y los centros de conexión con otras regiones (Transit Centers) hay 388 canales. En total, esto da un impresionante 5000 Tbps.
La red Backbone de AWS está construida específicamente para la nube y optimizada para trabajar con ella. La construimos en canales de 100 Gbps. Los controlamos completamente, exceptuando las regiones en 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 backbone privada. Cada vez más grandes empresas están siguiendo este camino. Esto es confirmado por investigadores independientes, como los de .
En el gráfico se puede ver que la participación de los proveedores de contenido y de la nube está creciendo. Debido a esto, la participación del tráfico de Internet de los proveedores de backbone está disminuyendo constantemente.
Voy a explicar por qué está sucediendo esto. Anteriormente, la mayoría de los servicios web estaban disponibles y se consumían directamente desde Internet. Ahora, cada vez más servidores están ubicados en la nube y son accesibles a través de CDN — Content Distribution Network. Para acceder al recurso, el usuario navega por Internet solo hasta el PoP de CDN más cercano — Point of Presence. La mayoría de las veces, está cerca. Luego, sale de Internet público y por backbone privado vuela a través del Atlántico, por ejemplo, y llega directamente al recurso.
Es interesante cómo cambiará Internet dentro de 10 años si esta tendencia se mantiene.
Canales físicos
Los científicos aún no han encontrado cómo aumentar la velocidad de la luz en el universo, pero han avanzado mucho en los métodos para transmitirla a través de fibra óptica. Ahora utilizamos cables con 6912 fibras. Esto ayuda a optimizar significativamente el costo de su instalación.
En algunas regiones, nos vemos obligados a utilizar cables especiales. Por ejemplo, en la región de Sídney utilizamos cables con un recubrimiento especial contra termitas.
No hay garantía contra los problemas, y a veces nuestros canales se dañan. En la foto de la derecha se pueden ver los cables ópticos en una de las regiones de Estados Unidos que fueron cortados 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 se conmutó literalmente a los canales de respaldo en un instante: la escala funciona.
Hemos recorrido rápidamente algunos servicios y tecnologías de la nube de Amazon. Espero que al menos haya adquirido una idea del alcance de las tareas que nuestros ingenieros deben resolver. Personalmente, esto me fascina mucho.
Esta es la parte final de la trilogía de Vasiliy Pantiukhin sobre la estructura de AWS. En esta parte se describen la optimización de servidores y la escalabilidad de bases de datos, y en — funciones serverless y Firecracker.
En en noviembre, Vasiliy Pantiukhin compartirá nuevos detalles sobre la estructura de Amazon. Él hablará sobre las causas de fallos y el diseño de sistemas distribuidos en Amazon. El 24 de octubre todavía se puede obtener un boleto a buen precio, y pagarlo después. ¡Lo esperamos en HighLoad++, venga y hablemos!
Fuente: habr.com
