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

En esta página, se explican los conceptos sobre cómo los balanceadores de cargas de red de transferencia externos 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 y si está habilitado el balanceo de cargas ponderado.

Política de conmutación por error Balanceo de cargas ponderado Backends aptos

Cuando no se configura ninguna política de conmutación por error y se inhabilita el balanceo de cargas ponderado, 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 no se configura ninguna política de conmutación por error y se habilita el balanceo de cargas ponderado, los backends aptos son aquellos que provienen del primero de los siguientes conjuntos que no está vacío:

  • Todos los backends en buen estado con un peso distinto de cero
  • Todos los backends en mal estado con un peso distinto de cero
  • Todos los backends en buen estado con ponderación cero
  • Todos los backends en mal estado con ponderación cero

Cuando se configura una política de conmutación por error y se inhabilita el balanceo de cargas ponderado, 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.

Cuando se configura una política de conmutación por error y se habilita el balanceo de cargas ponderado, el balanceador de cargas usa la información de peso, la información de 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 con un peso distinto de cero (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 el conjunto de backends principales en buen estado con un peso distinto de cero está vacío, los backends aptos son todos los backends de conmutación por error en buen estado con un peso distinto de cero.
    2. Si el conjunto de backends secundarios en buen estado con peso distinto de cero está vacío, los backends aptos son todos los backends principales en buen estado con peso distinto de cero.
    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 con un peso distinto de cero.
    4. Si la proporción de la cantidad de backends principales en buen estado con una ponderación distinta de cero 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 con una ponderación distinta de cero.
    5. Los backends aptos constan de todos los backends de conmutación por error en buen estado con ponderación distinta de cero.
  • Cuando no hay backends en buen estado con un peso distinto de cero (primarios y de conmutación por error), el conjunto de backends aptos depende 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 no hay backends principales ni de conmutación por error en buen estado y con un peso distinto de cero, el conjunto de backends aptos estará 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 no hay backends principales ni de conmutación por error en buen estado y con un peso distinto de cero, los backends aptos son aquellos que provienen del primero de los siguientes conjuntos que no esté vacío:
      1. Todos los backends principales en mal estado con un peso distinto de cero
      2. Todos los backends de conmutación por error en mal estado con un peso distinto de cero
      3. Todos los backends principales en buen estado con peso cero
      4. Todos los backends de conmutación por error en buen estado con peso cero
      5. Todos los backends principales en mal estado con peso cero
      6. Todos los backends de conmutación por error en mal estado con peso cero

2.2 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. El balanceo de cargas ponderado altera la forma en que los backends aptos se asignan al círculo, de modo que es más probable que se seleccionen los backends con pesos más altos, de forma proporcional a sus pesos.

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 del mapeo, incluso si cambia la cantidad de backends aptos o sus pesos.

    • 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, en las siguientes situaciones:

      • Si no se configura el balanceo de cargas ponderado, cuando el conjunto de backends aptos no cambia

      • Si se configura el balanceo de cargas ponderado, cuando el conjunto de backends aptos no cambia y el peso de cada backend apto permanece constante.

    • Si se agrega o quita un backend apto, o se cambia su peso, 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):

    • Si no se configura el balanceo de cargas ponderado, aproximadamente 1/N hashes de paquetes posibles se asignan a cada backend apto, donde N es el recuento de backends aptos.

    • Si se configura el balanceo de cargas ponderado, la proporción de hashes de paquetes posibles que se asignan a cada backend apto es aproximadamente la siguiente: la ponderación de un backend apto dividida por la suma de todas las ponderaciones de los backends aptos.

  • En los siguientes dos ejemplos, se muestra cómo el balanceo de cargas ponderado afecta las probabilidades de selección de cada backend apto:

    • Si el servicio de backend tiene dos backends aptos (el primero con un peso de 1 y el segundo con un peso de 4), el primer backend apto tiene una probabilidad de selección del 20% (1÷(1+4)), y el segundo backend apto tiene una probabilidad de selección del 80% (4÷(1+4)).

    • Si el servicio de backend tiene tres backends aptos (el backend apto a con peso 0, el backend apto b con peso 2 y el backend apto c con peso 6), el backend a tiene una probabilidad de selección del 0% (0÷(0+2+6)), el backend b tiene una probabilidad de selección del 25% (2÷(0+2+6)) y el backend c tiene una probabilidad de selección del 75% (6÷(0+2+6)).

2.3 Crea una entrada de tabla de seguimiento de la conexión

Después de seleccionar un backend, el balanceador de cargas crea una entrada en la tabla de seguimiento de conexiones si la afinidad de sesión configurada admite el seguimiento de conexiones para el protocolo del paquete.

  • Si la afinidad de sesión configurada no admite el seguimiento de conexiones para el protocolo del paquete, omite este paso.

  • Si la afinidad de sesión configurada admite el seguimiento de conexiones para el protocolo del paquete, la entrada de la tabla de seguimiento de conexiones que se crea 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 conexión y de la afinidad de sesión que configuraste.

Para obtener información sobre qué protocolos se pueden rastrear según tus opciones de configuración y qué características de paquetes se usan para el hash en la tabla de seguimiento de conexiones, consulta la tabla en la sección Modo de seguimiento de conexiones.

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 conexión después de que la conexión estuvo inactiva durante 60 segundos. Para obtener más información, consulta Tiempo de espera por inactividad.

  • 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 externo 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 externos 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

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.

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 cuándo y cómo el balanceador de cargas crea entradas en su tabla de seguimiento de conexiones. Los balanceadores de cargas de red de transferencia externos admiten el seguimiento de conexiones basado en el protocolo y la afinidad de sesión:

  • Las conexiones TCP siempre se pueden rastrear, para todas las opciones de afinidad de sesión.

  • Las conexiones UDP, ESP y GRE se pueden rastrear para todas las opciones de afinidad de sesión excepto NONE.

  • Todos los demás protocolos, como ICMP y ICMPv6, no son rastreables por conexión.

Cuando es posible el seguimiento de conexiones, el modo de seguimiento de conexiones, 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 conexiones.

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)
  • TCP y UDP sin fragmentar: Hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Hash de 3 tuplas
  • TCP: Seguimiento de conexión activado, hash de 5 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP: Seguimiento de conexión activado, hash de 5 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
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, ESP y GRE: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP y UDP sin fragmentar: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado, ESP y GRE: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
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, ESP y GRE: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP, UDP, ESP, GRE: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
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, ESP y GRE: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP, UDP, ESP, GRE: Seguimiento de conexión activado, hash de 2 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado

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: Las conexiones persisten en backends en mal estado (todas las afinidades de sesión).
  • ESP, GRE, UDP: Las conexiones persisten en backends en mal estado si la afinidad de sesión no es NONE.
  • Todos los demás protocolos: No aplicable porque no se puede realizar un seguimiento de la conexió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

Las entradas de las tablas de seguimiento de conexiones vencen 60 segundos después de que el balanceador de cargas procesa el último paquete que coincidió con la entrada. No se puede modificar este valor de tiempo de espera de inactividad.

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.

Balanceo de cargas ponderado

El balanceo de cargas ponderado influye en qué backends son aptos en los pasos de selección de backend. Cada VM o extremo de backend informa su peso al balanceador de cargas a través de una verificación de estado HTTP y un encabezado de respuesta personalizado. Para usar el balanceo de cargas ponderado, debes configurar lo siguiente en el servicio de backend del balanceador de cargas:

  • La política de localidad (localityLbPolicy) debe establecerse en WEIGHTED_MAGLEV.

  • La verificación de estado debe ser una verificación de estado HTTP que envíe un encabezado de respuesta especial:

    • El nombre del campo del encabezado de respuesta debe ser X-Load-Balancing-Endpoint-Weight.
    • Los valores de los campos del encabezado de respuesta pueden variar de 0 a 1000, inclusive.

Para obtener más información, consulta Configura el balanceo de cargas ponderado.

Consideraciones para el balanceo de cargas ponderado

El balanceo de cargas ponderado es útil en las siguientes situaciones, que permiten que un backend siga procesando sus conexiones existentes:

  • El balanceo de cargas ponderado permite que un backend que procesa conexiones de larga duración o conexiones que involucran grandes cantidades de datos le indique al balanceador de cargas que reduzca la cantidad de conexiones nuevas que recibe.

  • El balanceo de cargas ponderado permite que un backend sobrecargado o en mantenimiento se quite de los backends aptos para conexiones nuevas. Para ello, el backend sobrecargado envía el encabezado de respuesta X-Load-Balancing-Endpoint-Weight: 0 (y puede seguir pasando o fallando la verificación de estado del balanceador de cargas). Esto funciona porque todos los backends con un peso distinto de cero (independientemente del estado de la verificación de estado) son backends aptos más convenientes en el paso Identifica los backends aptos.

Ten en cuenta lo siguiente cuando uses el balanceo de cargas:

  • Si los backends aptos cambian sus pesos con frecuencia, el balanceo de cargas ponderado puede ser perjudicial para la afinidad de sesión. Para obtener más información, consulta el paso Selecciona un backend apto.

  • Si usas el mismo grupo de instancias o NEG como backend de dos o más servicios de backend del balanceador de cargas, puedes informar un peso único para cada servicio de backend con la siguiente estrategia:

    • Usa una verificación de estado HTTP única para cada servicio de backend. Cada verificación de estado puede usar un puerto de destino o un parámetro request-path únicos.

    • Configura instancias o extremos de backend para que respondan con la información de peso adecuada para cada verificación de estado.

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
  • Si usas la conmutación por error por sí sola o junto con el balanceo de cargas ponderado

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)
  • Protocolos con seguimiento de conexión: Las conexiones persisten mientras exista una entrada correspondiente en la tabla de seguimiento de conexiones cuando el conjunto de backends aptos cambia entre 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.
  • Protocolos que no se pueden rastrear por conexión: Las conexiones no persisten cuando el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error.

Para obtener información sobre qué protocolos se pueden hacer un seguimiento de la conexión, consulta la tabla en la sección Modo de seguimiento de la conexión.
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 con un peso distinto de cero para que fallen las verificaciones de estado o puedes establecer sus pesos en cero. De esta manera, los backends aptos pueden ser backends de conmutación por error en buen estado con un peso distinto de cero. 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 externo 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 externos basados en servicios de backend 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 o L3_DEFAULT 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 externo 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 externo 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?