Distribución del tráfico para balanceadores de cargas de red de transferencia internos

En esta página, se explican los conceptos sobre cómo los balanceadores de cargas de red de transferencia internos distribuyen el tráfico.

Selección de backend y seguimiento de conexiones

La selección de backend y el seguimiento de conexiones funcionan en conjunto para balancear varias conexiones en diferentes backends y para enrutar todos los paquetes de cada conexión al mismo backend. Esto se logra con una estrategia de dos partes. Primero, se selecciona un backend con un hash coherente. Luego, esta selección se registra en una tabla de seguimiento de conexiones.

En los siguientes pasos, se describen la selección de backend y el seguimiento de conexiones.

1. Verifica si hay una entrada en la tabla de seguimiento de la conexión

El balanceador de cargas determina si un paquete balanceado pertenece a una conexión nueva o a una existente con el siguiente proceso:

  • Paquete TCP con la marca SYN:

    • Si el modo de seguimiento de conexiones del balanceador de cargas es PER_CONNECTION, continúa con el paso Identifica los backends aptos. En el modo de seguimiento PER_CONNECTION, un paquete TCP con la marca SYN siempre representa una conexión nueva, sin importar la afinidad de sesión configurada.

    • Si el modo de seguimiento de conexión del balanceador de cargas es PER_SESSION y la afinidad de sesión es NONE o CLIENT_IP_PORT_PROTO, continúa con el paso Identifica los backends aptos. En el modo de seguimiento PER_SESSION, un paquete TCP con la marca SYN representa una conexión nueva solo cuando se usa una de las opciones de afinidad de sesión de 5 tuplas (NONE o CLIENT_IP_PORT_PROTO).

  • Todos los demás paquetes: El balanceador de cargas verifica si el paquete coincide con una entrada existente en la tabla de seguimiento de conexiones. La granularidad del hash de paquetes que se usa para verificar si existe una entrada en la tabla de seguimiento de conexiones depende del modo de seguimiento de conexiones y de la afinidad de sesión que configuraste. Para obtener más información, consulta la tabla en la sección Modo de seguimiento de conexiones.

    • Si el paquete coincide con una entrada de la tabla de seguimiento de conexiones, el balanceador de cargas envía el paquete al backend seleccionado anteriormente.

    • Si el paquete no coincide con una entrada de la tabla de seguimiento de conexiones, continúa con el paso Identifica los backends aptos.

    Para obtener información sobre cuánto tiempo persiste una entrada de la tabla de seguimiento de conexiones y en qué condiciones persiste, consulta el paso Administra las entradas de la tabla de seguimiento de conexiones.

2. Pasos para la selección del backend

Para una conexión nueva, el balanceador de cargas usa el hash coherente para seleccionar un backend entre los backends aptos.

En los siguientes pasos, se describe el proceso para seleccionar un backend apto para una conexión nueva y, luego, registrar esa conexión en una tabla de seguimiento de conexiones.

2.1 Identifica los servidores de backend aptos

Los backends aptos son los backends que pueden recibir conexiones nuevas. En la siguiente tabla, se define el conjunto de backends aptos según si configuraste una política de conmutación por error.

Política de conmutación por error Backends aptos

Cuando no se configura ninguna política de conmutación por error, todos los backends configurados son backends principales. El conjunto de backends aptos se define de la siguiente manera:

  • Cuando al menos un backend está en buen estado, el conjunto de backends aptos consta de todos los backends en buen estado.
  • Cuando todos los backends están en mal estado, el conjunto de backends aptos consta de todos los backends.

Cuando se configura una política de conmutación por error, el balanceador de cargas usa la información de la verificación de estado y la configuración de la política de conmutación por error para definir el conjunto de backends aptos:

  • Cuando al menos un backend (principal o de conmutación por error) está en buen estado, los backends aptos son aquellos que provienen del primer conjunto de los siguientes que no esté vacío:
    1. Si no hay backends principales en buen estado, los backends aptos son todos los backends de conmutación por error en buen estado.
    2. Si no hay backends de conmutación por error en buen estado, los backends aptos son todos los backends principales en buen estado.
    3. Si la proporción de conmutación por error se establece en 0.0 (el valor predeterminado), los backends aptos son todos los backends principales en buen estado.
    4. Si la proporción de la cantidad de backends principales en buen estado en comparación con la cantidad total de backends principales es mayor o igual que la proporción de conmutación por error configurada, los backends aptos constan de todos los backends principales en buen estado.
    5. Los backends aptos constan de todos los backends de conmutación por error en buen estado.
  • Cuando no hay backends en buen estado (primarios y de conmutación por error), el conjunto de backends aptos depende exclusivamente de la configuración de la política de conmutación por error:
    • Si la política de conmutación por error está configurada para descartar conexiones nuevas cuando todos los backends principales y de conmutación por error están en mal estado, el conjunto de backends aptos está vacío. En consecuencia, el balanceador de cargas descarta paquetes para las conexiones nuevas.
    • Si la política de conmutación por error no está configurada para descartar conexiones nuevas cuando todos los backends principales y de conmutación por error están en mal estado, los backends aptos son todos los backends principales en mal estado.

2.2 Ajusta los backends aptos para la afinidad zonal

Este paso se omite si se cumple alguna de las siguientes condiciones:

Si la afinidad zonal está habilitada, un cliente es compatible con la afinidad zonal y se produce una coincidencia zonal, las conexiones nuevas del cliente se enrutan a un conjunto ajustado de backends aptos. Para obtener más información, consulta lo siguiente:

2.3 Selecciona un backend apto

El balanceador de cargas mantiene hashes de los backends aptos, y cada hash de backend se asigna a un círculo unitario.

Cuando procesa un paquete para una conexión que no está en la tabla de seguimiento de conexiones, el balanceador de cargas calcula un hash de las características del paquete y asigna ese hash al mismo círculo unitario, seleccionando un backend apto en la circunferencia del círculo. El conjunto de características del paquete que se usa para calcular el hash del paquete se define en la configuración de afinidad de sesión. Por ejemplo, cuando la afinidad de sesión seleccionada genera un hash de selección de backend de 2 o 3 tuplas, todas las conexiones TCP desde una dirección IP de origen se asignan al mismo backend apto.

  • Si no se configura explícitamente una afinidad de sesión, la afinidad de sesión NONE es la predeterminada.

  • El hash coherente garantiza que el balanceador de cargas asigne conexiones nuevas a los backends aptos de una manera que minimice las interrupciones de la asignación, incluso si cambia la cantidad de backends aptos.

    • El balanceador de cargas siempre selecciona el mismo backend apto para una conexión y, en general, siempre selecciona el mismo backend apto para todos los paquetes con características idénticas, según lo define el parámetro de configuración de afinidad de sesión, si el conjunto de backends aptos no cambia.

    • Si se agrega o quita un backend apto, el hash coherente tiene como objetivo minimizar la interrupción de las asignaciones a los demás backends aptos, es decir, la mayoría de las conexiones que se asignan a otros backends aptos siguen asignándose al mismo backend apto.

  • Además, el hash coherente garantiza que el balanceador de cargas distribuya las conexiones nuevas entre los backends aptos de la manera más equitativa posible. Para todos los hashes de paquetes posibles, según lo define el parámetro de configuración de afinidad de sesión configurado (y, más específicamente, para todas las conexiones posibles cuando la afinidad de sesión genera un hash de 5 tuplas para la selección de backend):

    • Cuando se agrega un backend apto, aproximadamente 1/N conexiones nuevas se asignan al backend recién agregado. En esta situación, N es el recuento de backends después de que se agrega el nuevo backend.

    • Cuando se quita un backend apto, aproximadamente 1/N conexiones nuevas se asignan a uno de los N-1 backends restantes. En esta situación, N es el recuento de backends antes de que se quite el backend apto.

2.4 Crea una entrada de tabla de seguimiento de conexiones

Después de seleccionar un backend, el balanceador de cargas crea una entrada en la tabla de seguimiento de conexiones. La entrada de la tabla de seguimiento de conexiones asigna las características del paquete al backend seleccionado. Los campos de encabezado de paquetes que se usan para esta asignación dependen del modo de seguimiento de conexiones y la afinidad de sesión que configuraste.

3. Administra las entradas de la tabla de seguimiento de conexiones

El balanceador de cargas administra las entradas de la tabla de seguimiento de conexiones según los siguientes eventos y reglas:

  • Se quitan las entradas inactivas: Se quita una entrada de la tabla de seguimiento de conexiones después de que la conexión haya estado inactiva. A menos que configures un tiempo de espera por inactividad personalizado, el balanceador de cargas usará un tiempo de espera por inactividad predeterminado de 600 segundos. Para obtener más información, consulta Tiempo de espera inactivo.

  • Conexiones TCP cerradas: Las entradas de la tabla de seguimiento de conexiones para las conexiones TCP no se quitan cuando se cierra una conexión TCP con un paquete FIN o RST. Es posible que se quiten más adelante como entrada inactiva. Cada conexión TCP nueva siempre incluye la marca SYN y está sujeta al procesamiento que se describe en el paso Verifica si hay una entrada en la tabla de seguimiento de conexiones.

  • Vaciado de conexiones en la conmutación por error: Cuando se configura al menos un backend de conmutación por error y se inhabilita el parámetro de configuración de vaciado de conexiones en la conmutación por error, el balanceador de cargas quita todas las entradas de la tabla de seguimiento de conexiones cuando el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error. Para obtener más información, consulta Vaciado de conexiones en la conmutación por error.

  • Persistencia de la conexión en backends en mal estado: Se pueden quitar las entradas de la tabla de seguimiento de conexiones si un backend está en mal estado. Este comportamiento depende de los factores que se describen en Persistencia de la conexión en backends en mal estado.

    • Cuando se quita una entrada de la tabla de seguimiento de conexiones porque un backend seleccionado anteriormente cambia de buen estado a mal estado, los paquetes posteriores de la conexión se tratan como si pertenecieran a una conexión nueva. Después de seleccionar un nuevo backend apto para los paquetes posteriores, el balanceador de cargas crea una entrada de reemplazo en la tabla de seguimiento de conexiones.

    • Una entrada de reemplazo en la tabla de seguimiento de conexiones se comporta exactamente igual que cualquier otra entrada de la tabla de seguimiento de conexiones y está sujeta a los eventos y las reglas de este paso.

    • Si el backend seleccionado anteriormente vuelve a estar en buen estado después de estar en mal estado, el cambio de verificación de estado por sí solo no hace que se quite la entrada de la tabla de seguimiento de conexiones de reemplazo. Se produce una excepción cuando se configura al menos un backend de conmutación por error y se inhabilita el parámetro de configuración de vaciado de conexiones en la conmutación por error. Si el cambio en el estado de la verificación de estado de un backend seleccionado anteriormente coincide con el conjunto de backends aptos que cambian entre backends principales y de conmutación por error, se quitan las entradas de la tabla de seguimiento de conexiones.

  • Vaciado de conexiones para backends quitados, detenidos o borrados: Si el vaciado de conexiones para backends quitados, detenidos o borrados está habilitado, las entradas de la tabla de seguimiento de conexiones se quitan después de un tiempo de espera configurable para el vaciado de conexiones. El conteo del tiempo de espera comienza cuando se recibe el comando para quitar, detener o borrar un backend. Si el vaciado de conexiones para los backends quitados, detenidos o borrados está inhabilitado, las entradas de la tabla de seguimiento de conexiones se quitan cuando se recibe el comando para quitar, detener o borrar un backend. Para obtener más información, consulta Habilita el vaciado de conexiones.

Afinidad de sesión

