Descripción general del balanceador de cargas de aplicaciones interno

En este documento, se presentan los conceptos que debes comprender para configurar balanceadores de cargas de aplicaciones internos.

Un Trusted Cloud by S3NS balanceador de cargas de aplicaciones interno es un balanceador de cargas de capa 7 basado en proxy que te permite ejecutar y escalar tus servicios detrás de una sola dirección IP interna. El balanceador de cargas de aplicaciones interno distribuye el tráfico HTTP y HTTPS a los backends alojados en una variedad de Trusted Cloud plataformas, como Compute Engine, Google Kubernetes Engine (GKE) y Cloud Run. Para obtener más información, consulta Casos de uso.

Modos de operación

Este balanceador de cargas está disponible en el modo regional y, a partir de ahora, se denominará balanceador de cargas de aplicaciones interno regional. El balanceador de cargas se implementa como un servicio administrado basado en el proxy de Envoy con código abierto. Incluye capacidades de administración de tráfico avanzada, como duplicación de tráfico, división de tráfico basada en el peso, transformaciones de encabezados basadas en solicitudes o respuestas, y mucho más. El modo regional requiere que los backends se encuentren en una sola Trusted Cloud región. Los clientes pueden limitarse a esa región o estar en cualquier región, según si el acceso global está inhabilitado o habilitado en la regla de reenvío.

Arquitectura y recursos

En el siguiente diagrama, se muestran los recursos Trusted Cloud necesarios para los balanceadores de cargas de aplicaciones internos:

Balanceador de cargas de aplicaciones interno regional

En este diagrama, se muestran los componentes de una implementación del balanceador de cargas de aplicaciones interno regional en el nivel Premium.

Componentes del balanceador de cargas de aplicaciones interno regional.
Componentes del balanceador de cargas de aplicaciones interno regional (haz clic para ampliar).

Los siguientes recursos son necesarios para implementar un balanceador de cargas de aplicaciones interno:

Subred de solo proxy

La subred de solo proxy proporciona un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. Debes crear una subred de solo proxy en cada región de una red de VPC en la que uses balanceadores de cargas de aplicaciones internos regionales. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas regionales basados en Envoy en una región y red de VPC comparten un grupo de proxies de Envoy de la misma subred de solo proxy.

Además:

  • Las subredes de solo proxy se usan solo para los proxies de Envoy, no para tus backends.
  • Las VMs de backend o los extremos de todos los balanceadores de cargas de aplicaciones internos en una región y red de VPC reciben conexiones desde la subred de solo proxy.
  • La dirección IP virtual de un balanceador de cargas de aplicaciones interno no se encuentra en la subred de solo proxy. La dirección IP del balanceador de cargas se define según su regla de reenvío administrada interna, que se describe a continuación.

Regla de reenvío y dirección IP

Las reglas de reenvío enrutan el tráfico por dirección IP, puerto y protocolo a una configuración de balanceo de cargas que consiste de un proxy de destino y un servicio de backend.

Especificación de la dirección IP Cada regla de reenvío proporciona una sola dirección IP regional que puedes usar en los registros DNS de tu aplicación. Puedes reservar una dirección IP estática para usarla o permitir que Cloud Load Balancing te asigne una. Te recomendamos reservar una dirección IP estática; de lo contrario, deberás actualizar tu registro DNS con la dirección IP efímera recién asignada cada vez que borres una regla de reenvío y crees una nueva.

Los clientes usan la dirección IP y el puerto para conectarse a los proxies de Envoy del balanceador de cargas; la dirección IP de la regla de reenvío es la dirección IP del balanceador de cargas (a veces denominada dirección IP virtual o VIP). Los clientes que se conectan a un balanceador de cargas deben usar la versión 1.1 de HTTP o una posterior. Para obtener una lista completa de los protocolos compatibles, consulta Comparación de funciones del balanceador de cargas.

La dirección IP interna asociada con la regla de reenvío puede provenir de una subred en la misma red y región que los backends.

Especificación de puerto Cada regla de reenvío para un balanceador de cargas de aplicaciones puede hacer referencia a un puerto único del 1 al 65535. Para admitir varios puertos, debes configurar varias reglas de reenvío. Puedes configurar varias reglas de reenvío para usar la misma dirección IP interna (VIP) y hacer referencia al mismo proxy HTTP o HTTPS de destino siempre que la combinación general de la dirección IP, el puerto y el protocolo sean únicos para cada regla de reenvío. De esta manera, puedes usar un solo balanceador de cargas con un mapa de URL compartido como proxy para varias aplicaciones.

El tipo de regla de reenvío, la dirección IP y el esquema de balanceo de cargas que usan los balanceadores de cargas de aplicaciones internos dependen del modo del balanceador de cargas.

Balanceador de cargas de aplicaciones interno regional
Regla de reenvío

Método forwardingRules.insert
Dirección IP regional

Método addresses.insert
Esquema de balanceo de cargas

INTERNAL_MANAGED
Dirección IP (opcional)

SHARED_LOADBALANCER_VIP
Enrutamiento del cliente al frontend del balanceador de cargas

Puedes habilitar el acceso global para permitir que los clientes de cualquier región de una VPC accedan al balanceador de cargas. Los backends también deben estar en la misma región que el balanceador de cargas.

Reglas de reenvío y redes de VPC

En esta sección, se describe cómo las reglas de reenvío que usan los balanceadores de cargas de aplicaciones internos se asocian con las redes de VPC.

Modo de balanceador de cargas Asociación de redes de VPC
Balanceador de cargas de aplicaciones interno regional

Las direcciones IPv4 internas regionales siempre existen dentro de las redes de VPC. Cuando crees la regla de reenvío, deberás especificar la subred de la que se toma la dirección IP interna. Esta subred debe estar en la misma región y red de VPC en la que se creó una subred de solo proxy. Por lo tanto, hay una asociación de red implícita.

Proxy de destino

Un proxy HTTP o HTTPS de destino finaliza las conexiones HTTP(S) de los clientes. El proxy HTTP(S) consulta el mapa de URL para determinar el enrutamiento del tráfico a los backends. Un proxy HTTPS de destino usa un certificado SSL para autenticarse en los clientes.

El balanceador de cargas conserva el encabezado del host de la solicitud original del cliente. El balanceador de cargas también agrega dos direcciones IP al encabezado X-Forwarded-For:

  • La dirección IP del cliente que se conecta al balanceador de cargas
  • La dirección IP de la regla de reenvío del balanceador de cargas

Si no hay un encabezado X-Forwarded-For en la solicitud entrante, estas dos direcciones IP son el valor completo del encabezado. Si la solicitud tiene un encabezado X-Forwarded-For, otra información, como las direcciones IP registradas por los proxies en el camino hacia el balanceador de cargas, se conserva antes de las dos direcciones IP. El balanceador de cargas no verifica ninguna dirección IP que preceda a las últimas dos direcciones IP en este encabezado.

Si ejecutas un proxy como servidor de backend, este suele agregar más información al encabezado X-Forwarded-For, y es posible que tu software deba tener esto en cuenta. Las solicitudes que se envían a través de un proxy desde el balanceador de cargas provienen de una dirección IP en la subred de solo proxy, y el proxy en tu instancia de backend podría registrar esta dirección, así como la dirección IP de la instancia de backend.

Según el tipo de tráfico que necesite controlar tu aplicación, puedes configurar un balanceador de cargas con un proxy HTTP de destino o un proxy HTTPS de destino.

En la siguiente tabla, se muestran las APIs de proxy de destino que requieren los balanceadores de cargas de aplicaciones internos:

Modo de balanceador de cargas Proxy de destino
Balanceador de cargas de aplicaciones interno regional

Certificados SSL

Los balanceadores de cargas de aplicaciones internos que usan proxies HTTPS de destino requieren claves privadas y certificados SSL como parte de la configuración del balanceador de cargas.

Los balanceadores de cargas de aplicaciones internos regionales admiten certificados SSL de Compute Engine autoadministrados.

Mapas de URL

El proxy HTTP(S) de destino usa mapas de URL para realizar una determinación de enrutamiento basada en atributos HTTP (como la ruta de la solicitud, las cookies o los encabezados). En función de la decisión de enrutamiento, el proxy desvía las solicitudes de los clientes a servicios de backend específicos. En el mapa de URL se pueden especificar acciones adicionales, como volver a escribir encabezados, enviar redireccionamientos a clientes y configurar políticas de tiempo de espera, entre otras.

En la siguiente tabla, se especifica el tipo de mapa de URL que requieren los balanceadores de cargas de aplicaciones externos en cada modo.

Modo de balanceador de cargas Tipo de mapa de URL
Balanceador de cargas de aplicaciones interno regional regionUrlMaps

Servicio de backend

Un servicio de backend proporciona información de configuración al balanceador de cargas para que pueda dirigir las solicitudes a sus backends, por ejemplo, grupos de instancias de Compute Engine o grupos de extremos de red (NEG). Para obtener más información sobre los servicios de backend, consulta la Descripción general de los servicios de backend.

Permiso del servicio de backend

En la siguiente tabla, se indica qué recurso y alcance del servicio de backend utilizan los balanceadores de cargas de aplicaciones internos:

Modo de balanceador de cargas Recurso de servicio de backend
Balanceador de cargas de aplicaciones interno regional regionBackendServices

Protocolo para los backends

Los servicios de backend para los balanceadores de cargas de aplicaciones deben usar uno de los siguientes protocolos para enviar solicitudes a los backends:

  • HTTP, que usa HTTP/1.1 y no usa TLS
  • HTTPS, que usa HTTP/1.1 y TLS
  • HTTP/2, que usa HTTP/2 y TLS (no se admite HTTP/2 sin encriptación)
  • H2C, que usa HTTP/2 a través de TCP No se requiere TLS. H2C no es compatible con los balanceadores de cargas de aplicaciones clásicos.

El balanceador de cargas solo usa el protocolo del servicio de backend que especifiques para comunicarse con sus backends. El balanceador de cargas no recurre a un protocolo diferente si no puede comunicarse con los backends usando el protocolo de servicio de backend especificado.

El protocolo del servicio de backend no necesita coincidir con el protocolo que usan los clientes para comunicarse con el balanceador de cargas. Por ejemplo, los clientes pueden enviar solicitudes al balanceador de cargas con HTTP/2, pero el balanceador de cargas puede comunicarse con los backends con HTTP/1.1 (HTTP o HTTPS).

Backends

Un balanceador de cargas de aplicaciones externo regional admite los siguientes tipos de backends:

  • Grupos de instancias
  • NEG zonales
  • NEG de Internet
  • NEG híbridos

Backends y redes de VPC

Las restricciones sobre dónde se pueden ubicar los backends dependen del tipo de backend.

  • Para los grupos de instancias, los NEGs zonales y los NEG de conectividad híbrida, todos los backends deben estar ubicados en el mismo proyecto y región que el servicio de backend. Sin embargo, un balanceador de cargas puede hacer referencia a un backend que usa una red de VPC diferente en el mismo proyecto que el servicio de backend. La conectividad entre la red de VPC del balanceador de cargas y la red de VPC del backend se puede configurar mediante el intercambio de tráfico entre redes de VPC, túneles de Cloud VPN o adjuntos de VLAN de Cloud Interconnect.

    Definición de la red de backend

    • En el caso de los NEGs zonales y los híbridos, debes especificar de forma explícita la red de VPC cuando creas el NEG.
    • En los grupos de instancias administrados, la red de VPC se define en la plantilla de instancias.
    • En los grupos de instancias no administrados, la red de VPC del grupo de instancias se configura para que coincida con la red de VPC de la interfaz nic0 de la primera VM que se agrega al grupo de instancias.

    Requisitos de red del backend

    La red de tu backend debe satisfacer uno de los siguientes requisitos de red:

    • La red de VPC del backend debe coincidir exactamente con la red de VPC de la regla de reenvío.

    • La red de VPC del backend debe estar conectada a la red de VPC de la regla de reenvío mediante el intercambio de tráfico entre redes de VPC. Debes configurar intercambios de rutas de subred para permitir la comunicación entre la subred de solo proxy en la red de VPC de la regla de reenvío y las subredes que usan las instancias o los extremos de backend.

  • Para todos los demás tipos de backends, todos deben estar ubicados en la misma red de VPC y región.

Interfaces de red y backends

Si usas backends de grupos de instancias, los paquetes siempre se entregan a nic0. Si quieres enviar paquetes a interfaces que no son de nic0 (ya sean vNICs o interfaces de red dinámicas), usa backends de NEG en su lugar.

Si usas backends de NEG zonales, los paquetes se envían a cualquier interfaz de red que represente el extremo en el NEG. Los extremos del NEG deben estar en la misma red de VPC que la red de VPC definida explícitamente en el NEG.

Subconjuntos de backend

La subdivisión de backends es una función opcional compatible con los balanceadores de cargas de aplicaciones internos regionales que mejora el rendimiento y la escalabilidad asignando un subconjunto de backends a cada una de las instancias de proxy.

De forma predeterminada, la subdivisión del backend está inhabilitada. Si deseas obtener información para habilitar esta función, consulta Subconjunto del backend para los balanceadores de cargas de aplicaciones internos regionales.

Verificaciones de estado

Cada servicio de backend especifica una verificación de estado que supervisa de manera periódica la preparación de los backends para recibir una conexión del balanceador de cargas. Esto reduce el riesgo de que las solicitudes se envíen a backends que no pueden procesar la solicitud. Las verificaciones de estado no verifican si la aplicación en sí funciona.

Si quieres que los sondeos de verificación de estado sean exitosos, debes crear una regla de firewall de permiso de entrada que permita que los sondeos lleguen a tus instancias de backend. Por lo general, los sondeos de verificación de estado se originan a partir del mecanismo centralizado de verificación de estado de Google. Sin embargo, para los NEGs híbridos, las verificaciones de estado se originan a partir de la subred de solo proxy. Para obtener más detalles, consulta Verificaciones de estado de Envoy distribuidas.

Protocolo de verificación de estado

Aunque no es obligatorio y no siempre es posible, se recomienda usar una verificación de estado cuyo protocolo coincida con el protocolo del servicio de backend. Por ejemplo, una verificación de estado HTTP/2 comprueba de forma más precisa la conectividad HTTP/2 con los backends. Por el contrario, los balanceadores de cargas de aplicaciones internos que usan backends de NEG híbridos no admiten verificaciones de estado de gRPC. Para obtener la lista de protocolos de verificación de estado compatibles, consulta las funciones de balanceo de cargas en la sección Verificaciones de estado.

En la siguiente tabla, se especifica el alcance de las verificaciones de estado que admiten los balanceadores de cargas de aplicaciones internos:

Modo de balanceador de cargas Tipo de verificación de estado
Balanceador de cargas de aplicaciones interno regional regionHealthChecks

Para obtener más información sobre las verificaciones de estado, consulta los siguientes vínculos:

Reglas de firewall

Un balanceador de cargas de aplicaciones interno requiere las siguientes reglas de firewall:

  • Una regla de permiso de entrada que permita el tráfico de los rangos de verificación de estado central de Google. Para obtener más información sobre los rangos de direcciones IP específicos de los sondeos de verificación de estado y por qué es necesario permitir el tráfico de ellos, consulta Rangos de IP del sondeo y reglas de firewall.
  • Una regla de permiso de entrada que permita el tráfico de la subred de solo proxy.

Existen ciertas excepciones a los requisitos de las reglas de firewall para estos rangos:

  • No se requiere permitir el tráfico de los rangos de sondeo de verificación de estado de Google para los NEG híbridos. Sin embargo, si usas una combinación de NEG híbridos y zonales en un solo servicio de backend, debes permitir el tráfico de los rangos de sondeo de verificación de estado de Google para los NEG zonales.
  • Para los NEG de Internet regionales, las verificaciones de estado son opcionales. El tráfico de los balanceadores de cargas que usan NEGs de Internet regionales se origina desde la subred de solo proxy y, luego, se traduce con NAT (mediante Cloud NAT) a cualquiera de las direcciones IP de NAT asignadas manual o automáticamente. Este tráfico incluye sondeos de verificación de estado y solicitudes de usuario del balanceador de cargas a los backends. Para obtener más detalles, consulta NEG regionales: Usa una puerta de enlace de Cloud NAT.

Acceso del cliente

Los clientes pueden estar en la misma red o en una red de VPC conectada mediante el intercambio de tráfico entre redes de VPC.

Para los balanceadores de cargas de red de aplicaciones interno regional, los clientes deben estar en la misma región que el balanceador de cargas de forma predeterminada. Puedes habilitar el acceso global para permitir que los clientes de cualquier región de una VPC accedan al balanceador de cargas.

En la siguiente tabla, se resume el acceso del cliente para los balanceadores de cargas de aplicaciones internos regionales:

Acceso global inhabilitado Acceso global habilitado
Los clientes deben estar en la misma región que el balanceador de cargas. También deben estar en la misma red de VPC que el balanceador de cargas o en una red de VPC que esté conectada a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC. Los clientes pueden estar en cualquier región. Aún deben estar en la misma red de VPC que el balanceador de cargas o en una red de VPC que esté conectada a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC.
Los clientes locales pueden acceder al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de VLAN. Estos túneles o adjuntos deben estar en la misma región que el balanceador de cargas. Los clientes locales pueden acceder al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de VLAN. Estos túneles o adjuntos pueden estar en cualquier región.

Compatibilidad con GKE

GKE usa balanceadores de cargas de aplicaciones internos de las siguientes maneras:

  • Las puertas de enlace internas creadas con el controlador de GKE Gateway pueden usar cualquier modo de un balanceador de cargas de aplicaciones interno. Puedes controlar el modo del balanceador de cargas eligiendo un objeto GatewayClass. El controlador de la puerta de enlace de GKE siempre usa back-ends de NEG zonales GCE_VM_IP_PORT.

  • Los objetos Ingress internos creados con el controlador de Ingress de GKE siempre son balanceadores de cargas de aplicaciones internos regionales. El controlador de Ingress de GKE siempre usa backends de NEG zonales de GCE_VM_IP_PORT.

Arquitecturas de VPC compartida

Los balanceadores de cargas de aplicaciones internos admiten redes que usan VPC compartida. Con la VPC compartida, las organizaciones pueden conectar recursos de varios proyectos a una red de VPC común a fin de que puedan comunicarse entre ellas de forma segura y eficiente mediante las IP internas de esa red. Si aún no estás familiarizado con la VPC compartida, lee la Documentación de la descripción general de la VPC compartida.

Hay muchas formas de configurar un balanceador de cargas de aplicaciones interno dentro de una red de VPC compartida. Sin importar el tipo de implementación, todos los componentes del balanceador de cargas deben estar en la misma organización.

Subredes y dirección IP Componentes de frontend Componentes de backend

Crea la red y las subredes requeridas (incluida la subred de solo proxy) en el proyecto host de la VPC compartida.

La dirección IP interna del balanceador de cargas se puede definir en el proyecto host o en un proyecto de servicio, pero debe usar una subred en la red de VPC compartida deseada del host. La dirección en sí proviene del rango de IP principal de la subred a la que se hace referencia.

 La dirección IP interna regional, la regla de reenvío, el proxy HTTP(S) de destino y el mapa de URL asociado deben definirse en el mismo proyecto. Este proyecto puede ser un proyecto host o un proyecto de servicio. Puedes realizar una de las siguientes acciones:
  • Crea servicios de backend y backends (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en el mismo proyecto de servicio que los componentes del frontend.
  • Crea servicios de backends y backends (grupos de instancias, NEG sin servidores o cualquier otro tipo de backend compatible) en tantos proyectos de servicio como sea necesario. Un solo mapa de URL puede hacer referencia a servicios de backend en diferentes proyectos. Este tipo de implementación se conoce como referencia de servicio entre proyectos.

Cada servicio de backend debe definirse en el mismo proyecto que los backends a los que hace referencia. Las verificaciones de estado relacionadas con los servicios de backend deben definirse en el mismo proyecto que los servicios de backend.

Si bien puedes crear todos los componentes y backends del balanceo de cargas en el proyecto host de la VPC compartida, este tipo de implementación no separa las responsabilidades de administración de red y de desarrollo de servicios.

Todos los componentes y backends del balanceador de cargas en un proyecto de servicio

En el siguiente diagrama de arquitectura, se muestra una implementación de VPC compartida estándar en la que todos los componentes y backends del balanceador de cargas se encuentran en un proyecto de servicio. Este tipo de implementación es compatible con todos los balanceadores de cargas de aplicaciones.

El balanceador de cargas usa direcciones IP y subredes del proyecto host. Los clientes pueden acceder a un balanceador de cargas de aplicaciones interno si están en la misma región y red de VPC compartida que el balanceador de cargas. Los clientes pueden estar ubicados en el proyecto host o en un proyecto de servicio adjunto, o en cualquier red conectada.

Balanceador de cargas de aplicaciones interno en la red de VPC compartida
Balanceador de cargas de aplicaciones interno en la red de VPC compartida (haz clic para ampliar).

Backends sin servidores en un entorno de VPC compartida

Para un balanceador de cargas de aplicaciones interno que usa un backend de NEG sin servidores, el servicio de copia de seguridad de Cloud Run debe estar en el mismo proyecto de servicio que el servicio de backend y el NEG sin servidores. Los componentes de frontend del balanceador de cargas (regla de reenvío, proxy de destino y mapa de URL) se pueden crear en el proyecto host, en el mismo proyecto de servicio que los componentes de backend o en cualquier otro proyecto de servicio del mismo entorno de VPC compartida.

Referencia del servicio entre proyectos

La referencia de servicio entre proyectos es un modelo de implementación en el que el frontend y el mapa de URL del balanceador de cargas se encuentran en un proyecto, y el servicio de backend y los backends del balanceador de cargas se encuentran en un proyecto diferente.

La referencia a servicios entre proyectos permite a las organizaciones configurar un balanceador de cargas central y enrutar el tráfico a cientos de servicios distribuidos en varios proyectos diferentes. Puedes administrar de forma centralizada todas las reglas y las políticas de enrutamiento de tráfico en un mapa de URL. También puedes asociar el balanceador de cargas con un solo conjunto de nombres de host y certificados SSL. Por lo tanto, puedes optimizar la cantidad de balanceadores de cargas necesarios para implementar tu aplicación y reducir la administración, los costos operativos y los requisitos de cuota.

Si tienes proyectos diferentes para cada uno de los equipos funcionales, también puedes lograr la separación de los roles dentro de la organización. Los propietarios del servicio pueden enfocarse en compilar servicios en proyectos de servicio, mientras que los equipos de red pueden aprovisionar y mantener balanceadores de cargas en otro proyecto, y ambos se pueden conectar a través de referencias de servicios entre proyectos.

Los propietarios del servicio pueden mantener la autonomía sobre la exposición de sus servicios y controlar qué usuarios pueden acceder a sus servicios a través de el balanceador de cargas. Esto se logra mediante un rol especial de IAM llamado rol de usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser).

En el caso de los balanceadores de cargas de aplicaciones internos, la referencia de servicios entre proyectos solo se admite en entornos de VPC compartida.

Si deseas obtener información para configurar la VPC compartida para un balanceador de cargas de aplicaciones interno (con y sin referencias de servicios entre proyectos), consulta Configura un balanceador de cargas de aplicaciones interno con VPC compartida.

Notas de uso para la referencia del servicio entre proyectos

  • No puedes hacer referencia a un servicio de backend entre proyectos si el servicio de backend tiene backends de NEG de Internet regionales. El resto de los tipos de backend son compatibles.
  • Trusted Cloud no diferencia entre los recursos (por ejemplo, los servicios de backend) que usan el mismo nombre en varios proyectos. Por lo tanto, cuando usas la referencia de servicios entre proyectos, te recomendamos que uses nombres de servicio de backend únicos en todos los proyectos de tu organización.

Ejemplo 1: frontend y backend del balanceador de cargas en diferentes proyectos de servicio

Este es un ejemplo de una implementación de VPC compartida en la que se crean el frontend y el mapa de URL del balanceador de cargas en el proyecto de servicio A, y el mapa de URL hace referencia a un servicio de backend en el proyecto de servicio B.

En este caso, los administradores de red o del balanceador de cargas en el proyecto de servicio A requieren acceso a los servicios de backend en el proyecto de servicio B. Los administradores del proyecto de servicio B otorgan el rol Usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser) a los administradores del balanceador de cargas en el proyecto de servicio A que desean hacer referencia al servicio de backend en el proyecto de servicio B.

Frontend y mapa de URL del balanceador de cargas en el proyecto de servicio
Frontend y backend del balanceador de cargas en diferentes proyectos de servicio (haz clic para ampliar).

Ejemplo 2: frontend del balanceador de cargas en el proyecto host y backends en proyectos de servicio

Este es un ejemplo de una implementación de VPC compartida en la que se crean el frontend y el mapa de URL del balanceador de cargas en el proyecto host, y los servicios de backend (y los backends) se crean en los proyectos de servicio.

En este caso, los administradores de red o del balanceador de cargas en el proyecto host requieren acceso a los servicios de backend en el proyecto de servicio. Los administradores de proyectos de servicio otorgan el rol Usuario de servicios del balanceador de cargas de Compute (roles/compute.loadBalancerServiceUser) a los administradores del balanceador de cargas en el proyecto host A que desean hacer referencia al servicio de backend en el proyecto de servicio.

Frontend del balanceador de cargas y mapa de URL en el proyecto host
Frontend del balanceador de cargas y mapa de URL en el proyecto host (haz clic para ampliar).

Tiempos de espera y reintentos

Los balanceadores de cargas de aplicaciones internos admiten los siguientes tipos de tiempos de espera:

Tipo de tiempo de espera y descripción Valores predeterminados Admite valores personalizados
Tiempo de espera del servicio de backend

Un tiempo de espera de solicitud y respuesta Representa la cantidad máxima de tiempo que puede transcurrir entre el momento en que el balanceador de cargas envía el primer byte de una solicitud al backend y el momento en que el backend devuelve el último byte de la respuesta HTTP al balanceador de cargas. Si el backend no devolvió la respuesta HTTP completa al balanceador de cargas dentro de este límite de tiempo, se descartan los datos de respuesta restantes.
  • Para los NEGs sin servidores en un servicio de backend: 60 minutos
  • Para todos los demás tipos de backend en un servicio de backend: 30 segundos
Tiempo de espera de keepalive de HTTP del cliente

La cantidad máxima de tiempo en que la conexión TCP entre un cliente y el proxy de Envoy administrado por el balanceador de cargas puede estar inactivo. (se puede usar la misma conexión TCP para varias solicitudes HTTP).

 610 segundos
Tiempo de espera de keepalive de HTTP del backend

Es la cantidad máxima de tiempo que la conexión TCP entre el proxy de Envoy administrado por el balanceador de cargas y un backend puede estar inactiva. (se puede usar la misma conexión TCP para varias solicitudes HTTP).

 10 minutos (600 segundos)

Tiempo de espera del servicio de backend

El tiempo de espera del servicio de backend configurable representa la cantidad máxima de tiempo que el balanceador de cargas espera que el backend procese una solicitud HTTP y devuelva la respuesta HTTP correspondiente. Excepto por los NEG sin servidores, el valor predeterminado para el tiempo de espera del servicio de backend es de 30 segundos.

Por ejemplo, si quieres descargar un archivo de 500 MB y el valor del tiempo de espera del servicio de backend es de 90 segundos, el balanceador de cargas espera que el backend entregue todo el archivo de 500 MB en 90 segundos. Es posible configurar el tiempo de espera del servicio de backend para que no sea suficiente para que el backend envíe su respuesta HTTP completa. En esta situación, si el balanceador de cargas al menos recibió encabezados de respuesta HTTP, el balanceador de cargas devuelve los encabezados de respuesta completos y todo el cuerpo de respuesta que pudo obtener dentro del tiempo de espera del servicio de backend.

Te recomendamos que establezcas el tiempo de espera del servicio de backend en el tiempo más largo que esperas que tu backend necesite para procesar una respuesta HTTP. Si el software que se ejecuta en el backend necesita más tiempo para procesar una solicitud HTTP y devolver su respuesta completa, te recomendamos que aumentes el tiempo de espera del servicio de backend.

El tiempo de espera del servicio de backend acepta valores entre 1 y 2,147,483,647 segundos; sin embargo, los valores más grandes no son opciones de configuración prácticas.Trusted Cloud tampoco garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend. Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.

Para las conexiones de WebSocket que se usan con balanceadores de cargas de aplicaciones internos, las conexiones de WebSocket activas no siguen el tiempo de espera del servicio de backend. Las conexiones de WebSockets inactivas se cierran después del tiempo de espera del servicio de backend.

Trusted Cloud reinicia o cambia la cantidad de tareas de software de Envoy de forma periódica. Mientras más largo sea el valor de tiempo de espera del servicio de backend, más probable es que los reinicios o reemplazos de tareas de Envoy finalicen las conexiones TCP.

Para configurar el tiempo de espera del servicio de backend, usa uno de los siguientes métodos:

Console

Modifica el campo Tiempo de espera del servicio de backend del balanceador de cargas.

gcloud

Usa el comando gcloud compute backend-services update para modificar el parámetro --timeout del recurso de servicio de backend.

API

Modifica el parámetro timeoutSec para el recurso regionBackendServices

Tiempo de espera de keepalive de HTTP del cliente

El tiempo de espera de keepalive de HTTP del cliente representa la cantidad máxima de tiempo que una conexión TCP puede estar inactiva entre el cliente (en sentido descendente) y un proxy de Envoy. El valor predeterminado del tiempo de espera de keepalive de HTTP del cliente es de 610 segundos. Puedes configurar el tiempo de espera con un valor entre 5 y 1,200 segundos.

El tiempo de espera de keepalive de HTTP también se denomina tiempo de espera de TCP inactivo.

El tiempo de espera de keepalive del cliente HTTP del balanceador de cargas debe ser mayor que el tiempo de espera de keepalive de HTTP (TCP inactivo) que usan los clientes o proxies descendentes. Si un cliente descendente tiene un tiempo de espera de keepalive de HTTP (TCP inactivo) mayor que el del cliente HTTP del balanceador de cargas, es posible que se produzca una condición de carrera. Desde la perspectiva de un cliente descendente, una conexión TCP establecida puede estar inactiva durante más tiempo del que permite el balanceador de cargas. Esto significa que el cliente descendente puede enviar paquetes después de que el balanceador de cargas considera que la conexión TCP está cerrada. Cuando eso sucede, el balanceador de cargas responde con un paquete de restablecimiento de TCP (RST).

Cuando vence el tiempo de espera de keepalive de HTTP del cliente, el GFE o el proxy de Envoy envían un TCP FIN al cliente para cerrar la conexión de forma correcta.

Tiempo de espera de keepalive de HTTP del backend

Los balanceadores de cargas de aplicaciones internos son proxies que usan una primera conexión TCP entre el cliente (descendiente) y un proxy de Envoy, y una segunda conexión TCP entre el proxy de Envoy y los backends.

Es posible que las conexiones TCP secundarias del balanceador de cargas no se cierren después de cada solicitud; pueden permanecer abiertos para manejar varias solicitudes y respuestas HTTP. El tiempo de espera del keepalive de HTTP de backend define el tiempo de espera de inactividad de TCP entre el balanceador de cargas y los backends. El tiempo de espera de keepalive de HTTP de backend no se aplica a websockets.

El tiempo de espera de keepalive del backend se fija en 10 minutos (600 segundos) y no se puede cambiar. Esto ayuda a garantizar que el balanceador de cargas mantenga las conexiones inactivas durante al menos 10 minutos. Después de este período, el balanceador de cargas puede enviar paquetes de finalización al backend en cualquier momento.

El tiempo de espera del keepalive del backend del balanceador de cargas debe ser menor que el que usa el software que se ejecuta en los backends. Esto evita una condición de carrera en la que el sistema operativo de los backends puede cerrar las conexiones TCP con un restablecimiento TCP (RST). Debido a que no se puede configurar el tiempo de espera de keepalive del backend para el balanceador de cargas, debes configurar el software de backend para que el valor de tiempo de espera de keepalive de HTTP (TCP inactivo) sea superior a 600 segundos.

Cuando vence el tiempo de espera de keepalive de HTTP de backend, el GFE o el proxy de Envoy envían un TCP FIN a la VM de backend para cerrar la conexión de forma correcta.

En la siguiente tabla, se enumeran los cambios necesarios para modificar los valores de tiempo de espera de keepalive para el software del servidor web común.

Software de servidor web Parámetro Parámetro de configuración predeterminado Configuración recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Reintentos

Para configurar los reintentos, puedes usar una política de reintentos en el mapa de URL. La cantidad predeterminada de reintentos (numRetries) es 1. El perTryTimeout máximo configurable es de 24 horas.

Sin una política de reintento, las solicitudes fallidas que no tienen cuerpo HTTP (por ejemplo, solicitudes GET) que dan como resultado respuestas HTTP 502, 503 o 504 se reintentan una vez.

Las solicitudes HTTP POST no se reintentan.

Las solicitudes que se reintentaron solo generan una entrada de registro para la respuesta final.

Para obtener más información, consulta Registro y supervisión del balanceador de cargas de aplicaciones interno.

Accede a redes conectadas

Tus clientes pueden acceder a un balanceador de cargas de aplicaciones interno en tu red de VPC desde una red conectada mediante el siguiente procedimiento:

  • Intercambio de tráfico entre redes de VPC
  • Cloud VPN y Cloud Interconnect

Para ver ejemplos detallados, consulta Balanceadores de cargas de aplicaciones internos y redes conectadas.

Afinidad de sesión

La afinidad de sesión, configurada en el servicio de backend de los balanceadores de cargas de aplicaciones, hace su mejor esfuerzo para enviar solicitudes de un cliente en particular al mismo backend, siempre que la cantidad de instancias o extremos de backend en buen estado permanezca constante y siempre que la instancia o el extremo de backend seleccionado no esté al máximo de su capacidad. La capacidad de destino del modo de balanceo determina cuándo el backend alcanza el máximo de su capacidad.

En la siguiente tabla, se describen los diferentes tipos de opciones de afinidad de sesión admitidas para los distintos balanceadores de cargas de aplicaciones. En la siguiente sección, Tipos de afinidad de sesión, se analiza cada tipo de afinidad de sesión con más detalle.

Tabla: Configuración de afinidad de sesión compatible
Producto Opciones de afinidad de sesión
  • Ninguno (NONE)
  • IP de cliente (CLIENT_IP)
  • Cookie generada (GENERATED_COOKIE)
  • Campo de encabezado (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)
  • Afinidad basada en cookies con estado (STRONG_COOKIE_AFFINITY)

También ten en cuenta lo siguiente:

  • El valor predeterminado efectivo de la política de localidad del balanceo de cargas (localityLbPolicy) cambia según la configuración de afinidad de sesión. Si la afinidad de sesión no está configurada, es decir, si permanece en el valor predeterminado de NONE, el valor predeterminado para localityLbPolicy es ROUND_ROBIN. Si la afinidad de sesión se establece en un valor distinto de NONE, el valor predeterminado para localityLbPolicy es MAGLEV.
  • Para el balanceador de cargas de aplicaciones interno, no configures la afinidad de sesión si usas la división de tráfico ponderada. Si lo haces, la configuración de división de tráfico ponderada tiene prioridad.

Ten en cuenta lo siguiente cuando configures la afinidad de sesión:

  • No uses la afinidad de sesión para fines de autenticación o seguridad. La afinidad de sesión, excepto la afinidad de sesión basada en cookies con estado, se puede interrumpir cada vez que cambia la cantidad de backends activos y en buen estado. Para obtener más información, consulta Pérdida de afinidad de sesión.

  • Los valores predeterminados de las marcas --session-affinity y --subsetting-policy son NONE, y solo uno de ellos a la vez se puede establecer en un valor diferente.

Tipos de afinidad de sesión

