Descripción general del balanceo de cargas híbrido

Cloud Load Balancing admite tráfico de balanceo de cargas a extremos que se extienden más allá de Google Cloud, como centros de datos locales y otras nubes públicas a las que puedes usar la conectividad híbrida para llegar.

Una estrategia híbrida es una solución pragmática para que te adaptes a las demandas cambiantes del mercado y modernices tus aplicaciones de forma incremental. Esta puede ser una implementación híbrida temporal para permitir la migración a una solución moderna basada en la nube o un elemento permanente de la infraestructura de TI de tu organización.

La configuración del balanceo de cargas híbrido también te permite aprovechar los beneficios de las capacidades de red de Cloud Load Balancing en servicios que se ejecutan en tu infraestructura existente fuera de Google Cloud.

El balanceo de cargas híbrido es compatible con los siguientes balanceadores de cargas de Google Cloud:

• Balanceadores de cargas HTTP(S) externos globales
  • Los balanceadores de cargas HTTP(S) externos regionales no son compatibles con el balanceo de cargas híbrido.
• Balanceo de cargas de HTTP(S) interno
• Balanceo de cargas de proxy TCP
• Balanceo de cargas del proxy SSL

Nota: El balanceador de cargas HTTP(S) externo global (clásico) proporciona una funcionalidad similar mediante los grupos de extremos de red (NEG) de Internet. El tráfico se puede enviar directamente a direcciones IP de acceso público y a nombres de dominio completamente calificados (FQDN) que se pueden resolver de forma pública fuera de Google Cloud. Sin embargo, este tráfico no recorre tu red de nube privada virtual (VPC) y no puede enrutarse a un extremo remoto con una conexión privada. A diferencia de los NEG de conectividad híbrida que se describen aquí, los NEG de Internet tienen un alcance global y no admiten verificaciones de estado para los extremos públicos. Para obtener más información, consulta la descripción general de los grupos de extremos de red de Internet.

Caso de uso: Enruta el tráfico a una ubicación local o a otra nube

El caso práctico más simple para esta función es enrutar el tráfico desde un balanceador de cargas de Google Cloud a Google Cloud, una ubicación local o cualquier otra nube. Los clientes pueden originar tráfico desde la Internet pública, desde Google Cloud o desde un cliente local.

Clientes públicos

Puedes usar el balanceo de cargas HTTP(S) para enrutar el tráfico de clientes externos a un backend en Google Cloud, de manera local o en otra nube. Con el balanceo de cargas HTTP(S), también puedes habilitar funciones de herramientas de redes de valor agregado para tus servicios locales. Puede hacer lo siguiente:

• Usar la infraestructura perimetral global de Google para finalizar las conexiones de los usuarios más cerca de estos, lo que disminuye la latencia.
• Proteger el servicio con Google Cloud Armor, un producto de seguridad WAF o contra DSD disponible para todos los servicios a los que se accede a través de un balanceador de cargas de HTTP(S) externo.
• Habilitar el servicio para optimizar la entrega con Cloud CDN. Con Cloud CDN, puedes almacenar contenido en caché cerca de los usuarios. Cloud CDN proporciona capacidades como la invalidación de caché y las URL firmadas de Cloud CDN.
• Usa certificados SSL administrados por Google. Puedes volver a usar certificados y claves privadas que ya usas para otros productos de Google Cloud. Esto quita la necesidad de administrar certificados separados.

En el siguiente diagrama, se muestra una implementación híbrida con un balanceador de cargas HTTP(S) externo.

Conectividad híbrida con el balanceo de cargas de HTTP(S) interno (haz clic para ampliar)

En este diagrama, el tráfico de los clientes en la Internet pública ingresa a tu red privada local o en la nube a través de un balanceador de cargas de Google Cloud, como el balanceador de cargas de HTTP(S) externo global. Cuando el tráfico llega al balanceador de cargas, puedes aplicar servicios de red perimetral, como la protección contra DSD de Google Cloud Armor o la autenticación de usuario de Identity-Aware Proxy (IAP).

La forma en que se enruta la solicitud (ya sea a un backend de Google Cloud o a un extremo local o en la nube) depende de cómo se configure tu mapa de URL. Según el mapa de URL, el balanceador de cargas selecciona un servicio de backend para la solicitud. Si el servicio de backend seleccionado se configuró con un NEG de conectividad híbrida (solo para extremos que no son de Google Cloud), el balanceador de cargas reenvía el tráfico a través de Cloud VPN o Cloud Interconnect al destino previsto.

Clientes internos (de Google Cloud o locales)

También puedes configurar una implementación híbrida para clientes internos de Google Cloud. En este caso, el tráfico del cliente se origina desde la red de VPC de Google Cloud, tu red local o desde otra nube, y se enruta a extremos que pueden estar en Google Cloud, en tu entorno local o en otra nube. Ten en cuenta que el balanceo de cargas HTTP(S) interno es un balanceador de cargas regional, lo que significa que solo puede enrutar el tráfico a los extremos dentro de la misma zona o región de GCP que los recursos del balanceador de cargas.

En el siguiente diagrama, se muestra una implementación híbrida con un balanceador de cargas HTTP(S) interno.

Conectividad híbrida con el balanceo de cargas de HTTP(S) interno (haz clic para ampliar)

Caso de uso: Migrar a Cloud

La migración de un servicio existente a la nube te permite liberar capacidad local y reducir el costo y la carga de mantener la infraestructura local. Puedes configurar de forma temporal una implementación híbrida que te permita enrutar el tráfico al servicio local actual y al extremo del servicio de Google Cloud correspondiente.

En el siguiente diagrama, se muestra esta configuración con el balanceo de cargas HTTP(S) interno.

Migra a Google Cloud (haz clic para ampliar)

Si usas el balanceo de cargas de HTTP(S) interno para manejar los clientes internos, puedes configurar el balanceador de cargas de Google Cloud a fin de usar el tráfico basado en el peso para dividir el tráfico en los dos servicios. La división del tráfico te permite comenzar enviando un 0% del tráfico al servicio de Google Cloud y un 100% al servicio local. Luego, puedes aumentar de forma gradual la proporción del tráfico enviado al servicio de Google Cloud. Por último, envías el 100% del tráfico al servicio de Google Cloud y puedes retirar el servicio local.

Arquitectura híbrida

En esta sección, se describen la arquitectura y los recursos del balanceo de cargas necesarios para configurar una implementación de balanceo de cargas híbrido.

Los servicios locales y otros servicios en la nube son como cualquier otro backend de Cloud Load Balancing. La diferencia clave es que usas un NEG de conectividad híbrida para configurar los extremos de estos backends. Los extremos deben ser combinaciones IP:port válidas a las que tus clientes puedan acceder a través de una conectividad híbrida, como Cloud VPN o Cloud Interconnect.

En el siguiente diagrama, se muestran los recursos de Google Cloud necesarios a fin de habilitar el balanceo de cargas híbrido para el balanceo de cargas de HTTP(S) externo.

Recursos del balanceador de cargas de HTTP(S) externo para la conectividad híbrida (haz clic para ampliar)

En el siguiente diagrama, se muestran los recursos de Google Cloud necesarios a fin de habilitar el balanceo de cargas híbrido para el balanceo de cargas de HTTP(S) interno.

Recursos del balanceador de cargas de HTTP(S) interno para la conectividad híbrida (haz clic para ampliar)

Regional en comparación con global

El enrutamiento de Cloud Load Balancing depende del permiso del balanceador de cargas configurado:

Balanceo de cargas HTTP(S) externo. Para el tráfico de Internet, el balanceador de cargas HTTP(S) externo se puede configurar a fin de realizar el enrutamiento global o regional, según el nivel de la red que se use. Debes crear el backend de NEG híbrido del balanceador de cargas en la misma región en la que se configuró la conectividad híbrida. Los extremos que no son de Google Cloud también deben configurarse según corresponda para aprovechar el balanceo de cargas basado en la proximidad.

Balanceo de cargas HTTP(S) interno. Para el tráfico de clientes internos, el balanceador de cargas HTTP(S) interno es un balanceador de cargas regional. Es decir, solo puede enrutar el tráfico a los extremos dentro de la misma región que el balanceador de cargas. Los componentes internos del balanceador de cargas HTTP(S) deben configurarse en la misma región en la que se configuró la conectividad híbrida. Debido a que el balanceo de cargas HTTP(S) interno no admite el acceso global, los clientes que acceden al balanceador de cargas también deben estar en la misma región.

Por ejemplo, si la puerta de enlace de Cloud VPN o el adjunto de VLAN de Cloud Interconnect se configuraron en us-central1, los recursos que requiere el balanceador de cargas HTTP(S) interno (servicio de backend, NEG híbrido, regla de reenvío, etcétera) se debe crear en la región us-central1. Los clientes que acceden al balanceador de cargas también deben estar en la región us-central1.

Requisitos de conectividad de red

Antes de configurar una implementación de balanceo de cargas híbrido, debes tener configurados los siguientes recursos:

• Red de VPC de Google Cloud. Una red de VPC configurada dentro de Google Cloud Esta es la red en la que se crearán los recursos de balanceo de cargas híbridos (regla de reenvío, proxy de destino, servicio de backend, etcétera). Las direcciones IP locales, otras de la nube y de la subred de Google Cloud no deben superponerse. Cuando las direcciones IP se superponen, las rutas de subred se priorizan por sobre la conectividad remota.
• Conectividad híbrida. Tu Google Cloud, el entorno local y otros entornos de nube deben estar conectados a través de la conectividad híbrida, mediante un adjunto de VLAN de Cloud Interconnect o túneles de Cloud VPN con Cloud Router. Te recomendamos usar una conexión de alta disponibilidad. Un Cloud Router habilitado con enrutamiento dinámico global aprende sobre el extremo específico a través de BGP y lo programa en tu red de VPC de Google Cloud. No se admite el enrutamiento dinámico regional. Tampoco se admiten las rutas estáticas.
  
  Cloud Interconnect/Cloud VPN y Cloud Router deben configurarse en la misma red de VPC que deseas usar para la implementación del balanceo de cargas híbrido. Cloud Router también debe anunciar las siguientes rutas a tu entorno local:
  • Los rangos que usan los sondeos de verificación de estado de Google: 35.191.0.0/16 y 130.211.0.0/22.
  • Solo para el balanceo de cargas de HTTP(S) interno, el rango de la subred de solo proxy de la región.
• Extremos de red (IP:Port) en tu entorno local o en otra nube. Uno o más extremos de red de IP:Port configurados dentro de tus entornos locales u otros entornos de nube, que se pueden enrutar a través de Cloud Interconnect o Cloud VPN. Si hay varias rutas de acceso al extremo de IP, el enrutamiento seguirá el comportamiento descrito en la descripción general de las rutas de VPC y en la descripción general de Cloud Router.
• Reglas de firewall en tu entorno local o en otro entorno de nube. Las siguientes reglas de firewall se deben crear en tu entorno local o en otro entorno de nube:
  • Ingress permite las reglas de firewall para permitir el tráfico de los sondeos de verificación de estado de Google a tus extremos. Para el balanceador de cargas de HTTP(S) externo, el balanceador de cargas de HTTP(S) interno, el balanceador de cargas de proxy TCP y el balanceador de cargas de proxy SSL, los rangos que se permitirán son: 35.191.0.0/16 y 130.211.0.0/22. , Ten en cuenta que Cloud Router también debe anunciar estos rangos en tu red local. Para obtener más detalles, consulta Rangos de IP del sondeo y reglas de firewall.
  • Ingress permite que las reglas de firewall permitan que el tráfico con balanceo de cargas llegue a los extremos.
  • Para el balanceo de cargas HTTP(S) interno, también debes crear una regla de firewall que permita que el tráfico de la subred de solo proxy de la región llegue a los extremos.

Componentes del balanceador de cargas

Según el tipo de balanceador de cargas, puedes configurar una implementación del balanceo de cargas híbrido con los niveles de servicio de red Estándar o Premium.

