Acerca de la migración a Google Cloud con Hybrid Subnets

Las subredes híbridas te ayudan a migrar cargas de trabajo de otra red (la red de origen) a una subred de nube privada virtual (VPC) sin tener que cambiar ninguna dirección IP. Al combinar una subred de la red de origen con una subred de VPC, se crea una única subred lógica que te permite migrar cargas de trabajo e instancias de máquina virtual (VM) individuales a lo largo del tiempo. Una vez que se hayan migrado todas las cargas de trabajo y las VMs, puedes retirar la subred de origen.

Las subredes híbridas también permiten migrar máquinas virtuales desde Google Cloud a una red on-premise o entre dos redes de VPC.

En un diagrama de tres fases se muestra cómo migrar cargas de trabajo de un entorno local a Google Cloud mediante subredes híbridas.
Imagen 1. Durante la migración, una subred híbrida proporciona conectividad entre las cargas de trabajo de una red de origen y una red de VPC (haz clic para ampliar).

Especificaciones

Hybrid Subnets tiene las siguientes especificaciones.

  • Propiedades:
    • Una subred híbrida es una única subred lógica que combina un segmento de una red de origen con una subred de una red de VPC.
    • La conectividad interna se mantiene entre todas las máquinas virtuales y cargas de trabajo de una subred híbrida.
    • La red de origen puede ser una red local u otra red de VPC. El segmento puede ser una subred completa o parte de una.
    • Las dos partes de una subred híbrida deben estar conectadas mediante un producto de conectividad de red, como Cloud VPN o Cloud Interconnect.
    • El intervalo de direcciones IPv4 principal de la subred de la VPC debe coincidir con el intervalo del segmento de la red de origen que utiliza la subred híbrida.
  • Configuración de la red de VPC:
    • Debes habilitar el enrutamiento de subredes híbridas para configurar una subred de VPC como parte de una subred híbrida. Cuando el enrutamiento de subredes híbridas está habilitado, las rutas personalizadas pueden entrar en conflicto (superponerse) con los intervalos de direcciones IPv4 principales y secundarios de las subredes.
    • Utilizas las 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. Para admitir el proxy ARP y la coincidencia con el prefijo más largo, estas rutas deben ser más específicas (tener una máscara de subred más larga) que el intervalo de direcciones IP de la subred híbrida. Puedes usar /32 rutas para VMs individuales.
  • Configuración de red de origen:
    • Debe configurar proxy ARP en la red de origen.
    • Debes configurar la red de origen para que anuncie el intervalo de direcciones IP de la subred híbrida.
Un Cloud Router y un router local gestionan el enrutamiento entre las dos partes de una subred híbrida que usa un intervalo de direcciones IP compartido y superpuesto.
Imagen 2. En este diagrama se resumen los pasos para crear una subred híbrida y se muestra cómo un router de Cloud Router y un router on-premise enrutan paquetes entre las dos partes de una subred híbrida (haz clic para ampliar).

Enrutamiento de subredes híbridas

Una subred híbrida combina una subred de una red de origen con una subred de VPC para crear una única subred lógica. Las cargas de trabajo de ambas partes de la subred híbrida mantienen la conectividad interna. Una carga de trabajo puede enviar tráfico a un destino de cualquiera de las partes de la subred híbrida como si fuera local, independientemente de la ubicación del destino.

Enrutamiento de redes VPC

Durante el paso de coincidencia de rutas de subred del modelo de enrutamiento de VPC, si el destino de un paquete coincide con una ruta de subred local o de emparejamiento, Google Cloud intenta entregar el paquete mediante la ruta de subred coincidente. En una subred normal, si el destino no está asociado a una VM en ejecución o a una regla de reenvío interna, el paquete se descarta y se ignoran todas las demás rutas.