El parámetro de configuración de afinidad de sesión de un balanceador de cargas de red de transferencia interno define el hash de paquetes para la selección de backend y, según el modo de seguimiento de conexiones, el hash de paquetes para el seguimiento de conexiones.

La afinidad de sesión se configura en el servicio de backend, no en cada grupo de instancias de backend o NEG. La afinidad de sesión determina qué encabezados de IP y de capa 4 se usan para calcular un hash de las características del paquete. El hash de las características del paquete se usa en los pasos de selección del backend.

Los balanceadores de cargas de red de transferencia internos admiten los siguientes parámetros de configuración de afinidad de sesión.

Método hash para la selección de backend Configuración de afinidad de sesión

Hash de 5 tuplas (consta de la dirección IP de origen, el puerto de origen, el protocolo, la dirección IP de destino y el puerto de destino) para paquetes sin fragmentar que incluyen información de puertos (paquetes TCP y paquetes UDP sin fragmentar)

O

Hash de 3 tuplas (que consta de la dirección IP de origen, la dirección IP de destino y el protocolo) para paquetes UDP fragmentados y paquetes de todos los demás protocolos

 NONE1
O
CLIENT_IP_PORT_PROTO
Hash de 3 tuplas
(consta de la dirección IP de origen, la dirección IP de destino y el protocolo)		 CLIENT_IP_PROTO
Hash de 2 tuplas
(consta de la dirección IP de origen y la dirección IP de destino)		 CLIENT_IP
Hash de 1 tupla
(consta solo de la IP de origen)		 CLIENT_IP_NO_DESTINATION

1 La afinidad de sesión NONE no indica que no haya afinidad de sesión. En cambio, significa que la afinidad de sesión se realiza con un hash de 5 o 3 tuplas de las características del paquete, lo que, funcionalmente, es el mismo comportamiento que cuando se establece CLIENT_IP_PORT_PROTO.

Afinidad de sesión y próximo salto del balanceador de cargas

Cuando un balanceador de cargas de red de transferencia interno es el próximo salto de una ruta estática, la dirección IP de destino no se limita a la dirección IP de la regla de reenvío del balanceador de cargas. En cambio, la dirección IP de destino del paquete puede ser cualquier dirección IP que se ajuste al rango de destino de la ruta estática.

Seleccionar un backend apto depende del cálculo de un hash de las características del paquete. A excepción de la afinidad de sesión CLIENT_IP_NO_DESTINATION (hash de 1 tupla), el hash depende, en parte, de la dirección IP de destino del paquete.

El balanceador de cargas selecciona el mismo backend para todas las conexiones nuevas posibles que tengan características de paquetes idénticas, según lo define la afinidad de sesión, si el conjunto de backends aptos no cambia. Si necesitas que la misma VM de backend procese todos los paquetes de un cliente, en función solo de la dirección IP de origen, sin importar las direcciones IP de destino, usa la afinidad de sesión CLIENT_IP_NO_DESTINATION.

Política de seguimiento de conexiones

En esta sección, se describen los parámetros de configuración de la política de seguimiento de conexiones del balanceador de cargas:

Modo de seguimiento de conexiones

En esta sección, se describe cómo el balanceador de cargas crea entradas en su tabla de seguimiento de conexiones. Los balanceadores de cargas de red de transferencia internos hacen un seguimiento de las conexiones para todos los protocolos que admiten y para todas las opciones de afinidad de sesión.

El modo de seguimiento de conexión, el protocolo y la afinidad de sesión determinan el conjunto de características del paquete que se usan para generar el hash del paquete en cada entrada de la tabla de seguimiento de conexión.

El modo de seguimiento de conexiones puede ser uno de los siguientes:

  • PER_CONNECTION: Este es el modo de seguimiento de conexiones predeterminado y más detallado. Cada conexión se define como un hash de 5 tuplas o un hash de 3 tuplas de las características del paquete, según si la información del puerto está presente en el paquete. Los paquetes no fragmentados que incluyen información de puertos (como los paquetes TCP y los paquetes UDP no fragmentados) se rastrean con hashes de 5 tuplas. Todos los demás paquetes se rastrean con hashes de 3 tuplas.

  • PER_SESSION: Este modo de seguimiento de conexiones menos detallado usa un hash que coincide con el hash de afinidad de sesión. Según la afinidad de sesión elegida, el modo de seguimiento PER_SESSION puede tratar varias conexiones distintas como una sola para los fines del seguimiento de conexiones. Esto reduce la frecuencia con la que una conexión se considera nueva y está sujeta a los pasos de selección del backend.

En la siguiente tabla, se resume lo siguiente:

  • Los hashes de paquetes que se usan para la selección de backend
  • Son los hashes de paquetes que se usan para el seguimiento de conexiones, según el modo de seguimiento de conexiones, el protocolo y la afinidad de sesión.
Afinidad de sesión Hash de paquete para la selección de backend Hash de paquete para el seguimiento de conexiones
Cuando se usa el modo de seguimiento PER_CONNECTION (predeterminado) Cuando se usa el modo de seguimiento PER_SESSION
NONE (predeterminado)
O
CLIENT_IP_PORT_PROTO
  • TCP y UDP sin fragmentar: Hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Hash de 3 tuplas
  • TCP y UDP sin fragmentar: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
  • TCP y UDP sin fragmentar: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
CLIENT_IP_PROTO
  • Todos los protocolos: Hash de 3 tuplas
  • TCP y UDP sin fragmentar: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los protocolos: Seguimiento de conexión activado, hash de 3 tuplas
CLIENT_IP
  • Todos los protocolos: Hash de 2 tuplas
  • TCP y UDP sin fragmentar: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los protocolos: Seguimiento de conexión activado, hash de 2 tuplas
CLIENT_IP_NO_DESTINATION
  • Todos los protocolos: Hash de 1 tupla
  • TCP y UDP sin fragmentar: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los protocolos: Seguimiento de conexión activado, hash de 1 tupla

Para obtener información sobre cómo cambiar el modo de seguimiento de conexiones, consulta Configura una política de seguimiento de conexiones.

Persistencia de la conexión en backends en mal estado

La opción Persistencia de la conexión en backends en mal estado controla si las conexiones existentes persisten en una VM o un extremo de backend seleccionado anteriormente después de que el backend esté en mal estado, siempre que el backend permanezca en un grupo de instancias o un NEG balanceado por cargas.

Las siguientes opciones de persistencia de la conexión están disponibles:

  • DEFAULT_FOR_PROTOCOL (predeterminada)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

En la siguiente tabla, se resume si las conexiones persisten en función de los backends en mal estado, según la opción de persistencia de la conexión, la afinidad de sesión, el modo de seguimiento de conexiones y el protocolo.

Opción de persistencia de conexión en backends en mal estado Comportamiento de la persistencia de la conexión en backends en mal estado
Cuando se usa el modo de seguimiento PER_CONNECTION (predeterminado) Cuando se usa el modo de seguimiento PER_SESSION
DEFAULT_FOR_PROTOCOL
  • TCP: Las conexiones persisten en backends en mal estado (todas las afinidades de sesión).
  • Todos los demás protocolos: Las conexiones nunca persisten en backends en mal estado.
  • TCP: Las conexiones persisten en backends en mal estado si la afinidad de sesión es NONE o CLIENT_IP_PORT_PROTO.
  • Todos los demás protocolos: Las conexiones nunca persisten en backends en mal estado.
NEVER_PERSIST Todos los protocolos: las conexiones nunca persisten en backends en mal estado.
ALWAYS_PERSIST

Esta opción solo se debe usar para casos de uso avanzados.
  • TCP, UDP: Las conexiones persisten en backends en mal estado (todas las afinidades de sesión).
 No es posible realizar la configuración.

