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

Versión preliminar

Esta función está sujeta a las “Condiciones de la Oferta de la Fase Previa a la DG” en la sección Condiciones del Servicio Generales de las Condiciones Específicas del Servicio. Las funciones de la fase previa a la DG están disponibles sin modificaciones y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

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. Si combinas una subred en la red de origen con una subred de VPC, creas una única 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.

Las subredes híbridas también admiten la migración de VMs desde Google Clouda una red local o entre dos redes de VPC.

Figura 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

Las subredes híbridas tienen las siguientes especificaciones.

• Propiedades:
  • Una subred híbrida es una sola subred lógica que combina un segmento de una red de origen con una subred en una red de VPC.
  • La conectividad interna se mantiene entre todas las VMs y las cargas de trabajo de una subred híbrida.
  • La red de origen puede ser una red local o cualquier 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 por un producto de conectividad de red, como Cloud VPN o Cloud Interconnect.
  • El rango de direcciones IPv4 principal de la subred de VPC debe coincidir con el rango del segmento de la red de origen que usa 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 se habilita el enrutamiento de subredes híbridas, las rutas personalizadas pueden entrar en conflicto (superponerse) con los rangos de direcciones IPv4 principales y secundarios de las subredes.
  • 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. Para admitir el proxy ARP y la coincidencia del prefijo más largo, estas rutas deben ser más específicas (tener una máscara de subred más larga) que el rango de direcciones IP de la subred híbrida. Puedes usar rutas de /32 para VMs individuales.
• Configuración de red de origen:
  • Debes configurar el proxy ARP en la red de origen.
  • Debes configurar la red de origen para que anuncie el rango de direcciones IP de la subred híbrida.

Figura 2. En este diagrama, se proporciona una descripción general de los pasos para crear una subred híbrida y cómo un Cloud Router y un router local 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 en una red de origen con una subred de VPC para crear una sola subred lógica. Las cargas de trabajo en ambas partes de la subred híbrida mantienen la conectividad interna. Una carga de trabajo puede enviar tráfico a un destino en cualquiera de las partes de la subred híbrida como si fuera local, independientemente de la ubicación del destino.

Enrutamiento de la red de 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 intercambio de tráfico, Google Cloud intenta entregar el paquete con la ruta de subred coincidente. En una subred normal, si el destino no está asociado con una VM en ejecución o una regla de reenvío interna, se descarta el paquete y se ignoran todas las demás rutas.

Sin embargo, si el enrutamiento de subredes híbridas está habilitado para la subred, la ruta de 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 VM en ejecución o a una regla de reenvío interno en la subred de VPC, Google Cloud entrega el paquete según 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 VPC, Google Cloud se usa un proceso de enrutamiento especial para los recursos no coincidentes. Este proceso incluye la verificación de rutas dinámicas y estáticas personalizadas que se superponen con el rango de la subred híbrida. En una subred híbrida configurada correctamente, los paquetes se enrutan a la red de origen a través de una ruta dinámica local que el Cloud Router aprende para la subred de origen.

Figura 3. Las VMs en una subred híbrida pueden llegar a destinos en una subred local y en una subred de red de VPC, aunque ambas subredes compartan el mismo rango de direcciones IP superpuestas (haz clic para ampliar).

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

Enrutamiento de la red de origen

Cuando una carga de trabajo en la red de origen envía un paquete a un destino en el rango 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 proxy ARP. El destino recibe la solicitud ARP y responde con su propia dirección MAC, y el paquete se entrega de forma local.

Si el destino se encuentra en la parte de VPC de la subred híbrida y el router aprendió 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 con la coincidencia de prefijo más largo. Esto activa la funcionalidad de proxy ARP del router. El router responde con su propia dirección MAC y enruta el paquete al Cloud Router en la red de VPC.

Figura 4. Un router local usa el proxy ARP para enrutar un paquete desde una carga de trabajo en una red de origen a una VM que migró a Google Cloud(haz clic para ampliar).

Limitaciones

Las subredes híbridas tienen las siguientes limitaciones.

• Limitaciones de recursos:

  • No configures más de 25 subredes híbridas por red de VPC.
  • No superes los 130 Instances per VPC network.
  • No superes los 25 Internal passthrough Network Load Balancer forwarding rules per VPC network.
  • Si una red de VPC con subredes híbridas está conectada a otras redes de VPC a través del intercambio de tráfico entre redes de VPC, no superes los 50 Dynamic routes per region per peering group.
  • No configures más de 300 rutas personalizadas (estáticas y dinámicas) por red de VPC.

  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.

