Acerca de la migración a Google Cloud con Hybrid Subnets
En esta página, se describe cómo puedes usar el enrutamiento de subred híbrida para migrar cargas de trabajo a Google Cloud.
El enrutamiento de subredes híbridas permite que una red de VPC comparta un bloque CIDR con una red local conectada. Si un paquete coincide con una ruta de subred híbrida, pero la dirección IP de destino no está asociada a un recurso en esa subred,Google Cloud puede enrutar el paquete a la red local con rutas dinámicas o estáticas.
Esta configuración te ayuda a migrar cargas de trabajo a Google Cloudde forma incremental sin necesidad de cambiar sus direcciones IP. Durante la migración, las cargas de trabajo que se migraron a tu red de VPC pueden comunicarse con las que permanecen en la red local a través de direcciones IP internas. Después de que se hayan migrado todas las cargas de trabajo, puedes inhabilitar el enrutamiento de subred híbrida para restablecer el comportamiento de enrutamiento normal.
La migración a Google Cloud con subredes híbridas requiere tres componentes distintos que funcionan en conjunto:
- Conectividad: Tus redes locales y de VPC deben estar conectadas por un producto de conectividad de red, como Cloud VPN o Cloud Interconnect. Hybrid Subnets no proporciona esta conectividad por sí sola.
- Enrutamiento de subredes híbridas: Debes habilitar el enrutamiento de subredes híbridas aplicando la marca
allow-cidr-routes-overlapa un recurso de subred. - Herramienta de migración: Necesitas una herramienta de migración, como Migrate to Virtual Machines, para migrar cargas de trabajo a Google Cloud.
Especificaciones
Para configurar subredes híbridas que admitan la migración de cargas de trabajo aGoogle Cloud desde una red local, tu entorno debe cumplir con los siguientes requisitos.
- Requisitos de conectividad:
- Tus redes locales y de VPC deben estar conectadas por un producto de conectividad de red, como Cloud VPN o Cloud Interconnect.
- Los túneles de VPN con alta disponibilidad o los adjuntos de VLAN, los Cloud Routers y las subredes con el enrutamiento de subred híbrido habilitado deben estar en la misma región.
- Configuración de la red de VPC:
- Un rango de direcciones IPv4 de la subred con el enrutamiento de subredes híbridas habilitado debe coincidir con un bloque CIDR en la red local que aloja las cargas de trabajo que deseas migrar. En la mayoría de los casos de uso, el rango de direcciones IPv4 principal de la subred coincide con un bloque CIDR en la red local.
- Debes habilitar el enrutamiento de subredes híbridas. Cuando se habilita el enrutamiento de subred híbrida, no se aplican las reglas para las interacciones entre las rutas de subred y las rutas estáticas ni las reglas para las interacciones entre las rutas de subred y las rutas dinámicas. Las rutas estáticas o dinámicas locales y de intercambio de tráfico pueden existir incluso si sus destinos coinciden o se ajustan al rango de direcciones IPv4 principal de la subred o a cualquiera de sus rangos de direcciones IPv4 secundarios.
- Debes configurar rutas anunciadas personalizadas de Cloud Router para anunciar de forma selectiva las direcciones IP de las VMs a medida que las migras a tu red de VPC. Para admitir el ARP proxy y la coincidencia del prefijo más largo, estas rutas anunciadas personalizadas deben ser más específicas (tener una máscara de subred más larga) que el rango de direcciones IPv4 de la subred que tiene habilitado el enrutamiento de subred. Puedes usar una ruta anunciada personalizada de
/32para cada dirección IP de una VM migrada.
- Configuración de red local:
- Debes configurar el ARP de proxy para el router local.
- Debes configurar el router local para que anuncie el rango de direcciones IP del bloque CIDR compartido.
Enrutamiento de subredes híbridas
Cuando completes la configuración que se describe en las especificaciones de subredes híbridas, las VMs de ambas redes podrán comunicarse con direcciones IP internas.
En las siguientes secciones, se describe el comportamiento del enrutamiento en la red de VPC que contiene una subred con el enrutamiento de subredes híbridas habilitado y en una red local una vez que se establece esta configuración.
Enrutamiento en 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:
- Recursos coincidentes: Si el destino del paquete coincide con la interfaz de red de una instancia de VM en ejecución o con una regla de reenvío interna en la subred, Google Cloud entrega el paquete a la interfaz o a la regla de reenvío. Este comportamiento es el mismo que en una subred normal.
- Recursos no coincidentes: Si el destino del paquete no coincide con un recurso de la subred, Google Cloud sigue el proceso de recursos no coincidentes en subredes híbridas. Este proceso enruta los paquetes a los próximos saltos de las rutas estáticas o dinámicas locales o de intercambio de tráfico, siempre y cuando tengan próximos saltos en la misma región que la subred híbrida. Las rutas estáticas o dinámicas locales o de intercambio de tráfico proporcionan una ruta para entregar el paquete a la red local.
Por ejemplo, en la figura 3, el paquete A se enruta a una VM en la subred local 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 o una regla de reenvío interna en la subred que usa el enrutamiento de subred híbrida, por lo que Google Cloud verifica si hay rutas dinámicas o estáticas que se ajusten al rango de destino de la ruta de subred híbrida. Se encuentra una coincidencia y Google Cloud usa la ruta dinámica para entregar el paquete B a la red local.
Enrutamiento en la red local
En esta sección, se describe el comportamiento del enrutamiento en una red local. En este ejemplo, la red local está conectada a una red de VPC a través de túneles de Cloud VPN.
Cuando una VM de cliente en la red local envía un paquete a una VM de servidor que se encuentra dentro del bloque CIDR que comparten las dos redes, el router o el dispositivo de primer salto de la red local realiza una búsqueda en la tabla de enrutamiento:
Si la VM del servidor está asociada a una dirección IP en la red local, el router local no interviene en el ARP proxy. La VM del servidor responde a los paquetes ARP
who-hasde la VM del cliente con respuestas que contienen la dirección MAC del servidor. La VM del cliente envía una trama Ethernet a la VM del servidor.Si la VM del servidor no está asociada a una dirección IP en la red local y el router local recibió un anuncio de ruta personalizada específico de las sesiones de BGP del Cloud Router de los túneles de Cloud VPN en la red de VPC, el router local interviene con ARP proxy. El router local responde los paquetes ARP
who-hasde la VM del cliente con respuestas que contienen la dirección MAC del router. La VM del cliente envía una trama de Ethernet al router local, y este extrae el paquete IP y lo reenvía a uno de los túneles de Cloud VPN. Esto entrega el paquete a la VM en la subred que tiene habilitado el enrutamiento de subred híbrido.
Limitaciones
Las subredes híbridas tienen las siguientes limitaciones.
Administración de direcciones IP y tráfico admitido:
IPv6: Hybrid Subnets no admite tráfico IPv6.
Transmisión y multidifusión: Hybrid Subnets no admite el tráfico de transmisión ni de multidifusión.
Conflictos de direcciones IP: Las subredes híbridas no detectan conflictos de direcciones IP entre los recursos de la red local y la red de VPC que contiene la subred que tiene habilitado el enrutamiento de subred híbrida. Asegúrate de que cada dirección IP, excepto la puerta de enlace predeterminada, se use solo una vez.
Direcciones inutilizables: Los recursos de Google Cloud no pueden usar las dos primeras ni las dos últimas direcciones IPv4 del rango de direcciones IPv4 principal de una subred. Esta regla sigue vigente incluso si habilitas el enrutamiento de subred híbrido. Para obtener más información, consulta Direcciones inutilizables en rangos de subredes IPv4.
Regiones que no coinciden: Los paquetes se descartan si el siguiente salto de una ruta estática o dinámica coincidente dentro del rango de destino de la ruta de subred híbrida coincidente se encuentra en una región diferente de la región de la subred. Para obtener más información, consulta Limitación de regionalidad.
Rutas estáticas con etiquetas de red: Asegúrate de que ninguna ruta estática coincidente dentro del rango de destino de la ruta de subred híbrida coincidente use etiquetas de red. Las rutas estáticas coincidentes que usan etiquetas de red provocan pérdida de paquetes cuando hay tasas de paquetes altas.
Interacciones con productos no admitidas: No uses Hybrid Subnets con lo siguiente.
Network Connectivity Center (NCC): NCC no es compatible con las subredes híbridas. Google Cloudno te impide exportar subredes que tengan habilitado el enrutamiento de subredes híbridas a un concentrador de NCC, pero hacerlo puede generar un comportamiento de enrutamiento impredecible.
NEG de conectividad híbrida: Los sistemas de sondeo de verificación de estado de Google para las verificaciones de estado centralizadas no pueden comunicarse con los extremos de un NEG híbrido si estos se ajustan a una ruta de subred híbrida.
Hybrid NAT: Hybrid NAT no es compatible con Hybrid Subnets. La NAT híbrida no realiza NAT de origen (SNAT) en los paquetes enviados desde las VMs a los destinos en una ruta estática o dinámica si primero se encuentra una coincidencia con una ruta de subred híbrida.
También ten en cuenta las siguientes limitaciones prácticas.
La red local debe admitir el proxy ARP: Hybrid Subnets no admite la migración de cargas de trabajo desde redes remotas en otros proveedores de servicios en la nube, como Azure o AWS, porque esas redes remotas no admiten el proxy ARP.
La red local debe aceptar los anuncios de ruta de
/32: Si usas la interconexión de socio de capa 3, consulta con el socio para ver si admite la recepción de prefijos de/32.
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 usar Hybrid Subnets y migrar cargas de trabajo a Google Cloud.
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 local (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 local:
- Consulta con el proveedor de la estructura de red 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
Esta limitación se aplica cuando el tráfico coincide con una ruta de subred híbrida, pero la dirección IP de destino no está asociada con una VM en ejecución o una regla de reenvío interna. Durante el paso de recursos no coincidentes en subredes híbridas del modelo de selección de rutas de Google Cloud, las rutas se evalúan como si la fuente de un paquete estuviera en la misma red de VPC que la ruta de subred híbrida.
Si una ruta estática o dinámica con un rango de destino que se ajusta a una ruta de subred híbrida tiene próximos saltos en una región diferente, sucede lo siguiente:
- Si la ruta tiene una combinación de próximos saltos, en la que algunos se encuentran en la misma región que la ruta de la subred híbrida y otros en otras regiones, el tráfico se descarta cada vez que ECMP selecciona un próximo salto en una región que no sea la de la subred. Este descarte de paquetes ocurre incluso si el paquete también coincide con una ruta menos específica que tiene próximos saltos en la región de la subred.
- Si la ruta no tiene próximos saltos en la misma región que la subred que usa el enrutamiento de subred híbrida, se descarta el paquete.
Asegúrate de que los siguientes recursos se encuentren en la misma región:
- La subred que tiene habilitado el enrutamiento de subredes híbridas
- El Cloud Router que aprende rutas a tu red local
- Túneles VPN con alta disponibilidad o adjuntos de VLAN que proporcionan conectividad híbrida
Por ejemplo, supongamos que hay una subred con el rango de direcciones IP 192.0.2.0/24 que tiene habilitado el enrutamiento de subredes híbridas. La subred se encuentra en la región us-central1. El Cloud Router aprendió dos rutas con rangos de destino que se ajustan a la ruta de subred híbrida:
- Una ruta dinámica con el rango de destino
192.0.2.0/25y un siguiente salto en la regiónus-central1 - Una ruta dinámica con el rango de destino
192.0.2.0/30y un siguiente salto en la regiónus-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 local, por lo que el modelo de selección de rutas selecciona 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, 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 red de VPC que contiene una subred que usa el enrutamiento de subred híbrida a una red de VPC de intercambio de tráfico mediante el intercambio de tráfico entre redes de VPC.
El tráfico de los clientes en una red de intercambio de tráfico puede llegar a destinos dentro del bloque CIDR compartido, independientemente de si los destinos son recursos deGoogle Cloud o están en la red local. Si un paquete de un cliente en la red con intercambio de tráfico tiene un destino que coincide con una ruta de subred híbrida de intercambio de tráfico, y el destino no coincide con una VM en ejecución o una regla de reenvío interna, el paquete se puede enrutar con una ruta estática o dinámica en la red de VPC con intercambio de tráfico.
El enrutamiento con una ruta estática o dinámica en la red de VPC con intercambio de tráfico no depende del intercambio de rutas personalizadas con la red de VPC que contiene el cliente. Sin embargo, los siguientes elementos siguen siendo relevantes:
Asegúrate de que el uso de la cuota de rutas dinámicas por región por grupo de intercambio de tráfico en la red de VPC que contiene el cliente sea inferior al límite de la cuota.
Asegúrate de que no existan otras rutas en la red de VPC del cliente para los rangos de destino que coincidan con las rutas estáticas o dinámicas en la red con intercambio de tráfico que se ajusten a la ruta de subred híbrida de intercambio de tráfico.
Rendimiento de la red
Hybrid Subnets usa la capa 3 del modelo OSI para enrutar paquetes entre las redes locales y de VPC. 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.
Como Hybrid Subnets usa este enfoque de enrutamiento, puedes esperar un rendimiento 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, debes configurar reglas de firewall para asegurarte de que las VMs de Google Cloud puedan comunicarse con las cargas de trabajo en la red local.
Precios
Para obtener información sobre los precios de las subredes híbridas, 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.