Cuando la persistencia de la conexión en backends en mal estado se aplica al tráfico, cada conexión persiste mientras exista una entrada correspondiente en la tabla de seguimiento de conexiones. Para obtener más información, consulta el paso Administra las entradas de la tabla de seguimiento de conexiones.

Para obtener información sobre cómo cambiar el comportamiento de persistencia de la conexión, consulta Configura una política de seguimiento de conexiones.

Comportamiento de la persistencia de conexión TCP en backends en mal estado

El balanceador de cargas usa el seguimiento de conexiones con hash de 5 tuplas para las conexiones TCP en las siguientes situaciones:

  • Cuando se usa el modo de seguimiento PER_CONNECTION (todas las afinidades de sesión)
  • Cuando se usa el modo de seguimiento PER_SESSION, y la afinidad de sesión es NONE o CLIENT_IP_PORT_PROTO.

Cuando el balanceador de cargas usa un seguimiento de conexiones con hash de 5 tuplas para las conexiones TCP, ten en cuenta los siguientes comportamientos:

  • Si el backend en mal estado sigue respondiendo a los paquetes, la conexión continúa hasta que se restablece o se cierra (ya sea por el backend en mal estado o el cliente).
  • Si el backend en mal estado envía un paquete de restablecimiento de TCP (RST) o no responde a los paquetes, el cliente puede volver a intentarlo con una conexión nueva, lo que permite que el balanceador de cargas seleccione otro backend apto. (Los paquetes TCP SYN se tratan como conexiones nuevas en el paso Identifica los backends aptos).

Tiempo de espera inactivo

Una entrada de la tabla de seguimiento de conexiones se quita después de que la conexión estuvo inactiva durante un período determinado. A menos que configures un tiempo de espera por inactividad personalizado, el balanceador de cargas usará un valor predeterminado de 600 segundos (10 minutos).

En la siguiente tabla, se muestran los valores de tiempo de espera por inactividad configurables mínimos y máximos para diferentes combinaciones de configuración de afinidad de sesión y modo de seguimiento de conexiones.

Afinidad de sesión Modo de seguimiento de conexiones Tiempo de espera por inactividad predeterminado Tiempo de espera por inactividad mínimo configurable Tiempo de espera máximo de inactividad configurable
Cualquier tupla de conexión PER_CONNECTION 600 segundos 60 segundos 600 segundos
  • Tupla de 1 elemento (CLIENT_IP_NO_DESTINATION)
  • Tupla de 2 elementos (CLIENT_IP)
  • Tupla de 3 elementos (CLIENT_IP_PROTO)
 PER_SESSION 600 segundos 60 segundos 57,600 segundos
5 tuplas (NONE, CLIENT_IP_PORT_PROTO) PER_SESSION 600 segundos 60 segundos 600 segundos

Si deseas obtener información para cambiar el valor de tiempo de espera de inactividad, consulta Configura una política de seguimiento de conexiones.

Vaciado de conexiones para backends detenidos, borrados o quitados

El vaciado de conexiones proporciona una cantidad mínima configurable de tiempo para que las conexiones existentes persistan en la tabla de seguimiento de conexiones del balanceador de cargas cuando sucede una de las siguientes situaciones:

  • Se quita una instancia de máquina virtual (VM) de un grupo de instancias de backend (esto incluye descartar una instancia en un grupo de instancias administrado de backend).
  • Se detiene o borra una VM (esto incluye acciones automáticas, como actualizaciones continuas o la reducción del escalamiento de un grupo de instancias administrado de backend).
  • Se quita un extremo de un grupo de extremos de red (NEG) de backend

De forma predeterminada, el vaciado de conexiones cuando se quitan, detienen o borran los backends está inhabilitado. Para obtener más información, consulta Habilita el vaciado de conexiones.

Conmutación por error

La conmutación por error te permite influir en el conjunto de backends aptos para las conexiones nuevas clasificando cada grupo de instancias de backend o NEG como principal o de conmutación por error.

