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.

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 Administración 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 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 bajas tasas de solicitudes, 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.

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 del balanceador de cargas	No	Sí	No
Distribución del tráfico entre zonas	Sí. El tráfico se distribuye de manera uniforme entre las zonas de una región y, al mismo tiempo, se optimiza la latencia de la red. Si es necesario, el tráfico se puede enviar a varias zonas.	Sí	Sí. El tráfico primero va a la zona más cercana hasta que alcanza su 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 trasladó para equilibrarlo entre 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 no está en buen estado, por lo general, se recomienda 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, ya que envía tráfico solo a 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 elimina el backend en mal estado del grupo de balanceo de cargas global. Esta acción es funcionalmente equivalente a establecer backendService.capacityScaler en 0 para un backend cuando deseas evitar enrutar el 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. 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

Nota: En esta sección, se supone un nivel intermedio o avanzado de familiaridad con Cloud Load Balancing. En los pasos, no se explica la creación de un servicio de backend ni ninguna otra configuración básica del balanceador de cargas. Para implementar la configuración básica, consulta la documentación del balanceador de cargas correspondiente.

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

Agrega un backend preferido

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

gcloud 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 conocer todos los parámetros obligatorios, consulta el comando gcloud compute backend-services add-backend.

Actualiza las preferencias de un backend

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

gcloud 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 ejemplo de comando, se actualiza la preferencia de un grupo de instancias de backend y se establece en PREFERRED:

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

Este es 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 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 se habilita autoCapacityDrain. 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.