Un balanceador de cargas híbrido requiere una configuración especial solo para el servicio de backend. La configuración del frontend es la misma que cualquier otro balanceador de cargas. Además, los balanceadores de cargas HTTP(S) internos requieren una subred de solo proxy para ejecutar los proxies de Envoy en tu nombre.

Configuración de frontend

No se requiere ninguna configuración especial de frontend para el balanceo de cargas híbrido. Las reglas de reenvío se usan para enrutar el tráfico por dirección IP, puerto y protocolo a un proxy de destino. Luego, el proxy de destino finaliza las conexiones de los clientes.

Los balanceadores de cargas HTTP(S) usan los mapas de URL para configurar el enrutamiento basado en URL de las solicitudes a los servicios de backend correspondientes.

Para obtener más detalles sobre cada uno de estos componentes, consulta las secciones de arquitectura de las descripciones generales de los balanceadores de cargas específicos:

• Balanceo de cargas de HTTP(S) externo
• Balanceo de cargas de HTTP(S) interno
• Balanceo de cargas de proxy TCP
• Balanceo de cargas del proxy SSL

Servicio de backend

Los servicios de backend proporcionan información de configuración al balanceador de cargas. Los balanceadores de cargas usan la información en el servicio de backend para dirigir el tráfico entrante a uno o más backends conectados.

Para configurar una implementación del balanceo de cargas híbrido, configura el balanceador de cargas con backends que estén dentro de Google Cloud y fuera de Google Cloud.

• Backends ajenos a Google Cloud (local o en otra nube)

  Cualquier destino al que puedas acceder mediante los productos de conectividad híbrida de Google (Cloud VPN o Cloud Interconnect), y al que se pueda acceder con una combinación válida de IP:Port, se puede configurar como extremo para el balanceador de cargas.

  Configura los backends que no sean de Google Cloud de la siguiente manera:

  1. Agrega cada combinación IP:Port de extremo de red que no sea de Google Cloud a un grupo de extremos de red (NEG) de conectividad híbrida. Asegúrate de que se pueda acceder a esta dirección IP y al puerto desde Google Cloud mediante la conectividad híbrida (ya sea mediante Cloud VPN o Cloud Interconnect). Para los NEG de conectividad híbrida, debes establecer el tipo de extremo de red como NON_GCP_PRIVATE_IP_PORT.
  2. Cuando creas el NEG, especifica una zona de Google Cloud que minimice la distancia geográfica entre Google Cloud y tu entorno local o de otra nube. . Por ejemplo, si alojas un servicio en un entorno local en Fráncfort, Alemania, puedes especificar la zona europe-west3-a de Google Cloud cuando crees el NEG.
  3. Agrega este NEG de conectividad híbrida como un backend para el servicio de backend.

• Backends de Google Cloud

  Configura los extremos de Google Cloud de la siguiente manera:

  1. Crea un servicio de backend independiente para los backends de Google Cloud.
  2. Configura varios backends (NEG zonales o grupos de instancias) dentro de la misma región en la que configuraste la conectividad híbrida.

Puntos adicionales que considerar:

• Cada NEG de conectividad híbrida solo puede contener extremos de red del mismo tipo (NON_GCP_PRIVATE_IP_PORT).

• El servicio de backend tampoco puede usar otros tipos de NEG o grupos de instancias como backends. Todos los backends de un servicio de backend deben ser del mismo tipo. Si tienes backends en Google Cloud, debes crear un servicio de backend independiente para ellos. Esto se debe a que los backends basados en Google Cloud usarán un tipo diferente de backend (grupo de instancias o NEG zonal) y los servicios de backend con tipos de backend mixtos no son compatibles.

• El esquema de balanceo de cargas del servicio de backend debe ser EXTERNAL_MANAGED para el balanceador de cargas HTTP(S) externo global, EXTERNAL para el balanceador de cargas HTTP(S) externo global (clásico), el balanceador de cargas de proxy TCP y el balanceador de cargas de proxy SSL, o INTERNAL_MANAGED para balanceadores de cargas HTTP(S) internos. INTERNAL_SELF_MANAGED es compatible con implementaciones de entornos múltiples de Traffic Director con NEG de conectividad híbrida.

• El protocolo de servicio de backend debe ser HTTP, HTTPS o HTTP2 para los balanceadores de cargas HTTP(S), y TCP o SSL para el balanceador de cargas de proxy TCP y el balanceador de cargas de proxy SSL. Para obtener la lista de protocolos de servicio de backend compatibles con cada balanceador de cargas, consulta Protocolos del balanceador de cargas al backend.

• El modo de balanceo del backend debe ser RATE para el balanceo de cargas HTTP(S) interno y externo, y CONNECTION para el balanceo de cargas de proxy TCP/SSL. Para obtener detalles sobre los modos de balanceo, consulta Descripción general de los servicios de backend.

• Para agregar más extremos de red, actualiza los backends conectados a tu servicio de backend.

Importante: Si bien es posible crear un NEG de conectividad híbrida que apunte a los backends dentro de una red de VPC de Google Cloud diferente de la del balanceador de cargas, esta configuración no funciona. Usa un tipo diferente de NEG que sea compatible con el balanceador de cargas.

Verificaciones de estado

Cada servicio de backend debe estar asociado con una verificación de estado que verifique el estado de los backends. Para que los sondeos de verificación de estado funcionen de manera correcta, debes crear reglas de firewall que permitan el tráfico de los rangos de IP de sondeo de Google (130.211.0.0/22 y 35.191.0.0/16) acceda a tus extremos.

Para los backends fuera de Google Cloud, crea reglas de firewall en las redes locales y de otras nubes. Comunícate con tu administrador de red para esto. El Cloud Router que se usa para la conectividad híbrida también debe anunciar los rangos que usan los sondeos de verificación de estado de Google. Los rangos que se anunciarán son 35.191.0.0/16 y 130.211.0.0/22.

Para los backends dentro de Google Cloud, crea reglas de firewall en Google Cloud como se muestra en este ejemplo.

Limitaciones

• Los NEG de conectividad híbrida no son compatibles con Google Cloud Console. Para crear, borrar o administrar NEG de conectividad híbrida, debes usar Google Cloud CLI o la API de REST.
• El Cloud Router que se usa para la conectividad híbrida debe estar habilitado con el enrutamiento dinámico global. No se admiten el enrutamiento dinámico regional ni las rutas estáticas.
• El balanceo de cargas HTTP(S) interno y la conectividad híbrida deben configurarse en la misma región. Si están configurados en diferentes regiones, es posible que veas backends como en buen estado, pero las solicitudes de los clientes no se reenviarán al backend.

• Las consideraciones para las conexiones encriptadas desde el balanceador de cargas a los backends documentados aquí también se aplican a los extremos de backend que no son de Google Cloud configurados en el NEG de conectividad híbrida.

  Asegúrate de revisar también la configuración de seguridad en tu configuración de conectividad híbrida. Actualmente, las conexiones de Cloud VPN con alta disponibilidad están encriptadas (IPSec) de forma predeterminada. Las conexiones de Cloud Interconnect no están encriptadas de forma predeterminada. Para obtener más detalles, consulta el informe Encriptación en tránsito en Google Cloud.

Logging

Las solicitudes enviadas mediante proxy a un extremo en un NEG híbrido se registran en Cloud Logging de la misma manera que las solicitudes de otros backends de balanceo de cargas HTTP(S). Para obtener más información, consulta Registro y supervisión del balanceo de cargas HTTP(S).

Si habilitas Cloud CDN para tu balanceador de cargas, también se registrarán los aciertos de caché.

Cuota

Puedes configurar tantos NEG híbridos con extremos de red como lo permita la cuota de tu grupo de extremos de red existente. Para obtener más información, consulta Backends de NEG y Extremos por NEG.

¿Qué sigue?

• Configura un balanceador de cargas de HTTP(S) externo con conectividad híbrida.
• Configura un balanceador de cargas de HTTP(S) interno con conectividad híbrida.
• Para obtener más información sobre la conectividad híbrida con Traffic Director, consulta la descripción general de la conectividad híbrida de Traffic Director.
• Si deseas configurar Traffic Director para implementaciones híbridas, consulta Servicios de perímetro de red para implementaciones de múltiples entornos.