La afinidad zonal, configurada en el servicio de backend del balanceador de cargas, te permite limitar el tráfico entre zonas, reducir la latencia y mejorar el rendimiento, todo ello sin dejar de aprovechar los beneficios de una arquitectura multizonal.
Los balanceadores de cargas de red de transferencia internos admiten diferentes opciones de afinidad zonal que ofrecen distintos grados de preferencia para enrutar las conexiones nuevas a los backends aptos que se encuentran 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 cargas no se ven afectadas por la afinidad zonal.
Antes de comenzar
Antes de habilitar la afinidad zonal, debes comprender qué funciones del balanceador de cargas de red de transferencia interno son compatibles con la afinidad zonal.
Admitido
- Siguientes saltos para rutas estáticas
- Próximos saltos para rutas basadas en políticas
- Conmutación por error
- El hash simétrico solo se admite cuando ambos balanceadores de cargas de red de transferencia internos tienen habilitada la afinidad zonal.
No compatible
La afinidad zonal no es compatible con los balanceadores de cargas de red de transferencia internos que se configuran con lo siguiente:
- Subconjuntos de backend
- Destinos de recopilador para la Replicación de paquetes
- Implementaciones de integración de seguridad de redes (NSI) en banda o fuera de banda Usar la afinidad zonal con la integración de seguridad de red genera pérdidas de paquetes.
- Servicio publicado de Private Service Connect. La afinidad zonal solo es posible para los clientes compatibles que envían paquetes al balanceador de cargas, no a un extremo de Private Service Connect cuyo productor de servicios publicado use un balanceador de cargas de red de transferencia interno.
Clientes compatibles
La afinidad zonal solo es posible para las VM de cliente que se encuentran en la misma región que el balanceador de cargas. La afinidad zonal no es compatible con los siguientes clientes, que siempre operan como si la afinidad zonal estuviera inhabilitada:
Túneles de Cloud VPN del cliente y adjuntos de VLAN de Cloud Interconnect del cliente: Los túneles de Cloud VPN y los adjuntos 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 un adjunto de VLAN nunca admiten la afinidad zonal, independientemente de si se encuentran en la misma región que el balanceador de cargas o no.
VMs de cliente en regiones que no coinciden con la región del balanceador de cargas: Se puede acceder a un balanceador de cargas de red de transferencia interno ubicado en una región desde clientes en todas las demás regiones si se habilita el acceso global. Cuando las VMs de cliente se encuentran en una región diferente a la del balanceador de cargas, nunca comparten una zona común con ninguno de los backends del balanceador de cargas.
Opciones de afinidad zonal
Los balanceadores de cargas de red de transferencia internos admiten las siguientes opciones de afinidad zonal:
ZONAL_AFFINITY_DISABLED(predeterminado): La afinidad zonal está inhabilitada. El balanceador de cargas selecciona un backend apto para una conexión nueva 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 cargas mantiene el tráfico en la zona del cliente, incluso si eso implica usar backends en mal estado. Para obtener detalles 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 cargas permite que las conexiones nuevas se distribuyan dentro de la zona del cliente o se extiendan a otras zonas. El desbordamiento se controla con la proporción de desbordamiento. Para obtener más información sobre esta opción, consulta Cómo funcionanZONAL_AFFINITY_SPILL_CROSS_ZONEy el ratio de derrame.
Para obtener información sobre cómo configurar la afinidad zonal en el servicio de backend de un balanceador de cargas de red de transferencia interno, consulta Usa la afinidad zonal.
Diferentes tipos de backends
La afinidad zonal crea un conjunto de backends aptos modificados en función de los backends aptos originales y los backends configurados del balanceador de cargas. Para explicar cómo la afinidad zonal realiza esta modificación, definimos con precisión cinco conjuntos de servidores de backend diferentes. En este documento, se hace referencia a los siguientes términos en las secciones posteriores, ya que se explica cómo funciona la afinidad zonal.
Conjuntos de entrada
Backends configurados: Es el conjunto de todos los backends que forman parte del servicio de backend del balanceador de cargas. 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.
Backends originales aptos: Es un subconjunto de los backends configurados que son aptos para recibir conexiones nuevas. El conjunto de backends originales aptos se produce en el paso Identify eligible backends del proceso de selección de backend y seguimiento de conexiones.
Conjuntos intermedios
Backends de prueba de coincidencia zonal: Es un subconjunto de backends configurados que se usa para probar una coincidencia zonal. Tanto los backends configurados como los backends originales aptos determinan qué VMs son backends de prueba de coincidencia zonal.
Backends zonales coincidentes: Es un subconjunto de los backends de prueba de coincidencias zonales que se encuentran en la misma zona que un cliente compatible.
Conjunto de salida
- Backends aptos modificados: Según el tipo de afinidad zonal configurada y la proporción de desbordamiento, 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. 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. Luego, el balanceador de cargas podría modificar el conjunto de backends aptos originales para proporcionar la afinidad zonal configurada. La modificación de los backends aptos originales se produce después de que el balanceador de cargas selecciona un backend apto para una conexión nueva.
Para que se active la lógica de afinidad zonal, debe ocurrir la siguiente secuencia de eventos:
Se debe habilitar la afinidad zonal.
Si la afinidad zonal está habilitada, continúa con el siguiente paso.
Determina si el cliente es un cliente compatible.
Si el cliente es compatible, continúa con el siguiente paso.
Determina si puede ocurrir una coincidencia zonal.
Una coincidencia zonal significa que la VM del cliente se encuentra en una zona que contiene al menos un backend configurado del tipo pertinente. En la sección Condiciones de coincidencia zonales, se describen los diferentes backends que se pueden configurar.
Una coincidencia zonal nunca es posible si se cumple alguna de las siguientes condiciones:
- La afinidad zonal está inhabilitada
- El cliente no es compatible
Aplica la lógica de afinidad zonal.
Condiciones de coincidencia zonales
Para que se produzca una coincidencia zonal, al menos una instancia o un extremo en los backends de prueba de coincidencia zonal deben estar en la misma zona que un cliente compatible. Tanto los backends configurados como los backends originales aptos son entradas que se usan para determinar los backends de prueba de coincidencia zonal.
| Backends originales aptos | Backends de pruebas de coincidencia zonales |
|---|---|
| Todos los backends principales en buen estado |
Todos los backends principales configurados Es posible 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 Los backends principales configurados están todos en mal estado por definición cuando los backends principales aptos originales están todos en mal estado. |
Ejemplo de coincidencia zonal
Considera la siguiente configuración para un balanceador de cargas de red de transferencia interno para comprender si se produce una coincidencia zonal.
- Backends principales: zonas A y B
- Backends de conmutación por error: zonas C y D
- Ubicación de la VM del cliente: zona A
- Afinidad zonal habilitada
- La política de conmutación por error predeterminada está presente.
Situación 1:
- Backends originales aptos: Todos los backends principales en buen estado (zonas A y B)
- Backends de prueba de coincidencia zonal: Todos los backends principales configurados (zonas A y B)
- ¿Hay una coincidencia zonal?: Sí. En este caso, la VM del cliente se encuentra en la misma zona que los backends de prueba de coincidencia zonal, por lo que hay una coincidencia zonal.
Situación 2:
- Backends aptos originales: 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 se encuentra en la zona A, y los backends de prueba de coincidencias zonales se encuentran en las zonas C y D.
Después de que se produce una coincidencia zonal, debes aplicar la lógica de afinidad zonal como se describe en las siguientes secciones.
Lógica de afinidad zonal
Si se produce una coincidencia zonal, aplica la lógica de afinidad zonal según la opción de afinidad zonal configurada. Las opciones que habilitan la afinidad zonal son las siguientes:
ZONAL_AFFINITY_STAY_WITHIN_ZONEZONAL_AFFINITY_SPILL_CROSS_ZONEcon una proporción de derrame de0ZONAL_AFFINITY_SPILL_CROSS_ZONEcon una proporción de derrame distinta de cero
Después de que se produce una coincidencia zonal y según el tipo de opción de afinidad zonal que se configure, 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 establece en ZONAL_AFFINITY_STAY_WITHIN_ZONE y se produce una coincidencia zonal, el balanceador de cargas distribuye las conexiones nuevas a los backends aptos modificados. Los servidores de backend aptos modificados pueden ser los mismos que los originales, un subconjunto de los originales o diferentes de los originales.
Para crear backends aptos modificados, el balanceador de cargas usa el siguiente proceso:
Comienza con los backends de la prueba de coincidencia zonal identificados por la condición de coincidencia zonal.
Quita todos los backends que no estén en la misma zona que el cliente. Esto nos da un conjunto de backends zonales coincidentes. Este conjunto nunca está vacío porque se produjo una coincidencia zonal.
Calcula la intersección de los backends zonales coincidentes con los backends originales aptos. Esta intersección puede estar vacía o no.
Si la intersección no está vacía, los backends aptos modificados son el conjunto de intersección. Los backends aptos modificados pueden ser los mismos que los backends aptos originales, o bien los backends aptos modificados pueden ser un subconjunto de los backends aptos originales.
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 backends en la zona del cliente, incluso si esto implica usar backends en mal estado.
| Backends originales aptos (A) | Backends de pruebas de concordancia zonales (B) | Backends coincidentes zonales (C) | Intersección (A∩C) | Backends aptos modificados |
|---|---|---|---|---|
| Todos los backends principales en buen estado |
Todos los backends principales configurados Los backends de la prueba de coincidencia zonal pueden estar todos en buen estado o ser una combinación de backends en buen estado y en mal estado. |
Todos los servidores de backend principales en la zona del cliente Es posible que todos los backends zonales coincidentes 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 buen estado en la zona del cliente |
La intersección no está vacía: Los backends aptos modificados son todos los backends principales en buen estado de la zona del cliente. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos. La intersección está vacía: Los backends aptos modificados son todos los backends principales en mal estado en 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 están en mal 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 Los backends de la prueba de coincidencia zonal pueden estar todos en buen estado o ser una combinación de backends en buen estado y en mal estado. |
Todos los backends de conmutación por error en la zona del cliente Es posible que todos los backends zonales coincidentes 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 en 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 backends aptos modificados pueden ser los mismos que los backends aptos 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 zonales coincidentes, que son todos los backends de conmutación por error en 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 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 los backends aptos originales son todos backends principales en mal estado. |
Todos los backends principales en mal estado en la zona del cliente |
Todos los backends principales en mal estado en 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 backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos. |
Cómo funcionan ZONAL_AFFINITY_SPILL_CROSS_ZONE y la proporción de derrame
Si la afinidad zonal se establece en ZONAL_AFFINITY_SPILL_CROSS_ZONE y se produce una coincidencia zonal, el balanceador de cargas distribuye las conexiones nuevas a los backends aptos modificados. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos.
Cuando los backends aptos modificados son los mismos que los backends aptos originales, es posible que se envíen conexiones nuevas a los backends aptos de la zona del cliente o a los backends aptos de cualquier zona (desbordamiento). Esta distribución depende de una proporción de derrame configurable.
Una proporción de derrame configurable indica el valor de umbral para mantener el tráfico en la zona del cliente. El valor de la proporción de derrame puede variar de 0.0 a 1.0, inclusive. Si no especificas una proporción de desbordamiento cuando configuras ZONAL_AFFINITY_SPILL_CROSS_ZONE, Google Cloud usa un valor predeterminado de 0.0.
Proporción de derrame cero
Si la proporción de desbordamiento configurada es 0.0, el balanceador de cargas usa el siguiente proceso para crear los backends aptos modificados:
Comienza con los backends de prueba de la coincidencia zonal identificados por la condición de coincidencia zonal.
Quita todos los backends que no estén en la misma zona que el cliente. Esto nos da un conjunto de backends zonales coincidentes. Este conjunto nunca está vacío porque se produjo una coincidencia zonal.
Calcula la intersección de los backends zonales coincidentes con los backends originales aptos. Esta intersección puede estar vacía o no.
Si esta intersección no está vacía, el conjunto de backends aptos modificados es el conjunto de intersección. Los backends aptos modificados pueden ser los mismos que los backends aptos originales, o bien pueden ser un subconjunto de los backends aptos originales.
Si la intersección está vacía, los backends aptos modificados son los mismos que los backends 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 desbordamiento configurada es 0.0.
| Backends originales aptos (A) | Backends de pruebas de concordancia zonales (B) | Backends coincidentes zonales (C) | Intersección (A∩C) | Backends aptos modificados |
|---|---|---|---|---|
| Todos los backends principales en buen estado |
Todos los backends principales configurados Los backends de la prueba de coincidencia zonal pueden estar todos en buen estado o ser una combinación de backends en buen estado y en mal estado. |
Todos los servidores de backend principales en la zona del cliente Es posible que todos los backends zonales coincidentes 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 buen estado en la zona del cliente |
La intersección no está vacía: Los backends aptos modificados son todos los backends principales en buen estado de la zona del cliente. Las conexiones nuevas se distribuyen dentro de la zona del cliente. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos. La intersección está vacía: Los backends aptos modificados son los mismos que los backends aptos originales. Las conexiones nuevas se pueden distribuir dentro de 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 Los backends de la prueba de coincidencia zonal pueden estar todos en buen estado o ser una combinación de backends en buen estado y en mal estado. |
Todos los backends de conmutación por error en la zona del cliente Es posible que todos los backends zonales coincidentes 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 en 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 conexiones nuevas se distribuyen dentro de la zona del cliente. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos. La intersección está vacía: Los backends aptos modificados son los mismos que los backends aptos originales. Las conexiones nuevas se pueden distribuir dentro de 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 los backends aptos originales son todos backends principales en mal estado. |
Todos los backends principales en mal estado en la zona del cliente |
Todos los backends principales en mal estado en 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 conexiones nuevas se distribuyen dentro de la zona del cliente. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos. |
Proporción de derrame distinta de cero
Si la proporción de desbordamiento configurada es mayor que 0.0, pero menor o igual que 1.0, el balanceador de cargas usa el siguiente proceso para crear los backends aptos modificados:
Comienza con los backends de la prueba de coincidencia zonal identificados por la condición de coincidencia zonal.
Quita todos los backends que no estén en la misma zona que el cliente. Esto nos da un conjunto de backends zonales coincidentes. Este conjunto nunca está vacío, ya que se produjo una coincidencia zonal.
Calcula la intersección de los backends zonales coincidentes con los backends originales aptos. Este conjunto puede estar vacío o no.
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.
Usa la proporción calculada para determinar los backends aptos modificados:
Si la proporción calculada es mayor o igual que la proporción de desbordamiento, los backends aptos modificados son el conjunto de intersección. Los backends aptos modificados pueden ser los mismos que los backends aptos originales, o bien pueden ser un subconjunto de ellos.
Si la proporción calculada es menor que la proporción de transferencia, los backends aptos modificados son los mismos que los backends 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 desbordamiento configurada no es 0.0:
| Backends originales aptos (A) | Backends de pruebas de concordancia zonales (B) | Backends coincidentes zonales (C) | Intersección (A∩C) | Backends aptos modificados |
|---|---|---|---|---|
| Todos los backends principales en buen estado |
Todos los backends principales configurados Los backends de la prueba de coincidencia zonal pueden estar todos en buen estado o ser una combinación de backends en buen estado y en mal estado. |
Todos los servidores de backend principales en la zona del cliente Es posible que todos los backends zonales coincidentes 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 buen estado en la zona del cliente |
Proporción calculada ≥ proporción de derrame: Los backends aptos modificados son todos los backends principales en buen estado de la zona del cliente. Las conexiones nuevas se distribuyen dentro de la zona del cliente. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos. Proporción calculada < proporción de transferencia: Los servidores de backend aptos modificados son los mismos que los servidores de backend aptos originales. Las conexiones nuevas se pueden distribuir dentro de 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 Los backends de la prueba de coincidencia zonal pueden estar todos en buen estado o ser una combinación de backends en buen estado y en mal estado. |
Todos los backends de conmutación por error en la zona del cliente Es posible que todos los backends zonales coincidentes 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 en la zona del cliente |
Proporción calculada ≥ proporción de derrame: Los backends aptos modificados son todos los backends de conmutación por error en buen estado en la zona del cliente. Las conexiones nuevas se distribuyen dentro de la zona del cliente. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos. Proporción calculada < proporción de transferencia: Los servidores de origen aptos modificados son los mismos que los servidores de origen aptos originales. Las conexiones nuevas se pueden distribuir dentro de 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 los backends aptos originales son todos backends principales en mal estado. |
Todos los backends principales en mal estado en la zona del cliente |
Todos los backends principales en mal estado en la zona del cliente |
La proporción calculada siempre es ≥ la proporción de derrame: Los servidores de backend aptos modificados son todos los servidores de backend principales no aptos en la zona del cliente. Las conexiones nuevas se distribuyen dentro de la zona del cliente. Los backends aptos modificados pueden ser los mismos que los backends aptos originales o un subconjunto de ellos. |
¿Qué sigue?
- Si deseas configurar Cloud Monitoring para balanceadores de cargas de red de transferencia internos, consulta Registro y supervisión del balanceador de cargas de red de transferencia interno.
- Para solucionar problemas con el balanceador de cargas de red de transferencia interno, consulta Soluciona problemas del balanceador de cargas de red de transferencia interno.