Hola, me llamo Kostya Kramlih, soy el desarrollador líder de la división Cloud Privado Virtual en Yandex.Cloud. Me ocupo de redes virtuales y, como podrás adivinar, en este artículo hablaré sobre la estructura del Cloud Privado Virtual (VPC) en general y sobre redes virtuales en particular. Además, descubrirás por qué nosotros, los desarrolladores del servicio, valoramos la retroalimentación de nuestros usuarios. Pero todo a su debido tiempo.
¿Qué es VPC?
Hoy en día hay diversas oportunidades para desplegar servicios. Estoy seguro de que todavía hay quien mantiene un servidor debajo del escritorio del administrador, aunque espero que estas historias sean cada vez menos frecuentes.
En la actualidad, los servicios tienden a migrar a nubes públicas y aquí es donde se encuentran con el VPC. El VPC es una parte de la nube pública que conecta recursos de usuario, infraestructura, plataformas y otros componentes en un solo lugar, sin importar dónde se encuentren, ya sea en nuestra nube o fuera de ella. Al mismo tiempo, el VPC permite no exponer innecesariamente estos recursos a internet, permaneciendo dentro de su red aislada.
Cómo se ve la red virtual desde afuera
Bajo VPC entendemos principalmente una red superpuesta y servicios de red como VPNaaS, NATaas, LBaas, etc. Todo esto funciona sobre una infraestructura de red resistente, de la cual ya hemos hablado un excelente artículo aquí mismo, en Habr.
Analicemos la red virtual y su estructura más detenidamente.
Consideremos dos zonas de disponibilidad. Proporcionamos una red virtual, lo que llamamos VPC. De hecho, define el espacio de unicidad de sus direcciones "grises". Dentro de cada red virtual, usted controla completamente el espacio de direcciones que puede asignar a los recursos de computación.
La red es global. Se proyecta en cada una de las zonas de disponibilidad a través de una entidad llamada Subred. Para cada Subred, se asigna un cierto CIDR con un tamaño de 16 o menos. En cada zona de disponibilidad, puede haber más de una de tales entidades, existiendo siempre un enrutamiento transparente entre ellas. Esto significa que todos sus recursos dentro de un VPC pueden "comunicarse" entre sí, incluso si se encuentran en diferentes zonas de disponibilidad. "Comunicarse" sin salir a internet, a través de nuestros canales internos, "pensando" que están dentro de una red privada.
En el esquema anterior se muestra una situación típica: dos VPC, que se superponen en direcciones en algún lugar. Ambas pueden pertenecerle. Por ejemplo, una para desarrollo y la otra para pruebas. Pueden ser simplemente diferentes usuarios; en este caso, no importa. Y en cada VPC está conectada una máquina virtual.
Complicamos el esquema. Se puede hacer que una máquina virtual esté conectada a múltiples Subnet. Y no de cualquier manera, sino en diferentes redes virtuales.
Al mismo tiempo, si necesita exponer máquinas a Internet, puede hacerlo a través de API o UI. Para ello, es necesario configurar la traducción NAT de su dirección interna «gris» a «blanca» – pública. No puede elegir la dirección «blanca», se asigna aleatoriamente de nuestro grupo de direcciones. Una vez que deja de usar la IP externa, regresa al grupo. Solo paga por el tiempo de uso de la dirección «blanca».
También existe la posibilidad de otorgar a la máquina acceso a Internet mediante una instancia NAT. Se puede enrutar el tráfico a través de una tabla de enrutamiento estática. Hemos contemplado este caso, porque a veces es necesario para los usuarios, y lo sabemos. Por lo tanto, en nuestro catálogo de imágenes hay una imagen NAT especialmente configurada.
Pero incluso cuando hay una imagen NAT lista, la configuración puede ser complicada. Entendemos que para algunos usuarios esta no es la opción más conveniente, por lo que finalmente hicimos posible activar NAT para la Subnet deseada con un solo clic. Esta característica aún está en acceso preview cerrado, donde se está probando con la ayuda de miembros de la comunidad.
Cómo está estructurada una red virtual desde adentro
¿Cómo interactúa el usuario con la red virtual? La red se comunica externamente a través de su API. El usuario accede a la API y trabaja con el estado deseado. A través de la API, el usuario ve cómo debe estar configurado todo y, al mismo tiempo, observa el estado, cuán diferente es el estado actual del deseado. Esta es la perspectiva del usuario. ¿Y qué sucede internamente?
Registramos el estado deseado en Yandex Database y procedemos a configurar varias partes de nuestra VPC. La red de superposiciones en Yandex.Cloud se construye sobre componentes seleccionados de OpenContrail, que recientemente ha pasado a llamarse Tungsten Fabric. Los servicios de red se implementan en una única plataforma, CloudGate. En CloudGate también utilizamos algunos componentes de código abierto: GoBGP para acceder a información de control, así como VPP para implementar un enrutador programático que funciona sobre DPDK para la ruta de datos.
Tungsten Fabric se comunica con CloudGate a través de GoBGP. Informa sobre lo que ocurre en la red de superposición. CloudGate, a su vez, conecta las redes de superposición entre sí y con internet.
Ahora veamos cómo la red virtual aborda los problemas de escalabilidad y disponibilidad. Consideremos un caso simple. Hay una zona de disponibilidad y en ella se han creado dos VPC. Hemos desplegado una instancia de Tungsten Fabric, la cual soporta decenas de miles de redes. Las redes se conectan a CloudGate. CloudGate, como mencionamos antes, asegura su conectividad entre sí y con internet.
Supongamos que se añade una segunda zona de disponibilidad. Esta debe fallar de manera completamente independiente de la primera. Por lo tanto, en la segunda zona de disponibilidad debemos implementar una instancia separada de Tungsten Fabric. Este será un sistema independiente que maneja la superposición y sabe poco sobre el primer sistema. La visibilidad de que nuestra red virtual es global la establece, de hecho, nuestra API de VPC. Esa es su función.
VPC1 se proyecta en la zona de disponibilidad B, si hay recursos en la zona de disponibilidad B que se conectan a VPC1. Si no hay recursos de VPC2 en la zona de disponibilidad B, no materializaremos VPC2 en esa zona. A su vez, dado que los recursos de VPC3 existen solo en la zona B, VPC3 no está en la zona A. Es todo simple y lógico.
Vamos a profundizar un poco más y ver cómo está estructurado un host específico en Yandex.Cloud. Lo principal que quiero señalar es que todos los hosts están estructurados de manera idéntica. Hacemos que solo el mínimo necesario de servicios funcione en el 'hardware', mientras que todos los demás operan en máquinas virtuales. Construimos servicios de orden superior sobre servicios de infraestructura básicos, y también utilizamos la Nube para resolver algunas tareas de ingeniería, por ejemplo, en el contexto de Integración Continua.
Si miramos a un host específico, veremos que en el sistema operativo del host funcionan tres componentes:
- Compute – la parte responsable de distribuir los recursos de computo en el host.
- VRouter – parte de Tungsten Fabric que organiza el overlay, es decir, encapsula paquetes a través del underlay.
- VDisk – son fragmentos de virtualización de almacenamiento.
Además de esto, máquinas virtuales se ejecutan servicios: servicios de infraestructura de la Nube, servicios de plataforma y capacidades de los clientes. Las capacidades de los clientes y los servicios de plataforma siempre se gestionan en el overlay a través del VRouter.
Los servicios de infraestructura pueden conectarse al overlay, pero principalmente desean operar en el underlay. En el underlay se conectan mediante SR-IOV. De hecho, estamos dividiendo la tarjeta en tarjetas de red virtuales (funciones virtuales) y las introducimos en máquinas virtuales de infraestructura para no perder rendimiento. Por ejemplo, el mismo CloudGate se ejecuta como una de estas máquinas virtuales de infraestructura.
Ahora que hemos descrito las tareas globales de la red virtual y la disposición de los componentes básicos de la nube, veamos cómo interactúan diferentes partes de la red virtual entre sí.
En nuestro sistema, destacamos tres capas:
- Config Plane – define el estado deseado del sistema. Es lo que el usuario configura a través de la API.
- Control Plane – asegura la semántica proporcionada por el usuario, es decir, lleva el estado del Data Plane a lo que fue descrito por el usuario en el Config Plane.
- Data Plane – procesa directamente los paquetes del usuario.
Como mencioné anteriormente, todo comienza cuando el usuario o un servicio interno de plataforma llega a la API y describe un cierto estado objetivo.
Este estado se graba inmediatamente en la Yandex Database, devuelve a través de la API el ID de la operación asincrónica y activa nuestra maquinaria interna para proporcionar el estado que deseaba el usuario. Las tareas de configuración se envían al controlador SDN y le indican a Tungsten Fabric qué hacer en el overlay. Por ejemplo, reservan puertos, redes virtuales y así sucesivamente.
Config Plane en Tungsten Fabric entrega el estado requerido al Control Plane. A través de este, Config Plane se comunica con los hosts, informando qué se ejecutará en ellos en breve.
Ahora veamos cómo se ve el sistema en los hosts. En una máquina virtual hay un adaptador de red conectado en el VRouter. El VRouter es un módulo central de Tungsten Fabric que examina los paquetes. Si hay un flujo existente para un paquete, el módulo lo procesa. Si no hay flujo, el módulo realiza lo que se conoce como punting, es decir, envía el paquete al proceso en modo usuario. El proceso descompone el paquete y responde a él, como en el caso de DHCP y DNS, o le dice al VRouter qué hacer. Después de esto, el VRouter puede procesar el paquete.
Luego, el tráfico entre máquinas virtuales dentro de una misma red virtual fluye de manera transparente, no se dirige hacia CloudGate. Los hosts en los que se despliegan las máquinas virtuales se comunican directamente entre sí. Túnelizan el tráfico y lo transmiten entre ellos a través del underlay.
El Control Plane se comunica entre sí entre zonas de disponibilidad mediante BGP, como con otro enrutador. Se informan sobre qué máquinas están disponibles en cada ubicación, permitiendo que las máquinas virtuales en una zona interactúen directamente con otras máquinas virtuales.
Además, el Control Plane se comunica con CloudGate. Informa de manera similar sobre dónde y qué máquinas virtuales están activas, así como sus direcciones. Esto permite dirigir tráfico externo hacia ellas y tráfico desde los balanceadores.
El tráfico que sale del VPC llega a CloudGate, en la ruta de datos, donde es procesado rápidamente por VPP con nuestros plugins. Luego, el tráfico se envía a otros VPC o hacia afuera, a los enrutadores fronterizos que se configuran a través del Control Plane de CloudGate.
Planes para el futuro cercano
Si resumimos todo lo dicho anteriormente en algunas frases, podemos afirmar que el VPC en Yandex.Cloud resuelve dos tareas importantes:
- Proporciona aislamiento entre diferentes clientes.
- Integra recursos, infraestructura, servicios de plataforma, otras nubes y on-premise en una única red.
Y para desempeñar bien estas funciones, es necesario garantizar la escalabilidad y la resiliencia en el nivel de arquitectura interna, que es precisamente lo que hace el VPC.
Gradualmente, el VPC se enriquece con funciones, implementamos nuevas capacidades y nos esforzamos por mejorar la comodidad para los usuarios. Algunas ideas se comunican y entran en la lista de prioridades gracias a la participación de nuestra comunidad.
Actualmente, tenemos aproximadamente la siguiente lista de planes para el futuro cercano:
- VPN como servicio.
- Instancias de DNS privado: imágenes para la configuración rápida de máquinas virtuales con un servidor DNS preconfigurado.
- DNS como servicio.
- Balanceador de carga interno.
- Adición de una dirección IP "blanca" sin necesidad de recrear la máquina virtual.
El balanceador y la posibilidad de cambiar la dirección IP para una máquina virtual ya creada fueron incluidos en esta lista a solicitud de los usuarios. Debo ser honesto, sin comentarios explícitos, hubiéramos abordado estas funciones un poco más tarde. Ahora ya estamos trabajando en la tarea de las direcciones.
Inicialmente, solo se podía agregar una dirección IP "blanca" al crear la máquina. Si el usuario olvidaba hacerlo, tenía que recrear la máquina virtual. Lo mismo sucedía al necesitar eliminar una IP externa. Pronto será posible activar y desactivar la IP pública sin necesidad de recrear la máquina.
No dudes en expresar tus ideas y apoyar las sugerencias de otros usuarios. ¡Nos ayudas a mejorar la Nube y a obtener funciones importantes y útiles más rápido!
Fuente: habr.com
