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, varias configuraciones de distribución y sesión, verificaciones de estado y tiempos de espera. Esta configuración proporciona un control detallado sobre el comportamiento de tu balanceador de cargas. La mayoría de las opciones de configuración tienen valores predeterminados que permiten una configuración sencilla 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 HTTP(S) externo
  • Balanceo de cargas HTTP(S) interno
  • Balanceo de cargas del proxy SSL
  • Balanceo de cargas del proxy TCP
  • Balanceo de cargas 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 usan la información de configuración en el recurso de servicio de backend para 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 HTTP(S) externo para usar 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 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 balanceadores de cargas HTTP(S) externos)
  • Para determinar si las políticas de seguridad de Google Cloud Armor están habilitadas (solo balanceadores de cargas HTTP(S) externos)
  • Para determinar si Identity-Aware Proxy está habilitado (solo balanceadores de cargas HTTP(S) 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:

La cantidad máxima de servicios de backend por balanceador de cargas, el alcance de un servicio de backend, el tipo de backends que puede usar cada servicio de backend y el esquema de balanceo de cargas de un servicio de backend dependen del tipo del balanceador de cargas:

Tipo de balanceador de cargas Cantidad máxima de servicios de backend Alcance del servicio de backend Tipos de backend compatibles Esquema de balanceo de cargas
Balanceo de cargas 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, sin administrar o una combinación de ambos
  • Todos los NEG zonales: uno o más NEG zonales
  • Un NEG de Internet
EXTERNAL
Balanceo de cargas HTTP(S) interno Varias Discos 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, sin administrar o una combinación de ambos
  • Todos los NEG zonales: uno o más NEG zonales
INTERNAL_MANAGED
Balanceo de cargas del 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, sin administrar o una combinación de ambos
  • Todos los NEG zonales: uno o más NEG zonales
  • Un NEG de Internet
EXTERNAL
Balanceo de cargas del 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, sin administrar o una combinación de ambos
  • Todos los NEG zonales: uno o más NEG zonales
  • Un NEG de Internet
EXTERNAL
Balanceo de cargas 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, sin administrar 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, sin administrar 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 HTTP(S), el balanceo de cargas del proxy SSL y el balanceo de cargas del proxy TCP siempre son globales en el nivel de red Estándar o Premium. Sin embargo, en el nivel Estándar se aplican las siguientes restricciones:

Backends

Un backend es un recurso en el que un balanceador de cargas de Google Cloud distribuye el tráfico. Cada servicio de backend está asociado con uno o más backends compatibles. Existen tres tipos de backends:

No puedes usar diferentes tipos de backends 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 qué backends son compatibles con qué servicios de backend, consulta la tabla de la sección anterior.

No puedes borrar un grupo de instancias de backends o un NEG que esté asociado con un servicio de backend. Antes de borrar un grupo de instancias o un NEG, primero debes quitarlo como un backend de todos los servicios de backend que hacen referencia a él.

Protocolo para los backends

Cuando creas un servicio de backend, debes especificar el protocolo que usa el balanceador de cargas para la comunicación 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

Los protocolos válidos dependen del tipo de balanceador de cargas. Para obtener más información, consulta Características del balanceador de cargas.

Cuando cambias el protocolo de un servicio de backend, los backends permanecen inaccesibles 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 HTTP(S), el balanceo de cargas del proxy de TCP y el balanceo de cargas del proxy de SSL, Google encripta de forma automática el tráfico entre Google Front Ends (GFE) y tus backends dentro de Google Cloud. En los backends fuera de Google Cloud, como los extremos dentro de un grupo de extremos de red de Internet, el tráfico solo se encripta de forma automática dentro de la red de Google.

  • Además de esta encriptación a nivel de la red, puedes elegir un protocolo seguro, como SSL, HTTPS o HTTP/2 (mediante TLS), como protocolo de servicio de backend.
  • Recomendamos usar HTTPS o HTTP/2 cuando te conectes a backends fuera de Google Cloud, ya que la comunicación con el backend puede transitar por la Internet pública.
  • Cuando usas SSL, HTTPS o HTTP/2 como protocolo de servicio de backend, debes instalar claves y certificados privados y configurar el software que se ejecuta en tus backends para que funcione como un servidor SSL o HTTPS.

Cuando un GFE se conecta a tus backends mediante un protocolo de servicio de backend seguro, es el cliente SSL o HTTPS.

  • Cuando se conecta a los backends dentro de Google Cloud, GFE acepta cualquier certificado que presente tus backends, ya sea que esté autofirmado o firmado por una autoridad certificada. En este caso, los GFE no realizan la validación de certificados cuando se conectan a backends.
  • Cuando te conectas a backends a través de la Internet pública mediante un NEG de Internet, el certificado debe estar firmado por una CA pública y cumplir con los requisitos de validación

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:

  • Para los balanceadores de cargas HTTP(S) externos, los balanceadores de cargas del proxy de SSL y los balanceadores de cargas del proxy de 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 la red principal. Debido a que GFE es un proxy, las VM de backend no requieren direcciones IP externas.

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

Puertos con nombre

Los grupos de instancias de backend conectados a uno de estos tipos de balanceadores de cargas deben tener un puerto con nombre que coincida con el puerto con nombre al que se suscribe el servicio de backend del balanceador de cargas:

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

Cada grupo de instancias puede tener varios puertos con nombre. Un puerto con nombre crea una asignación de un nombre de servicio a un número de puerto. Si el puerto con nombre de un grupo de instancias coincide con el puerto con nombre al que se suscriben los servicios de backend, la asignación de puertos con nombre en el grupo de instancias se usa para definir el número de puerto que el servicio de backend usa para la comunicación con las VM miembro del grupo.

Por ejemplo, puedes configurar el puerto con nombre en un grupo de instancias de la siguiente manera, en la que 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 de esto, puedes configurar el puerto con nombre 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 con nombre para ese nombre.

  • Es posible que un servicio de backend use 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 único para el mismo nombre de puerto.

  • El número de puerto resuelto por 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 de NEG de Internet, ya que los NEG definen puertos mediante un mecanismo diferente, es decir, en los extremos.
  • Para los balanceadores de cargas TCP/UDP internos, ya que un balanceador de cargas TCP/UDP interno es un balanceador de cargas de paso, no un proxy, 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 orientación para grupos de instancias

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

  • No coloques una VM en más de un grupo de instancias con balanceo de cargas. Si una VM pertenece a dos o más grupos de instancias no administrados, o un miembro de un grupo de instancias administrado y uno o más grupos de instancias no administrados, Google Cloud te limita solo a usar una de esas instancias grupos 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 a diferentes puertos, crea los puertos con nombre requeridos en un grupo de instancias y haz que cada servicio de backend se suscriba a un puerto con nombre único.

  • Es posible usar el mismo grupo de instancias que un backend para más de un servicio de backend. En esta situación, esos servicios de backend deben usar el mismo modo de balanceo.

    Esta es una configuración compleja y no siempre es posible. Por ejemplo, el mismo grupo de instancias no puede ser un backend para un servicio de backend de un balanceador de cargas de TCP/UDP interno y un balanceador de cargas HTTP(S) externo. Un balanceador de cargas de TCP/UDP interno usa servicios de backend cuyos backends deben usar el modo de balanceo CONNECTION, mientras que un balanceador de cargas HTTP(S) externo usa servicios de backend compatibles con los modos RATE o UTILIZATION. Dado que no hay un modo de balanceo común para ambos, no puedes usar el mismo grupo de instancias como backend para ambos tipos de balanceadores de cargas.

    • Si tu 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 no agregar un grupo de instancias administrado con ajuste de escala automático a más de un servicio de backend. Esto puede 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 de balanceo de cargas 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 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 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 alojados en una infraestructura local o en una infraestructura proporcionada por terceros.

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

  • Un nombre de dominio completamente calificado que se pueda resolver públicamente 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 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 la descripción general del grupo de extremos de red de Internet.

Distribución de tráfico

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

  • Un modo de balanceo, que el balanceador de cargas usa para determinar los backends que son aptos para nuevas solicitudes o conexiones.
  • Una capacidad deseada, que define una cantidad máxima deseada de conexiones, una tasa máxima deseada o el uso máximo de CPU deseado.
  • Un escalador de capacidad, que se puede usar para ajustar la capacidad general disponible sin modificar la capacidad deseada.

Modo de balanceo

El modo de balanceo determina si los backends de un balanceador de cargas pueden controlar el tráfico adicional o se cargan 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.

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

Si el uso promedio de todas las VM asociadas con un servicio de backend es inferior al 10%, Google Cloud podría preferir zonas específicas. Esto puede suceder cuando usas grupos de instancias regionales administrados, grupos de instancias zonales administrados en diferentes zonas 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 de balanceo posible:

  • Los servicios de backend para balanceadores de cargas TCP/UDP internos solo pueden usar el modo de balanceo CONNECTION.
  • Los servicios de backend para balanceadores de cargas 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 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 de 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 de 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, ya que hay más de un modo disponible para sus servicios de backend:

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

Si el mismo grupo de instancias es un backend para varios servicios de backend, debe usar el mismo modo de balanceo en cada servicio de backend. 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 nuevo modo de balanceo.

Además, no puedes usar el mismo grupo de instancias como backend para algunas combinaciones de servicios de backend diferentes. Por ejemplo, no puedes usar el mismo grupo de instancias como backend para un balanceador de cargas de TCP/UDP interno, que solo admite el modo de balanceo CONNECTION y simultáneamente para un balanceador de cargas HTTP(S) externo, que admite el modo de balanceo RATE o UTILIZATION.

Capacidad de destino

Cada modo de balanceo tiene una capacidad de destino correspondiente, que define una cantidad máxima de destino de conexiones, 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 todas las VM o los extremos del backend lo alcanzaron.

  • En el modo de balanceo CONNECTION, la capacidad de destino define una cantidad máxima de conexiones simultáneas de destino. Excepto para los balanceadores de cargas TCP/UDP internos, debes especificar una cantidad máxima de conexiones con uno de los siguientes 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 sin administrar, puedes especificar max-connections para todo el grupo.

    Cuando especificas max-connections-per-instance o max-connections-per-endpoint, Google Cloud calcula el objetivo eficaz 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 o Google Cloud calcula el destino efectivo 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 en cada extremo en un NEG zonal mediante max-rate-per-endpoint. En los NEG zonales y los grupos de instancias zonales sin administrar, 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 efectiva 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 efectiva por VM o por extremo de la siguiente 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 resume 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 TCP/UDP interno Grupo de instancias CONNECTION No puedes especificar una cantidad máxima de conexiones.
Balanceo de cargas del proxy de SSL, balanceo de cargas del proxy de 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 Puedes especificar de forma opcional 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. 1 y 2 combinados
5. 1 y 3 combinados
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 HTTP(S), balanceo de cargas 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 Puedes especificar de forma opcional 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. 1 y 2 combinados
5. 1 y 3 combinados
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 capacidad objetivo (uso máximo, tasa máxima o conexiones máximas) sin cambiar la capacidad objetivo. 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 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 se establece 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%). No puedes configurar una configuración mayor que 0.0 y menor que 0.1. 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 adjunto 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 de instancias.

Traffic Director y la distribución de tráfico

Traffic Director también usa recursos de servicio de backend. Específicamente, Traffic Director usa servicios de backend cuyo esquema de balanceo de cargas es INTERNAL_SELF_MANAGED. Para un servicio de backend interno administrado, 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 de 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 modos de balanceo siguientes:

  • 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 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 usa la publicación de anuncios, los juegos o los servicios con almacenamiento en caché interno de gran tamaño, necesitan varias solicitudes de un usuario determinado para ser dirigidas 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 y cuando una instancia o extremo de backend esté en buen estado y no esté en capacidad, según lo definido por su 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 UDP no existe el concepto de sesión, por lo que la afinidad de sesión no tiene sentido para este tipo de tráfico.

  • No confíes en la afinidad de sesión para propósitos de autenticación o seguridad. La afinidad de sesión está diseñada para interrumpirse cuando un backend alcanza o supera su máxima capacidad o se pone en mal estado.

  • Los balanceadores de cargas de Google Cloud proporcionan afinidad de sesión según el mejor esfuerzo. Factores como el cambio de los estados de la verificación de estado o los cambios a la integridad del backend, según el modo de balanceo, pueden romper 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 la instancia pueden hacer que el servicio de balanceo de cargas dirija nuevas solicitudes o conexiones a una afinidad de sesión menos completa. En su lugar, usa el modo de balanceo RATE o CONNECTION, compatible con el balanceador de cargas elegido, para reducir la posibilidad de romper 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 del cliente
• IP y protocolo del cliente
• IP, protocolo y puerto del cliente
Proxy TCP
Proxy SSL
• Ninguna
• IP del cliente
HTTP(S) externo • Ninguna
• IP del cliente
• Cookie generada
HTTP(S) interno • Ninguno
• IP del 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 los grupos de destino.
Traffic Director • Ninguno
• IP del 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 desde 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 esto en cuenta:

  • La afinidad de IP de cliente es un hash de dos tuplas que consiste en la dirección IP del cliente y la dirección IP de la regla de reenvío del balanceador de cargas al 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 HTTP(S) externos, la cookie se llama GCLB.
  • Para los balanceadores de cargas internos HTTP(S) y Traffic Director, la cookie se llama GCILB.

La afinidad basada en cookies puede identificar con mayor precisión un cliente de 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 de 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 desde la misma dirección IP de origen como si fueran 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 tratar la conexión como nueva.

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 una coincidencia de ruta que especifica más de un servicio de backend para un nombre de host determinado, todos los servicios de backend que usan afinidades de sesión basadas 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 entre 1 y 86400 segundos (24 horas) inclusive.

Afinidad del campo del encabezado

Un balanceador de cargas HTTP(S) interno puede usar la afinidad del campo del 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 del campo del encabezado enruta las solicitudes a VM o extremos 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 HTTP(S) interno, en el que se usa la afinidad del campo del encabezado, consulta Descripción general del balanceo de cargas HTTP(S) interno.

Un balanceador de cargas 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 VM o extremos de backend en un NEG en función de la cookie HTTP que se infica en la marca HTTP_COOKIE. Si el cliente no proporciona la cookie, el proxy generará la cookie y la mostrará al cliente en un encabezado Set-Cookie.

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

Pérdida la afinidad de sesión

Sin importa 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 puede estar en una zona diferente. Puedes mitigar esto si te aseguras de especificar la capacidad de destino correcta para cada backend según tu propio testimonio.
  • El ajuste de escala automático agrega instancias a un grupo de instancias administrado o las quita de este. 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 evitarlo, 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 una VM o extremo de backend falla en las verificaciones de estado, el balanceador de cargas dirige el tráfico a un 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.
  • 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 modo de balanceo RATE o CONNECTION, el que sea compatible con el tipo de balanceador de cargas.

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

  • Si la ruta de enrutamiento de un cliente en Internet a Google cambia entre solicitudes o conexiones, se puede seleccionar otra interfaz de Google (GFE) como proxy. Esto puede romper la afinidad de sesión.
  • Cuando usas el modo de balanceo UTILIZATION, especialmente si no tienes una capacidad de destino máxima 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 en su lugar.

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 HTTP(S) externos y los balanceadores de cargas HTTP(S) internos mediante el protocolo HTTP, HTTPS o HTTP/2, el tiempo de espera del servicio de backend es un tiempo de espera de solicitud/respuesta para el tráfico HTTP(S). Esta es la cantidad de tiempo que el balanceador de cargas espera 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 reintenta la solicitud HTTP GET una vez si el backend cierra la conexión o se 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, el balanceador de cargas muestra una respuesta HTTP 5xx al cliente. Para estos balanceadores de cargas, cambia el valor de tiempo de espera si deseas que los backends respondan por completo a las solicitudes.

  • En los balanceadores de cargas HTTP(S) 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 un WebSocket puede estar abierto, esté inactivo o no.

  • Para los balanceadores de cargas de proxy SSL y TCP, el tiempo de espera es inactivo. Para estos balanceadores de cargas, cambia el valor del 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 TCP/UDP internos ignoran el valor del 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 con Google Cloud Console, puedes crear la verificación de estado, si es necesario, cuando creas el balanceador de cargas o puedes hacer referencia a una verificación de estado existente.

Cuando creas un servicio de backend con backends de un 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 del balanceador 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 características opcionales de Google Cloud están disponibles para los servicios de backend que usa un balanceo de cargas HTTP(S). No se analizan en este documento, pero se analizan en las siguientes páginas:

  • Google Cloud Armor brinda protección contra ataques de DSD y otros ataques con políticas de seguridad.
  • Cloud CDN es un sistema de entrega de contenido de latencia baja.
  • Los encabezados de solicitudes definidos por el usuario 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 son compatibles con balanceadores de cargas HTTP(S) internos y 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 páginas siguientes: