Distribución del tráfico de los balanceadores de carga de red de paso a través externos

En esta página se explican los conceptos sobre cómo distribuyen el tráfico los balanceadores de carga de red de paso a través externos.

Selección de backend y seguimiento de conexiones

La selección de backend y el seguimiento de conexiones funcionan conjuntamente para equilibrar varias conexiones entre diferentes backends y para enrutar todos los paquetes de cada conexión al mismo backend. Esto se consigue con una estrategia de dos partes. Primero, se selecciona un backend mediante un hash coherente. A continuación, esta selección se registra en una tabla de seguimiento de conexiones.

En los siguientes pasos se describe el proceso de selección del backend y de seguimiento de la conexión.

1. Comprobar si hay una entrada en la tabla de seguimiento de conexiones para usar un backend seleccionado anteriormente

En una conexión ya creada, el balanceador de carga usa la tabla de seguimiento de conexiones para identificar el backend seleccionado anteriormente para esa conexión.

El balanceador de carga intenta asociar cada paquete balanceado con una entrada de su tabla de seguimiento de conexiones mediante el siguiente proceso:

  • Si el paquete es un paquete TCP con la marca SYN:

    • Si el modo de seguimiento de conexiones del balanceador de carga es PER_CONNECTION, vaya al paso Identificar los back-ends aptos. En el modo de seguimiento PER_CONNECTION, un paquete TCP con la marca SYN siempre representa una nueva conexión, independientemente de la afinidad de sesión configurada.

    • Si el modo de seguimiento de conexiones del balanceador de carga es PER_SESSION y la afinidad de sesión es NONE o CLIENT_IP_PORT_PROTO, ve al paso Identificar los back-ends aptos. En el PER_SESSIONmodo de seguimiento, un paquete TCP con la marca SYN representa una nueva conexión solo cuando se usa una de las cinco opciones de afinidad de sesión (NONE o CLIENT_IP_PORT_PROTO).

  • Si la afinidad de sesión configurada no admite el seguimiento de conexiones para el protocolo del paquete, ve al paso Identificar los back-ends aptos. Para obtener información sobre qué protocolos se pueden monitorizar, consulta la tabla de la sección Modo de monitorización de conexiones.

  • En el caso del resto de los paquetes, el balanceador de carga comprueba si el paquete coincide con una entrada de la tabla de seguimiento de conexiones. La tupla de conexión (un conjunto de características de paquetes) que se usa para comparar el paquete con las entradas de la tabla de seguimiento de conexiones depende del modo de seguimiento de conexiones y de la afinidad de sesión que hayas configurado. Para obtener información sobre qué tupla de conexión se usa para el seguimiento de conexiones, consulta la tabla de 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 carga envía el paquete al backend seleccionado anteriormente.

    • Si el paquete no coincide con ninguna entrada de la tabla de seguimiento de conexiones, vaya al paso Identificar back-ends aptos.

    Para obtener información sobre cuánto tiempo se mantiene una entrada de la tabla de seguimiento de conexiones y en qué condiciones, consulta el paso Crear una entrada de la tabla de seguimiento de conexiones.

2. Seleccionar un backend apto para una nueva conexión

En el caso de una conexión nueva, el balanceador de carga usa el algoritmo de hash coherente para seleccionar un backend de entre los backends aptos.

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

2.1 Identificar back-ends aptos

En este paso se modelan los backends que pueden recibir conexiones nuevas, teniendo en cuenta el estado, el balanceo de carga ponderado y la configuración de la política de conmutación por error.

En la siguiente tabla se describe cómo influyen la política de conmutación por error y el balanceo de carga ponderado en los backends aptos.

Política de conmutación por error Balanceo de carga ponderado Backends aptos
Consulta Sin política de conmutación por error, balanceo de carga ponderado inhabilitado.
Consulta Sin política de conmutación por error, balanceo de carga ponderado habilitado.
Consulta Política de conmutación por error configurada y balanceo de carga ponderado inhabilitado.
Consulta Política de conmutación por error configurada y balanceo de carga ponderado habilitado.

No hay política de conmutación por error y el balanceo de carga ponderado está inhabilitado

El conjunto de backends aptos solo depende de las comprobaciones de estado:

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

  • Cuando todos los backends están en mal estado, el conjunto de backends aptos está formado por todos los backends.

Sin política de conmutación por error, balanceo de carga ponderado habilitado

El conjunto de backends aptos depende tanto de las comprobaciones de estado como de los pesos, y consta del primero de los siguientes elementos que no esté vacío:

  • Todos los backends en buen estado y con un peso distinto de cero
  • Todos los backends en mal estado y con un peso distinto de cero
  • Todos los backends en buen estado y con peso cero
  • Todos los backends en mal estado y con peso cero

Política de conmutación por error configurada y balanceo de carga ponderado inhabilitado

El conjunto de backends aptos depende de las comprobaciones de estado y de la configuración de la política de conmutación por error:

  • Cuando al menos un backend está en buen estado, el conjunto de backends aptos se define de la siguiente manera, usando la primera condición que sea verdadera de esta lista ordenada:

    • Si no hay backends principales en buen estado, los backends aptos son todos los backends de conmutación por error en buen estado.
    • Si no hay backends de conmutación por error en buen estado, los backends aptos son todos los backends principales en buen estado.
    • Si el índice de conmutación por error es 0.0 (el valor predeterminado), los backends aptos son todos los backends principales en buen estado.
    • Si la proporción del número de backends principales en buen estado en comparación con el número total de backends principales es mayor o igual que la proporción de conmutación por error configurada, los backends aptos serán todos los backends principales en buen estado.
    • Los backends aptos son todos los backends de conmutación por error que estén en buen estado.

  • Cuando no hay backends en buen estado, el conjunto de backends aptos se define de la siguiente manera:

    • Si la política de conmutación por error del balanceador de carga está configurada para eliminar las nuevas conexiones cuando no haya backends en buen estado, el conjunto de backends aptos estará vacío. El balanceador de carga descarta los paquetes de las conexiones nuevas.
    • Si la política de conmutación por error del balanceador de carga no está configurada para eliminar las nuevas conexiones cuando no haya backends en buen estado, las comprobaciones de estado no serán relevantes. Los back-ends aptos son todos los back-ends principales.

Política de conmutación por error configurada y balanceo de carga ponderado habilitado

El conjunto de backends aptos depende de las comprobaciones del estado, los pesos y la configuración de la política de conmutación por error:

  • Cuando al menos un backend está en buen estado y tiene un peso distinto de cero, el conjunto de backends aptos se define de la siguiente manera, usando la primera condición que se cumpla de esta lista ordenada:

    • Si no hay backends principales en buen estado y con un peso distinto de cero, los backends aptos son todos los backends de conmutación por error en buen estado y con un peso distinto de cero.
    • Si no hay backends de conmutación por error en buen estado y con un peso distinto de cero, los backends aptos son todos los backends principales en buen estado y con un peso distinto de cero.
    • Si el índice de conmutación por error es 0.0 (el valor predeterminado), los backends aptos son todos los backends principales en buen estado y con un peso distinto de cero.
    • Si la proporción del número de backends principales en buen estado y con un peso distinto de cero en comparación con el número total de backends principales es mayor o igual que el índice de conmutación por error configurado, los backends aptos serán todos los backends principales en buen estado y con un peso distinto de cero.
    • Los backends aptos son todos los backends de conmutación por error en buen estado y con un peso distinto de cero.

  • Cuando no hay backends en buen estado con un peso distinto de cero, el conjunto de backends aptos se define de la siguiente manera:

    • Si la política de conmutación por error del balanceador de carga está configurada para eliminar las nuevas conexiones cuando no haya backends en buen estado, el conjunto de backends aptos estará vacío. El balanceador de carga descarta los paquetes de las conexiones nuevas.

    • Si la política de conmutación por error del balanceador de carga no está configurada para eliminar las nuevas conexiones cuando no haya backends en buen estado, el conjunto de backends aptos será el primero de los siguientes que no esté vacío:

      • Todos los backends principales en mal estado y con un peso distinto de cero
      • Todos los backends de failover en mal estado y con un peso distinto de cero
      • Todos los backends principales en buen estado y con peso cero
      • Todos los backends están en buen estado y ninguno tiene peso de failover
      • Todos los backends principales en mal estado y con peso cero
      • Todos los backends en mal estado y con cero peso de conmutación por error

2.2 Selecciona un backend apto

El balanceador de carga usa el hash coherente para seleccionar un backend apto. El balanceador de carga mantiene los hashes de los backends aptos, asignados a un círculo unitario. El balanceo de carga asignado por porcentajes modifica la forma en que se asignan los back-ends aptos al círculo de forma que los back-ends con porcentajes más altos tienen más probabilidades de ser seleccionados, de forma proporcional a sus porcentajes.

Cuando procesa un paquete de una conexión que no está en la tabla de seguimiento de conexiones, el balanceador de carga 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 el ajuste de afinidad de sesión.

  • Si no se configura explícitamente la afinidad de sesión, se usará la afinidad de sesión NONE de forma predeterminada.

  • En los dos ejemplos siguientes se muestra cómo afecta el balanceo de carga ponderado a la selección de un backend apto:

    • Si el servicio 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 a con un peso de 0, el backend b con un peso de 2 y el backend c con un peso de 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)).

  • El balanceador de carga asigna nuevas conexiones a los back-ends aptos de la forma más coherente posible, incluso si cambia el número de back-ends aptos o sus pesos. Las siguientes ventajas del hash coherente muestran cómo selecciona el balanceador de carga los backends aptos para posibles conexiones nuevas que no tienen entradas en la tabla de seguimiento de conexiones:

    • El balanceador de carga selecciona el mismo backend para todas las conexiones nuevas posibles que tengan características de paquete idénticas, tal como se define en la afinidad de sesión, en las siguientes situaciones:

      • Si no se configura el balanceo de carga ponderado, cuando el conjunto de backends aptos no cambie.

      • Si se configura el balanceo de carga ponderado, cuando el conjunto de back-ends aptos no cambia y el peso de cada back-end apto se mantiene constante.

    • El balanceador de carga distribuye las posibles nuevas conexiones entre los backends aptos de la forma más equitativa posible:

      • Si no se configura el balanceo de carga ponderado, se asignan aproximadamente 1/N posibles conexiones nuevas a cada backend apto, donde N es el número de backends aptos.

      • Si se configura el balanceo de carga ponderado, la proporción de posibles conexiones nuevas que se asignan a cada backend apto es aproximadamente el peso de un backend apto dividido entre la suma de los pesos de todos los backends aptos.

      • Si se añade o se quita un backend apto, o si cambia su peso, el objetivo del hash coherente es minimizar las interrupciones 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.

2.3 Crear una entrada en la tabla de seguimiento de conexiones

Después de seleccionar un backend, el balanceador de carga 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 del encabezado de paquete que se usan en esta asignación dependen del modo de seguimiento de conexiones y de la afinidad de sesión que hayas configurado.

Para obtener información sobre qué protocolos se pueden monitorizar en función de las opciones de configuración y qué características de los paquetes se usan para el hash, consulta la sección Modo de monitorización de conexiones.

El balanceador de carga elimina las entradas de la tabla de seguimiento de conexiones según las siguientes reglas:

  • Una entrada de la tabla de seguimiento de conexiones se elimina después de que la conexión haya estado inactiva durante 60 segundos. Para obtener más información, consulta Tiempo de espera por inactividad.

  • Las entradas de la tabla de seguimiento de conexiones no se eliminan cuando se cierra una conexión TCP con un paquete FIN o RST. Cualquier conexión TCP nueva siempre lleva la marca SYN y se procesa como se describe en el paso Comprobar si hay una entrada en la tabla de seguimiento de conexiones.

  • Si se configura una política de conmutación por error y se inhabilita la opción de desviación de conexiones al producirse una conmutación por error y una conmutación tras error, el balanceador de carga elimina todas las entradas de la tabla de seguimiento de conexiones cuando los backends aptos pasan de ser principales a ser de conmutación por error (conmutación por error) o de ser de conmutación por error a ser principales (conmutación tras error). Para obtener más información, consulta Desviación de conexiones al producirse una conmutación por error y una conmutación por recuperación.

  • Las entradas de la tabla de seguimiento de conexiones se pueden eliminar si un backend deja de estar en buen estado. Este comportamiento depende del modo de seguimiento de conexiones, el protocolo y el ajuste de persistencia de conexión en backends no saludables. Para obtener más información, consulta Persistencia de la conexión en back-ends incorrectos.

  • Las entradas de la tabla de seguimiento de conexiones se eliminan después del tiempo de espera de purga de la conexión que se produce tras un evento, como eliminar una VM de backend o eliminar una VM de backend de un grupo de instancias o un NEG. Para obtener más información, consulta Habilitar el drenaje de conexiones.

