Información general sobre el balanceo de carga avanzado
La función de balanceo de carga avanzado incluye funciones que te permiten optimizar el balanceo de carga global y la distribución del tráfico para alcanzar tus objetivos de disponibilidad, rendimiento y rentabilidad. Este documento está dirigido a usuarios que tengan al menos un conocimiento intermedio de los conceptos de Cloud Service Mesh y balanceo de carga.
Para implementar el balanceo de carga avanzado, debe crear una política de balanceo de carga de servicio (recurso serviceLbPolicies), que contiene valores que influyen en la selección de un backend. A continuación, adjunta la política de balanceo de carga de servicio a un servicio de backend. La política de balanceo de carga de servicios 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 algoritmo para el balanceo de carga avanzado:
- Cascada por región (algoritmo predeterminado).
- Rociar en la región.
- Spray to world.
- Cascada por zona.
Están disponibles las siguientes opciones adicionales:
- Designa los back-ends preferidos. Cloud Service Mesh envía tráfico a esos MIGs o NEGs antes de enviarlo a otros backends.
- Configura el drenaje automático de capacidad.
- Personaliza el comportamiento de conmutación por error.
Antes de configurar cualquiera de las opciones avanzadas de balanceo de carga, te recomendamos que consultes la documentación del recurso de servicio de backend.
Cómo enruta y balancea la carga el servicio Cloud Service Mesh
En el siguiente diagrama se muestra cómo decide Cloud Service Mesh enrutar el tráfico.
En primer lugar, Cloud Service Mesh elige un servicio de backend en función de las características de la solicitud y de las reglas de enrutamiento del recurso Route o del mapa de URLs, según la API que use tu implementación.
En segundo lugar, Cloud Service Mesh elige un MIG o NEG de backend asociado al servicio de backend en función de la ubicación del cliente, la ubicación, el estado y la capacidad del MIG o NEG, así como de la información de la política de balanceo de carga del servicio asociada al servicio de backend.
Por último, Cloud Service Mesh elige una instancia o un endpoint dentro del MIG o del NEG. Esta elección se basa en la información de la política de balanceo de carga según la ubicación de los servicios backend.
Back-ends compatibles y no compatibles
Se admiten los siguientes tipos de backend para el balanceo de carga avanzado:
- Grupos de instancias sin gestionar
- Grupos de instancias gestionados
- Grupos de puntos finales de red por zonas (NEGs de GCE_VM_IP_PORT)
- Grupos de endpoints de red de conectividad híbrida (NEG NON_GCP_PRIVATE_IP_PORT)
Los siguientes tipos de backend no se admiten en el balanceo de carga avanzado:
- Grupos de instancias gestionados regionales
- Grupos de puntos finales de red de Internet (NEGs INTERNET_FQDN_PORT)
Casos prácticos
En las siguientes secciones se describe cómo funciona cada algoritmo y cuál debe elegir en función de las necesidades de su empresa.
Equilibrar el tráfico entre los backends de una región
El algoritmo de balanceo de carga predeterminado, cascada por región, distribuye el tráfico de forma uniforme entre todos los MIGs o NEGs de 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 sobrecargas de backend. El tráfico se envía entre zonas cuando es necesario para mantener la carga de los backends equilibrada en la región. Aunque la zona local del cliente tenga capacidad restante, hay tráfico entre zonas. Las solicitudes de cada cliente se pueden distribuir entre varios MIGs o NEGs zonales de la región, lo que ayuda a mantener uniforme la carga de los MIGs o NEGs cuando la carga de tráfico de los clientes no es uniforme.
Aumentar la resiliencia repartiendo 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 MIGs o NEGs zonales. Sin embargo, con ese algoritmo, las solicitudes procedentes de un solo cliente no se envían de forma coherente a todas las zonas, y las solicitudes de un solo cliente suelen dirigirse a MIGs o NEGs de una sola zona.
Usa el algoritmo de dispersión en la región cuando quieras que los clientes distribuyan sus solicitudes a todos los MIGs o NEGs de una región, lo que reduce el riesgo de sobrecargar los MIGs o NEGs de una sola zona cuando se produce un aumento rápido y localizado del volumen de tráfico.
Con el algoritmo de dispersión a la región, si tienes dos zonas, A y B, y hay un pico de tráfico en la zona B, el tráfico se dividirá entre las dos zonas. Con el algoritmo predeterminado, un pico 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 dispersión por región, el tráfico de cada cliente siempre se distribuye entre las zonas de backend de una región. Esto provoca que el tráfico entre zonas sea constantemente más alto, incluso cuando queda capacidad en la zona local, y puede provocar que el área afectada por el tráfico de Cloud Service Mesh sea mayor si dos clientes de Cloud Service Mesh envían tráfico a las mismas zonas.
Distribuir el tráfico de tu cliente entre todos los back-ends de varias regiones
Como se ha explicado en las secciones anteriores, el algoritmo de dispersión a 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 MIGs o NEGs 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 mayor, usa el algoritmo de rociado al mundo. Con este algoritmo, los clientes distribuyen sus solicitudes a todos los MIGs o NEGs del mundo en varias regiones.
Es importante tener en cuenta que, con este algoritmo, todo el tráfico se distribuye entre todos los back-ends del mundo. Una consulta defectuosa puede dañar todos los back-ends de tus implementaciones. El algoritmo también genera más tráfico entre regiones, lo que puede aumentar la latencia de las solicitudes y generar costes adicionales.
Minimizar el tráfico entre zonas
Puedes optimizar la latencia general y reducir el tráfico entre zonas usando el ajuste de cascada por zona. Cuando se configuran varios MIGs o NEGs en una zona, el tráfico de los clientes se dirige al MIG o NEG más cercano de la zona, hasta que se alcanza su capacidad, antes de enviar tráfico al siguiente MIG o NEG de la zona hasta que se utilice toda la capacidad de los MIGs o NEGs de la zona. Solo entonces se desvía el tráfico a la zona más cercana.
Con este algoritmo, puede minimizar el tráfico innecesario entre zonas. La latencia general puede mejorar ligeramente porque se prefieren los back-ends locales más cercanos. Sin embargo, esto también puede provocar un tráfico desigual entre los MIGs o los NEGs de una región.
Comparación de los algoritmos de balanceo de carga
En la siguiente tabla se ofrece una comparación detallada de los cuatro algoritmos de balanceo de carga de Cloud Service Mesh.
| Comportamiento | Cascada por región | Pulverizar en la región | Pintar en el mundo | Cascada por zona |
|---|---|---|---|---|
| Uso uniforme de la capacidad en 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 del tráfico uniforme en una región en estado estable | No | Sí | Sí | No |
| Tráfico entre zonas | Sí. Este algoritmo distribuirá el tráfico de forma 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 entre zonas. | Sí | Sí | Sí, el tráfico llenará la zona más cercana hasta su capacidad. Después, se desplazará a la siguiente zona. |
| Sensibilidad a los picos de tráfico de la zona local | Media, en función de la cantidad de tráfico que ya se haya desviado para equilibrar las zonas. | Más baja, ya que los picos de una sola zona se distribuirán entre todas las zonas de la región. | Menor, ya que los picos de una sola zona se distribuirán en todas las regiones. | Mayor, ya que es más probable que los picos de una sola zona se sirvan por completo en una sola zona hasta que Cloud Service Mesh pueda reaccionar. |
Opciones avanzadas adicionales de balanceo de carga
En las siguientes secciones se describen las opciones para modificar el balanceo de carga de Cloud Service Mesh.
Back-ends preferidos
Puedes configurar el balanceo de carga para que se designe como preferido un grupo de backends de un servicio de backend. Estos back-ends se usan por completo antes de que las solicitudes posteriores se enruten a los back-ends restantes. Cloud Service Mesh distribuye el tráfico de los clientes a los backends preferidos en primer lugar, lo que minimiza las latencias de las solicitudes de los clientes.
El tráfico que supere la capacidad configurada de los backends preferidos se dirigirá a los backends no preferidos. El algoritmo de balanceo de carga distribuye el tráfico entre los backends no preferidos.
Un caso práctico es el desbordamiento a Google Cloud, en el que se especifican recursos de computación on-premise, representados por un NEG de conectividad híbrida, que se utilizarán por completo antes de que las solicitudes se enruten a MIGs o NEGs de backend con autoescalado Google Cloud . Esta configuración puede minimizar el consumo de recursos de computación de Google Cloud y, aun así, tener la capacidad de pasar gradualmente o conmutar por error aGoogle Cloud cuando sea necesario.
Drenaje automático de la capacidad
Cuando un backend no está en buen estado, suele ser conveniente excluirlo lo antes posible de las decisiones de balanceo de carga. Si excluye el backend, las solicitudes no se enviarán al backend incorrecto. Además, el tráfico se balancea entre los back-ends en buen estado para evitar la sobrecarga de los back-ends y optimizar la latencia general.
Esta opción es similar a definir el valor cero para capacityscalar. Pide 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 endpoints individuales que superen las comprobaciones de estado. Con esta opción, los backends que no estén en buen estado se eliminan del balanceo de carga global.
Cuando los back-ends que se han drenado automáticamente vuelven a estar en buen estado, se les quita el drenaje si al menos el 35% de los endpoints o las instancias están en buen estado durante 60 segundos. Cloud Service Mesh no agota más del 50% de los endpoints de un servicio de backend, independientemente del estado de salud del backend.
Un caso práctico es que puedes usar el drenaje automático de capacidad con back-ends preferidos. Si se prefiere un MIG o un NEG de backend y muchos de sus puntos finales no están en buen estado, este ajuste protege los puntos finales restantes del MIG o del NEG desviando el tráfico del MIG o del NEG.
Personalizar el comportamiento de conmutación por error
Cloud Service Mesh suele enviar tráfico a los backends teniendo en cuenta varios factores. En un estado estable, Cloud Service Mesh envía tráfico a los back-ends que se seleccionan en función de los algoritmos descritos anteriormente. Los back-ends seleccionados se consideran óptimos en términos de latencia y utilización de la capacidad. Se denominan back-ends principales.
Cloud Service Mesh también hace un seguimiento de los back-ends que se deben usar cuando los back-ends principales no están en buen estado y no pueden recibir tráfico. Estos back-ends se denominan back-ends de conmutación por error. Suelen ser back-ends cercanos que tienen algo de capacidad restante.
Cuando un backend no está en buen estado, Cloud Service Mesh intenta evitar enviar tráfico a ese backend y, en su lugar, lo redirige 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 de umbral que
definas determinará cuándo se desvía el tráfico de los back-ends principales a los de
conmutación por error.
Cuando algunos endpoints del backend principal no están en buen estado, Cloud Service Mesh no tiene por qué cambiar el tráfico inmediatamente. En su lugar, Cloud Service Mesh puede desviar el tráfico a los endpoints en buen estado del backend principal para intentar estabilizar el tráfico.
Si demasiados endpoints del backend no están en buen estado, los endpoints restantes no podrán gestionar el tráfico adicional. En este caso, el umbral de error se usa para decidir si se activa o no la conmutación por error. Cloud Service Mesh tolera los problemas de estado hasta el umbral y, a continuación, desvía una parte del tráfico de los backends principales a los de conmutación por error.
El umbral de estado de salud de la conmutación por error es un valor porcentual. El valor que definas determinará cuándo dirige Cloud Service Mesh el tráfico a los backends de failover. Puedes asignar un valor entero entre 1 y 99. El valor predeterminado de Cloud Service Mesh 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 bajo.
Solución de problemas
Los patrones de distribución del tráfico pueden cambiar en función de cómo configure el nuevo serviceLbPolicy con el servicio de backend.
Para depurar problemas de tráfico, usa los sistemas de monitorización que ya tengas para examinar cómo fluye el tráfico a tus backends. Las métricas adicionales de Cloud Service Mesh y de la red pueden ayudarte a entender cómo se toman las decisiones de balanceo de carga. En esta sección se ofrecen sugerencias generales para solucionar problemas y reducir su impacto.
En general, Cloud Service Mesh intenta asignar tráfico para que los backends sigan funcionando por debajo de su capacidad configurada. Ten en cuenta que no está garantizado. Para obtener más información, consulta la documentación del servicio backend.
A continuación, el tráfico se asigna en función del algoritmo que uses. Por ejemplo, con el algoritmo WATERFALL_BY_ZONE, Cloud Service Mesh intenta mantener el tráfico en la zona más cercana. Si compruebas las métricas de red, verás que Cloud Service Mesh prefiere un backend con la latencia de RTT más baja al enviar solicitudes para optimizar la latencia de RTT general.
En las siguientes secciones se describen los problemas que pueden surgir con la política de balanceo de carga del servicio y los ajustes de backend preferido.
El tráfico se envía a MIGs o NEGs más lejanos antes que a los más cercanos
Este es el comportamiento esperado cuando los backends preferidos se configuran con MIGs o NEGs más lejanos. Si no quieres que se produzca este comportamiento, cambia los valores del campo preferred_backends.
No se envía tráfico a los MIGs o NEGs que tienen muchos endpoints incorrectos
Este es el comportamiento esperado cuando se agotan los MIGs o los NEGs porque se ha configurado un autoCapacityDrain. Con este ajuste, los MIGs o los NEGs con muchos endpoints no saludables se eliminarán de las decisiones de balanceo de carga y, por lo tanto, se evitarán. Si no quieres que se produzca este comportamiento, puedes inhabilitar el ajuste autoCapacityDrain. Sin embargo, ten en cuenta que esto significa que el tráfico se puede enviar a MIGs o NEGs con muchos endpoints no operativos, por lo que las solicitudes pueden fallar y devolver errores.
No se envía tráfico a algunos MIGs o NEGs cuando se prefieren otros
Este es el comportamiento previsto si los MIGs o los NEGs configurados como preferidos aún no han alcanzado su capacidad.
Si se han configurado backends preferidos y no han alcanzado su límite de capacidad, el tráfico no se enviará a otros MIGs ni NEGs. Las MIGs o las NEGs preferidas se asignarán primero en función de la latencia RTT a estos back-ends.
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 MIGs o NEGs preferidos.
Se está enviando tráfico a demasiados MIGs o NEGs distintos desde una sola fuente
Este es el comportamiento previsto si se usa la opción de rociar a la región o al mundo. Sin embargo, es posible que tengas problemas con la distribución más amplia de tu tráfico. Por ejemplo, las tasas de aciertos de caché pueden reducirse, ya que los back-ends reciben tráfico de una selección más amplia de clientes. En ese caso, puedes usar otros algoritmos, como el de cascada por región.
El tráfico se envía a un clúster remoto cuando cambia el estado de los back-ends
Este es el comportamiento previsto cuando failoverHealthThreshold tiene un valor alto. Si quieres que el tráfico se quede en los backends principales cuando haya cambios de estado transitorios, asigna un valor inferior a failoverHealthThreshold.
Los endpoints en buen estado están sobrecargados cuando algunos endpoints no están en buen estado
Si failoverHealthThreshold tiene un valor bajo, este es el comportamiento esperado. Cuando algunos puntos finales no están en buen estado, el tráfico de estos puntos finales puede distribuirse entre los puntos finales restantes del mismo MIG o NEG. Si quieres que el comportamiento de conmutación por error se active antes, asigna un valor más alto a failoverHealthThreshold.
Limitaciones y consideraciones
A continuación, se indican las limitaciones y consideraciones que debes tener en cuenta al configurar el balanceo de carga avanzado.
Cascada por zonas
Durante los eventos de mantenimiento transparentes, es posible que el tráfico se equilibre temporalmente fuera de la zona local.
Es posible que algunos MIGs o NEGs estén al máximo de su capacidad, mientras que otros MIGs o NEGs de la misma región estén infrautilizados.
Si la fuente de tráfico de su servicio está en la misma zona que sus endpoints, verá un tráfico entre zonas reducido.
Una zona puede asignarse a diferentes clústeres de hardware físico interno en 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 forma uniforme. En general, se optimizará la latencia general.
Pintar en región
Si los endpoints de un MIG o NEG dejan de funcionar, las consecuencias suelen extenderse a un conjunto más amplio de clientes. En otras palabras, puede que se vea afectado un mayor número de clientes de la malla, pero de forma menos grave.
Como los clientes envían solicitudes a todos los MIGs o NEGs de la región, en algunos casos, esto puede aumentar la cantidad de tráfico entre zonas.
El número de conexiones abiertas a los endpoints puede aumentar, lo que provoca un mayor uso de recursos.
Back-ends preferidos
Los MIGs o NEGs configurados como back-ends preferidos pueden estar lejos de los clientes y provocar una latencia media más alta para los clientes. Esto puede ocurrir aunque haya otros MIGs o NEGs que puedan servir a los clientes con una latencia menor.
Los algoritmos de balanceo de carga global (en cascada por región, dispersión por región y en cascada por zona) no se aplican a los grupos de instancias gestionados ni a los grupos de endpoints de red configurados como backends preferidos.
Consumo automático de capacidad
El número mínimo de MIGs que nunca se vacían es diferente del valor definido al configurarlas con
serviceLbPolicies.De forma predeterminada, el número mínimo de MIGs que nunca se agotan es 1.
Si se define
serviceLbPolicies, el porcentaje mínimo de MIGs o NEGs que nunca se agotan es del 50%. En ambas configuraciones, un MIG o un NEG se marcan como no aptos si menos del 25% de las instancias o los endpoints del MIG o del NEG están en buen estado.Para que un MIG o un NEG se recupere después de un drenaje, al menos el 35% de las instancias o los endpoints deben estar en buen estado. Esto es necesario para asegurarse de que un MIG o un NEG no oscile entre los estados de drenaje y sin drenaje.
Se aplican las mismas restricciones al escalador de capacidad de los backends que no usan un modo de balanceo.
Siguientes pasos
- Para obtener instrucciones de configuración, consulta el artículo Configurar el balanceo de carga avanzado.