Afinidad zonal para balanceadores de carga de red de paso a través internos

De forma predeterminada, un balanceador de carga de red de paso a través interno distribuye las conexiones nuevas a los backends aptos sin tener en cuenta la zona en la que se encuentran el cliente y el backend.

Con la afinidad zonal, el balanceador de carga puede distribuir las conexiones nuevas de una VM de cliente determinada a un conjunto modificado de back-ends aptos que se encuentren en la zona de la VM de cliente. Limitar el tráfico entre zonas manteniendo el tráfico local en la zona siempre que sea posible reduce el coste de transferencia de datos entre zonas, reduce la latencia y mejora el rendimiento, al tiempo que se mantienen las ventajas de la arquitectura multizonal.

La afinidad zonal se configura en el servicio de backend de un balanceador de carga de red de paso a través interno. El balanceador de carga admite diferentes opciones de afinidad zonal que ofrecen distintos grados de preferencia para enrutar nuevas conexiones a back-ends aptos que se encuentren en la misma zona que un cliente compatible. Ten en cuenta que las conexiones establecidas en la tabla de seguimiento de conexiones del balanceador de carga no se ven afectadas por la afinidad zonal.

Compatibilidad con funciones

Antes de habilitar la afinidad de zona, debes saber qué funciones del balanceador de carga de red de paso a través interno se admiten con la afinidad de zona.

Funciones compatibles

Funciones no compatibles

La afinidad zonal no es compatible con los balanceadores de carga de red de paso a través internos que se han configurado con lo siguiente:

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:

  • Clientes conectados a través de túneles de Cloud VPN y vinculaciones de VLAN de Cloud Interconnect: 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: los clientes de todas las demás regiones pueden acceder a un balanceador de carga de red con paso a través interno ubicado en una región 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.

Compatibilidad con balanceadores de carga de red de paso a través internos del siguiente salto

Aunque se puede habilitar la afinidad de zona en los balanceadores de carga de red de pases internos que se usan como siguientes saltos para las rutas estáticas, no se recomienda en arquitecturas con estado en las que se configuran aplicaciones virtuales como cortafuegos en paralelo y las entidades de balanceo de carga se colocan a ambos lados de los cortafuegos.

Para obtener más información, consulta la sección de requisitos de la guía Balanceador de carga de red interno de transferencia directa como próximo salto.

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 originales.

  • 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, aunque eso implique usar backends en mal estado. Para obtener más información sobre esta opción, consulta Cómo funciona ZONAL_AFFINITY_STAY_WITHIN_ZONE.

  • ZONAL_AFFINITY_SPILL_CROSS_ZONE: la afinidad zonal está habilitada. Cuando se produce una coincidencia zonal, el balanceador de carga permite que las nuevas conexiones se distribuyan en la zona del cliente o que se extiendan a otras zonas. El desbordamiento se controla mediante la proporción de desbordamiento. Para obtener más información sobre esta opción, consulta Cómo funcionan el espacio disponible y la proporción de desbordamiento.ZONAL_AFFINITY_SPILL_CROSS_ZONE

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 la afinidad zonal

En las siguientes secciones se explica en detalle cómo funciona la afinidad de zona. No es necesario que conozca estos detalles para configurar la afinidad zonal, pero pueden ayudarle a entender los casos límite y el comportamiento preciso de la distribución del tráfico.

En concreto, estas secciones abarcan lo siguiente:

Diferentes tipos de back-ends

La afinidad zonal crea un conjunto de backends aptos modificados a partir de los backends aptos originales y los backends configurados del balanceador de carga. Para explicar cómo realiza la afinidad zonal esta modificación, definimos con precisión cinco conjuntos de backend diferentes. En este documento se hace referencia a los siguientes términos en las secciones posteriores, donde se explica cómo funciona la afinidad zonal.

  • Conjuntos de entrada

    • Backends configurados: conjunto de todos los backends que forman parte del servicio de backend del balanceador de carga. Esto incluye todos los backends principales y, si la función de conmutación por error está habilitada, todos los backends principales y de conmutación por error.

    • Back-ends originales aptos: un subconjunto de back-ends configurados que pueden recibir nuevas conexiones. El conjunto de backends originales aptos se genera en el paso Identificar backends aptos del proceso de selección y seguimiento de la conexión de backend.

  • Conjuntos intermediarios

    • Back-ends de prueba de coincidencia zonal: un subconjunto de back-ends configurados que se usa para probar una coincidencia zonal. Tanto los backends configurados como los backends aptos originales determinan qué VMs son backends de prueba de coincidencia de zona.

    • Back-ends de concordancia zonal: un subconjunto de los back-ends de prueba de concordancia zonal que están en la misma zona que un cliente compatible.

  • Conjunto de salida

    • Backends aptos modificados: en función del tipo de afinidad zonal configurado y de la proporción de desbordamiento, los backends aptos modificados pueden ser los mismos que los originales, un subconjunto de los originales o diferentes de los originales. Este conjunto se usa para proporcionar la afinidad zonal configurada.

Coincidencia zonal

Una coincidencia zonal describe las condiciones en las que se activa la afinidad zonal. El balanceador de carga podría modificar el conjunto de backends originales aptos para proporcionar la afinidad zonal configurada. La modificación de los backends aptos originales se produce después de que el balanceador de carga seleccione un backend apto para una nueva conexión.

Para que se active la lógica de afinidad zonal, debe producirse la siguiente secuencia de eventos:

  1. La afinidad zonal debe estar habilitada.

    Si la afinidad zonal está habilitada, continúa con el siguiente paso.

  2. Determina si el cliente es un cliente compatible.

    Si el cliente es compatible, ve al siguiente paso.

  3. Determina si se puede producir una coincidencia zonal.

    Una coincidencia zonal significa que la VM cliente se encuentra en una zona que contiene al menos un backend de prueba de coincidencia zonal. Los backends de prueba de coincidencia zonal son un conjunto de backends configurados basados en los backends aptos originales. Para obtener más información, consulta 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
  4. Aplica la lógica de afinidad zonal.

Condiciones de coincidencia zonales

Para que se produzca una coincidencia zonal, al menos una instancia o un endpoint de los backends de prueba de coincidencia zonal debe estar en la misma zona que un cliente compatible. Tanto los backends configurados como los backends aptos originales son entradas que se usan para determinar los backends de prueba de coincidencia zonal.

Backends originales aptos Backends de prueba de coincidencia zonales
Todos los backends principales en buen estado

Todos los backends principales configurados

Puede que todos los backends principales configurados estén en buen estado o que haya una combinación de backends en buen estado y en mal estado.

Todos los backends de conmutación por error en buen estado

Todos los backends de conmutación por error configurados

Es posible que todos los backends de conmutación por error configurados estén en buen estado o que haya una combinación de backends en buen estado y en mal estado.

Todos los backends principales en mal estado

Todos los backends principales configurados

Todos los backends principales configurados están en mal estado por definición cuando todos los backends principales aptos originales están en mal estado.

Ejemplo de coincidencia zonal

Consulta la siguiente configuración de un balanceador de carga de red de paso a través interno para saber si se produce una coincidencia zonal.

  • Back-ends principales: zonas A y B
  • Back-ends de conmutación por error: zonas C y D
  • Ubicación de la VM cliente: zona A
  • Afinidad zonal habilitada
  • Política de conmutación por error predeterminada presente

Situación 1:

  • Backends aptos originales: todos los backends principales en buen estado (zonas A y B)
  • Back-ends de prueba de concordancia zonal: todos los back-ends principales configurados (zonas A y B)
  • ¿Hay una coincidencia zonal?: Sí. En este caso, la VM cliente está en la misma zona que los backends de prueba de match zonal, por lo que hay un match zonal.

Situación 2:

  • Backends originales aptos: todos los backends de conmutación por error en buen estado (zonas C y D)
  • Backends de prueba de coincidencia zonal: todos los backends de conmutación por error configurados (zonas C y D)
  • ¿Hay una coincidencia zonal?: No. Para que se produzca una coincidencia zonal, la VM del cliente debe estar en una zona que contenga al menos un backend del conjunto de backends de prueba de coincidencia zonal. En este caso, el cliente está en la zona A y los backends de prueba de concordancia zonal están en las zonas C y D.

Cuando se produce una coincidencia zonal, aplica la lógica de afinidad zonal como se indica en las siguientes secciones.

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_ZONE
  • ZONAL_AFFINITY_SPILL_CROSS_ZONE con una relación de desbordamiento de 0
  • ZONAL_AFFINITY_SPILL_CROSS_ZONE con una relación de desbordamiento distinta de cero

Después de que se produzca una coincidencia zonal y en función del tipo de opción de afinidad zonal que se haya configurado, los backends aptos modificados pueden ser los mismos que los backends aptos originales, un subconjunto de los backends aptos originales o diferentes de los backends aptos originales.

Cómo funciona ZONAL_AFFINITY_STAY_WITHIN_ZONE

Si la afinidad zonal se define como ZONAL_AFFINITY_STAY_WITHIN_ZONE y se produce una coincidencia zonal, el balanceador de carga distribuye las nuevas conexiones a los backends aptos modificados. Los back-ends aptos modificados pueden ser los mismos que los back-ends aptos originales, un subconjunto de los back-ends aptos originales o diferentes de los back-ends aptos originales.

Para crear backends aptos modificados, el balanceador de carga sigue este proceso:

  1. Empieza con los backends de prueba de coincidencia zonal identificados por la condición de coincidencia zonal.

  2. Elimina todos los back-ends que no estén en la misma zona que el cliente. De esta forma, obtenemos un conjunto de backends coincidentes zonales. Este conjunto nunca está vacío porque se ha producido una coincidencia zonal.

  3. Calcula la intersección de los backends coincidentes zonales con los backends aptos originales. Esta intersección puede estar vacía o no.

    • Si la intersección no está vacía, los back-ends aptos modificados son el conjunto de intersección. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos.

    • Si la intersección está vacía, los backends aptos modificados son los backends coincidentes zonales, que siempre son diferentes de los backends aptos originales. En esta situación, todos los backends aptos modificados están en mal estado.

En la siguiente tabla se resume el proceso para crear el conjunto de backends aptos modificados cuando la opción de afinidad zonal es ZONAL_AFFINITY_STAY_WITHIN_ZONE. Esta opción de afinidad zonal favorece los back-ends de la zona del cliente, aunque eso suponga usar back-ends no saludables.

Backends originales aptos (A) Back-ends de prueba de concordancia zonal (B) Backends coincidentes zonales (C) Intersección (A∩C) Backends aptos modificados
Todos los backends principales en buen estado

Todos los backends principales configurados

Es posible que todos los backends de prueba de coincidencia zonal estén en buen estado o que haya una combinación de backends en buen estado y en mal estado.

Todos los back-ends principales de la zona del cliente

Es posible que todos los backends coincidentes zonales estén en buen estado, en mal estado o en una combinación de ambos.

Todos los backends principales en buen estado de la zona del cliente

Intersección no vacía: los backends aptos modificados son todos los backends principales en buen estado de la zona del cliente.

Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.


La intersección está vacía: los back-ends aptos modificados son todos los back-ends principales no operativos de la zona del cliente.

Los backends aptos modificados son los mismos que los backends coincidentes zonales, que son todos los backends principales de la zona del cliente. Sin embargo, todos estos backends no están en buen estado porque la intersección con los backends aptos originales está vacía.

Todos los backends de conmutación por error en buen estado

Todos los backends de conmutación por error configurados

Es posible que todos los backends de prueba de coincidencia zonal estén en buen estado o que haya una combinación de backends en buen estado y en mal estado.

Todos los back-ends de conmutación por error de la zona del cliente

Es posible que todos los backends coincidentes zonales estén en buen estado, en mal estado o en una combinación de ambos.

Todos los backends de conmutación por error en buen estado de la zona del cliente

La intersección no está vacía: los backends aptos modificados son todos los backends de conmutación por error en buen estado de la zona del cliente.

Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.


La intersección está vacía: los backends aptos modificados son todos los backends de conmutación por error en mal estado de la zona del cliente.

