Descripción general del balanceo de cargas avanzado
El balanceo de cargas avanzado consta de funciones que te permiten ajustar el balanceo de cargas global y la distribución de tráfico para cumplir mejor tus objetivos de disponibilidad, rendimiento y rentabilidad. Este documento está dirigido a usuarios que tengan al menos una comprensión intermedia de Traffic Director y los conceptos del balanceo de cargas.
Para implementar el balanceo de cargas avanzado, debes crear una política de balanceo de cargas de servicio (recurso serviceLbPolicies), que contenga valores que influyen en la selección de un backend. Luego, adjunta la política de balanceo de cargas del servicio a un servicio de backend. La política de balanceo de cargas del servicio especifica el algoritmo que se usa para determinar cómo se balancea el tráfico a los backends.
Puedes elegir entre las siguientes opciones de algoritmos para el balanceo de cargas avanzado:
- Cascada por región (algoritmo predeterminado).
- Aplica el aerosol en la región.
- Aplica el rociador al mundo.
- Cascada por zona.
Están disponibles las siguientes opciones adicionales:
- Designa los backends preferidos. Traffic Director envía tráfico a esos MIG o NEG antes de enviar tráfico a otros backends.
- Configurar el vaciado automático de capacidad
- Personaliza el comportamiento de conmutación por error.
Antes de configurar cualquiera de las opciones avanzadas de balanceo de cargas, te recomendamos que revises la documentación del recurso del servicio de backend.
Cómo Traffic Director enruta y balancea las cargas del tráfico
En el siguiente diagrama, se muestra cómo Traffic Director decide enrutar el tráfico.
Primero, Traffic Director elige un servicio de backend según las características de la solicitud y las reglas de enrutamiento en el recurso Route o el mapa de URL, según la API que use tu implementación.
En segundo lugar, Traffic Director elige un MIG o NEG de backend que está asociado con el servicio de backend, según la ubicación del cliente, la ubicación, el estado y la capacidad del MIG o el NEG, y la información en la política de balanceo de cargas del servicio asociada con el servicio de backend.
Por último, Traffic Director elige una instancia o un extremo dentro del MIG o NEG. Esta opción se basa en la información de la política de balanceo de cargas de localidad en los servicios de backend.
Backends compatibles y no compatibles
Los siguientes tipos de backend son compatibles con el balanceo de cargas avanzado:
- Grupos de instancias no administrados
- Grupos de instancias administrados (MIG)
- Grupos de extremos de red zonales (NEG de GCE_VM_IP_PORT)
- Grupos de extremos de red de conectividad híbrida (NEG NON_GCP_PRIVATE_IP_PORT)
Los siguientes tipos de backend no son compatibles con el balanceo de cargas avanzado:
- Grupos de instancias administrados regionales
- Grupos de extremos de red de Internet (NEG de INTERNET_FQDN_PORT)
Casos de uso
En las siguientes secciones, se describe cómo funciona cada algoritmo y cuáles puedes elegir según tus necesidades empresariales particulares.
Equilibra el tráfico entre backends en una región
El algoritmo predeterminado de balanceo de cargas, en cascada por región, distribuye el tráfico de manera uniforme entre todos los MIG o NEG en las zonas de una región. Te recomendamos que uses el algoritmo predeterminado, a menos que tengas requisitos especiales.
Con cascada por región, los backends reciben tráfico en proporción a su capacidad, lo que brinda protección contra la sobrecarga de backend. Cuando es necesario, el tráfico se envía a través de los límites de la zona para mantener los backends cargados de manera uniforme dentro de la región. Incluso si la zona local del cliente tiene capacidad restante, hay tráfico entre zonas. Las solicitudes de cada cliente se pueden distribuir entre varios MIG o NEG zonales en la región, lo que ayuda a mantener la carga en ellos uniforme cuando la carga de tráfico de los clientes no es uniforme.
Distribuir el tráfico de un cliente por las zonas para aumentar la resiliencia
La cascada predeterminada por algoritmo de región intenta balancear el uso de la capacidad en varios MIG o NEG zonales. Sin embargo, según ese algoritmo, las solicitudes que se originan en un solo cliente no se envían de manera coherente a todas las zonas y, por lo general, las solicitudes de un solo cliente se enrutan a MIG o NEG en una sola zona.
Usa el algoritmo de aplicación para regiones cuando desees que los clientes distribuyan sus solicitudes a todos los MIG o NEG de una región, lo que reduce el riesgo de sobrecargar los MIG o los NEG en una sola zona cuando hay un aumento rápido y localizado en el volumen de tráfico.
Con el algoritmo de aplicación a la región, si tienes dos zonas, A y B, y hay un aumento repentino de tráfico en la zona B, el tráfico se divide entre las dos zonas. Con el algoritmo predeterminado, un aumento repentino en la zona B podría activar una sobrecarga en la zona antes de que Traffic Director pueda responder al cambio.
Ten en cuenta que, cuando usas el algoritmo de aplicación para regiones, el tráfico de cada cliente siempre se distribuye entre las zonas de backend de una región. Esto da como resultado un tráfico entre zonas de forma constante más alto, incluso cuando hay capacidad restante en la zona local, y puede dar como resultado un área afectada más grande para el tráfico de Traffic Director, si dos clientes de Traffic Director envían tráfico a las mismas zonas.
Distribuye el tráfico de tu cliente entre todos los backends en varias regiones
Como se analizó en las secciones anteriores, el algoritmo de aplicación a la región distribuye el tráfico de cada cliente a todas las zonas de una región. Para los servicios que tienen MIG o NEG en varias regiones, Traffic Director aún optimiza la latencia general mediante el envío de tráfico a la región más cercana.
Si prefieres un radio de expansión más amplio, usa el algoritmo de Spray para Globalizar. Con este algoritmo, los clientes distribuyen sus solicitudes a todos los MIG o NEG del mundo en varias regiones.
Es importante tener en cuenta que, con este algoritmo, todo el tráfico se distribuye a todos los backends a nivel mundial. Una consulta defectuosa podría dañar todos los backends en tus implementaciones. El algoritmo también genera más tráfico entre regiones, lo que puede aumentar la latencia de las solicitudes y generar costos adicionales.
Minimiza el tráfico entre zonas
Puedes optimizar la latencia general y reducir el tráfico entre zonas con la configuración de cascada por zona. Cuando se configuran varios MIG o NEG en una zona, el tráfico del cliente se enruta al MIG o NEG más cercano en la zona, hasta alcanzar su capacidad, antes de enviar tráfico al siguiente MIG o NEG en la zona y así sucesivamente hasta que se use toda la capacidad de MIG o NEG de la zona. Solo entonces el tráfico se desborda a la siguiente zona más cercana.
Con este algoritmo, puedes minimizar el tráfico innecesario entre zonas. La latencia general podría mejorarse un poco porque se prefieren los backends locales más cercanos. Sin embargo, esto también puede crear tráfico desigual entre los MIG o NEG dentro de una región.
Comparación de los algoritmos de balanceo de cargas
En la siguiente tabla, se proporciona una comparación detallada de los cuatro algoritmos de balanceo de cargas de Traffic Director.
| Comportamiento | Cascada por región | Aerosol en la región | Aplica el rociador al mundo | Cascada por zona |
|---|---|---|---|---|
| Uso uniforme de capacidad dentro de una región en estado estable | Sí | Sí | Sí | No. |
| Uso de capacidad uniforme en varias regiones en estado estable | No. | No. | Sí | No. |
| División del tráfico uniforme dentro de una región en estado estable | No. | Sí | Sí | No. |
| Tráfico entre zonas | Sí. Este algoritmo distribuirá el tráfico de manera uniforme entre las zonas de una región mientras optimiza la latencia de red. El tráfico puede enviarse a través de zonas si es necesario. | Sí | Sí | Sí, el tráfico llenará la zona más cercana a su capacidad. Luego, irá a la siguiente zona. |
| Sensibilidad a los aumentos repentinos de tráfico en zona local | Promedio, dependiendo de cuánto tráfico ya se haya cambiado para balancear entre zonas. | Más baja, ya que los picos de una sola zona se propagarán en todas las zonas de la región. | Más baja, ya que los picos de una sola zona se propagarán en todas las regiones. | Mayor, ya que es más probable que una sola zona entregue los aumentos repentinos en una sola zona hasta que Traffic Director pueda reaccionar. |
Opciones adicionales avanzadas de balanceo de cargas
En las siguientes secciones, se analizan las opciones para modificar el balanceo de cargas de Traffic Director.
Backends preferidos
Puedes configurar el balanceo de cargas para que se designe como preferido un grupo de backends de un servicio de backend. Estos backends se usan por completo antes de que las solicitudes posteriores se enruten a los backends restantes. Traffic Director distribuye el tráfico de clientes a los backends preferidos primero, lo que minimiza las latencias de las solicitudes para tus clientes.
El tráfico que excede la capacidad configurada de los backends preferidos se enruta a los backends no preferidos. El algoritmo de balanceo de cargas distribuye el tráfico entre los backends no preferidos.
Un caso de uso es el desbordamiento en Google Cloud, en el que especificas recursos de procesamiento locales, representados por un NEG de conectividad híbrida, para que se usen por completo antes de que las solicitudes se enruten a los MIG o NEG de backend de Google Cloud con ajuste de escala automático. Esta configuración puede minimizar el consumo de procesamiento de Google Cloud y aun así tener la resiliencia para desbordar o conmutar por error gradualmente a Google Cloud cuando sea necesario.
Vaciado automático de capacidad
Cuando un backend está en mal estado, generalmente, es conveniente excluirlo lo más rápido posible de las decisiones de balanceo de cargas. La exclusión del backend evita que las solicitudes se envíen al backend en mal estado. Además, el tráfico se balancea entre backends en buen estado para evitar la sobrecarga del backend y optimizar la latencia general.
Esta opción es similar a configurar capacityscalar como cero. Le pide a Traffic Director que reduzca la capacidad de backend a cero de forma automática cuando un backend tiene menos del 25% de sus instancias o extremos individuales que pasan las verificaciones de estado. Con esta opción, los backends en mal estado se quitan del balanceo de cargas global.
Cuando los backends con desvío automático vuelven a estar en buen estado, no quedan limitados si al menos el 35% de los extremos o las instancias se encuentran en buen estado durante 60 segundos. Traffic Director no desvía más del 50% de los extremos en un servicio de backend, sin importar el estado del backend.
Un caso de uso es que puedes usar el vaciado automático de capacidad con los backends preferidos. Si se prefiere un MIG o NEG de backend y muchos de los extremos están en mal estado, esta configuración protege los extremos restantes del MIG o NEG mediante el traslado del tráfico fuera de este.
Personaliza el comportamiento de conmutación por error
Por lo general, Traffic Director envía tráfico a los backends cuando se tienen en cuenta varios factores. En estado estable, Traffic Director envía tráfico a los backends que se seleccionan según los algoritmos que se analizaron antes. Los backends seleccionados se consideran óptimos en términos de latencia y uso de la capacidad. Se llaman backends principales.
Traffic Director también realiza un seguimiento de los backends que se usan cuando los backends principales están en mal estado y no pueden recibir tráfico. Estos backends se denominan backends de conmutación por error. Por lo general, son backends cercanos que tienen cierta capacidad restante.
Cuando un backend está en mal estado, Traffic Director intenta evitar enviarle tráfico y, en su lugar, lo cambia a backends en buen estado.
El recurso serviceLbPolicy incluye un campo, failoverHealthThreshold, cuyo valor se puede personalizar para controlar el comportamiento de conmutación por error. El valor del umbral que estableces determina cuándo se cambia el tráfico de los backends principales a los backends de conmutación por error.
Cuando algunos extremos del backend principal están en mal estado, Traffic Director no necesariamente cambia el tráfico de inmediato. En su lugar, Traffic Director podría cambiar el tráfico a extremos en buen estado en el backend principal para intentar estabilizarlo.
Si demasiados extremos en el backend están en mal estado, los extremos restantes no pueden manejar tráfico adicional. En este caso, el umbral de fallas se usa para decidir si la conmutación por error se activa o no. Traffic Director tolera el mal estado hasta el umbral y, luego, traslada una parte del tráfico de los backends principales a los backends de conmutación por error.
El umbral del estado de conmutación por error es un valor porcentual. El valor que estableces determina cuándo Traffic Director dirige el tráfico a los backends de conmutación por error. Puedes establecer el valor en un número entero entre 1 y 99. El valor predeterminado para Traffic Director es 70 con Envoy y 50 para gRPC sin proxy. Un valor más alto inicia la conmutación por error del tráfico antes que un valor más pequeño.
Soluciona problemas
Los patrones de distribución de tráfico pueden cambiar en función de cómo configuras el serviceLbPolicy nuevo con el servicio de backend.
Para depurar problemas de tráfico, usa los sistemas de supervisión existentes a fin de examinar cómo fluye el tráfico a tus backends. Las métricas de red y de Traffic Director adicionales pueden ayudarte a comprender cómo se toman las decisiones de balanceo de cargas. En esta sección, se ofrecen sugerencias generales de solución de problemas y mitigación.
En general, Traffic Director intenta asignar tráfico para mantener los backends en ejecución por debajo de su capacidad configurada. Ten en cuenta que esto no está garantizado. Puedes revisar la documentación del servicio de backend para obtener más detalles.
Luego, el tráfico se asigna según el algoritmo que uses. Por ejemplo, con el algoritmo de WATERFALL_BY_ZONE, Traffic Director intenta mantener el tráfico en la zona más cercana. Si verificas las métricas de red, verás que Traffic Director prefiere un backend con la latencia de RTT más pequeña cuando envía solicitudes para optimizar la latencia general de RTT.
En las siguientes secciones, se describen los problemas que podrías experimentar con la política del balanceo de cargas del servicio y la configuración del backend preferida.
El tráfico se envía a los MIG o NEG más distantes antes que a los más cercanos
Este es el comportamiento previsto cuando los backends preferidos se configuran con MIG o NEG más distantes. Si no deseas este comportamiento, cambia los valores en el campo de backends preferidos.
El tráfico no se envía a los MIG o NEG que tienen muchos extremos en mal estado.
Este es el comportamiento previsto cuando se desvían los MIG o NEG porque se configuró un autoCapacityDrain. Con esta configuración, los MIG o NEG con muchos extremos en mal estado se quitarán de las decisiones de balanceo de cargas y, por lo tanto, se evitarían. Si este comportamiento no es el deseado, puedes inhabilitar la configuración de autoCapacityDrain. Sin embargo, ten en cuenta que esto significa que el tráfico se puede enviar a MIG o NEG con muchos extremos en mal estado y, por lo tanto, las solicitudes pueden fallar con errores.
El tráfico no se envía a algunos MIG o NEG cuando se prefieren algunos MIG o NEG
Este es el comportamiento previsto si los MIG o NEG configurados como preferidos aún no alcanzaron su capacidad.
Cuando se configuran los backends preferidos y no alcanzan su límite de capacidad, el tráfico no se enviará a otros MIG o NEG. Los MIG o NEG preferidos se asignarán primero en función de la latencia de RTT de estos backends.
Si prefieres que el tráfico se envíe a otro lugar, puedes configurar su servicio de backend sin backends preferidos o con estimaciones de capacidad más conservadoras para los MIG o NEG preferidos.
El tráfico se envía a demasiados MIG o NEG distintos desde una sola fuente
Este es el comportamiento previsto si se usa el método de aplicación por región o de aplicación para el mundo. Sin embargo, es posible que tengas problemas con una distribución más amplia de tu tráfico. Por ejemplo, las tasas de acierto de caché pueden reducirse a medida que los backends ven el tráfico de una selección más amplia de clientes. En este caso, considera usar otros algoritmos, como cascada por región.
El tráfico se envía a un clúster remoto cuando cambia el estado del backend.
Cuando failoverHealthThreshold se establece en un valor alto, este es el comportamiento previsto. Si deseas que el tráfico se mantenga en los backends principales cuando haya cambios de estado transitorios, establece failoverHealthThreshold en un valor más bajo.
Los extremos en buen estado se sobrecargan cuando algunos están en mal estado.
Cuando failoverHealthThreshold se establece en un valor bajo, este es el comportamiento deseado. Cuando algunos extremos están en mal estado, el tráfico de estos puede distribuirse entre los extremos restantes en el mismo MIG o NEG. Si deseas que el comportamiento de conmutación por error se active con anticipación, establece failoverHealthThreshold en un valor más alto.
Limitaciones y consideraciones
Las siguientes son limitaciones y consideraciones que debes tener en cuenta cuando configures el balanceo de cargas avanzado.
Cascada por zona
Durante los eventos de mantenimiento transparente, es posible que el tráfico se balancee temporalmente fuera de la zona local.
Espera casos en los que algunos MIG o NEG están al máximo de su capacidad, mientras que otros MIG o NEG de la misma región tienen poco uso.
Si la fuente de tráfico hacia tu servicio se encuentra en la misma zona que sus extremos, verás una reducción en el tráfico entre zonas.
Una zona se puede asignar a diferentes clústeres de hardware físico interno dentro de los centros de datos de Google; por ejemplo, debido a la virtualización de zonas. En este caso, es posible que las VMs que se encuentran en la misma zona no se carguen de manera uniforme. En general, se optimizará la latencia general.
Aerosol a la región
Si los extremos de un MIG o NEG fallan, las consecuencias, por lo general, se distribuyen en un conjunto más grande de clientes. En otras palabras, una mayor cantidad de clientes de la malla puede verse afectada, pero de manera menos grave.
En algunos casos, a medida que los clientes envían solicitudes a todos los MIG o NEG de la región, esto puede aumentar la cantidad de tráfico entre zonas.
La cantidad de conexiones abiertas a los extremos puede aumentar, lo que genera un mayor uso de recursos.
Backends preferidos
Los MIG o NEG configurados como backends preferidos pueden estar lejos de los clientes y causar una latencia promedio más alta para los clientes. Esto puede suceder incluso si hay otros MIG o NEG que podrían entregar a los clientes con una latencia más baja.
Los algoritmos de balanceo de cargas global (cascada por región, de aplicación a región y cascada por zona) no se aplican a los MIG o NEG configurados como backends preferidos.
Vaciado automático de capacidad
La cantidad mínima de MIG que nunca se desvían es diferente del valor establecido cuando se configura con
serviceLbPolicies.De forma predeterminada, la cantidad mínima de MIG que nunca se desvían es 1.
Si se configura
serviceLbPolicies, el porcentaje mínimo de MIG o NEG que nunca se desvían es del 50%. En ambas opciones de configuración, un MIG o un NEG se marcan en mal estado si menos del 25% de las instancias o extremos en el MIG o NEG están en buen estado.Para que un MIG o un NEG se desvíen después de un desvío, al menos el 35% de las instancias o extremos deben estar en buen estado. Esto es necesario para garantizar que un MIG o un NEG no vacien entre los estados desviados y sin agotar.
Aquí también se aplican las mismas restricciones del escalador de capacidad para backends que no usan un modo de balanceo.
¿Qué sigue?
- Para obtener instrucciones de configuración, consulta Configura el balanceo de cargas avanzado.