De forma predeterminada, cuando agregas un grupo de instancias o un NEG a un servicio de backend, las VMs o los extremos miembros son backends principales, y el grupo de instancias o el NEG es un grupo de backends principal. Con la conmutación por error, puedes agregar un grupo de backends de conmutación por error (grupo de instancias o NEG) cuyas VMs o extremos miembros sean backends de conmutación por error:

  • La conmutación por error requiere que un servicio de backend tenga al menos un grupo de backend principal y al menos un grupo de backend de conmutación por error.
  • Puedes agregar hasta 50 grupos de backend principales y 50 grupos de backend de conmutación por error a un servicio de backend.

Con la conmutación por error, los siguientes factores determinan el conjunto de servidores de backend aptos:

  • El estado de cada backend
  • La proporción de conmutación por error que configuraste
  • El parámetro de configuración Abandonar el tráfico si los backends están en mal estado

Política de conmutación por error

Cuando un servicio de backend tiene al menos un grupo de backend principal y al menos un grupo de backend de conmutación por error, puedes ajustar la siguiente configuración en su política de conmutación por error:

  • Índice de conmutación por error: Es un número entre 0.0 y 1.0, incluidos.
  • Descartar el tráfico si los backends están en mal estado: Es un valor booleano que determina el comportamiento de último recurso del balanceador de cargas. El porcentaje de conmutación por error y el parámetro de configuración Descartar tráfico si los backends no están en buen estado funcionan en conjunto con otros factores para controlar el conjunto de backends aptos.
  • Desvío de conexión en conmutación por error: Es un valor booleano que controla si las conexiones persisten en los backends seleccionados anteriormente cuando el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error.

Índice de conmutación por error

La proporción de conmutación por error configurada determina cuándo el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error. El índice puede ser un número entre 0.0 y 1.0, inclusive. Si no especificas una proporción de conmutación por error, Google Cloud usa un valor predeterminado de 0.0. Se recomienda configurar el índice de conmutación por error en un número adecuado para tu caso de uso, en lugar de basarse en este valor predeterminado.

Vaciado de conexiones en conmutación por error

El parámetro de configuración Vaciado de conexiones en la conmutación por error controla si una conexión existente persiste en una VM o un extremo de backend seleccionado previamente cuando el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error.

El vaciado de conexiones en la conmutación por error está habilitado de forma predeterminada. En la siguiente tabla, se resume si las conexiones persisten, según la opción de vaciado de conexiones en conmutación por error y el protocolo:

Opción de vaciado de conexiones en conmutación por error Comportamiento cuando el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error
Habilitados (configuración predeterminada) Todos los protocolos: Las conexiones persisten, siempre y cuando exista una entrada de tabla de seguimiento de conexión correspondiente, cuando el conjunto de backends aptos cambia entre los backends principales y de conmutación por error. Para obtener más información, consulta el paso Administra las entradas de la tabla de seguimiento de conexiones.
Inhabilitado Todos los protocolos: Las conexiones no persisten cuando el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error.

Inhabilitar el vaciado de conexiones en la conmutación por error y por recuperación es útil para las siguientes situaciones:

  • Aplica un parche a las VMs de backend. Antes de aplicar el parche, puedes configurar los backends principales en buen estado para que fallen las verificaciones de estado, de modo que los backends aptos puedan ser backends de conmutación por error en buen estado. Si se inhabilita el vaciado de conexiones en la conmutación por error y por recuperación, el balanceador de cargas quita las entradas de la tabla de seguimiento de conexiones, aplica los pasos de selección de backend a los paquetes posteriores y los entrega a un backend diferente apto. Luego, el backend diferente cierra la conexión con un restablecimiento de TCP para que las VMs cliente puedan establecer rápidamente una nueva conexión con el balanceador de cargas.

  • VM de backend única para la coherencia de datos Si necesitas asegurarte de que el conjunto de backends aptos no tenga más de una VM o un extremo miembro, inhabilitar el vaciado de conexiones en la conmutación por error y la recuperación reduce la posibilidad de que haya incoherencias en los datos.

