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. La mayoría de los parámetros de configuración tienen valores predeterminados que permiten una configuración fácil si necesitas comenzar con rapidez.

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 de TCP/UDP interno

Traffic Director también usa servicios de backend. El balanceo de cargas de red no usa un servicio 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 de servicio de backend para realizar las siguientes funciones:

  • Para dirigir el tráfico a los backends correctos, que son grupos de instancias o grupos de extremos de red (NEG). Ten en cuenta que se puede configurar un balanceador de cargas de HTTP(S) externo para que use un depósito 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
  • Para distribuir el tráfico en función de un modo de balanceo, que es una configuración de cada backend
  • Para determinar qué verificación de estado supervisa el estado de los backends
  • Para especificar la afinidad de sesión
  • Para determinar si Cloud CDN está habilitado (solo en balanceadores de cargas de HTTP o HTTPS externos)
  • Para determinar si las políticas de seguridad de Google Cloud Armor están habilitadas (solo en balanceadores de cargas de HTTP o HTTPS externos)
  • Para determinar si Identity-Aware Proxy está habilitado (solo en balanceadores de cargas de HTTP o HTTPS externos)

Debes establecer algunos valores cuando creas un servicio de backend. Debes establecer otros valores cuando agregas un backend a un 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 utilizas, ya sea un balanceador de cargas o Traffic Director, determina la cantidad máxima de servicios de backend, el permiso de un servicio de backend, el tipo de backend que puede usar cada servicio de backend y el servicio de backend esquema de balanceo de cargas:

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
  • 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
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
  • 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
  • Un NEG de Internet
EXTERNAL
Balanceo de cargas de TCP/UDP interno 1 Regional, pero se puede configurar para que sea accesible de forma global 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
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
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. Sin embargo, en el nivel Estándar se aplican las siguientes restricciones:

Backends

Un backend es un recurso al que un balanceador de cargas de Google Cloud o un proxy de Envoy o un cliente de gRPC sin proxy configurado de Traffic Director distribuyen el tráfico. Cada servicio de backend está asociado con uno o más backends compatibles. Existen varios tipos de backends:

Además, si usas un depósito de backend en lugar de un servicio de backend, puedes configurar el backend del depósito 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.

Estos son los protocolos disponibles:

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP
  • gRPC (solo en Traffic Director)

Los protocolos válidos dependen del tipo de balanceador de cargas o de si se usa Traffic Director. Para obtener más información, consulta Funciones del balanceador de cargas y Funciones de Traffic Director.

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 el balanceo de cargas de HTTP(S), del proxy TCP y del proxy SSL, Google encripta de forma automática el tráfico entre Google Front Ends (GFE) y los backends que residen en Google Cloud.

Además de esta encriptación a nivel de red, puedes usar un protocolo seguro, como SSL, HTTPS o HTTP/2 (mediante TLS), como protocolo de servicio de backend para los balanceadores de cargas basados en GFE, Traffic Director y el balanceo de cargas de HTTP(S).

Cuando un balanceador de cargas se conecta a los backends mediante un protocolo de servicio de backend seguro, el GFE es el cliente SSL o HTTPS. De manera similar, cuando un proxy del cliente configurado con Traffic Director se conecta a los backends mediante un protocolo de servicio de backend seguro, el proxy es el cliente SSL o HTTPS.

Se recomienda un protocolo seguro que permita conectarse a instancias de backend en los siguientes casos:

  • Cuando necesites una conexión encriptada y que se pueda auditar desde el balanceador de cargas (o Traffic Director) hacia las instancias de backend.

  • Cuando el balanceador de cargas se conecta a una instancia de backend que está fuera de Google Cloud (a través de un NEG de Internet) La comunicación con un backend de NEG de Internet puede transitar la Internet pública. Cuando el balanceador de cargas se conecta a un NEG de Internet, el certificado debe estar firmado por una CA pública y cumplir con los requisitos de validación.

Para usar un protocolo seguro entre el balanceador de cargas y los backends, ten en cuenta los siguientes requisitos:

  • Debes configurar los servicios de backend del balanceador de cargas para que usen los protocolos SSL (TLS), HTTPS o HTTP/2.

  • En las instancias de backend, debes configurar el software para que se entregue el tráfico mediante el mismo protocolo que usa el servicio de backend. Por ejemplo, si el servicio de backend usa HTTPS, asegúrate de configurar las instancias de backend para que usen HTTPS. Si usas el protocolo HTTP/2, los backends deben usar TLS. Para obtener instrucciones de configuración, consulta la documentación del software de la instancia de backend.

  • Debes instalar claves privadas y certificados en las instancias de backend. No es necesario que estos certificados coincidan con el certificado SSL del balanceador de cargas. Para obtener instrucciones de instalación, consulta la documentación del software de la instancia de backend.

  • Debes configurar el software que se ejecuta en las instancias de backend para que funcione como un servidor SSL o HTTPS. Para obtener instrucciones de configuración, consulta la documentación del software de la instancia de backend.

Ten en cuenta esta información cuando uses grupos de instancias o backends de NEG zonales:

  • Cuando un GFE inicia una sesión de TLS para backends, el GFE no usa la extensión de indicación del nombre del servidor (SNI).

  • Cuando un GFE se conecta a backends que están dentro de Google Cloud, el GFE acepta cualquier certificado que presenten los backends. Los GFE no realizan la validación del certificado. Por ejemplo, el certificado se considera válido incluso en las siguientes circunstancias:

    • El certificado está autofirmado.
    • El certificado está firmado por una autoridad certificada (CA) desconocida.
    • El certificado caducó o aún no es válido.
    • Los atributos CN y subjectAlternativeName no coinciden con un encabezado Host ni con un registro PTR de DNS.
Para obtener información adicional sobre la encriptación de Google, consulta Encriptación en tránsito en Google Cloud.

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 las direcciones IP internas de la interfaz de red principal. Debido a que GFE es un proxy, las VM de backend no requieren direcciones IP externas.

  • Para los balanceadores de cargas HTTP(S) internos, los balanceadores de cargas TCP/UDP internos y Traffic Director: las VM de backend para balanceadores de cargas internos y Traffic Director no requieren direcciones IP externas.

Puertos con nombre

Un balanceador de cargas puede escuchar en el frontend en uno o más números de puerto que configuras en la regla de reenvío del balanceador de cargas. En el backend, el balanceador de cargas puede desviar el tráfico al mismo número de puerto o a uno diferente. Este es el número de puerto en el 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.

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. Luego, consultas el puerto con nombre 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, este servicio usa este número de puerto para la comunicación con las VM del grupo de instancias.

Los siguientes tipos de balanceadores de cargas requieren que cada grupo de instancias de backend de Compute Engine tenga un puerto con nombre:

  • 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

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

Por ejemplo, puedes configurar el puerto con nombre en un grupo de instancias de la siguiente manera; en este caso, el nombre del servicio es my-service-name y el puerto es 8888:

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

Luego, puedes configurar --port-name en el servicio de backend como my-service-name:

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

Ten en cuenta lo siguiente:

  • Cada servicio de backend se suscribe a un solo nombre de puerto. En consecuencia, cada uno de sus grupos de instancias de backend debe tener al menos un puerto que tenga ese nombre.

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

  • El número de puerto resuelto que usa el servicio de backend no tiene que coincidir con el número de puerto que usan las reglas de reenvío del balanceador de cargas.

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, 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 balancear el tráfico en puertos diferentes, crea los puertos con nombre necesarios en un grupo de instancias y haz que cada servicio de backend se suscriba a un puerto con nombre único.

  • 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 HTTP(S) externo y internal-tcp-backend-service para un balanceador de cargas 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 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 del grupo de instancias administrado es el uso de CPU o la métrica de Cloud Monitoring, que no están relacionados 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 que genera la métrica de ajuste de escala automático del uso del balanceo de cargas de HTTP.

Grupos de extremos de red zonal

Un servicio de backend que usa grupos de extremos de red (NEG) zonales como sus backends distribuye el tráfico entre aplicaciones o contenedores que se ejecutan dentro de las VM.

Un extremo de red zonal es una combinación de una dirección IP y un puerto, especificada de una de las siguientes maneras:

  • Con la especificación de un par IP address:port, como 10.0.1.1:80
  • Con la especificación de solo una dirección IP de extremo de red. El puerto predeterminado para el NEG se usa de manera automática como el puerto del par IP address:port

Los extremos de red representan servicios por su dirección IP y puerto, en lugar de hacer referencia a una VM específica. Un grupo de extremos de red es una agrupación lógica de extremos de red.

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

  • 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 o incluso una versión específica de una app

Para obtener más información, consulta Descripción general de los grupos 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, que el balanceador de cargas usa a fin de determinar los backends que son aptos para solicitudes o conexiones nuevas
  • Una capacidad de destino, que 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, que se puede usar para ajustar 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 configurar un modo de balanceo para un NEG sin servidores.

Modo de balanceo Esquemas de balanceo de cargas compatibles Protocolos de servicio de backend compatibles Tipos de backends compatibles Productos aplicables
CONNECTION EXTERNAL
INTERNAL
SSL, TCP y UDP
Las opciones de protocolo están limitadas por el tipo de balanceador de cargas. Por ejemplo, el balanceo de cargas de TCP/UDP interno solo usa el protocolo TCP o UDP.
Grupos de instancias o NEG zonales, si son compatibles.
Por ejemplo, el balanceo de cargas de TCP/UDP interno no admite NEG zonales.
  • Balanceo de cargas de proxy SSL
  • Balanceo de cargas de proxy TCP
  • Balanceo de cargas TCP/UDP interno
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 de HTTP y gRPC)
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
Cualquier protocolo Solo grupos de instancias. Los NEG zonales no admiten el modo de uso.
  • Balanceo de cargas de HTTP(S) externo
  • Balanceo de cargas de HTTP(S) interno
  • Balanceo de cargas de proxy SSL
  • Balanceo de cargas del proxy de TCP
  • Traffic Director (INTERNAL_SELF_MANAGED; solo protocolos de HTTP y gRPC)

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:

  • Los servicios de backend para balanceadores de cargas de TCP/UDP internos solo pueden usar el modo de balanceo CONNECTION.
  • Los servicios de backend para balanceadores de cargas de HTTP(S) externos en los que todos los backends son NEG solo pueden usar el modo de balanceo RATE.
  • Los servicios de backend para balanceadores de cargas de HTTP(S) internos en los que todos los backends son NEG solo pueden usar el modo de balanceo RATE.
  • Los servicios de backend para balanceadores de cargas de proxy SSL en los que todos los backends son NEG solo pueden usar el modo de balanceo CONNECTION.
  • Los servicios de backend para balanceadores de cargas de proxy TCP en los que todos los backends son NEG solo pueden usar el modo de balanceo CONNECTION.

En algunos balanceadores de cargas, puedes cambiar el modo de balanceo, porque hay más de un modo disponible para los servicios de backend:

  • Los servicios de backend para balanceadores de cargas de HTTP(S) externos en los que todos los backends son grupos de instancias pueden usar los modos de balanceo RATE o UTILIZATION.
  • Los servicios de backend para balanceadores de cargas de HTTP(S) internos en los que todos los backends son grupos de instancias pueden usar los modos de balanceo RATE o UTILIZATION.
  • Los servicios de backend para balanceadores de cargas de proxy SSL en los que todos los backends son grupos de instancias pueden usar los modos de balanceo CONNECTION o UTILIZATION.
  • Los servicios de backend para balanceadores de cargas de proxy TCP en los que todos los backends son grupos de instancias pueden usar los modos de balanceo CONNECTION o UTILIZATION.

Capacidad de destino

Cada modo de balanceo tiene una capacidad de destino correspondiente, que define una cantidad máxima de conexiones de destino, una tasa máxima de destino o el uso máximo de CPU de destino. En cada modo de balanceo, la capacidad de destino no es un disyuntor. Un balanceador de cargas superará el máximo en ciertas condiciones, por ejemplo, si todos los extremos o las VM de backend lo alcanzaron.

  • En el modo de balanceo CONNECTION, la capacidad de destino define una cantidad máxima de destino de conexiones simultáneas. Excepto para los balanceadores de cargas de TCP/UDP internos, debes especificar una cantidad máxima de destino de conexiones con uno de estos tres métodos: puedes especificar la cantidad máxima de conexiones de cada VM mediante max-connections-per-instance o de cada extremo en un NEG zonal mediante max-connections-per-endpoint. En los NEG zonales y los grupos de instancias zonales no administrados, puedes especificar max-connections para todo el grupo.

    Cuando especificas max-connections-per-instance o max-connections-per-endpoint, Google Cloud calcula el destino real por VM o por extremo de la siguiente manera:

    • (cantidad máxima de conexiones por VM * cantidad total de VM) / cantidad de VM en buen estado
    • (cantidad máxima de conexiones por extremo * cantidad total de extremos) / cantidad de extremos en buen estado

    Cuando especificas max-connections, Google Cloud calcula el destino real por VM o por extremo de la siguiente manera:

    • Cantidad máxima de conexiones / cantidad de VM en buen estado
    • Cantidad máxima de conexiones / cantidad de extremos en buen estado
  • En el modo de balanceo RATE, la capacidad de destino define una tasa máxima de destino para las solicitudes HTTP. Debes especificar una tasa de destino mediante uno de estos tres métodos: puedes especificar una tasa máxima de destino para cada VM mediante max-rate-per-instance o para cada extremo en un NEG zonal mediante max-rate-per-endpoint. En los NEG zonales y los grupos de instancias zonales no administrados, puedes especificar max-rate para todo el grupo.

    Cuando especificas max-rate-per-instance o max-rate-per-endpoint, Google Cloud calcula la tasa de destino real por VM o por extremo de la siguiente manera:

    • tasa máxima por VM * cantidad total de VM / cantidad de VM en buen estado
    • tasa máxima por extremo * cantidad total de extremos / cantidad de extremos en buen estado

    Cuando especificas max-rate, Google Cloud calcula la tasa de destino real por VM o por extremo de esta manera:

    • tasa máxima / cantidad de VM en buen estado
    • tasa máxima / cantidad de extremos en buen estado
  • En el modo de balanceo UTILIZATION, no hay una capacidad de destino obligatoria. Tienes varias opciones que dependen del tipo de backend, como se indica en la siguiente tabla.

En esta tabla, se explican 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 junto 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 máxima de conexiones.
Balanceo de cargas de proxy SSL, balanceo de cargas de proxy TCP Grupo de instancias CONNECTION Debes especificar una de las siguientes opciones:
1. Cantidad máxima de conexiones por grupo de instancias zonal
2. Cantidad máxima de conexiones por instancia
(grupos de instancias zonales o regionales)
UTILIZATION De forma alternativa, puedes especificar una de las siguientes opciones:
1. Uso máximo
2. Cantidad máxima de conexiones por grupo de instancias zonal
3. Cantidad máxima de conexiones por instancia
(grupos de instancias zonales o regionales)
4. Opciones 1 y 2 combinadas
5. Opciones 1 y 3 combinadas
NEG zonal CONNECTION Debes especificar una de las siguientes opciones:
1. Cantidad máxima de conexiones por NEG zonal
2. Cantidad máxima de conexiones por extremo
Balanceo de cargas de HTTP(S), balanceo de cargas de HTTP(S) interno, Traffic Director Grupo de instancias RATE Debes especificar una de las siguientes opciones:
1. Tasa máxima por grupo de instancias zonal
2. Tasa máxima por instancia
(grupos de instancias zonales o regionales)
UTILIZATION De forma alternativa, puedes especificar una de las siguientes opciones:
1. Uso máximo
2. Tasa máxima por grupo de instancias zonal
3. Tasa máxima por instancia
(grupos de instancias zonales o regionales)
4. Opciones 1 y 2 combinadas
5. Opciones 1 y 3 combinadas
NEG zonal RATE Debes especificar una de las siguientes opciones:
1. Tasa máxima por NEG zonal
2. Tasa máxima por extremo

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. La única excepción es el balanceador de cargas de TCP/UDP interno.

De forma predeterminada, el escalador de capacidad es 1.0 (100%). Esto significa que, por ejemplo, si el porcentaje de uso actual de una instancia de backend es del 80% y el uso máximo está configurado en 80%, el servicio de backend deja de enviar solicitudes a esta instancia:

capacity-scaler: 1 * 0.8

Puedes configurar el escalador de capacidad en 0.0 o de 0.1 (10%) a 1.0 (100%). Un factor de escala de cero (0.0) evita todas las conexiones nuevas. No puedes establecer una configuración de 0.0 cuando solo hay un backend conectado al servicio de backend.

Usa el escalador de capacidad cuando dos servicios de backend compartan un backend de grupo de instancias

En una situación en la que tienes dos servicios de backend que usan el mismo backend de grupos de instancias, debes asignar la capacidad del grupo de instancias entre los dos servicios de backend.

Por ejemplo, podrías establecer el escalador de capacidad en 0.5 en ambos servicios de backend para que cada servicio de backend reciba el 40% de la capacidad del grupo de instancias:

capacity-scaler: 0.5 * 0.8

Cuando cada servicio de backend haya usado el 40% de la capacidad del grupo de instancias, las solicitudes ya no se enviarán a este grupo.

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 del 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 (grupo de instancias o NEG) de acuerdo con el modo de balanceo del backend. Luego, una vez que se selecciona un backend, Traffic Director distribuye el tráfico en función de 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

Si no tienen afinidad de sesión, los balanceadores de cargas distribuyen las solicitudes nuevas en función de un hash de 5 tuplas que consiste en la dirección IP y el puerto de origen del cliente, la dirección IP y el puerto de destino de la regla de reenvío del balanceador de cargas y el protocolo L3 (protocolo TCP para todos los balanceadores de cargas que usan servicios de backend). El modo de balanceo del grupo de instancias de backend o el NEG zonal determina cuándo el backend llegó al máximo de su capacidad. Algunas aplicaciones, como los servidores con estado que usan la publicación de anuncios, los juegos o los servicios con almacenamiento en caché interno de gran tamaño, necesitan que varias solicitudes de un usuario determinado se dirijan al mismo backend o extremo.

La afinidad de sesión está disponible para el tráfico de TCP, incluidos los protocolos SSL, HTTP(S) y HTTP/2. Siempre que un extremo o una instancia de backend se mantengan en buen estado y no estén al máximo de capacidad, según lo definido por el modo de balanceo, el balanceador de cargas dirige las solicitudes posteriores al mismo extremo o VM de backend. Ten en cuenta lo siguiente cuando configures la afinidad de sesión:

  • En el tráfico de UDP no existe el concepto de sesión, por lo que la afinidad de sesión no se aplica para este tipo de tráfico.

  • Cuando se configuran servicios gRPC sin proxy, Traffic Director no es compatible con 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 que no sea None con el modo de balanceo UTILIZATION, ya que los cambios en el uso de instancias pueden hacer que el servicio de balanceo de cargas dirija las solicitudes o conexiones nuevas a VM de backend que tienen menos carga, lo que interrumpe la afinidad de sesión. En su lugar, usa los modos de balanceo RATE o CONNECTION, según lo que admita el balanceador de cargas elegido, para reducir la posibilidad de interrumpir 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
• TCP/UDP interno • Ninguna
• IP de cliente
• IP y protocolo de cliente
• IP, protocolo y puerto de cliente
• Proxy TCP
• Proxy SSL
• Ninguna
• IP de cliente
• HTTP(S) externo • Ninguna
• IP de cliente
• Cookie generada
• HTTP(S) interno • Ninguna
• IP de cliente
• Cookie generada
• Campo del encabezado
• Cookie HTTP
Red El balanceo de cargas de red no usa servicios de backend. En su lugar, debes establecer la afinidad de sesión para los balanceadores de cargas de red a través de grupos de destino. Consulta el parámetro sessionAffinity en Grupos de destino.
• Traffic Director • Ninguna
• IP de cliente
• Cookie generada
• Campo del encabezado
• Cookie 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 (por ejemplo, un dispositivo móvil que pasa de red a red), la afinidad basada en cookies permite que el balanceador de cargas reconozca las conexiones posteriores de ese cliente en lugar de tratarlas como nuevas.

Cuando un balanceador de cargas crea una cookie para la afinidad basada en cookies generadas, establece el atributo path de la cookie en /. Si el mapa de URL del balanceador de cargas tiene un comparador de rutas que especifica más de un servicio de backend para un nombre de host determinado, todos los servicios de backend que usan la afinidad de sesión basada en cookies 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 de sesión, o puedes establecer la duración de la cookie en un valor entre 1 y 86400 segundos (24 horas) inclusive.

Afinidad de campo de encabezado

Un balanceador de cargas de HTTP(S) interno puede usar la afinidad de campo de encabezado cuando la política de localidad del balanceo de cargas es RING_HASH o MAGLEV, y 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.

Un balanceador de cargas de TCP/UDP interno puede usar la afinidad de cookie HTTP cuando la política de localidad del balanceo de cargas es RING_HASH o MAGLEV, y 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. En su lugar, cambia al modo de balanceo RATE o CONNECTION.

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.

  • 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. Para estos balanceadores de cargas, puedes cambiar el valor de tiempo de espera a fin de que los backends tengan más o menos tiempo de responder por completo a las solicitudes.

  • En el caso del tráfico HTTP, la cantidad máxima de tiempo que debe llevar a cabo el cliente para enviar su solicitud es igual al tiempo de espera del servicio de backend. Si ves respuestas de 408 HTTP con jsonPayload.statusDetail client_timed_out, esto significa que no se completó el progreso mientras se enviaban a través del proxy la solicitud del cliente o la respuesta del backend. Si el problema se debe a clientes que tienen problemas de rendimiento, puedes resolverlo si aumentas el tiempo de espera del servicio de backend.

  • Para los balanceadores de cargas HTTP(S) externos e internos, 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 abrirse un WebSocket, ya sea que esté activa o no.

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

  • Los balanceadores de cargas de TCP/UDP internos ignoran el valor de tiempo de espera del servicio de backend.

  • Cuando se configuran servicios de gRPC sin proxy, Traffic Director no admite el tiempo de espera del servicio de backend.

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 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 se usan en el balanceo de cargas de HTTP(S). 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 requerir autenticación con una Cuenta de Google mediante un flujo de trabajo de acceso de OAuth 2.0 y controlar el acceso mediante permisos de IAM.

Otras notas

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

  • Disyuntores
  • Detección de valores atípicos
  • Políticas de balanceo de cargas
  • Afinidad de sesión en función de cookies HTTP
  • Afinidad de sesión en función de encabezados HTTP

Próximos pasos

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: