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 del tráfico para satisfacer mejor tus objetivos de disponibilidad, rendimiento y eficiencia en cuanto a costos. Este documento está dirigido a los usuarios que tienen al menos un conocimiento intermedio de los conceptos de Cloud Service Mesh y balanceo de cargas.
Para implementar el balanceo de cargas avanzado, debes crear una política de balanceo de cargas de servicios (recurso serviceLbPolicies), que contiene valores que influyen en la selección de un backend. Luego, adjunta la política de balanceo de cargas de servicios a un servicio de backend. La política de balanceo de cargas de servicio especifica el algoritmo que se usa para determinar cómo se balancea el tráfico hacia los backends.
Puedes elegir entre las siguientes opciones de algoritmos para el balanceo de cargas avanzado:
- Cascada por región (algoritmo predeterminado)
- Difundir a la región
- Difundir al mundo
- Es una cascada por zona.
Están disponibles las siguientes opciones adicionales:
- Designa backends preferidos. Cloud Service Mesh envía tráfico a esos MIG o NEG antes de enviarlo a otros backends.
- Configura el desvío de capacidad automático.
- Personaliza el comportamiento de la 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 Cloud Service Mesh enruta y balancea las cargas del tráfico
En el siguiente diagrama, se muestra cómo Cloud Service Mesh decide enrutar el tráfico.
En primer lugar, Cloud Service Mesh elige un servicio de backend según las características de la solicitud y las reglas de enrutamiento del recurso Route o el mapa de URL, según la API que use tu implementación.
En segundo lugar, Cloud Service Mesh elige un MIG o NEG de backend asociado con el servicio de backend, según la ubicación del cliente, la ubicación, el estado y la capacidad del MIG o NEG, y la información de la política de balanceo de cargas del servicio asociada con el servicio de backend.
Por último, Cloud Service Mesh elige una instancia o un extremo dentro del MIG o el NEG. Esta elección se basa en la información de la política de balanceo de cargas por 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 de 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 INTERNET_FQDN_PORT)
Casos de uso
En las siguientes secciones, se describe cómo funciona cada algoritmo y cuál elegir para las necesidades específicas de tu empresa.
Balancea el tráfico entre los backends de una región
El algoritmo de balanceo de cargas predeterminado, 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 la cascada por región, los backends reciben tráfico en proporción a su capacidad, lo que proporciona protección contra la sobrecarga del backend. El tráfico se envía a través de los límites de zona cuando es necesario para mantener los backends con una carga uniforme dentro de la región. Incluso si la zona local para el cliente tiene capacidad restante, hay tráfico entre zonas. Las solicitudes de cada cliente se pueden distribuir entre varios MIG o NEG zonales de la región, lo que ayuda a mantener uniforme la carga en los MIG o NEG cuando la carga de tráfico de los clientes no es uniforme.
Aumenta la capacidad de recuperación distribuyendo el tráfico de un cliente entre las zonas
El algoritmo de cascada predeterminado por región intenta equilibrar el uso de la capacidad en varios MIG o NEG zonales. Sin embargo, con ese algoritmo, las solicitudes que se originan en un solo cliente no se envían de manera coherente a todas las zonas, y las solicitudes de un solo cliente suelen enrutarse a los MIG o NEG en una sola zona.
Usa el algoritmo de distribución en la región cuando quieras que los clientes propaguen sus solicitudes a todos los MIG o NEG de una región, lo que reduce el riesgo de sobrecargar los MIG o NEG en una sola zona cuando hay un aumento rápido y localizado en el volumen de tráfico.
Con el algoritmo de distribución por regiones, si tienes dos zonas, A y B, y hay un aumento repentino del tráfico en la zona B, el tráfico se dividirá entre las dos zonas. Con el algoritmo predeterminado, un aumento repentino en la zona B podría provocar una sobrecarga en la zona antes de que Cloud Service Mesh pueda responder al cambio.
Ten en cuenta que, cuando usas el algoritmo de distribución en la región, el tráfico de cada cliente siempre se distribuye entre las zonas de backend de una región. Esto genera un tráfico entre zonas constantemente más alto, incluso cuando queda capacidad en la zona local, y puede generar un área afectada más grande para el tráfico de Cloud Service Mesh si dos clientes de Cloud Service Mesh envían tráfico a las mismas zonas.
Distribuye el tráfico de tu cliente en todos los backends de varias regiones
Como se explicó en las secciones anteriores, el algoritmo de distribución a la región distribuye el tráfico de cada cliente a todas las zonas de una región. En el caso de los servicios que tienen MIG o NEG en varias regiones, Cloud Service Mesh sigue optimizando la latencia general enviando el tráfico a la región más cercana.
Si prefieres un radio de dispersión más grande, usa el algoritmo de rociado al mundo. 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 global. Una consulta defectuosa podría dañar todos los backends de tus implementaciones. El algoritmo también genera más tráfico entre regiones, lo que podría aumentar la latencia de las solicitudes y generar costos adicionales.
Minimiza el tráfico interzonal
Puedes optimizar la latencia general y reducir el tráfico entre zonas con el parámetro de 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 su capacidad, antes de enviar tráfico al siguiente MIG o NEG en la zona hasta que se use toda la capacidad del MIG o NEG en la zona. Solo entonces el tráfico se desborda hacia la zona más cercana.
Con este algoritmo, puedes minimizar el tráfico innecesario entre zonas. Es posible que la latencia general mejore ligeramente porque se prefieren los backends locales más cercanos. Sin embargo, esto también podría generar un tráfico desigual en los MIG o los NEG 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 Cloud Service Mesh.
| Comportamiento | Cascada por región | Difundir a la región | Difundir al mundo | Cascada por zona |
|---|---|---|---|---|
| Uso uniforme de la capacidad dentro de una región en estado estable | Sí | Sí | Sí | No |
| Uso uniforme de la capacidad en varias regiones en estado estable | No | No | Sí | No |
| División uniforme del tráfico 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 y, al mismo tiempo, optimizará la latencia de la red. Si es necesario, el tráfico se puede enviar a través de zonas. | Sí | Sí | Sí, el tráfico llenará la zona más cercana hasta su capacidad. Luego, se dirigirá a la siguiente zona. |
| Sensibilidad a los aumentos repentinos del tráfico en la zona local | Promedio, según la cantidad de tráfico que ya se haya transferido para equilibrar las zonas. | Más baja, ya que los aumentos repentinos de tráfico de una sola zona se distribuirán en todas las zonas de la región. | Más baja, ya que los aumentos repentinos de tráfico de una sola zona se distribuirán en todas las regiones. | Más alta; es más probable que una sola zona entregue por completo los aumentos repentinos de zona hasta que Cloud Service Mesh pueda reaccionar. |
Opciones adicionales de balanceo de cargas avanzado
En las siguientes secciones, se analizan las opciones para modificar el balanceo de cargas de Cloud Service Mesh.
Backends preferidos
Puedes configurar el balanceo de cargas de modo que un grupo de backends de un servicio de backend se designe como preferido. Estos backends se usan por completo antes de que las solicitudes posteriores se enruten a los backends restantes. Cloud Service Mesh 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 supere 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 a Google Cloud, en el que especificas que los recursos de procesamiento locales, representados por un NEG de conectividad híbrida, se deben usar por completo antes de que las solicitudes se enruten a los MIG o NEG de backend Google Cloud con ajuste de escala automático. Esta configuración puede minimizar el consumo de recursos de procesamiento de Google Cloud y, aun así, tener la capacidad de recuperación para realizar una conmutación por error o una transferencia gradual aGoogle Cloud cuando sea necesario.
Desvío de capacidad automático
Cuando un backend no está en buen estado, suele ser conveniente excluirlo lo antes posible de las decisiones de balanceo de cargas. Si excluyes el backend, se evita que se envíen solicitudes al backend en mal estado. Además, el tráfico se balancea entre los backends en buen estado para evitar la sobrecarga y optimizar la latencia general.
Esta opción es similar a establecer capacityscalar en cero. Le solicita a Cloud Service Mesh que reduzca la capacidad del backend a cero automáticamente cuando un backend tenga menos del 25% de sus instancias o extremos individuales que pasen las verificaciones de estado. Con esta opción, los backends en mal estado se quitan del balanceo de cargas global.
Cuando los backends desviados automáticamente vuelven a estar en buen estado, se desvían si al menos el 35% de los extremos o las instancias están en buen estado durante 60 segundos. Cloud Service Mesh no desvía más del 50% de los extremos en un servicio de backend, independientemente del estado del backend.
Un caso de uso es que puedes usar el desvío de capacidad automática con backends preferidos. Si se prefiere un MIG o un NEG de backend y muchos de sus extremos están en mal estado, este parámetro de configuración protege los extremos restantes del MIG o el NEG desviando el tráfico del MIG o el NEG.
Personaliza el comportamiento de conmutación por error
Por lo general, Cloud Service Mesh envía tráfico a los backends teniendo en cuenta varios factores. En estado estable, Cloud Service Mesh envía tráfico a los backends que se seleccionan en función de los algoritmos que se analizaron anteriormente. Los backends seleccionados se consideran óptimos en términos de latencia y utilización de la capacidad. Se denominan backends principales.
Cloud Service Mesh también realiza un seguimiento de los backends que se deben usar 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 capacidad restante.
Cuando un backend está en mal estado, Cloud Service Mesh intenta evitar enviarle tráfico y, en cambio, 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 de conmutación por error.
Cuando algunos extremos del backend principal están en mal estado, Cloud Service Mesh no necesariamente cambia el tráfico de inmediato. En cambio, Cloud Service Mesh podría cambiar el tráfico a los extremos en buen estado del backend principal para intentar estabilizar el tráfico.
Si demasiados extremos en el backend están en mal estado, los extremos restantes no pueden manejar el tráfico adicional. En este caso, el umbral de falla se usa para decidir si se activa o no la conmutación por error. Cloud Service Mesh tolera la falta de buen estado hasta el umbral y, luego, desvía una parte del tráfico de los backends principales a los backends de conmutación por error.
El umbral de estado de conmutación por error es un valor porcentual. El valor que estableces determina cuándo Cloud Service Mesh 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 Cloud Service Mesh es 70 con Envoy y 50 para gRPC sin proxy. Un valor más grande inicia la conmutación por error del tráfico antes que un valor más pequeño.
Soluciona problemas
Los patrones de distribución del tráfico pueden cambiar según cómo configures el nuevo serviceLbPolicy con el servicio de backend.
Para depurar problemas de tráfico, usa los sistemas de supervisión existentes para examinar cómo fluye el tráfico a tus backends. Las métricas adicionales de Cloud Service Mesh y de red pueden ayudarte a comprender cómo se toman las decisiones de balanceo de cargas. En esta sección, se ofrecen sugerencias generales para solucionar problemas y mitigar sus efectos.
En general, Cloud Service Mesh intenta asignar tráfico para mantener los backends en ejecución dentro 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, Cloud Service Mesh intenta mantener el tráfico en la zona más cercana. Si verificas las métricas de red, verás que Cloud Service Mesh prefiere un backend con la latencia de RTT más baja cuando envía solicitudes para optimizar la latencia de RTT general.
En las siguientes secciones, se describen los problemas que podrías observar con la política de balanceo de cargas de servicios y la configuración de backend preferido.
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 deseado 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.
No se envía tráfico a los MIG ni a los NEG que tienen muchos extremos en mal estado
Este es el comportamiento previsto cuando se agotan los MIG o los NEG porque se configuró un autoCapacityDrain. Con este parámetro de 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án. Si no deseas este comportamiento, puedes inhabilitar el parámetro de configuración 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, por lo que las solicitudes pueden fallar con errores.
No se envía tráfico a algunos MIG o NEG cuando se prefieren algunos MIG o NEG
Este es el comportamiento deseado si los MIG o los NEG configurados como preferidos aún no alcanzaron su capacidad.
Cuando se configuran backends preferidos y estos no alcanzan su límite de capacidad, no se enviará tráfico a otros MIG ni NEG. Los MIG o NEG preferidos se asignarán primero según la latencia del RTT a 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 esperado si se usa la opción de lanzamiento en la región o en todo 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é podrían reducirse a medida que los backends reciben tráfico de una selección más amplia de clientes. En este caso, considera usar otros algoritmos, como el de cascada por región.
Se envía tráfico a un clúster remoto cuando cambia el estado del backend
Cuando failoverHealthThreshold se establece en un valor alto, este es el comportamiento deseado. Si deseas que el tráfico permanezca en los backends principales cuando hay cambios de estado transitorios, establece failoverHealthThreshold en un valor más bajo.
Los extremos en buen estado están sobrecargados cuando algunos extremos no están en buen 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 para estos extremos en mal estado se puede distribuir entre los extremos restantes en el mismo MIG o NEG. Si deseas que el comportamiento de la conmutación por error se active antes, establece failoverHealthThreshold en un valor más alto.
Limitaciones y consideraciones
A continuación, se indican las limitaciones y consideraciones que debes tener en cuenta cuando configures el balanceo de cargas avanzado.
Cascada por zona
Durante los eventos de mantenimiento transparentes, 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 estén subutilizados.
Si la fuente de tráfico a tu servicio se encuentra en la misma zona que sus extremos, verás una reducción del 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 de la misma zona no se carguen de manera uniforme. En general, se optimizará la latencia general.
Difundir a la región
Si los extremos de un MIG o NEG dejan de funcionar, las consecuencias suelen extenderse a un conjunto más grande de clientes. En otras palabras, es posible que se vea afectado un mayor número de clientes de la malla, pero de forma menos grave.
A medida que los clientes envían solicitudes a todos los MIG o NEG de la región, en algunos casos, esto podría 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
Es posible que los MIG o los NEG configurados como backends preferidos estén lejos de los clientes y causen una latencia promedio más alta para ellos. Esto puede ocurrir incluso si hay otros MIG o NEG que podrían entregar contenido a los clientes con una latencia más baja.
Los algoritmos de balanceo de cargas globales (en cascada por región, dispersión por región y en cascada por zona) no se aplican a los MIGs ni a los NEGs configurados como backends preferidos.
Desvío de capacidad automático
La cantidad mínima de MIG que nunca se agotan es diferente del valor establecido cuando se configura con
serviceLbPolicies.De forma predeterminada, la cantidad mínima de MIG que nunca se agotan es 1.
Si se establece
serviceLbPolicies, el porcentaje mínimo de MIG o NEG que nunca se agotan es del 50%. En ambas configuraciones, un MIG o un NEG se marcan como en mal estado si menos del 25% de las instancias o los extremos del MIG o el NEG están en buen estado.Para que un MIG o un NEG se recuperen después de un vaciado, al menos el 35% de las instancias o los extremos deben estar en buen estado. Esto es necesario para garantizar que un MIG o un NEG no vacilen entre los estados desviado y no desviado.
Aquí también se aplican las mismas restricciones para el escalador de capacidad de los backends que no usan un modo de balanceo.
¿Qué sigue?
- Para obtener instrucciones de configuración, consulta Configura el balanceo de cargas avanzado.