Optimizaciones avanzadas del balanceo de cargas

En esta página, se describe cómo usar una política de balanceo de cargas de servicios para admitir optimizaciones avanzadas de costo, latencia y resiliencia en los siguientes balanceadores de cargas:

Balanceador de cargas de aplicaciones externo global
Balanceador de cargas de aplicaciones interno entre regiones
Balanceador de cargas de red del proxy externo global
Balanceador de cargas de red del proxy interno entre regiones

Traffic Director también es compatible con optimizaciones avanzadas de balanceo de cargas. Para obtener más detalles, consulta Descripción general del balanceo de cargas avanzado en la documentación de Traffic Director.

Una política de balanceo de cargas de servicio (serviceLbPolicy) es un recurso asociado con el servicio de backend del balanceador de cargas. Una política de balanceo de cargas de servicios te permite personalizar los parámetros que influyen en cómo se distribuye el tráfico dentro de los backends asociados con un servicio de backend:

Personaliza el algoritmo de balanceo de cargas que se usa para determinar cómo se distribuye el tráfico dentro de una región o una zona en particular.
Habilita el vaciado de capacidad automática para que el balanceador de cargas pueda vaciar rápidamente el tráfico de los backends en mal estado.
Establece un umbral de conmutación por error para determinar cuándo se considera que un backend está en mal estado. Esto permite que el tráfico se traslade a un backend diferente para evitar backends en mal estado.

Además, puedes designar backends específicos como backends preferidos. Estos backends deben usarse en toda su capacidad antes de que se envíen solicitudes a los backends restantes.

En el siguiente diagrama, se muestra cómo Cloud Load Balancing evalúa el enrutamiento, el balanceo de cargas y la distribución de tráfico.

Cómo Cloud Load Balancing toma decisiones de enrutamiento y distribución de tráfico.

Antes de comenzar

Antes de revisar el contenido de esta página, revisa con cuidado el proceso de distribución de solicitudes que se describe en la página de descripción general del balanceador de cargas de aplicaciones externo. Para los balanceadores de cargas que siempre son de nivel Premium, todos los algoritmos de balanceo de cargas que se describen en esta página admiten desbordamiento entre regiones si una región de primera elección ya está llena.

Backends compatibles

Las políticas de balanceo de cargas de servicio y los backends preferidos se pueden configurar solo en balanceadores de cargas que usan los backends compatibles, como se indica en la siguiente tabla.

Backend	¿Es compatible?
Grupos de instancias No administrado Administrado zonal
MIG regionales
NEG zonales (extremos `GCE_VM_IP_PORT`)
NEG híbridos (extremos `NON_GCP_PRIVATE_IP_PORT`)
NEG sin servidores
NEG de Internet
NEG de Private Service Connect

Algoritmos de balanceo de cargas

En esta sección, se describen los algoritmos de balanceo de cargas que puedes configurar en una política de balanceo de cargas de servicios. Si no configuras un algoritmo o si no configuras una política de balanceo de cargas de servicios en absoluto, el balanceador de cargas usa WATERFALL_BY_REGION de forma predeterminada.

Cascada por región

WATERFALL_BY_REGION es el algoritmo de balanceo de cargas predeterminado. Con este algoritmo, de manera no individualizada, todos los Google Front Ends (GFE) de una región intentan completar backends en proporción a las capacidades de destino configuradas (modificadas por sus escaladores de capacidad).

Cada GFE individual de segunda capa prefiere seleccionar extremos o instancias de backend en una zona lo más cercana posible (definida por el tiempo de ida y vuelta de la red) al GFE de segunda capa. Debido a que WATERFALL_BY_REGION minimiza la latencia entre zonas, a tasas de solicitud bajas, cada GFE de segunda capa puede enviar solicitudes de forma exclusiva a los backends en la zona preferida de GFE de segunda capa.

Difundir a la región

El algoritmo SPRAY_TO_REGION modifica el comportamiento individual de cada GFE de segunda capa en la medida en que cada GFE de segunda capa no tenga preferencia para seleccionar instancias o extremos de backend que se encuentran en una zona lo más cerca posible del GFE de segunda capa. Con SPRAY_TO_REGION, cada GFE de segunda capa envía solicitudes a todas las instancias o extremos de backend, en todas las zonas de la región, sin preferencia por un tiempo de ida y vuelta más corto entre el GFE de segunda capa y las instancias o extremos de backend.

