Descripción general del balanceo de cargas avanzado
El balanceo de cargas avanzado consta de funciones que te permiten ajustar las cargas globales y la distribución del tráfico para satisfacer mejor tu disponibilidad, rendimiento y los objetivos de rentabilidad. Este documento está dirigido a usuarios que tengan, al menos un conocimiento intermedio de los conceptos de Cloud Service Mesh y el balanceo de cargas.
Para implementar el balanceo de cargas avanzado, creas una política de balanceo de cargas de servicio (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 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 algoritmos para el balanceo de cargas avanzado:
- Cascada por región (algoritmo predeterminado)
- Difundir a la región
- Difundir al mundo
- 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 enviar tráfico a otros backends.
- Configura el desvío de capacidad automático.
- Personaliza el comportamiento de conmutación por error.
Antes de que configures cualquiera de las opciones avanzadas de balanceo de cargas, te recomendamos que revises la documentación del recurso de servicio de backend.
Cómo enruta y balancea las cargas del tráfico Cloud Service Mesh
En el siguiente diagrama, se muestra cómo Cloud Service Mesh decide enrutar el tráfico.
Primero, Cloud Service Mesh elige un servicio de backend según las características de la solicitud y según 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, Cloud Service Mesh elige un MIG o NEG de backend que está asociado el servicio de backend, según la ubicación, la ubicación, el estado y la capacidad del MIG o NEG y la información del balanceo de cargas del servicio política asociada con el servicio de backend.
Por último, Cloud Service Mesh elige una instancia o un extremo dentro del MIG o NEG. Esta elección se basa en la información de la política de balanceo de cargas de la 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 por zonas (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 de INTERNET_FQDN_PORT)
Casos de uso
En las siguientes secciones, se describe cómo funciona cada algoritmo y cuál elegir para tus necesidades comerciales específicas.
Equilibra 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 forma uniforme entre todos los MIG o NEG en las zonas de una región. Recomendaciones el algoritmo predeterminado, a menos que tenga requisitos especiales.
Con cascada por región, los backends reciben tráfico en proporción al tráfico que proporciona protección contra sobrecargas de backend. El tráfico se envía a través de los límites de zona cuando es necesario 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 en varios MIG o NEG zonales de la región, lo que ayuda a mantener la carga en los MIG o NEG uniforme cuando la carga de tráfico de los clientes no es uniforme.
Aumenta la resiliencia distribuyendo el tráfico de un cliente entre las zonas
El algoritmo predeterminado de cascada por región intenta balancear el uso de la capacidad. en varios MIG o NEG zonales. Sin embargo, según ese algoritmo, las solicitudes que provienen de un solo cliente no se envían de forma coherente a todas las zonas, y las solicitudes de un solo cliente suelen enrutarse a MIG o NEG en una sola zona.
Use el algoritmo de rociar a la región cuando desee que los clientes distribuyan sus solicitudes a todos los MIG o NEG de una región, lo que reduce el riesgo de sobrecargar MIG o NEG en una sola zona cuando hay una conexión rápida y de aumento en el volumen de tráfico.
Con el algoritmo de distribución de tráfico a la región, 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 activar una sobrecarga en la zona antes Cloud Service Mesh es capaz de responder al cambio.
Ten en cuenta que, cuando usas el algoritmo de distribución en 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 sistemáticamente más alto, incluso cuando hay capacidad restante en la zona local y puede resultar en 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 entre todos los backends en varias regiones
Como se explicó en las secciones anteriores, el algoritmo de distribución en 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, Cloud Service Mesh aún optimiza la latencia general con el envío de tráfico a la región más cercana.
Si prefieres un radio de dispersión más amplio, usa el algoritmo de espray para el mundo. Con con este algoritmo, los clientes extienden sus solicitudes a todos los MIG o NEG del mundo en múltiples regiones.
Es importante tener en cuenta que, con este algoritmo, todo el tráfico se distribuye a todos los backend a nivel global. Una consulta defectuosa puede dañar todos los backends de tu de Google Cloud. El algoritmo también genera más tráfico entre regiones, lo que podría aumentar la latencia de la solicitud y generar costos adicionales.
Minimiza el tráfico interzonal
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 su capacidad, antes de enviar el 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 en ese momento se derrama el tráfico a la siguiente zona más cercana.
Con este algoritmo, puedes minimizar el tráfico innecesario entre zonas. General la latencia podría mejorarse un poco, ya que los backends locales más cercanos de tu preferencia. Sin embargo, esto también podría crear un tráfico desigual entre los MIG o los 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 servicios de Cloud Service Mesh algoritmos de balanceo de cargas.
| Comportamiento | Cascada por región | Difundir a la región | Difundir al mundo | Cascada por zona |
|---|---|---|---|---|
| Uso de capacidad uniforme 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 de 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 en un región y, al mismo tiempo, optimiza la latencia de red. El tráfico puede enviarse a través de en ciertas zonas si es necesario. | Sí | Sí | Sí, el tráfico llenará la zona más cercana hasta su capacidad. Luego, irá a la siguiente zona. |
| Sensibilidad a los aumentos repentinos de tráfico en la zona local | Promedio: Depende de la cantidad de tráfico que ya se haya redireccionado 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. | Mayor; ya que es más probable que los picos de una sola zona se entreguen por completo por una sola zona hasta que Cloud Service Mesh pueda reaccionar. |
Opciones adicionales avanzadas de balanceo de cargas
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 para que un grupo de backends de un servicio de backend se designe como preferido. Estos backends se usan completamente antes que las solicitudes posteriores se enrutan a los backends restantes. Malla de servicios en la nube distribuye el tráfico de clientes a los backends preferidos primero, lo que minimiza las solicitudes latencias para tus clientes.
Cualquier tráfico que exceda la capacidad configurada de los backends preferidos enrutan a 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 de Google Cloud, en el que especificas el procesamiento local recursos, representados por un NEG de conectividad híbrida, que se usarán por completo antes se enrutan a MIG o NEG de backend de Google Cloud con ajuste de escala automático. Esta puede minimizar el consumo de procesamiento en Google Cloud tienen la resiliencia para derramar o hacer una conmutación por error gradualmente a Google Cloud cuando sea necesario.
Vaciado automático de la capacidad
Cuando un backend está en mal estado, suele ser conveniente excluirlo lo más rápido posibles a partir de decisiones de balanceo de cargas. Si excluyes el backend, se evita que las solicitudes se envíen al backend en mal estado. Además, el tráfico se equilibra entre los backends en buen estado para evitar la sobrecarga del backend y optimizar la latencia general.
Esta opción es similar a establecer capacityscalar en cero. Le solicita a Cloud Service Mesh que reduzca automáticamente la capacidad del backend a cero cuando un backend tenga menos del 25% de sus instancias o extremos individuales que superen las verificaciones de estado. Con esta opción, se quitan los backends en mal estado 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 instancias están en buen estado durante 60 segundos. Malla de servicios en la nube no agota 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 NEG de backend y muchos de los extremos en él en mal estado, este parámetro de configuración protege los extremos restantes en el MIG o NEG al alejando el tráfico del MIG o NEG.
Personaliza el comportamiento de conmutación por error
Por lo general, Cloud Service Mesh envía tráfico a los backends tomando varios factores tener en cuenta. En un estado estable, Cloud Service Mesh envía tráfico a los backends que se eligen en función de los algoritmos analizados anteriormente. Los seleccionados backends se consideran óptimos en términos de latencia y uso de capacidad. Se denominan backends principales.
Cloud Service Mesh 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 llaman backends de conmutación por error. Por lo general, son backends cercanos que tienen algo de capacidad disponible.
Cuando un backend está en mal estado, Cloud Service Mesh intenta evitar que se envíe tráfico y, en su lugar, traslada el tráfico a backends en buen estado.
El recurso serviceLbPolicy incluye un campo, failoverHealthThreshold, cuyo
se puede personalizar para controlar el comportamiento de conmutación por error. El valor del umbral que establezcas 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, Cloud Service Mesh cambiar el tráfico de manera inmediata. En cambio, Cloud Service Mesh podría cambiar el tráfico a extremos en buen estado en el backend principal para intentar estabilizar el tráfico.
Si demasiados extremos del backend están en mal estado, los extremos restantes no pueden manejar el tráfico adicional. En este caso, el umbral de fallas es que se usa para decidir si la conmutación por error debe activarse o no. Cloud Service Mesh tolera el estado no saludable hasta el umbral y, luego, cambia 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 establezcas determina cuándo Cloud Service Mesh dirige el tráfico a los backends de conmutación por error. Tú Puedes establecer el valor en un número entero entre 1 y 99. El valor predeterminado de Cloud Service Mesh es 70 con Envoy y 50 para gRPC sin proxy. Un valor mayor la conmutación por error del tráfico se inicia antes que un valor menor.
Soluciona problemas
Los patrones de distribución de tráfico pueden cambiar en función de cómo configures el nuevo
serviceLbPolicy por 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. Métricas de red y de la malla de servicios de Cloud adicionales puede 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, Cloud Service Mesh intenta asignar tráfico para mantener los backends en ejecución según su capacidad configurada. Ten en cuenta que no hay garantía de que se pueda satisfacer la solicitud. Tú puedes revisar la documentación del servicio de backend para obtener más información.
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 a la zona más cercana. Si revisas las métricas de red, verás que Cloud Service Mesh 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 ver con la política de balanceo de cargas del servicio y la configuración de backend preferida.
El tráfico se envía a 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 más MIG o NEG distantes. Si no deseas este comportamiento, cambia los valores en el backends preferidos.
El tráfico no se envía a los MIG o NEG que tienen muchos extremos inactivos
Este es el comportamiento deseado 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
los extremos en mal estado se quitarán de las decisiones
de balanceo de cargas y, por lo tanto, se
evitar. Si este comportamiento no es el deseado, puedes inhabilitar el autoCapacityDrain
del lugar. 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 deseado si los MIG o NEG configurados como preferidos aún no alcanzaron la capacidad.
Cuando se configuran los backends preferidos y estos no han alcanzado su capacidad límite, el tráfico no se enviará a otros MIG o NEG. Los MIG o NEG preferidos se asignarán primero según la latencia de RTT a estos backends.
Si prefieres que el tráfico se envíe a otro lugar, puedes configurar sus servicio de backend sin backends preferidos o con una capacidad más conservadora estimaciones para los MIG o NEG preferidos.
El tráfico se envía a demasiados MIG o NEG distintos de una sola fuente
Este es el comportamiento deseado si se usa la propagación a región o a todo el mundo. Sin embargo, es posible que tengas problemas con la distribución más amplia de tus tráfico. Por ejemplo, las tasas de acierto de caché pueden reducirse a medida que los backends ven 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 deseado. Si deseas que el tráfico permanezca 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 extremos no están en buen estado
Cuando failoverHealthThreshold se establece en un valor bajo, este es el
de tu modelo. Cuando algunos extremos están en mal estado, el tráfico de estos extremos en mal estado
podría distribuirse entre los extremos restantes del mismo MIG o NEG. Si
si deseas que el comportamiento de conmutación por error se active antes de tiempo, configura failoverHealthThreshold
a un valor más alto.
Limitaciones y consideraciones
Aquí encontrarás limitaciones y consideraciones que debes tener en cuenta. cuando configuras el balanceo de cargas avanzado.
Cascada por zona
Durante los eventos de mantenimiento transparentes, es posible balanceado temporalmente fuera de la zona local.
Es posible que se produzcan 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 infrautilizados.
Si el origen de tráfico del servicio se encuentra en la misma zona que su verás una reducción en el tráfico entre zonas.
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.
Spray para aplicar a la región
Si los extremos en un MIG o NEG fallan, las consecuencias suelen ser distribuida entre un conjunto más grande de clientes; en otras palabras, un número mayor de los clientes en malla podrían verse afectados, 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 esto podría aumentar la cantidad de tráfico entre zonas.
La cantidad de conexiones abiertas a los endpoints puede aumentar, lo que el aumento en el uso de los recursos.
Backends preferidos
Es posible que los MIG o NEG configurados como backends preferidos estén lejos de los clientes y que causen una latencia promedio más alta para los clientes. Esto puede ocurrir incluso si hay otros MIG o NEG que podrían entregar los clientes con una latencia más baja.
Algoritmos de balanceo de cargas global (cascada por región, rociador a región, cascada por zona) no se apliquen a los MIG o NEG configurados como preferidos backends.
Desvío de capacidad automático
La cantidad mínima de MIG que nunca se desvían es diferente del de salida que se establece cuando se configura con
serviceLbPolicies.De forma predeterminada, la cantidad mínima de MIG que nunca se agotan es 1.
Si se configura
serviceLbPolicies, el porcentaje mínimo de MIG o NEG que nunca se es drenado es del 50%. En ambas configuraciones, un MIG o NEG se marca como no operativo si menos del 25% de las instancias o los extremos del MIG o NEG están en buen estado.Para que un MIG o NEG se desagote después de un drenaje, al menos el 35% de las instancias o los extremos deben estar en buen estado. Esto es necesario para garantizar que un MIG o el NEG no vacila entre los estados de drenaje y sin drenar.
Las mismas restricciones para el escalador de capacidad de los backends que no usan un el modo de balanceo también se aplican aquí.
¿Qué sigue?
- Para obtener instrucciones de configuración, consulta Configura el balanceo de cargas avanzado.