Get best of the week

Cómo Yandex.Cloud está alojado en Virtual Private Cloud y cómo nuestros usuarios nos ayudan a implementar funciones útiles

Hola, mi nombre es Kostya Kramlikh, soy un desarrollador líder de la división Virtual Private Cloud en Yandex.Cloud. Estoy involucrado en una red virtual y, como podrán suponer, en este artículo hablaré sobre el dispositivo Virtual Private Cloud (VPC) en general y la red virtual en particular. También aprenderá por qué nosotros, los desarrolladores del servicio, apreciamos los comentarios de nuestros usuarios. Pero lo primero es lo primero.



¿Qué es un VPC?


Hoy en día, para el despliegue de servicios hay una variedad de oportunidades. Estoy seguro de que alguien aún mantiene el servidor bajo la mesa del administrador, aunque, espero, cada vez hay menos historias de este tipo.

Ahora los servicios intentan entrar en las nubes públicas, y aquí se enfrentan a VPC. VPC es una parte de la nube pública que conecta a los usuarios, la infraestructura, la plataforma y otras capacidades, en cualquier lugar, en nuestra nube o más allá. Al mismo tiempo, VPC permite no poner innecesariamente estas capacidades en Internet, permanecen dentro de su red aislada.

Cómo se ve una red virtual desde el exterior




Por VPC, entendemos principalmente la red superpuesta y los servicios de red, como VPNaaS, NATaas, LBaas, etc. Y todo esto funciona además de la infraestructura de red a prueba de fallas, sobre la cual ya había un excelente artículo aquí en Habré.

Veamos la red virtual y su dispositivo más de cerca.



Considere dos áreas de accesibilidad. 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 informáticos.

La red es global. Al mismo tiempo, se proyecta en cada una de las zonas de acceso en forma de una entidad llamada Subred. Para cada subred, asigna un cierto CIDR de tamaño 16 o menos. Puede haber más de una entidad de este tipo en cada zona de disponibilidad, mientras que siempre hay un enrutamiento transparente entre ellas. Esto significa que todos sus recursos dentro de la misma VPC pueden "comunicarse" entre sí, incluso si están en diferentes zonas de acceso. "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 en las direcciones. Ambos pueden pertenecer a usted. Por ejemplo, uno para desarrollo, otro para pruebas. Simplemente puede haber diferentes usuarios, en este caso, no importa. Y una máquina virtual está atascada en cada VPC.



Compuesto el esquema. Puede hacer que una máquina virtual se pegue en varias subredes a la vez. Y no solo así, sino en diferentes redes virtuales.



Al mismo tiempo, si necesita poner automóviles en 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 "blanco" - público. No puede seleccionar una dirección "blanca", se asigna aleatoriamente de nuestro grupo de direcciones. Tan pronto como deja de usar la IP externa, vuelve al grupo. Solo paga por el tiempo que usa la dirección "blanca".



También es posible dar acceso a la máquina a Internet mediante una instancia de NAT. En una instancia, puede obtener tráfico a través de una tabla de enrutamiento estático. Hemos proporcionado tal caso, porque los usuarios lo necesitan, y nosotros lo sabemos. En consecuencia, en nuestro catálogo de imágenes se encuentra una imagen NAT especialmente configurada.



Pero incluso cuando hay una imagen NAT preparada, la configuración puede ser complicada. Nos dimos cuenta de que, para algunos usuarios, esta no es la opción más conveniente, por lo que al final pudimos incluir NAT para la subred deseada con un solo clic. Esta característica todavía está en acceso privado de vista previa, donde se implementa con la ayuda de los miembros de la comunidad.

Cómo funciona una red virtual de adentro hacia afuera





¿Cómo interactúa un usuario con una red virtual? La red mira hacia afuera con su API. El usuario llega a la API y trabaja con el estado de destino. A través de la API, el usuario ve cómo se debe organizar y configurar todo, mientras ve el estado de cuánto difiere el estado real del deseado. Esta es una foto del usuario. ¿Qué está pasando adentro?

Registramos el estado deseado en la base de datos Yandex y vamos a configurar diferentes partes de nuestra VPC. La red de superposición en Yandex.Cloud está construida sobre la base de componentes seleccionados de OpenContrail, que recientemente se ha llamado Tungsten Fabric. Los servicios de red se implementan en una única plataforma CloudGate. En CloudGate, también utilizamos una serie de componentes de código abierto: GoBGP, para acceder a la información de control, y VPP, para implementar un enrutador de software que funciona sobre DPDK para la ruta de datos.

Tungsten Fabric se comunica con CloudGate a través de GoBGP. Cuenta lo que sucede en la red superpuesta. CloudGate, a su vez, conecta redes superpuestas entre sí y a Internet.



Ahora veamos cómo una red virtual aborda la escalabilidad y la disponibilidad. Considere un caso simple. Hay una zona de disponibilidad y se crean dos VPC en ella. Implementamos una instancia de Tungsten Fabric, y atrae a decenas de miles de redes. Las redes se comunican con CloudGate. CloudGate, como hemos dicho, garantiza su conectividad entre sí y con Internet.



Supongamos que se agrega una segunda zona de accesibilidad. Debería fallar completamente independientemente del primero. Por lo tanto, en la segunda zona de acceso, debemos entregar una instancia de Tungsten Fabric separada. Este será un sistema separado que se ocupa de las superposiciones y sabe poco sobre el primer sistema. Y la apariencia de que nuestra red virtual es global, de hecho, crea nuestra API VPC. Esta es su tarea.

VPC1 se proyecta en la zona de acceso B si hay recursos en la zona de acceso B que se adhieren a VPC1. Si no hay recursos de VPC2 en la zona de acceso B, no materializaremos VPC2 en esta zona. A su vez, dado que los recursos de VPC3 solo existen en la zona B, VPC3 no está en la zona A. Todo es simple y lógico.

Veamos un poco más profundo y veamos cómo se organiza 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 esté girando en el hardware, el resto funciona en máquinas virtuales. Construimos servicios de un orden superior basados ​​en servicios de infraestructura básica, y también utilizamos la nube para resolver algunos problemas de ingeniería, por ejemplo, como parte de la Integración continua.



Si observamos un host específico, veremos que tres componentes giran en el sistema operativo host:
  • Compute es la parte responsable de la distribución de recursos informáticos en el host.
  • VRouter es parte de la tela de tungsteno que organiza la superposición, es decir, los paquetes de túneles a través de la capa subyacente.
  • VDisk son piezas de virtualización de almacenamiento.

Además, se lanzaron servicios en máquinas virtuales: servicios de infraestructura en la nube, servicios de plataforma y capacidades del cliente. Las capacidades del cliente y los servicios de la plataforma siempre se superponen a través de VRouter.

Los servicios de infraestructura pueden adherirse a la superposición, pero básicamente quieren trabajar en la superposición. Están atrapados en una capa subyacente por medio de SR-IOV. De hecho, cortamos la tarjeta en tarjetas de red virtuales (funciones virtuales) y las insertamos en máquinas virtuales de infraestructura para no perder rendimiento. Por ejemplo, se lanza el mismo CloudGate como una de esas 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 exactamente 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 el usuario configura 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 descrito por el usuario en el plano de configuración.
  • Plano de datos: procesa directamente los paquetes de usuario.



Como dije anteriormente, todo comienza con el hecho de que un usuario o un servicio de plataforma interna llega a la API y describe un estado objetivo específico.

Este estado se registra inmediatamente en la base de datos Yandex, devuelve el ID de la 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 dicen a Tungsten Fabric qué hacer en la superposición. Por ejemplo, reservan puertos, redes virtuales y similares.



El plano de configuración en Tungsten Fabric envía el estado requerido al plano de control. A través de él, Config Plane se comunica con los hosts, diciéndoles qué se activará en un futuro cercano.



Ahora veamos cómo se ve el sistema en los hosts. En la máquina virtual hay un cierto adaptador de red atascado en VRouter. VRouter es un módulo principal de Tungsten Fabric que analiza los paquetes. Si ya hay flujo para algún paquete, el módulo lo procesa. Si no hay flujo, el módulo realiza el llamado punteo, es decir, envía el paquete al proceso en modo usuario. El proceso analiza el paquete y responde a sí mismo, como, por ejemplo, a DHCP y DNS, o le dice a VRouter qué hacer con él. Después de eso, el VRouter puede procesar el paquete.

Además, el tráfico entre máquinas virtuales dentro de la misma red virtual se ejecuta de forma transparente, no se dirige a CloudGate. Los hosts en los que se implementan máquinas virtuales se comunican directamente entre sí. Tunelan el tráfico y lo reenvían entre sí a través del subsuelo.



El plano de control se comunica entre sí entre las zonas de acceso BGP, como con otro enrutador. Indican en qué máquinas se crían, para que las máquinas virtuales en una zona puedan interactuar directamente con otras máquinas virtuales.



Además, Control Plane se comunica con CloudGate. De manera similar, informa dónde y qué máquinas virtuales se generan, cuáles son sus direcciones. Esto le permite dirigir el tráfico externo y el tráfico de los balanceadores hacia ellos.

El tráfico que sale de VPC llega a CloudGate, en la ruta de datos, donde VPP se mastica rápidamente con nuestros complementos. A continuación, el tráfico se dispara a otras VPC o hacia afuera en los enrutadores de borde que se configuran a través del plano de control de CloudGate.

Planes para el futuro cercano


Si resumimos todo lo anterior en varias oraciones, 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 locales en una sola red.

Y para resolver bien estos problemas, debe proporcionar escalabilidad y tolerancia a fallas a nivel de arquitectura interna, lo que hace VPC.

VPC está adquiriendo funciones gradualmente, nos estamos dando cuenta de nuevas oportunidades, estamos tratando de mejorar algo en términos de conveniencia para el usuario. Algunas ideas se expresan y entran en la lista de prioridades gracias a los miembros de nuestra comunidad.

Ahora tenemos aproximadamente la siguiente lista de planes para el futuro cercano:

  • VPN como servicio.
  • Private DNS – DNS-.
  • DNS .
  • .
  • «» IP- .

El equilibrador y la capacidad de cambiar la dirección IP de la máquina virtual ya creada estaban en esta lista a solicitud de los usuarios. Francamente, sin comentarios explícitos, retomaríamos estas funciones un poco más tarde. Y así, ya estamos trabajando en una tarea sobre direcciones.

Inicialmente, una dirección IP "blanca" solo se podía agregar al crear la máquina. Si el usuario olvidó hacer esto, la máquina virtual tuvo que ser recreada. Lo mismo y, si es necesario, elimine la IP externa. Pronto será posible encender y apagar la IP pública sin volver a crear la máquina.

Siéntase libre de expresar sus ideas y apoyar las sugerencias de otros usuarios. ¡Nos ayudas a mejorar la nube y a obtener características importantes y útiles más rápido!

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles