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

Cloud Service Mesh también admite optimizaciones avanzadas de balanceo de cargas. Para obtener detalles, consulta Descripción general del balanceo de cargas avanzado en la documentación de Cloud Service Mesh.

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

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 del servicio y todas las funciones que se describen en esta página requieren backends compatibles que admitan un modo de balanceo. Los backends compatibles se resumen en la siguiente tabla:

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 la región más cercana al usuario intentan completar backends en proporción a las capacidades de destino configuradas (modificadas por sus escaladores de capacidad).

Cada GFE de segunda capa individual prefiere seleccionar instancias o extremos 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 del GFE de segunda capa.

Si todos los backends de la región más cercana se ejecutan en su límite de capacidad configurado, el tráfico comenzará a desbordarse a la siguiente región más cercana mientras se optimiza la latencia de la red.

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 los backends en todas las zonas de una región, especialmente a tasas de solicitudes bajas, esta distribución uniforme conlleva las siguientes consideraciones:

• Cuando los backends fallan (pero siguen pasando las verificaciones de estado), se ven afectados 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 procesan, cada GFE de segunda capa también 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 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.

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

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 orienta solo por la latencia.
• WATERFALL_BY_ZONE no garantiza que cada GFE de segunda capa siempre complete su zona más preferida antes de completar otras zonas. Los eventos de mantenimiento pueden hacer que, de forma temporal, 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.

Desvío y anulación de capacidad automática

El desvío y la recuperación de capacidad automática combinan los conceptos de las verificaciones de estado y la capacidad del backend. Con el desvío de capacidad automática, las verificaciones de estado se usan como un indicador adicional para establecer en cero la capacidad efectiva del backend. Con el drenaje automático de capacidad, las verificaciones de estado se usan como un indicador adicional para restablecer la capacidad efectiva del backend a su valor anterior.

Sin el drenaje y la recuperación automáticos de la capacidad, si deseas dirigir las solicitudes lejos de todos los backends de una región en particular, debes establecer manualmente en cero la capacidad efectiva de cada backend de esa región. Por ejemplo, puedes usar el escalador de capacidad para hacerlo.

Con el desvío y la recuperación de capacidad automática, las verificaciones de estado se pueden usar como un indicador para ajustar la capacidad de un backend, ya sea mediante el desvío o la recuperación.

Para habilitar el desvío y la recuperación de capacidad automática, consulta Configura una política de balanceo de cargas de servicio.

Desvío de capacidad automática

El desvío de capacidad automática establece la capacidad de un backend en cero cuando se cumplen las siguientes condiciones:

• Menos del 25% de las instancias o los extremos del backend pasan las verificaciones de estado.
• La cantidad total de grupos de instancias de backend o NEG que se deben agotar automáticamente no supera el 50% del total de grupos de instancias de backend o NEG. Cuando se calcula la proporción del 50%, los backends con cero capacidad no se incluyen en el numerador. Sin embargo, todos los backends se incluyen en el denominador.

Los backends sin capacidad son los siguientes:

• Grupos de instancias de backend sin instancias miembro, en los que la capacidad del grupo de instancias se define por instancia
• NEG de backend sin extremos de miembros, en los que la capacidad del NEG se define por extremo
• Grupos de instancias de backend o NEG con escaladores de capacidad establecidos en cero

La capacidad del backend que se desvía automáticamente es funcionalmente equivalente a configurar manualmente backendService.backends[].capacityScaler de un backend en 0, pero sin establecer el valor del escalador de capacidad.

Desvío de capacidad automática

El desvío de capacidad automática muestra la capacidad de un backend al valor controlado por el escalador de capacidad del backend cuando el 35% o más de las instancias o los extremos del backend pasan las verificaciones de estado durante al menos 60 segundos. El requisito de 60 segundos reduce las probabilidades de drenaje y desagüe secuenciales cuando las verificaciones de estado fallan y se aprueban en rápida sucesión.

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. Todo el tráfico que supere la capacidad configurada de los backends preferidos se enruta a los backends restantes que no son preferidos. 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 ocurre incluso si hay otros backends más cercanos que podrían haber entregado 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 más 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:

1. Crea un recurso de política de balanceo de cargas de servicios. Puedes hacerlo con un archivo YAML o directamente con 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 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 del 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 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.

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

Cómo quitar una política

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

gcloud 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 compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

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

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

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

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 podrías ver en la configuración recientemente expuesta.

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

Este es el comportamiento previsto del algoritmo SPRAY_TO_REGION. Sin embargo, es posible que tengas problemas debido a la distribución más amplia de tu tráfico. Por ejemplo, las tasas de acierto de caché podrían 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 backends con muchos extremos en mal estado

Este es el comportamiento previsto cuando autoCapacityDrain está habilitado. Los backends con muchos extremos en mal estado se agotan 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 no saludables, 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 alcanzan la capacidad. Los backends preferidos se asignan primero en función de la latencia del tiempo de ida y vuelta a estos backends.

Si deseas que el tráfico se envíe a otros backends, puedes hacer lo siguiente:

• Actualiza la configuración de preferencias para los otros backends.
• Establece una configuración de capacidad objetivo 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.