Sin embargo, si el enrutamiento de subred híbrida está habilitado en la subred, la ruta de la subred se convierte en una ruta de subred híbrida y el comportamiento de enrutamiento es diferente:

  • Si el paquete está asociado a una instancia de máquina virtual en ejecución o a una regla de reenvío interna en la subred de la VPC, Google Cloud entrega el paquete en función de la ruta de subred híbrida local.
  • Si el paquete no está asociado a una VM en ejecución o a una regla de reenvío interna en la subred de la VPC, Google Cloud se usa un proceso de enrutamiento especial para los recursos no coincidentes. Este proceso incluye la comprobación de rutas dinámicas y estáticas personalizadas que se solapan con el intervalo de la subred híbrida. En una subred híbrida configurada correctamente, los paquetes se enrutan a la red de origen mediante una ruta dinámica local que Cloud Router aprende para la subred de origen.
En una subred híbrida, el paquete A se enruta localmente y el paquete B se enruta a un destino local.
Imagen 3. Las VMs de una subred híbrida pueden acceder a destinos de una subred local y de una subred de red de VPC, aunque ambas subredes compartan el mismo intervalo de direcciones IP superpuestas (haz clic para ampliar).

Por ejemplo, en la figura 3, el paquete A se enruta a una VM de la parte de VPC de una subred híbrida mediante una ruta de subred híbrida local. El destino del paquete B no está asociado a ninguna VM en ejecución ni a ninguna regla de reenvío interna en la parte de la VPC de la subred híbrida, por lo que Google Cloud comprueba si hay rutas personalizadas en conflicto. Se encuentra una coincidencia y Google Cloud usa la ruta dinámica personalizada superpuesta para enviar el paquete B a la red de origen.

Enrutamiento de red de origen

Cuando una carga de trabajo de la red de origen envía un paquete a un destino en el intervalo de direcciones IP de la subred híbrida, el router o el dispositivo de primer salto de la red de origen realiza una búsqueda en la tabla de enrutamiento.

Si el destino está asociado a una carga de trabajo en la red de origen, el router no interviene en el ARP proxy. El destino recibe la solicitud ARP y responde con su propia dirección MAC. El paquete se entrega localmente.

Si el destino está en la parte de VPC de la subred híbrida y el router ha aprendido una ruta dinámica para el destino que es más específica que la ruta de la subred local, el router selecciona la ruta dinámica mediante la coincidencia de prefijo más largo. Esto activa la función de proxy ARP del router. El router responde con su propia dirección MAC y enruta el paquete al router de Cloud de la red de VPC.

Un router local usa el proxy ARP para enrutar un paquete de una carga de trabajo de una red de origen a una máquina virtual que se ha migrado a Google Cloud.
Imagen 4. Un router on-premise usa ARP proxy para enrutar un paquete de una carga de trabajo de una red de origen a una VM que se ha migrado a Google Cloud (haz clic para ampliar).

Limitaciones

