Hola, mi nombre es Kostya Kramlikh, soy el desarrollador principal de la división Virtual Private Cloud en Yandex.Cloud. Soy un usuario de redes virtuales y, como puede suponer, en este artículo hablaré sobre el dispositivo de nube privada virtual (VPC) en general y la red virtual en particular. Y también descubrirá por qué nosotros, los desarrolladores del servicio, valoramos los comentarios de nuestros usuarios. Pero primero lo primero.
¿Qué es VPC?
Hoy en día, hay una variedad de opciones para implementar servicios. Estoy seguro de que alguien todavía mantiene el servidor debajo del escritorio del administrador, aunque espero que haya menos historias de este tipo.
Ahora los servicios intentan ir a las nubes públicas, y aquí es donde chocan con las VPC. VPC es parte de una nube pública que une al usuario, la infraestructura, la plataforma y otras capacidades, donde sea que estén, en nuestra nube o fuera de ella. Al mismo tiempo, VPC le permite no exponer estas capacidades a Internet innecesariamente, permanecen dentro de su red aislada.
¿Cómo se ve una red virtual desde el exterior?
Por VPC, nos referimos principalmente a una red superpuesta y servicios de red, como VPNaaS, NATaas, LBaas, etc. Y todo esto funciona sobre una infraestructura de red tolerante a fallas, que ya ha sido aquí, en Habré.
Echemos un vistazo más de cerca a la red virtual y su dispositivo.
Considere dos zonas de disponibilidad. Proporcionamos una red virtual, lo que llamamos VPC. De hecho, define el espacio de singularidad de sus direcciones "grises". Dentro de cada red virtual, tiene control total sobre el espacio de direcciones que puede asignar a los recursos informáticos.
La red es mundial. Al mismo tiempo, se proyecta sobre cada una de las zonas de disponibilidad en forma de una entidad denominada Subred. Para cada subred, asigna un CIDR de tamaño 16 o menos. Puede haber más de una entidad de este tipo en cada zona de disponibilidad y siempre hay un enrutamiento transparente entre ellas. Esto significa que todos sus recursos dentro de la misma VPC pueden "hablar" entre sí, incluso si se encuentran en diferentes zonas de disponibilidad. "Comunicarse" sin acceso a Internet, a través de nuestros canales internos, "pensando" que están dentro de la misma red privada.
El diagrama anterior muestra una situación típica: dos VPC que se cruzan en algún lugar de las direcciones. Ambos pueden ser tuyos. Por ejemplo, uno para desarrollo, el otro para pruebas. Simplemente puede haber diferentes usuarios; en este caso, no importa. Y una máquina virtual está conectada a cada VPC.
Empeoremos el esquema. Puede hacer que una máquina virtual se atasque en varias subredes a la vez. Y no solo así, sino en diferentes redes virtuales.
Al mismo tiempo, si necesita exponer máquinas a Internet, puede hacerlo a través de la API o la interfaz de usuario. Para hacer esto, debe configurar la traducción NAT de su dirección interna "gris" a "blanca" - pública. No puede elegir una dirección "blanca", se asigna aleatoriamente de nuestro conjunto de direcciones. Tan pronto como deja de usar la IP externa, se devuelve al grupo. Solo pagas por el tiempo de uso de la dirección "blanca".
También es posible dar a la máquina acceso a Internet mediante una instancia de NAT. Puede enrutar el tráfico a una instancia a través de una tabla de enrutamiento estática. Hemos proporcionado tal caso, porque los usuarios a veces lo necesitan, y lo sabemos. En consecuencia, nuestro catálogo de imágenes contiene una imagen NAT especialmente configurada.
Pero incluso cuando hay una imagen NAT lista, la configuración puede ser complicada. Entendimos que para algunos usuarios esta no es la opción más conveniente, por lo que al final hicimos posible habilitar NAT para la Subred deseada en un solo clic. Esta función aún se encuentra en acceso de vista previa cerrado, donde se prueba con la ayuda de miembros de la comunidad.
Cómo se organiza la red virtual desde el interior
¿Cómo interactúa el usuario con la red virtual? La web mira hacia afuera con su API. El usuario llega a la API y trabaja con el estado objetivo. A través de la API, el usuario ve cómo debe organizarse y configurarse todo, mientras ve el estado, cuánto difiere el estado real del deseado. Esta es una imagen del usuario. ¿Qué está pasando dentro?
Escribimos el estado deseado en Yandex Database y vamos a configurar diferentes partes de nuestra VPC. La red de superposición en Yandex.Cloud se basa en componentes seleccionados de OpenContrail, que recientemente se llamó Tungsten Fabric. Los servicios de red se implementan en una sola plataforma CloudGate. En CloudGate, también utilizamos una serie de componentes de código abierto: GoBGP, para acceder a la información de control, así como VPP, para implementar un enrutador de software que se ejecuta sobre DPDK para la ruta de datos.
Tungsten Fabric se comunica con CloudGate a través de GoBGP. Dice lo que está pasando en la red superpuesta. CloudGate, a su vez, conecta redes superpuestas entre sí y con Internet.
Ahora veamos cómo una red virtual resuelve los problemas de escalabilidad y disponibilidad. Consideremos un caso simple. Hay una zona de disponibilidad y se crean dos VPC en ella. Implementamos una instancia de Tungsten Fabric y extrae varias decenas de miles de redes. Las redes se comunican con CloudGate. CloudGate, como ya hemos dicho, asegura su conectividad entre sí y con Internet.
Digamos que se agrega una segunda zona de disponibilidad. Debería fallar completamente independientemente del primero. Por lo tanto, en la segunda zona de disponibilidad, debemos instalar una instancia de Tungsten Fabric independiente. Este será un sistema separado que se ocupa de la superposición y sabe poco sobre el primer sistema. Y la visibilidad de que nuestra red virtual es global, de hecho, crea nuestra API de VPC. Esta es su tarea.
VPC1 se asigna a la Zona de disponibilidad B si hay recursos en la Zona de disponibilidad B que se envían a VPC1. Si no hay recursos de VPC2 en la zona de disponibilidad B, no materializaremos VPC2 en esta zona. A su vez, dado que los recursos de VPC3 existen solo en la zona B, VPC3 no existe en la zona A. Todo es simple y lógico.
Profundicemos un poco más y veamos cómo funciona un host en particular en Y.Cloud. Lo principal que quiero señalar es que todos los hosts están organizados de la misma manera. Lo hacemos para que solo el mínimo necesario de servicios se ejecute en hardware, todo el resto se ejecute en máquinas virtuales. Construimos servicios de orden superior basados en servicios básicos de infraestructura, y también utilizamos la Nube para resolver algunos problemas de ingeniería, por ejemplo, en el marco de la Integración Continua.
Si observamos un host específico, podemos ver que hay tres componentes que se ejecutan en el sistema operativo del host:
- Compute: la parte responsable de la distribución de los recursos informáticos en el host.
- VRouter es una parte de Tungsten Fabric que organiza una superposición, es decir, canaliza paquetes a través de una capa subyacente.
- Los discos virtuales son fragmentos de virtualización de almacenamiento.
Además, se lanzan servicios en máquinas virtuales: servicios de infraestructura en la nube, servicios de plataforma y capacidades de clientes. Las capacidades del cliente y los servicios de la plataforma siempre van a la superposición a través de VRouter.
Los servicios de infraestructura pueden adherirse a la superposición, pero básicamente quieren trabajar en la base. Se pegan en la base con la ayuda de SR-IOV. De hecho, cortamos la tarjeta en tarjetas de red virtual (funciones virtuales) y las insertamos en máquinas virtuales de infraestructura para no perder rendimiento. Por ejemplo, el mismo CloudGate se lanza como una de estas máquinas virtuales de infraestructura.
Ahora que hemos descrito las tareas globales de la red virtual y la estructura de los componentes básicos de la nube, veamos exactamente cómo interactúan entre sí las diferentes partes de la red virtual.
Distinguimos tres capas en nuestro sistema:
- Plano de configuración: establece el estado objetivo del sistema. Esto es lo que configura el usuario a través de la API.
- Plano de control: proporciona una semántica definida por el usuario, es decir, lleva el estado del plano de datos a lo que describió el usuario en el plano de configuración.
- Plano de datos: procesa directamente los paquetes del usuario.
Como dije anteriormente, todo comienza con el hecho de que el usuario o el servicio de la plataforma interna llega a la API y describe un determinado estado objetivo.
Este estado se escribe inmediatamente en la base de datos de Yandex, devuelve el ID de operación asincrónica a través de la API e inicia nuestra maquinaria interna para devolver el estado que el usuario deseaba. Las tareas de configuración van al controlador SDN y le indican a Tungsten Fabric qué hacer en la superposición. Por ejemplo, reservan puertos, redes virtuales y similares.
Config Plane en Tungsten Fabric envía el estado requerido al Control Plane. A través de él, Config Plane se comunica con los anfitriones, diciéndoles exactamente qué estará girando sobre ellos pronto.
Ahora veamos cómo se ve el sistema en los hosts. La máquina virtual tiene un adaptador de red conectado a VRouter. VRouter es un módulo central de Tungsten Fabric que analiza los paquetes. Si ya existe un flujo para algún paquete, el módulo lo procesa. Si no hay flujo, el módulo hace el llamado punting, es decir, envía un paquete al proceso usermod. El proceso analiza el paquete y responde por sí mismo, como DHCP y DNS, o le dice a VRouter qué hacer con él. Después de eso, VRouter puede procesar el paquete.
Además, el tráfico entre máquinas virtuales dentro de la misma red virtual se realiza de forma transparente, no se dirige a CloudGate. Los hosts en los que se implementan las máquinas virtuales se comunican directamente entre sí. Canalizan el tráfico y lo reenvían entre sí a través de la base.
Los planos de control se comunican entre sí entre zonas de disponibilidad a través de BGP, como con otro enrutador. Indican qué máquinas están activas y dónde para que las VM en una zona puedan comunicarse directamente con otras VM.
Y Control Plane se comunica con CloudGate. De igual forma, informa dónde y qué máquinas virtuales están levantadas, qué direcciones tienen. Esto le permite dirigir el tráfico externo y el tráfico de los balanceadores hacia ellos.
El tráfico que sale de la VPC llega a CloudGate, a la ruta de datos, donde se mastica rápidamente la VPP con nuestros complementos. Luego, el tráfico se envía a otras VPC o al exterior, a los enrutadores fronterizos que se configuran a través del plano de control de CloudGate.
Planes para el futuro cercano
Si resumimos todo lo dicho anteriormente en unas pocas frases, podemos decir que VPC en Yandex.Cloud resuelve dos tareas importantes:
- Proporciona aislamiento entre diferentes clientes.
- Combina recursos, infraestructura, servicios de plataforma, otras nubes y en las instalaciones en una sola red.
Y para resolver bien estos problemas, debe proporcionar escalabilidad y tolerancia a fallas al nivel de la arquitectura interna, lo cual hace VPC.
Poco a poco, VPC adquiere funciones, implementamos nuevas características, tratamos de mejorar algo en términos de comodidad para el usuario. Algunas ideas se expresan y se incluyen en la lista de prioridades gracias a los miembros de nuestra comunidad.
Actualmente tenemos la siguiente lista de planes para el futuro cercano:
- VPN como servicio.
- Las instancias de DNS privado son imágenes para configurar rápidamente máquinas virtuales con un servidor DNS preconfigurado.
- DNS como un servicio.
- Equilibrador de carga interno.
- Agregar una dirección IP "blanca" sin volver a crear la máquina virtual.
El equilibrador y la capacidad de cambiar la dirección IP de una máquina virtual ya creada estaban en esta lista a pedido de los usuarios. Para ser honesto, sin comentarios explícitos, habríamos asumido estas funciones un poco más tarde. Así que ya estamos trabajando en el problema de las direcciones.
Inicialmente, solo se podía agregar una dirección IP "blanca" al crear una máquina. Si el usuario se olvidaba de hacer esto, la máquina virtual tenía que volver a crearse. Lo mismo y, si es necesario, eliminar la IP externa. Pronto será posible activar y desactivar la IP pública sin tener que volver a crear la máquina.
Siéntete libre de expresar tu otros usuarios. ¡Usted nos ayuda a mejorar la nube y obtener funciones importantes y útiles más rápido!
Fuente: habr.com