![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/62b3d222c1911fb28a345defdd81135c.jpeg\")
<\/p>\nHola, me llamo Kostya Kramlih, soy el desarrollador l\u00edder de la divisi\u00f3n Cloud Privado Virtual en Yandex.Cloud. Me ocupo de redes virtuales y, como podr\u00e1s adivinar, en este art\u00edculo hablar\u00e9 sobre la estructura del Cloud Privado Virtual (VPC) en general y sobre redes virtuales en particular. Adem\u00e1s, descubrir\u00e1s por qu\u00e9 nosotros, los desarrolladores del servicio, valoramos la retroalimentaci\u00f3n de nuestros usuarios. Pero todo a su debido tiempo.<\/p>\n
<\/p>\n
<\/a><\/p>\n Hoy en d\u00eda hay diversas oportunidades para desplegar servicios. Estoy seguro de que todav\u00eda hay quien mantiene un servidor debajo del escritorio del administrador, aunque espero que estas historias sean cada vez menos frecuentes.<\/p>\n En la actualidad, los servicios tienden a migrar a nubes p\u00fablicas y aqu\u00ed es donde se encuentran con el VPC. El VPC es una parte de la nube p\u00fablica que conecta recursos de usuario, infraestructura, plataformas y otros componentes en un solo lugar, sin importar d\u00f3nde 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.<\/p>\n 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\u00edculo<\/a> aqu\u00ed mismo, en Habr.<\/p>\n Analicemos la red virtual y su estructura m\u00e1s detenidamente.<\/p>\n 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\u00f3n.<\/p>\n La red es global. Se proyecta en cada una de las zonas de disponibilidad a trav\u00e9s de una entidad llamada Subred. Para cada Subred, se asigna un cierto CIDR con un tama\u00f1o de 16 o menos. En cada zona de disponibilidad, puede haber m\u00e1s 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\u00ed, incluso si se encuentran en diferentes zonas de disponibilidad. \"Comunicarse\" sin salir a internet, a trav\u00e9s de nuestros canales internos, \"pensando\" que est\u00e1n dentro de una red privada.<\/p>\n En el esquema anterior se muestra una situaci\u00f3n t\u00edpica: dos VPC, que se superponen en direcciones en alg\u00fan 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\u00e1 conectada una m\u00e1quina virtual.<\/p>\n Complicamos el esquema. Se puede hacer que una m\u00e1quina virtual est\u00e9 conectada a m\u00faltiples Subnet. Y no de cualquier manera, sino en diferentes redes virtuales.<\/p>\n Al mismo tiempo, si necesita exponer m\u00e1quinas a Internet, puede hacerlo a trav\u00e9s de API o UI. Para ello, es necesario configurar la traducci\u00f3n NAT de su direcci\u00f3n interna \u00abgris\u00bb a \u00abblanca\u00bb \u2013 p\u00fablica. No puede elegir la direcci\u00f3n \u00abblanca\u00bb, 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\u00f3n \u00abblanca\u00bb.<\/p>\n Tambi\u00e9n existe la posibilidad de otorgar a la m\u00e1quina acceso a Internet mediante una instancia NAT. Se puede enrutar el tr\u00e1fico a trav\u00e9s de una tabla de enrutamiento est\u00e1tica. Hemos contemplado este caso, porque a veces es necesario para los usuarios, y lo sabemos. Por lo tanto, en nuestro cat\u00e1logo de im\u00e1genes hay una imagen NAT especialmente configurada.<\/p>\n Pero incluso cuando hay una imagen NAT lista, la configuraci\u00f3n puede ser complicada. Entendemos que para algunos usuarios esta no es la opci\u00f3n m\u00e1s conveniente, por lo que finalmente hicimos posible activar NAT para la Subnet deseada con un solo clic. Esta caracter\u00edstica a\u00fan est\u00e1 en acceso preview cerrado, donde se est\u00e1 probando con la ayuda de miembros de la comunidad.<\/p>\n \u00bfC\u00f3mo interact\u00faa el usuario con la red virtual? La red se comunica externamente a trav\u00e9s de su API. El usuario accede a la API y trabaja con el estado deseado. A trav\u00e9s de la API, el usuario ve c\u00f3mo debe estar configurado todo y, al mismo tiempo, observa el estado, cu\u00e1n diferente es el estado actual del deseado. Esta es la perspectiva del usuario. \u00bfY qu\u00e9 sucede internamente?<\/p>\n 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 \u00fanica plataforma, CloudGate. En CloudGate tambi\u00e9n utilizamos algunos componentes de c\u00f3digo abierto: GoBGP para acceder a informaci\u00f3n de control, as\u00ed como VPP para implementar un enrutador program\u00e1tico que funciona sobre DPDK para la ruta de datos.<\/p>\n Tungsten Fabric se comunica con CloudGate a trav\u00e9s de GoBGP. Informa sobre lo que ocurre en la red de superposici\u00f3n. CloudGate, a su vez, conecta las redes de superposici\u00f3n entre s\u00ed y con internet.<\/p>\n Ahora veamos c\u00f3mo 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\u00ed y con internet.<\/p>\n Supongamos que se a\u00f1ade 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\u00e1 un sistema independiente que maneja la superposici\u00f3n 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\u00f3n.<\/p>\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\u00e1 en la zona A. Es todo simple y l\u00f3gico.<\/p>\n Vamos a profundizar un poco m\u00e1s y ver c\u00f3mo est\u00e1 estructurado un host espec\u00edfico en Yandex.Cloud. Lo principal que quiero se\u00f1alar es que todos los hosts est\u00e1n estructurados de manera id\u00e9ntica. Hacemos que solo el m\u00ednimo necesario de servicios funcione en el 'hardware', mientras que todos los dem\u00e1s operan en m\u00e1quinas virtuales<\/a>. Construimos servicios de orden superior sobre servicios de infraestructura b\u00e1sicos, y tambi\u00e9n utilizamos la Nube para resolver algunas tareas de ingenier\u00eda, por ejemplo, en el contexto de Integraci\u00f3n Continua.<\/p>\n Si miramos a un host espec\u00edfico, veremos que en el sistema operativo del host funcionan tres componentes:<\/p>\n Adem\u00e1s de esto, m\u00e1quinas virtuales<\/a> 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\u00e9s del VRouter.<\/p>\n 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\u00e1quinas virtuales de infraestructura para no perder rendimiento. Por ejemplo, el mismo CloudGate se ejecuta como una de estas m\u00e1quinas virtuales de infraestructura.<\/p>\n Ahora que hemos descrito las tareas globales de la red virtual y la disposici\u00f3n de los componentes b\u00e1sicos de la nube, veamos c\u00f3mo interact\u00faan diferentes partes de la red virtual entre s\u00ed.<\/p>\n En nuestro sistema, destacamos tres capas:<\/p>\n Como mencion\u00e9 anteriormente, todo comienza cuando el usuario o un servicio interno de plataforma llega a la API y describe un cierto estado objetivo.<\/p>\n Este estado se graba inmediatamente en la Yandex Database, devuelve a trav\u00e9s de la API el ID de la operaci\u00f3n asincr\u00f3nica y activa nuestra maquinaria interna para proporcionar el estado que deseaba el usuario. Las tareas de configuraci\u00f3n se env\u00edan al controlador SDN y le indican a Tungsten Fabric qu\u00e9 hacer en el overlay. Por ejemplo, reservan puertos, redes virtuales y as\u00ed sucesivamente.<\/p>\n Config Plane en Tungsten Fabric entrega el estado requerido al Control Plane. A trav\u00e9s de este, Config Plane se comunica con los hosts, informando qu\u00e9 se ejecutar\u00e1 en ellos en breve.<\/p>\n Ahora veamos c\u00f3mo se ve el sistema en los hosts. En una m\u00e1quina virtual<\/a> hay un adaptador de red conectado en el VRouter. El VRouter es un m\u00f3dulo central de Tungsten Fabric que examina los paquetes. Si hay un flujo existente para un paquete, el m\u00f3dulo lo procesa. Si no hay flujo, el m\u00f3dulo realiza lo que se conoce como punting, es decir, env\u00eda el paquete al proceso en modo usuario. El proceso descompone el paquete y responde a \u00e9l, como en el caso de DHCP y DNS, o le dice al VRouter qu\u00e9 hacer. Despu\u00e9s de esto, el VRouter puede procesar el paquete.<\/p>\n Luego, el tr\u00e1fico entre m\u00e1quinas 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\u00e1quinas virtuales se comunican directamente entre s\u00ed. T\u00fanelizan el tr\u00e1fico y lo transmiten entre ellos a trav\u00e9s del underlay.<\/p>\n El Control Plane se comunica entre s\u00ed entre zonas de disponibilidad mediante BGP, como con otro enrutador. Se informan sobre qu\u00e9 m\u00e1quinas est\u00e1n disponibles en cada ubicaci\u00f3n, permitiendo que las m\u00e1quinas virtuales en una zona interact\u00faen directamente con otras m\u00e1quinas virtuales.<\/p>\n Adem\u00e1s, el Control Plane se comunica con CloudGate. Informa de manera similar sobre d\u00f3nde y qu\u00e9 m\u00e1quinas virtuales est\u00e1n activas, as\u00ed como sus direcciones. Esto permite dirigir tr\u00e1fico externo hacia ellas y tr\u00e1fico desde los balanceadores.<\/p>\n El tr\u00e1fico que sale del VPC llega a CloudGate, en la ruta de datos, donde es procesado r\u00e1pidamente por VPP con nuestros plugins. Luego, el tr\u00e1fico se env\u00eda a otros VPC o hacia afuera, a los enrutadores fronterizos que se configuran a trav\u00e9s del Control Plane de CloudGate.<\/p>\n Si resumimos todo lo dicho anteriormente en algunas frases, podemos afirmar que el VPC en Yandex.Cloud resuelve dos tareas importantes:<\/p>\n Y para desempe\u00f1ar 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.<\/p>\n 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\u00f3n de nuestra comunidad.<\/p>\n Actualmente, tenemos aproximadamente la siguiente lista de planes para el futuro cercano:<\/p>\n El balanceador y la posibilidad de cambiar la direcci\u00f3n IP para una m\u00e1quina virtual ya creada fueron incluidos en esta lista a solicitud de los usuarios. Debo ser honesto, sin comentarios expl\u00edcitos, hubi\u00e9ramos abordado estas funciones un poco m\u00e1s tarde. Ahora ya estamos trabajando en la tarea de las direcciones.<\/p>\n Inicialmente, solo se pod\u00eda agregar una direcci\u00f3n IP \"blanca\" al crear la m\u00e1quina. Si el usuario olvidaba hacerlo, ten\u00eda que recrear la m\u00e1quina virtual. Lo mismo suced\u00eda al necesitar eliminar una IP externa. Pronto ser\u00e1 posible activar y desactivar la IP p\u00fablica sin necesidad de recrear la m\u00e1quina.<\/p>\n No dudes en expresar tus ideas y apoyar las sugerencias<\/a> de otros usuarios. \u00a1Nos ayudas a mejorar la Nube y a obtener funciones importantes y \u00fatiles m\u00e1s r\u00e1pido!<\/p>\n\u00bfQu\u00e9 es VPC?<\/h2>\n
C\u00f3mo se ve la red virtual desde afuera<\/h2>\n
![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/073a0cbac0e733decd8a4e6ffd9570ff.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/b1b7a15912f9c7995663ab9943d473f1.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/73e872a4f6c3e19576db4e4980d62a45.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/cc4ab2c7553d63ef2636924df1575479.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/c2375fd6d0fb7b55ca55787adf505229.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/744ac3bdd2f388bab2597d6fe1519d76.jpeg\")
<\/p>\nC\u00f3mo est\u00e1 estructurada una red virtual desde adentro<\/h2>\n
![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/71cab3ae7f067f165a87e30c60559794.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/222d68fff4b9577f316c8642e846172e.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/4da02ba041dcd886eee212dd8998718c.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/4664bd03793ba394ceda1f8214fa2c16.jpeg\")
<\/p>\n\n
\n
![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/644cddfa8bce83a501bf4788a21f9588.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/c2c6e443c93f8dedc6a63e4bd3fd7042.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/2139361a9e1837c7bc7f156e8bc36d38.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/1247f20fa2a12f093d7f1d2361d48a02.jpeg\")
<\/p>\n![\"C\u00f3mo](\"\/wp-content\/uploads\/2020\/02\/f70cd562220c7367e29597d8e8b62f81.jpeg\")
<\/p>\nPlanes para el futuro cercano<\/h2>\n
\n
\n