Hybrid Subnets tiene las siguientes limitaciones.

  • Limitaciones de recursos:

    Estas limitaciones de recursos no se aplican mediante Google Cloud límites ni cuotas. Si se superan, pueden producirse problemas de conectividad y estabilidad.

  • Tráfico y rutas no admitidos:

    • Los paquetes se descartan si el siguiente salto de una ruta conflictiva se encuentra en una región diferente a la subred híbrida.
    • Los siguientes tipos de rutas no se admiten como rutas conflictivas:
      • Rutas predeterminadas generadas por el sistema
      • Rutas basadas en políticas
      • Rutas estáticas que tienen etiquetas de red
      • Rutas con destinos que contienen o son más amplios que la ruta de subred híbrida
    • Network Connectivity Center no es totalmente compatible con las subredes híbridas. Puede configurar una red de VPC que contenga una subred híbrida para que sea un radio de un hub de Network Connectivity Center. Sin embargo, el tráfico de los radios conectados al intervalo de direcciones IP de la subred híbrida tiene un comportamiento de enrutamiento impredecible.
    • NAT híbrido no es compatible con subredes híbridas. Aunque puedes configurar una subred híbrida para que use NAT híbrido, la función no se aplica al tráfico afectado por el enrutamiento de subredes híbridas.
    • El enrutamiento de subredes híbridas no se aplica al tráfico IPv6.
    • No se admite el tráfico de difusión y multidifusión en una subred híbrida.
    • No puedes usar conexiones de Interconnect de partner de capa 3 que no admitan el anuncio de rutas /32 con subredes híbridas.
    • El router de Cloud Router de una subred híbrida no puede superar el número máximo de rutas anunciadas personalizadas por sesión BGP.
    • Las cargas de trabajo de la red de origen no pueden acceder a las APIs y los servicios de Google mediante Acceso privado de Google.
    • Las cargas de trabajo de la red de origen no pueden acceder a los puntos finales de Private Service Connect de las APIs de Google.

  • Situaciones de migración no admitidas:

    • Las subredes híbridas no admiten la migración de cargas de trabajo de otros proveedores de servicios en la nube.
    • Las subredes híbridas no admiten la migración de VMs desde un origen de Azure o AWS.
    • Las subredes híbridas no admiten la transferencia de datos de sitio a sitio.
    • Las subredes híbridas no admiten VMware Engine de Google Cloud como destino de migración. Si VMware Engine es tu destino de migración, te recomendamos que migres las máquinas virtuales de VMware con VMware HCX.

  • Otras limitaciones:

    • Subredes híbridas no detecta 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 pasarela predeterminada) se use solo una vez.
    • Las subredes híbridas no pueden alojar cargas de trabajo en las direcciones IP reservadas de las subredes IPv4.
    • Las cargas de trabajo de la red de origen no pueden ser endpoints de grupos de endpoints de red de conectividad híbrida que usen comprobaciones de estado centralizadas.
    • El reenvío entrante de Cloud DNS no responde a las solicitudes de DNS de las cargas de trabajo de la red de origen.

Opciones de migración

Google recomienda usar Migrate to Virtual Machines con subredes híbridas para automatizar el proceso de migración de máquinas virtuales desde un origen de VMware o desde un origen de VMware Engine de Google Cloud.

También puedes usar herramientas de migración de terceros con subredes híbridas, siempre que se cumplan los requisitos de las subredes híbridas que se describen en este documento.

Para obtener información sobre cómo planificar una migración con Migrate to Virtual Machines, consulta el artículo Proceso de migración con Migrate to VMs.

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

Si necesitas ayuda para planificar una migración a Google Cloud con subredes híbridas, envía un caso de asistencia.

Consideraciones para usar subredes híbridas

En las secciones siguientes se describen las consideraciones que se deben tener en cuenta al usar subredes híbridas.

Proxy ARP y subredes híbridas

Las subredes híbridas requieren que se configure proxy ARP en el router o el dispositivo de primer salto de la red de origen (el punto en el que un host envía por primera vez tráfico que tiene un destino fuera de su red local).

El dispositivo de primer salto puede ser un router, un dispositivo virtual, un cortafuegos o una máquina virtual que ejecute una solución de software como choparp.

Te recomendamos que hagas lo siguiente para usar proxy ARP en tu red de origen:

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

Limitación de regionalización

Para que una subred híbrida funcione correctamente, las rutas conflictivas (rutas personalizadas que se solapan con el intervalo de direcciones de la subred híbrida) deben tener todos sus saltos siguientes en la misma región que la subred híbrida.

Si una ruta en conflicto tiene siguientes saltos en otra región:

  • Si la ruta tiene una combinación de siguientes saltos locales y remotos, el tráfico se descartará siempre que ECMP seleccione un siguiente salto en una región remota. Esta pérdida de paquetes se produce aunque el paquete también coincida con una ruta menos específica que tenga saltos siguientes en la misma región.
  • Si la ruta no tiene ningún siguiente salto en la misma región que la subred híbrida, el paquete se descarta.

Asegúrate de que los siguientes recursos se encuentren en la misma región:

  • La subred de VPC que se ha configurado como subred híbrida
  • El Cloud Router que aprende rutas a tu red de origen
  • Los túneles VPN de alta disponibilidad o las vinculaciones de VLAN que proporcionan conectividad híbrida

