Acerca de Hybrid Subnets

Hybrid Subnets te ayuda a migrar cargas de trabajo de otra red (la red de origen) a una subred de nube privada virtual (VPC) sin necesidad de cambiar las direcciones IP. Este proceso de migración se llama Migrate Motion. Si combinas una subred en la red de origen con una subred de VPC, creas una sola subred lógica que te permite migrar cargas de trabajo individuales e instancias de máquina virtual (VM) con el tiempo. Después de que se hayan migrado todas las cargas de trabajo y las VMs, puedes retirar la subred de origen.

En una subred híbrida, un router en una red de origen y un Cloud Router en una red de VPC anuncian rutas mediante el protocolo de puerta de enlace de frontera (BGP) (haz clic para ampliar).

Opciones de migración

Recomendamos usar Migrate to Virtual Machines con subredes híbridas para automatizar el proceso de migración de VMs desde una fuente de VMware o desde una fuente de Google Cloud VMware Engine.

Hybrid Subnets no admite Google Cloud VMware Engine como destino de migración. Si VMware Engine es tu destino de migración, te recomendamos migrar las VMs de VMware con VMware HCX. No es necesario que configures subredes híbridas cuando usas VMware HCX para migrar a Google Cloud VMware Engine.

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

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

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.

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

Especificaciones

  • Hybrid Subnets requiere un producto de conectividad de red como Cloud VPN o Cloud Interconnect.
  • Se debe configurar el proxy de ARP en la red de origen.
  • La red de origen debe configurarse para anunciar el rango de direcciones IP de la subred híbrida.
  • El rango de direcciones IPv4 principal de la subred de VPC debe coincidir con el rango de direcciones IP de la subred de origen.
  • 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 los rangos de subredes IPv4 principales y secundarios.
  • 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 de una red de origen 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

  • Las redes de VPC que usan subredes híbridas tienen las siguientes limitaciones de recursos:

    Google Cloud no aplica estas limitaciones de recursos con límites o cuotas. Si se superan, es posible que se produzcan 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 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 red de origen.

  • Las cargas de trabajo en la red de origen no pueden acceder a los servicios y las APIs de Google a través del Acceso privado a Google.

  • Las cargas de trabajo en la red de origen no pueden acceder a los extremos de Private Service Connect para las APIs de Google.

  • Las cargas de trabajo en la red de origen no pueden ser extremos para los grupos de extremos de red de conectividad híbrida que usan verificaciones de estado centralizadas.

  • Hybrid Subnets no admite la transferencia de datos de sitio a sitio.

  • No puedes conectar una subred híbrida a otra.

  • Las subredes híbridas no detectan conflictos de direcciones IP entre la red de origen y las partes de VPC de una subred híbrida. Asegúrate de que cada dirección IP (excepto la puerta de enlace predeterminada) se use solo una vez.

  • Hybrid Subnets no admite Google Cloud VMware Engine como destino de migración.

  • Hybrid Subnets no admite la migración de VMs desde una fuente de Azure o AWS.

  • Hybrid Subnets no admite la migración de cargas de trabajo desde otros proveedores de servicios en la nube.

  • Hybrid Subnets no es compatible con Network Connectivity Center.

Consideraciones para usar Hybrid Subnets

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

Proxy ARP y Hybrid Subnets

Hybrid Subnets requiere que se configure el proxy ARP en el dispositivo de primer salto de la red de origen. Un dispositivo de primer salto es el punto en el que un host envía por primera vez tráfico que tiene un destino fuera de su red local. El ARP de proxy permite que el dispositivo responda con su propia dirección MAC cuando recibe solicitudes ARP para VMs que están en la parte de VPC de una subred híbrida. Luego, el dispositivo puede reenviar paquetes a las VMs en la subred de VPC con los bloques CIDR que aprendió de las rutas anunciadas personalizadas de la sesión del Protocolo de puerta de enlace fronteriza (BGP) en Cloud Router.

El dispositivo de primer salto puede ser un router, un dispositivo virtual, un firewall o una VM que ejecute una solución de software como choparp.

Recomendamos lo siguiente para usar el proxy ARP en tu red de origen:

  • Consulta con el proveedor de la estructura de red de origen 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 aGoogle Cloud.

Rendimiento de la red

Hybrid Subnets usa la capa 3 del modelo OSI para enrutar paquetes entre la red de origen y las partes 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 de origen, 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.

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 en la red de origen.

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 la VPC de una subred híbrida.

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

¿Qué sigue?