Herramientas de redes de nube privada para VMware Engine
En este documento, se proporciona una descripción general de Google Cloud VMware Engine, se analizan conceptos de herramientas de redes, se revisan los flujos de tráfico más típicos y se incluyen algunas consideraciones para usar VMware Engine a fin de diseñar una arquitectura. En el documento, se explica cómo funciona VMware Engine, cuáles son sus capacidades y qué se debe considerar para elegir la mejor arquitectura.
Este documento es relevante para ti si eres ingeniero de redes, ingeniero de nube, arquitecto o operador con tarea de diseñar, mantener o solucionar problemas de seguridad, conectividad y disponibilidad de aplicaciones respaldadas por VMware alojadas en Google Cloud.
También te ayuda a obtener más información sobre VMware Engine, y sus requisitos y capacidades. A medida que profundizas en la tecnología, o si la vas a probar o a implementar en producción, este documento te ayuda a comprender cómo funciona VMware Engine y cómo integrarlo en un entorno nuevo o existente de Google Cloud. En este documento, se revisan todos los aspectos de las herramientas de redes y se te ayuda a determinar la mejor solución para tu caso de uso.
Las herramientas de redes de VMware Engine se integran en las redes de nube privada virtual (VPC) que tienen conectividad existente con las redes locales y también con otros servicios de Google Cloud. VMware Engine se basa en una infraestructura de alto rendimiento, confiable y de alta capacidad para brindarte una experiencia de VMware rentable y óptima.
Descripción general
VMware Engine es un servicio que proporciona Google y que te ayuda a migrar y ejecutar tus cargas de trabajo de VMware en Google Cloud.
VMware Engine ofrece un centro de datos definido por software (SDDC) de VMware completamente administrado, que consta de los siguientes componentes: VMware vSphere, vCenter Server, vSAN y NSX-T. VMware Engine incluye HCX para la migración a la nube en un entorno dedicado en Google Cloud con el fin de admitir las cargas de trabajo de producción empresariales. Puedes usar VMware Engine para migrar o extender tus cargas de trabajo locales a Google Cloud si te conectas a un entorno de VMware dedicado directamente a través de la consola de Google Cloud. Esta función te permite migrar a la nube sin el costo o la complejidad de refactorizar las aplicaciones, y te permite ejecutar y administrar cargas de trabajo de manera coherente con tu entorno local. Cuando ejecutas tus cargas de trabajo de VMware en Google Cloud, reduces tu carga operativa mientras te beneficias de la escala y la agilidad, y mantienes la continuidad con tus herramientas, políticas y procesos existentes.
VMware Engine se basa en la infraestructura escalable y de alto rendimiento de Google Cloud, con herramientas de redes de 100 Gbps totalmente redundantes y dedicadas, lo que proporciona una disponibilidad de hasta el 99.99% para satisfacer las necesidades de tu pila de VMware. Los servicios de herramientas de redes de Cloud, como Cloud Interconnect y Cloud VPN, te proporcionan acceso desde tus entornos locales a la nube. El alto ancho de banda de estas conexiones a los servicios en la nube está optimizado para el rendimiento y la flexibilidad, a la vez que se minimizan los costos y la sobrecarga operativa. La asistencia integral de extremo a extremo proporciona una experiencia integrada y continua en este servicio y en el resto de Google Cloud.
Después de mover las cargas de trabajo, tienes acceso inmediato a los servicios de Google Cloud, como BigQuery, Cloud Operations, Cloud Storage, Anthos y Cloud AI. En Google Cloud, también se ofrece una facturación completamente integrada y administración de identidades y control de acceso para unificar tu experiencia con otros productos y servicios de Google Cloud.
Casos de uso
En el siguiente diagrama, se muestra una arquitectura de referencia que representa cómo puedes migrar o extender tu entorno de VMware a Google Cloud, a la vez que aprovechas los servicios de Google Cloud. VMware Engine ofrece soluciones para los siguientes casos de uso.
Requisitos para la integración
Antes de comenzar la implementación de VMware Engine en Google Cloud, asegúrate de leer los requisitos para la integración.
Componentes del sistema
A grandes rasgos, los componentes de VMware Engine son los siguientes:
- Google Cloud:
- VMware Engine:
- NSX-T
- HCX
- vCenter
- vSAN
- Tu organización de Google Cloud:
- Tu proyecto de Google Cloud que tiene una red de VPC
- Cloud Interconnect mediante la interconexión de socio, la interconexión dedicada o la conexión de Cloud VPN a sistemas locales
- Conexión de acceso privado a servicios a la región de VMware Engine
- Conexión de acceso a servicios privados
- Integración de servicios administrados de Google
- VMware Engine:
- (Opcional) Recursos locales:
- Herramientas de redes
- Almacenamiento
- HCX (recomendado para conexiones de capa 2, también conocido como extensión L2)
- vCenter
Una nube privada es una pila de VMware aislada que consta de hosts ESXi, vCenter, vSAN, NSX-T y HCX. En conjunto, estos componentes se conocen como los componentes de Google Cloud VMware Engine y se implementan cuando el administrador de la nube crea una nube privada. Los usuarios de tu organización pueden acceder de forma privada a las nubes privadas de VMware Engine desde sus redes de VPC mediante una conexión de acceso a servicios privados. En el siguiente diagrama, se muestra esta arquitectura.
El acceso privado a los servicios es una conexión privada entre tu red de VPC y una red de Google o terceros. Las entidades que ofrecen servicios, como Google o terceros, también se conocen como productores de servicios.
Para cada una de tus redes de VPC conectadas a VMware Engine, hay una red de VPC de productor de servicios que se crea cuando creas una conexión de acceso a servicios privados en Google Cloud. El proyecto de Google Cloud contiene una red de VPC compartida que se puede usar para conectarse a otros servicios de Google Cloud, como Memorystore y Cloud SQL. Como ejemplo, puedes hacer la migración lift-and-shift de tus VM locales de MySQL o PostgreSQL a VMware Engine y, luego, migrarlas a Cloud SQL mediante Database Migration Service incorporado de Google Cloud, a la vez que permites que las cargas de trabajo de VMware Engine accedan a estas bases de datos.
VMware no requiere que uses NSX-T local. Además, usar HCX no es obligatorio para ninguno de los casos de uso, ya que puedes usar otros mecanismos para lograr la migración de cargas de trabajo y la extensión de la capa 2 (L2). Sin embargo, recomendamos HCX para una migración eficiente de la carga de trabajo y por comodidad, ya que esta función se implementa de forma automática cuando creas la nube privada si seleccionas esta opción.
Funciones de herramientas de redes
A continuación, se presenta un resumen de las capacidades de red de VMware Engine:
- Conectividad de varias VPC: VMware Engine te permite conectar la misma nube privada a varias redes de VPC (hasta tres en total o dos si usas el servicio de Internet regional). Estas redes de VPC pueden ser redes de VPC del consumidor o Managed Partner Services (MPS).
- Subredes: Puedes crear subredes de administración y cargas de trabajo en tus nubes privadas.
- Enrutamiento dinámico: Las subredes de VMware Engine administradas por NSX se anuncian automáticamente en el resto de la red de Google y también en las ubicaciones locales, a través del protocolo de Puerta de Enlace Fronteriza (BGP).
- Funciones de enrutamiento global y regional: Puedes controlar si las redes de VPC compartida del productor de servicios que conectan tus nubes privadas pueden enrutarse solo dentro de una región o a nivel global.
- Servicio de IP pública y puerta de enlace de Internet (entrada y salida): VMware Engine tiene su propio servicio de IP pública para la entrada y la salida de puerta de enlace de Internet. Este es un servicio regional.
- Políticas de firewall: VMware Engine te permite crear políticas de firewall de capa 4 y 7 mediante el firewall distribuido de NSX (de este a oeste) y el firewall de puerta de enlace de NSX (de norte a sur). Por ejemplo, puedes aplicar controles detallados para acceder a cargas de trabajo con direcciones IP públicas, como servidores web.
- Encadenamiento de servicios para la seguridad este-oeste: Proporciona la posibilidad de registrar una solución de seguridad de socios (IDS, IPS o NGFW) a fin de configurar servicios de red para inspeccionar el tráfico de este a oeste entre VM.
- Protección de extremos: Las VM respaldadas por VMware Engine se pueden proteger contra el software malicioso y los virus a través de la integración de socios con terceros compatibles. Para obtener más información, consulta la documentación oficial de VMware.
- Acceso privado a otros servicios de Google: VMware Engine se integra en otros servicios de Google Cloud mediante el Acceso privado a Google y el acceso privado a los servicios. Si deseas obtener una lista completa de los servicios compatibles, consulta Opciones de acceso privado a los servicios.
- Funciones de DNS
- DNS para el acceso a dispositivos de administración: La resolución de direcciones global de los dispositivos de administración de VMware Engine (como vCenter y NSX Manager) mediante Cloud DNS te permite acceder a los dispositivos sin intervención del usuario.
- DNS para cargas de trabajo: Para cada nube privada, decides qué configuración de DNS es la mejor para ti. El servicio de DNS NSX-T te permite reenviar consultas de DNS a ciertos servidores DNS, crear tu servidor DNS en VMware Engine o de forma local, o usar Cloud DNS o Compute Engine.
- Servidor DHCP: Se incluye compatibilidad con el servidor DHCP para segmentos NSX-T.
- Retransmisión de DHCP: La retransmisión de DHCP permite que las organizaciones se integren a un sistema de administración de direcciones IP (IPAM) local, por ejemplo.
- VPN de capa 2 y VPN de capa 3 de sitio a sitio: Estos servicios se configuran directamente en NSX mediante la capa 2 VPN y VPN con IPsec, respectivamente.
- Balanceo de cargas: Este servicio usa las capacidades integradas de balanceo de cargas de NSX-T, que incluye compatibilidad con L4 y L7, así como verificaciones de estado.
- Compatibilidad con el enrutamiento de multidifusión de IP parcial: Se admite la multidifusión independiente del protocolo (PIM), como se describe en la documentación de VMware.
- Compatibilidad con IPv6 parcial: Esta característica permite que las organizaciones aprovechen IPv6 para sus aplicaciones respaldadas por VMware Engine, como se describe en laGuía de diseño de NSX-T 3.0.
- Migración de VM de larga distancia (vMotion): Tanto las migraciones en vivo (las aplicaciones continúan ejecutándose) como las migraciones en frío (las aplicaciones están apagadas) son compatibles entre las instalaciones locales y en la nube, o de nube a nube dentro de VMware Engine con optimización de WAN incorporada, encriptación y movilidad respaldada por replicación. Esto es posible debido a VMware HCX, que se incluye en el servicio.
- Operaciones de red avanzadas: Puedes usar instrumentación y herramientas de NSX incorporadas, como la duplicación de puertos, Traceflow, la captura de paquetes y SNMP v1/v2/v3 con sondeos y detecciones, entre otras.
Redes y rangos de direcciones
Google Cloud VMware Engine crea una red para cada región en la que se implementa el servicio de VMware Engine. La red es un único espacio de direcciones de capa 3 con el enrutamiento habilitado de forma predeterminada. Todas las subredes y las nubes privadas que creas en esta región pueden comunicarse entre sí sin la necesidad de una configuración adicional. Puedes crear segmentos de red (subredes) mediante NSX-T para las máquinas virtuales de carga de trabajo. Puedes configurar cualquier rango de direcciones RFC 1918 que no se superponga con las redes locales, la red de administración de la nube privada o cualquier subred de la VPC. También se admiten direcciones IP públicas de uso privado (PUPI).
De forma predeterminada, todas las subredes pueden comunicarse entre sí, lo que reduce la sobrecarga de configuración para el enrutamiento entre las nubes privadas. El tráfico de datos entre nubes privadas de la misma región permanece en la misma red de capa 3 y se transfiere a través de la infraestructura de la red local dentro de la región, por lo que no se necesita la salida para la comunicación entre estas nubes privadas. Con este enfoque, se elimina cualquier penalización de rendimiento de WAN o salida cuando se implementan diferentes cargas de trabajo en diferentes nubes privadas.
En teoría, una nube privada se crea como un entorno aislado de pila de VMware (hosts ESXi, vCenter, vSAN y NSX) administrado por un servidor de vCenter. Los componentes de administración se implementan en la red seleccionada para el rango de CIDR de las subredes de vSphere/vSAN. El rango CIDR de la red se divide en subredes diferentes durante la implementación.
Administra subredes en VMware Engine
VMware Engine usa varios rangos de direcciones IP. Algunos de los rangos de direcciones IP son obligatorios y otros dependen de los servicios que planeas implementar. El espacio de direcciones IP no debe superponerse con subredes locales, subredes de VPC ni subredes de cargas de trabajo planificadas. En las siguientes secciones, se describe el conjunto de rangos de direcciones y los servicios correspondientes que usan esos rangos.
En el siguiente diagrama, se proporciona una descripción general de las subredes de administración para los servicios que se explican en las siguientes secciones:
vSphere/vSAN CIDR
Los siguientes rangos de direcciones IP son necesarios para inicializar y crear una nube privada:
| Nombre | Descripción | Rango de direcciones |
|---|---|---|
| vSphere/vSAN CIDR | Es obligatorio para redes de administración de VMware. Debe especificarse durante la creación de la nube privada. También es necesario para vMotion. | /21, /22, /23, o/24 |
Cuando creas una nube privada, se crean varias subredes de administración de forma automática. Las subredes de administración usan la asignación de CIDR de vSphere/vSAN requerida que se describió antes en este documento. A continuación, se muestra un ejemplo de la arquitectura y la descripción de las diferentes subredes creadas con este rango de CIDR:
- Administración del sistema: VLAN y subred para la red de administración de los hosts ESXi, el servidor DNS y vCenter Server.
- vMotion: VLAN y subred para la red de vMotion de los hosts ESXi
- vSAN: VLAN y subred para la red vSAN de los hosts ESXi
- NsxtEdgeUplink1: VLAN y subred para los enlaces de subida de VLAN a una red externa
- NsxtEdgeUplink2: VLAN y subred para los enlaces de subida de VLAN a una red externa
- NsxtEdgeTransport: VLAN y subred para las zonas de transporte que controlan el alcance de las redes de capa 2 en NSX-T
- NsxtHostTransport: VLAN y subred para la zona de transporte del host
Ejemplo:
El rango de CIDR de las subredes de vSphere/vSAN que se especifica se divide en varias subredes. En la siguiente tabla, se proporciona un ejemplo del desglose para los prefijos admitidos (de /21 a /24) mediante 192.168.0.0 como el rango de CIDR.
| Prefijo o CIDR especificado de las subredes de vSphere o vSAN | 192.168.0.0/21 |
192.168.0.0/22 |
192.168.0.0/23 |
192.168.0.0/24 |
|---|---|---|---|---|
| Administración del sistema | 192.168.0.0/24 |
192.168.0.0/24 |
192.168.0.0/25 |
192.168.0.0/26 |
| vMotion | 192.168.1.0/24 |
192.168.1.0/25 |
192.168.0.128/26 |
192.168.0.64/27 |
| vSAN | 192.168.2.0/24 |
192.168.1.128/25 |
192.168.0.192/26 |
192.168.0.96/27 |
| Transporte del host de NSX-T | 192.168.4.0/23 |
192.168.2.0/24 |
192.168.1.0/25 |
192.168.0.128/26 |
| Transporte de NSX-T Edge | 192.168.7.208/28 |
192.168.3.208/28 |
192.168.1.208/28 |
192.168.0.208/28 |
| Uplink1 de NSX-T Edge | 192.168.7.224/28 |
192.168.3.224/28 |
192.168.1.224/28 |
192.168.0.224/28 |
| Uplink2 de NSX-T Edge | 192.168.7.240/28 |
192.168.3.240/28 |
192.168.1.240/28 |
192.168.0.240/28 |
Según el rango de CIDR que selecciones, la máscara de subred para cada subred cambia. Por ejemplo, si seleccionas un CIDR de vSphere/vSAN de /21, se crean las siguientes subredes: una subred de administración del sistema /24, una subred de vMotion /24, una sinred de vSAN /24, una subred de transporte del host NSX-T /23, una subred de transporte perimetral NSX-T /28, un uplink1 perimetral de NSX-T /28 y un uplink2 perimetral de NSX-T /28.
Rango de implementación de HCX CIDR
Los siguientes rangos de direcciones IP son necesarios para HCX en tu nube privada:
| Nombre | Descripción | Rango de direcciones |
|---|---|---|
| Rango de implementación de HCX CIDR | Es obligatorio para implementar redes de HCX. Es opcional durante la creación en la nube privada. | /27 o superior |
Rango de direcciones asignado
Las siguientes direcciones IP son necesarias para el acceso privado a servicios en VMware Engine:
| Nombre | Descripción | Rango de direcciones |
|---|---|---|
| Rango de direcciones asignado | Es el rango de direcciones que se usará para la conexión privada a servicios en los servicios de Google Cloud, incluido VMware Engine. | /24 o superior |
Servicios de perímetro y subred del cliente
Los siguientes rangos de direcciones IP son necesarios para habilitar los servicios de herramientas de redes perimetrales que proporciona VMware Engine:
| Nombre | Descripción | Rango de direcciones |
|---|---|---|
| Rango de CIDR de servicios de perímetro | Es obligatorio si están habilitados los servicios perimetrales opcionales, como la VPN de punto a sitio, el acceso a Internet y la dirección IP pública. Los rangos se determinan por región. | /26 |
| Subred del cliente | Es obligatoria para VPN de punto a sitio. Las direcciones DHCP se proporcionan a la conexión de VPN de la subred del cliente. | /24 |
Opciones de Acceso privado a Google para servicios
Google Cloud proporciona varias opciones de acceso privado a las cargas de trabajo que se ejecutan en VMware Engine o en las redes de VPC de Google. El acceso privado a los servicios proporciona una conexión privada entre tu red de VPC y el servicio de VMware Engine. Cuando usas el Acceso privado a Google, tus cargas de trabajo de VMware pueden acceder a otras API y servicios de Google Cloud sin salir de la red de Google Cloud.
Acceso privado a servicios
VMware Engine usa el acceso privado a servicios para conectar tu red de VPC a la red de VPC de un productor de servicios en una carpeta de usuario en tu organización de Google mediante direcciones IP privadas.
Para obtener información sobre cómo configurar el acceso privado a los servicios, consulta Configura el acceso privado a los servicios. El acceso privado a los servicios crea una conexión de intercambio de tráfico entre redes de VPC, por lo que es importante importar y exportar rutas.
Google y los terceros (que juntos se conocen como productores de servicios) pueden ofrecer servicios con direcciones IP internas que se alojan en una red de VPC. El acceso privado a servicios te permite acceder a esas direcciones IP internas. La conexión privada habilita el siguiente comportamiento:
Las instancias de VM en tu red de VPC y las VM de VMware se comunican de forma exclusiva mediante direcciones IP internas. Las instancias de VM no necesitan acceso a Internet o direcciones IP externas para alcanzar los servicios que están disponibles a través del acceso privado a los servicios.
La comunicación entre las VM de VMware y los servicios compatibles de Google Cloud admite el acceso privado a los servicios mediante direcciones IP internas.
Si tienes conectividad local mediante Cloud VPN o Cloud Interconnect con tu red de VPC, puedes usar las conexiones locales existentes para conectarte a tu nube privada de VMware Engine.
Si usas una red de VPC compartida en tu propio proyecto, se deben crear el rango de IP asignado y la conexión privada en el proyecto host para permitir que las instancias de VM en proyectos de servicio tengan conectividad con el entorno.
Puedes configurar el acceso privado a los servicios y crear las nubes privadas de VMware Engine por separado. También puedes crear una conexión privada antes o después de crear la nube privada a la que deseas conectar tu red de VPC.
Por lo tanto, cuando configures el acceso privado a los servicios, debes asignar un rango de direcciones IP internas y, luego, crear una conexión privada, como se mencionó en la sección anterior. Este rango asignado es un bloque CIDR reservado que se usa para la conexión de acceso a servicios privados y no se puede usar en tu red de VPC local. Este rango se reserva solo para los productores de servicios y evita que se superpongan tu red de VPC y la de ellos. Cuando creas una conexión privada, debes especificar una asignación. Para obtener información sobre el lado del productor de servicios, consulta Habilita el acceso privado a los servicios.
Para evitar la superposición de direcciones IP, recomendamos asignar todas las subredes de VMware Engine en la conexión privada a servicios. En la siguiente captura de pantalla, se utiliza el bloque CIDR de VMware Engine para la conexión privada a servicios y el bloque CIDR gcve-2 se asigna a fin de evitar las superposiciones de direcciones IP:
Service Networking no verifica la superposición de direcciones en rutas dinámicas recibidas, por lo que debes asociar el acceso privado a servicios con prefijos reservados para los servicios que no son de VMware. Esto evita los problemas causados por la superposición de direcciones IP, ya que reservas rangos de CIDR y no podrás usarlos en tu red de VPC.
Cuando configures el acceso privado a los servicios, asegúrate de que la conexión de intercambio de tráfico de VPC esté configurada de forma correcta para importar y exportar todas las rutas en la conexión privada servicenetworking-googleapis-com. También debes tener en cuenta el ID del proyecto de intercambio de tráfico para que puedas usarlo cuando configures una conexión privada en VMware Engine.
La red de VPC del productor de servicios se conecta de manera automática al servicio de VMware Engine, que contiene tu nube privada (una instalación de vCenter privada y de instalación única de NSX-T).
VMware Engine usa la misma conexión a varios servicios de Google Cloud aprovisionados dentro de la red de VPC del productor de servicios que usan acceso privado a servicios, como Cloud SQL, Memorystore para Redis, Memorystore para Memcached, AI Platform Training y clústeres privados de GKE. Si deseas usar estos servicios, puedes seleccionar el rango de CIDR que usaste para establecer la conexión privada a servicios con VMware Engine.
En el portal de servicio de VMware Engine, cuando el estado de la región está conectado, puedes revisar la conexión privada con su ID del proyecto de usuario para la región correspondiente. Los detalles de conexión privada muestran las rutas aprendidas a través del intercambio de tráfico entre redes de VPC. En las rutas exportadas, se muestran las nubes privadas aprendidas de la región y exportadas a través del intercambio de tráfico entre VPC.
Una nube privada representa una sola instalación de vCenter y una sola instalación de NSX-T con un máximo de 64 nodos. Puedes implementar varias nubes privadas y, si alcanzas el límite de 64 nodos para una nube privada, puedes crear otra nube privada. Esto significa que administras dos nubes privadas, dos instalaciones de vCenter y dos instalaciones de NSX-T.
Según tu caso de uso, puedes implementar una sola nube privada o implementar varias nubes privadas sin alcanzar el límite de 64 nodos. Por ejemplo, puedes implementar una nube privada con cargas de trabajo de base de datos y una nube privada separada para un caso de uso de VDI, o una nube privada para cargas de trabajo de América y una nube privada diferente para cargas de trabajo de EMEA. Como alternativa, puedes separar las cargas de trabajo en varios clústeres dentro de la misma nube privada, según tu caso de uso.
Acceso privado a Google
El Acceso privado a Google te permite conectarte a las API y los servicios de Google sin asignar direcciones IP externas a las VM de VMware Engine. Después de configurar el Acceso privado a Google, el tráfico se enruta a la puerta de enlace de Internet y, luego, al servicio solicitado sin salir de la red de Google.
Para obtener más información, consulta Acceso privado a Google: información detallada.
Flujos de tráfico clave
En esta sección, se revisan algunos flujos de tráfico clave y se describe la arquitectura que se usa para abarcar todos los flujos de red diferentes.
A continuación, se muestran ejemplos de lo que debes tener en cuenta cuando creas un diseño para VMware Engine.
Conectividad de usuario remota y local de VMware Engine
A continuación, se mencionan opciones que puedes usar para acceder al entorno de VMware Engine desde un centro de datos local o desde una ubicación remota:
- Conectividad de usuario remota:
- Conectividad local:
Las puertas de enlace de VPN proporcionan conectividad segura entre varios sitios, como entornos locales, redes de VPC y nubes privadas. Estas conexiones de VPN encriptadas recorren Internet y finalizan en una puerta de enlace de VPN. Cuando creas varias conexiones a la misma puerta de enlace de VPN, todos los túneles VPN comparten el ancho de banda de la puerta de enlace disponible.
Las puertas de enlace de VPN de punto a sitio permiten a los usuarios conectarse de forma remota a VMware Engine desde sus computadoras. Ten en cuenta que solo puedes crear una puerta de enlace de VPN de punto a sitio por región.
La puerta de enlace de VPN de punto a sitio permite conexiones TCP y UDP, y puedes elegir el protocolo que se usará cuando te conectes desde tu computadora. Además, la subred del cliente configurada se usa para los clientes TCP y UDP, y el rango que define el bloque CIDR se divide en dos subredes: una para los clientes TCP y otra para los clientes UDP.
Una VPN de punto a sitio envía tráfico encriptado entre una red de región de VMware Engine y una computadora del cliente. Puedes usar la VPN de punto a sitio para acceder a tu red de nube privada, incluidas las VM de carga de trabajo y el vCenter de nube privada. Para obtener información sobre la configuración de la puerta de enlace de VPN de punto a sitio, consulta Configura puertas de enlace de VPN en la red de VMware Engine.
También puedes usar Cloud VPN para la conectividad de VPN de sitio a sitio o Cloud Interconnect a fin de establecer conexiones entre tu red local y tu nube privada de VMware Engine. Debes aprovisionar Cloud VPN y Cloud Interconnect en la red de VPC. Para obtener más información, consulta la documentación de Cloud VPN y Cloud Interconnect.
Las opciones para la conectividad de VPN son VPN de IPsec de NSX-T, VPN de capa 2 de NSX-T y VPN de capa 2 de HCX, por ejemplo, para configurar una extensión de capa 2. Un caso de uso para la VPN de IPsec de NSX-T es la encriptación de extremo a extremo con finalización de VPN directamente dentro de la nube privada de VMware Engine. Para obtener más información sobre las capacidades de VPN de NSX-T, consulta la documentación de la red privada virtual de VMware.
Te recomendamos que configures el acceso privado a los servicios en la red de VPC en la que se encuentra Cloud Router o Cloud VPN (y dónde existen los adjuntos de VLAN en caso de que se use el Protocolo de puerta de enlace fronteriza). De lo contrario, deben configurarse las rutas de VPC. Si la arquitectura contiene varias conexiones de intercambio de tráfico de VPC, recuerda que el intercambio de tráfico entre VPC no es transitivo.
Las rutas locales anunciadas en Interconnect o VPN se propagan de forma automática a través del acceso privado a los servicios si se configuran rutas de importación y exportación. Esto requiere que edites de forma manual las rutas de importación y exportación en la conexión de intercambio de tráfico de VPC.
También ten en cuenta que las rutas aprendidas a través del acceso privado a servicios no se propagan automáticamente a los sistemas locales, ya que el intercambio de tráfico entre redes de VPC no admite el enrutamiento de transición. Cloud Routers no anuncia de forma automática las rutas importadas de otras redes en tu red de VPC. Sin embargo, puedes usar anuncios de rangos de IP personalizados de Cloud Routers en tu red de VPC para compartir rutas a destinos en la red de intercambio de tráfico. En el caso de los túneles de Cloud VPN que usan enrutamiento estático, debes configurar rutas estáticas para los rangos de destino de la red de intercambio de tráfico en tu red local.
Entrada a VMware Engine
En esta sección, se describen las siguientes opciones para la entrada a VMware Engine:
- Entrada mediante el servicio de IP pública de VMware Engine
- Entrada de tu red de VPC
- Entrada desde un centro de datos local
La opción que selecciones dependerá del lugar en el que desees intercambiar tráfico de la infraestructura de Google Cloud con Internet. En el siguiente diagrama, se muestran estas opciones de entrada.
En las siguientes secciones, se abarca cada opción en detalle.
Entrada mediante VMware Engine
Cuando usas la puerta de enlace de Internet de VMware Engine, se pueden crear y borrar direcciones IP públicas según demanda para los recursos dentro de la nube privada del portal de VMware Engine. En esta situación, cada dirección IP pública corresponde a una dirección IP de nube privada configurada de manera única.
La entrada pública se puede proporcionar a través de la puerta de enlace de IP pública, que también es responsable de NAT, por lo que los usuarios que provienen de la Internet pública se conectan a la dirección IP pública de Google. La dirección IP pública de Google se traduce a una dirección IP privada de la máquina virtual en VMware Engine (respaldada por segmentos de NSX-T).
Cuando creas reglas de firewall para permitir conexiones entrantes desde fuera a una IP pública expuesta, las reglas de firewall se aplican a una puerta de enlace de IP pública y esas reglas de firewall deben aprovisionarse en el portal de VMware Engine.
Por lo general, un router lógico-tier-0 se usa para el enrutamiento de norte a sur, como una máquina virtual que se conecta a Internet. Se usa un router lógico tier-1 para el enrutamiento este-oeste y puedes configurar varias subredes para el nivel 1.
Una dirección IP pública permite que los recursos de Internet se comuniquen con los recursos de nube privada en una dirección IP privada. La dirección IP privada es una máquina virtual o un balanceador de cargas de software en tu vCenter de nube privada. La dirección IP pública te permite exponer los servicios que se ejecutan en tu nube privada a Internet.
Un recurso asociado con una dirección IP pública siempre usa la dirección IP pública para el acceso a Internet. De forma predeterminada, solo se permite el acceso saliente a Internet en una dirección IP pública y se rechaza el tráfico entrante en la dirección IP pública. A fin de permitir el tráfico entrante, crea una regla de firewall para la dirección IP pública con el puerto específico.
Los usuarios de tu organización pueden exponer y asignar IP públicas a nodos específicos de su nube privada, como las cargas de trabajo de VM. La dirección IP pública se puede asignar a una sola dirección IP privada. La dirección IP pública está dedicada a esa dirección IP privada hasta que anules la asignación. Recomendamos que no expongas los hosts ESXi o vCenter.
Si deseas asignar una IP pública, debes proporcionar un nombre, una ubicación o una región, así como la dirección local adjunta.
Entrada mediante tu red de VPC
Puedes proporcionar entrada a VMware Engine a través de tu red de VPC mediante Cloud Load Balancing. Cuando seleccionas el balanceador de cargas que elijas según las capacidades que necesites, puedes crear un grupo de instancias administrado (MIG) o un grupo de instancias no administrado como el backend de ese balanceador de cargas a fin de usar el tráfico de proxy en la conexión de intercambio de tráfico de VPC. En esta situación, también podrías usar un dispositivo de red virtual de terceros de Google Cloud Marketplace.
Puedes combinar Cloud Load Balancing conusar tu propia IP (BYOIP) en caso de que desees usar tu propio espacio de IP pública en Google, así como conGoogle Cloud Armor para proteger tus aplicaciones y sitios web contra ataques de denegación del servicio distribuido (DSD) y ataques web, como inyecciones de SQL o secuencias de comandos entre sitios.
Entrada mediante tu red local
Para proporcionar entrada local, recomendamos usar Cloud Interconnect. Para una prueba de concepto o en caso de que tengas una capacidad de procesamiento baja y no haya requisitos de latencia, puedes usar Cloud VPN en su lugar.
Salida de VMware Engine
Existen varias opciones para la salida de VMware Engine:
- Salida a través de la puerta de enlace de Internet de VMware Engine
- Salida a través de tu red de VPC
- Salida a través de un centro de datos local
En la siguiente arquitectura, puedes ver estas opciones para un flujo de salida desde una perspectiva de VMware Engine.
Salida pública mediante VMware Engine
Puedes configurar el acceso a Internet y los servicios de IP pública para tus cargas de trabajo por separado para cada región. Puedes dirigir el tráfico vinculado a Internet desde tus cargas de trabajo de VMware mediante una conexión a Internet perimetral de Google Cloud o una conexión local.
El tráfico de una máquina virtual alojado en una nube privada de VMware Engine destinado a la Internet pública sale a través de la puerta de enlace de nivel 0. La puerta de enlace de nivel 0 reenvía el tráfico a la puerta de enlace de Internet. La puerta de enlace de Internet realiza la traducción de direcciones de puerto de origen (PAT). El servicio de Internet es regional, lo que significa que está habilitado para cada región por separado.
Salida pública con tu red de VPC
Como alternativa, en el portal de servicios de VMware Engine, puedes inhabilitar los servicios de IP pública y de Internet, y proporcionar salidas públicas desde la red de VPC. En este caso, el acceso a Internet se realiza a través de la red de VPC si anunciaste una ruta predeterminada 0.0.0.0/0.
Si deseas usar este flujo de paquetes, inhabilita el acceso a Internet para la región de VMware Engine y, luego, inserta una ruta 0.0.0.0/0 predeterminada.
También debes quitar las direcciones IP públicas asignadas y las puertas de enlace de VPN de punto a sitio antes de que el tráfico pueda salir a través de la red de VPC.
La ruta predeterminada debe ser visible en tu red de VPC y, luego, se propagará automáticamente a VMware Engine. Un requisito es habilitar los Controles del servicio de VPC en la conexión de intercambio de tráfico de VPC entre tu red de VPC y VMware Engine.
Para realizar una traducción de direcciones de red (NAT), puedes implementar una instancia de Compute Engine o tener una ruta predeterminada 0.0.0.0/0 que apunte a un balanceador de cargas interno vinculado con un clúster de dispositivo de red virtual centralizado de terceros (disponible en Cloud Marketplace) y realiza NAT de origen en la instancia para salir de tu red de VPC a la Internet pública. Para obtener más información, consulta cómo usar rutas en tu red de VPC.
Salida pública con un centro de datos local
Puedes salir a través de tu centro de datos local si inhabilitas los servicios de IP pública y de Internet y proporcionas la salida pública desde el entorno local. Cuando lo haces, el acceso a Internet fluye a través de tu red de VPC antes de que llegue al centro de datos local a través de Cloud VPN o Cloud Interconnect.
Para implementar la salida pública a través de tu centro de datos local, debes anunciar una ruta 0.0.0.0/0 predeterminada y, luego, habilitar los Controles del servicio de VPC en la conexión de intercambio de tráfico, de modo que la ruta predeterminada se importe de forma correcta, como se describe aquí.
Para obtener más información sobre los Controles del servicio de VPC, consulta la documentación de los Controles del servicio de VPC.
Si los Controles del servicio de VPC están inhabilitados en la conexión de intercambio de tráfico de VPC, el acceso a Internet a través de una conexión local también está inhabilitado, incluso si una ruta predeterminada (0.0.0.0/0) se anuncia y se propaga en la conexión de intercambio de tráfico de VPC.
Descripción general del servicio: De la nube privada a la nube privada
Las nubes privadas se administran a través del portal del servicio de VMware Engine. Las nubes privadas tienen su propio servidor de vCenter que se encuentra en su propio dominio de administración. La pila de VMware se ejecuta en nodos de hardware físicos aislados y dedicados en ubicaciones de Google Cloud. El entorno de nube privada está diseñado para eliminar puntos únicos de fallo:
En el siguiente diagrama, se muestran dos rutas de red para la comunicación entre nubes privadas en VMware Engine. La ruta depende de si las nubes privadas están en la misma región o en regiones diferentes:
- La comunicación entre dos nubes privadas en la misma región dentro del servicio de VMware Engine es a través de la conectividad directa. Puedes implementar varias nubes privadas en la misma región para que la comunicación entre esas nubes privadas se realice de forma local.
- Si las nubes privadas están en regiones diferentes, la conectividad pasa por la red de VPC del productor de servicios. Google es propietario de esta red y también la administra. Este es el caso siempre que el modo de enrutamiento esté configurado como global.
Descripción general del servicio: nube privada a VPC
En esta sección, se revisa la conectividad entre tu red de VPC y la nube privada. En la red de VPC, se usa el modelo de acceso a servicios privados para intercambiar tráfico con la red de VPC del productor de servicios y, luego, se extiende la conectividad a la región de VMware Engine. El enrutamiento global está habilitado en la red de VPC del productor de servicios, y el router de nivel 0 anuncia en NSX-T automáticamente cualquier red que crees en el portal de servicio de VMware Engine. Asegúrate de que la conexión de intercambio de tráfico tenga habilitada la marca de importación y exportación para intercambiar rutas y tener conectividad entre VMware Engine y tu VPC.
En el siguiente diagrama, se muestra el flujo de tráfico de este caso.
Descripción general del servicio: De la nube privada a la VPC compartida
Cuando usas una red de VPC compartida, la conectividad es similar al ejemplo anterior de conexión de una nube privada a una red de VPC. La diferencia es que cuando conectas una nube privada a la red de VPC compartida, las cargas de trabajo residen en el proyecto de servicio y usan el espacio de direcciones IP en la red de VPC compartida del proyecto host. Debido a esto, debes configurar el acceso privado a los servicios en el proyecto host en el que están configurados la red de VPC compartida y la interconexión o VPN.
Por ejemplo, si deseas tener la nube privada, IAM y la facturación en un proyecto de servicio, asegúrate de que la conexión de acceso privado a servicios esté establecida en la red de VPC compartida del proyecto host.
Descripción general del servicio: De la nube privada a las instalaciones locales
En el caso de la nube privada al entorno local, tienes una red de VPC en tu proyecto y organización, y la conectividad es entre la nube privada y el centro de datos local.
Como se mencionó antes, cuando configuras VMware Engine, debes asignar una subred (y, de manera ideal, también las subredes de VMware Engine para evitar conflictos futuros) para la conexión de acceso a servicios privados. Cuando se asigna esa subred, creas una red de VPC de productor de servicios que las conecta a la región de VMware Engine en la que existe la nube privada.
Después de crear y aprovisionar la conexión de intercambio de tráfico de VPC, la red de VPC del productor de servicios se conecta a tu red de VPC. Esto permite que todas las subredes y direcciones IP dentro de tu red de VPC sean accesibles desde la nube privada. Asegúrate de habilitar la importación y exportación de rutas en la conexión de intercambio de tráfico de VPC cuando configures el acceso privado a los servicios.
En el siguiente diagrama, se muestra la conectividad de extremo a extremo entre una nube privada en VMware Engine y un centro de datos local.
Acceso privado a Google: Obtén más información
Como se mencionó antes, puedes usar el Acceso privado a Google para conectarte a los servicios y las API de Google sin tener que proporcionar las direcciones IP externas a los recursos de Google Cloud, de modo que el servicio de VMware Engine pueda aprovechar esto y usar la puerta de enlace de Internet para obtener acceso a las API de Google.
Las instancias de VM que solo tienen direcciones IP internas pueden aprovechar el Acceso privado a Google para acceder a las direcciones IP externas de los servicios y las API de Google. Cuando se configura el Acceso privado a Google, el tráfico se enruta a la puerta de enlace de Internet y, luego, al servicio solicitado.
Si quieres habilitar el acceso privado a Google para VMware Engine, configura el servidor DNS en el entorno de VMware Engine para que use la dirección IP virtual privada. Si deseas obtener más información, consulta Acceso privado a Google para hosts locales y Configura el Acceso privado a Google para hosts locales.
El dominio private.googleapis.com usa 199.36.153.8/30.
Para administrar la resolución de DNS, puedes usar el servicio de DNS proporcionado en NSX-T para reenviar solicitudes a un servidor DNS especificado. El servidor DNS puede ser una VM en VMware Engine, Cloud DNS o un servidor DNS local. Según la forma en que accedas a Internet como se describe en la sección anterior, se usará una de esas opciones.
El Acceso privado a Google es compatible con la mayoría de los servicios y las API de Google, como Cloud Storage, Cloud Spanner y BigQuery. El Acceso privado a Google no es compatible con App Engine, Memorystore ni Filestore. Para obtener más información sobre las opciones de acceso privado, consulta Opciones de acceso privado a los servicios.
A continuación, se muestran ejemplos de cómo puedes usar VMware Engine con los servicios de Google Cloud:
- Acceder a Cloud Storage desde las VM de VMware para exportar datos o como un destino de almacenamiento extendido
- Supervisar todas tus aplicaciones públicas, híbridas y privadas mediante Cloud Monitoring.
- Importar datos de bases de datos a BigQuery para obtener estadísticas
- Implementar Anthos para implementaciones de aplicaciones alojadas en contenedores privadas y de alto rendimiento
En el siguiente diagrama, se muestran dos rutas de red para la comunicación con las API y los servicios de Google. La configuración del Acceso privado a Google depende del acceso a Internet habilitado para VMware Engine:
- Si se proporciona acceso a Internet a través de VMware Engine y se habilita para la región, el Acceso privado a Google y el acceso a Internet usarán la puerta de enlace de Internet.
- Si proporcionas acceso a Internet (mediante la publicidad de una ruta
0.0.0.0/0) desde las instalaciones locales o a través de tu red de VPC, la comunicación usa la puerta de enlace de Internet de la red de VPC del productor de servicios. Se ignora el acceso a través del servicio de Internet de VMware Engine.
Opción 1: Acceso privado a Google con acceso a Internet proporcionado por VMware Engine
Si proporcionas acceso a Internet a través de VMware Engine para una región, Internet y el Acceso privado a Google usan la puerta de enlace de Internet y realizan PAT. En este caso, no necesitas ninguna configuración adicional, excepto la resolución de DNS para el Acceso privado a Google.
Opción 2: Acceso privado a Google con acceso a Internet proporcionado por la VPC local o del cliente
Si proporcionas acceso a Internet de forma local o a través de tu red de VPC, debes configurar el servicio de VMware Engine para enrutar paquetes a las API de Google a través de la puerta de enlace de Internet en la red de VPC del usuario de la organización. Debes configurar el servicio de VMware Engine para enrutar paquetes de otro tráfico a través de tu red de VPC a fin de llegar al entorno local a través de VPN o interconexión, o a través de tu red de VPC.
Para todo el tráfico, inhabilita el acceso a Internet y los servicios de IP pública en la región de VMware Engine e inserta una ruta 0.0.0.0/0 predeterminada a través de las instalaciones locales.
Si proporcionas acceso local a Internet o a través de la red de VPC, quita cualquier dirección IP pública asignada y las puertas de enlace de VPN de punto a sitio antes de inhabilitar el servicio de IP pública. Asegúrate de que la ruta sea visible en tu red de VPC y que la ruta se exporte a la red de VPC de usuario.
Además, debes habilitar los Controles del servicio de VPC en la conexión de intercambio de tráfico de VPC entre tu red de VPC y VMware Engine.
Por último, el acceso a las API de Google usa la dirección IP virtual restringida, por lo que el DNS debe configurarse en consecuencia con los registros A y CNAME necesarios. El acceso a las API de Google se realiza a través de la organización de Google, no a través de tu red de VPC.
Nube privada a Managed Partner Services
Managed Partner Services (MPS) te permite proporcionar ofertas de software como servicio (SaaS) de servicio crítico a los clientes de Google Cloud desde el hardware y el software que alojas en una instalación de colocación de MPS.
Para el flujo de tráfico entre una nube privada y MPS, VMware Engine usa la conectividad de varias VPC. Esta función te permite establecer una conectividad no solo a las redes de VPC del consumidor adicionales, sino también al MPS de Google. El siguiente diagrama es una versión simplificada de la conectividad entre una nube privada y MPS, así como las redes de VPC del consumidor adicionales.
Recursos adicionales: VMware
Para obtener más información sobre la pila de VMware, consulta las versiones de componentes de VMware y la guía de diseño de NSX 3.0.