La afinidad de sesión para los balanceadores de cargas de aplicaciones internos se puede clasificar en una de las siguientes categorías:
  • Afinidad de sesión basada en hash (NONE, CLIENT_IP)
  • Afinidad de sesión en función de encabezados HTTP (HEADER_FIELD)
  • Afinidad de sesión basada en cookies (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

Afinidad de sesión basada en hash

Para la afinidad de sesión basada en hash, el balanceador de cargas usa el algoritmo de hash coherente para seleccionar un backend apto. El parámetro de configuración de afinidad de sesión determina qué campos del encabezado IP se usan para calcular el hash.

La afinidad de sesión basada en hash puede ser de los siguientes tipos:

Ninguno

Un parámetro de configuración de afinidad de sesión de NONE no significa que no haya afinidad de sesión. Esto significa que no se configuró explícitamente ninguna opción de afinidad de sesión.

El hashing siempre se realiza para seleccionar un backend. Además, un parámetro de configuración de afinidad de sesión de NONE significa que el balanceador de cargas usa un hash de 5 tuplas para seleccionar un backend. El hash de 5 tuplas consta de la dirección IP de origen, el puerto de origen, el protocolo, la dirección IP de destino y el puerto de destino.

El valor predeterminado de la afinidad de sesión es NONE.

Afinidad de IP de cliente

La afinidad de sesión de IP de cliente (CLIENT_IP) es un hash de 2 tuplas creado a partir de las direcciones IP de origen y destino del paquete. La afinidad de IP de cliente reenvía todas las solicitudes de la misma dirección IP de cliente al mismo backend, siempre que ese backend tenga capacidad y se mantenga en buen estado.

Cuando uses la afinidad de IP de cliente, ten en cuenta lo siguiente:

  • La dirección IP de destino del paquete solo es la misma que la dirección IP de la regla de reenvío del balanceador de cargas si el paquete se envía directamente al balanceador de cargas.
  • Es posible que la dirección IP de origen del paquete no coincida con una dirección IP asociada al cliente original si un sistema intermedio de NAT o proxy procesa el paquete antes de que se entregue a un balanceador de cargas de Trusted Cloud . En situaciones en las que muchos clientes comparten la misma dirección IP de origen efectiva, algunas VMs de backend pueden recibir más conexiones o solicitudes que otras.

Afinidad de sesión en función de encabezados HTTP

Con la afinidad de campo de encabezado (HEADER_FIELD), las solicitudes se enrutan a los backends según el valor del encabezado HTTP en el campo consistentHash.httpHeaderName del servicio de backend. Para distribuir las solicitudes entre todos los backends disponibles, cada cliente debe usar un valor de encabezado HTTP diferente.

La afinidad de campo de encabezado es compatible cuando se cumplen las siguientes condiciones:

  • La política de localidad del balanceo de cargas es RING_HASH o MAGLEV.
  • El consistentHash del servicio de backend especifica el nombre del encabezado HTTP (httpHeaderName).

La afinidad de sesión basada en cookies puede ser de los siguientes tipos:

Cuando usas la afinidad basada en cookies generadas (GENERATED_COOKIE), el balanceador de cargas incluye una cookie HTTP en el encabezado Set-Cookie en respuesta a la solicitud HTTP inicial.

El nombre de la cookie generada varía según el tipo de balanceador de cargas.

Producto Nombre de cookie
Balanceadores de cargas de aplicaciones internos entre regiones GCILB
Balanceadores de cargas de aplicaciones internos regionales GCILB

El atributo de ruta de la cookie generada siempre es una barra (/), por lo que se aplica a todos los servicios de backend en el mismo mapa de URL, siempre que los otros servicios de backend también usen la afinidad de cookie generada.

Puedes configurar el valor de tiempo de actividad (TTL) de la cookie entre 0 y 1,209,600 segundos (inclusive) con el parámetro del servicio de backend affinityCookieTtlSec. Si no se especifica affinityCookieTtlSec, el valor predeterminado del TTL es 0.

Cuando el cliente incluye la cookie de afinidad de sesión generada en el encabezado de solicitud Cookie de las solicitudes HTTP, el balanceador de cargas dirige esas solicitudes a la misma instancia o extremo de backend, siempre que la cookie de afinidad de sesión siga siendo válida. Esto se hace asignando el valor de la cookie a un índice que hace referencia a una instancia de backend o un extremo específicos, y asegurándose de que se cumplan los requisitos de afinidad de sesión de la cookie generada.

Para usar la afinidad de cookie generada, configura los siguientes parámetros de configuración del modo de balanceo y de localityLbPolicy:

  • Para los grupos de instancias de backend, usa el modo de balanceo RATE.
  • Para el localityLbPolicy del servicio de backend, usa RING_HASH o MAGLEV. Si no estableces localityLbPolicy de forma explícita, el balanceador de cargas usa MAGLEV como valor predeterminado implícito.

Para obtener más información, consulta Pérdida de afinidad de sesión.

Cuando usas la afinidad basada en cookies HTTP (HTTP_COOKIE), el balanceador de cargas incluye una cookie HTTP en el encabezado Set-Cookie en respuesta a la solicitud HTTP inicial. Especificas el nombre, la ruta y el tiempo de actividad (TTL) de la cookie.

Todos los balanceadores de cargas de aplicaciones admiten la afinidad basada en cookies HTTP.

Puedes configurar los valores de TTL de la cookie con segundos, fracciones de segundo (como nanosegundos) o ambos (segundos y fracciones de segundo como nanosegundos) con los siguientes parámetros del servicio de backend y valores válidos:

  • consistentHash.httpCookie.ttl.seconds se puede establecer en un valor entre 0 y 315576000000 (inclusive).
  • consistentHash.httpCookie.ttl.nanos se puede establecer en un valor entre 0 y 999999999 (inclusive). Como las unidades son nanosegundos, 999999999 significa .999999999 segundos.

Si no se especifican consistentHash.httpCookie.ttl.seconds ni consistentHash.httpCookie.ttl.nanos, se usa el valor del parámetro del servicio de backend affinityCookieTtlSec. Si no se especifica affinityCookieTtlSec, el valor de TTL predeterminado es 0.

Cuando el cliente incluye la cookie de afinidad de sesión HTTP en el encabezado de solicitud Cookie de las solicitudes HTTP, el balanceador de cargas dirige esas solicitudes al mismo extremo o instancia de backend, siempre y cuando la cookie de afinidad de sesión siga siendo válida. Esto se hace asignando el valor de la cookie a un índice que hace referencia a una instancia de backend o un extremo específicos, y asegurándose de que se cumplan los requisitos de afinidad de sesión de la cookie generada.

Para usar la afinidad de cookie HTTP, configura el siguiente modo de balanceo y la configuración de localityLbPolicy:

  • Para los grupos de instancias de backend, usa el modo de balanceo RATE.
  • Para el localityLbPolicy del servicio de backend, usa RING_HASH o MAGLEV. Si no estableces localityLbPolicy de forma explícita, el balanceador de cargas usa MAGLEV como valor predeterminado implícito.

Para obtener más información, consulta Pérdida de afinidad de sesión.

Afinidad de sesión basada en cookies con estado

Cuando usas la afinidad basada en cookies con estado (STRONG_COOKIE_AFFINITY), el balanceador de cargas incluye una cookie HTTP en el encabezado Set-Cookie en respuesta a la solicitud HTTP inicial. Especificas el nombre, la ruta y el tiempo de actividad (TTL) de la cookie.

Los siguientes balanceadores de cargas admiten la afinidad basada en cookies con estado:

  • Balanceadores de cargas de aplicaciones regionales externos
  • Balanceadores de cargas de aplicaciones internos regionales

Puedes configurar los valores de TTL de la cookie con segundos, fracciones de segundo (como nanosegundos) o ambos (segundos y fracciones de segundo como nanosegundos). La duración representada por strongSessionAffinityCookie.ttl no se puede establecer en un valor que represente más de dos semanas (1,209,600 segundos).

El valor de la cookie identifica una instancia o un extremo de backend seleccionado mediante la codificación de la instancia o el extremo seleccionados en el valor. Mientras la cookie sea válida, si el cliente incluye la cookie de afinidad de sesión en el encabezado de solicitud Cookie de las solicitudes HTTP posteriores, el balanceador de cargas dirige esas solicitudes a la instancia o el extremo de backend seleccionados.

A diferencia de otros métodos de afinidad de sesión,

  • La afinidad basada en cookies con estado no tiene requisitos específicos para el modo de balanceo ni para la política de localidad del balanceo de cargas (localityLbPolicy).

  • La afinidad basada en cookies con estado no se ve afectada cuando el ajuste de escala automático agrega una instancia nueva a un grupo de instancias administrado.

  • La afinidad basada en cookies con estado no se ve afectada cuando el ajuste de escala automático quita una instancia de un grupo de instancias administrado a menos que se quite la instancia seleccionada.

  • La afinidad basada en cookies con estado no se ve afectada cuando la recuperación automática quita una instancia de un grupo de instancias administrado a menos que se quite la instancia seleccionada.

Para obtener más información, consulta Pérdida de afinidad de sesión.

Significado de TTL cero para las afinidades basadas en cookies

Todas las afinidades de sesión basadas en cookies, como la afinidad de cookie generada, la afinidad de cookie HTTP y la afinidad basada en cookies con estado, tienen un atributo TTL.

Un TTL de cero segundos significa que el balanceador de cargas no asigna un atributo Expires a la cookie. En este caso, el cliente trata la cookie como una cookie de sesión. La definición de una sesión varía según el cliente:

  • Algunos clientes, como los navegadores web, conservan la cookie durante toda la sesión de navegación. Esto significa que la cookie persiste en varias solicitudes hasta que se cierra la aplicación.

  • Otros clientes tratan una sesión como una sola solicitud HTTP y descartan la cookie inmediatamente después.

Pérdida de la afinidad de sesión

Todas las opciones de afinidad de sesión requieren lo siguiente:

  • La instancia o el extremo de backend seleccionados deben permanecer configurados como backend. La afinidad de sesión se puede interrumpir cuando ocurre uno de los siguientes eventos:
    • Quitas la instancia seleccionada de su grupo de instancias.
    • El ajuste de escala automático o la recuperación automática del grupo de instancias administrado quitan la instancia seleccionada de su grupo de instancias administrado.
    • Quitas el extremo seleccionado de su NEG.
    • Quitas del servicio de backend el grupo de instancias o el NEG que contiene la instancia o el extremo seleccionados.
  • La instancia o el extremo de backend seleccionados deben permanecer en buen estado. La afinidad de sesión se puede interrumpir cuando la instancia o el extremo seleccionados fallan en las verificaciones de estado.
A excepción de la afinidad de sesión basada en cookies con estado, todas las opciones de afinidad de sesión tienen los siguientes requisitos adicionales:

  • El grupo de instancias o el NEG que contiene la instancia o el extremo seleccionados no deben estar completos según su capacidad objetivo. (En el caso de los grupos de instancias administrados regionales, el componente zonal del grupo de instancias que contiene la instancia seleccionada no debe estar completo). La afinidad de sesión puede interrumpirse cuando el grupo de instancias o el NEG están llenos y otros grupos de instancias o NEG no lo están. Dado que la plenitud puede cambiar de formas impredecibles cuando se usa el modo de balanceo UTILIZATION, debes usar el modo de balanceo RATE o CONNECTION para minimizar las situaciones en las que se puede interrumpir la afinidad de sesión.

  • La cantidad total de instancias o extremos de backend configurados debe permanecer constante. Cuando se produce al menos uno de los siguientes eventos, cambia la cantidad de instancias o extremos de backend configurados, y se puede interrumpir la afinidad de sesión:

    • Agregar instancias o extremos nuevos:

      • Agrega instancias a un grupo de instancias existente en el servicio de backend.
      • El ajuste de escala automático del grupo de instancias administrado agrega instancias a un grupo de instancias administrado en el servicio de backend.
      • Agrega extremos a un NEG existente en el servicio de backend.
      • Agregas grupos de instancias o NEG no vacíos al servicio de backend.

    • Quitar cualquier instancia o extremo, no solo la instancia o el extremo seleccionados:

      • Quitas cualquier instancia de un backend de grupo de instancias.
      • El ajuste de escala automático o la recuperación automática de un grupo de instancias administrado quitan cualquier instancia de un backend de grupo de instancias administrado.
      • Quitas cualquier extremo de un backend de NEG.
      • Quita cualquier grupo de instancias de backend o NEG existente y no vacío del servicio de backend.

  • La cantidad total de instancias o extremos de backend en buen estado debe permanecer constante. Cuando ocurre al menos uno de los siguientes eventos, cambia la cantidad de instancias o extremos de backend en buen estado, y se puede interrumpir la afinidad de sesión:

    • Cualquier instancia o extremo pasa su verificación de estado y pasa de estar en mal estado a estar en buen estado.
    • Cualquier instancia o extremo falla su verificación de estado y pasa de estar en buen estado a estar en mal estado o con tiempo de espera agotado.

Conmutación por error

Si un backend se encuentra en mal estado, el tráfico se redireccionará de forma automática a los backends en buen estado.

En la siguiente tabla, se describe el comportamiento de la conmutación por error en cada modo:

Modo de balanceador de cargas Comportamiento de la conmutación por error Comportamiento cuando todos los backends están en mal estado
Balanceador de cargas de aplicaciones interno regional

Conmutación por error automática a backends en buen estado en la misma región.

El proxy de Envoy envía tráfico a backends en buen estado en una región según la distribución de tráfico configurada.

 Devuelve HTTP 503

Alta disponibilidad y conmutación por error entre regiones

Para balanceadores de cargas de aplicaciones internos regionales

Para lograr la alta disponibilidad, implementa varios balanceadores de cargas de aplicaciones internos regionales individuales en las regiones que mejor admitan el tráfico de tu aplicación. Luego, usa una política de enrutamiento de ubicación geográfica de Cloud DNS para detectar si un balanceador de cargas responde durante una interrupción regional. Una política de ubicación geográfica enruta el tráfico a la siguiente región disponible más cercana según el origen de la solicitud del cliente. La verificación de estado está disponible de forma predeterminada para los balanceadores de cargas de aplicaciones internos.

Compatible con WebSocket

Trusted Cloud Los balanceadores de cargas basados en HTTP(S) admiten el protocolo WebSocket cuando se usa HTTP o HTTPS como el protocolo para el backend. El balanceador de cargas no necesita ninguna configuración para usar un proxy en las conexiones de WebSocket.

El protocolo de WebSocket proporciona un canal de comunicación dúplex completo entre los clientes y el balanceador de cargas. Para obtener más información, consulta RFC 6455.

El protocolo WebSocket funciona de la siguiente manera:

  1. El balanceador de cargas reconoce una solicitud Upgrade de WebSocket de un cliente HTTP o HTTPS. La solicitud contiene los encabezados Connection: Upgrade y Upgrade: websocket, seguidos de otros encabezados de solicitud relevantes relacionados con WebSocket.
  2. El backend envía una respuesta Upgrade de WebSocket. La instancia de backend envía una respuesta 101 switching protocol con encabezados Connection: Upgrade y Upgrade: websocket, y otros encabezados de respuesta relacionados con WebSocket.
  3. El balanceador de cargas usa proxies para el tráfico bidireccional mientras dure la conexión actual.

Si la instancia de backend devuelve un código de estado 426 o 502, el balanceador de cargas cierra la conexión.

La afinidad de sesión para WebSockets funciona de la misma manera que en cualquier otra solicitud. Para obtener más información, consulta afinidad de sesión.

Compatibilidad con HTTP/2

HTTP/2 es una revisión importante del protocolo HTTP/1. Existen 2 modos de compatibilidad con HTTP/2:

  • HTTP/2 sobre TLS
  • Texto simple HTTP/2 a través de TCP

HTTP/2 sobre TLS

HTTP/2 a través de TLS es compatible con las conexiones entre los clientes y el balanceador de cargas de aplicaciones externo, y con las conexiones entre el balanceador de cargas y sus backends.

El balanceador de cargas negocia automáticamente HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS. Incluso si un balanceador de cargas está configurado para usar HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de cargas.

Si un cliente no admite HTTP/2 y el balanceador de cargas está configurado para usar HTTP/2 entre el balanceador de cargas y las instancias de backend, es posible que el balanceador de cargas aún negocie una conexión HTTPS o acepte solicitudes HTTP no seguras. Luego, el balanceador de cargas transforma esas solicitudes HTTPS o HTTP para representarlas a través de HTTP/2 en las instancias de backend.

Para usar HTTP/2 a través de TLS, debes habilitar TLS en tus backends y configurar el protocolo del servicio de backend enHTTP2. Para obtener más información, consulta Encriptación del balanceador de cargas a los backends.

Transmisiones simultáneas máximas de HTTP/2

La configuración de HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS describe el número máximo de transmisiones que acepta un extremo, que inicia el par. El valor que anuncia un cliente HTTP/2 a un balanceador de cargas deTrusted Cloud no tiene sentido, porque el balanceador de cargas no inicia transmisiones al cliente.

En los casos en que el balanceador de cargas usa HTTP/2 para comunicarse con un servidor que se ejecuta en una VM, el balanceador de cargas respeta el valor SETTINGS_MAX_CONCURRENT_STREAMS que anuncia el servidor. Si se anuncia un valor de cero, el balanceador de cargas no puede reenviar solicitudes al servidor y puede generar errores.

Limitaciones de HTTP/2

  • En comparación con HTTP o HTTPS, el uso de HTTP/2 entre el balanceador de cargas y la instancia puede requerir una cantidad significativamente mayor de conexiones TCP a la instancia. La agrupación de conexiones, una optimización que reduce la cantidad de conexiones con HTTP o HTTPS, no está disponible con HTTP/2. Como resultado, es posible que veas latencias de backend altas porque las conexiones de backend se realizan con más frecuencia.
  • El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la ejecución del protocolo WebSocket a través de una sola transmisión de conexión HTTP/2 (RFC 8441).
  • El uso de HTTP/2 entre el balanceador de cargas y el backend no admite la extracción de servidor.
  • La tasa de errores de gRPC y el volumen de solicitudes no son visibles en la API deTrusted Cloud ni en la consola de Trusted Cloud . Si el extremo de gRPC devuelve un error, los registros del balanceador de cargas y los datos de supervisión informan el código de estado HTTP 200 OK.

HTTP/2 de texto simple a través de TCP (H2C)

HTTP/2 de texto no encriptado a través de TCP, también conocido como H2C, te permite usar HTTP/2 sin TLS. H2C se admite para las siguientes conexiones:

  • Conexiones entre los clientes y el balanceador de cargas No se requiere ninguna configuración especial.

  • Conexiones entre el balanceador de cargas y sus backends

    Para configurar H2C para las conexiones entre el balanceador de cargas y sus backends, debes establecer el protocolo del servicio de backend en H2C.

La compatibilidad con H2C también está disponible para los balanceadores de cargas creados con el controlador de Gateway de GKE y Cloud Service Mesh.

H2C no es compatible con los balanceadores de cargas de aplicaciones clásicos.

Compatibilidad con gRPC

gRPC es un framework de código abierto para llamadas de procedimiento remoto. Se basa en el estándar HTTP/2. Los casos prácticos para gRPC incluyen lo siguiente:

  • Sistemas distribuidos altamente escalables y de baja latencia
  • Desarrollo de clientes móviles que se comuniquen con un servidor en la nube
  • Diseño de protocolos nuevos que deben ser precisos, independientes del lenguaje y eficientes
  • Diseño en capas para habilitar extensiones, autenticación y registros

Para usar gRPC con tus Trusted Cloud aplicaciones, debes enviar solicitudes proxy de extremo a extremo a través de HTTP/2. Para ello, crea un balanceador de cargas de aplicaciones con una de las siguientes configuraciones:

  • Para el tráfico sin encriptar de extremo a extremo (sin TLS): Crea un balanceador de cargas de HTTP (configurado con un proxy HTTP de destino). Además, puedes configurar el balanceador de cargas para que use HTTP/2 en las conexiones sin encriptar entre el balanceador de cargas y sus backends. Para ello, configura el protocolo del servicio de backend en H2C.

  • Para el tráfico encriptado de extremo a extremo (con TLS): Crea un balanceador de cargas HTTPS (configurado con un proxy HTTPS de destino y un certificado SSL). El balanceador de cargas negocia HTTP/2 con los clientes como parte del protocolo de enlace SSL a través de la extensión ALPN TLS.

    Además, debes asegurarte de que los backends puedan controlar el tráfico de TLS y configurar el balanceador de cargas para que use HTTP/2 en las conexiones encriptadas entre el balanceador de cargas y sus backends. Para ello, configura el protocolo del servicio de backend en HTTP2.

    Es posible que el balanceador de cargas aún negocie HTTPS con algunos clientes o acepte solicitudes HTTP no seguras en un balanceador de cargas configurado para usar HTTP/2 entre las instancias de backend y el balanceador de cargas. El balanceador de cargas transforma esas solicitudes HTTP o HTTPS para representar las solicitudes a través de HTTP/2 en las instancias de backend.

Compatibilidad con TLS

De forma predeterminada, un proxy HTTPS de destino solo acepta TLS 1.0, 1.1, 1.2 y 1.3 cuando finaliza las solicitudes SSL del cliente.

Cuando el balanceador de cargas de aplicaciones interno usa HTTPS como protocolo de servicio de backend, puede negociar TLS 1.2 o 1.3 con el backend.

Compatibilidad con TLS mutua

La TLS mutua, o mTLS, es un protocolo estándar de la industria para la autenticación mutua entre un cliente y un servidor. La mTLS ayuda a garantizar que tanto el cliente como el servidor se autentiquen mutuamente verificando que cada uno tenga un certificado válido emitido por una autoridad certificadora (CA) de confianza. A diferencia de la TLS estándar, en la que solo se autentica el servidor, la mTLS requiere que tanto el cliente como el servidor presenten certificados, lo que confirma las identidades de ambas partes antes de que se establezca la comunicación.

Todos los balanceadores de cargas de aplicaciones admiten mTLS. Con la mTLS, el balanceador de cargas solicita que el cliente envíe un certificado para autenticarse durante el protocolo de enlace de TLS con el balanceador de cargas. Puedes configurar un almacén de confianza del Administrador de certificados que el balanceador de cargas usará para validar la cadena de confianza del certificado de cliente.

Para obtener más información sobre mTLS, consulta Autenticación TLS mutua.

Limitaciones

  • No hay garantía de que la solicitud de un cliente en una zona de la región se envíe a un backend que se encuentre en la misma zona que el cliente. La afinidad de sesión no reduce la comunicación entre zonas.

  • Los balanceadores de cargas de aplicaciones internos no son compatibles con las siguientes características:

  • Para usar certificados del Administrador de certificados con balanceadores de cargas de aplicaciones internos, debes usar la API o gcloud CLI. La consola deTrusted Cloud no admite certificados de Certificate Manager.

  • Un balanceador de cargas de aplicaciones interno admite HTTP/2 solo a través de TLS.

  • Los clientes que se conectan a un balanceador de cargas de aplicaciones interno deben usar la versión 1.1 de HTTP o una versión posterior. HTTP 1.0 no es compatible.

  • Trusted Cloud no te advierte si tu subred de solo proxy se queda sin direcciones IP.

  • La regla de reenvío interno que usa el balanceador de cargas de aplicaciones interno debe tener exactamente un puerto.

  • Cuando se usa un balanceador de cargas de aplicaciones interno con Cloud Run en un entorno de VPC compartida, las redes de VPC independientes en proyectos de servicio pueden enviar tráfico a cualquier otro servicio de Cloud Run implementado en cualquier otro proyectos de servicio dentro del mismo entorno de VPC compartida. Este es un problema conocido.

  • Trusted Cloud no garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el valor del tiempo de espera del servicio de backend. Los sistemas cliente deben implementar la lógica de reintento en lugar de depender de una conexión TCP para estar abierta durante períodos prolongados.

¿Qué sigue?