Afinidad de sesión

La afinidad de sesión controla la distribución de las conexiones nuevas de los clientes a los backends del balanceador de carga. Los balanceadores de carga de red de paso a través externos usan la afinidad de sesión para seleccionar un backend de un conjunto de backends aptos, tal como se describe en los pasos Identificar backends aptos y Seleccionar un backend apto de la sección Selección y seguimiento de la conexión de backend. La afinidad de sesión se configura en el servicio de backend, no en cada grupo de instancias de backend ni en cada NEG.

Los balanceadores de carga de red de paso a través externos admiten los siguientes ajustes de afinidad de sesión. Cada ajuste de afinidad de sesión usa el hash coherente para seleccionar un backend apto. El ajuste de afinidad de sesión determina qué campos de los encabezados IP y TCP/UDP se usan para calcular el hash.

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

Hash de quíntupla (compuesto por 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 no fragmentados que incluyen información de puerto, como paquetes TCP y paquetes UDP no fragmentados

OR

Hash de 3 tuplas (compuesto por 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

 NONE2

Hash de quíntupla (compuesto por 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 no fragmentados que incluyen información de puerto, como paquetes TCP y paquetes UDP no fragmentados

OR

Hash de 3 tuplas (compuesto por 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

 CLIENT_IP_PORT_PROTO
Hash de 3 tuplas
(formado por la dirección IP de origen, la dirección IP de destino y el protocolo)		 CLIENT_IP_PROTO
Hash de 2 tuplas
(formado por la dirección IP de origen y la dirección IP de destino)		 CLIENT_IP
1 Estos tipos de afinidad de sesión se admiten en los balanceadores de carga de red de paso a través externos basados en servicios de backend. Los balanceadores de carga de red de paso a través externos basados en grupos de destino no usan servicios de backend y admiten menos opciones de afinidad de sesión. En el caso de los balanceadores de carga de red de paso a través externos basados en grupos de destino, debes definir el parámetro session affinity en cada grupo de destino.

2 Si el ajuste de afinidad de sesión es NONE, no significa que no haya afinidad de sesión. Esto significa que no se ha configurado ninguna opción de afinidad de sesión de forma explícita.

El hashing siempre se realiza para seleccionar un backend. Si el valor de afinidad de sesión es NONE, el balanceador de carga usa un hash de 5 tuplas o de 3 tuplas para seleccionar los back-ends, lo que equivale a usar el valor CLIENT_IP_PORT_PROTO.

Para obtener información sobre cómo afectan los diferentes ajustes de afinidad de sesión a los métodos de selección de backend y de seguimiento de conexiones, consulta la tabla de la sección Modo de seguimiento de conexiones.

Política de seguimiento de conexiones

En esta sección se describen los ajustes que controlan el comportamiento del seguimiento de conexiones de los balanceadores de carga de red de paso a través externos. Una política de seguimiento de conexiones incluye los siguientes ajustes:

Modo de seguimiento de la conexión

Cuando se puede hacer un seguimiento de las conexiones, la tabla de seguimiento de conexiones del balanceador de carga asigna tuplas de conexión a backends seleccionados anteriormente en una tabla hash. El conjunto de características de los paquetes que componen cada tupla de conexión depende del modo de seguimiento de la conexión y de la afinidad de sesión.

Los balanceadores de carga de red de paso a través externos admiten el seguimiento de conexiones basado en el protocolo y las opciones de afinidad de sesión:

  • Las conexiones TCP siempre se pueden monitorizar, independientemente de la opción de afinidad de sesión que se elija.

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

  • El resto de los protocolos, como ICMP e ICMPv6, no se pueden monitorizar.

El modo de seguimiento de conexiones hace referencia a la granularidad de cada tupla de conexión en la tabla de seguimiento de conexiones del balanceador de carga. La tupla de conexión puede ser de 5 o 3 elementos (modo PER_CONNECTION) o puede coincidir con el ajuste de afinidad de sesión (modo PER_SESSION).

  • PER_CONNECTION. Este es el modo de seguimiento de conexiones predeterminado. Este modo de seguimiento de conexiones usa un hash de 5 tuplas o un hash de 3 tuplas. Los paquetes no fragmentados que incluyen información de puertos, como los paquetes TCP y los paquetes UDP no fragmentados, se monitorizan con hashes de 5 tuplas. El resto de los paquetes se monitorizan con hashes de tuplas de 3 elementos.

  • PER_SESSION. Este modo de seguimiento de conexiones usa un hash que consta de las mismas características de paquete que el hash de afinidad de sesión. En función de la afinidad de sesión elegida, PER_SESSION puede dar lugar a conexiones que coincidan con más frecuencia con una entrada de tabla de seguimiento de conexiones, lo que reduce la frecuencia con la que el backend debe seleccionarse mediante el hash de afinidad de sesión.

En la siguiente tabla se resume cómo funcionan conjuntamente el modo de seguimiento de conexiones y la afinidad de sesión para enrutar todos los paquetes de cada conexión al mismo backend.

Selección de backend mediante la afinidad de sesión Modo de seguimiento de la conexión
Ajuste de afinidad de sesión Método de hash para la selección de backend PER_CONNECTION (predeterminado) PER_SESSION
Predeterminado

(NONE)

TCP y UDP sin fragmentar: hash de 5 tuplas

UDP fragmentado y todos los demás protocolos: hash de 3 tuplas
  • TCP: seguimiento de conexiones de 5 tuplas
  • Otros protocolos: seguimiento de conexiones desactivado
  • TCP seguimiento de conexiones de 5 tuplas
  • Otros protocolos: seguimiento de conexiones desactivado
IP de cliente e IP de destino

(CLIENT_IP)

 Todos los protocolos: hash de 2 tuplas
  • TCP y UDP sin fragmentar: seguimiento de conexiones de 5 tuplas
  • UDP, ESP y GRE fragmentados: seguimiento de conexiones de 3 tuplas
  • Otros protocolos: seguimiento de conexiones desactivado
  • TCP, UDP, ESP y GRE: seguimiento de conexiones de 2 tuplas
  • Otros protocolos: seguimiento de conexiones desactivado
IP de cliente, IP de destino y protocolo

(CLIENT_IP_PROTO)

 Todos los protocolos: hash de tupla de 3 elementos
  • TCP y UDP sin fragmentar: seguimiento de conexiones de 5 tuplas
  • UDP, ESP y GRE fragmentados: seguimiento de conexiones de 3 tuplas
  • Otros protocolos: seguimiento de conexiones desactivado
  • TCP, UDP, ESP y GRE: seguimiento de conexiones de 3 tuplas
  • Otros protocolos: seguimiento de conexiones desactivado
IP de cliente, puerto de cliente, IP de destino, puerto de destino y protocolo

(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 conexiones de 5 tuplas
  • UDP, ESP y GRE fragmentados: seguimiento de conexiones de 3 tuplas
  • Otros protocolos: seguimiento de conexiones desactivado
  • TCP y UDP sin fragmentar: seguimiento de conexiones de 5 tuplas
  • UDP, ESP y GRE fragmentados: seguimiento de conexiones de 3 tuplas
  • Otros protocolos: seguimiento de conexiones desactivado

Para saber cómo cambiar el modo de seguimiento de conexiones, consulta Configurar una política de seguimiento de conexiones.

Persistencia de la conexión en backends en mal estado

Los ajustes de persistencia de la conexión controlan si una conexión ya establecida persiste en una VM o un endpoint de backend seleccionados después de que ese backend deje de estar en buen estado, siempre que el backend permanezca en el grupo de backend configurado del balanceador de carga (en un grupo de instancias o en un NEG).

Estas son las opciones de persistencia de la conexión disponibles:

  • DEFAULT_FOR_PROTOCOL (predeterminado)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

En la siguiente tabla se resumen las opciones de persistencia de la conexión y cómo persisten las conexiones en diferentes protocolos, opciones de afinidad de sesión y modos de seguimiento.

Opción de persistencia de conexiones en backends en mal estado Modo de seguimiento de la conexión
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: las conexiones persisten en back-ends incorrectos (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 los back-ends incorrectos si la afinidad de sesión es NONE o CLIENT_IP_PORT_PROTO.

Otros 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

TCP: las conexiones persisten en back-ends incorrectos (todas las afinidades de sesión)

ESP, GRE y UDP: las conexiones persisten en back-ends no saludables si la afinidad de sesión no es NONE.

ICMP e ICMPv6: no se aplican porque no se pueden rastrear las conexiones.

Esta opción solo se debe usar en casos prácticos avanzados.

 No se puede configurar

Comportamiento de persistencia de conexiones TCP en backends en mal estado

Siempre que una conexión TCP con seguimiento de 5 tuplas persista en un backend no operativo:

  • Si el backend en mal estado sigue respondiendo a los paquetes, la conexión continuará hasta que se restablezca o se cierre (ya sea por el backend en mal estado o por el cliente).
  • Si el backend en mal estado envía un paquete de restablecimiento (RST) de TCP o no responde a los paquetes, el cliente puede volver a intentarlo con una nueva conexión, lo que permite que el balanceador de carga seleccione otro backend en buen estado. Los paquetes SYN de TCP siempre seleccionan un backend nuevo y en buen estado.

Para saber cómo cambiar el comportamiento de persistencia de la conexión, consulta Configurar una política de seguimiento de conexiones.

Tiempo de espera de inactividad

Las entradas de las tablas de seguimiento de conexiones caducan 60 segundos después de que el balanceador de carga procese el último paquete que coincida con la entrada. Este valor de tiempo de espera inactivo no se puede modificar.

Balanceo de carga ponderado

El balanceo de carga ponderado de los balanceadores de carga de red de paso a través externos usa la información de peso que proporciona una comprobación del estado HTTP. Para usar el balanceo de carga ponderado, debe configurar lo siguiente:

  • La política de localidad del balanceador de carga del servicio de backend (localityLbPolicy) debe ser WEIGHTED_MAGLEV.
  • El servicio de backend debe usar una comprobación del estado HTTP.
  • Las respuestas de comprobación de estado de cada VM de backend o punto final de backend deben contener un encabezado de respuesta HTTP personalizado. El nombre del campo del encabezado de respuesta es X-Load-Balancing-Endpoint-Weight y los valores de campo válidos van de 0 a 1000.

Si necesitas usar el mismo grupo de instancias o NEG como backend de dos o más servicios de backend, te recomendamos que sigas esta estrategia para que cada una de las instancias o los endpoints de backend comunes puedan proporcionar información de peso única para cada servicio de backend:

  • Usa una comprobación de estado HTTP única para cada servicio de backend. Por ejemplo, usa un parámetro de comprobación del estado request-path único.
  • Configura las instancias o los endpoints de backend para que respondan con la información de peso adecuada en cada comprobación de estado.

Cuando se usa el balanceo de carga ponderado, el balanceador de carga clasifica las VMs o los endpoints de backend primero en función de si tienen un peso superior a cero o igual a cero y, después, en función de las comprobaciones de estado. El estado de la comprobación del estado se determina en función de los criterios de éxito de las comprobaciones del estado HTTP, HTTPS y HTTP/2.

Ponderación Saludable o poco saludable Clasificación
Ponderación mayor que cero Buen estado Primera opción
Ponderación mayor que cero Mal estado Segunda opción
El peso es igual a cero Buen estado Tercera opción
El peso es igual a cero Mal estado Cuarta (última) opción

Para obtener más información sobre cómo influye el balanceo de carga ponderado en los backends aptos, consulta los pasos Identificar los backends aptos y Seleccionar un backend apto en la sección Selección de backend y seguimiento de conexiones.

El balanceo de carga ponderado se puede usar en los siguientes casos:

  • Si algunas conexiones procesan más datos que otras o si algunas conexiones duran más que otras, la distribución de la carga del backend puede volverse desigual. Al indicar un peso por instancia inferior, una instancia con una carga elevada puede reducir su parte de las conexiones nuevas, mientras sigue atendiendo las conexiones existentes.

  • Si un backend está sobrecargado y asignar más conexiones puede interrumpir las conexiones existentes, estos backends se asignan un peso cero. Al señalar un peso cero, una instancia de backend deja de atender nuevas conexiones, pero sigue atendiendo las que ya tiene.

  • Si un backend está agotando las conexiones antes del mantenimiento, se asigna un peso cero. Al indicar que el peso es cero, la instancia de backend deja de atender nuevas conexiones, pero sigue atendiendo las que ya tiene.

Para obtener más información, consulta Configurar el balanceo de carga ponderado.

Purga de conexión

La desviación de conexiones proporciona una cantidad configurable de tiempo adicional para que las conexiones establecidas persistan en la tabla de seguimiento de conexiones del balanceador de carga cuando se produce una de las siguientes acciones:

  • Se elimina una instancia de máquina virtual de un grupo de instancias de backend (esto incluye abandonar una instancia en un grupo de instancias gestionado de backend)
  • Se detiene o se elimina una VM (esto incluye acciones automáticas como la implementación gradual de actualizaciones o la reducción del tamaño de un grupo de instancias gestionado de backend)
  • Se elimina un endpoint de un grupo de endpoints de red (NEG) de backend

De forma predeterminada, el vaciado de conexiones de las acciones mencionadas está inhabilitado. Para obtener información sobre cómo se activa el drenaje de conexiones y cómo habilitarlo, consulta el artículo Habilitar el drenaje de conexiones.

Fragmentación de UDP

Los balanceadores de carga de red de paso a través 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 VPC. Google Cloud
  • 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 sonGoogle Cloud y los equipos de red on-premise pueden reenviar fragmentos UDP a medida que llegan, retrasar los paquetes UDP fragmentados hasta que hayan llegado todos los fragmentos o descartar los paquetes UDP fragmentados. Para obtener más información, consulta la documentación del proveedor de la red o del equipo de red.

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

  • Configuración de la regla de reenvío: usa solo una regla de reenvío UDP o L3_DEFAULT por dirección IP con balanceo de carga y configura la regla de reenvío para que acepte tráfico en todos los puertos. De esta forma, todos los fragmentos llegan a la misma regla de reenvío. Aunque los paquetes fragmentados (excepto el primer fragmento) no tienen un puerto de destino, al configurar la regla de reenvío para procesar el tráfico de todos los puertos, también se configura para recibir fragmentos UDP que no tienen información de puerto. Para configurar todos los puertos, usa la interfaz de línea de comandos de Google Cloud para definir --ports=ALL o usa la API para definir allPorts en True.

  • Configuración del servicio de backend: asigna el valor CLIENT_IP (hash de 2 tuplas) o CLIENT_IP_PROTO (hash de 3 tuplas) a la afinidad de sesión del servicio de backend para que se seleccione el mismo backend para los paquetes UDP que incluyan información de puerto y los fragmentos UDP (excepto el primer fragmento) que no incluyan información de puerto. Define el modo de seguimiento de conexiones del servicio de backend como PER_SESSION para que las entradas de la tabla de seguimiento de conexiones se creen con los mismos hashes de tupla de 2 o 3 elementos.

Conmutación por error

Puedes configurar un balanceador de carga de red de pases externo para distribuir las conexiones entre las instancias de VM o los endpoints de los backends principales (grupos de instancias o NEGs) y, a continuación, cambiar a los backends de conmutación por error si es necesario. La conmutación por error es otro método para aumentar la disponibilidad, además de ofrecerte más control sobre cómo gestionar tu carga de trabajo cuando tus back-ends principales no están en buen estado.

De forma predeterminada, cuando añades un backend al servicio de backend de un balanceador de carga de red de pases externo, ese backend es un backend principal. Puedes designar un backend como backend de failover cuando lo añadas al servicio de backend del balanceador de carga o editando el servicio de backend más adelante.

Para obtener más información sobre cómo se usa la conmutación por error para seleccionar el backend y hacer un seguimiento de las conexiones, consulta los pasos Identificar los backends aptos y Crear una entrada en la tabla de seguimiento de conexiones de la sección Selección de backend y seguimiento de conexiones.

Para obtener más información sobre cómo funciona la conmutación por error, consulta el artículo sobre la conmutación por error de los balanceadores de carga de red de transferencia externa.

Siguientes pasos