Descripción general de los servicios de backend

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.

Puedes configurar un servicio de backend para los siguientes servicios de balanceo de cargas de Google Cloud:

  • Balanceo de cargas de HTTP(S) externo
  • Balanceo de cargas de HTTP(S) interno
  • Balanceo de cargas de proxy SSL
  • Balanceo de cargas de proxy TCP
  • Balanceo de cargas TCP/UDP interno
  • Balanceo de cargas de redes TCP/UDP externo

Traffic Director también usa servicios de backend.

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). Puedes configurar un balanceador de cargas de HTTP(S) externo para usar un bucket de backend en lugar de un servicio de backend. Para obtener información sobre el uso de depósitos de backend con balanceadores de cargas de HTTP(S) externos, consulta Configura un balanceador de cargas con depósitos de backend
  • 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:
    • Cloud CDN, solo balanceadores de cargas de HTTP(S) externos
    • Políticas de seguridad de Google Cloud Armor,solo balanceadores de cargas de HTTP(S) externos
    • Identity-Aware Proxy, solo balanceadores de cargas HTTP(S) externos

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

Un servicio de backend puede tener un alcance global o regional.

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

El producto que usas, que es un balanceador de cargas o Traffic Director, determina lo siguiente:

  • Cantidad máxima de servicios de backend
  • Alcance de un servicio de backend
  • Tipo de backends que puede usar cada servicio de backend
  • Esquema del balanceo de cargas del servicio de backend
Producto Cantidad máxima de servicios de backend Alcance del servicio de backend Tipos de backends compatibles Esquema de balanceo de cargas
Balanceo de cargas de HTTP(S) externo Varias Global1 Cada servicio de backend admite estas 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
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
  • Todos los NEG sin servidores: Uno o más servicios de App Engine, Cloud Run o Cloud Functions
  • Un NEG de Internet
EXTERNAL
Balanceo de cargas de HTTP(S) interno Varias Regional Cada servicio de backend admite estas 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
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
INTERNAL_MANAGED
Balanceo de cargas de proxy SSL 1 Global1 El servicio de backend admite estas 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
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT, o bien
  • Un NEG de Internet
EXTERNAL
Balanceo de cargas de proxy TCP 1 Global1 El servicio de backend admite estas 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
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT, o bien
  • Un NEG de Internet
EXTERNAL
Balanceo de cargas de red 1 Discos El servicio de backend admite esta combinación 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
Balanceo de cargas de TCP/UDP interno 1 Regional, pero configurable para que sea accesible a nivel global El servicio de backend admite estas 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, o bien
  • 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 estas 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
  • Todos los NEG zonales: Uno o más NEG zonales de tipo GCE_VM_IP_PORT
INTERNAL_SELF_MANAGED
1 Los servicios de backend que usa el balanceo de cargas de HTTP(S), de proxy SSL y de proxy TCP siempre son globales, ya sea en los niveles de red Estándar o Premium. However, in Standard Tier the following restrictions apply:

Backends

Un backend es un grupo de 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:

Además, mediante un bucket de backend en lugar de un servicio de backend, puedes tener un backend de bucket de Cloud Storage.

No puedes usar tipos de backends diferentes con el mismo servicio de backend. Por ejemplo, un solo servicio de backend no puede hacer referencia a una combinación de grupos de instancias y NEG zonales. Sin embargo, 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.

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.

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.

Producto Esquema de balanceo de cargas Opciones de protocolo del servicio de backend
Balanceo de cargas HTTP(S) externo EXTERNAL HTTP, HTTPS, HTTP/2
Balanceo de cargas del proxy de SSL EXTERNAL SSL
Balanceo de cargas del proxy de TCP EXTERNAL TCP
Balanceo de cargas HTTP(S) interno INTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Balanceo de cargas de red EXTERNAL TCP, UDP o UNSPECIFIED (vista previa)
Balanceo de cargas TCP/UDP interno 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.

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, de proxy SSL y de proxy TCP: los clientes se comunican con un Google Front End (GFE) mediante la dirección IP externa del balanceador de cargas. GFE se comunica con los extremos o las VM de backend mediante una combinación de un identificador de la red de VPC del backend y la VM o la dirección IP interna del extremo. Las direcciones IP internas deben estar asociadas a la interfaz de la red principal (nic0) del backend. La comunicación entre los GFE y los extremos o VM de backend se facilita mediante rutas especiales.
  • En el caso de los balanceadores de cargas de red, los paquetes primero se enrutan a la dirección IP externa del balanceador de cargas de red. Luego, el balanceador de cargas usa un hash coherente para enrutarlos a las VM de backend.
  • Para los balanceadores de cargas de HTTP(S) internos, balanceadores de cargas de TCP/UDP internos y Traffic Director: Las VM de backend no requieren direcciones IP externas.

Puertos con nombre

En el backend, el balanceador de cargas reenvía el tráfico a los números de puerto que escuchan las instancias de backend (instancias de Compute Engine). Este número de puerto se configura en el grupo de instancias y se hace referencia a él en la configuración del servicio de backend.

Si el puerto con nombre de un grupo de instancias coincide con --port-name en la configuración del servicio de backend, el servicio de backend usa este número de puerto para la comunicación con las VM del grupo de instancias.

El número de puerto de backend se denomina puerto con nombre porque es un par nombre/valor. En el grupo de instancias, define el nombre y el valor de la clave para el puerto.

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

Si usas varios números de puerto para un puerto con nombre (por ejemplo, http:80,http:8080), todos deben ser para la misma aplicación. Esto se debe a que el tráfico se balancea entre todos los puertos con el mismo nombre de puerto. Por ejemplo, no puedes crear un puerto con nombre con los valores 80 y 443. Esto no funciona porque el puerto 80 suele no ser compatible con TLS.

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

Ten en cuenta lo siguiente:

  • Cada servicio de backend se suscribe a un solo nombre de puerto. Cada uno de sus grupos de instancias de backend debe tener al menos un puerto con nombre para ese nombre.

  • 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. Sin embargo, todos los puertos deben representar la misma aplicación. Por ejemplo, http:80,http:8080 funciona, pero http:80,http:443 no.

  • El número de puerto resuelto que usa el servicio de backend no necesita coincidir con el número de puerto que usan las reglas de reenvío del balanceador de cargas. Un balanceador de cargas escucha el frontend en uno o más números de puerto que configuras en la regla de reenvío del balanceador de cargas. Las instancias de backend pueden escuchar en números de puertos diferentes.

Los puertos con nombre no se usan en las siguientes circunstancias:

  • Para backends de NEG zonales o NEG de Internet, porque estos NEG definen puertos mediante un mecanismo diferente, es decir, en los extremos.
  • Para backends de NEG sin servidores, porque estos NEG no tienen extremos.
  • Para los balanceadores de cargas de TCP/UDP internos, porque son balanceadores de cargas de paso, no proxies. Además, su servicio de backend no se suscribe a un puerto con nombre.
  • Para los balanceadores de cargas de red, porque son balanceadores de cargas de paso, no proxies, y su servicio de backend no se suscribe a un puerto con nombre.

Para obtener más información sobre los puertos con nombre, consulta gcloud compute instance-groups managed set-named-ports y gcloud compute instance-groups unmanaged set-named-ports en la documentación del SDK.

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. Estas son las combinaciones incompatibles:

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

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

  • Extremos de GCE_VM_IP.
  • Extremos de GCE_VM_IP_PORT.

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

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.

Los grupos de extremos de red por zonas (NEG) que usan extremos GCE_VM_IP_PORT se pueden usar como backends para los siguientes tipos de balanceadores de cargas:

  • Balanceo de cargas HTTP(S) interno
  • Balanceo de cargas de HTTP(S)
  • Balanceo de cargas de proxy SSL
  • Balanceo de cargas del proxy de TCP

Traffic Director también es compatible con backends de NEG zonales con extremos GCE_VM_IP_PORT.

Los grupos de extremos de red por zonas (NEG) que usan extremos GCE_VM_IP se pueden usar como backends solo para el balanceo de cargas TCP/UDP interno.

El balanceo de cargas de red no admite los NEG zonales.

Para obtener más información, consulta Descripción general de los grupos de extremos de red en el balanceo de cargas.

Grupos de extremos de red de Internet

Los NEG de Internet son recursos globales que se alojan dentro de la infraestructura local o en la infraestructura proporcionada por terceros.

Un NEG de Internet es una combinación de una dirección IP o un nombre de host, más un puerto opcional:

  • Un nombre de dominio completamente calificado que se pueda resolver de forma pública y un puerto opcional, por ejemplo backend.example.com:443 (puertos predeterminados: 80 para HTTP y 443 para HTTPS)
  • 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)

Un servicio de backend de un balanceador de cargas de HTTP(S) externo que usa un grupo de extremos de red de Internet como su backend distribuye el tráfico a un destino fuera de Google Cloud.

Para obtener más información, incluida qué balanceadores de carga admiten 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 o Cloud Functions.

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

  • Un servicio de Cloud Run o un grupo de servicios que comparten el mismo patrón de URL
  • Una función de Cloud Functions o un grupo de funciones que comparten el mismo patrón de URL
  • 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 que comparten el mismo patrón de URL

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 obtener más información, incluida qué balanceadores de cargas admiten NEG sin servidores, consulta Descripción general del grupo de extremos de red sin servidores.

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 pueden manejar el tráfico adicional o si están cargados por completo. Google Cloud tiene tres modos de balanceo:

  • CONNECTION
  • RATE
  • UTILIZATION

Las opciones del modo de balanceo dependen del esquema de balanceo de cargas del servicio de backend, el protocolo del servicio de backend y el tipo de backends conectados al servicio de backend.

Debes establecer el modo de balanceo cuando agregas un backend al servicio de backend. Ten en cuenta que no puedes especificar un modo de balanceo cuando usas NEG sin servidores o NEG de Internet como backends para un balanceador de cargas.

Modo de balanceo Esquemas de balanceo de cargas compatibles Protocolos de servicio de backend compatibles1 Backends compatibles2 Productos aplicables
CONNECTION EXTERNAL
INTERNAL
SSL, TCP, UDP
Grupos de instancias o NEG zonales, si son compatibles.
  • Balanceo de cargas del proxy de SSL
  • Balanceo de cargas de proxy TCP
  • Balanceo de cargas TCP/UDP interno
  • Balanceo de cargas de red
RATE EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
HTTP, HTTPS, HTTP2, gRPC Grupos de instancias o NEG zonales
  • Balanceo de cargas de HTTP(S) externo
  • Balanceo de cargas HTTP(S) interno
  • Traffic Director (INTERNAL_SELF_MANAGED; solo protocolos HTTP, TCP y gRPC)
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
Sin restricción especial Solo grupos de instancias. Los NEG zonales no admiten el modo de uso.
  • Balanceo de cargas HTTP(S) externo
  • Balanceo de cargas del proxy de SSL
  • Balanceo de cargas del proxy de TCP
  • Balanceo de cargas HTTP(S) interno
  • Traffic Director (INTERNAL_SELF_MANAGED; solo protocolos HTTP, TCP y gRPC)
1Los protocolos tienen más restricciones según el tipo de balanceador de cargas.
2Para ver los tipos de backend admitidos (por ejemplo, grupos de instancias y NEG zonales), consulta Backends en la página de características del balanceador de cargas.

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 zonales administrados 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 beta compute backend-services add-backend.

Cambia el modo de balanceo de un balanceador de cargas

En algunos balanceadores de cargas, no puedes cambiar el modo de balanceo porque el servicio de backend tiene solo un modo 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.

Balanceador de cargas Backends Modos de balanceo disponibles
Balanceo de cargas HTTP(S) Grupos de instancias RATE o UTILIZATION
NEG zonales (extremos GCE_VM_IP_PORT) RATE
Balanceo de cargas HTTP(S) interno Grupos de instancias RATE o UTILIZATION
NEG zonales (extremos GCE_VM_IP_PORT) RATE
Balanceo de cargas del proxy de TCP Grupos de instancias CONNECTION o UTILIZATION
NEG zonales (extremos GCE_VM_IP_PORT) CONNECTION
Balanceo de cargas del proxy de SSL Grupos de instancias CONNECTION o UTILIZATION
NEG zonales (extremos GCE_VM_IP_PORT) CONNECTION
Balanceo de cargas de red Grupos de instancias CONNECTION
Balanceo de cargas TCP/UDP interno Grupos de instancias CONNECTION
NEG zonales (extremos GCE_VM_IP) CONNECTION

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

Combinaciones del modo de balanceo

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.

Balanceador de cargas Tipo de backend Modo de balanceo Capacidad de destino
Balanceo de cargas de TCP/UDP interno 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.
Balanceo de cargas de redes TCP/UDP externo Grupo de instancias CONNECTION No puedes especificar una cantidad objetivo máxima de conexiones.
Balanceo de cargas de proxy SSL, balanceo de cargas de proxy TCP 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:
  • max-utilization
  • max-connections por grupo de instancias zonales
  • max-connections-per-instance
    (grupos de instancias zonales o regionales)
  • Opciones 1 y 2 combinadas
  • Opciones 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
Balanceo de cargas de HTTP(S), balanceo de cargas de 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:
  • max-utilization
  • max-rate por grupo de instancias zonales
  • max-rate-per-instance
    (grupos de instancias zonales o regionales)
  • Opciones 1 y 2 combinadas
  • Opciones 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

Escalador de capacidad

De manera opcional, puedes ajustar el escalador de capacidad para reducir la escala de la capacidad de destino (uso máximo, tasa máxima o cantidad máxima de conexiones) sin cambiar la capacidad de destino. El escalador de capacidad es compatible con todos los balanceadores de cargas que admiten una capacidad de destino. Las únicas excepciones son el balanceador de cargas de red y el balanceador de cargas TCP/UDP interno.

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.

Afinidad de sesión

Algunas aplicaciones necesitan varias solicitudes de un usuario determinado para que 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. La desventaja de la afinidad de sesión es que la carga puede distribuirse de manera menos uniforme.

La afinidad de sesión opera según el criterio del mejor esfuerzo para entregar solicitudes al mismo backend que entregó la solicitud inicial. De forma predeterminada, la afinidad de sesión está inhabilitada (--session-affinity=NONE). Sin la afinidad de sesión habilitada, los balanceadores de cargas distribuyen solicitudes nuevas en función de un hash de 5 tuplas, como se muestra a continuación:

  • 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, si una instancia o un extremo de backend están en buen estado, las solicitudes posteriores se envían a la misma VM de backend o extremo.

En el caso de los balanceadores de cargas basados en proxy, si una instancia o extremo de backend está en buen estado y no está al límite de su capacidad, las solicitudes posteriores se dirigen a la misma VM o extremo de backend. El modo de balanceo determina cuándo llega el backend a su límite de capacidad.

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 cuando un backend alcanza o supera la capacidad máxima o se encuentra en mal estado.

  • 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 del backend o los cambios en el contenido total del backend, según la medición del modo de balanceo, pueden interrumpir la afinidad de sesión. 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.

  • Cuando los balanceadores de cargas tienen habilitada la afinidad de sesión, balancean bien las cargas cuando hay una distribución razonablemente grande de sesiones únicas. Razonablemente grande significa al menos varias veces la cantidad de instancias de backend en el grupo de instancias. Cuando pruebas un balanceador de cargas con una pequeña cantidad de sesiones, el tráfico no se distribuye de manera uniforme.

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

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

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

En la siguiente tabla, se muestran las opciones de afinidad de sesión:

Producto Opciones de afinidad de sesión
Balanceo de cargas TCP/UDP interno • Ninguna (5 tuplas)
• Cliente y destino de IP (2 tuplas)
• Protocolo, cliente y destino de IP (3 tuplas)
• IP de cliente, puerto de cliente, destino de IP, puerto de destino y protocolo (5 tuplas)
Balanceo de cargas del proxy de TCP
Balanceo de cargas del proxy de SSL
• Ninguna
• IP de cliente
Balanceo de cargas de HTTP(S) externo • Ninguna
• IP de cliente
• Cookie generada
Balanceo de cargas de HTTP(S) interno • Ninguna
• IP de cliente
• Cookie generada
• Campo del encabezado
• Cookie HTTP
Balanceo de cargas de red • Ninguna (5 tuplas)
• Cliente y destino de IP (2 tuplas)
• Protocolo, cliente y destino de IP (3 tuplas)
• IP de cliente, puerto de cliente, destino de IP, puerto de destino y protocolo (5 tuplas)
Traffic Director • Ninguna
• IP de cliente
• Cookie generada (solo protocolos HTTP)
• Campo de encabezado (solo protocolos HTTP)
• Cookie HTTP (solo protocolos HTTP)

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

Afinidad de IP de cliente

La afinidad de IP de cliente 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.

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 a la misma VM o extremo de backend.

  • Para los balanceadores de cargas de HTTP(S) externos, la cookie se llama GCLB.
  • Para los balanceadores de cargas de 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.

Afinidad de campo de encabezado

Traffic Director y un balanceador de cargas de HTTP(S) interno pueden usar la afinidad de campo de encabezado 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 del encabezado HTTP.

La afinidad de campo de encabezado enruta las solicitudes a extremos o VM de backend en un NEG zonal según el valor del encabezado HTTP que se indica en la marca --custom-request-header.

Para obtener más información sobre el balanceo de cargas de HTTP(S) interno, en el que se usa la afinidad de campo de encabezado, consulta Descripción general del balanceo de cargas de HTTP(S) interno.

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 más información sobre el balanceo de cargas de HTTP(S) interno, en el que se usa la afinidad de cookie HTTP, consulta Descripción general del balanceo de cargas de HTTP(S) interno.

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 o de proxy TCP, 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 de 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). Esta es la cantidad de tiempo que el balanceador de cargas espera a que un backend muestre una respuesta completa a una solicitud. Por ejemplo, si el valor del tiempo de espera del servicio de backend es el valor predeterminado de 30 segundos, los backends tienen 30 segundos para entregar una respuesta completa a las solicitudes. El balanceador de cargas vuelve a intentar la solicitud HTTP GET si el backend cierra la conexión o agota el tiempo de espera antes de enviar encabezados de respuesta al balanceador de cargas. Si el backend envía encabezados de respuesta (incluso si el cuerpo de la respuesta está incompleto) o si la solicitud enviada al backend no es una solicitud HTTP GET, el balanceador de cargas no vuelve a intentarlo. Si el backend no responde en absoluto, el balanceador de cargas muestra una respuesta HTTP 5xx al cliente. A fin de cambiar el tiempo asignado para que los backends respondan a las solicitudes, cambia el valor del tiempo de espera.

  • En el caso del tráfico HTTP, la cantidad máxima de tiempo que debe llevarle al cliente completar el envío de su solicitud es igual al tiempo de espera del servicio de backend. Si ves respuestas HTTP 408 con jsonPayload.statusDetail client_timed_out, esto significa que no hubo un progreso suficiente mientras la solicitud del cliente o la respuesta del backend se envió a través de un proxy. Si el problema se debe a clientes que tienen problemas de rendimiento, puedes resolverlo con el aumento del tiempo de espera del servicio de backend.

  • Para los balanceadores de cargas de HTTP(S) internos y externos, si la conexión HTTP se actualiza a un WebSocket, el tiempo de espera del servicio de backend define la cantidad máxima de tiempo que puede estar abierto un WebSocket, ya sea que esté inactivo o no.

  • Para los balanceadores de cargas de proxy SSL y TCP, 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.

  • Cuando se configuran servicios de gRPC sin proxy, Traffic Director no admite el tiempo de espera del servicio de backend especificado mediante el campo timeoutSec. 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 Google Cloud Console, 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 herramienta de línea de comandos de gcloud 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:

Funciones adicionales habilitadas en el recurso de servicio de backend

Las siguientes funciones opcionales de Google Cloud están disponibles para los servicios de backend que usa un balanceador de cargas HTTP(S) externo. No se analizan en este documento, pero sí en las siguientes páginas:

  • Google Cloud Armor brinda protección contra los ataques de DSD y otros ataques con políticas de seguridad.
  • Cloud CDN es un sistema de entrega de contenido de latencia baja.
  • Crea encabezados personalizados, estos son encabezados adicionales que el balanceador de cargas agrega a las solicitudes.
  • IAP te permite hacer lo siguiente:
    • Solicitar autenticación con una Cuenta de Google con acceso de OAuth 2.0
    • Controlar el acceso mediante permisos de administración de identidades y accesos

Otras notas

Las siguientes funciones solo se admiten con balanceadores de cargas de HTTP(S) internos y Traffic Director. Sin embargo, no se admiten cuando usas servicios de gRPC sin proxy con Traffic Director.

  • Políticas de balanceo de cargas (localityLbPolicy), excepto para ROUND_ROBIN.
  • Disyuntores, excepto en el campo maxRequests.
  • Detección de valores atípicos

¿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: