Ola, chámome Kostya Kramlikh, son o desenvolvedor principal da división Virtual Private Cloud en Yandex.Cloud. Son un usuario de rede virtual e, como podes adiviñar, neste artigo falarei do dispositivo Virtual Private Cloud (VPC) en xeral e da rede virtual en particular. E tamén descubrirás por que nós, os desenvolvedores do servizo, valoramos os comentarios dos nosos usuarios. Pero primeiro o primeiro.
Que é VPC?
Hoxe en día, hai unha variedade de opcións para implementar servizos. Estou seguro de que alguén aínda mantén o servidor baixo a mesa do administrador, aínda que espero que haxa menos historias deste tipo.
Agora os servizos están tentando ir ás nubes públicas, e aquí é onde chocan coas VPC. VPC forma parte dunha nube pública que une usuarios, infraestruturas, plataformas e outras capacidades, estean onde estean, na nosa nube ou fóra dela. Ao mesmo tempo, VPC permítelle non expor estas capacidades a Internet innecesariamente, permanecen dentro da súa rede illada.
Como é unha rede virtual desde fóra?
Por VPC, entendemos principalmente unha rede superposta e servizos de rede, como VPNaaS, NATaas, LBaas, etc. E todo isto funciona ademais dunha infraestrutura de rede tolerante a fallos, que xa foi aquí, en Habré.
Vexamos máis de cerca a rede virtual e o seu dispositivo.
Considere dúas zonas de dispoñibilidade. Ofrecemos unha rede virtual, o que chamamos VPC. De feito, define o espazo de singularidade dos teus enderezos "grises". Dentro de cada rede virtual, tes un control total sobre o espazo de enderezos que podes asignar aos recursos informáticos.
A rede é global. Ao mesmo tempo, proxéctase en cada unha das zonas de dispoñibilidade en forma de entidade chamada Subrede. Para cada subrede, asigna un CIDR de tamaño 16 ou inferior. Pode haber máis dunha entidade deste tipo en cada zona de dispoñibilidade e sempre hai un enrutamento transparente entre elas. Isto significa que todos os teus recursos dentro da mesma VPC poden "falar" entre eles, aínda que estean en zonas de dispoñibilidade diferentes. “Comunicarnos” sen acceso a Internet, a través das nosas canles internas, “pensando” que están dentro da mesma rede privada.
O diagrama anterior mostra unha situación típica: dúas VPC que se cruzan nalgún lugar dos enderezos. Ambos poden ser teus. Por exemplo, un para desenvolvemento e outro para probas. Simplemente pode haber usuarios diferentes, neste caso non importa. E unha máquina virtual está conectada a cada VPC.
Imos empeorar o esquema. Podes facer que unha máquina virtual estea atrapada en varias subredes á vez. E non só así, senón en diferentes redes virtuais.
Ao mesmo tempo, se precisa expor máquinas a Internet, pódese facer a través da API ou da IU. Para iso, debes configurar a tradución NAT do teu enderezo interno "gris" a "branco" - público. Non podes escoller un enderezo "branco", atribúeselle de forma aleatoria do noso conxunto de enderezos. En canto deixes de usar a IP externa, devólvese ao grupo. Só pagas polo tempo de usar o enderezo "branco".
Tamén é posible darlle á máquina acceso a Internet mediante unha instancia NAT. Pode dirixir o tráfico a unha instancia a través dunha táboa de enrutamento estática. Proporcionamos un caso así, porque os usuarios ás veces o necesitan e sabemos del. En consecuencia, o noso catálogo de imaxes contén unha imaxe NAT especialmente configurada.
Pero mesmo cando hai unha imaxe NAT lista, a configuración pode ser complicada. Entendemos que para algúns usuarios esta non é a opción máis cómoda, polo que ao final fixemos posible habilitar NAT para a Subrede desexada cun só clic. Esta función aínda está en acceso pechado de vista previa, onde se proba coa axuda dos membros da comunidade.
Como se organiza a rede virtual desde dentro
Como interactúa o usuario coa rede virtual? A web mira cara a fóra coa súa API. O usuario accede á API e traballa co estado de destino. A través da API, o usuario ve como se debe organizar e configurar todo, mentres ve o estado, o que difiere o estado real do desexado. Esta é unha imaxe do usuario. Que está pasando dentro?
Escribimos o estado desexado na base de datos Yandex e imos a configurar diferentes partes do noso VPC. A rede de superposición en Yandex.Cloud baséase en compoñentes seleccionados de OpenContrail, que se chamou recentemente Tungsten Fabric. Os servizos de rede impléntanse nunha única plataforma CloudGate. En CloudGate, tamén utilizamos unha serie de compoñentes de código aberto: GoBGP - para acceder á información de control, así como VPP - para implementar un enrutador de software que se executa enriba de DPDK para a ruta de datos.
Tungsten Fabric comunícase con CloudGate a través de GoBGP. Indica o que está a suceder na rede de superposición. CloudGate, pola súa banda, conecta redes superpostas entre si e con Internet.
Agora vexamos como unha rede virtual resolve os problemas de escalado e dispoñibilidade. Consideremos un caso sinxelo. Hai unha zona de dispoñibilidade e nela créanse dúas VPC. Implementamos unha instancia de Tungsten Fabric, que atrae varias decenas de miles de redes. As redes comunícanse con CloudGate. CloudGate, como xa dixemos, garante a súa conectividade entre si e con Internet.
Digamos que se engade unha segunda zona de dispoñibilidade. Debería fallar completamente independentemente do primeiro. Polo tanto, na segunda zona de dispoñibilidade, debemos instalar unha instancia separada de Tungsten Fabric. Este será un sistema separado que se ocupa da superposición e sabe pouco sobre o primeiro sistema. E a visibilidade de que a nosa rede virtual é global, de feito, crea a nosa API de VPC. Esta é a súa tarefa.
VPC1 está asignado á Zona de dispoñibilidade B se hai recursos na Zona de dispoñibilidade B que se envían a VPC1. Se non hai recursos de VPC2 na zona de dispoñibilidade B, non materializaremos VPC2 nesta zona. Pola súa banda, dado que os recursos de VPC3 só existen na zona B, VPC3 non existe na zona A. Todo é sinxelo e lóxico.
Afondemos un pouco máis e vexamos como funciona un host en particular en Y.Cloud. O principal que quero destacar é que todos os hosts están organizados da mesma forma. Facemos que só o mínimo necesario de servizos funcione en hardware, todo o resto funcione en máquinas virtuais. Construímos servizos de orde superior baseados en servizos de infraestrutura básica, e tamén utilizamos a nube para resolver algúns problemas de enxeñería, por exemplo, no marco da Integración Continua.
Se observamos un host específico, podemos ver que hai tres compoñentes que se executan no sistema operativo host:
- Compute - a parte responsable da distribución dos recursos informáticos no host.
- VRouter é unha parte de Tungsten Fabric que organiza unha superposición, é dicir, túnel de paquetes a través dunha capa inferior.
- Os VDisks son anacos de virtualización do almacenamento.
Ademais, lánzanse servizos en máquinas virtuais: servizos de infraestrutura na nube, servizos de plataforma e capacidades dos clientes. As capacidades dos clientes e os servizos da plataforma sempre van á superposición a través de VRouter.
Os servizos de infraestrutura poden manterse na superposición, pero basicamente queren traballar na capa inferior. Están pegados na capa inferior coa axuda de SR-IOV. De feito, cortamos a tarxeta en tarxetas de rede virtuais (funcións virtuais) e empúxoas a máquinas virtuais de infraestrutura para non perder rendemento. Por exemplo, o mesmo CloudGate lánzase como unha destas máquinas virtuais de infraestrutura.
Agora que describimos as tarefas globais da rede virtual e a estrutura dos compoñentes básicos da nube, vexamos como interactúan exactamente as diferentes partes da rede virtual entre si.
Distinguimos tres capas no noso sistema:
- Plano de configuración: establece o estado de destino do sistema. Isto é o que o usuario configura a través da API.
- Plano de control: proporciona semántica definida polo usuario, é dicir, leva o estado do plano de datos ao descrito polo usuario en Plano de configuración.
- Plano de datos: procesa directamente os paquetes do usuario.
Como dixen anteriormente, todo comeza co feito de que o usuario ou o servizo da plataforma interna chega á API e describe un determinado estado de destino.
Este estado escríbese inmediatamente na base de datos Yandex, devolve o ID da operación asíncrona a través da API e inicia a nosa maquinaria interna para devolver o estado que quería o usuario. As tarefas de configuración van ao controlador SDN e indican a Tungsten Fabric que facer na superposición. Por exemplo, reservan portos, redes virtuais e similares.
Config Plane en Tungsten Fabric envía o estado necesario ao Control Plane. A través del, Config Plane comunícase cos anfitrións, dicindo exactamente o que lles vai xirar en breve.
Agora vexamos como se ve o sistema nos hosts. A máquina virtual ten un adaptador de rede conectado a VRouter. VRouter é un módulo básico de Tungsten Fabric que analiza os paquetes. Se xa hai un fluxo para algún paquete, o módulo procesao. Se non hai fluxo, o módulo fai o chamado punting, é dicir, envía un paquete ao proceso usermod. O proceso analiza o paquete e responde a el mesmo, como DHCP e DNS, ou indica a VRouter que facer con el. Despois diso, VRouter pode procesar o paquete.
Ademais, o tráfico entre máquinas virtuais dentro da mesma rede virtual vai de forma transparente, non está dirixido a CloudGate. Os hosts nos que están implantadas as máquinas virtuais comunícanse directamente entre si. Túnelen o tráfico e envíano un para o outro a través da capa inferior.
Os avións de control comunícanse entre si entre as zonas de dispoñibilidade mediante BGP, como ocorre con outro enrutador. Eles indican cales son as máquinas onde se atopan para que as máquinas virtuales dunha zona poidan comunicarse directamente con outras máquinas virtuales.
E Control Plane comunícase con CloudGate. Do mesmo xeito, informa onde e que máquinas virtuais se levantan, que enderezos teñen. Isto permítelle dirixir o tráfico externo e o tráfico dos equilibradores a eles.
O tráfico que sae do VPC chega a CloudGate, á ruta de datos, onde o VPP cos nosos complementos é rapidamente mastigado. A continuación, o tráfico despídese a outras VPC ou ao exterior, aos enrutadores de fronteira que se configuran a través do propio Plano de Control de CloudGate.
Plans para o futuro próximo
Se resumimos todo o dito anteriormente nunhas poucas frases, podemos dicir que VPC en Yandex.Cloud resolve dúas tarefas importantes:
- Proporciona illamento entre diferentes clientes.
- Combina recursos, infraestrutura, servizos de plataforma, outras nubes e local nunha única rede.
E para resolver ben estes problemas, cómpre proporcionar escalabilidade e tolerancia a fallos a nivel da arquitectura interna, o que fai VPC.
Pouco a pouco VPC adquire funcións, implementamos novas funcionalidades, intentamos mellorar algo en canto á comodidade do usuario. Algunhas ideas son expresadas e pasan á lista de prioridades grazas aos membros da nosa comunidade.
Actualmente temos a seguinte lista de plans para o futuro próximo:
- VPN como servizo.
- As instancias de DNS privadas son imaxes para configurar rapidamente máquinas virtuais cun servidor DNS preconfigurado.
- DNS como servizo.
- Balanceador de carga interno.
- Engadir un enderezo IP "branco" sen recrear a máquina virtual.
O equilibrador e a posibilidade de cambiar o enderezo IP dunha máquina virtual xa creada estaban nesta lista a petición dos usuarios. Para ser honesto, sen comentarios explícitos, asumiríamos estas funcións un pouco máis tarde. E por iso xa estamos traballando no problema dos enderezos.
Inicialmente, só se podía engadir un enderezo IP "branco" ao crear unha máquina. Se o usuario esquecía facelo, había que recrear a máquina virtual. O mesmo e, se é necesario, elimina a IP externa. En breve será posible activar e desactivar a IP pública sen ter que recrear a máquina.
Non dubides en expresar o teu outros usuarios. Axúdanos a mellorar a nube e a conseguir funcións importantes e útiles máis rápido!
Fonte: www.habr.com