Al igual que WATERFALL_BY_REGION, de manera no individualizada, todos los GFE de segunda capa en la región completan backends en proporción a sus capacidades de destino configuradas (modificadas por sus escaladores de capacidad).

Si bien SPRAY_TO_REGION proporciona una distribución más uniforme entre backends en todas las zonas de una región, en especial con porcentajes de solicitudes bajos, esta distribución uniforme tiene las siguientes consideraciones:

Cuando los backends fallan (pero continúan pasando sus verificaciones de estado), más GFE de segunda capa se ven afectados, aunque el impacto individual es menos grave.
Debido a que cada GFE de segunda capa no tiene preferencia para una zona sobre otra, los GFE de segunda capa crean más tráfico entre zonas. Según la cantidad de solicitudes que se procesen, cada GFE de segunda capa también puede crear más conexiones TCP a los backends.

Cascada por zona

El algoritmo WATERFALL_BY_ZONE modifica el comportamiento individual de cada GFE de segunda capa en la medida en que cada GFE de segunda capa tiene una preferencia muy fuerte de seleccionar instancias o extremos de backend que se encuentran en la zona más cercana posible al GFE de segunda capa. Con WATERFALL_BY_ZONE, cada GFE de segunda capa solo envía solicitudes a instancias o extremos de backend en otras zonas de la región cuando la segunda capa GFE completó (o proporcionalmente completó en exceso) instancias o extremos en el backend en su zona más preferida.

El algoritmo WATERFALL_BY_ZONE minimiza la latencia con las siguientes consideraciones:

WATERFALL_BY_ZONE no minimiza inherentemente las conexiones entre zonas. El algoritmo se controla solo mediante la latencia.
WATERFALL_BY_ZONE no garantiza que cada GFE de segunda capa siempre llene su zona más preferida antes de llenar otras zonas. Los eventos de mantenimiento pueden provocar de forma temporal que todo el tráfico de un GFE de segunda capa se envíe a instancias o extremos de backend en otra zona.
WATERFALL_BY_ZONE puede dar como resultado una distribución menos uniforme de las solicitudes entre todos los extremos o las instancias de backend dentro de la región en general. Por ejemplo, los extremos o las instancias de backend en la zona más preferida del GFE de segunda capa pueden llenarse al máximo de su capacidad, mientras que los backends en otras zonas no se llenan hasta la capacidad.

Compara los algoritmos de balanceo de cargas

En la siguiente tabla, se comparan los diferentes algoritmos de balanceo de cargas.

Comportamiento	Cascada por región	Difundir a la región	Cascada por zona
Uso uniforme de la capacidad dentro de una sola región	Sí	Sí	No.
Uso uniforme de la capacidad entre varias regiones	No.	No	No.
División del tráfico uniforme desde el balanceador de cargas	No.	Sí	No.
Distribución de tráfico entre zonas	Sí. El tráfico se distribuye de manera uniforme entre las zonas de una región, a la vez que se optimiza la latencia de red. Es posible que el tráfico se envíe a través de las zonas si es necesario.	Sí	Sí. El tráfico primero se dirige a la zona más cercana hasta que alcanza el máximo de capacidad. Luego, se dirige a la siguiente zona más cercana.
Sensibilidad a los aumentos repentinos de tráfico en una zona local	Promedio; depende de la cantidad de tráfico que ya se haya cambiado para balancear las zonas.	Más baja; los aumentos repentinos de tráfico de una sola zona se distribuyen en todas las zonas de la región.	Más alta; es probable que la misma zona entregue por completo los aumentos repentinos de zona hasta que el balanceador de cargas pueda reaccionar.

Desvío de capacidad automática

Cuando un backend está en mal estado, por lo general, deseas excluirlo de las decisiones de balanceo de cargas lo más rápido posible. La exclusión de backends en mal estado optimiza la latencia general mediante el envío del tráfico solo a los backends en buen estado.

Cuando habilitas la función de desvío de capacidad automática, el balanceador de cargas escala automáticamente la capacidad de un backend a cero cuando menos del 25% de las instancias o extremos del backend pasan las verificaciones de estado. Esto quita el backend en mal estado del grupo de balanceo de cargas global. Esta acción equivale a configurar backendService.capacityScaler en 0 para un backend cuando deseas evitar el enrutamiento del tráfico a ese backend.

Si el 35% (10% por encima del umbral) de las instancias o los extremos de backend desviados de forma automática pasan las verificaciones de estado durante 60 segundos, el backend no se desvía de forma automática y se vuelve a agregar al grupo de balanceo de cargas. Esto garantiza que el backend esté en buen estado y no cambie entre un estado desviado y no desviado.

Incluso con el desvío de capacidad automática habilitado, el balanceador de cargas no desvía más del 50% de los backends conectados a un servicio de backend, sin importar su estado. Mantener el 50% de los backends conectados reduce el riesgo de sobrecargar los backends en buen estado.

Un caso práctico de desvío de capacidad automática es usarlo para minimizar el riesgo de sobrecargar tus backends preferidos. Por ejemplo, si un backend se marca como preferido, pero la mayoría de sus instancias o extremos están en mal estado, el desvío de capacidad automática quita el backend del grupo de balanceo de cargas. En lugar de sobrecargar las instancias o los extremos en buen estado restantes en el backend preferido, el desvío de capacidad automática cambia el tráfico a otros backends.

Puedes habilitar el desvío de capacidad automática como parte de la política de balanceo de cargas del servicio. Para obtener más información, consulta Configura una política de balanceo de cargas de servicio.

La capacidad automática no es compatible con backends que no usan un modo de balanceo. Esto incluye backends, como NEG de Internet, NEG sin servidores y NEG de PSC.

Umbral de conmutación por error

El balanceador de cargas determina la distribución del tráfico entre backends de varios niveles. En estado estable, envía tráfico a backends que se seleccionan en función de uno de los algoritmos de balanceo de cargas descritos con anterioridad. Estos backends, llamados backends principales, se consideran óptimos en términos de latencia y capacidad.

El balanceador de cargas también realiza un seguimiento de otros backends que se pueden usar si los backends principales están en mal estado y no pueden manejar el tráfico. Estos backends se denominan backends de conmutación por error. Estos backends suelen ser backends cercanos con capacidad restante.

Si las instancias o los extremos en el backend principal están en mal estado, el balanceador de cargas no cambiará el tráfico a otros backends de inmediato. En cambio, el balanceador de cargas primero cambia el tráfico a otras instancias o extremos en buen estado en el mismo backend para estabilizar la carga del tráfico. Si demasiados extremos en un backend principal están en mal estado, y los extremos restantes en el mismo backend no pueden manejar el tráfico adicional, el balanceador de cargas usa el umbral de conmutación por error para determinar cuándo comenzar a enviar tráfico a un backend de conmutación por error. El balanceador de cargas tolera el mal estado en el backend principal hasta el umbral de la conmutación por error. Después de eso, el tráfico cambia del backend principal.

El umbral de conmutación por error es un valor entre 1 y 99, expresado como un porcentaje de extremos en un backend que debe estar en buen estado. Si el porcentaje de extremos en buen estado es inferior al umbral de conmutación por error, el balanceador de cargas intenta enviar tráfico a un backend de conmutación por error. De forma predeterminada, el umbral de conmutación por error es 70.

Si el umbral de conmutación por error es demasiado alto, pueden ocurrir desbordamientos innecesarios de tráfico debido a cambios de estado transitorios. Si el umbral de conmutación por error es demasiado bajo, el balanceador de cargas continúa enviando tráfico a los backends principales, aunque haya muchos extremos en mal estado.

Las decisiones de conmutación por error están localizadas. Cada Google Front End local (GFE) se comporta de forma independiente. Es tu responsabilidad asegurarte de que los backends de conmutación por error puedan manejar el tráfico adicional.

El tráfico de conmutación por error puede generar backends sobrecargados. Incluso si un backend está en mal estado, es posible que el balanceador de cargas envíe tráfico allí. Para excluir backends en mal estado del grupo de backends disponibles, habilita la función de desvío de capacidad automática.

Backends preferidos

Los backends preferidos son backends cuya capacidad deseas usar completamente antes de derramar tráfico a otros backends. Cualquier tráfico que supere la capacidad configurada de los backends preferidos se enruta a los backends no preferidos restantes. El algoritmo de balanceo de cargas distribuye el tráfico entre los backends no preferidos de un servicio de backend.

Puedes configurar el balanceador de cargas para que prefiera y use por completo uno o más backends conectados a un servicio de backend antes de enrutar las solicitudes posteriores a los backends restantes.

Ten en cuenta las siguientes limitaciones cuando uses backends preferidos:

Los backends configurados como backends preferidos pueden estar más lejos de los clientes y generar una latencia promedio más alta para las solicitudes de los clientes. Esto sucede incluso si hay otros backends más cercanos que podrían haber entregado a los clientes con una latencia más baja.
Ciertos algoritmos de balanceo de cargas (WATERFALL_BY_REGION, SPRAY_TO_REGION y WATERFALL_BY_ZONE) no se aplican a los backends configurados como backends preferidos.

Para obtener información sobre cómo configurar backends preferidos, consulta Configura backends preferidos.

Configura una política de balanceo de cargas de servicios

El recurso de política de balanceo de cargas de servicios te permite configurar los siguientes campos:

Algoritmo de balanceo de cargas
Desvío de capacidad automática
Umbral de conmutación por error

Para establecer un backend preferido, consulta Configura backends preferidos.

Crear una política

Para crear y configurar una política de balanceo de cargas de servicios, completa los siguientes pasos:

Crea un recurso de política de balanceo de cargas de servicios. Puedes hacerlo mediante un archivo YAML o directamente mediante los parámetros gcloud.
- Con un archivo YAML. Debes especificar las políticas de balanceo de cargas de servicios en un archivo YAML. Aquí hay un archivo YAML de muestra que muestra cómo configurar un algoritmo de balanceo de cargas, habilitar el vaciado de capacidad automática y establecer un umbral de conmutación por error personalizado:
```
name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
autoCapacityDrain:
    enable: True
failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
```
  Reemplaza lo siguiente:
  - PROJECT_ID: El ID del proyecto.
  - SERVICE_LB_POLICY_NAME: El nombre de la política de balanceo de cargas del servicio.
  - FAILOVER_THRESHOLD_VALUE: Es el valor del umbral de conmutación por error. Debe ser un número entre 1 y 99.
  - LOAD_BALANCING_ALGORITHM: El algoritmo de balanceo de cargas que se usará. Puede ser SPRAY_TO_REGION, WATERFALL_BY_REGION o WATERFALL_BY_ZONE.
  Después de crear el archivo YAML, importa el archivo a una nueva política de balanceo de cargas de servicio.
```
gcloud beta network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
 --source=PATH_TO_POLICY_FILE \
 --location=global
```
- Sin un archivo YAML. Como alternativa, puedes configurar las características de la política de balanceo de cargas de servicios sin usar un archivo YAML.
  
  Para configurar el algoritmo de balanceo de cargas y habilitar el vaciado automático, usa los siguientes parámetros:
```
gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
 --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \
 --auto-capacity-drain \
 --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \
 --location=global
```
  Reemplaza lo siguiente:
  - SERVICE_LB_POLICY_NAME: El nombre de la política de balanceo de cargas del servicio.
  - LOAD_BALANCING_ALGORITHM: El algoritmo de balanceo de cargas que se usará. Puede ser SPRAY_TO_REGION, WATERFALL_BY_REGION o WATERFALL_BY_ZONE.
  - FAILOVER_THRESHOLD_VALUE: Es el valor del umbral de conmutación por error. Debe ser un número entre 1 y 99.

Actualiza un servicio de backend para que su campo --service-lb-policy haga referencia al recurso de política de balanceo de cargas del servicio recién creado. Un servicio de backend solo se puede asociar con un recurso de política de balanceo de cargas de servicios.

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
  --service-lb-policy=SERVICE_LB_POLICY_NAME \
  --global

Puedes asociar una política de balanceo de cargas de servicios con un servicio de backend mientras creas el servicio de backend.

gcloud beta compute backend-services create BACKEND_SERVICE_NAME \
    --protocol=PROTOCOL \
    --port-name=NAMED_PORT_NAME \
    --health-checks=HEALTH_CHECK_NAME \
    --load-balancing-scheme=LOAD_BALANCING_SCHEME \
    --service-lb-policy=SERVICE_LB_POLICY_NAME \
    --global

Quita una política

Para quitar una política de balanceo de cargas de servicios de un servicio de backend, usa el siguiente comando:

gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

Configura backends preferidos

Puedes configurar backends preferidos mediante Google Cloud CLI o la API.

gcloud

Agrega un backend preferido

Para establecer un backend preferido, usa el comando gcloud beta compute backend-services add-backend para fijar la marca --preference cuando agregues el backend al servicio de backend.

gcloud beta compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

Reemplaza PREFERENCE por el nivel de preferencia que deseas asignar al backend. Puede ser PREFERRED o DEFAULT.

El resto del comando depende del tipo de backend que uses (grupo de instancias o NEG). Para obtener todos los parámetros obligatorios, consulta el comando gcloud beta compute backend-services add-backend.

Actualiza las preferencias de un backend

Para actualizar el parámetro --preference de un backend, usa el comando gcloud beta compute backend-services update-backend.

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

El resto del comando depende del tipo de backend que uses (grupo de instancias o NEG). En el siguiente comando de ejemplo, se actualiza la preferencia de un grupo de instancias de backend y se establece en PREFERRED:

gcloud beta compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

API

Para establecer un backend preferido, fija la marca preference en cada backend mediante el recurso backendServices global.

Aquí hay un ejemplo que muestra cómo configurar la preferencia de backend:

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

Reemplaza lo siguiente:

PROJECT_ID: el ID del proyecto
BACKEND_SERVICE_NAME: es el nombre del servicio de backend.
BACKEND_1_NAME: el nombre del backend preferido.
BACKEND_2_NAME: el nombre del backend predeterminado.

Soluciona problemas

Los patrones de distribución del tráfico pueden cambiar cuando adjuntas una nueva política de balanceo de cargas de servicios a un servicio de backend.

Para depurar problemas de tráfico, usa Cloud Monitoring para ver cómo fluye el tráfico entre el balanceador de cargas y el backend. Los registros y las métricas de Cloud Load Balancing también pueden ayudarte a comprender el comportamiento del balanceo de cargas.

En esta sección, se resumen algunas situaciones comunes que puedes ver en la configuración recién expuesta.

El tráfico de una sola fuente se envía a demasiados backends distintos

Este es el comportamiento deseado del algoritmo SPRAY_TO_REGION. Sin embargo, es posible que experimentes problemas causados por una distribución más amplia del tráfico. Por ejemplo, las tasas de aciertos de caché pueden disminuir porque los backends ven el tráfico de una selección más amplia de clientes. En este caso, considera usar otros algoritmos, como WATERFALL_BY_REGION.

No se envía tráfico a los backends con muchos extremos en mal estado

Este es el comportamiento deseado cuando autoCapacityDrain se habilita. Los backends con muchos extremos en mal estado se desvían y se quitan del grupo de balanceo de cargas. Si no deseas este comportamiento, puedes inhabilitar el desvío de capacidad automática. Sin embargo, esto significa que el tráfico se puede enviar a backends con muchos extremos en mal estado y las solicitudes pueden fallar.

Se envía el tráfico a backends más distantes antes que a los más cercanos

Este es el comportamiento deseado si tus backends preferidos están más lejos que los backends predeterminados. Si no deseas este comportamiento, actualiza la configuración de preferencia para cada backend según corresponda.

No se envía tráfico a algunos backends cuando se usan backends preferidos

Este es el comportamiento deseado cuando tus backends preferidos aún no alcanzaron la capacidad. Los backends preferidos se asignan primero en función de la latencia de tiempo de ida y vuelta a estos backends.

Si deseas que el tráfico se envíe a otros backends, puedes realizar una de las siguientes acciones:

Actualiza la configuración de preferencias para los otros backends.
Establece una configuración de capacidad de destino más baja para tus backends preferidos. La capacidad de destino se configura mediante los campos max-rate o max-utilization, según el modo de balanceo del servicio de backend.

Se envía el tráfico a un backend remoto durante los cambios transitorios de estado

Este es el comportamiento deseado cuando el umbral de conmutación por error se establece en un valor alto. Si deseas que el tráfico continúe con los backends principales cuando hay cambios de estado transitorios, establece este campo en un valor más bajo.

Los extremos en buen estado están sobrecargados cuando otros extremos no están en buen estado

Este es el comportamiento deseado cuando el umbral de conmutación por error se establece en un valor bajo. Cuando los extremos están en mal estado, el tráfico destinado a estos extremos en mal estado se distribuye entre los extremos restantes en el mismo backend. Si deseas que el comportamiento de la conmutación por error se active antes, establece este campo en un valor más alto.

Limitaciones

Cada servicio de backend solo se puede asociar con un único recurso de política de balanceo de cargas de servicio.