Distribución de solicitudes para balanceadores de carga de aplicación externos

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

Cómo funcionan las conexiones

Los balanceadores de carga de aplicación externos deGoogle Cloud, tanto globales como regionales, optimizan el enrutamiento mediante proxies distribuidos (GFEs) o subredes gestionadas por Envoy. Gracias a los tiempos de espera configurables, la finalización de TLS y la seguridad integrada, garantizan una entrega de aplicaciones conforme y escalable en todo el mundo o en una región concreta.

Conexiones del balanceador de carga de aplicación externo global

Los balanceadores de carga de aplicación externos globales se implementan mediante muchos proxies llamados Google Front Ends (GFEs). No hay un solo proxy. En el nivel Premium, la misma dirección IP externa global se anuncia desde varios puntos de presencia y las solicitudes de los clientes se dirigen al GFE más cercano.

En función de dónde se encuentren tus clientes, varios GFE pueden iniciar conexiones HTTP(S) con tus backends. Los paquetes enviados desde los GFE tienen direcciones IP de origen del mismo intervalo que usan los verificadores de estado: 35.191.0.0/16 y 130.211.0.0/22.

.

En función de la configuración del servicio de backend, el protocolo que usa cada GFE para conectarse a tus backends puede ser HTTP, HTTPS o HTTP/2. En las conexiones HTTP o HTTPS, se usa la versión HTTP 1.1.

Keep-alive de HTTP está habilitado de forma predeterminada, tal como se especifica en la especificación de HTTP 1.1. Los keep-alives de HTTP intentan usar de forma eficiente la misma sesión TCP, pero no hay ninguna garantía. GFE usa un tiempo de espera de keep-alive HTTP de cliente de 610 segundos y un valor de tiempo de espera de keep-alive de backend predeterminado de 600 segundos. Puedes actualizar el tiempo de espera de keep-alive HTTP del cliente, pero el valor del tiempo de espera de keep-alive del backend es fijo. Puedes configurar el tiempo de espera de las solicitudes y las respuestas definiendo el tiempo de espera del servicio de backend. Aunque están estrechamente relacionados, el tiempo de espera inactivo de HTTP y el de TCP no son lo mismo. Para obtener más información, consulta tiempos de espera y reintentos.

Para asegurarse de que el tráfico se balancea de carga de forma uniforme, el balanceador de carga puede cerrar limpiamente una conexión TCP enviando un paquete FIN ACK después de completar una respuesta que incluya un encabezado Connection: close, o bien puede emitir un marco GOAWAY de HTTP/2 después de completar una respuesta. Este comportamiento no interfiere con ninguna solicitud ni respuesta activas.

El número de conexiones HTTP y sesiones TCP varía en función del número de GFE que se conecten, el número de clientes que se conecten a los GFE, el protocolo de los back-ends y dónde se implementen los back-ends.

Para obtener más información, consulta Cómo funcionan los balanceadores de carga de aplicación externos en la guía de soluciones Optimización de la capacidad de las aplicaciones con balanceo de carga global.

Conexiones de balanceadores de carga de aplicación externos regionales

El balanceador de carga de aplicación externo regional es un servicio gestionado implementado en el proxy Envoy. El balanceador de carga de aplicación 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 de esta subred de solo proxy tiene el valor REGIONAL_MANAGED_PROXY. Todos los balanceadores de carga regionales basados en Envoy de una red y una región concretas comparten esta subred.

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

En función de la configuración del servicio de backend, el protocolo que usan los proxies de Envoy para conectarse a tus backends puede ser HTTP, HTTPS o HTTP/2. Si es HTTP o HTTPS, la versión de HTTP es HTTP 1.1. Keep-Alive de HTTP está habilitado de forma predeterminada, tal como se especifica en la especificación de HTTP 1.1. El proxy de Envoy define el tiempo de espera de keep-alive de HTTP del cliente y el tiempo de espera de keep-alive del backend en un valor predeterminado de 600 segundos cada uno. Puedes actualizar el tiempo de espera de keep-alive de HTTP del cliente, pero el valor del tiempo de espera de keep-alive del backend es fijo. Puedes configurar el tiempo de espera de las solicitudes o respuestas configurando el 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 carga

• Los clientes pueden comunicarse con el balanceador de carga mediante los protocolos HTTP/1.0, HTTP/1.1, HTTP/2 o HTTP/3.
• Cuando se usa HTTPS, los clientes modernos utilizan HTTP/2 de forma predeterminada. Esto se controla en el cliente, no en el balanceador de carga HTTPS.
• No puedes inhabilitar HTTP/2 cambiando la configuración del balanceador de carga. Sin embargo, puedes configurar algunos clientes para que usen HTTP 1.1 en lugar de HTTP/2. Por ejemplo, con curl, usa el parámetro --http1.1.
• Los balanceadores de carga de aplicación externos admiten la respuesta HTTP/1.1 100 Continue.

Para ver la lista completa de protocolos admitidos por las reglas de reenvío de los balanceadores de carga de aplicaciones externos en cada modo, consulta las funciones de los balanceadores de carga.

Direcciones IP de origen de los paquetes de clientes

La dirección IP de origen de los paquetes, tal como la ven los backends, no es laGoogle Cloud dirección IP externa del balanceador de carga. En otras palabras, hay dos conexiones TCP.

En el caso de los balanceadores de carga de aplicación externos globales:

• Conexión 1, del cliente original al balanceador de carga (GFE):

  • Dirección IP de origen: el cliente original (o la dirección IP externa si el cliente está detrás de una pasarela NAT o un proxy de reenvío).
  • Dirección IP de destino: la dirección IP de tu balanceador de carga.

• Conexión 2, del balanceador de carga (GFE) a la máquina virtual o al endpoint de backend:

  • Dirección IP de origen: una dirección IP de uno de los intervalos especificados en Reglas de cortafuegos.

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

. En el caso de los balanceadores de carga de aplicación externos regionales:

• Conexión 1, del cliente original al balanceador de carga (subred de solo proxy):

  • Dirección IP de origen: el cliente original (o la dirección IP externa si el cliente está detrás de una pasarela NAT o un proxy de reenvío).
  • Dirección IP de destino: la dirección IP de tu balanceador de carga.

• Conexión 2, del balanceador de carga (subred de solo proxy) a la máquina virtual o el endpoint de backend:

  • Dirección IP de origen: una dirección IP de la subred solo proxy que comparten todos los balanceadores de carga basados en Envoy implementados en la misma región y red que el balanceador de carga.

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

Rutas especiales

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

• En el caso de las comprobaciones de estado, excepto las comprobaciones de estado de Envoy distribuidas. Para obtener más información, consulta Rutas de comprobaciones del estado.

• Entre las GFEs y los backends de los balanceadores de carga de aplicación externos globales y los balanceadores de carga de aplicación clásicos. Para obtener más información, consulta Rutas entre los front-ends y los back-ends de Google.

Google Cloud usa rutas de subred para subredes solo proxy con el fin de enrutar paquetes de los siguientes tipos de tráfico:

• Cuando se usan comprobaciones de estado de Envoy distribuidas.

En el caso de los balanceadores de carga de aplicación externos regionales, Google Cloud se usan proxies de Envoy de código abierto para finalizar las solicitudes de los clientes al balanceador de carga. El balanceador de carga finaliza la sesión TCP y abre una nueva sesión TCP desde la subred solo de proxy de la región hasta tu backend. Las rutas definidas en tu red de VPC facilitan la comunicación de los proxies Envoy a tus back-ends y de tus back-ends a los proxies Envoy.

Puertos abiertos

Los GFE tienen varios puertos abiertos para admitir otros servicios de Google que se ejecutan en la misma arquitectura. Cuando ejecutas un análisis de puertos, es posible que veas otros puertos abiertos de otros servicios de Google que se ejecutan en GFE.

Los balanceadores de carga basados en GFE (balanceadores de carga de aplicación externos globales y balanceadores de carga de aplicación clásicos) siempre muestran los puertos 80 y 443 como abiertos (junto con cualquier otro puerto que hayas configurado en las reglas de reenvío de tu balanceador de carga). Sin embargo, si no has configurado una regla de reenvío para el puerto 80 o el 443, se rechazarán todas las conexiones enviadas a esos puertos. Por el contrario, los balanceadores de carga de aplicación externos regionales se implementan mediante proxies Envoy y no muestran puertos abiertos adicionales durante un análisis.

No es útil realizar un análisis de puertos en la dirección IP de un balanceador de carga basado en GFE desde el punto de vista de la auditoría por los siguientes motivos:

• En un análisis de puertos (por ejemplo, con nmap), normalmente no se espera ningún paquete de respuesta o un paquete TCP RST al realizar un sondeo TCP SYN. Los GFE solo envían paquetes SYN-ACK en respuesta a las sondas SYN de los puertos en los que haya configurado una regla de reenvío. Los GFE solo envían paquetes a tus back-ends en respuesta a los paquetes enviados a la dirección IP de tu balanceador de carga y al puerto de destino configurado en su regla de reenvío. Los paquetes que se envían a una dirección IP o un puerto diferentes no se envían a tus back-ends.

  Los GFE implementan funciones de seguridad como Google Cloud Armor. Con Cloud Armor Standard, las GFEs ofrecen protección continua frente a ataques DDoS volumétricos y basados en protocolos, así como frente a inundaciones SYN. Esta protección está disponible aunque no hayas configurado Cloud Armor de forma explícita. Solo se te cobrará si configuras políticas de seguridad o si te registras en Managed Protection Plus.

• Los paquetes enviados a la dirección IP de tu balanceador de carga pueden responderse con cualquier GFE de la flota de Google. Sin embargo, al analizar una combinación de dirección IP y puerto de destino de un balanceador de carga, solo se interroga a un GFE por conexión TCP. La dirección IP de tu balanceador de carga no se asigna a un solo dispositivo o sistema. Por lo tanto, al analizar la dirección IP de un balanceador de carga basado en GFE, no se analizan todos los GFEs de la flota de Google.

Teniendo esto en cuenta, a continuación se indican algunas formas más eficaces de auditar la seguridad de tus instancias de backend:

• Un auditor de seguridad debe inspeccionar la configuración de las reglas de reenvío de la configuración del balanceador de carga. Las reglas de reenvío definen el puerto de destino para el que el balanceador de carga acepta paquetes y los reenvía a los backends. En los balanceadores de carga basados en GFE, cada regla de reenvío externa solo puede hacer referencia a un puerto TCP de destino. En el caso de un balanceador de carga que use el puerto TCP 443, se utiliza el puerto UDP 443 cuando la conexión se actualiza a QUIC (HTTP/3).

• Un auditor de seguridad debe inspeccionar la configuración de las reglas de cortafuegos aplicables a las VMs backend. Las reglas de cortafuegos que definas bloquearán el tráfico de los GFEs a las VMs de backend, pero no bloquearán el tráfico entrante a los GFEs. Para consultar las prácticas recomendadas, ve a la sección Reglas de cortafuegos.

cancelación de TLS

En la siguiente tabla se resume cómo gestionan la terminación de TLS los balanceadores de carga de aplicaciones externos.

Modo del balanceador de carga	cancelación de TLS
Balanceador de carga de aplicación externo global	TLS se termina en un GFE, que puede estar en cualquier parte del mundo.
Balanceador de carga de aplicación clásico	TLS se termina en un GFE, que puede estar en cualquier parte del mundo.
Balanceador de carga de aplicación externo regional	TLS se termina en los proxies de Envoy ubicados en una subred de solo proxy de una región elegida por el usuario. Usa este modo de balanceador de carga si necesitas controlar la región geográfica en la que se termina TLS.

Tiempos de espera y reintentos

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

Tipo y descripción del tiempo de espera	Valores predeterminados	Admite valores de tiempo de espera personalizados
		Global	Clásico	Regional
Tiempo de espera del servicio de backend1 Tiempo de espera de la solicitud y la respuesta. Representa el tiempo máximo permitido entre que el balanceador de carga envía el primer byte de una solicitud al backend y que el backend devuelve el último byte de la respuesta HTTP al balanceador de carga. Si el backend no ha devuelto toda la respuesta HTTP al balanceador de carga en este plazo, se descartarán los datos de respuesta restantes.	En el caso de los NEGs sin servidor de un servicio de backend, el tiempo es de 60 minutos. Para todos los demás tipos de backend de un servicio de backend: 30 segundos En el caso de los segmentos de backend,el plazo es de 24 horas (86.400 segundos).
Tiempo de espera de keep-alive HTTP del cliente Cantidad máxima de tiempo que puede estar inactiva la conexión TCP entre un cliente y el proxy del balanceador de carga. (Es posible que se use la misma conexión TCP para varias solicitudes HTTP). En el caso de los balanceadores de carga de aplicación externos globales y los balanceadores de carga de aplicación clásicos, el proxy del balanceador de carga es un GFE de primera capa. En el caso de los balanceadores de carga de aplicaciones externos regionales, el proxy del balanceador de carga es el software Envoy.	610 segundos
Tiempo de espera de keep-alive HTTP del backend Cantidad máxima de tiempo que puede estar inactiva la conexión TCP entre el proxy del balanceador de carga y un backend. (Es posible que se utilice la misma conexión TCP para varias solicitudes HTTP). En el caso de los balanceadores de carga de aplicación externos globales y los balanceadores de carga de aplicación clásicos, el proxy del balanceador de carga es un GFE de segunda capa. En el caso de los balanceadores de carga de aplicaciones externos regionales, el proxy del balanceador de carga es el software Envoy.	Servicios de backend: 10 minutos (600 segundos) En el caso de los segmentos de backend, 6 minutos (360 segundos)
Tiempo de espera de inactividad de la sesión QUIC Es el tiempo máximo que puede estar inactiva una sesión QUIC entre el cliente (descarga) y el GFE de un balanceador de carga de aplicación externo global o de un balanceador de carga de aplicación clásico.	En el caso de los balanceadores de carga de aplicación externos globales y los balanceadores de carga de aplicación clásicos: El tiempo de espera de inactividad de la sesión QUIC es el mínimo entre el tiempo de espera de inactividad del cliente y el tiempo de espera de inactividad de GFE (300 segundos). El tiempo de espera de inactividad de GFE es de 300 segundos. Se puede configurar el tiempo de espera del cliente.

Tiempo de espera del servicio de backend

El tiempo de espera del servicio de backend configurable representa el tiempo máximo que espera el balanceador de carga a que el backend procese una solicitud HTTP y devuelva la respuesta HTTP correspondiente. Excepto en los NEGs sin servidor, el valor predeterminado del tiempo de espera del servicio de backend es de 30 segundos.

Por ejemplo, si quiere descargar un archivo de 500 MB y el valor del tiempo de espera del servicio backend es de 90 segundos, el balanceador de carga espera que el backend entregue el archivo completo de 500 MB en 90 segundos. Es posible que el tiempo de espera del servicio de backend no sea suficiente para que el backend envíe su respuesta HTTP completa. En esta situación, si el balanceador de carga ha recibido al menos los encabezados de respuesta HTTP del backend, devuelve los encabezados de respuesta completos y la mayor parte posible del cuerpo de la respuesta que haya podido obtener durante el tiempo de espera del servicio de backend.

Te recomendamos que definas el tiempo de espera del servicio de backend como el periodo más largo que creas que tu backend necesitará para procesar una respuesta HTTP. Si el software que se ejecuta en tu backend necesita más tiempo para procesar una solicitud HTTP y devolver toda la respuesta, 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 con errores jsonPayload.statusDetail client_timed_out.

El tiempo de espera del servicio backend acepta valores entre 1 y 2,147,483,647 segundos. Sin embargo, los valores más altos no son opciones de configuración prácticas. Google Cloud tampoco garantiza que una conexión TCP subyacente pueda permanecer abierta durante todo el tiempo de espera del servicio backend. En el caso de los balanceadores de carga de aplicaciones globales y clásicos, las GFEs imponen un tiempo de espera máximo efectivo del servicio de backend de 86,400 segundos (1 día). Los sistemas cliente deben implementar una lógica de reintento en lugar de depender de que una conexión TCP esté abierta durante largos periodos.

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

Los tiempos de espera de las conexiones Websocket no siempre son los mismos que los de los servicios de backend. Los tiempos de espera de las conexiones Websocket dependen del tipo de balanceador de carga:

Modo del balanceador de carga	Valores predeterminados	Descripción del tiempo de espera de los websockets
Balanceador de carga de aplicación externo global	Tiempo de espera del servicio de backend: 30 segundos	Las conexiones WebSocket activas no usan el tiempo de espera del servicio de backend configurado del balanceador de carga. Las conexiones se cierran automáticamente al cabo de 24 horas (86.400 segundos). Este límite de 24 horas es fijo y anula el tiempo de espera del servicio de backend si es superior a 24 horas. Las conexiones websockets inactivas se cierran cuando se agota el tiempo de espera del servicio backend. No recomendamos usar valores de tiempo de espera del servicio backend superiores a 24 horas (86.400 segundos), ya que Google Cloud los GFE se reinician periódicamente para instalar actualizaciones de software y realizar otras tareas de mantenimiento rutinarias. El valor de tiempo de espera de tu servicio de backend no retrasa las actividades de mantenimiento. Cuanto mayor sea el valor del tiempo de espera del servicio de backend, más probable será que Google Cloudtermine las conexiones TCP por mantenimiento.
Balanceador de carga de aplicación clásico	Tiempo de espera del servicio de backend: 30 segundos	Las conexiones Websocket, tanto si están inactivas como activas, se cierran automáticamente cuando se agota el tiempo de espera del servicio backend. No recomendamos usar valores de tiempo de espera del servicio backend superiores a 24 horas (86.400 segundos), ya que Google Cloud los GFE se reinician periódicamente para instalar actualizaciones de software y realizar otras tareas de mantenimiento rutinarias. El valor de tiempo de espera de tu servicio de backend no retrasa las actividades de mantenimiento. Cuanto mayor sea el valor del tiempo de espera del servicio de backend, más probable será que Google Cloudtermine las conexiones TCP por mantenimiento.
Balanceador de carga de aplicación externo regional	Tiempo de espera del servicio de backend: 30 segundos	Las conexiones WebSocket activas no usan el tiempo de espera del servicio de backend del balanceador de carga. Las conexiones websockets inactivas se cierran cuando se agota el tiempo de espera del servicio backend. Google Cloud reinicia periódicamente o cambia el número de tareas de software de servicio de Envoy. Cuanto mayor sea el valor del tiempo de espera del servicio backend, más probable será que las tareas de Envoy se reinicien o que se terminen las conexiones TCP.

Los balanceadores de carga de aplicaciones externos regionales usan el parámetro routeActions.timeout configurado de los mapas de URLs e ignoran el tiempo de espera del servicio de backend. Si no se configura routeActions.timeout, se usa el valor del tiempo de espera del servicio backend. Cuando se proporciona routeActions.timeout, se ignora el tiempo de espera del servicio backend y se usa el valor de routeActions.timeout como tiempo de espera de la solicitud y la respuesta.

Tiempo de espera de keep-alive HTTP del cliente

El tiempo de espera de keep-alive HTTP del cliente representa el tiempo máximo que puede estar inactiva una conexión TCP entre el cliente (descendente) y uno de los siguientes tipos de proxies:

• En el caso de un balanceador de carga de aplicación externo global o un balanceador de carga de aplicación clásico, un Google Front End de primera capa

• En el caso de un balanceador de carga de aplicación externo regional, un proxy Envoy

El tiempo de espera de keep-alive HTTP del cliente representa el tiempo de espera de inactividad de TCP de las conexiones TCP subyacentes. El tiempo de espera de keep-alive HTTP del cliente no se aplica a los websockets.

El valor predeterminado del tiempo de espera de keep-alive HTTP del cliente es de 610 segundos. En el caso de los balanceadores de carga de aplicación externos globales y regionales, puedes configurar el tiempo de espera de keep-alive HTTP del cliente con un valor entre 5 y 1200 segundos.

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

El tiempo de espera de keep-alive de HTTP del cliente del balanceador de carga debe ser superior al tiempo de espera de keep-alive de HTTP (inactividad de TCP) que usan los clientes o proxies de nivel inferior. Si un cliente de nivel inferior tiene un tiempo de espera de keep-alive de HTTP (inactividad de TCP) mayor que el tiempo de espera de keep-alive de HTTP del cliente del balanceador de carga, es posible que se produzca una condición de carrera. Desde el punto de vista de un cliente de nivel inferior, se permite que una conexión TCP establecida esté inactiva durante más tiempo del permitido por el balanceador de carga. Esto significa que el cliente de nivel inferior puede enviar paquetes después de que el balanceador de carga considere que la conexión TCP está cerrada. Cuando esto ocurre, el balanceador de carga responde con un paquete de restablecimiento (RST) de TCP.

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

Tiempo de espera de keep-alive HTTP del backend

Los balanceadores de carga de aplicaciones externos son proxies que usan al menos dos conexiones TCP:

• En el caso de un balanceador de carga de aplicación externo global o un balanceador de carga de aplicación clásico, se establece una primera conexión TCP entre el cliente (descendente) y un GFE de primera capa. Los GFE de la primera capa se conectan a los GFE de la segunda capa, y estos abren una segunda conexión TCP a tus backends.

• En el caso de un balanceador de carga de aplicaciones externo regional, se establece una primera conexión TCP entre el cliente (descendente) y un proxy de Envoy. A continuación, el proxy de Envoy abre una segunda conexión TCP a tus back-ends.

Es posible que las conexiones TCP secundarias del balanceador de carga no se cierren después de cada solicitud, sino que permanezcan abiertas para gestionar varias solicitudes y respuestas HTTP. El tiempo de espera de keep-alive HTTP del backend define el tiempo de espera de inactividad de TCP entre el balanceador de carga y tus backends. El tiempo de espera de keep-alive HTTP del backend no se aplica a los websockets.

El tiempo de espera de mantenimiento activo del backend es de 10 minutos (600 segundos) y no se puede cambiar. De esta forma, se asegura de que el balanceador de carga mantenga las conexiones inactivas durante al menos 10 minutos. Después de este periodo, el balanceador de carga puede enviar paquetes de finalización al backend en cualquier momento.

El tiempo de espera de keepalive del backend del balanceador de carga debe ser inferior al tiempo de espera de keepalive que usa el software que se ejecuta en tus backends. De esta forma, se evita una condición de carrera en la que el sistema operativo de tus back-ends podría cerrar las conexiones TCP con un restablecimiento de TCP (RST). Como el tiempo de espera de keepalive del backend del balanceador de carga no se puede configurar, debes configurar el software de backend para que su valor de tiempo de espera de keepalive HTTP (inactividad de TCP) sea superior a 600 segundos.

Cuando caduca el tiempo de espera de keep-alive HTTP del backend, el GFE o el proxy Envoy envían un FIN TCP a la VM del backend para cerrar la conexión correctamente.

En la siguiente tabla se indican los cambios necesarios para modificar los valores de tiempo de espera de keep-alive en el software de servidor web habitual.

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

Tiempo de espera de inactividad de la sesión QUIC

El tiempo de espera inactivo de la sesión QUIC representa el tiempo máximo que puede estar inactiva una sesión QUIC entre el cliente y el GFE de un balanceador de carga de aplicación externo global o de un balanceador de carga de aplicación clásico.

El valor de tiempo de espera de inactividad de la sesión QUIC se define como el mínimo entre el tiempo de espera de inactividad del cliente y el tiempo de espera de inactividad de GFE (300 segundos). El tiempo de espera de inactividad de GFE es de 300 segundos. Se puede configurar el tiempo de espera de inactividad del cliente.

Reintentos

La compatibilidad con la lógica de reintento depende del modo del balanceador de carga de aplicación externo.

Modo del balanceador de carga	Lógica de reintento
Balanceador de carga de aplicación externo global	Se puede configurar mediante una política de reintentos en el mapa de URLs. El número máximo de reintentos (numRetries) que se puede configurar mediante la política de reintentos es 25. El perTryTimeout máximo configurable es de 24 horas. Si quieres inhabilitar los reintentos, debes definir explícitamente numRetries en 1. Si no hay una política de reintentos, las solicitudes incorrectas que no tengan un cuerpo HTTP (por ejemplo, las solicitudes GET) que den como resultado respuestas HTTP 502, 503 o 504 (retryConditions=["gateway-error"]) se reintentarán una vez. Las solicitudes HTTP POST no se vuelven a intentar. Las solicitudes reintentadas solo generan una entrada de registro para la respuesta final.
Balanceador de carga de aplicación clásico	La política de reintentos no se puede cambiar para los reintentos de conexión. Las solicitudes HTTP POST no se vuelven a intentar. Las solicitudes HTTP GET siempre se reintentan una vez siempre que el 80% o más de los back-ends estén en buen estado. Si hay una sola instancia de backend en un grupo y falla la conexión a esa instancia, el porcentaje de instancias de backend incorrectas es del 100%, por lo que el GFE no vuelve a intentar enviar la solicitud. El balanceador de carga vuelve a intentar enviar una solicitud GET fallida si la primera solicitud falla antes de recibir los encabezados de respuesta de la instancia de backend. Las solicitudes reintentadas solo generan una entrada de registro para la respuesta final. Para obtener más información, consulta Registro y monitorización de balanceadores de carga de aplicación externos. Las solicitudes incorrectas hacen que el balanceador de carga sintetice una respuesta HTTP 502.
Balanceador de carga de aplicación externo regional	Se puede configurar mediante una política de reintentos en el mapa de URLs. El número predeterminado de reintentos (numRetries) es 1. El número máximo de reintentos que se pueden configurar mediante la política de reintentos es 25. El valor máximo configurable de perTryTimeout es de 24 horas. Si no hay una política de reintentos, las solicitudes incorrectas que no tengan un cuerpo HTTP (por ejemplo, las solicitudes GET) que den como resultado respuestas HTTP 502, 503 o 504 se reintentarán una vez. Las solicitudes HTTP POST no se vuelven a intentar. Las solicitudes reintentadas solo generan una entrada de registro para la respuesta final.

El protocolo WebSocket es compatible con GKE Ingress.

Gestión de solicitudes y respuestas no permitida

El balanceador de carga bloquea las solicitudes de los clientes y las respuestas de los backends para que no lleguen al backend o al cliente, respectivamente, por varios motivos. Algunos motivos se deben estrictamente al cumplimiento de HTTP/1.1 y otros, a evitar que se transfieran datos inesperados a los back-ends o desde ellos. Ninguna de las comprobaciones se puede inhabilitar.

El balanceador de carga bloquea las siguientes solicitudes para cumplir el estándar HTTP/1.1:

• No puede analizar la primera línea de la solicitud.
• Falta el delimitador de dos puntos (:) en un encabezado.
• 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 Content-Length.
• Hay varias claves de codificación de transferencia o hay valores de codificación de transferencia no reconocidos.
• Hay un cuerpo sin fragmentar y no se ha especificado 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 carga cierra las conexiones con el cliente y el backend cuando recibe un fragmento que no se puede analizar.

Gestión de solicitudes

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

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

Gestión de respuestas

El balanceador de carga 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 máximo de tamaño de encabezado de respuesta para los balanceadores de carga de aplicaciones externos.
• Se desconoce la versión HTTP.

Al gestionar tanto la solicitud como la respuesta, el balanceador de carga puede quitar o sobrescribir los encabezados hop-by-hop en HTTP/1.1 antes de reenviarlos al destino previsto.

Distribución del tráfico

Cuando añades 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 para medir la carga del backend y una capacidad objetivo. Los balanceadores de carga de aplicación externos admiten dos modos de balanceo:

• RATE, en el caso de los grupos de instancias o los NEG, es el número máximo objetivo de solicitudes (consultas) por segundo (RPS o QPS). El RPS o QPS máximo objetivo se puede superar si todos los back-ends están al máximo de su capacidad o por encima de ella.

• UTILIZATION es la utilización del backend de las VMs de un grupo de instancias.

La forma en que se distribuye el tráfico entre los backends depende del modo del balanceador de carga.

Balanceador de carga de aplicación externo global

Antes de que un frontend de Google (GFE) envíe solicitudes a las instancias de backend, el GFE estima qué instancias de backend tienen capacidad para recibir solicitudes. Esta estimación de la capacidad se realiza de forma proactiva, no al mismo tiempo que llegan las solicitudes. Los GFE reciben información periódica sobre la capacidad disponible y distribuyen las solicitudes entrantes en consecuencia.

El significado de capacidad depende en parte del modo de balanceo. En el modo RATE, es relativamente sencillo: un GFE determina exactamente cuántas solicitudes puede asignar por segundo. El balanceo de carga basado en UTILIZATION es más complejo: el balanceador de carga comprueba el uso actual de las instancias y, a continuación, estima la carga de consultas que puede gestionar cada instancia. Esta estimación cambia con el tiempo a medida que cambian la utilización de las instancias y los patrones de tráfico.

Ambos factores (la estimación de la capacidad y la asignación proactiva) influyen en la distribución entre las instancias. Por lo tanto, Cloud Load Balancing se comporta de forma diferente a un balanceador de carga de asignación rotatoria simple que distribuye las solicitudes exactamente al 50 % entre dos instancias. En su lugar,el Google Cloud equilibrio de carga intenta optimizar la selección de la instancia de backend para cada solicitud.

En el caso del balanceador de carga de aplicación externo global, el balanceo de carga se realiza en dos niveles. El modo de balanceo determina la ponderación o la fracción del tráfico que se envía a cada backend (grupo de instancias o NEG). A continuación, la política de balanceo de carga (LocalityLbPolicy) determina cómo se distribuye el tráfico a las instancias o los endpoints del grupo. Para obtener más información, consulta la política de localidad de balanceo de carga (documentación de la API del servicio de backend).

En el caso del balanceador de carga de aplicaciones clásico, el modo de balanceo se usa para seleccionar el backend más favorable (grupo de instancias o NEG). A continuación, el tráfico se distribuye de forma rotatoria entre las instancias o los endpoints del backend.

Cómo se distribuyen las solicitudes

Los balanceadores de carga de aplicaciones externos basados en GFE siguen este proceso para distribuir las solicitudes entrantes:

1. Del cliente a la primera capa de GFE. Los routers de borde anuncian la dirección IP externa de la regla de reenvío en los bordes de la red de Google. Cada anuncio muestra un salto siguiente a un sistema de balanceo de carga de las capas 3 y 4 (Maglev). Los sistemas Maglev dirigen el tráfico a un frontend de Google (GFE) de primera capa.
   • Si usas el nivel Premium, Google anuncia la dirección IP de tu balanceador de carga desde todos los puntos de presencia del mundo. Cada dirección IP del balanceador de carga es anycast global.
   • Cuando se usa el nivel Estándar, Google anuncia la dirección IP de tu balanceador de carga desde puntos de presencia asociados a la región de la regla de reenvío. El balanceador de carga usa una dirección IP externa regional. Si usas una regla de reenvío de nivel estándar, solo podrás usar backends de grupos de instancias y NEGs zonales que se encuentren en la misma región que la regla de reenvío del balanceador de carga.
2. De la capa de GFE de primer nivel a la de segundo nivel. La GFE de primera capa termina la conexión TLS si es necesario y, a continuación, enruta el tráfico a las GFEs de segunda capa siguiendo este proceso:
   • Los GFEs de primera capa analizan el mapa de URLs y seleccionan un servicio de backend o un backend de almacenamiento.
   • En el caso de los servicios de backend con NEGs de Internet, las GFEs de primera capa seleccionan una pasarela de reenvío externa de segunda capa ubicada en el mismo sitio que la GFE de primera capa. La pasarela de reenvío envía solicitudes al endpoint de NEG de Internet. Con esto concluye el proceso de distribución de solicitudes de NEGs de Internet.
   • En el caso de los servicios de backend con NEGs sin servidor y NEGs de Private Service Connect (PSC), así como de los segmentos de backend de una sola región, los GFEs de primera capa seleccionan un GFE de segunda capa en la región que coincida con la región del NEG o del segmento. En el caso de los segmentos de Cloud Storage multirregionales, las GFEs de primera capa seleccionan GFEs de segunda capa en la región del segmento o en una región lo más cercana posible al segmento multirregional (definida por el tiempo de ida y vuelta de la red).
   • En el caso de los servicios backend con grupos de instancias, NEG zonales con GCE_VM_IP_PORT endpoints y NEGs híbridos, el sistema de gestión de capacidad de Google informa a los GFEs de primera capa sobre la capacidad usada y configurada de cada backend. La capacidad configurada de un backend se define mediante el modo de balanceo, la capacidad objetivo del modo de balanceo y el escalador de capacidad.
     • Nivel estándar: las GFEs de la primera capa seleccionan una GFE de la segunda capa en la región que contiene los back-ends.
     • Nivel Premium: las GFEs de la primera capa seleccionan las GFEs de la segunda capa de un conjunto de regiones aplicables. Las regiones aplicables son todas las regiones en las que se han configurado backends, excepto aquellas en las que se han configurado backends con capacidad cero. Los GFE de primera capa seleccionan el GFE de segunda capa más cercano de una región aplicable (definida por el tiempo de ida y vuelta de la red). Si los back-ends están configurados en dos o más regiones, las GFEs de primera capa pueden derivar solicitudes a otras regiones aplicables si una región de primera opción está llena. El desbordamiento a otras regiones es posible cuando todos los back-ends de la región de primera opción están al máximo de su capacidad.
3. La segunda capa de GFE selecciona los back-ends. Los GFEs de segunda capa se encuentran en zonas de una región. Para seleccionar un backend, siguen este proceso:
   • En el caso de los servicios de backend con NEGs sin servidor, NEGs de Private Service Connect y buckets de backend, los GFEs de segunda capa reenvían las solicitudes a los sistemas de producción de Google. De esta forma, se completa el proceso de distribución de solicitudes para estos back-ends.

   • En el caso de los servicios de backend con grupos de instancias, NEGs zonales con GCE_VM_IP_PORT puntos finales y NEGs híbridos, los sistemas de sondeo de comprobación del estado de Google informan a los GFEs de segunda capa sobre el estado de la comprobación del estado de las instancias o los puntos finales de backend.

     Solo para el nivel Premium: si el GFE de segunda capa no tiene instancias o endpoints de backend en buen estado en su región, puede enviar solicitudes a otro GFE de segunda capa en otra región aplicable con backends configurados. El desbordamiento entre GFEs de segunda capa en diferentes regiones no agota todas las combinaciones posibles entre regiones. Si necesitas dirigir el tráfico lejos de los back-ends de una región concreta, en lugar de configurar los back-ends para que fallen las comprobaciones de estado, define el escalador de capacidad del back-end como cero para que la GFE de primera capa excluya la región durante el paso anterior.

   A continuación, la GFE de segunda capa dirige las solicitudes a las instancias de backend o a los endpoints de las zonas de su región, tal como se explica en el paso siguiente.

4. La segunda capa de GFE selecciona una zona. De forma predeterminada, los GFEs de segunda capa usan el algoritmo WATERFALL_BY_REGION, en el que cada GFE de segunda capa prefiere seleccionar instancias o endpoints de backend en la misma zona que la que contiene el GFE de segunda capa. Como WATERFALL_BY_REGION minimiza el tráfico entre zonas, con frecuencias de solicitud bajas, cada GFE de segunda capa puede enviar solicitudes exclusivamente a back-ends de la misma zona que el propio GFE de segunda capa.

   Solo en el caso de los balanceadores de carga de aplicación externos globales, se pueden configurar GFE de segunda capa para que usen uno de los siguientes algoritmos alternativos mediante un serviceLbPolicy:

   • SPRAY_TO_REGION: los GFEs de segunda capa no prefieren seleccionar instancias o endpoints de backend en la misma zona que el GFE de segunda capa. Los GFEs de segunda capa intentan distribuir el tráfico a todas las instancias o endpoints de backend de todas las zonas de la región. Esto puede llevar a una distribución más uniforme de la carga a costa de un aumento del tráfico entre zonas.
   • WATERFALL_BY_ZONE: las GFEs de segunda capa prefieren seleccionar instancias o endpoints de backend en la misma zona que la GFE de segunda capa. Los GFE de segunda capa solo dirigen las solicitudes a las back-ends de diferentes zonas cuando todas las back-ends de la zona actual han alcanzado sus capacidades configuradas.
5. La segunda capa de GFE selecciona instancias o endpoints dentro de la zona. De forma predeterminada, un GFE de segunda capa distribuye las solicitudes entre los backends de forma rotatoria. Solo en el caso de los balanceadores de carga de aplicación externos globales, puedes cambiarlo mediante una política de localidad de balanceo de carga (localityLbPolicy). La política de localidad de balanceo de carga solo se aplica a los back-ends de la zona seleccionada, como se ha explicado en el paso anterior.

Balanceador de carga de aplicación externo regional

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

El modo de balanceo determina el peso y la fracción del tráfico que se envía a cada grupo (grupo de instancias o NEG). La política de localidad del balanceo de carga (LocalityLbPolicy) determina cómo se balancea la carga de los backends 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. Una vez que se ha seleccionado un backend, el tráfico se distribuye entre las instancias o los endpoints de ese grupo de backend según la política de localidad del balanceo de carga.

Para obtener más información, consulta las siguientes secciones:

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

Afinidad de sesión

La afinidad de sesión, configurada en el servicio de backend de los balanceadores de carga de aplicaciones, intenta enviar las solicitudes de un cliente concreto al mismo backend siempre que el número de instancias o endpoints de backend en buen estado se mantenga constante y que la instancia o el endpoint de backend seleccionado anteriormente no haya alcanzado su capacidad. La capacidad objetivo del modo de balanceo determina cuándo el backend alcanza su capacidad.

En la siguiente tabla se describen los diferentes tipos de opciones de afinidad de sesión que se admiten en los distintos balanceadores de carga de aplicaciones. En la sección Tipos de afinidad de sesión, se explica con más detalle cada tipo de afinidad de sesión.

Tabla: ajustes de afinidad de sesión admitidos

Producto	Opciones de afinidad de sesión
Balanceador de carga de aplicación externo global Balanceador de carga de aplicación 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) Nota: El valor predeterminado efectivo de la política de localidad de balanceo de carga (localityLbPolicy) cambia en función de los ajustes de afinidad de sesión. Si no se configura la afinidad de sesión (es decir, si la afinidad de sesión mantiene el valor predeterminado NONE), el valor predeterminado de localityLbPolicy es ROUND_ROBIN. Si la afinidad de sesión tiene un valor distinto de NONE, el valor predeterminado de localityLbPolicy es MAGLEV. En el caso del balanceador de carga de aplicación externo global, no configure la afinidad de sesión si usa la división de tráfico ponderada. Si lo haces, tendrá prioridad la configuración de división del tráfico ponderada.
Balanceador de carga de aplicación clásico	Ninguno (NONE) IP de cliente (CLIENT_IP) Cookie generada (GENERATED_COOKIE)

Tenga en cuenta lo siguiente al configurar la afinidad de sesión:

• No confíes en 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, puede dejar de funcionar cuando cambia el número de back-ends activos y correctos. Para obtener más información, consulta Pérdida de la afinidad de sesión.

• Los valores predeterminados de las marcas --session-affinity y --subsetting-policy son NONE, y solo se puede asignar un valor diferente a una de ellas a la vez.

Tipos de afinidad de sesión

La afinidad de sesión de los balanceadores de carga 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 basada en encabezados HTTP (HEADER_FIELD)
• Afinidad de sesión basada en cookies (GENERATED_COOKIE, HTTP_COOKIE y STRONG_COOKIE_AFFINITY)

Afinidad de sesión basada en hash

En el caso de la afinidad de sesión basada en hash, el balanceador de carga usa el algoritmo de hash coherente para seleccionar un backend apto. El ajuste 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

Si el ajuste de afinidad de sesión es NONE, no significa que no haya afinidad de sesión. Esto significa que no se ha configurado explícitamente ninguna opción de afinidad de sesión.

El hashing siempre se realiza para seleccionar un backend. Si la afinidad de sesión es NONE, el balanceador de carga usa un hash de 5 tuplas para seleccionar un backend. El hash de 5 tuplas está formado por 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 por IP de cliente (CLIENT_IP) es un hash de dos tuplas creado a partir de las direcciones IP de origen y de 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 este 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 carga si el paquete se envía directamente al balanceador de carga.
• Es posible que la dirección IP de origen del paquete no coincida con una dirección IP asociada al cliente original si el paquete se procesa mediante un sistema NAT o proxy intermedio antes de enviarse a un balanceador de carga. Google Cloud En situaciones en las que muchos clientes comparten la misma dirección IP de origen efectiva, algunas VMs backend pueden recibir más conexiones o solicitudes que otras.

Afinidad de sesión basada en encabezados HTTP

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

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

• La política de localidad de balanceo de carga 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 cookies 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 carga incluye una cookie HTTP en el encabezado Set-Cookie en respuesta a la solicitud HTTP inicial.

El nombre de la cookie generada varía en función del tipo de balanceador de carga.

Producto	Nombre de la cookie
Balanceadores de carga de aplicación externos globales	GCLB
Balanceadores de carga de aplicación clásicos	GCLB
Balanceadores de carga de aplicación externos regionales	GCILB

El atributo de ruta de la cookie generada siempre es una barra inclinada (/), por lo que se aplica a todos los servicios backend del mismo mapa de URLs, siempre que los demás servicios backend también usen la afinidad de cookie generada.

Puedes configurar el valor del tiempo de vida (TTL) de la cookie entre 0 y 1,209,600 segundos (ambos incluidos) mediante el parámetro de servicio backend affinityCookieTtlSec. Si no se especifica affinityCookieTtlSec, el valor predeterminado de 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 carga dirige esas solicitudes a la misma instancia o endpoint backend, siempre que la cookie de afinidad de sesión siga siendo válida. Para ello, se asigna el valor de la cookie a un índice que hace referencia a una instancia de backend o a un endpoint específicos, y se asegura de que se cumplan los requisitos de afinidad de sesión de la cookie generada.

Para usar la afinidad de cookies generada, configura los siguientes ajustes de localityLbPolicy y de modo de balanceo:

• En el caso de 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 defines explícitamente localityLbPolicy, el balanceador de carga usará MAGLEV como valor predeterminado implícito.

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

Afinidad de cookies HTTP

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

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

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

• consistentHash.httpCookie.ttl.seconds puede tener un valor entre 0 y 315576000000 (ambos incluidos).
• consistentHash.httpCookie.ttl.nanos puede tener un valor entre 0 y 999999999 (ambos incluidos). Como las unidades son nanosegundos, 999999999 significa .999999999 segundos.

Si no se especifican consistentHash.httpCookie.ttl.seconds ni consistentHash.httpCookie.ttl.nanos, se usará el valor del parámetro de servicio backend affinityCookieTtlSec. Si no se especifica affinityCookieTtlSec, el valor predeterminado de TTL 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 carga dirige esas solicitudes a la misma instancia o endpoint backend, siempre que la cookie de afinidad de sesión siga siendo válida. Para ello, se asigna el valor de la cookie a un índice que hace referencia a una instancia de backend o a un endpoint específicos, y se asegura de que se cumplan los requisitos de afinidad de sesión de la cookie generada.

Para usar la afinidad de cookies HTTP, configura los siguientes ajustes de localityLbPolicy y de modo de balanceo:

• En el caso de 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 defines explícitamente localityLbPolicy, el balanceador de carga usará MAGLEV como valor predeterminado implícito.

Para obtener más información, consulta Pérdida de la 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 carga incluye una cookie HTTP en el encabezado Set-Cookie en respuesta a la solicitud HTTP inicial. Usted especifica el nombre, la ruta y el tiempo de vida (TTL) de la cookie.

Todos los balanceadores de carga de aplicaciones, excepto los clásicos, admiten la afinidad basada en cookies con estado.

Puedes configurar los valores de TTL de las cookies usando segundos, fracciones de segundo (en nanosegundos) o ambos (segundos y fracciones de segundo en nanosegundos). La duración representada por strongSessionAffinityCookie.ttl no puede ser superior a dos semanas (1.209.600 segundos).

El valor de la cookie identifica una instancia o un endpoint de backend seleccionados codificando la instancia o el endpoint seleccionados en el propio 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 carga dirigirá esas solicitudes a la instancia o el endpoint 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 de balanceo de carga (localityLbPolicy).

• La afinidad basada en cookies con estado no se ve afectada cuando el autoescalado añade una instancia nueva a un grupo de instancias gestionado.

• La afinidad basada en cookies con estado no se ve afectada cuando el autoescalado elimina una instancia de un grupo de instancias gestionado a menos que se elimine la instancia seleccionada.

• La afinidad basada en cookies con estado no se ve afectada cuando la reparación automática elimina una instancia de un grupo de instancias gestionado, a menos que se elimine la instancia seleccionada.

Para obtener más información, consulta Pérdida de la 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 carga 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 sesión varía en función del 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 única 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 endpoint de backend seleccionados deben seguir configurados como backend. La afinidad de sesión puede dejar de funcionar cuando se produce uno de los siguientes eventos:
  • Se elimina la instancia seleccionada de su grupo de instancias.
  • La función de autoescalado o de reparación automática de grupos de instancias gestionados elimina la instancia seleccionada de su grupo de instancias gestionado.
  • Eliminas el endpoint seleccionado de su NEG.
  • Elimina del servicio de backend el grupo de instancias o el NEG que contenga la instancia o el endpoint seleccionados.
• La instancia o el endpoint de backend seleccionados deben mantener su buen estado. La afinidad de sesión puede dejar de funcionar cuando la instancia o el endpoint seleccionados no superan las comprobaciones de estado.
• En el caso de los balanceadores de carga de aplicaciones externos globales y los balanceadores de carga de aplicaciones clásicos, la afinidad de sesión puede dejar de funcionar si se usa un frontend de Google (GFE) de primera capa diferente para las solicitudes o conexiones posteriores al cambio en la ruta. Es posible que se seleccione otra GFE de primera capa si la ruta de acceso de un cliente de 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 NEG que contiene la instancia o el endpoint seleccionados no debe estar lleno, tal como se define en su capacidad objetivo. En el caso de los grupos de instancias gestionados regionales, el componente de zona del grupo de instancias que contiene la instancia seleccionada no debe estar lleno. La afinidad de sesión puede dejar de funcionar cuando el grupo de instancias o el NEG están llenos y otros grupos de instancias o NEGs no. Como la capacidad puede cambiar de forma impredecible al usar el modo de balanceo UTILIZATION, debes usar el modo de balanceo RATE o CONNECTION para minimizar las situaciones en las que la afinidad de sesión pueda fallar.

• El número total de instancias o endpoints de backend configurados debe permanecer constante. Cuando se produce al menos uno de los siguientes eventos, cambia el número de instancias o endpoints de backend configurados y se puede interrumpir la afinidad de sesión:

  • Añadir nuevas instancias o endpoints:

    • Añade instancias a un grupo de instancias que ya tengas en el servicio de backend.
    • El autoescalado de grupos de instancias gestionados añade instancias a un grupo de instancias gestionado en el servicio de backend.
    • Añade puntos finales a un NEG que ya esté en el servicio backend.
    • Añade grupos de instancias o NEGs no vacíos al servicio de backend.

  • Para quitar cualquier instancia o endpoint, no solo la instancia o el endpoint seleccionados:

    • Elimina cualquier instancia de un backend de grupo de instancias.
    • El autoescalado o la reparación automática de grupos de instancias gestionados elimina cualquier instancia de un backend de grupo de instancias gestionado.
    • Puedes quitar cualquier endpoint de un backend de NEG.
    • Elimina cualquier grupo de instancias de backend o NEG no vacío del servicio de backend.

• El número total de instancias o endpoints de backend en buen estado debe mantenerse constante. Cuando se produce al menos uno de los siguientes eventos, cambia el número de instancias o endpoints de backend correctos y se puede interrumpir la afinidad de sesión:

  • Cualquier instancia o endpoint supera su comprobación de estado y pasa de estar en mal estado a estar en buen estado.
  • Si alguna instancia o endpoint no supera la comprobación del estado, pasa de estar en buen estado a no estarlo o a agotar el tiempo de espera.