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 servicio 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 para aumentar la capacidad antes de que se envíen las 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 por zonas
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 servicio, 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 de segunda capa prefiere seleccionar instancias de backend o extremos en una zona que esté lo más cerca posible (definido 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, con tasas de solicitudes bajas, cada GFE de segunda capa puede enviar solicitudes de forma exclusiva a los backends en la zona preferida de GFE de segunda capa.

Apunta 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 tiene preferencia para seleccionar instancias de backend o extremos que estén en una zona lo más cerca posible de GFE de segunda capa. Con SPRAY_TO_REGION, cada GFE de segunda capa envía solicitudes a todas las instancias de backend o extremos, en todas las zonas de la región, sin preferencia por un tiempo de ida y vuelta más corto entre 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 tasas de solicitudes bajas, esta distribución uniforme implica las siguientes consideraciones:

Cuando los backends fallan (pero siguen pasando sus verificaciones de estado), se ven más GFE de segunda capa, aunque el impacto individual es menos grave.
Debido a que cada GFE de segunda capa no tiene preferencia por 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 podría 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 sólida para seleccionar instancias o extremos de backend que 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 de forma inherente las conexiones entre zonas. El algoritmo se dirige solo mediante latencia.
WATERFALL_BY_ZONE no garantiza que cada GFE de segunda capa siempre llene la zona que más prefiera antes de completar otras zonas. Los eventos de mantenimiento pueden hacer que se envíe de forma temporal todo el tráfico de un GFE de segunda capa a las instancias de backend o a los extremos en otra zona.
WATERFALL_BY_ZONE puede dar como resultado una distribución menos uniforme de solicitudes entre todas las instancias de backend o extremos dentro de la región en general. Por ejemplo, las instancias de backend o los extremos en la zona más preferida de GFE de segunda capa pueden estar llenos de capacidad, mientras que los backends en otras zonas no están llenas de 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	Apunta a la región	Cascada por zona
Uso uniforme de capacidad dentro de una sola región	Sí	Sí	No.
Uso uniforme de capacidad en 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 zonas de una región, a la vez que se optimiza la latencia de la red. Es posible que se envíe tráfico entre zonas si es necesario.	Sí	Sí. El tráfico primero se dirige a la zona más cercana hasta que alcanza su capacidad máxima. Luego, pasa a la siguiente zona más cercana.
Sensibilidad a los aumentos repentinos de tráfico en una zona local	Promedio; depende de cuánto tráfico se haya desplazado para balancear entre 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, quieres 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 de tráfico solo a backends en buen estado.

Cuando habilitas la característica 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 verificaciones de estado. Esto quita el backend en mal estado del grupo de balanceo de cargas global. Esta acción es funcionalmente equivalente a configurar backendService.capacityScaler en 0 para un backend cuando quieras evitar el enrutamiento de tráfico a ese backend.

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

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

Un caso de uso de vaciado de capacidad automático es usarlo para minimizar el riesgo de sobrecarga de tus backends preferidos. Por ejemplo, si un backend está marcado como preferido, pero la mayoría de sus instancias o extremos están en mal estado, el vaciado de capacidad automático 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 de 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 por completo antes de desbordar el tráfico a otros backends. Cualquier tráfico que supere la capacidad configurada de 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.
Algunos 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 establecer backends preferidos, consulta Configura backends preferidos.

Configura una política de balanceo de cargas de servicio

El recurso de la política de balanceo de cargas de servicio 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 servicio, completa los siguientes pasos:

Crea un recurso de política de balanceo de cargas de servicio. Puedes hacerlo mediante un archivo YAML o directamente con 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
- loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
- failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
```
  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.
  - 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.
  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 funciones de la política de balanceo de cargas de servicio 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 servicio.

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 servicio 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 servicio 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 los backends preferidos mediante la CLI de Google Cloud 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 usas (grupo de instancias o NEG). Para ver 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 usas (grupo de instancias o NEG). Con el siguiente comando de ejemplo, se actualiza la preferencia de un grupo de instancias de backend y se configura como 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.

A continuación, se muestra un ejemplo de cómo configurar las preferencias 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 de tráfico pueden cambiar cuando adjuntas una política de balanceo de cargas de servicio nueva 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 debido a una distribución más amplia de tu 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.

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

Este es el comportamiento deseado cuando autoCapacityDrain está habilitado. 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 vaciado de capacidad automática. Sin embargo, esto significa que el tráfico se puede enviar a los backends con muchos extremos en mal estado y las solicitudes pueden fallar.

Se envía el tráfico a backends más distantes antes de 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 enviar tráfico a otros backends, puedes realizar una de las siguientes acciones:

Actualiza la configuración de preferencia 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.