Distribución de solicitudes para balanceadores de cargas de aplicaciones externos

En este documento, se profundiza en las complejidades de cómo los balanceadores de cargas de aplicaciones externos manejan las conexiones, enrutan el tráfico y mantienen la afinidad de sesión.

Cómo funcionan las conexiones

Los balanceadores de cargas de aplicaciones externos deTrusted Cloud, tanto globales como regionales, optimizan el enrutamiento con proxies distribuidos (GFE) o subredes administradas por Envoy. Con tiempos de espera configurables, finalización de TLS y seguridad integrada, garantizan la entrega de aplicaciones escalables y compatibles en todo el mundo o a nivel regional.

Conexiones del balanceador de cargas de aplicaciones externo regional

El balanceador de cargas de aplicaciones externo regional es un servicio administrado que se implementa en el proxy de Envoy. El balanceador de cargas de aplicaciones externo regional usa una subred compartida llamada subred de solo proxy para aprovisionar un conjunto de direcciones IP que Google usa para ejecutar proxies de Envoy en tu nombre. La marca --purpose para esta subred de solo proxy se configura como REGIONAL_MANAGED_PROXY. Todos los balanceadores de cargas basados en Envoy en una red y una región en particular comparten esta subred.

Los clientes usan la dirección IP y el puerto del balanceador de cargas para conectarse al balanceador de cargas. Las solicitudes del cliente se dirigen a la subred de solo proxy en la misma región que el cliente. El balanceador de cargas finaliza las solicitudes de los clientes y abre conexiones nuevas de la subred de solo proxy a tus backends. Por lo tanto, los paquetes enviados desde el balanceador de cargas tienen direcciones IP de origen de la subred de solo proxy.

Según la configuración del servicio de backend, el protocolo que usan los proxies de Envoy para conectarse a los backends puede ser HTTP, HTTPS o HTTP/2. Si es HTTP o HTTPS, la versión HTTP es HTTP 1.1. El keepalive de HTTP está habilitado de forma predeterminada, como se indica en la especificación HTTP 1.1. El proxy de Envoy establece el tiempo de espera de keepalive HTTP del cliente y el tiempo de espera de keepalive del backend en un valor predeterminado de 600 segundos cada uno. Puedes actualizar el tiempo de espera de keepalive HTTP del cliente, pero el valor del tiempo de espera de keepalive del backend es fijo. Puedes configurar el tiempo de espera de la solicitud o la respuesta a través de la configuración del tiempo de espera del servicio de backend. Para obtener más información, consulta Tiempos de espera y reintentos.

Comunicaciones del cliente con el balanceador de cargas

• Los clientes se pueden comunicar con el balanceador de cargas a través de el protocolo HTTP 1.1 o HTTP/2.
• Cuando se usa HTTPS, los clientes modernos usan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de cargas de HTTPS.
• No puedes inhabilitar HTTP/2 aunque realices un cambio de configuración en el balanceador de cargas. Sin embargo, puedes configurar algunos clientes para usar HTTP 1.1 en lugar de HTTP/2. Por ejemplo, con curl, usa el parámetro --http1.1.
• Los balanceadores de cargas de aplicaciones externos admiten la respuesta HTTP/1.1 100 Continue.

Para obtener una lista completa de los protocolos que admiten las reglas de reenvío del balanceador de cargas de aplicaciones externo en cada modo, consulta Funciones del balanceador de cargas.

Direcciones IP de origen para paquetes de clientes

La dirección IP de origen de los paquetes, como la ven los backends, no es la dirección IP externa del balanceador de cargas.Trusted Cloud En otras palabras, existen dos conexiones TCP.

Para los balanceadores de cargas de aplicaciones externos regionales:

• Conexión 1, desde el cliente original hasta el balanceador de cargas (subred de solo proxy):

  • Dirección IP de origen: Es el cliente original (o la dirección IP externa si el cliente está detrás de una puerta de enlace NAT o un proxy de reenvío).
  • Dirección IP de destino: Es la dirección IP del balanceador de cargas.

• Conexión 2, desde el balanceador de cargas (subred de solo proxy) hasta la VM o el extremo de backend:

  • Dirección IP de origen: Una dirección IP en la subred de solo proxy que se comparte entre todos los balanceadores de cargas basados en Envoy implementados en la misma región y la red que el balanceador de cargas.

  • Dirección IP de destino: Es la dirección IP interna del contenedor o la VM de backend en la red de VPC.

Rutas de acceso de enrutamiento especiales

Trusted Cloud usa rutas especiales no definidas en tu red de VPC para enrutar paquetes para los siguientes tipos de tráfico:

• Para las verificaciones de estado, excepto las verificaciones de estado distribuidas de Envoy. Si deseas obtener más información, consulta Rutas de acceso para las verificaciones de estado.

Trusted Cloud usa rutas de subred para subredes de solo proxy para enrutar paquetes para los siguientes tipos de tráfico:

• Cuando se usan verificaciones de estado distribuidas de Envoy

Para los balanceadores de cargas de aplicaciones externos regionales, Trusted Cloud usa proxies de Envoy de código abierto para finalizar las solicitudes de los clientes al balanceador de cargas. El balanceador de cargas finaliza la sesión TCP y abre una nueva sesión TCP desde la subred de solo proxy de la región a tu backend. Las rutas definidas dentro de la red de VPC facilitan la comunicación de los proxies de Envoy a los backends y de los backends a los proxies de Envoy.

finalización de TLS

En la siguiente tabla, se resume cómo los balanceadores de cargas de aplicaciones externos administran la finalización de TLS.

Modo de balanceador de cargas	finalización de TLS
Balanceador de cargas de aplicaciones externo regional	TLS finaliza en proxies de Envoy ubicados en una subred de solo proxy en una región elegida por el usuario. Usa este modo de balanceador de cargas si necesitas control geográfico sobre la región en la que se finaliza TLS.

Tiempos de espera y reintentos

Los balanceadores de cargas de aplicaciones externos admiten los siguientes tipos de tiempos de espera para el tráfico HTTP o HTTPS:

Tipo de tiempo de espera y descripción	Valores predeterminados	Admite valores de tiempo de espera personalizados
		Tiempo de espera del servicio de backend1 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 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 del balanceador de cargas puede estar inactivo. (Podría usarse la misma conexión TCP para varias solicitudes HTTP). Para los balanceadores de cargas de aplicaciones externos regionales, el proxy del balanceador de cargas es el software de Envoy.	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 del balanceador de cargas y un backend puede estar inactiva. (Podría usarse la misma conexión TCP para varias solicitudes HTTP). Para los balanceadores de cargas de aplicaciones externos regionales, el proxy del balanceador de cargas es el software de Envoy.	Para servicios de backend: 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. Por ejemplo, te recomendamos que aumentes el tiempo de espera si ves respuestas con el código de estado HTTP 408 y errores jsonPayload.statusDetail client_timed_out.

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 configurar el tiempo de espera del servicio de backend, usa uno de los siguientes métodos:

Los tiempos de espera de conexión de WebSocket no siempre son los mismos que los tiempos de espera del servicio de backend. Los tiempos de espera de conexión de WebSocket dependen del tipo de balanceador de cargas:

Modo de balanceador de cargas	Valores predeterminados	Descripción del tiempo de espera para WebSockets
Balanceador de cargas de aplicaciones externo regional	Tiempo de espera del servicio de backend: 30 segundos	Las conexiones de WebSocket activas no usan el tiempo de espera del servicio de backend del balanceador de cargas. Las conexiones de WebSocket inactivas se cierran después de que se agota el 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 las tareas de Envoy se reinicien o finalicen las conexiones TCP.

Los balanceadores de cargas de aplicaciones externos regionales usan el parámetro routeActions.timeout configurado de los mapas de URL y omiten el tiempo de espera del servicio de backend. Cuando no se configura routeActions.timeout, se usa el valor del tiempo de espera del servicio de backend. Cuando se proporciona routeActions.timeout, se ignora el tiempo de espera del servicio de backend y, en su lugar, se usa el valor de routeActions.timeout como el tiempo de espera de la solicitud y la respuesta.

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 (downstream) y uno de los siguientes tipos de proxies:

• Para un balanceador de cargas de aplicaciones externo regional: un proxy de Envoy

El tiempo de espera de keepalive de HTTP del cliente representa el tiempo de espera de inactividad de TCP para las conexiones TCP subyacentes. El tiempo de espera de keepalive de HTTP del cliente no se aplica a websockets.

El valor predeterminado para el tiempo de espera de keepalive de HTTP del cliente es de 610 segundos. En el caso de los balanceadores de cargas de aplicaciones externos globales y regionales, puedes configurar el tiempo de espera de keepalive de HTTP del cliente con un valor entre 5 y 1,200 segundos.

Para configurar el tiempo de espera de keepalive del cliente HTTP, usa uno de los siguientes métodos:

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 externos son proxies que usan al menos dos conexiones TCP:

• Para un balanceador de cargas de aplicaciones externo regional, existe una primera conexión TCP entre el cliente (downstream) y un proxy de Envoy. Luego, el proxy de Envoy abre una segunda conexión TCP a tus 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

La compatibilidad con la lógica de reintento depende del modo del balanceador de cargas de aplicaciones externo.

Modo de balanceador de cargas

Lógica de reintentos

Balanceador de cargas de aplicaciones externo regional

Se puede configurar a través de una política de reintento en el mapa de URL. La cantidad predeterminada de reintentos (numRetries) es 1. La cantidad máxima de reintentos que se pueden configurar con la política de reintentos es de 25. 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,GET solicitudes) que den 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.

El protocolo WebSocket es compatible con GKE Ingress.

Solicitud ilegal y manejo de respuestas

El balanceador de cargas impide que las solicitudes de cliente y las respuestas de backend lleguen al backend o al cliente, respectivamente, por varios motivos. Algunas razones son solo para el cumplimiento de HTTP/1.1 y otras para evitar que se pasen datos inesperados a los backends o desde ellos. No se puede inhabilitar ninguna de las verificaciones.

El balanceador de cargas bloquea las siguientes solicitudes para el cumplimiento de HTTP/1.1:

• No se puede analizar la primera línea de la solicitud.
• A un encabezado le falta el delimitador de dos punto :.
• Los encabezados o la primera línea contienen caracteres no válidos.
• La longitud del contenido no es un número válido o hay varios encabezados de longitud del contenido.
• Hay varias claves de codificación de transferencia o hay valores de codificación de transferencia no reconocidos.
• Hay un cuerpo no fragmentado y no se especifica la longitud del contenido.
• Los fragmentos del cuerpo no se pueden analizar. Este es el único caso en el que algunos datos llegan al backend. El balanceador de cargas cierra las conexiones con el cliente y el backend cuando recibe un fragmento no analizable.

Cómo administrar solicitudes

El balanceador de cargas bloquea la solicitud si se cumple alguna de las siguientes condiciones:

• El tamaño total de los encabezados y la URL de la solicitud supera el límite del tamaño máximo del encabezado de solicitud para los balanceadores de cargas de aplicaciones externos.
• El método de solicitud no permite un cuerpo, pero la solicitud tiene uno.
• La solicitud contiene un encabezado Upgrade. El encabezado Upgrade no se usa para habilitar las conexiones WebSocket.
• La versión HTTP es desconocida.

Control de respuestas

El balanceador de cargas bloquea la respuesta del backend si se cumple alguna de las siguientes condiciones:

• El tamaño total de los encabezados de respuesta supera el límite del tamaño máximo del encabezado de respuesta del balanceador de cargas de aplicaciones externo.
• La versión HTTP es desconocida.

Cuando se manejan la solicitud y la respuesta, el balanceador de cargas puede quitar o reemplazar los encabezados de salto por salto en HTTP/1.1 antes de reenviarlos al destino previsto.

Distribución del tráfico

Cuando agregas un grupo de instancias de backend o un NEG a un servicio de backend, debes especificar un modo de balanceo, que define un método que mide la carga de backend y una capacidad objetivo. Los balanceadores de cargas de aplicaciones externos admiten dos modos de balanceo:

• RATE, para grupos de instancias o NEG, es la cantidad máxima de solicitudes (consultas) de destino por segundo (RPS, QPS). Se puede exceder la cantidad máxima de RPS/QPS si se alcanza o supera la capacidad de todos los backends.

• UTILIZATION es el uso de backend de las VMs en un grupo de instancias.

La manera en que se distribuye el tráfico entre backends depende del modo del balanceador de cargas.

Balanceador de cargas de aplicaciones externo regional

Para los balanceadores de cargas de aplicaciones externos regionales, la distribución del tráfico se basa en el modo de balanceo de cargas y la política de localidad del balanceo de cargas.

El modo de balanceo determina el peso y la fracción del tráfico que se debe enviar a cada grupo (grupo de instancias o NEG). La política de localidad del balanceo de cargas (LocalityLbPolicy) determina cómo se balancean las cargas del backend dentro del grupo.

Cuando un servicio de backend recibe tráfico, primero lo dirige a un backend (grupo de instancias o NEG) según el modo de balanceo del backend. Después de seleccionar un backend, el tráfico se distribuye entre instancias o extremos en ese grupo de backend de acuerdo con la política de localidad del balanceo de cargas.

Para obtener más información, consulta lo siguiente:

• Modos de balanceo
• Política de balanceo de cargas de la localidad (documentación de la API de servicio de backend regional).

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

Balanceador de cargas de aplicaciones externo regional

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.

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 externos 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
• Afinidad de IP de cliente

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

Afinidad de sesión basada en cookies

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

• Afinidad de cookie generada
• Afinidad de cookie HTTP
• Afinidad de sesión basada en cookies con estado

Afinidad de cookie generada

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 externos globales	GCLB
Balanceadores de cargas de aplicaciones clásicos	GCLB
Balanceadores de cargas de aplicaciones regionales externos	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.

Afinidad de cookie HTTP

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, ocurre lo siguiente:

• 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 del 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.
• En el caso de los balanceadores de cargas de aplicaciones externos globales y los balanceadores de cargas de aplicaciones clásicos, la afinidad de sesión puede interrumpirse si se usa un Google Front End (GFE) de primera capa diferente para las solicitudes o conexiones posteriores después del cambio en la ruta de acceso de enrutamiento. Es posible que se seleccione un GFE de primera capa diferente si la ruta de acceso de enrutamiento de un cliente en Internet a Google cambia entre solicitudes o conexiones.

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.