Descripción general de los servicios de backend

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Un servicio de backend define cómo Cloud Load Balancing distribuye el tráfico. La configuración del servicio de backend contiene un conjunto de valores, como el protocolo que se usa para conectarse a backends, varios parámetros de configuración de distribución y sesión, verificaciones de estado y tiempos de espera. Esta configuración proporciona un control detallado sobre el comportamiento del balanceador de cargas. Si necesitas comenzar con rapidez, la mayoría de las opciones de configuración tienen valores predeterminados que permiten una configuración sencilla. Un servicio de backend puede tener un alcance global o regional.

Los balanceadores de cargas, los proxies de Envoy y los clientes de gRPC sin proxy usan la información de configuración en el recurso del servicio de backend para hacer lo siguiente:

  • Dirigir el tráfico a los backends correctos, que son grupos de instancias o grupos de extremos de red (NEG).
  • Distribuir el tráfico según un modo de balanceo, que es una configuración para cada backend
  • Determinar qué verificación de estado supervisa el estado de los backends
  • Especificar la afinidad de sesión
  • Determina si otros servicios están habilitados, incluidos los siguientes que solo están disponibles para ciertos balanceadores de cargas:
    • Cloud CDN
    • Políticas de seguridad de Google Cloud Armor
    • Identity‑Aware Proxy

Establece estos valores cuando creas un servicio de backend o cuando agregas un backend al servicio de backend.

En la siguiente tabla, se resumen los balanceadores de cargas que usan servicios de backend. El producto que usas determina la cantidad máxima de servicios de backend, el permiso de un servicio de backend, el tipo de backends compatibles y el esquema de balanceo de cargas del servicio de backend. El esquema de balanceo de cargas es un identificador que Google usa para clasificar reglas de reenvío y servicios de backend. Cada producto de balanceo de cargas usa un esquema de balanceo de cargas para las reglas de reenvío y los servicios de backend. Algunos esquemas se comparten entre los productos.

Tabla: Servicios de backend y tipos de backend compatibles
Producto Cantidad máxima de servicios de backend Alcance del servicio de backend Tipos de backends compatibles Esquema de balanceo de cargas
Balanceador de cargas de HTTP(S) externo global Varias Global Cada servicio de backend admite una de las siguientes combinaciones:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
  • Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT 2
  • Todos los NEG sin servidores: Uno o más servicios de App Engine, Cloud Run o Cloud Functions
  • NEG de Private Service Connect: si se especifica más de un NEG, los NEG deben estar en diferentes regiones.
 EXTERNAL_MANAGED
Balanceador de cargas de HTTP(S) global externo (clásico) Varias Global1 Cada servicio de backend admite una de las siguientes combinaciones:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
  • Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT 2
  • Todos los NEG sin servidores: Uno o más servicios de App Engine, Cloud Run o Cloud Functions
  • Un NEG de Internet para un backend externo
 EXTERNAL
Balanceador de cargas HTTP(S) regional externo Varias Regional Cada servicio de backend admite una de las siguientes combinaciones:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
  • Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT 2
  • Un solo NEG sin servidores (solo Cloud Run)
  • Un NEG de Private Service Connect único
 EXTERNAL_MANAGED
Balanceador de cargas HTTP(S) interno Varias Regional Cada servicio de backend admite una de las siguientes combinaciones:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
  • Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT 2
  • Un solo NEG sin servidores (solo Cloud Run)
  • Un NEG de Private Service Connect único
 INTERNAL_MANAGED
Balanceador de cargas del proxy SSL externo 1 Global1 El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
  • Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT 2
 EXTERNO
Balanceador de cargas del proxy TCP externo 1 Global1 El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
  • Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT 2
 EXTERNO
Balanceador de cargas del proxy TCP regional interno 1 Regional El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
  • Todos los NEG de conectividad híbrida: Uno o más NEG de tipo NON_GCP_PRIVATE_IP_PORT
  • Una combinación de NEG zonales y híbridos: NEG de tipo GCE_VM_IP_PORT y NON_GCP_PRIVATE_IP_PORT
INTERNAL_MANAGED
Balanceador de cargas de red 1 Regional El servicio de backend admite las siguientes combinaciones de backends:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
 EXTERNAL
Balanceadores de cargas TCP/UDP internos 1 Regional, pero configurable para que sea accesible a nivel global El servicio de backend admite una de las siguientes combinaciones de backend:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP
 INTERNAL
Traffic Director Varias Global Cada servicio de backend admite una de las siguientes combinaciones:
  • Todos los backends de grupos de instancias: Uno o más backends de grupos de instancias administrados, no administrados o una combinación de ambos
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT o NON_GCP_PRIVATE_IP_PORT
  • Un NEG de Internet de tipo INTERNET_FQDN_PORT
  • Una o más vinculaciones del servicio
 INTERNAL_SELF_MANAGED
1 Los servicios de backend que usa el balanceador de cargas de HTTP(S) externo (clásico) global, los balanceadores de cargas de proxy SSL externos y los balanceadores de cargas de proxy TCP externos son siempre de alcance global, ya sea estándar o el nivel Premium de la red. However, in Standard Tier the following restrictions apply:
2 Para implementaciones de GKE, los backends de NEG mixtos solo son compatibles con NEG independientes.

Backends

Un backend es uno o más extremos que reciben tráfico de un balanceador de cargas de Google Cloud, un proxy de Envoy configurado por Traffic Director o un cliente de gRPC sin proxy. Existen varios tipos de backends:

No puedes borrar un grupo de instancias de backend o un NEG que estén asociados con un servicio de backend. Antes de borrar un grupo de instancias o un NEG, primero debes quitarlos como un backend de todos los servicios de backend que hacen referencia a ellos.

Grupos de instancias

En esta sección, se analiza cómo funcionan los grupos de instancias con el servicio de backend.

Direcciones IP externas y VM de backend

Las VM de backend en los servicios de backend no necesitan direcciones IP externas:

  • En el caso de los balanceadores de cargas de HTTP(S) externos y globales, de proxy SSL externos y de proxy TCP externos: los clientes se comunican con un Google Front End (GFE) que aloja la dirección IP externa del balanceador de cargas. Los GFE se comunican con las VMs o los extremos de backend mediante el envío de paquetes a una dirección interna creada mediante la unión de un identificador a la red de VPC del backend con la dirección IPv4 interna del backend. Para los backends de grupo de instancias, la dirección IPv4 interna siempre es la dirección IPv4 interna principal que corresponde a la interfaz nic0 de la VM. Para los extremos GCE_VM_IP_PORT en un NEG zonal, puedes especificar la dirección IPv4 del extremo como la dirección IPv4 principal asociada con cualquier NIC de una VM o cualquier dirección IPv4 de un rango de alias de IP asociado con cualquier NIC de una VM. La comunicación entre los GFE y los extremos o VMs de backend se facilita mediante rutas especiales.
  • Balanceadores de cargas de HTTP(S) regionales externos: los clientes se comunican con un proxy de Envoy que aloja la dirección IP externa del balanceador de cargas. Los proxies de Envoy se comunican con las VMa o los extremos de backend mediante el envío de paquetes a una dirección interna creada mediante la unión de un identificador a la red de VPC del backend con la dirección IPv4 interna del backend.
    • Para los backends de grupo de instancias, la dirección IPv4 interna siempre es la dirección IPv4 interna principal que corresponde a la interfaz nic0 de la VM y nic0 debe estar en la misma red que el balanceador de cargas.
    • Para los extremos GCE_VM_IP_PORT en un NEG zonal, puedes especificar la dirección IPv4 del extremo como la dirección IPv4 principal de la NIC de una VM o una dirección IPv4 de un rango de alias de IP de la NIC de una VM, siempre que la NIC de la VM esté en la misma red que el balanceador de cargas.
  • Para balanceadores de cargas de red: Los clientes se comunican directamente con los backends a través de la infraestructura de balanceo de cargas de paso de Maglev de Google. Los paquetes se enrutan y se entregan a la interfaz nic0 de una VM de backend con las direcciones IP de origen y destino originales conservadas. Los backends responden a los clientes mediante el retorno directo del servidor. Los métodos utilizados para seleccionar un backend y realizar un seguimiento de las conexiones son configurables.

Puertos con nombre

El atributo del puerto con nombre del servicio de backend solo se aplica a los balanceadores de cargas de proxy que usan backends de grupos de instancias. El puerto con nombre define el puerto de destino que se usa para la conexión TCP entre el proxy (GFE o Envoy) y la instancia de backend.

Los puertos con nombre se configuran de la siguiente manera:

  • En cada backend del grupo de instancias, debes configurar uno o más puertos con nombre mediante pares clave-valor. La clave representa un nombre de puerto significativo que eliges y el valor representa el número de puerto que asignas al nombre. La asignación de nombres a números se realiza de forma individual para cada backend del grupo de instancias.

  • En el servicio de backend, debes especificar un solo puerto con nombre únicamente con el nombre del puerto (--port-name).

En cada backend de grupo de instancias, el servicio de backend traduce el nombre del puerto a un número de puerto. Cuando el puerto con nombre de un grupo de instancias coincide con el --port-name del servicio de backend, el servicio de backend usa este número de puerto para la comunicación con las VMs del grupo de instancias.

Por ejemplo, puedes configurar el puerto con nombre en un grupo de instancias con el nombre my-service-name y el puerto 8888:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

Luego, debes hacer referencia al puerto con nombre en la configuración del servicio de backend mediante el --port-name en el servicio de backend configurado como my-service-name:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Un servicio de backend puede usar un número de puerto diferente cuando se comunica con las VM en grupos de instancias diferentes si cada grupo de instancias especifica un número de puerto diferente para el mismo nombre de puerto.

No es necesario que el número de puerto resuelto que usa el servicio de backend del balanceador de cargas de proxy coincida con el número de puerto que usan las reglas de reenvío del balanceador de cargas. Un balanceador de cargas de proxy escucha las conexiones TCP enviadas a la dirección IP y al puerto de destino de las reglas de reenvío. Debido a que el proxy abre una segunda conexión de TCP a sus backends, el puerto de destino de la segunda conexión de TCP puede ser diferente.

Los puertos con nombre solo se aplican a los backends de grupos de instancias. Los NEG zonales con extremos GCE_VM_IP_PORT, los NEG híbridos con extremos NON_GCP_PRIVATE_IP_PORT y los NEG de Internet definen puertos mediante un mecanismo diferente, es decir, en los extremos. Los NEG sin servidores hacen referencia a los servicios de Google y los NEG de PSC hacen referencia a los adjuntos de servicio mediante abstracciones que no implican especificar un puerto de destino.

Los balanceadores de cargas TCP/UDP internos y los externos no usan puertos con nombre. Esto se debe a que son balanceadores de cargas de paso que enrutan las conexiones directamente a los backends en lugar de crear conexiones nuevas. Los paquetes se entregan a los backends mediante la preservación de la dirección IP y el puerto de destino de la regla de reenvío del balanceador de cargas.

Para aprender a crear puertos con nombre, consulta las siguientes instrucciones:

Restricciones y recomendaciones para grupos de instancias

Ten en cuenta las siguientes restricciones y recomendaciones cuando crees grupos de instancias para los balanceadores de cargas:

  • No pongas una VM en más de un grupo de instancias con balanceo de cargas. Si una VM es miembro de dos o más grupos de instancias no administrados, o de un grupo de instancias administrado y de uno o más grupos de instancias no administrados, solo puedes usar uno de esos grupos de instancias a la vez como backend para un servicio de backend en particular.

    Si necesitas una VM para participar en varios balanceadores de cargas, debes usar el mismo grupo de instancias como backend en cada uno de los servicios de backend.

  • Para los balanceadores de cargas de proxy, cuando quieras balancear el tráfico en puertos diferentes, especifica los puertos con nombre necesarios en un grupo de instancias y haz que cada servicio de backend se suscriba a un único nombre llamado puerto.

  • Puedes usar el mismo grupo de instancias como backend para más de un servicio de backend. En esta situación, los backends deben usar modos de balanceo compatibles. Compatible significa que los modos de balanceo deben ser iguales o deben ser una combinación de CONNECTION y RATE.

    Las combinaciones de modo de balanceo incompatibles son las siguientes:

    • CONNECTION con UTILIZATION
    • RATE con UTILIZATION

    Considera el siguiente ejemplo:

    • Tienes dos servicios de backend: external-https-backend-service para un balanceador de cargas de HTTP(S) externo y internal-tcp-backend-service para un balanceador de cargas de TCP/UDP interno.
    • Usas un grupo de instancias llamado instance-group-a en internal-tcp-backend-service.
    • En internal-tcp-backend-service, debes aplicar el modo de balanceo CONNECTION, porque los balanceadores de cargas de TCP/UDP internos solo admiten el modo de balanceo CONNECTION.
    • También puedes usar instance-group-a en external-https-backend-service si aplicas el modo de balanceo RATE en external-https-backend-service.
    • No puedes usar instance-group-a en external-https-backend-service con el modo de balanceo UTILIZATION.

  • Si deseas cambiar el modo de balanceo de un grupo de instancias que funciona como backend para varios servicios de backend, haz lo siguiente:

    • Quita el grupo de instancias de todos los servicios de backend, excepto de uno.
    • Cambia el modo de balanceo del backend en el servicio de backend restante.
    • Vuelve a agregar el grupo de instancias como backend para los servicios de backend restantes, si es que admiten el modo de balanceo nuevo.

  • Si el grupo de instancias está asociado con varios servicios de backend, cada servicio de backend puede hacer referencia al mismo puerto con nombre o a un puerto con nombre diferente en el grupo de instancias.

  • Recomendamos que no se agregue un grupo de instancias administrado con ajuste de escala automático a más de un servicio de backend. Esto podría causar un escalamiento impredecible e innecesario de las instancias en el grupo, en especial si usas la métrica de ajuste de escala automático del uso del balanceo de cargas de HTTP.

    • Aunque no se recomienda, esta situación podría funcionar si la métrica de ajuste de escala automático es uso de CPU o una métrica de Cloud Monitoring que no está relacionada con la capacidad de entrega del balanceador de cargas. El uso de una de estas métricas de ajuste de escala automático puede evitar el escalamiento errático.

Grupos de extremos de red zonal

Los extremos de red representan servicios por su dirección IP o una combinación de dirección IP y puerto, en lugar de hacer referencia a una VM de un grupo de instancias. Un grupo de extremos de red (NEG) es una agrupación lógica de extremos de red.

Los grupos de extremos de red por zonas (NEG) son recursos zonales que representan conjuntos de direcciones IP o combinaciones de direcciones IP/puertos para recursos de Google Cloud dentro de una única subred..

Los servicios de backend que usan NEG zonales como backends distribuyen el tráfico entre las aplicaciones o los contenedores que se ejecutan dentro de las VM.

Existen dos tipos de extremos de red disponibles para los NEG zonales:

  • Extremos GCE_VM_IP (compatibles solo con balanceadores de cargas TCP/UDP internos).
  • Extremos de GCE_VM_IP_PORT.

Para ver qué productos admiten backends de NEG zonales, consulta Tabla: Servicios de backend y tipos de backends compatibles.

Para obtener más detalles, consulta la Descripción general de los NEG zonales.

Grupos de extremos de red de Internet

Los NEG de Internet son recursos globales que definen backends externos. Un backend externo es un backend alojado en la infraestructura local o en la infraestructura proporcionada por terceros.

Un NEG de Internet es una combinación de un nombre de host o una dirección IP, más un puerto opcional. Existen dos tipos de extremos de red disponibles para los NEG de Internet:

  • INTERNET_FQDN_PORT. Un nombre de dominio completamente calificado que se puede resolver de forma pública y un puerto opcional, por ejemplo backend.example.com:443 (puertos predeterminados: 80 para HTTP y 443 para HTTPS)
  • INTERNET_IP_PORT. Una dirección IP de acceso público y un puerto opcional, por ejemplo, 203.0.113.8:80 o 203.0.113.8:443 (puertos predeterminados: 80 para HTTP y 443 para HTTPS)

Para ver qué productos admiten backends de NEG de Internet, consulta Tabla: Servicios de backend y tipos de backends compatibles.

Para obtener más información sobre los NEG de Internet, consulta Descripción general de los grupos de extremos de red de Internet.

Grupos de extremos de red sin servidores

Un grupo de extremos de red (NEG) especifica un grupo de extremos de backend para un balanceador de cargas. Un NEG sin servidores es un backend que apunta a un servicio de Cloud Run, App Engine, Cloud Functions o API Gateway.

Un NEG sin servidores puede representar una de las siguientes opciones:

  • Un servicio de Cloud Run o un grupo de servicios
  • Una función de Cloud Functions o un grupo de funciones.
  • Una app de App Engine (estándar o flexible), un servicio específico dentro de una app, una versión específica de una app o un grupo de servicios.
  • Una API Gateway que proporciona acceso a tus servicios a través de una API de REST coherente en todos los servicios, sin importar la implementación de estos. Esta función se encuentra en vista previa.

A fin de configurar un NEG sin servidores para aplicaciones sin servidores que comparten un patrón de URL, usa una máscara de URL. Una máscara de URL es una plantilla del esquema de URL (por ejemplo, example.com/<service>). El NEG sin servidores usará esta plantilla para extraer el nombre <service> de la URL de la solicitud entrante y enrutar la solicitud al servicio de Cloud Run, Cloud Functions o App Engine coincidente con el mismo nombre.

Para ver qué balanceadores de cargas admiten backends de NEG sin servidores, consulta Tabla: Servicios de backend y tipos de backends compatibles.

Para obtener más información sobre los NEG sin servidores, consulta la descripción general de los grupos de extremos de red sin servidores.

Vinculaciones del servicio

Una vinculación de servicio es un backend que establece una conexión entre un servicio de backend en Traffic Director y un servicio registrado en el Directorio de servicios. Un servicio de backend puede hacer referencia a varias vinculaciones del servicio. Un servicio de backend con una vinculación del servicio no puede hacer referencia a ningún otro tipo de backend.

Backends mixtos

Las siguientes consideraciones de uso se aplican cuando agregas diferentes tipos de backends a un solo servicio de backend:

  • Un solo servicio de backend no puede usar simultáneamente grupos de instancias y NEG zonales.
  • Puedes usar una combinación de tipos de grupos de instancias diferentes en el mismo servicio de backend. Por ejemplo, un solo servicio de backend puede hacer referencia a una combinación de grupos de instancias administrados y no administrados. Para obtener información completa sobre la compatibilidad de los backends con los servicios de backend, consulta la tabla de la sección anterior.
  • Con ciertos balanceadores de cargas de proxy, puedes usar una combinación de NEG zonales (con extremos GCE_VM_IP_PORT) y NEG de conectividad híbrida (con extremos NON_GCP_PRIVATE_IP_PORT) para configurar el balanceo de cargas híbrido. Para ver qué balanceadores de cargas tienen esta capacidad, consulta Tabla: Servicios de backend y tipos de backend compatibles.

Protocolo para los backends

Cuando creas un servicio de backend, debes especificar el protocolo que se usa para comunicarse con los backends. Puedes especificar solo un protocolo por servicio de backend; no puedes especificar un protocolo secundario para usar como resguardo.

Los protocolos válidos dependen del tipo de balanceador de cargas o de si se usa Traffic Director.

Tabla: Protocolo para los backends
Producto Esquema de balanceo de cargas Opciones de protocolo del servicio de backend
Balanceador de cargas de HTTP(S) externo global EXTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Balanceador de cargas de HTTP(S) global externo (clásico) EXTERNAL HTTP, HTTPS, HTTP/2
Balanceador de cargas HTTP(S) regional externo EXTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Balanceador de cargas de proxy SSL externo EXTERNO SSL o TCP
Balanceador de cargas de proxy TCP externo EXTERNO TCP o SSL
Balanceador de cargas HTTP(S) interno INTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Balanceador de cargas del proxy TCP regional interno INTERNAL_MANAGED TCP
Balanceador de cargas de red EXTERNAL TCP, UDP o UNSPECIFIED
Balanceadores de cargas TCP/UDP internos INTERNAL TCP o UDP
Traffic Director INTERNAL_SELF_MANAGED HTTP, HTTPS, HTTP/2, gRPC, TCP

Cuando cambias el protocolo de un servicio de backend, no se puede acceder a los backends a través de los balanceadores de cargas durante unos minutos.

Encriptación entre el balanceador de cargas y los backends

Para obtener más información sobre este tema, consulta Encriptación en los backends.

Distribución de tráfico

Los valores de los siguientes campos del recurso de servicios de backend determinan algunos aspectos del comportamiento del backend:

  • Un modo de balanceo define cómo el balanceador de cargas mide la preparación de backend para solicitudes o conexiones nuevas.
  • Una capacidad de destino define una cantidad máxima de conexiones de destino, una tasa máxima de destino o el uso máximo de CPU de destino.
  • Un escalador de capacidad ajusta la capacidad general disponible sin modificar la capacidad de destino.

Modo de balanceo

El modo de balanceo determina si los backends de un balanceador de cargas o Traffic Director pueden manejar el tráfico adicional o si están cargados por completo. Google Cloud tiene tres modos de balanceo:

  • CONNECTION: Determina cómo se distribuye la carga en función de la cantidad de conexiones simultáneas que puede controlar el backend.
  • RATE: 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: Determina cómo se distribuye la carga en función del uso de las instancias en un grupo de instancias.

Modos de balanceo disponibles para cada balanceador de cargas

Debes establecer el modo de balanceo cuando agregas un backend al servicio de backend. Los modos de balanceo disponibles para un balanceador de cargas dependen del tipo de balanceador de cargas y de los backends.

Los balanceadores de cargas de paso requieren el modo de balanceo CONNECTION, pero no admiten la configuración de ninguna capacidad de destino.

Los balanceadores de cargas de proxy HTTP(S) admiten modos de balanceo RATE o UTILIZATION para backends de grupo de instancias, el modo de balanceo RATE para NEG zonales conextremos GCE_VM_IP_PORT y el modo de balanceo RATE para NEG híbridos (extremos NON_GCP_PRIVATE_IP_PORT). Para cualquier otro tipo de backend compatible, se debe omitir el modo de balanceo.

  • Para el balanceador de cargas de HTTP(S) externo global (clásico), se selecciona una región en función de la ubicación del cliente y si la región tiene capacidad disponible, según la capacidad de destino del modo de balanceo de cargas. Luego, dentro de una región, la capacidad objetivo del modo de balanceo se usa para calcular las proporciones sobre cuántas solicitudes deben dirigirse a cada backend de la región. Luego, las solicitudes o conexiones se distribuyen según un algoritmo round robin entre las instancias o los extremos dentro del backend.
  • Para los balanceadores de cargas HTTP(S) externos globales, se selecciona una región en función de la ubicación del cliente y de si la región tiene capacidad disponible, según la capacidad de destino del modo de balanceo de cargas. Dentro de una región, la capacidad de destino del modo de balanceo se usa para calcular las proporciones de cuántas solicitudes deben dirigirse a cada backend (grupo de instancias o NEG) de la región. Dentro de cada grupo de instancias o NEG, la política de balanceo de cargas (LocalityLbPolicy) determina cómo se distribuye el tráfico en las instancias o extremos del grupo.
  • En el caso de los balanceadores de cargas HTTP(S) externos regionales y los balanceadores de cargas HTTP(S) internos, la capacidad de destino del modo de balanceo se usa para calcular las proporciones de cuántas solicitudes deben dirigirse a cada backend (grupo de instancias o NEG) en la región. Dentro de cada grupo de instancias o NEG, la política de balanceo de cargas (LocalityLbPolicy) determina cómo se distribuye el tráfico en las instancias o extremos del grupo.

Los balanceadores de cargas de proxy TCP/SSL admiten modos de balanceo CONNECTION o UTILIZATION para backends de grupo de instancias, el modo de balanceo CONNECTION para NEG zonales conextremos GCE_VM_IP_PORT y el modo de balanceo CONNECTION para NEG híbridos (extremos NON_GCP_PRIVATE_IP_PORT). Para cualquier otro tipo de backend compatible, se debe omitir el modo de balanceo.

  • Para el balanceador de cargas del proxy TCP externo y el proxy SSL externo, se selecciona una región en función de la ubicación del cliente y si la región tiene capacidad disponible, según la capacidad de destino del modo de balanceo de cargas. Luego, dentro de una región, la capacidad de destino del modo de balanceo de cargas se usa para calcular las proporciones sobre cuántas solicitudes o conexiones deben ir a cada backend (grupo de instancias o NEG) en la región. Una vez que el balanceador de cargas selecciona un backend, las solicitudes o conexiones se distribuyen de forma round robin entre las instancias de VM o los extremos de red dentro de cada backend individual.

  • Para el balanceador de cargas de proxy TCP regional, la capacidad de destino del modo de balanceo de cargas se usa para calcular las proporciones de cuántas solicitudes deben ir a cada backend (grupo de instancias o NEG). Dentro de cada grupo de instancias o NEG, la política de balanceo de cargas (LocalityLbPolicy) determina cómo se distribuye el tráfico en las instancias o extremos del grupo.

En la siguiente tabla, se resumen los modos de balanceo de cargas disponibles para cada combinación de balanceador de cargas y backend.

Tabla: Modos de balanceo disponibles para cada balanceador de cargas
Balanceador de cargas Backends Modos de balanceo disponibles
  • Balanceador de cargas de HTTP(S) externo global
  • Balanceador de cargas de HTTP(S) global externo (clásico)
  • Balanceador de cargas HTTP(S) regional externo
 Grupos de instancias RATE o UTILIZATION
NEG zonales (extremos GCE_VM_IP_PORT) RATE
NEG híbridos (extremos NON_GCP_PRIVATE_IP_PORT) RATE
  • Balanceador de cargas de proxy TCP externo
  • Balanceador de cargas de proxy SSL externo
  • Balanceador de cargas del proxy TCP regional interno
 Grupos de instancias CONNECTION o UTILIZATION
NEG zonales (extremos GCE_VM_IP_PORT) CONNECTION
NEG híbridos (extremos NON_GCP_PRIVATE_IP_PORT)
(solo compatible con el balanceador de cargas de proxy TCP regional interno)		 CONNECTION
Balanceador de cargas de red Grupos de instancias CONNECTION
Balanceadores de cargas TCP/UDP internos Grupos de instancias CONNECTION
NEG zonales (extremos GCE_VM_IP) CONNECTION

Si el uso promedio de todas las VM asociadas con un servicio de backend es inferior al 10%, Google Cloud puede preferir zonas específicas. Esto puede suceder cuando usas grupos de instancias regionales administrados, grupos de instancias administrados zonales en zonas diferentes y grupos de instancias zonales no administrados. Este desequilibrio zonal se resuelve de forma automática a medida que se envía más tráfico al balanceador de cargas.

Para obtener más información, consulta la página gcloud compute backend-services add-backend.

Capacidad de destino

Cada modo de balanceo tiene una capacidad de destino correspondiente, que define uno de los siguientes valores máximos de destino:

  • Número de conexiones
  • Tasa
  • Uso de CPU

En cada modo de balanceo, la capacidad de destino no es un disyuntor. Un balanceador de cargas puede exceder el máximo en ciertas condiciones, por ejemplo, si todas las VM o los extremos de backend lo alcanzaron.

Modo de balanceo de conexiones

En el modo de balanceo CONNECTION, la capacidad de destino define una cantidad máxima de destino de conexiones simultáneas. A excepción de los balanceadores de cargas TCP/UDP internos y los de red, debes usar una de las siguientes configuraciones para especificar una cantidad máxima de conexiones de destino:

  • max-connections-per-instance (por VM): Cantidad promedio de conexiones de destino para una sola VM.
  • max-connections-per-endpoint (por extremo en un NEG zonal): Cantidad promedio de conexiones de destino para un solo extremo.
  • max-connections (por NEG zonales y para grupos de instancias zonales): Cantidad promedio de conexiones de destino en todo el NEG o grupo de instancias. Para los grupos de instancias administrados regionales, usa max-connections-per-instance en su lugar.

En la siguiente tabla, se muestra cómo el parámetro de capacidad de destino define los siguientes aspectos:

  • La capacidad de destino de todo el backend
  • La capacidad de destino esperada para cada instancia o extremo
Tabla: Capacidad de destino para los backends con el modo de balanceo CONNECTION
Tipo de backend Capacidad de destino
Si especificas Capacidad completa del backend Capacidad esperada por instancia o extremo
Grupo de instancias
N instancias,
H en buen estado
 max-connections-per-instance=X X × N (X × N)/H
NEG zonales
N extremos,
H en buen estado 		max-connections-per-endpoint=X X × N (X × N)/H
Grupos de instancias
(excepto los grupos de instancias administrados regionales)

H instancias en buen estado 		max-connections=Y Y Y/H

Como se ilustra, la configuración max-connections-per-instance y max-connections-per-endpoint son proxies para calcular una cantidad máxima de conexiones de destino en todo el grupo de instancias o en el NEG zonal completo:

  • En un grupo de instancias con instancias N, configurar max-connections-per-instance=X tiene el mismo significado que configurar max-connections=X × N.
  • En un NEG zonal con extremos N, la configuración de max-connections-per-endpoint=X tiene el mismo significado que la opción de configuración max-connections=X × N.

Modo de balanceo de tarifas

Para el modo de balanceo RATE, debes definir la capacidad de destino mediante uno de los siguientes parámetros:

  • max-rate-per-instance (por VM): Proporciona una tasa promedio de solicitudes HTTP de destino para una sola VM.
  • max-rate-per-endpoint (por extremo en un NEG zonal): Proporciona una tasa promedio de solicitudes HTTP de destino para un solo extremo.
  • max-rate (por NEG zonales y para grupos de instancias zonales): Proporciona una tasa promedio de solicitudes HTTP de destino para todo el NEG o todo grupo de instancias. Para los grupos de instancias administrados regionales, usa max-rate-per-instance en su lugar.

En la siguiente tabla, se muestra cómo el parámetro de capacidad de destino define los siguientes aspectos:

  • La capacidad de destino de todo el backend
  • La capacidad de destino esperada para cada instancia o extremo
Tabla: Capacidad de destino para backends mediante el modo de balanceo RATE
Tipo de backend Capacidad de destino
Si especificas Capacidad completa del backend Capacidad esperada por instancia o extremo
Grupo de instancias
N instancias,
H en buen estado
 max-rate-per-instance=X X × N (X × N)/H
NEG zonales
N extremos,
H en buen estado 		max-rate-per-endpoint=X X × N (X × N)/H
Grupos de instancias
(excepto los grupos de instancias administrados regionales)

H instancias en buen estado 		max-rate=Y Y Y/H

Como se ilustra, la configuración max-rate-per-instance y max-rate-per-endpoint son proxies para calcular una tasa máxima de solicitudes HTTP de destino en todo el grupo de instancias o en el NEG zonal completo:

  • En un grupo de instancias con instancias N, configurar max-rate-per-instance=X tiene el mismo significado que configurar max-rate=X × N.
  • En un NEG zonal con extremos N, la configuración de max-rate-per-endpoint=X tiene el mismo significado que la opción de configuración max-rate=X × N.

Modo de balanceo de uso

El modo de balanceo UTILIZATION no tiene una capacidad de destino requerida. Tienes una serie de opciones que dependen del tipo de backend, como se resume en la tabla de la sección siguiente.

La capacidad de destino max-utilization solo se puede especificar por grupo de instancias y no se puede aplicar a una VM específica del grupo.

El modo de balanceo UTILIZATION no tiene una capacidad de destino requerida. Cuando usas la consola de Google Cloud para agregar un grupo de instancias de backend a un servicio de backend, la consola de Cloud establece el valor de max-utilization en 0.8 (80%) si el modo de balanceo UTILIZATION está seleccionado. Además de max-utilization, el modo de balanceo UTILIZATION admite capacidades de destino más complejas, como se resume en la tabla en la siguiente sección.

Cambia el modo de balanceo de un balanceador de cargas

En algunos balanceadores de cargas o sus configuraciones, no puedes cambiar el modo de balanceo porque el servicio de backend tiene solo un modo de balanceo posible. Para otros, según el backend usado, puedes cambiar el modo de balanceo porque hay más de un modo disponible para esos servicios de backend.

A fin de ver qué modos de balanceo son compatibles para cada balanceador de cargas, consulta Tabla: Modos de balanceo disponibles para cada balanceador de cargas.

Modos de balanceo y configuración de la capacidad objetivo

En esta tabla, se resumen todos los modos de balanceo posibles para un balanceador de cargas y un tipo de backend determinados. También, se muestra la configuración de capacidad disponible o requerida que debes especificar con el modo de balanceo.

Tabla: Especificación de la capacidad de destino de los modos de balanceo
Balanceador de cargas Tipo de backend Modo de balanceo Capacidad de destino
  • Balanceador de cargas de HTTP(S) externo global
  • Balanceador de cargas de HTTP(S) global externo (clásico)
  • Balanceador de cargas HTTP(S) regional externo
  • Balanceador de cargas HTTP(S) interno
  • Traffic Director
 Grupo de instancias RATE Debes especificar uno de los siguientes valores:
  • max-rate por grupo de instancias zonales
  • max-rate-per-instance
    (grupos de instancias zonales o regionales)
UTILIZATION De manera opcional, puedes especificar una de las siguientes opciones:
  • (1) max-utilization
  • (2) max-rate por grupo de instancias zonales
  • (3) max-rate-per-instance
    (grupos de instancias zonales o regionales)
  • (1) y (2) combinadas.
  • (1) y (3) combinadas.
NEG zonal (GCP_VM_IP_PORT) RATE Debes especificar uno de los siguientes valores:
  • max-rate por NEG zonal
  • max-rate-per-endpoint
NEG híbrido (NON_GCP_PRIVATE_IP_PORT) RATE Debes especificar uno de los siguientes valores:
  • max-rate por NEG híbrido
  • max-rate-per-endpoint
  • Balanceador de cargas de proxy SSL externo
  • Balanceador de cargas de proxy TCP externo
  • Balanceador de cargas del proxy TCP regional interno
 Grupo de instancias CONNECTION Debes especificar uno de los siguientes valores:
  • max-connections por grupo de instancias zonales
  • max-connections-per-instance (grupos de instancias zonales o regionales)
UTILIZATION De manera opcional, puedes especificar una de las siguientes opciones:
  • (1) max-utilization
  • (2) max-connections por grupo de instancias zonales
  • (3) max-connections-per-instance
    (grupos de instancias zonales o regionales)
  • (1) y (2) combinadas.
  • (1) y (3) combinadas.
NEG zonal (GCP_VM_IP_PORT) CONNECTION Debes especificar uno de los siguientes valores:
  • max-connections por NEG zonal
  • max-connections-per-endpoint
NEG híbrido (NON_GCP_PRIVATE_IP_PORT)
(compatible con el balanceador de cargas de proxy TCP regional interno) 		CONNECTION Debes especificar uno de los siguientes valores:
  • max-connections por NEG híbrido
  • max-connections-per-endpoint
Balanceadores de cargas TCP/UDP internos Grupo de instancias CONNECTION No puedes especificar una cantidad objetivo máxima de conexiones.
NEG zonales (GCP_VM_IP) CONNECTION No puedes especificar una cantidad objetivo máxima de conexiones.
Balanceador de cargas de red de TCP/UDP externo Grupo de instancias CONNECTION No puedes especificar una cantidad objetivo máxima de conexiones.

Escalador de capacidad

Para ciertas configuraciones de balanceador de cargas de proxy, puedes ajustar el escalador de capacidad a fin de escalar la capacidad de destino efectiva (uso de destino efectivo, tasa de destino efectiva o conexiones de destino efectivas) sin cambiar de forma explícita uno de los parámetros --max-*.

De forma predeterminada, el valor del escalador de capacidad es 1.0 (100%). Puedes configurar el escalador de capacidad con cualquiera de estos valores:

  • exactamente 0.0, lo que evitará todas las conexiones nuevas
  • un valor entre 0.1 (10%) y 1.0 (100%)

En los siguientes ejemplos, se demuestra cómo funciona el escalador de capacidad junto con la configuración de capacidad objetivo.

  • Si el modo de balanceo es RATE, la tasa máxima se establece en 80 RPS y el escalador en 1.0, y la capacidad objetivo efectiva también es de 80 RPS.

  • Si el modo de balanceo es RATE, el uso máximo se establece en 80 RPS y el escalador en 0.5, y la capacidad objetivo efectiva es de 40 RPS (0.5 times 80).

  • Si el modo de balanceo es RATE, el uso máximo se establece en 80 RPS y el escalador en 0.0, y la capacidad objetivo efectiva es cero. Un escalador de capacidad de cero quitará el backend de la rotación.

Traffic Director y la distribución de tráfico

Traffic Director también usa recursos de servicio de backend. De forma específica, Traffic Director usa servicios de backend cuyo esquema de balanceo de cargas es INTERNAL_SELF_MANAGED. Para un servicio de backend interno autoadministrado, la distribución de tráfico se basa en la combinación de un modo de balanceo de cargas y una política de balanceo de cargas. El servicio de backend dirige el tráfico a un backend según el modo de balanceo del backend. Luego, Traffic Director distribuye el tráfico según una política de balanceo de cargas.

Los servicios de backend internos autoadministrados son compatibles con los siguientes modos de balanceo:

  • UTILIZATION, si todos los backends son grupos de instancias
  • RATE, si todos los backends son grupos de instancias o NEG zonales

Si eliges el modo de balanceo RATE, debes especificar una tasa máxima, una tasa máxima por instancia o una tasa máxima por extremo.

Para obtener más información sobre Traffic Director, consulta los conceptos de Traffic Director.

Subconjuntos de backend

La subdivisión de backends es una función opcional que mejora el rendimiento y la escalabilidad mediante la asignación de un subconjunto de backends a cada una de las instancias de proxy.

La subdivisión de backends es compatible con lo siguiente:

  • Balanceo de cargas HTTP(S) interno
  • Balanceo de cargas TCP/UDP interno

Subdivisión de backends para el balanceador de cargas HTTP(S) interno

Para los balanceadores de cargas HTTP(S) internos, la subdivisión de backends asigna automáticamente solo una subdivisión de los backends dentro del servicio de backend regional a cada instancia de proxy.

De forma predeterminada, cada instancia de proxy del balanceador de cargas de HTTP(S) interno abre conexiones con todos los backends dentro de un servicio de backend. Cuando la cantidad de instancias de proxy y los backends son conexiones grandes de apertura a todos los backends, puede haber problemas de rendimiento. Mediante la habilitación del subconjunto, cada proxy solo abre conexiones a un subconjunto de backends, lo que reduce la cantidad de conexiones que se mantienen abiertas a cada backend. Reducir la cantidad de conexiones abiertas a cada backend puede mejorar el rendimiento de los backends y los proxies.

En el siguiente diagrama, se muestra un balanceador de cargas con dos proxies. Sin la subconfiguración de backend, el tráfico de ambos proxies se distribuye a todos los backends en el servicio de backend 1. Con el subconjunto del backend habilitado, el tráfico de cada proxy se distribuye a un subconjunto de los backends. El tráfico del proxy 1 se distribuye a los backends 1 y 2, y el tráfico del proxy 2 se distribuye a los backends 3 y 4.

Compara el balanceador de cargas https interno sin y con la división de backend.
Comparación del balanceador de cargas HTTP(S) interno sin subdivisión de backends y con ella.

Además, puedes definir mejor el tráfico del balanceo de cargas en los backends si configuras la política localityLbPolicy. Para obtener más información, consulta Políticas de tráfico.

Si deseas leer sobre la configuración de la subdivisión de backends para balanceadores de cargas HTTP(S) internos, consulta Configura la subdivisión de backends.

Advertencias relacionadas con la subdivisión de backends para el balanceador de cargas HTTP(S) interno
  • Aunque los subconjuntos de backend están diseñados para garantizar que todas las instancias de backend se mantengan bien usadas, pueden generar sesgos en la cantidad de tráfico que recibe cada backend. Se recomienda configurar localityLbPolicy en LEAST_REQUEST para los servicios de backend sensibles al balanceo de cargas de backend.
  • Si se habilita o se inhabilita la subdivisión, se interrumpen las conexiones existentes.
  • La subdivisión de backends requiere que la afinidad de sesión sea NONE (un hash de 5 tuplas). Otras opciones de afinidad de sesión solo se pueden usar si la subdivisión de backends está inhabilitada. Los valores predeterminados de las marcas --subsetting-policy y --session-affinity son NONE, y solo uno de ellos a la vez se puede establecer en un valor diferente.

Subdivisión de backends para el balanceador de cargas TCP/UDP interno

La subdivisión de backends para los balanceadores de cargas TCP/UDP internos te permiten escalar tu balanceador de cargas TCP/UDP interno a fin de admitir una mayor cantidad de instancias de VM de backend por servicio de backend interno.

Para obtener información sobre cómo la subdivisión afecta este límite, consulta la sección “Servicios de backend” de las cuotas y los límites de recursos del balanceo de cargas.

De forma predeterminada, la subdivisión está inhabilitada, lo que limita el servicio de backend a una distribución de hasta 250 instancias de backend o extremos. Si tu servicio de backend necesita admitir más de 250 backends, puedes habilitar la subdivisión. Cuando se habilita la subdivisión, se selecciona un subconjunto de instancias de backend para cada conexión de cliente.

En el siguiente diagrama, se muestra un modelo reducido de la diferencia entre estos dos modos de operación.

Compara un balanceador de cargas TCP/UDP interno sin y con subdivisión (haz clic para ampliar)
Compara un balanceador de cargas TCP/UDP interno sin y con subdivisión (haz clic para ampliar)

Sin la subdivisión, el conjunto completo de backends en buen estado se usa mejor, y las conexiones de clientes nuevas se distribuyen entre todos los backends en buen estado según la distribución de tráfico. La subposición impone restricciones de balanceo de cargas, pero permite que el balanceador de cargas admita más de 250 backends.

Para obtener instrucciones de configuración, consulta Subdivisión.

Advertencias relacionadas con la subdivisión de backends para el balanceador de cargas TCP/UDP interno
  • Cuando la subdivisión está habilitada, no todos los backends recibirán tráfico de un remitente determinado, incluso cuando la cantidad de backends sea pequeña.
  • Para obtener la cantidad máxima de instancias de backend cuando los subconjuntos están habilitados, consulta la página de cuotas.
  • Solo la afinidad de sesión de 5 tuplas es compatible con la subdivisión.
  • La duplicación de paquetes no es compatible con la subdivisión.
  • Si se habilita o se inhabilita la subdivisión, se interrumpen las conexiones existentes.
  • Si los clientes locales necesitan acceder a un balanceador de cargas TCP/UDP interno, la subdivisión puede reducir de forma sustancial la cantidad de backends que reciben conexiones de tus clientes locales. Esto se debe a que la región del túnel de Cloud VPN o el adjunto de VLAN de Cloud Interconnect determina el subconjunto de backends del balanceador de cargas. Todos los extremos de Cloud VPN y Cloud Interconnect en una región específica usan el mismo subconjunto. Se usan diferentes subconjuntos en diferentes regiones.

Precios de la división de backend

No se aplican cargos por el uso de división de backend. Para obtener más información, consulta Todos los precios de herramientas de redes.

Afinidad de sesión

La afinidad de sesión te permite controlar cómo el balanceador de cargas selecciona backends para conexiones nuevas de manera predecible, siempre que la cantidad de backends en buen estado se mantenga constante. Esto es útil para las aplicaciones que necesitan que varias solicitudes de un usuario determinado se dirijan al mismo backend o extremo. Estas aplicaciones incluyen servidores con estado que usan la publicación de anuncios, los juegos o los servicios con almacenamiento en caché interno intenso.

Los balanceadores de cargas de Google Cloud proporcionan afinidad de sesión en función del mejor esfuerzo. Factores como los cambios en los estados de la verificación de estado del backend, agregar o quitar backends, o cambios en el contenido total del backend, según la medición del modo de balanceo, pueden interrumpir la afinidad de sesión.

El balanceo de cargas con afinidad de sesión funciona bien cuando hay una distribución razonable grande de conexiones únicas. Razonablemente grande significa al menos varias veces la cantidad de backends. Probar un balanceador de cargas con una cantidad pequeña de conexiones no dará como resultado una representación precisa de la distribución de las conexiones de cliente entre backends.

De forma predeterminada, todos los balanceadores de cargas de Google Cloud seleccionan backends mediante un hash quíntuple (--session-affinity=NONE), de la siguiente manera:

  • Dirección IP de origen del paquete
  • El puerto de origen del paquete (si está presente en el encabezado del paquete)
  • Dirección IP de destino del paquete
  • El puerto de destino del paquete (si está presente en el encabezado del paquete)
  • Protocolo del paquete

Para los balanceadores de cargas de paso, las conexiones nuevas se distribuyen a extremos o instancias de backend en buen estado (en el grupo activo, si se configura una política de conmutación por error). Puedes controlar lo siguiente:

Para los balanceadores de cargas basados en proxy, 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, las solicitudes o conexiones posteriores van al mismo extremo o VM de backend. 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 muestran las opciones de afinidad de sesión compatibles con cada producto:

Tabla: Configuración de afinidad de sesión compatible
Producto Opciones de afinidad de sesión
  • Ninguno (NONE)
  • IP de cliente (CLIENT_IP)
  • Cookie generada (GENERATED_COOKIE)
  • Campo de encabezado (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)

También ten en cuenta lo siguiente:

  • La configuración de afinidad de sesión se cumple solo si la política de localidad del balanceo de cargas (LocalityLbPolicy) se establece en RING_HASH o MAGLEV.
  • Para el balanceador de cargas de HTTP(S) global externo, no configures la afinidad de sesión si usas la división de tráfico ponderada. Si lo haces, la configuración de división de tráfico ponderada tiene prioridad.
Balanceador de cargas de HTTP(S) global externo (clásico)
  • Ninguno (NONE)
  • IP de cliente (CLIENT_IP)
  • Cookie generada (GENERATED_COOKIE)
Balanceador de cargas HTTP(S) interno
  • Ninguno (NONE)
  • IP de cliente (CLIENT_IP)
  • Cookie generada (GENERATED_COOKIE)
  • Campo de encabezado (HEADER_FIELD)
  • Cookie HTTP (HTTP_COOKIE)

La configuración de afinidad de sesión se cumple solo si la política de localidad del balanceo de cargas (LocalityLbPolicy) se establece en RING_HASH o MAGLEV.
Balanceadores de cargas TCP/UDP internos
  • Ninguno (NONE)
  • IP DE CLIENTE sin destino (vista previa) (CLIENT_IP_NO_DESTINATION)
  • IP de cliente, IP de destino (CLIENT_IP)
  • IP de cliente, IP de destino, protocolo (CLIENT_IP_PROTO)
  • IP de cliente, puerto de cliente, IP de destino, puerto de destino, protocolo (CLIENT_IP_PORT_PROTO)

Para obtener información específica sobre el balanceo de cargas TCP/UDP interno y la afinidad de sesión, consulta la descripción general del balanceo de cargas TCP/UDP interno.
Balanceador de cargas de red1
  • Ninguno (NONE)
  • IP de cliente, IP de destino (CLIENT_IP)
  • IP de cliente, IP de destino, protocolo (CLIENT_IP_PROTO)
  • IP de cliente, puerto de cliente, IP de destino, puerto de destino, protocolo (CLIENT_IP_PORT_PROTO)

Para obtener información específica sobre el balanceo de cargas de red y la afinidad de sesión, consulta la descripción general del balanceo de cargas de red de TCP/UDP externo.
  • Ninguno (NONE)
  • IP de cliente (CLIENT_IP)
Traffic Director
  • Ninguno (NONE)
  • IP de cliente (CLIENT_IP)
  • Cookie generada (GENERATED_COOKIE) (solo protocolos HTTP)
  • Campo de encabezado (HEADER_FIELD) (solo protocolos HTTP)
  • Cookie HTTP (HTTP_COOKIE) (solo protocolos HTTP)

Cuando se configuran servicios de gRPC sin proxy, Traffic Director no es compatible con la afinidad de sesión.

1 En esta tabla, se documentan los afinidades de sesión que admiten los balanceadores de cargas de red basados en servicios de backend. Los balanceadores de cargas de red basados en grupos de destino no usan servicios de backend. En su lugar, debes establecer la afinidad de sesión para los balanceadores de cargas de red a través del parámetro sessionAffinity en grupos de destino.

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 está diseñada para interrumpirse cada vez que cambia la cantidad de backends activos y en buen estado. Las actividades que generan la interrupción de la afinidad de sesión incluyen las siguientes:

    • Agregar grupos de instancias de backend o NEG al servicio de backend
    • Quita grupos de instancias de backend o NEG del servicio de backend
    • Agregar instancias a un grupo de instancias de backend existente (lo que ocurre de forma automática cuando habilitas el ajuste de escala automático con grupos de instancias administrados)
    • Quitar instancias de un grupo de instancias de backend existente (lo que ocurre de forma automática cuando habilitas el ajuste de escala automático en grupos de instancias administrados)
    • Agregar extremos a un NEG de backend existente
    • Quitar extremos de un NEG de backend existente
    • Cuando un backend en buen estado falla su verificación de estado y queda en mal estado
    • Cuando un backend en mal estado pasa su verificación de estado y queda en buen estado
    • Para los balanceadores de cargas de paso: durante la conmutación por error y por recuperación, si se configura una política de conmutación por error
    • Para los balanceadores de cargas de proxy, cuando un backend alcanza o supera su máxima capacidad

  • No se recomienda usar una afinidad de sesión distinta de None con el modo de balanceo UTILIZATION. Esto se debe a que los cambios en el uso de la instancia pueden hacer que el servicio de balanceo de cargas dirija nuevas solicitudes o conexiones a VM de backend que estén menos completas. Esto interrumpe la afinidad de sesión. En su lugar, usa el modo de balanceo RATE o CONNECTION para reducir la posibilidad de interrumpir la afinidad de sesión. Para obtener más información, consulta Pérdida de afinidad de sesión.

  • En el caso de los balanceadores de cargas HTTP(S) internos y externos, la afinidad de sesión puede interrumpirse cuando el extremo o la instancia previstos superan el máximo establecido del modo de balanceo. Considera el siguiente ejemplo:

    • Un balanceador de cargas tiene un NEG y tres extremos.
    • Cada extremo tiene una capacidad objetivo de 1 RPS.
    • El modo de balanceo es RATE.
    • En este momento, cada extremo procesa las solicitudes 1.1, 0.8 y 1.6 RPS, respectivamente.
    • Cuando una solicitud HTTP con afinidad para el último extremo llega al balanceador de cargas, la afinidad de sesión reclama el extremo que se procesa a 1.6 RPS.
    • La solicitud nueva puede ir al extremo central con 0.8 RPS.

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

En las siguientes secciones, se analizan los diferentes tipos de afinidad de sesión.

IP de cliente sin afinidad de destino

La IP de cliente sin afinidad (CLIENT_IP_NO_DESTINATION) de destino dirige las solicitudes de la misma dirección IP de origen del cliente a la misma instancia de backend.

Cuando uses una IP de cliente, sin afinidad de destino ten en cuenta lo siguiente:

  • La IP de cliente sin afinidad de destino es un hash de una tupla que consiste en la dirección IP de origen del cliente.

  • Si un cliente se traslada de una red a otra, su dirección IP cambiará, lo que da como resultado una afinidad interrumpida.

La IP de cliente sin afinidad de destino es solo una opción para los balanceadores de cargas TCP/UDP internos.

Afinidad de IP de cliente

La afinidad de IP de cliente (CLIENT_IP) dirige las solicitudes de la misma dirección IP de cliente a la misma instancia de backend. La afinidad de IP de cliente es una opción para todos los balanceadores de cargas de Google Cloud que usan servicios de backend.

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

  • La afinidad de IP de cliente es un hash de dos tuplas que consiste en la dirección IP de cliente y la dirección IP de la regla de reenvío del balanceador de cargas con la que se comunica el cliente.

  • Es posible que la dirección IP de cliente, como la ve el balanceador de cargas, no sea el cliente de origen si está detrás de NAT o realiza solicitudes a través de un proxy. Las solicitudes realizadas a través de NAT o un proxy usan la dirección IP del proxy o enrutador NAT como la dirección IP de cliente. Esto puede hacer que el tráfico entrante se acumule de manera innecesaria en las mismas instancias de backend.

  • Si un cliente se traslada de una red a otra, su dirección IP cambiará, lo que da como resultado una afinidad interrumpida.

Para obtener información sobre qué productos son compatibles con la afinidad de IP de cliente, consulta Tabla: Configuración de afinidad de sesión compatible.

Cuando se establece la afinidad de cookie generada, el balanceador de cargas emite una cookie en la primera solicitud. Para cada solicitud posterior con la misma cookie, el balanceador de cargas dirige la solicitud al mismo extremo o VM de backend.

  • Para los balanceadores de cargas de HTTP(S) externos globales, la cookie se llama GCLB.
  • Para los balanceadores de cargas HTTP(S) regionales externos, los balanceadores de cargas HTTP(S) internos y Traffic Director, la cookie se llama GCILB.

La afinidad basada en cookies puede identificar con mayor precisión a un cliente que a un balanceador de cargas, en comparación con la afinidad basada en IP de cliente. Por ejemplo:

  1. Con la afinidad basada en cookies, el balanceador de cargas puede identificar de forma única dos o más sistemas cliente que comparten la misma dirección IP de origen. Mediante la afinidad basada en IP de cliente, el balanceador de cargas trata todas las conexiones que provienen de la misma dirección IP de origen como si provinieran del mismo sistema cliente.

  2. Si un cliente cambia su dirección IP, la afinidad basada en cookies permite que el balanceador de cargas reconozca las conexiones posteriores de ese cliente en lugar de tratar la conexión como nueva. Un ejemplo de cuándo un cliente cambia su dirección IP es cuando un dispositivo móvil se traslada de una red a otra.

Cuando un balanceador de cargas crea una cookie para la afinidad generada basada en cookies, establece el atributo path de la cookie en /. Si el comparador de rutas del mapa de la URL tiene varios servicios de backend para un nombre de host, todos los servicios de backend comparten la misma cookie de sesión.

La vida útil de la cookie HTTP generada por el balanceador de cargas se puede configurar. Puedes configurarla en 0 (predeterminado), lo que significa que la cookie es solo una cookie de sesión. O puedes establecer la vida útil de la cookie en un valor de 1 a 86400 segundos (24 horas) inclusive.

Para obtener información sobre qué productos admiten la afinidad de cookie generada, consulta Tabla: Configuración de afinidad de sesión compatible.

Afinidad de campo de encabezado

Traffic Director y un balanceador de cargas de HTTP(S) interno se pueden usar 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).

Para obtener información sobre qué productos admiten la afinidad de campo de encabezado, consulta Tabla: Configuración de afinidad de sesión compatible.

Traffic Director y un balanceador de cargas de HTTP(S) interno pueden usar la afinidad de cookie HTTP cuando se cumplen las siguientes condiciones:

  • La política de localidad del balanceo de cargas es RING_HASH o MAGLEV.
  • El hash coherente del servicio de backend especifica el nombre de la cookie HTTP.

La afinidad de cookie HTTP enruta las solicitudes a extremos o VM de backend en un NEG en función de la cookie HTTP que se indica en la marca HTTP_COOKIE. Si el cliente no proporciona la cookie, el proxy la generará y la mostrará al cliente en un encabezado Set-Cookie.

Para obtener información sobre qué productos son compatibles con la afinidad de IP de cookie HTTP, consulta Tabla: Configuración de afinidad de sesión compatible.

Pérdida de la afinidad de sesión

Sin importar el tipo de afinidad elegida, un cliente puede perder afinidad con un backend en las siguientes situaciones:

  • Si el grupo de instancias de backend o el NEG zonal se quedan sin capacidad, según lo define la capacidad de destino del modo de balanceo. En esta situación, Google Cloud dirige el tráfico a un grupo de instancias de backend o un NEG zonal diferente, que pueden estar en una zona distinta. Puedes mitigar esto si te aseguras de especificar la capacidad de destino correcta para cada backend según tus propias pruebas.
  • El ajuste de escala automático agrega o quita instancias de un grupo de instancias administrado. Cuando esto sucede, la cantidad de instancias en el grupo de instancias cambia, por lo que el servicio de backend vuelve a calcular los hash para la afinidad de sesión. Para mitigar esto, asegúrate de que el tamaño mínimo del grupo de instancias administrado pueda manejar una carga típica. El ajuste de escala automático solo se realiza durante aumentos inesperados en la carga.
  • Si un extremo o una VM de backend en un NEG fallan en las verificaciones de estado, el balanceador de cargas dirige el tráfico a otro backend en buen estado. Consulta la documentación de cada balanceador de cargas de Google Cloud para obtener detalles sobre cómo se comporta el balanceador de cargas cuando todos sus backends fallan en las verificaciones de estado.
  • Cuando el modo de balanceo UTILIZATION está activo en los grupos de instancias de backend, la afinidad de sesión se interrumpe debido a cambios en el uso del backend. Puedes mitigar esto mediante el uso de los modos de balanceo RATE o CONNECTION, el que sea compatible con el tipo de balanceador de cargas.

Cuando uses el balanceo de cargas de HTTP(S), de proxy SSL externo o de proxy TCP externo, ten en cuenta los siguientes puntos adicionales:

  • Si la ruta de acceso de enrutamiento de un cliente en Internet a Google cambia entre solicitudes o conexiones, es posible que se seleccione otro Google Front End (GFE) como proxy. Esto puede interrumpir la afinidad de sesión.
  • Cuando usas el modo de balanceo UTILIZATION, en particular si no tienes una capacidad máxima de destino definida, es probable que la afinidad de sesión se interrumpa cuando el tráfico al balanceador de cargas sea bajo. Cambia al modo de balanceo RATE o CONNECTION, según lo admita el balanceador de cargas elegido.

Tiempo de espera del servicio de backend

La mayoría de los balanceadores de cargas de Google Cloud tienen un tiempo de espera del servicio de backend. El valor predeterminado es 30 segundos. El rango completo de valores de tiempo de espera permitidos es de 1 a 2,147,483,647 segundos.

  • Para los balanceadores de cargas HTTP(S) internos y externos que usan el protocolo HTTP, HTTPS o HTTP/2, el tiempo de espera del servicio de backend es de solicitud y respuesta para el tráfico HTTP(S).

    A fin de obtener más detalles sobre el tiempo de espera del servicio de backend para cada balanceador de cargas, consulta los siguientes vínculos:

  • En el caso de los balanceadores de cargas de proxy SSL y TCP externos, el tiempo de espera es de inactividad. Para permitir más o menos tiempo antes de que se borre la conexión, cambia el valor del tiempo de espera. Este tiempo de espera de inactividad también se usa para las conexiones de WebSocket.

  • Para los balanceadores de cargas TCP/UDP internos y los de red, puedes establecer el valor del tiempo de espera del servicio de backend con gcloud o la API, pero se ignorará el valor. El tiempo de espera del servicio de backend no significa nada para estos balanceadores de cargas de paso.

  • Para Traffic Director, el campo del tiempo de espera del servicio de backend (especificado mediante timeoutSec) no es compatible con los servicios de gRPC sin proxy. Para esos servicios, configura el tiempo de espera del servicio de backend mediante el campo maxStreamDuration. Esto se debe a que gRPC no admite la semántica de timeoutSec, que especifica la cantidad de tiempo que se debe esperar para que un backend muestre una respuesta completa después de enviar la solicitud. El tiempo de espera de gRPC especifica el tiempo que se debe esperar desde el comienzo de la transmisión hasta que la respuesta se haya procesado por completo, incluidos todos los reintentos.

Verificaciones de estado

Cada servicio de backend cuyos backends son grupos de instancias o NEG zonales debe tener una verificación de estado asociada. Los servicios de backend que usan un NEG sin servidores o un NEG de Internet como backend no deben hacer referencia a una verificación de estado.

Cuando creas un balanceador de cargas mediante la consola de Google Cloud, puedes crear la verificación de estado, si es necesaria, cuando creas el balanceador de cargas, o puedes hacer referencia a una verificación de estado existente.

Cuando creas un servicio de backend mediante backends de grupo de instancias o de NEG zonales con la CLI de Google Cloud o la API, debes hacer referencia a una verificación de estado existente. Consulta la guía de balanceadores de cargas en la Descripción general de las verificaciones de estado para obtener detalles sobre el tipo y el alcance de la verificación de estado requerida.

Para obtener más información, lee los siguientes documentos:

Google Cloud Armor

Si usas uno de los siguientes balanceadores de cargas, puedes agregar protección adicional a tus aplicaciones si habilitas Google Cloud Armor durante la creación del balanceador de cargas:

Si usas la consola de Google Cloud, puedes realizar una de las siguientes acciones:

  • Selecciona una política de seguridad de Google Cloud Armor existente.

  • Acepta la configuración de una política de seguridad predeterminada para el límite de frecuencia de Google Cloud Armor con un nombre, recuento de solicitudes, intervalo, clave y parámetros de límite de frecuencia personalizables. Si usas Google Cloud Armor con un servicio de proxy ascendente, como un proveedor de CDN, Enforce_on_key debe configurarse como una dirección IP de XFF.

  • Si deseas inhabilitar la protección de Google Cloud Armor, selecciona Ninguna.

Funciones adicionales habilitadas en el recurso de servicio de backend

Algunas funciones opcionales de Google Cloud (como Cloud CDN y Google Cloud Armor) están disponibles para los servicios de backend que usan los balanceadores de cargas de HTTP(S) externos globales. Google Cloud Armor también es compatible con balanceadores de cargas de proxy SSL externos y balanceadores de cargas de proxy TCP externos.

Para obtener más información, consulte:

Funciones de la administración del tráfico

Las siguientes funciones solo son compatibles con algunos productos:

Las siguientes funciones son compatibles con los siguientes balanceadores de cargas:

  • Balanceador de cargas de HTTP(S) externo global (no se admite la interrupción de circuitos)
  • Balanceador de cargas HTTP(S) regional externo
  • Balanceador de cargas HTTP(S) interno
  • Traffic Director (pero no es compatible con los servicios de gRPC sin proxy)

API y referencia de gcloud

Para obtener más información sobre las propiedades del recurso del servicio de backend, consulta las siguientes referencias:

¿Qué sigue?

Para obtener información y documentación sobre cómo se usan los servicios de backend en el balanceo de cargas, consulta las siguientes páginas:

Para ver videos relacionados, consulta lo siguiente: