Optimizaciones avanzadas del balanceo de carga

En esta página se describe cómo configurar optimizaciones avanzadas de costes, latencia y resiliencia para balanceadores de carga de aplicaciones y balanceadores de carga de red proxy.

Cloud Service Mesh también admite optimizaciones avanzadas del balanceo de carga. Para obtener más información, consulta la descripción general del balanceo de carga avanzado en la documentación de Cloud Service Mesh.

Cloud Load Balancing ofrece las siguientes funciones avanzadas:

  • Política de balanceo de carga de servicio. Una política de balanceo de carga de servicio (serviceLbPolicy) es un recurso asociado al servicio de backend del balanceador de carga. Una política de balanceo de carga de servicio te permite personalizar los siguientes parámetros para influir en la forma en que se distribuye el tráfico entre los backends asociados a un servicio de backend:

    • Algoritmos de balanceo de carga. Personaliza el algoritmo de balanceo de carga que se usa para determinar cómo se distribuye el tráfico en una región o una zona concretas.
    • Consumo automático de capacidad. Habilita el drenaje automático de capacidad para que el balanceador de carga pueda drenar rápidamente el tráfico de los backends que no estén en buen estado.
    • Umbral de conmutación por error. Define un umbral de conmutación por error para determinar cuándo se considera que un backend no está en buen estado. De esta forma, el tráfico puede pasar a otro backend para evitar los que no estén en buen estado.
    • Aislamiento del tráfico. Evita los fallos en cascada limitando o prohibiendo el desbordamiento del tráfico entre regiones.

  • Back-ends preferidos. Puedes designar back-ends específicos como back-ends preferidos. Estos back-ends deben usarse al máximo antes de enviar solicitudes a los back-ends restantes.

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

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

Antes de empezar

Antes de revisar el contenido de esta página, consulta detenidamente el proceso de solicitud de distribución descrito en la página de descripción general del balanceador de carga de aplicaciones externo. En el caso de los balanceadores de carga que siempre son de nivel Premium, todos los algoritmos de balanceo de carga descritos en esta página admiten el desbordamiento entre regiones si una región de primera opción ya está llena.

Balanceadores de carga y backends admitidos

Los siguientes balanceadores de carga admiten políticas de balanceo de carga de servicio y backends preferidos:

  • Balanceador de carga de aplicación externo global
  • Balanceador de carga de aplicación interno entre regiones
  • Balanceador de carga de red con proxy externo global
  • Balanceador de carga de red con proxy interno interregional

Para usar las funciones descritas en esta página, se necesitan back-ends compatibles que admitan un modo de equilibrio. Los back-ends admitidos se resumen en la siguiente tabla:

Backend ¿Es compatible?
Grupos de instancias
Se admiten los grupos de instancias sin gestionar y gestionados por zonas, pero no los grupos de instancias gestionados por regiones.
NEGs por zonas (puntos finales GCE_VM_IP_PORT)
NEGs por zonas (puntos finales GCE_VM_IP)
Los balanceadores de carga de aplicaciones y los balanceadores de carga de red de proxy no admiten estos tipos de NEGs.
NEGs híbridas (puntos finales NON_GCP_PRIVATE_IP_PORT)
NEGs sin servidor
NEGs de Internet
NEGs de Private Service Connect

Algoritmos de balanceo de carga

En esta sección se describen los algoritmos de balanceo de carga que puedes configurar en una política de balanceo de carga de servicio. Si no configuras un algoritmo o una política de balanceo de carga de servicio, el balanceador de carga usará WATERFALL_BY_REGION de forma predeterminada.

Cascada por región

WATERFALL_BY_REGION es el algoritmo de balanceo de carga predeterminado. Con este algoritmo, en conjunto, todos los front-ends de Google (GFEs) de la región más cercana al usuario intentan rellenar los back-ends en proporción a sus capacidades objetivo configuradas (modificadas por sus escaladores de capacidad).

Cada GFE de segunda capa prefiere seleccionar instancias de backend o endpoints en una zona que esté lo más cerca posible (definida por el tiempo de ida y vuelta de la red) del GFE de segunda capa. Como WATERFALL_BY_REGION minimiza la latencia entre zonas, con frecuencias de solicitudes bajas, cada GFE de segunda capa puede enviar solicitudes exclusivamente a los back-ends de la zona preferida del GFE de segunda capa.

Si todos los backends de la región más cercana están funcionando al límite de capacidad configurado, el tráfico empezará a desviarse a la siguiente región más cercana mientras se optimiza la latencia de la red.

Pintar en región

El algoritmo SPRAY_TO_REGION modifica el comportamiento individual de cada GFE de segunda capa de forma que cada GFE de segunda capa no tenga preferencia por seleccionar instancias o endpoints de backend que estén 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 endpoints 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 endpoints de backend.

Al igual que WATERFALL_BY_REGION, en conjunto, todos los GFE de segunda capa de la región rellenan los backends en proporción a sus capacidades objetivo configuradas (modificadas por sus escaladores de capacidad).

Aunque SPRAY_TO_REGION proporciona una distribución más uniforme entre los back-ends de todas las zonas de una región, especialmente con tasas de solicitudes bajas, esta distribución uniforme conlleva las siguientes consideraciones:

  • Cuando los back-ends dejan de funcionar (pero siguen superando sus comprobaciones de estado), se ven afectados más GFEs de segunda capa, aunque el impacto individual es menos grave.
  • Como cada GFE de segunda capa no tiene preferencia por una zona sobre otra, los GFEs de segunda capa crean más tráfico entre zonas. En función del número de solicitudes que se estén procesando, cada GFE de segunda capa también puede crear más conexiones TCP con los back-ends.

Cascada por zona

El algoritmo WATERFALL_BY_ZONE modifica el comportamiento individual de cada GFE de segunda capa de forma que cada GFE de segunda capa tenga una preferencia muy marcada por seleccionar instancias o endpoints de backend que se encuentren 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 endpoints de backend en otras zonas de la región cuando el GFE de segunda capa ha llenado (o llenado proporcionalmente) instancias o endpoints de backend en su zona preferida.

Al igual que WATERFALL_BY_REGION, en conjunto, todos los GFE de segunda capa de la región rellenan los backends en proporción a sus capacidades objetivo configuradas (modificadas por sus escaladores de capacidad).

El algoritmo WATERFALL_BY_ZONE minimiza la latencia teniendo en cuenta lo siguiente:

  • WATERFALL_BY_ZONE no minimiza de forma inherente las conexiones entre zonas. El algoritmo se basa únicamente en la latencia.
  • WATERFALL_BY_ZONE no garantiza que cada GFE de segunda capa siempre llene su zona preferida antes de llenar otras zonas. Los eventos de mantenimiento pueden provocar temporalmente que todo el tráfico de un GFE de segunda capa se envíe a instancias o endpoints de backend de otra zona.
  • WATERFALL_BY_ZONE puede provocar que las solicitudes no se distribuyan de forma uniforme entre todas las instancias o los endpoints de backend de la región. Por ejemplo, las instancias o los endpoints de backend de la zona más utilizada de la GFE de segunda capa pueden alcanzar su capacidad máxima, mientras que los backends de otras zonas no.

Comparar algoritmos de balanceo de carga

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

Comportamiento Cascada por región Pintar en región Cascada por zona
Uso uniforme de la capacidad en una sola región Sí Sí No
Uso uniforme de la capacidad en varias regiones No No No
División del tráfico uniforme desde el balanceador de carga No Sí No
Distribución del tráfico entre zonas Sí. El tráfico se distribuye de forma 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 entre zonas. Sí Sí. El tráfico se dirige primero a la zona más cercana hasta que se alcanza la capacidad. Después, se va a la zona más cercana.
Sensibilidad a los picos de tráfico en una zona local Media. Depende de la cantidad de tráfico que ya se haya desviado para equilibrar la carga entre las zonas. Más baja, ya que los picos de una sola zona se distribuyen entre todas las zonas de la región. Mayor; es probable que los picos de una sola zona se sirvan por completo en la misma zona hasta que el balanceador de carga pueda reaccionar.

Drenaje y recarga automáticos de la capacidad

La purga y la recuperación automáticas de la capacidad combinan los conceptos de comprobaciones del estado y capacidad de backend. Con la purga automática de capacidad, las comprobaciones del estado se usan como señal adicional para establecer la capacidad efectiva del backend en cero. Con la función de recuperación automática de capacidad, las comprobaciones de estado se usan como señal adicional para restaurar el valor anterior de la capacidad de backend efectiva.

Si no se usan las funciones de drenaje y recuperación automáticos de la capacidad, para dirigir las solicitudes lejos de todos los back-ends de una región concreta, debes definir manualmente la capacidad efectiva de cada back-end de esa región en cero. Por ejemplo, puedes usar el escalador de capacidad para hacerlo.

Con la purga y la restauración automáticas de la capacidad, las comprobaciones del estado se pueden usar como señal para ajustar la capacidad de un backend, ya sea purgando o restaurando.

Para habilitar la reducción y el aumento automáticos de la capacidad, consulta Configurar una política de balanceo de carga de un servicio.

Consumo excesivo de batería

La opción Reducción automática de la capacidad asigna el valor cero a la capacidad de cada grupo de instancias de backend candidato a reducción o NEG mientras la proporción de grupos de instancias de backend candidatos a reducción o NEGs en comparación con todos los grupos de instancias de backend o NEGs sea inferior al 50%. Al calcular la proporción del 50 %, los back-ends con capacidad cero no se incluyen en el numerador. Sin embargo, todos los back-ends se incluyen en el denominador.

Un backend candidato a drenaje es un grupo de instancias de backend o un NEG que tiene menos del 25% de sus instancias o endpoints miembros que superan las comprobaciones de estado del balanceador de carga.

Los back-ends con capacidad cero son los siguientes:

  • Grupos de instancias de backend sin instancias miembro, en los que la capacidad del grupo de instancias se define por instancia
  • NEGs de backend sin puntos finales miembros, en los que la capacidad del NEG se define por punto final
  • Grupos de instancias de backend o NEGs cuyo escalador de capacidad hayas definido en cero

La capacidad de backend agotada automáticamente es funcionalmente equivalente a definir manualmente el valor backendService.backends[].capacityScaler de un backend como 0, pero sin definir el valor del escalador de capacidad.

Recuperación automática de capacidad

La recuperación automática de la capacidad devuelve 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 endpoints del backend superan las comprobaciones de estado durante al menos 60 segundos. El requisito de 60 segundos reduce las probabilidades de que se produzcan drenajes y no drenajes secuenciales cuando las comprobaciones del estado fallan y se superan en rápida sucesión.

Umbral de conmutación por error

El balanceador de carga determina la distribución del tráfico entre los backends de forma multinivel. En el estado estable, envía tráfico a los back-ends que se seleccionan en función de uno de los algoritmos de balanceo de carga descritos anteriormente. Estos back-ends, denominados back-ends principales, se consideran óptimos en términos de latencia y capacidad.

El balanceador de carga también monitoriza otros backends que se pueden usar si los backends principales no están en buen estado y no pueden gestionar el tráfico. Estos backends se denominan backends de conmutación por error. Estos back-ends suelen ser back-ends cercanos con capacidad restante.

Si las instancias o los endpoints del backend principal dejan de estar en buen estado, el balanceador de carga no transfiere el tráfico a otros backends inmediatamente. En su lugar, el balanceador de carga primero transfiere el tráfico a otras instancias o endpoints en buen estado del mismo backend para ayudar a estabilizar la carga de tráfico. Si hay demasiados endpoints en mal estado en un backend principal y los endpoints restantes del mismo backend no pueden gestionar el tráfico adicional, el balanceador de carga usa el umbral de conmutación por error para determinar cuándo empezar a enviar tráfico a un backend de conmutación por error. El balanceador de carga tolera el mal estado del backend principal hasta el umbral de conmutación por error. Después, el tráfico se desvía del backend principal.

El umbral de conmutación por error es un valor entre 1 y 99, expresado como un porcentaje de los endpoints de un backend que deben estar en buen estado. Si el porcentaje de endpoints en buen estado es inferior al umbral de conmutación por error, el balanceador de carga 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, se pueden producir derivaciones de tráfico innecesarias debido a cambios transitorios en el estado. Si el umbral de conmutación por error es demasiado bajo, el balanceador de carga seguirá enviando tráfico a los backends principales aunque haya muchos endpoints en mal estado.

Las decisiones de conmutación por error son locales. Cada frontend de Google (GFE) local se comporta de forma independiente del resto. Es tu responsabilidad asegurarte de que tus back-ends de conmutación por error puedan gestionar el tráfico adicional.

El tráfico de conmutación por error puede provocar que los back-ends se sobrecarguen. Aunque un backend no esté en buen estado, el balanceador de carga puede seguir enviando tráfico a ese backend. Para excluir los back-ends incorrectos del grupo de back-ends disponibles, habilita la función de drenaje automático de capacidad.

Aislamiento de tráfico

De forma predeterminada, Cloud Load Balancing usa el algoritmo WATERFALL_BY_REGION para decidir a dónde se debe enrutar el tráfico de los usuarios. Con WATERFALL_BY_REGION, el tráfico se desvía a otras regiones cuando los backends de la región más cercana al usuario están llenos o no funcionan correctamente. Si habilitas el aislamiento del tráfico, el balanceador de carga podrá enrutar el tráfico solo a la región más cercana al usuario, aunque todos los back-ends de esa región estén funcionando al límite de capacidad configurado. Habilitar el aislamiento del tráfico puede ayudarte a evitar fallos regionales en cascada y limitar las posibles interrupciones a una sola región.

El aislamiento del tráfico se configura como parte de la política de balanceo de carga del servicio. Hay dos modos de aislamiento disponibles:

  • NEAREST (valor predeterminado): el balanceador de carga (es decir, el GFE de segunda capa o el proxy de Envoy que gestiona la conexión) envía el tráfico a las back-ends de la región más cercana al usuario. Si no hay backends configurados en la región más cercana o si los backends de la región más cercana no están en buen estado, el tráfico se dirige a la siguiente región más cercana y se optimiza la latencia de la red. Esto continúa a medida que cada región se queda sin capacidad de servicio.

  • ESTRICTO: el balanceador de carga (es decir, el proxy de Envoy que gestiona la conexión) envía el tráfico solo a los back-ends de la región más cercana al usuario. Si no hay backends configurados en la región más cercana o si los backends de la región más cercana no están en buen estado y no pueden atender solicitudes, el tráfico se rechaza y las solicitudes empiezan a fallar.

Sin aislamiento

En el siguiente diagrama se muestra cómo se comportan los balanceadores de carga interregionales cuando la función de aislamiento del tráfico no está habilitada.

Cómo se comporta Cloud Load Balancing cuando no está habilitado el aislamiento del tráfico.
Cómo se comporta Cloud Load Balancing cuando no está habilitado el aislamiento del tráfico

Más cercano

En el siguiente diagrama se muestra cómo se comportan los balanceadores de carga entre regiones cuando se habilita el aislamiento del tráfico con el modo NEAREST.

Cómo se comporta Cloud Load Balancing cuando el aislamiento del tráfico está habilitado en el modo NEAREST.
Cómo se comporta Cloud Load Balancing cuando la función de aislamiento del tráfico está habilitada en el modo NEAREST

Estricto

En el siguiente diagrama se muestra cómo se comportan los balanceadores de carga entre regiones cuando se habilita el aislamiento del tráfico con el modo STRICT.

Cómo se comporta Cloud Load Balancing cuando la función de aislamiento del tráfico está habilitada en el modo ESTRICTO.
Cómo se comporta Cloud Load Balancing cuando el aislamiento del tráfico está habilitado en el modo ESTRICTO.

Ten en cuenta lo siguiente antes de habilitar esta función:

  • Si los backends de una región están sobrecargados, el balanceador de carga puede seguir enviándoles tráfico adicional aunque los backends de otras regiones puedan gestionarlo. Esto significa que es más probable que los back-ends de cada región se sobrecarguen debido al tráfico adicional, por lo que debes planificarlo en consecuencia.

  • Aunque el aislamiento esté habilitado, el tráfico seguirá enrutándose a través de un plano de control global. Esto significa que sigue habiendo riesgo de que se produzcan fallos globales en varias regiones. Para mejorar el aislamiento a nivel de infraestructura, elige un balanceador de carga regional.

Cuando configures el modo de aislamiento del tráfico, también debes definir la granularidad del aislamiento en REGION, lo que evita que se produzca un desbordamiento del tráfico entre regiones. Si no se configura la granularidad, no se aplicará el aislamiento del tráfico. Para obtener más información sobre cómo habilitar el aislamiento del tráfico, consulta Configurar una política de balanceo de carga de servicio.

Back-ends preferidos

Los back-ends preferidos son aquellos cuya capacidad quieres usar por completo antes de desviar el tráfico a otros back-ends. El tráfico que supere la capacidad configurada de los backends preferidos se dirigirá a los backends no preferidos restantes. A continuación, el algoritmo de balanceo de carga distribuye el tráfico entre los backends no preferidos de un servicio de backend.

Puedes configurar tu balanceador de carga para que prefiera y use por completo uno o varios backends asociados 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 preferidos pueden estar más lejos de los clientes, lo que puede provocar una latencia media más alta en las solicitudes de los clientes. Esto ocurre aunque haya otros back-ends más cercanos que podrían haber servido a los clientes con una latencia menor.
  • Algunos algoritmos de balanceo de carga (WATERFALL_BY_REGION, SPRAY_TO_REGION y WATERFALL_BY_ZONE) no se aplican a los backends configurados como backends preferidos.

Para saber cómo definir back-ends preferidos, consulta Definir back-ends preferidos.

Configurar una política de balanceo de carga de servicio

El recurso de política de balanceo de carga de servicio te permite configurar los siguientes campos:

  • Algoritmo de balanceo de carga
  • Consumo excesivo de batería
  • Umbral de conmutación por error
  • Aislamiento de tráfico

Para definir un backend preferido, consulta Definir backends preferidos.

Crear una política

Siga estos pasos para crear y configurar una política de balanceo de carga de servicio.

Consola

Sigue estos pasos para crear una política de balanceo de carga de servicio.

  1. En la Google Cloud consola, ve a la página Balanceo de carga.

    Ir a Balanceo de carga

  2. Haz clic en Crear política de balanceo de carga de servicio.

  3. Introduce un Nombre para tu política de balanceo de carga de servicio.

  4. Para habilitar el drenaje automático de capacidad, selecciona Drenar el tráfico de los back-ends no saludables.

  5. En Umbral de buen estado de la conmutación por error, introduce un número entre 1 y 99.

  6. En Distribución del tráfico, selecciona el algoritmo de balanceo de carga que quieras usar.

  7. Haz clic en Crear.

gcloud

  1. Crea un recurso de política de balanceo de carga de servicio. Puede hacerlo mediante un archivo YAML o directamente con los parámetros gcloud.

    • Con un archivo YAML. Las políticas de balanceo de carga del servicio se especifican en un archivo YAML. Aquí tienes un archivo YAML de ejemplo que muestra cómo configurar un algoritmo de balanceo de carga, habilitar el drenaje automático de capacidad y definir 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
isolationConfig:
  isolationGranularity: ISOLATION_GRANULARITY
  isolationMode: ISOLATION_MODE

    Haz los cambios siguientes:

    • PROJECT_ID: el ID del proyecto.
    • SERVICE_LB_POLICY_NAME: nombre de la política de balanceo de carga del servicio.
    • FAILOVER_THRESHOLD_VALUE: 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 carga que se va a usar. Puede ser SPRAY_TO_REGION, WATERFALL_BY_REGION o WATERFALL_BY_ZONE.
    • ISOLATION_GRANULARITY: la granularidad de la restricción de aislamiento. Para evitar que se produzca un desbordamiento del tráfico entre regiones, asigna el valor REGION a esta opción. Si no se especifica ningún valor, no se aplica ningún aislamiento.
    • ISOLATION_MODE: el comportamiento de aislamiento. Los valores posibles son NEAREST o STRICT.

    Una vez que hayas creado el archivo YAML, impórtalo a una nueva política de balanceo de carga de servicio.

    gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
   --source=PATH_TO_POLICY_FILE \
   --location=global
    • Sin archivo YAML. También puede configurar las funciones de la política de balanceo de carga de servicios sin usar un archivo YAML.

    Para definir el algoritmo de balanceo de carga y habilitar el drenaje automático, usa el siguiente comando:

    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

    Haz los cambios siguientes:

    • SERVICE_LB_POLICY_NAME: nombre de la política de balanceo de carga del servicio.
    • LOAD_BALANCING_ALGORITHM: el algoritmo de balanceo de carga que se va a usar. Puede ser SPRAY_TO_REGION, WATERFALL_BY_REGION o WATERFALL_BY_ZONE.
    • FAILOVER_THRESHOLD_VALUE: el valor del umbral de conmutación por error. Debe ser un número entre 1 y 99.

    Para configurar el aislamiento del tráfico (vista previa), usa el siguiente comando:

    gcloud beta network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
   --isolation-config-granularity=ISOLATION_GRANULARITY \
   --isolation-config-mode=ISOLATION_MODE \
   --location=global

    Haz los cambios siguientes:

    • ISOLATION_GRANULARITY: la granularidad de la restricción de aislamiento. Para evitar que se produzca un desbordamiento del tráfico entre regiones, asigna el valor REGION a esta opción. Si no se especifica ningún valor, no se aplica ningún aislamiento.
    • ISOLATION_MODE: el comportamiento de aislamiento. Los valores posibles son NEAREST y STRICT.

  2. Actualiza un servicio backend para que su campo --service-lb-policy haga referencia al recurso de política de balanceo de carga del servicio que acabas de crear. Un servicio de backend solo se puede asociar a un recurso de política de balanceo de carga de servicio.

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

    También puede asociar una política de balanceo de carga de servicio a un servicio de backend al crear 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

Inhabilitar las funciones configuradas en la política

En esta sección se explica cómo restablecer o inhabilitar las funciones configuradas en la política de balanceo de carga del servicio.

Restablecer el algoritmo de balanceo de carga

Para restablecer el algoritmo de balanceo de carga, usa el siguiente comando para volver a definir el algoritmo de balanceo de carga predeterminado WATERFALL_BY_REGION:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --load-balancing-algorithm=WATERFALL_BY_REGION \
    --location=global

Restablecer el umbral de conmutación por error

Para restablecer el umbral de conmutación por error, usa el siguiente comando para volver a definirlo en el valor predeterminado de 70 segundos:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --failover-health-threshold=70 \
    --location=global

Inhabilitar el consumo automático de capacidad

Para inhabilitar el consumo automático de capacidad, usa el siguiente comando:

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --no-auto-capacity-drain \
    --location=global

Inhabilitar el aislamiento de tráfico

Para inhabilitar el aislamiento del tráfico (vista previa), asigna el valor UNSPECIFIED a ambos parámetros de configuración de aislamiento, tal como se muestra en el siguiente comando:

gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=UNSPECIFIED \
    --isolation-config-mode=UNSPECIFIED \
    --location=global

Eliminar una política

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

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

Definir back-ends preferidos

Puedes configurar los back-ends preferidos mediante la CLI de Google Cloud o la API.

Consola

Puedes designar un backend como backend preferido mientras creas un balanceador de carga mundial o multirregional en la Google Cloud consola.

Asigna el valor Preferred (Preferido) al campo Backend preference level (Nivel de preferencia de backend) cuando añadas el backend al servicio backend.

gcloud

Añadir un backend preferido

Para definir un backend preferido, usa el comando gcloud compute backend-services add-backend para definir la marca --preference cuando añadas el backend al servicio de backend.

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

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

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

Actualizar la preferencia 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 utilices (grupo de instancias o NEG). El siguiente comando de ejemplo actualiza la preferencia de un grupo de instancias de backend y la define como 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 definir un backend preferido, define la marca preference en cada backend mediante el recurso backendServices global.

Aquí tienes 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
      ...

Haz los cambios siguientes:

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

Solución de problemas

Los patrones de distribución del tráfico pueden cambiar cuando se asocia una nueva política de balanceo de carga de servicio 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 carga y el backend. Los registros y las métricas de Cloud Load Balancing también pueden ayudarte a comprender el comportamiento del balanceo de carga.

En esta sección se resumen algunos casos habituales que pueden darse cuando activas cada una de estas funciones.

Algoritmos de balanceo de carga

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

Este es el comportamiento previsto del algoritmo de 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 back-ends ven tráfico de una selección más amplia de clientes. En ese caso, puedes usar otros algoritmos, como WATERFALL_BY_REGION.

Consumo excesivo de batería

No se envía tráfico a backends con muchos endpoints incorrectos

Este es el comportamiento previsto cuando autoCapacityDrain está habilitado. Los back-ends con muchos endpoints que no están en buen estado se vacían y se eliminan del grupo de balanceo de carga. Si no quieres que esto ocurra, puedes inhabilitar el consumo automático de capacidad. Sin embargo, esto significa que el tráfico se puede enviar a back-ends con muchos endpoints no saludables y que las solicitudes pueden fallar.

Umbral de conmutación por error

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

Este es el comportamiento esperado cuando el umbral de conmutación por error se establece en un valor alto. Si quieres que el tráfico siga dirigiéndose a los backends principales cuando haya cambios de estado transitorios, asigna un valor inferior a este campo.

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

Este es el comportamiento previsto cuando el umbral de conmutación por error se establece en un valor bajo. Cuando los endpoints no están en buen estado, el tráfico destinado a estos endpoints se distribuye entre los endpoints restantes del mismo backend. Si quiere que el comportamiento de conmutación por error se active antes, asigne un valor más alto a este campo.

Back-ends preferidos

El tráfico se envía a back-ends más lejanos antes que a los más cercanos

Este es el comportamiento previsto si tus back-ends preferidos están más lejos que tus back-ends predeterminados. Si no quieres que esto ocurra, actualiza los ajustes de preferencias de cada backend.

No se envía tráfico a algunos back-ends cuando se usan back-ends preferidos

Este es el comportamiento previsto cuando tus back-ends preferidos aún no han alcanzado su capacidad. Los back-ends preferidos se asignan primero en función de la latencia del tiempo de ida y vuelta a estos back-ends.

Si quieres enviar tráfico a otros back-ends, puedes hacer lo siguiente:

  • Actualiza los ajustes de preferencias de los demás back-ends.
  • Define un valor de capacidad objetivo más bajo para los back-ends que prefieras. La capacidad de destino se configura mediante los campos max-rate o max-utilization, en función del modo de balanceo del servicio de backend.

Aislamiento de tráfico

Las solicitudes enviadas a tu balanceador de carga interno entre regiones fallan

Si el modo de aislamiento STRICT está habilitado y no hay backends configurados en la misma región que el balanceador de carga, es normal que el tráfico falle. Si no es el comportamiento que esperabas, asegúrate de que los back-ends se encuentren en la región a la que quieres enviar el tráfico. También puedes definir el modo de aislamiento en NEAREST para que el tráfico se pueda dirigir a la región más cercana.

El tráfico se dirige de una región remota a una más cercana

El aislamiento de solicitudes evita que se produzcan desbordamientos de tráfico basados en la capacidad. Por lo tanto, si tus back-ends ya estaban sobrecargados antes de habilitar esta función, es posible que el tráfico ya se haya enviado a una región remota. En ese caso, activar esta función podría hacer que ese tráfico se redirija a la región más cercana.

El tráfico no se ha redirigido después de activar el aislamiento del tráfico

El aislamiento de solicitudes evita que se produzcan desbordamientos de tráfico basados en la capacidad. Por lo tanto, si tus back-ends de la región más cercana no estaban sobrecargados antes de habilitar esta función, es probable que la región más cercana pueda gestionar todo el tráfico. En ese caso, es normal que no veas ningún cambio en las rutas de tráfico a corto plazo. Esto puede cambiar a medida que cambie el volumen de tráfico.

El tráfico se mueve cuando se añaden o se quitan back-ends de una región

Este es el comportamiento esperado, ya que los balanceadores de carga intentan enrutar el tráfico para optimizar la latencia de red general. Por lo tanto, cuando se implementan nuevos backends en una región más cercana, el balanceador de carga puede enviar más tráfico a esa región. Del mismo modo, cuando se eliminan backends, en función de la configuración de aislamiento de solicitudes, el balanceador de carga empieza a enviar el tráfico de desbordamiento a una región que esté más lejos.

Limitaciones

  • Cada servicio de backend solo se puede asociar a un recurso de política de balanceo de carga de servicio.