La afinidad zonal, configurada en el servicio de backend del balanceador de carga, te permite limitar el tráfico entre zonas, reducir la latencia y mejorar el rendimiento, todo ello sin dejar de disfrutar de las ventajas de una arquitectura multizonal.
Los balanceadores de carga de red de paso a través internos admiten tres opciones de afinidad zonal que ofrecen distintos grados de preferencia para enrutar nuevas conexiones a backends aptos que estén en la misma zona que un cliente compatible. La afinidad zonal modifica el conjunto de back-ends aptos después de que el balanceador de carga seleccione un back-end apto para una nueva conexión. Las conexiones establecidas en la tabla de seguimiento de conexiones del balanceador de carga no se ven afectadas por la afinidad zonal.
Compatibilidad
La afinidad de zona es compatible con los balanceadores de carga de red de paso a través internos que cumplen los siguientes requisitos:
- ¿Son siguientes saltos de rutas estáticas o siguientes saltos de rutas basadas en políticas?
- Tener una política de conmutación por error
La afinidad zonal es compatible con el hash simétrico solo cuando se cumplen las siguientes condiciones:
- Tanto los balanceadores de carga de red de paso a través internos en la dirección directa como en la inversa tienen habilitada la afinidad de zona.
- El tráfico de las VMs emisoras solo se dirige a las VMs receptoras de la misma zona.
La afinidad de zona no es compatible con los balanceadores de carga de red de paso a través internos que cumplen las siguientes condiciones:
- Tener habilitada la creación de subconjuntos de backend
- Son destinos de recopilador para la replicación de paquetes
- Se usan para proporcionar un servicio publicado de Private Service Connect. La afinidad zonal solo es posible para los clientes compatibles que envían paquetes al balanceador de carga, no a un punto final de Private Service Connect cuyo productor de servicios publicado utilice un balanceador de carga de red interno de transferencia.
Clientes compatibles
La afinidad zonal solo es posible para los clientes de máquinas virtuales que se encuentren en la misma región que el balanceador de carga. La afinidad zonal no es compatible con los siguientes clientes, que siempre funcionan como si estuviera inhabilitada:
Túneles de Cloud VPN de cliente y vinculaciones de VLAN de Cloud Interconnect de cliente: los túneles de Cloud VPN y las vinculaciones de VLAN de Cloud Interconnect son recursos regionales, no zonales. Los paquetes que se enrutan a través de un túnel de Cloud VPN o una vinculación de VLAN nunca admiten la afinidad de zona, independientemente de si están en la misma región que el balanceador de carga o no.
VMs de cliente en regiones que no coinciden con la región del balanceador de carga: un balanceador de carga de red con paso a través interno ubicado en una región es accesible para los clientes de todas las demás regiones si acceso global está habilitado. Cuando las VMs de cliente se encuentran en una región distinta a la del balanceador de carga, las VMs de cliente nunca comparten una zona común con ninguno de los back-ends del balanceador de carga.
Coincidencia zonal
Una coincidencia zonal describe las condiciones en las que se activa la afinidad zonal. El balanceador de carga puede modificar el conjunto original de backends aptos para proporcionar la afinidad zonal configurada. La modificación del conjunto original de backends aptos se lleva a cabo después del paso Identificar backends aptos del proceso Selección de backend y seguimiento de conexiones.
Para que se active la lógica de afinidad zonal, debe producirse la siguiente secuencia de eventos:
La afinidad zonal debe estar habilitada
Si la afinidad zonal está habilitada, debes determinar si el cliente es compatible.
Determina si el cliente es un cliente compatible.
Si el cliente es compatible, determina si se puede producir una coincidencia zonal.
Determinar si se puede producir una coincidencia zonal
Una coincidencia zonal significa que la VM cliente está en una zona que contiene al menos un backend configurado del tipo correspondiente. Los diferentes back-ends que se pueden configurar se describen en la sección Condiciones de coincidencia zonales.
Nunca se puede producir una coincidencia zonal si se cumple alguna de estas condiciones:
- La afinidad zonal está inhabilitada
- El cliente no es compatible
Aplica la lógica de afinidad zonal
Si se produce una coincidencia zonal, aplica la lógica de afinidad zonal en función de la opción de afinidad zonal que se haya configurado. Estas son las opciones que habilitan la afinidad zonal:
ZONAL_AFFINITY_STAY_WITHIN_ZONEZONAL_AFFINITY_SPILL_CROSS_ZONEcon una tasa de desbordamiento de0ZONAL_AFFINITY_SPILL_CROSS_ZONEcon una relación de cobertura adicional distinta de cero
Cuando se produce una coincidencia zonal y en función del tipo de opción de afinidad zonal que se haya configurado, el conjunto original de back-ends aptos puede refinarse, sustituirse o mantenerse sin cambios. Las nuevas conexiones del cliente se dirigen a este conjunto modificado de back-ends aptos.
Condiciones de coincidencia zonales
En la siguiente tabla se determina si el balanceador de carga puede restringir el tráfico a la zona del cliente. Si no se cumple la condición de la tercera columna, se ignora la afinidad zonal y las nuevas conexiones se dirigen a cualquier backend apto.
| Configuración de conmutación por error | Backends aptos1 | Condición para la coincidencia zonal |
|---|---|---|
| Sin política de conmutación por error | Todos los backends en buen estado o todos los backends | La VM cliente se encuentra en una zona que contiene al menos un backend configurado. El backend configurado puede ser un backend apto o no. |
| Política de conmutación por error configurada | Todos los backends principales en buen estado o todos los backends principales2 | La VM cliente se encuentra en una zona que contiene al menos un backend principal configurado. El backend principal configurado puede ser un backend apto o no. |
| Política de conmutación por error configurada | Todos los backends de conmutación por error en buen estado3 | La VM cliente se encuentra en una zona que contiene al menos un backend de failover configurado. El backend de conmutación por error configurado puede ser un backend apto o no. |
2 El balanceador de carga está en modo conmutación por recuperación.
3 El balanceador de carga está en modo de conmutación por error.
Ejemplo de coincidencia zonal
Veamos la siguiente situación para determinar si hay una coincidencia zonal:
- Política de conmutación por error configurada
- La afinidad zonal está habilitada
- El cliente está en la zona A
- Los backends principales solo están en la zona B y la zona C.
- No hay back-ends principales en la zona A
Ahora, aunque la afinidad zonal esté habilitada y haya un cliente compatible, no se producirá ninguna coincidencia zonal porque no hay ningún backend principal en la zona A, que es la zona de la VM del cliente. Por lo tanto, la afinidad zonal se ignora.
Opciones de afinidad zonal
Los balanceadores de carga de red de paso a través internos admiten las siguientes opciones de afinidad de zona:
ZONAL_AFFINITY_DISABLED(predeterminado): la afinidad zonal está inhabilitada. El balanceador de carga selecciona un backend apto para una nueva conexión sin modificar el conjunto de backends aptos.ZONAL_AFFINITY_STAY_WITHIN_ZONE: la afinidad zonal está habilitada. Cuando se produce una coincidencia zonal, el balanceador de carga mantiene el tráfico en la zona del cliente refinando el conjunto original de back-ends aptos o sustituyendo el conjunto original de back-ends aptos por un nuevo conjunto. Para obtener más información sobre esta opción, consulta Cómo funcionaZONAL_AFFINITY_STAY_WITHIN_ZONE.ZONAL_AFFINITY_SPILL_CROSS_ZONE: la afinidad zonal está habilitada. Cuando se produce una coincidencia zonal, el balanceador de carga puede refinar el conjunto de back-ends aptos o dejarlo sin cambios. Esta opción permite que el tráfico se desborde a otras zonas si no hay suficientes backends en buen estado en la zona del cliente. El desbordamiento se controla mediante la propiedad spillover ratio. Para obtener más información sobre esta opción, consulta Cómo funcionanZONAL_AFFINITY_SPILL_CROSS_ZONEy la proporción de desbordamiento.
Para saber cómo configurar la afinidad de zona en el servicio de backend de un balanceador de carga de red pasarela interno, consulta Usar la afinidad de zona.
Cómo funciona ZONAL_AFFINITY_STAY_WITHIN_ZONE
Si la afinidad de zona se define como ZONAL_AFFINITY_STAY_WITHIN_ZONE y se produce una coincidencia de zona, el balanceador de carga mantiene el tráfico en la zona del cliente haciendo una de las siguientes acciones:
Refinar el conjunto original de back-ends aptos
Si al menos un backend apto se encuentra en la zona del cliente, el balanceador de carga refina el conjunto de backends aptos de la siguiente manera:
- Descartar todos los backends aptos que no estén en la zona del cliente
- Usando solo los backends aptos que se encuentran en la zona del cliente
El conjunto refinado de back-ends aptos es un subconjunto del conjunto original de back-ends aptos.
Sustituir el conjunto original de back-ends aptos
Si no hay backends aptos en la zona del cliente, habrá otros backends configurados (que no formen parte del conjunto de backends aptos) en la zona del cliente porque se ha producido una coincidencia zonal para que se active la afinidad zonal. En esta situación, el balanceador de carga sustituye el conjunto de back-ends aptos por un conjunto nuevo que incluye back-ends no aptos de la zona del cliente, en función de si se ha configurado una política de conmutación por error y, si es así, del estado de la conmutación por error.
Este nuevo conjunto de back-ends aptos sustituidos consta de uno de los siguientes elementos:
Si no se configura ninguna política de conmutación por error, el conjunto de sustitución de back-ends aptos está formado por todos los back-ends que no están en buen estado de la zona del cliente.
Si se configura una política de conmutación por error y los backends aptos originales eran backends principales, el conjunto de sustitución de backends aptos estará formado por todos los backends principales no aptos de la zona del cliente.
Si se configura una política de conmutación por error y los backends aptos originales eran backends de conmutación por error, el conjunto de backends aptos de sustitución consta de todos los backends de conmutación por error no disponibles de la zona del cliente.
En la siguiente tabla se resumen todos los casos de refinamiento y sustitución de la opción ZONAL_AFFINITY_STAY_WITHIN_ZONE:
| Conjunto original de backends aptos | Si al menos un backend apto (del conjunto original de backends aptos) se encuentra en la zona del cliente: | Si no hay ningún backend apto (del conjunto original de backends aptos) en la zona del cliente: |
|---|---|---|
| Política de conmutación por error no configurada | ||
| Todos los backends en buen estado | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Sustituir el conjunto original de back-ends aptos. El nuevo conjunto de backends aptos está formado por todos los backends en mal estado de la zona del cliente. |
| Todos los backends | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Esta situación no puede darse.1 |
| Política de conmutación por error configurada | ||
| Todos los backends principales en buen estado | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Sustituir el conjunto original de back-ends aptos. El nuevo conjunto de backends aptos está formado por todos los backends principales en mal estado de la zona del cliente. |
| Todos los backends de conmutación por error en buen estado | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Sustituir el conjunto original de back-ends aptos. El nuevo conjunto de backends aptos está formado por todos los backends de conmutación por error en mal estado de la zona del cliente. |
| Todos los backends principales | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Esta situación no puede darse.2 |
1 La afinidad zonal requiere una coincidencia zonal. Si no se configura una política de conmutación por error, para que se produzca una coincidencia zonal, debe haber al menos un backend configurado en la misma zona que el cliente. Cuando todos los backends aptos son backends configurados, siempre hay al menos un backend apto en la misma zona que el cliente.
2 La afinidad zonal requiere una coincidencia zonal. Cuando se configura una política de conmutación por error y los backends aptos son backends principales, una coincidencia zonal requiere al menos un backend principal configurado en la misma zona que el cliente. Cuando todos los backends aptos son backends principales configurados, siempre hay al menos un backend apto en la misma zona que el cliente.
Es importante tener en cuenta lo siguiente en relación con la opción ZONAL_AFFINITY_STAY_WITHIN_ZONE:
- Esta opción de afinidad zonal nunca modifica el conjunto original de backends aptos.
- Esta opción de afinidad zonal favorece los back-ends de la zona del cliente, aunque eso suponga usar back-ends no saludables, siempre que se cumpla una condición de coincidencia zonal.
Cómo funcionan ZONAL_AFFINITY_SPILL_CROSS_ZONE y la proporción de desbordamiento
Si la afinidad zonal se define como ZONAL_AFFINITY_SPILL_CROSS_ZONE y se produce una coincidencia zonal, el conjunto de back-ends aptos para el cliente puede refinarse o no cambiar.
Si el conjunto original de back-ends aptos no cambia, es posible que las nuevas conexiones se envíen a los back-ends aptos de la zona del cliente o que se transfieran a los back-ends aptos de otras zonas. Esta distribución depende de una proporción de desbordamiento configurable que determina cuándo empieza a desbordarse el tráfico a los back-ends aptos de otras zonas.
Una proporción de desbordamiento configurable indica el valor umbral para mantener el tráfico en la zona del cliente. Si la proporción de backends aptos y en buen estado es inferior a la proporción de desbordamiento definida, todas las conexiones nuevas de los clientes de la zona se distribuyen entre los backends aptos de otras zonas. El valor de la proporción de desbordamiento puede oscilar entre 0.0 y 1.0, ambos incluidos.
Si no especificas una proporción de desbordamiento al configurar la ZONAL_AFFINITY_SPILL_CROSS_ZONEafinidad zonal,Google Cloud utiliza el valor predeterminado 0.0.
Ratio de desbordamiento cero
Si la proporción de desbordamiento configurada es 0.0, el balanceador de carga refina el conjunto de backends aptos descartando todos los backends aptos que no estén en la zona del cliente, siempre que se cumpla una de las siguientes condiciones:
- Si no se configura ninguna política de conmutación por error, los backends aptos serán todos los backends en buen estado y al menos uno de ellos estará en la zona del cliente.
- Si se configura una política de conmutación por error, todos los backends principales aptos están en buen estado y al menos uno de ellos se encuentra en la zona del cliente.
- Si se configura una política de conmutación por error, los backends aptos son todos los backends de conmutación por error en buen estado y al menos uno de ellos se encuentra en la zona del cliente.
Si no hay backends aptos en la zona del cliente:
- El balanceador de carga conserva el conjunto original de backends aptos
- Se permite que las conexiones nuevas se extiendan a back-ends aptos de otras zonas
En la siguiente tabla se resumen todos los casos de refinamiento de la opción ZONAL_AFFINITY_SPILL_CROSS_ZONE cuando la proporción de desbordamiento configurada es 0.0:
| Conjunto original de backends aptos | Si al menos un backend apto (del conjunto original de backends aptos) se encuentra en la zona del cliente: | Si no hay ningún backend apto (del conjunto original de backends aptos) en la zona del cliente: |
|---|---|---|
| Política de conmutación por error no configurada | ||
| Todos los backends en buen estado | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las nuevas conexiones se transfieren a los back-ends aptos de otras zonas. |
| Todos los backends | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las conexiones nuevas se pueden enviar a back-ends aptos de la zona del cliente o pueden derivarse a back-ends aptos de otras zonas. | Esta situación no puede darse.1 |
| Política de conmutación por error configurada | ||
| Todos los backends principales en buen estado | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las nuevas conexiones se transfieren a los back-ends aptos de otras zonas. |
| Todos los backends de conmutación por error en buen estado | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las nuevas conexiones se transfieren a los back-ends aptos de otras zonas. |
| Todos los backends principales | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las conexiones nuevas se pueden enviar a back-ends aptos de la zona del cliente o pueden derivarse a back-ends aptos de otras zonas. | Esta situación no puede darse.2 |
1 La afinidad zonal requiere una coincidencia zonal. Si no se configura una política de conmutación por error, para que se produzca una coincidencia zonal, debe haber al menos un backend configurado en la misma zona que el cliente. Cuando todos los backends aptos son backends configurados, siempre hay al menos un backend apto en la misma zona que el cliente.
2 La afinidad zonal requiere una coincidencia zonal. Cuando se configura una política de conmutación por error y los backends aptos son backends principales, una coincidencia zonal requiere al menos un backend principal configurado en la misma zona que el cliente. Cuando todos los backends aptos son backends principales configurados, siempre hay al menos un backend apto en la misma zona que el cliente.
Ratio de desbordamiento distinto de cero
Si la relación de desbordamiento configurada es superior a 0.0 pero inferior o igual a 1.0, el balanceador de carga calcula primero una de las siguientes relaciones:
Si no se configura ninguna política de conmutación por error, la proporción calculada es el número de backends aptos y en buen estado de la zona del cliente dividido entre el número de backends configurados de la zona del cliente.
$$ \frac{\text{count}(\text{Eligible and healthy backends})_{\text{Client's zone}}}{\text{count}(\text{Configured backends})_{\text{Client's zone}}} $$Si se configura una política de conmutación por error y todos los backends aptos son backends principales, la proporción calculada es el número de backends aptos y en buen estado de la zona del cliente dividido entre el número de backends principales configurados de la zona del cliente.
$$ \frac{\text{count}(\text{Eligible and healthy primary backends})_{\text{Client's zone}}}{\text{count}(\text{Configured primary backends})_{\text{Client's zone}}} $$Si se configura una política de conmutación por error y todos los backends aptos son backends de conmutación por error, la proporción calculada es el número de backends aptos y en buen estado de la zona del cliente dividido entre el número de backends de conmutación por error configurados de la zona del cliente.
$$ \frac{\text{count}(\text{Eligible and healthy failover backends})_{\text{Client's zone}}}{\text{count}(\text{Configured failover backends})_{\text{Client's zone}}} $$
A continuación, el balanceador de carga compara la proporción calculada con la proporción de desbordamiento. Si la relación calculada es mayor o igual que la relación de desbordamiento, el balanceador de carga refina el conjunto de backends aptos descartando todos los backends aptos que no estén en la zona del cliente. De lo contrario, el balanceador de carga usa los backends aptos originales.
Al calcular el ratio, recuerda lo siguiente:
Los backends aptos pueden ser todos los backends en buen estado, todos los backends, todos los backends principales en buen estado, todos los backends de conmutación por error en buen estado o todos los backends principales.
Excepto cuando los backends aptos son todos los backends o todos los backends principales, el conjunto de backends configurados, backends principales configurados o backends de conmutación por error configurados contiene más que solo los backends aptos.
Una relación de desbordamiento de
1.0indica que se cumple una de las siguientes condiciones:Si no se configura ninguna política de conmutación por error, el conjunto de backends aptos debe estar formado por todos los backends en buen estado, y el número de backends aptos de la zona del cliente debe ser igual al número de backends configurados en la zona del cliente.
Si se configura una política de conmutación por error y todos los backends aptos son backends principales, el conjunto de backends aptos debe contener todos los backends principales en buen estado, y el número de backends aptos de la zona del cliente debe ser igual al número de backends principales configurados en la zona del cliente.
Si se configura una política de conmutación por error y todos los backends aptos son backends de conmutación por error, el conjunto de backends aptos debe contener todos los backends de conmutación por error en buen estado, y el número de backends aptos de la zona del cliente debe ser igual al número de backends de conmutación por error configurados en la zona del cliente.
En la siguiente tabla se resumen todos los casos de refinamiento de la opción ZONAL_AFFINITY_SPILL_CROSS_ZONE cuando la proporción de desbordamiento configurada no es 0.0:
| Conjunto original de backends aptos | Ratio calculado >= ratio de desbordamiento | Ratio calculado < ratio de desbordamiento |
|---|---|---|
| Política de conmutación por error no configurada | ||
| Todos los backends en buen estado | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las conexiones nuevas se pueden enviar a back-ends aptos de la zona del cliente o pueden derivarse a back-ends aptos de otras zonas. |
| Todos los backends | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las conexiones nuevas se pueden enviar a back-ends aptos de la zona del cliente o pueden derivarse a back-ends aptos de otras zonas. | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las conexiones nuevas se pueden enviar a back-ends aptos de la zona del cliente o pueden derivarse a back-ends aptos de otras zonas. |
| Política de conmutación por error configurada | ||
| Todos los backends principales en buen estado | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las conexiones nuevas se pueden enviar a back-ends aptos de la zona del cliente o pueden derivarse a back-ends aptos de otras zonas. |
| Todos los backends de conmutación por error en buen estado | Refina el conjunto original de back-ends aptos descartando todos los back-ends aptos que no estén en la zona del cliente. | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las conexiones nuevas se pueden enviar a back-ends aptos de la zona del cliente o pueden derivarse a back-ends aptos de otras zonas. |
| Todos los backends principales | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las conexiones nuevas se pueden enviar a back-ends aptos de la zona del cliente o pueden derivarse a back-ends aptos de otras zonas. | Sin cambios: usa el conjunto original de back-ends aptos. En esta situación, las nuevas conexiones se pueden enviar a back-ends aptos de la zona del cliente o pueden derivarse a back-ends aptos de otras zonas. |
Ejemplos de ratio de desbordamiento
En los siguientes ejemplos se muestra cómo funciona ZONAL_AFFINITY_SPILL_CROSS_ZONE cuando no hay ninguna política de conmutación por error configurada.
Para que la afinidad zonal se aplique cuando configures una proporción de desbordamiento de
1.0, se deben cumplir las siguientes condiciones:- El conjunto de backends aptos debe estar formado por todos los backends en buen estado.
- El número de back-ends aptos y en buen estado de la zona del cliente debe ser igual al número de back-ends configurados en la zona del cliente.
Una proporción de desbordamiento de
1.0indica que el 100% de los back-ends aptos de la zona del cliente deben estar en buen estado para que todas las conexiones nuevas se distribuyan solo a los back-ends de la zona del cliente. Aunque un backend deje de estar en buen estado, el balanceador de carga distribuye algunas conexiones nuevas a los backends de otras zonas.Para que la afinidad zonal se aplique cuando configures una proporción de desbordamiento de
0.8, se deben cumplir las siguientes condiciones:- El conjunto de backends aptos debe estar formado por todos los backends en buen estado.
- El número de back-ends aptos y en buen estado de la zona del cliente dividido entre el número de back-ends configurados de la zona del cliente debe ser al menos
0.8.
Una proporción de desbordamiento de
0.8indica que al menos el 80% de los back-ends aptos de la zona del cliente deben estar en buen estado para que todas las conexiones nuevas se distribuyan solo a los back-ends de la zona del cliente. Si menos del 80% de los backends de la zona del cliente están activos, el balanceador de carga distribuye algunas conexiones nuevas a los backends de otras zonas.Para que la afinidad zonal se aplique cuando configures una proporción de desbordamiento de
0.0, se deben cumplir las siguientes condiciones:- El conjunto de backends aptos debe estar formado por todos los backends en buen estado.
- Debe haber al menos un backend apto y en buen estado en la zona del cliente.
Una proporción de desbordamiento de
0.0significa que, mientras haya al menos un backend en buen estado en la zona del cliente, todas las conexiones nuevas se distribuirán a los backends de la zona del cliente. Si la proporción de desbordamiento es0.0y no hay ningún backend en buen estado en la zona del cliente, el balanceador de carga distribuye todas las conexiones nuevas a los backends en buen estado de otras zonas.
En el siguiente diagrama se muestra una proporción de desbordamiento de 0.8:
Las zonas 1 y 2 contienen cinco backends configurados cada una.
El conjunto original de backends aptos consta de ocho de los diez backends configurados:
Los cinco backends configurados en la zona 1 están en buen estado.
Tres backends configurados en la zona 2 están en buen estado.
En el caso de un cliente compatible que se encuentre en la zona 1:
Se produce una coincidencia zonal porque hay al menos un backend configurado en la zona 1.
La proporción de backends aptos en buen estado de la zona 1 con respecto a todos los backends configurados de la zona 1 es
5/5=1.0.En el caso del cliente compatible de la zona 1, como la proporción calculada de
1.0es mayor que la proporción de desbordamiento de0.8, el balanceador de carga refina el conjunto de backends aptos descartando todos los backends aptos que no estén en la zona 1. Por lo tanto, las nuevas conexiones del cliente compatible de la zona 1 se distribuyen exclusivamente entre los cinco back-ends aptos y en buen estado de la zona 1.
En el caso de un cliente compatible que se encuentre en la zona 2:
Se produce una coincidencia zonal porque hay al menos un backend configurado en la zona 2.
La proporción de backends aptos en buen estado de la zona 2 con respecto a todos los backends configurados de la zona 2 es
3/5=0.6.En el caso del cliente compatible de la zona 2, como la proporción calculada de
0.6no es mayor o igual que la proporción de desbordamiento de0.8, el balanceador de carga no hace ningún cambio en el conjunto de back-ends aptos. Por lo tanto, las nuevas conexiones del cliente compatible de la zona 2 se distribuyen entre el conjunto original de ocho backends aptos en buen estado (cinco en la zona 1 y tres en la zona 2).
Siguientes pasos
- Para configurar Cloud Monitoring en balanceadores de carga de red de paso a través internos, consulta Registro y monitorización de balanceadores de carga de red de paso a través internos.
- Para solucionar problemas con tu balanceador de carga de red de paso a través interno, consulta el artículo Solucionar problemas de balanceadores de carga de red de paso a través internos.