Acerca de Hybrid Subnets

Hybrid Subnets te permite combinar una subred local con una subred de nube privada virtual (VPC) para crear una única subred lógica. Con el tiempo, puedes migrar instancias de máquina virtual (VM) y cargas de trabajo individuales de la subred local a la subred de VPC sin necesidad de cambiar las direcciones IP. Después de que se hayan migrado todas las cargas de trabajo y las VMs, puedes retirar la subred local.

En una subred híbrida, los routers locales y Cloud Routers anuncian rutas mediante el protocolo de puerta de enlace de frontera (BGP) (haz clic para ampliar).

Hybrid Subnets y Migrate to Virtual Machines

Recomendamos usar Migrate to Virtual Machines con Hybrid Subnets para automatizar el proceso de migración de VMs desde una fuente de VMware. Migrate to Virtual Machines es compatible con Google.

Para obtener más información sobre las opciones de migración, consulta Recursos de migración.

Como alternativa, puedes usar herramientas de migración de terceros con Hybrid Subnets, siempre que los requisitos de Hybrid Subnets que se describen en este documento se cumplan.

Para obtener asistencia con la planificación de una migración a Google Cloud mediante Hybrid Subnets, presenta un caso de asistencia.

Para obtener información sobre la planificación de una migración con Migrate to VMs, consulta Recorrido de migración con Migrate to VMs.

Especificaciones

  • Hybrid Subnets requiere un producto de conectividad de red como Cloud VPN o Cloud Interconnect.
  • Un router local usa el proxy ARP para enrutar el tráfico desde las máquinas locales a las VMs de Google Cloud mediante las rutas aprendidas de las rutas anunciadas personalizadas de Cloud Router.
  • El rango de direcciones IPv4 principal de la subred de Google Cloud debe coincidir con el rango de direcciones IP de la subred local.
  • Debes habilitar la marca allow-cidr-routes-overlap de una subred de VPC para configurar la subred como una subred híbrida. Cuando se habilita allow-cidr-routes-overlap, Google Cloud permite que las rutas personalizadas se superpongan con los rangos de direcciones IP de la subred.
  • La marca allow-cidr-routes-overlap se aplica a rangos de subredes IPv4 principales y rangos de subredes IPv4 secundarios, además de rangos de subredes IPv6.
  • La conectividad interna se mantiene entre todas las VMs y las cargas de trabajo de una subred híbrida.
  • Utilizas rutas anunciadas personalizadas de Cloud Router para anunciar de forma selectiva las direcciones IP de las VMs a medida que las migras a la subred de VPC.
  • A medida que migras cargas de trabajo desde una red local a Google Cloud, debes actualizar las rutas anunciadas personalizadas de Cloud Router para incluir las direcciones IP de las VMs migradas.
  • Puedes conectar una subred híbrida a una red de VPC de intercambio de tráfico mediante el intercambio de tráfico entre redes de VPC. La configuración de intercambio de tráfico para la red de VPC que contiene la subred híbrida debe establecerse para exportar rutas personalizadas. La configuración de intercambio de tráfico de la otra red de VPC debe establecerse para importar rutas personalizadas.