Por ejemplo, supongamos que hay una subred híbrida con el intervalo de direcciones IP 192.0.2.0/24. La subred de VPC está en la región us-central1. Cloud Router ha aprendido dos rutas conflictivas:

  • Una ruta personalizada con el intervalo de destino 192.0.2.0/25 y un siguiente salto en la región us-central1
  • Una ruta personalizada con el intervalo de destino 192.0.2.0/30 y un siguiente salto en la región us-west1.

Se envía un paquete al destino 192.0.2.2. Esta dirección IP no está asociada a ninguna VM en ejecución ni a ninguna regla de reenvío interna de la subred de VPC, por lo que el modelo de selección de rutas elige la ruta personalizada que tiene el destino más específico, que es 192.0.2.0/30. Esta ruta no tiene un siguiente salto en la región de la subred híbrida, por lo que el paquete se descarta.

Para obtener más información, consulta la sección sobre recursos no coincidentes en subredes híbridas.

Emparejamiento entre redes VPC

Puedes conectar una subred híbrida a una red de VPC emparejada mediante el emparejamiento entre redes de VPC. La red de VPC de la subred híbrida debe configurarse para exportar subredes y rutas personalizadas, y la red de VPC emparejada debe configurarse para importarlas.

Cuando la red de VPC emparejada ha programado las rutas, puede acceder a los destinos que se encuentren dentro del intervalo de direcciones IP de la subred híbrida, independientemente de si existen en la red de origen o en la red de destino. Google Cloud

Las rutas no se programarán para la red emparejada en los siguientes casos:

  • Una ruta de subred local de la red emparejada tiene un intervalo de destino idéntico al de la ruta importada.
  • Se ha superado la cuota de rutas dinámicas por región y por grupo de emparejamiento.
  • Las dos redes de VPC no están emparejadas directamente. El emparejamiento entre redes de VPC no es transitivo.

Si se cumple alguna de esas condiciones, la subred híbrida no funcionará correctamente desde la perspectiva de la red de VPC emparejada.

Rendimiento de la red

Las subredes híbridas usan la capa 3 del modelo OSI para enrutar paquetes entre la red de origen y las partes de la VPC de una subred híbrida. Este enfoque ayuda a las subredes híbridas a evitar problemas de latencia, fluctuaciones y rendimiento que pueden producirse durante las migraciones cuando algunas cargas de trabajo se encuentran en una red de origen, pero otras se han migrado a la nube.

En concreto, evitar el túnel de capa 2 ayuda a prevenir la degradación del rendimiento asociada a la encapsulación y el cifrado de una superposición de capa 2 adicional. Además, el enrutamiento de capa 3 permite que las subredes híbridas eviten un problema habitual con el túnel 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 se conoce como tromboning de red.

El enfoque de las subredes híbridas en el enrutamiento significa que puedes esperar un rendimiento de una subred híbrida similar o igual al de una red que no utilice subredes híbridas.

Cortafuegos y subredes híbridas

Las subredes híbridas evitan los problemas relacionados con el uso de cortafuegos con tráfico encapsulado en superposiciones de capa 2. En el caso del tráfico de capa 2, los cortafuegos solo pueden inspeccionar paquetes en los endpoints de superposición o más allá, a menos que tomes medidas específicas, como el descifrado transparente o las inspecciones profundas del tráfico de superposición.

No es necesario tener en cuenta nada especial para usar los cortafuegos y las reglas de cortafuegos con subredes híbridas. Sin embargo, es posible que tengas que configurar reglas de firewall para asegurarte de que las Google Cloud VMs puedan comunicarse con las cargas de trabajo de la red de origen.

Precios

No se aplican cargos adicionales por usar subredes híbridas. Sin embargo, se te cobra por los recursos y el tráfico de red de la parte de la VPC de una subred híbrida.

Para obtener más información, consulta la página Precios de Virtual Private Cloud.

Siguientes pasos