• Tráfico y rutas no admitidos:

  • Los paquetes se descartan si el próximo salto de una ruta en conflicto se encuentra en una región diferente a la de la subred híbrida.
  • Los siguientes tipos de rutas no se admiten como rutas en conflicto:
    • Rutas predeterminadas generadas por el sistema
    • Rutas basadas en políticas
    • Rutas estáticas que tienen etiquetas de red
    • Rutas con destinos que contienen la ruta de subred híbrida o son más amplios que esta
  • Network Connectivity Center no es totalmente compatible con las subredes híbridas. Puedes configurar una red de VPC que contenga una subred híbrida para que sea un radio de un concentrador de Network Connectivity Center. Sin embargo, el tráfico de las subredes híbridas conectadas al rango de direcciones IP de la subred híbrida tiene un comportamiento de enrutamiento impredecible.
  • NAT híbrida no es compatible con las subredes híbridas. Si bien puedes configurar una subred híbrida para que use NAT híbrida, la función no se aplica al tráfico afectado por el enrutamiento de subredes híbridas.
  • El enrutamiento de subred híbrida no se aplica al tráfico IPv6.
  • 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.
  • El Cloud Router de una subred híbrida no puede exceder la cantidad máxima de rutas anunciadas personalizadas por sesión de BGP.
  • 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.

• Situaciones de migración no admitidas:

  • Hybrid Subnets no admite la migración de cargas de trabajo desde otros proveedores de servicios en la nube.
  • Hybrid Subnets no admite la migración de VMs desde una fuente de Azure o AWS.
  • Hybrid Subnets no admite la transferencia de datos de sitio a sitio.
  • 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 VMs de VMware con VMware HCX.

• Otras limitaciones:

  • Hybrid Subnets 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 puerta de enlace predeterminada) se use solo una vez.
  • Hybrid Subnets no puede alojar cargas de trabajo en las direcciones IP reservadas en las subredes IPv4.
  • 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.
  • El reenvío entrante de Cloud DNS no responde a las solicitudes de DNS de cargas de trabajo en 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 VMs desde una fuente de VMware o desde una fuente de 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 información sobre la planificación de una migración con Migrate to Virtual Machines, consulta Proceso de migración con Migrate to VMs.

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

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

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 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 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.

Limitación de regionalidad

Para que una subred híbrida funcione correctamente, las rutas en conflicto (rutas personalizadas que se superponen con el rango de direcciones de la subred híbrida) deben tener todos sus próximos saltos en la misma región que la subred híbrida.

Si una ruta en conflicto tiene siguientes saltos en una región diferente, haz lo siguiente:

• Si la ruta tiene una combinación de próximos saltos locales y remotos, el tráfico se descarta cuando ECMP selecciona un próximo salto en una región remota. Esta pérdida de paquetes se produce incluso si el paquete también coincide con una ruta menos específica que tiene próximos saltos en la misma región.
• Si la ruta no tiene próximos saltos en la misma región que la subred híbrida, se descarta el paquete.

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

• La subred de VPC que se configuró como subred híbrida
• El Cloud Router que aprende rutas a tu red de origen
• Túneles VPN con alta disponibilidad o adjuntos de VLAN que proporcionan conectividad híbrida

Por ejemplo, supongamos que hay una subred híbrida con el rango de direcciones IP 192.0.2.0/24. La subred de VPC se encuentra en la región us-central1. El Cloud Router aprendió dos rutas en conflicto:

• Una ruta personalizada con el rango de destino 192.0.2.0/25 y un próximo salto en la región us-central1
• Una ruta personalizada con el rango de destino 192.0.2.0/30 y un próximo 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 una VM en ejecución ni a una regla de reenvío interna en la subred de VPC, por lo que el modelo de selección de ruta elige la ruta personalizada que tiene el destino más específico, que es 192.0.2.0/30. Esta ruta no tiene un próximo salto en la región de la subred híbrida, por lo que se descarta el paquete.

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

Intercambio de tráfico entre redes de VPC

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 red de VPC de la subred híbrida debe configurarse para exportar rutas de subred y personalizadas, y la red de VPC con intercambio de tráfico debe configurarse para importarlas.

Cuando la red de VPC con intercambio de tráfico programó las rutas, puede llegar a destinos dentro del rango de direcciones IP de la subred híbrida, independientemente de si existen en Google Cloud o en la red de origen.

Las rutas no se programarán para la red de intercambio de tráfico en los siguientes casos:

• Una ruta de subred local en la red con intercambio de tráfico tiene un rango de destino idéntico al de la ruta importada.
• Se superó la cuota de rutas dinámicas por región por grupo de intercambio de tráfico.
• Las dos redes de VPC no tienen intercambio de tráfico directo. El intercambio de tráfico entre redes de VPC no es transitivo.

Si alguna de esas condiciones es verdadera, la subred híbrida no funcionará correctamente desde la perspectiva de la red de VPC interconectada.

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?

• Si deseas preparar una red de VPC para la conectividad de Hybrid Subnets, consulta Prepárate para la conectividad de Hybrid Subnets.