Limitaciones

  • La cantidad máxima de VMs en una red de VPC que usa Hybrid Subnets es 130. Superar este límite puede causar problemas de conectividad y estabilidad.
  • El Cloud Router de una subred híbrida no puede exceder la cantidad máxima de rutas anunciadas personalizadas por sesión de BGP.
  • No se admite la transmisión y el tráfico de multidifusión dentro de una subred híbrida.
  • No puedes usar conexiones de interconexión de socio de capa 3 que no admitan el anuncio de rutas /32 con Hybrid Subnets.
  • Hybrid Subnets no es compatible con IPv6.
  • Hybrid Subnets no es compatible con Google Cloud VMware Engine. Recomendamos migrar las VMs de VMware con VMware HCX.
  • Si una carga de trabajo local tiene la misma dirección IP que el Cloud Router, las cargas de trabajo en la parte de VPC de una subred híbrida no pueden enviar paquetes a esa dirección IP. Por ejemplo, si el rango de direcciones IP de la subred híbrida es 192.168.1.0/24, las cargas de trabajo en la subred de VPC no pueden llegar a 192.168.1.1.
  • Hybrid Subnets no puede alojar cargas de trabajo en las direcciones IP reservadas en las subredes IPv4.
  • El reenvío entrante de Cloud DNS no responde a las solicitudes de DNS de cargas de trabajo en la parte local de una subred híbrida.
  • Las cargas de trabajo en la parte local de una subred híbrida no pueden acceder a los servicios y las APIs de Google mediante el Acceso privado a Google.
  • Las cargas de trabajo en la parte local de una subred híbrida no pueden acceder a los extremos de Private Service Connect para las APIs de Google.
  • Hybrid Subnets no admite la transferencia de datos de sitio a sitio.
  • Hybrid Subnets no admite la migración de cargas de trabajo desde otros proveedores de servicios en la nube ni la migración de cargas de trabajo dentro de Google Cloud porque esos entornos no admiten el proxy ARP.
  • Una subred híbrida no puede conectarse a redes de intercambio de tráfico mediante Network Connectivity Center.

Consideraciones para usar Hybrid Subnets

En las siguientes secciones, se describen las consideraciones para el uso de Hybrid Subnets.

Rendimiento de la red

Hybrid Subnets usa la capa 3 del modelo OSI para enrutar paquetes entre las partes locales y de VPC de una subred híbrida. Este enfoque ayuda a Hybrid Subnets a evitar problemas de latencia, Jitter y capacidad de procesamiento que pueden ocurrir durante las migraciones cuando algunas cargas de trabajo existen en una red local, pero otras se migraron a la nube.

En particular, evitar la tunelización de capa 2 ayuda a evitar la degradación del rendimiento asociada con el encapsulamiento y la encriptación de una superposición adicional de la capa 2. Además, el enrutamiento de capa 3 permite que Hybrid Subnets evite un problema común con la tunelización de capa 2, en el que el tráfico se envía a un nodo central antes de llegar a destinos que pueden estar cerca del punto de origen del tráfico. Este problema a veces se denomina tromboning de red.

El enfoque de Hybrid Subnets para el enrutamiento significa que puedes esperar un rendimiento de una subred híbrida similar o igual al de una red que no usa Hybrid Subnets.

Proxy ARP y Hybrid Subnets

El proxy ARP es obligatorio para Hybrid Subnets. Recomendamos lo siguiente para usar el proxy ARP en la parte local de una subred híbrida:

  • Consulta con el proveedor de la estructura de red local para conocer las prácticas recomendadas relacionadas con la habilitación del proxy ARP y la protección del entorno de red.
  • Inhabilita el proxy ARP después de completar la migración a Google Cloud.

Firewalls y Hybrid Subnets

Hybrid Subnets evita los problemas relacionados con el uso de firewalls con tráfico que se encapsula en las superposiciones de capa 2. Para el tráfico de capa 2, los firewalls solo pueden inspeccionar paquetes en los extremos de superposición o más allá, a menos que tomes medidas específicas, como la desencriptación transparente o las inspecciones profundas del tráfico de superposición.

No se necesitan consideraciones especiales para usar firewalls y reglas de firewall existentes con Hybrid Subnets. Sin embargo, es posible que debas configurar reglas de firewall para asegurarte de que las VMs de Google Cloud puedan comunicarse con las cargas de trabajo locales.

Precios

No se aplican cargos adicionales por usar Hybrid Subnets. Sin embargo, se te cobra por los recursos y el tráfico de red en la parte de Google Cloud de una subred híbrida.

Para obtener más información, consulta Precios de la nube privada virtual.

¿Qué sigue?