Descripción general de grupos de extremos de red de conectividad híbrida

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:

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 pueda acceder tu balanceador de cargas mediante productos de conectividad híbrida, como Cloud VPN o Cloud Interconnect.

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

El caso de uso más simple para usar NEG híbridos es enrutar el tráfico desde un balanceador de cargas de Google Cloud a una ubicación local o a otro entorno de 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 un balanceador de cargas de aplicaciones externo con un backend de NEG híbrido para enrutar el tráfico de clientes externos a un backend local o en otra red de nube. También puedes habilitar las siguientes funciones de red con valor agregado para tus servicios de forma local o en otras redes de nube:

  • Con el balanceador de cargas de aplicaciones externo global y el balanceador de cargas de aplicaciones clásico, puedes 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 aplicaciones 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 de aplicaciones externo.

    Conectividad híbrida con un balanceador de cargas de aplicaciones externo global.
    Conectividad híbrida con un balanceador de cargas de aplicaciones externo global (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 aplicaciones externo. 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).

  • Con el balanceador de cargas de aplicaciones externo regional, puedes enrutar el tráfico externo a los extremos que se encuentran dentro de la misma región de Google Cloud que los recursos del balanceador de cargas. Usa este balanceador de cargas si necesitas entregar contenido desde una sola ubicación geográfica (por ejemplo, para cumplir con las reglamentaciones de cumplimiento) o si deseas usar el nivel de servicio de red Estándar.

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 externo 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 locales o en otras redes de nube.

El balanceador de cargas de aplicaciones interno regional es un balanceador de cargas regional, lo que significa que solo puede enrutar el tráfico a los extremos dentro de la misma región de Google Cloud en la que se encuentran los recursos del balanceador de cargas. El balanceador de cargas de aplicaciones interno entre regiones es un balanceador de cargas multirregión que puede balancear las cargas del tráfico a los servicios de backend distribuidos de forma global.

En el siguiente diagrama, se muestra una implementación híbrida con un balanceador de cargas de aplicaciones interno regional.