Para obtener información sobre cómo inhabilitar el vaciado de conexiones en la conmutación por error y la recuperación, consulta Inhabilitación del vaciado de conexiones en la conmutación por error y la recuperación.

Prácticas recomendadas y orientación

Puedes optimizar el balanceador de cargas de red de transferencia interno siguiendo estos lineamientos operativos. En las siguientes secciones, se proporcionan los requisitos técnicos para administrar paquetes UDP fragmentados y las prácticas recomendadas para probar la distribución de carga desde un solo cliente.

Cómo controlar la fragmentación de UDP

Los balanceadores de cargas de red de transferencia internos pueden procesar paquetes UDP fragmentados y no fragmentados. Si tu aplicación usa paquetes UDP fragmentados, ten en cuenta lo siguiente:
  • Los paquetes UDP pueden fragmentarse antes de llegar a una red de Google CloudVPC.
  • Google Cloud Las redes de VPC reenvían fragmentos UDP a medida que llegan (sin esperar a que lleguen todos los fragmentos).
  • Las redes que no son deGoogle Cloud y el equipo de red local pueden reenviar fragmentos UDP a medida que llegan, retrasar los paquetes UDP fragmentados hasta que todos los fragmentos hayan llegado, o descartar paquetes UDP fragmentados. Para obtener más información, consulta la documentación del proveedor de red o el equipo de red.

Si esperas paquetes UDP fragmentados y necesitas enrutarlos a los mismos backends, usa la siguiente regla de reenvío y parámetros de configuración del servicio de backend:

  • Configuración de reglas de reenvío: Usa solo una regla de reenvío UDP por dirección IP con balanceo de cargas y configura la regla de reenvío para aceptar tráfico en todos los puertos. Esto garantiza que todos los fragmentos lleguen a la misma regla de reenvío. Aunque los paquetes fragmentados (que no sea el primer fragmento) no tienen un puerto de destino, configurar la regla de reenvío para procesar el tráfico en todos los puertos también la configura para recibir fragmentos UDP que no tienen información de puertos. A fin de configurar todos los puertos, usa Google Cloud CLI para configurar --ports=ALL o usa la API a fin de configurar allPorts en True.

  • Configuración del servicio de backend: establece la afinidad de sesión del servicio de backend en CLIENT_IP (hash de 2 tuplas) o CLIENT_IP_PROTO (hash de 3 tuplas), de manera que se seleccione el mismo backend para paquetes de UDP que incluyen información de puertos y fragmentos UDP (que no sean el primer fragmento) que carecen de información de puertos. Establece el modo de seguimiento de conexión del servicio de backend en PER_SESSION para que las entradas de la tabla de seguimiento de conexión se compilen mediante los mismos valores hash de 2 o 3 tuplas.

Prueba desde un solo cliente

Cuando pruebes un balanceador de cargas de red de transferencia interno desde un solo cliente, ten en cuenta lo siguiente:

  • Si la VM del cliente no es un backend del balanceador de cargas: Las conexiones nuevas se procesan como se describe en los pasos de Selección y seguimiento de la conexión de backend. En el paso Selecciona un backend apto, el balanceador de cargas crea un hash de las características del paquete según la afinidad de sesión.

    Recuerda que todas las opciones de afinidad de sesión dependen, al menos, de la dirección IP del cliente, por lo que las conexiones del mismo cliente pueden distribuirse al mismo backend apto con mayor frecuencia de lo que esperas. Por lo tanto, no puedes modelar con precisión la distribución general de las conexiones nuevas si te conectas a un balanceador de cargas de red de transferencia interno desde un solo cliente.

  • Si la VM de cliente también es una VM de backend del balanceador de cargas, el balanceador de cargas no procesa las conexiones nuevas. Los paquetes salientes con la dirección IP de destino de la regla de reenvío del balanceador de cargas se enrutan de forma local dentro del SO invitado del cliente debido a la presencia de una ruta local para la regla de reenvío.

¿Qué sigue?