Los backends aptos modificados son los mismos que los backends coincidentes zonales, que son todos los backends de failover de la zona del cliente. Sin embargo, todos estos backends están en mal estado porque la intersección con los backends aptos originales está vacía.

Todos los backends principales en mal estado

Todos los backends principales configurados

Por definición, todos los backends de prueba de coincidencia zonal están en mal estado cuando todos los backends principales aptos originales están en mal estado.

Todos los backends principales en mal estado de la zona del cliente

Todos los backends principales en mal estado de la zona del cliente

La intersección nunca está vacía: los backends aptos modificados son todos los backends principales no aptos de la zona del cliente.

Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.

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 balanceador de carga distribuye las nuevas conexiones a los backends aptos modificados. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos.

Si los back-ends aptos modificados son los mismos que los back-ends aptos originales, las nuevas conexiones se pueden enviar a los back-ends aptos de la zona del cliente o a los back-ends aptos de cualquier zona (desbordamiento). Esta distribución depende de una proporción de desbordamiento configurable.

Una proporción de desbordamiento configurable indica el valor umbral para mantener el tráfico en la zona del cliente. El valor de la relación de cobertura adicional puede oscilar entre 0.0 y 1.0, ambos incluidos. Si no especifica una proporción de desbordamiento al configurar ZONAL_AFFINITY_SPILL_CROSS_ZONE, Google Cloud usa el valor predeterminado 0.0.

Ratio de desbordamiento cero

Si la proporción de desbordamiento configurada es 0.0, el balanceador de carga usa el siguiente proceso para crear los backends aptos modificados:

  1. Empieza con los backends de prueba de match zonal identificados por la condición de match zonal.

  2. Elimina todos los back-ends que no estén en la misma zona que el cliente. De esta forma, obtenemos un conjunto de backends coincidentes zonales. Este conjunto nunca está vacío porque se ha producido una coincidencia zonal.

  3. Calcula la intersección de los backends coincidentes zonales con los backends aptos originales. Esta intersección puede estar vacía o no.

    • Si esta intersección no está vacía, los back-ends aptos modificados son el conjunto de intersección. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de los backends aptos originales.

    • Si la intersección está vacía, los back-ends aptos modificados son los mismos que los back-ends aptos originales.

En la siguiente tabla se resume el proceso para crear el conjunto de backends aptos modificados cuando la opción de afinidad zonal es ZONAL_AFFINITY_SPILL_CROSS_ZONE y la proporción de derivación configurada es 0.0.

Backends originales aptos (A) Back-ends de prueba de concordancia zonal (B) Backends coincidentes zonales (C) Intersección (A∩C) Backends aptos modificados
Todos los backends principales en buen estado

Todos los backends principales configurados

Es posible que todos los backends de prueba de coincidencia zonal estén en buen estado o que haya una combinación de backends en buen estado y en mal estado.

Todos los back-ends principales de la zona del cliente

Es posible que todos los backends coincidentes zonales estén en buen estado, en mal estado o en una combinación de ambos.

Todos los backends principales en buen estado de la zona del cliente

Intersección no vacía: los backends aptos modificados son todos los backends principales en buen estado de la zona del cliente.

Las nuevas conexiones se distribuyen en la zona del cliente. Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.


La intersección está vacía: los back-ends aptos modificados son los mismos que los back-ends aptos originales.

Las nuevas conexiones se pueden distribuir en la zona del cliente o en otras zonas.

Todos los backends de conmutación por error en buen estado

Todos los backends de conmutación por error configurados

Es posible que todos los backends de prueba de coincidencia zonal estén en buen estado o que haya una combinación de backends en buen estado y en mal estado.

Todos los back-ends de conmutación por error de la zona del cliente

Es posible que todos los backends coincidentes zonales estén en buen estado, en mal estado o en una combinación de ambos.

Todos los backends de conmutación por error en buen estado de la zona del cliente

La intersección no está vacía: los backends aptos modificados son todos los backends de conmutación por error en buen estado de la zona del cliente.

Las nuevas conexiones se distribuyen en la zona del cliente. Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.


La intersección está vacía: los back-ends aptos modificados son los mismos que los back-ends aptos originales.

Las nuevas conexiones se pueden distribuir en la zona del cliente o en otras zonas.

Todos los backends principales en mal estado

Todos los backends principales configurados

Por definición, todos los backends de prueba de coincidencia zonal están en mal estado cuando todos los backends principales aptos originales están en mal estado.

Todos los backends principales en mal estado de la zona del cliente

Todos los backends principales en mal estado de la zona del cliente

La intersección nunca está vacía: los backends aptos modificados son todos los backends principales no aptos de la zona del cliente.

Las nuevas conexiones se distribuyen en la zona del cliente. Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.

Ratio de desbordamiento distinto de cero

Si la proporción de desbordamiento configurada es superior a 0.0 pero inferior o igual a 1.0, el balanceador de carga usa el siguiente proceso para crear los backends aptos modificados:

  1. Empieza con los backends de prueba de coincidencia zonal identificados por la condición de coincidencia zonal.

  2. Elimina todos los back-ends que no estén en la misma zona que el cliente. De esta forma, obtenemos un conjunto de backends coincidentes zonales. Este conjunto nunca está vacío porque se ha producido una coincidencia zonal.

  3. Calcula la intersección de los backends coincidentes zonales con los backends aptos originales. Este conjunto puede estar vacío o no.

  4. Calcula la siguiente proporción:

    $$ \frac{\text{count}(\text{zonal matched backends} \; \cap \; \text{original eligible backends})}{\text{count}(\text{zonal matched backends})} $$

    Ten en cuenta que la proporción calculada siempre es cero cuando el conjunto de intersección está vacío.

  5. Usa la relación calculada para determinar los backends aptos modificados:

    • Si la relación calculada es mayor o igual que la relación de desbordamiento, los backends aptos modificados son el conjunto de intersección. Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.

    • Si la proporción calculada es inferior a la proporción de desbordamiento, los backends aptos modificados serán los mismos que los originales.

En la siguiente tabla se resume el proceso para crear el conjunto de backends aptos modificados cuando la opción de afinidad zonal es ZONAL_AFFINITY_SPILL_CROSS_ZONE y la proporción de desbordamiento configurada no es 0.0:

Backends originales aptos (A) Back-ends de prueba de concordancia zonal (B) Backends coincidentes zonales (C) Intersección (A∩C) Backends aptos modificados
Todos los backends principales en buen estado

Todos los backends principales configurados

Es posible que todos los backends de prueba de coincidencia zonal estén en buen estado o que haya una combinación de backends en buen estado y en mal estado.

Todos los back-ends principales de la zona del cliente

Es posible que todos los backends coincidentes zonales estén en buen estado, en mal estado o en una combinación de ambos.

Todos los backends principales en buen estado de la zona del cliente

Relación calculada ≥ relación de desbordamiento: los back-ends aptos modificados son todos los back-ends principales sanos de la zona del cliente.

Las nuevas conexiones se distribuyen en la zona del cliente. Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.


Relación calculada < relación de desbordamiento: los back-ends aptos modificados son los mismos que los back-ends aptos originales.

Las nuevas conexiones se pueden distribuir en la zona del cliente o en otras zonas.

Todos los backends de conmutación por error en buen estado

Todos los backends de conmutación por error configurados

Es posible que todos los backends de prueba de coincidencia zonal estén en buen estado o que haya una combinación de backends en buen estado y en mal estado.

Todos los back-ends de conmutación por error de la zona del cliente

Es posible que todos los backends coincidentes zonales estén en buen estado, en mal estado o en una combinación de ambos.

Todos los backends de conmutación por error en buen estado de la zona del cliente

Relación calculada ≥ relación de respaldo: los back-ends aptos modificados son todos los back-ends de conmutación por error correctos de la zona del cliente.

Las nuevas conexiones se distribuyen en la zona del cliente. Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.


Relación calculada < relación de desbordamiento: los back-ends aptos modificados son los mismos que los back-ends aptos originales.

Las nuevas conexiones se pueden distribuir en la zona del cliente o en otras zonas.

Todos los backends principales en mal estado

Todos los backends principales configurados

Por definición, todos los backends de prueba de coincidencia zonal están en mal estado cuando todos los backends principales aptos originales están en mal estado.

Todos los backends principales en mal estado de la zona del cliente

Todos los backends principales en mal estado de la zona del cliente

La proporción calculada siempre es igual o superior a la proporción de desbordamiento: los back-ends aptos modificados son todos los back-ends principales no operativos de la zona del cliente.

Las nuevas conexiones se distribuyen en la zona del cliente. Los back-ends aptos modificados pueden ser los mismos que los originales o un subconjunto de ellos.

Ejemplos de ratio de desbordamiento

En los siguientes ejemplos se muestra cómo funciona ZONAL_AFFINITY_SPILL_CROSS_ZONE.

  • Una proporción de desbordamiento de 1.0 significa lo siguiente:

    • Si la intersección de los backends coincidentes zonales y los backends aptos originales es el mismo conjunto que los backends coincidentes zonales, los backends aptos modificados son el conjunto de intersección.
    • Si la intersección de los backends coincidentes zonales y los backends aptos originales no es el mismo conjunto que los backends coincidentes zonales, los backends aptos modificados son los mismos que los backends aptos originales.
  • Una proporción de desbordamiento de 0.8 significa lo siguiente:

    • Cuando el número de back-ends de la intersección de zonal matched backends y original eligible backends es al menos el 80 % del número de zonal matched backends, modified eligible backends es ese conjunto de intersección.
    • Si el número de back-ends de la intersección de los back-ends coincidentes zonales y los back-ends aptos originales es inferior al 80 % del número de back-ends coincidentes zonales, los back-ends aptos modificados son los mismos que los back-ends aptos originales.
  • Una proporción de desbordamiento de 0.0 significa lo siguiente:

    • Si la intersección de los backends coincidentes zonales y los backends aptos originales no está vacía, los backends aptos modificados son el conjunto de intersección.
    • Si la intersección de los backends coincidentes zonales y los backends aptos originales está vacía, los backends aptos modificados son los mismos que los backends aptos originales.

Considera la siguiente configuración, en la que se configura un balanceador de carga de red de paso a través interno con una opción de afinidad de zona ZONAL_AFFINITY_SPILL_CROSS_ZONE y una proporción de desbordamiento de 0.8:

  • Backends configurados: diez backends principales (cinco en la zona 1 y cinco en la zona 2)
  • Backends aptos originales: todos los backends principales en buen estado (ocho backends: cinco en la zona 1 y tres en la zona 2)
  • Backend de prueba de coincidencia zonal: los diez backends principales configurados
Ejemplo de afinidad zonal de un balanceador de carga de red de paso a través interno.
Parte del tráfico ligero se desborda a otra zona (haz clic para ampliar la imagen).

Situación A: cliente compatible en la zona 1

  • Backends coincidentes zonales: cinco backends en la zona 1.
  • Intersección: la intersección de los backends coincidentes zonales y los backends aptos originales consta de los cinco backends en buen estado de la zona 1.
  • Relación calculada: 5 / 5 = 1,0
  • Resultado: Como la proporción calculada de 1,0 es ≥ 0,8, los back-ends aptos modificados se encuentran en el conjunto de intersección, es decir, los cinco back-ends principales en buen estado de la zona 1 del cliente. Las conexiones nuevas se distribuyen exclusivamente en la zona del cliente.

Situación B: cliente compatible en la zona 2

  • Backends coincidentes zonales: cinco backends en la zona 2.
  • Intersección: la intersección de los backends coincidentes zonales y los backends aptos originales consta de los tres backends en buen estado de la zona 2.
  • Relación calculada: 3 / 5 = 0,6
  • Resultado: como la proporción calculada de 0,6 es inferior a 0,8, los back-ends aptos modificados son los back-ends aptos originales. Los backends aptos originales son los ocho backends en buen estado (cinco en la zona 1 y tres en la zona 2). Las nuevas conexiones se distribuyen entre la zona 1 y la zona 2.

Siguientes pasos