Conectividad híbrida con los balanceadores de cargas de aplicaciones internos regionales.
Conectividad híbrida con los balanceadores de cargas de aplicaciones internos regionales (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 un balanceador de cargas de aplicaciones interno.

Migra a Google Cloud
Migra a Google Cloud (haz clic para ampliar)

Si usas un balanceador de cargas de aplicaciones interno para manejar los clientes internos, puedes configurar el balanceador de cargas de Google Cloud a fin de usar la división del tráfico basada 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 los siguientes diagramas, se muestran los recursos de Google Cloud necesarios para habilitar el balanceo de cargas híbrido para balanceadores de cargas de aplicaciones externos y balanceadores de cargas de aplicaciones internos regionales.

HTTP(S) externo global

Recursos del balanceador de cargas de aplicaciones externo global para la conectividad híbrida.
Recursos del balanceador de cargas de aplicaciones externo global para la conectividad híbrida (haz clic para ampliar)

HTTP(S) externo regional

Recursos del balanceador de cargas de aplicaciones externo regional para la conectividad híbrida.
Recursos del balanceador de cargas de aplicaciones externo regional para la conectividad híbrida (haz clic para ampliar)

HTTP(S) interno regional

Recursos del balanceador de cargas de aplicaciones interno regional para la conectividad híbrida.
Recursos del balanceador de cargas de aplicaciones interno regional para la conectividad híbrida (haz clic para ampliar)

Proxy interno regional

Recursos del balanceador de cargas de red del proxy interno regional para la conectividad híbrida.
Recursos del balanceador de cargas de red del proxy interno regional 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:

Balanceador de cargas de aplicaciones externo y balanceador de cargas de red del proxy externo. Estos balanceadores de cargas se pueden configurar para el enrutamiento global o regional según el nivel de red que se use. Debes crear el backend de NEG híbrido del balanceador de cargas en la misma red y 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.

Balanceador de cargas interno de aplicaciones entre regiones Balanceador de cargas de red de proxy interno entre regiones Este es un balanceador de cargas multirregional que puede balancear las cargas del tráfico a los servicios de backend distribuidos de forma global. Debes crear el backend de NEG híbrido del balanceador de cargas en la misma red y 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.

Balanceador de cargas de aplicaciones interna regional y balanceador de cargas de red de proxy interno regional. Estos son balanceadores de cargas regionales. Es decir, solo pueden enrutar el tráfico a los extremos dentro de la misma región que el balanceador de cargas. Los componentes del balanceador de cargas deben configurarse en la misma región en la que se configuró la conectividad híbrida. De forma predeterminada, los clientes que acceden al balanceador de cargas también deben estar en la misma región. Sin embargo, si habilitas el acceso global, los clientes de cualquier región pueden acceder al balanceador de cargas.

Por ejemplo, si la puerta de enlace de Cloud VPN o el adjunto de VLAN de Cloud Interconnect están configurados en us-central1, los recursos que requiere el balanceador de cargas (como un servicio de backend, NEG híbrido o regla de reenvío) se debe crear en la región us-central1. De forma predeterminada, los clientes que acceden al balanceador de cargas también deben estar en la región us-central1. Sin embargo, si habilitas el acceso global, los clientes de cualquier región pueden acceder al balanceador de cargas.

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 de VPC que se usa para configurar Cloud Interconnect/Cloud VPN y Cloud Router. Esta también es la misma red en la que crearás los recursos de balanceo de cargas (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. Esto es necesario para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos, los balanceadores de cargas de red de proxy externo global y los balanceadores de cargas de red de proxy clásico.

    • El rango de la subred de solo proxy de la región: para balanceadores de cargas basados en Envoy: balanceadores de cargas de aplicaciones externos regionales, balanceadores de cargas de red del proxy externos regionales, balanceadores de cargas de red del proxy internos regionales y Balanceadores de cargas de aplicaciones internos.

      También se requiere la subred de solo proxy de la región publicitaria para que funcionen las verificaciones de estado distribuidas de Envoy. La verificación de estado distribuida de Envoy es el mecanismo de verificación de estado predeterminado para los NEGs de conectividad híbrida zonal (es decir, los extremos NON_GCP_PRIVATE_IP_PORT) detrás de los balanceadores de cargas basados en Envoy.

  • Extremos de red (IP:Port) locales o en otras nubes. 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. 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 los balanceadores de cargas basados en Envoy: balanceadores de cargas de aplicaciones externos regionales, balanceadores de cargas de red de proxy externo regionales, balanceadores de cargas de red de proxy internos regionales, balanceadores de cargas de red de proxy internos entre regiones y balanceadores de cargas de aplicaciones internos, también debes crear una regla de firewall para permitir que el tráfico de la subred de solo proxy de la región llegue a los extremos que se encuentran en instalaciones locales o en otros entornos de nube.

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 la de cualquier otro balanceador de cargas. Los balanceadores de cargas basados en Envoy (balanceadores de cargas de aplicaciones externos regionales, balanceadores de cargas de red de proxy externos regionales, balanceadores de cargas de red de proxy internos regionales, balanceadores de cargas de red de proxy internos entre regiones y balanceadores de cargas de aplicaciones internos) exigen una subred de solo proxy adicional para ejecutar 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:

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.

      Un NEG de conectividad híbrida solo debe incluir extremos que no sean de Google Cloud. El tráfico puede descartarse si un NEG híbrido incluye extremos para recursos dentro de una red de VPC de Google Cloud, como las direcciones IP de reglas de reenvío para balanceadores de cargas de red de transferencia internos. Configura los extremos de Google Cloud como se indica en la siguiente sección.

  • 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 GCE_VM_IP_PORT 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).

  • Puedes usar un solo servicio de backend para hacer referencia a backends basados en Google Cloud (mediante NEG zonales con extremos GCE_VM_IP_PORT) y otros backends locales o en la nube (mediante NEG de conectividad híbrida con extremos NON_GCP_PRIVATE_IP_PORT). No se permite ninguna otra combinación de tipos de backend mixtos. Traffic Director no admite tipos de backend mixtos en un solo servicio de backend.

  • El esquema de balanceo de cargas del servicio de backend debe ser uno de los siguientes:

    • EXTERNAL_MANAGED para balanceadores de cargas de aplicaciones externos globales, balanceadores de cargas de aplicaciones externos regionales, balanceadores de cargas de red del proxy externos globales y balanceadores de cargas de red del proxy externos regionales
    • EXTERNAL para balanceadores de cargas de aplicaciones clásicos y balanceadores de cargas de red del proxy clásico
    • INTERNAL_MANAGED para los balanceadores de cargas de aplicaciones internos, los balanceadores de cargas de red de proxy internos entre regiones, los balanceadores de cargas de red de proxy internos entre regiones y los balanceadores de cargas de red de proxy internos regionales

    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 de aplicaciones, y TCP o SSL para los balanceadores de cargas de red del proxy externos y los balanceadores de cargas de red del proxy internos regionales. 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 de NEG híbrido debe ser RATE para balanceadores de cargas de aplicaciones internos y externos, y CONNECTION para balanceadores de cargas de red del proxy internos regionales y balanceadores de cargas de red del proxy externos. 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.

  • Si usas Verificaciones de estado distribuidas de Envoy con NEGs de conectividad híbrida zonal (es decir, NON_GCP_PRIVATE_IP_PORT) detrás de los balanceadores de cargas basados en Envoy, no configures la misma red extremo en varios NEG conectados a un servicio de backend. Si lo haces, se produce un comportamiento indefinido.

Verificaciones de estado centralizadas

Las verificaciones de estado centralizadas, cuando se usan NEGs híbridos, son necesarias para los balanceadores de cargas de aplicaciones externos globales, los balanceadores de cargas de aplicaciones clásicos, los balanceadores de cargas de red de proxy externo globales y los balanceadores de cargas de red de proxy clásico. Otros balanceadores de cargas basados en Envoy usan verificaciones de estado de Envoy distribuidas, como se describe en la siguiente sección.

Para los extremos NON_GCP_PRIVATE_IP_PORT 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 otros tipos de backends dentro de Google Cloud, crea reglas de firewall en Google Cloud como se muestra en este ejemplo.

Documentación relacionada:

Verificaciones de estado distribuidas de Envoy

La configuración de la verificación de estado varía según el tipo de balanceador de cargas:

  • Balanceador de cargas de aplicaciones externo global, balanceador de cargas de aplicaciones clásico, balanceador de cargas de red del proxy externo global y balanceador de cargas de red del proxy clásico Estos balanceadores de cargas no admiten las verificaciones de estado distribuidas de Envoy. Aún usan el mecanismo de verificación de estado centralizado de Google como se describe en la sección Verificaciones de estado centralizadas.

  • Balanceador de cargas de aplicaciones externo regional, balanceador de cargas de aplicaciones interno (entre regiones y regional), balanceador de cargas de red de proxy externo regional, balanceador de cargas de red de proxy interno entre regiones y balanceador de cargas de red de proxy interno regional. Estos balanceadores de cargas usan verificaciones de estado distribuidas de Envoy para verificar el estado de los NEGs híbridos. Los sondeos de verificación de estado se originan en el propio software de proxy de Envoy. Cada servicio de backend debe estar asociado con una verificación de estado que verifique el estado de los backends. Los sondeos de verificación de estado se originan en los proxies de Envoy en la subred de solo proxy en la región. Para que los sondeos de verificación de estado funcionen de manera correcta, debes crear reglas de firewall en el entorno externo que permitan que el tráfico de la subred de solo proxy llegue a los backends externos.

    Para los extremos NON_GCP_PRIVATE_IP_PORT fuera de Google Cloud, debes crear estas reglas de firewall en tus redes locales y de otras nubes. Comunícate con tu administrador de red para esto. El Cloud Router que usas para la conectividad híbrida también debe anunciar el rango de subred de solo proxy de la región.

Las verificaciones de estado distribuidas de Envoy se crean mediante los mismos procesos de la consola de Google Cloud, la CLI de gcloud y la API que las verificaciones de estado centralizadas. No se requiere ninguna otra configuración.

Puntos para tener en cuenta:

  • No se admiten las verificaciones de estado de gRPC.
  • No se admiten las verificaciones de estado con el protocolo PROXY habilitado.
  • Si usas NEG mixtos en los que un solo servicio de backend tiene una combinación de NEG zonales (extremos GCE_VM_IP_PORT en Google Cloud) y NEG híbridos (extremos NON_GCP_PRIVATE_IP_PORT fuera de Google Cloud), debes configurar reglas de firewall para permitir el tráfico desde Rangos de IP de sondeo de verificación de estado de Google (130.211.0.0/22 y 35.191.0.0/16) a los extremos de NEG zonales en Google Cloud. Esto se debe a que los NEGs zonales usan el sistema centralizado de verificación de estado de Google.

  • Debido a que el plano de datos de Envoy controla las verificaciones de estado, no puedes usar la consola de Google Cloud, la API ni la CLI de gcloud para verificar el estado de estos extremos externos. En el caso de los NEGs híbridos con balanceadores de cargas basados en Envoy, la consola de Google Cloud muestra el estado de la verificación de estado como N/A. Esta situación es esperable.

  • Cada proxy de Envoy asignado a la subred de solo proxy en la región de la red de VPC inicia las verificaciones de estado de forma independiente. Por lo tanto, es posible que veas un aumento en el tráfico de red debido a la verificación de estado. El aumento depende de la cantidad de proxies de Envoy asignados a tu red de VPC en una región, la cantidad de tráfico que reciben estos proxies y la cantidad de extremos en los que cada proxy de Envoy debe comprobar el estado. En el peor de los casos, el tráfico de red generado por las verificaciones de estado aumenta a una frecuencia cuadrática de (O(n^2)).

  • Los registros de verificaciones de estado de las verificaciones de estado distribuidas de Envoy no incluyen estados detallados. Para obtener detalles sobre lo que se registra, consulta Registro de verificación de estado. Para solucionar problemas de conectividad de proxies de Envoy a tus extremos de NEG, también debes verificar los registros correspondientes del balanceador de cargas.

Documentación relacionada:

Limitaciones

  • 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.
  • Para los balanceadores de cargas regionales basados en Envoy (balanceadores de cargas de aplicaciones externos regionales, balanceadores de cargas de red del proxy externos regionales, balanceadores de cargas de red del proxy internos regionales y balanceadores de cargas de aplicaciones internos regionales), la conectividad híbrida debe configurarse en la misma región que el balanceador de cargas. Si están configurados en diferentes regiones, es posible que veas backends en buen estado, pero las solicitudes de clientes no se reenviarán a los backends.

  • 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 VPN de 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 sobre Encriptación en tránsito.

Registros

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. Si habilitas Cloud CDN para tu balanceador de cargas de aplicaciones externo global, también se registrarán los aciertos de caché.

Para obtener más información, consulte:

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?