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 Trusted Cloud by S3NS, 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 Trusted Cloud.

El balanceo de cargas híbrido es compatible con los siguientes Trusted Cloud by S3NS balanceadores de cargas:

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, Cloud Interconnect o VMs de dispositivos de router.

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 deTrusted Cloud a una ubicación local o a otro entorno de nube. Los clientes pueden originar tráfico desde la Internet pública, desde Trusted Cloudo 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 regional, puedes enrutar el tráfico externo a los extremos que se encuentran dentro de la misma Trusted Cloud región 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 Trusted 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 deTrusted Cloud ), el balanceador de cargas reenvía el tráfico a través de Cloud VPN, Cloud Interconnect o VMs de dispositivos de router al destino externo previsto.

Clientes internos (dentro de Trusted Cloud o locales)

También puedes configurar una implementación híbrida para clientes internos deTrusted Cloud. En este caso, el tráfico del cliente se origina desde la red deTrusted Cloud VPC, 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 Trusted Cloud región que los recursos del balanceador de cargas.

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

Conectividad híbrida con 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 deTrusted Cloud correspondiente.

Si usas un balanceador de cargas de aplicaciones interno para controlar los clientes internos, puedes configurar el Trusted Cloud balanceador de cargas para que use la división del tráfico basada en el peso y 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 Trusted Cloud y un 100% al servicio local. Luego, puedes aumentar de forma gradual la proporción del tráfico enviado al servicio de Trusted Cloud . Por último, envías el 100% del tráfico al servicio Trusted 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, Cloud Interconnect o una VM de dispositivo de router.

En los siguientes diagramas, se muestran los Trusted Cloud recursos necesarios para habilitar el balanceo de cargas híbrido.

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)

Enrutamiento de Cloud Load Balancing

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

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.

Por ejemplo, si la puerta de enlace de Cloud VPN o el adjunto de VLAN de Cloud Interconnect están configurados en REGION_A, 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 REGION_A. De forma predeterminada, los clientes que acceden al balanceador de cargas también deben estar en la región REGION_A.

Requisitos de conectividad de red

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

  • Trusted Cloud Red de VPC. Una red de VPC configurada dentro de Trusted CloudEsta es la red de VPC que se usa para configurar Cloud Interconnect/Cloud VPN y Cloud Router. Esta es también 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 Trusted 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 Trusted Cloud y otros entornos de nube deben estar conectados a través de la conectividad híbrida, mediante adjuntos de VLAN de Cloud Interconnect, túneles de Cloud VPN con Cloud Router o VMs de dispositivos de 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 deTrusted Cloud VPC. No se admite el enrutamiento dinámico regional. Tampoco se admiten las rutas estáticas.

    Cloud Interconnect/Cloud VPN/dispositivo de 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:

    • Rangos que usan los sondeos de verificación de estado de Google: 35.191.0.0/16 y 130.211.0.0/22.

    • 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 aplicaciones internos regionales, balanceadores de cargas de red de proxy externos regionales, y balanceadores de cargas de red de proxy internos regionales.

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

    Puedes usar la misma red o una red de VPC diferente dentro del mismo proyecto para configurar tanto las redes híbridas (Cloud Interconnect o Cloud VPN) como el balanceador de cargas. Ten en cuenta lo siguiente:

    • Si usas diferentes redes de VPC, las dos redes deben estar conectadas a través del intercambio de tráfico entre redes de VPC o deben ser radios de VPC en el mismo concentrador de Network Connectivity Center.

    • Si usas la misma red de VPC, asegúrate de que los rangos de CIDR de la subred de la red de VPC no entren en conflicto con los rangos de CIDR remotos. Cuando las direcciones IP se superponen, las rutas de subred se priorizan por sobre la conectividad remota.

  • 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, Cloud VPN o una VM del dispositivo de router. 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 aplicaciones internos regionales, balanceadores de cargas de red de proxy externos regionales, y balanceadores de cargas de red de proxy internos regionales), 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 que se encuentran en instalaciones locales o en otros entornos de nube.

Componentes del balanceador de cargas

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 aplicaciones internos regionales, balanceadores de cargas de red de proxy externos regionales, y balanceadores de cargas de red de proxy internos regionales) requieren 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 Trusted Cloudy fuera de Trusted Cloud.

  • Backends ajenos aTrusted Cloud (locales o en otra nube)

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

    Configura tus backends que no sean deTrusted Cloud de la siguiente manera:

    1. Agrega cada combinación IP:Port de extremo de red que no sea deTrusted 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 Trusted Cloud con conectividad híbrida (ya sea a través de Cloud VPN, Cloud Interconnect o VMs de dispositivo de router). Para los NEG de conectividad híbrida, debes establecer el tipo de extremo de red como NON_GCP_PRIVATE_IP_PORT.
    2. Cuando crees el NEG, especifica una Trusted Cloud zona que minimice la distancia geográfica entre Trusted 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 Trusted 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 deTrusted Cloud. El tráfico puede descartarse si un NEG híbrido incluye extremos para recursos dentro de una red de Trusted Cloud VPC, como las direcciones IP de reglas de reenvío para balanceadores de cargas de red de transferencia internos. Configura los extremos de Trusted Cloud como se indica en la siguiente sección.

  • Trusted Cloud backends

    Configura tus extremos Trusted Cloud de la siguiente manera:

    1. Crea un servicio de backend independiente para los backends de Trusted 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 enTrusted 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.

  • El esquema de balanceo de cargas del servicio de backend es INTERNAL_MANAGED para los balanceadores de cargas de aplicaciones internos regionales y los balanceadores de cargas de red de proxy internos regionales.

  • 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 de proxy. 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 los balanceadores de cargas de aplicaciones y CONNECTION para los balanceadores de cargas de red de proxy. 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 backends de NEG de conectividad híbrida (solo admitidos para balanceadores de cargas basados en Envoy), asegúrate de configurar extremos de red únicos para todos los NEG adjuntos al mismo servicio de backend. Agregar el mismo extremo de red a varios NEG genera un comportamiento indefinido.

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 regional, balanceador de cargas de aplicaciones interno regional, balanceador de cargas de red del proxy externo regional, balanceador de cargas de red del 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 correctamente, debes crear reglas de firewall en el entorno externo que permitan que el tráfico de la subred de solo proxy llegue a tus backends externos.

    Para los extremos NON_GCP_PRIVATE_IP_PORT fuera de Trusted 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 de Envoy distribuidas se crean con los mismos procesos de la consola, gcloud CLI y la API que las verificaciones de estado centralizadas.Trusted Cloud 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 v1 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 dentro deTrusted Cloud) y NEG híbridos (extremos NON_GCP_PRIVATE_IP_PORT fuera de Trusted Cloud), debes configurar reglas de firewall para permitir el tráfico de los 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 enTrusted Cloud. Esto se debe a que los NEG 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 deTrusted Cloud , la API ni gcloud CLI para verificar el estado de estos extremos externos. En el caso de los NEG híbridos con balanceadores de cargas basados en Envoy, la consola Trusted Cloud muestra el estado de la verificación de estado comoN/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 las verificaciones de estado de Envoy distribuidas no incluyen estados detallados. Para obtener detalles sobre lo que se registra, consulta Registro de la verificación de estado. Para solucionar aún más los problemas de conectividad de los proxies de Envoy a los extremos de tu NEG, también debes consultar 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 deTrusted 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. Las conexiones de 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 sobre Encriptación en tránsito.

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.

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?