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

Los balanceadores de cargas de red de transferencia distribuyen el tráfico entrante entre las instancias de backend disponibles. En este documento, se explica cómo el balanceador de cargas selecciona backends, hace un seguimiento de las conexiones y administra la afinidad de sesión, el balanceo de cargas ponderado y la conmutación por error.

Comprender cómo funcionan todas estas funciones en conjunto te ayuda a optimizar la configuración del balanceo de cargas para obtener un rendimiento confiable y un uso eficiente de los recursos. Estos mecanismos son fundamentales para las aplicaciones que requieren persistencia de sesión, ya que les permiten mantener un comportamiento coherente para cada interacción del usuario.

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 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. Cómo verificar si hay una entrada en la tabla de seguimiento de conexiones

El balanceador de cargas determina si un paquete con balanceo de cargas 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 conexiones 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 de la tabla de seguimiento de conexiones existente. 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 conexión.

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

    • 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, consulta el paso Administra las entradas de la tabla de seguimiento de conexiones.

2. Pasos para seleccionar el 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 backends aptos

Los backends que cumplen con los requisitos son los backends que pueden recibir conexiones nuevas. En la siguiente tabla, se define el conjunto de backends aptos según si el balanceador de cargas usa la conmutación por error y si el balanceo de cargas ponderado está habilitado.

Conmutación por error Balanceo de cargas ponderado Backends aptos

Cuando se inhabilitan las funciones de conmutación por error y 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 se inhabilita la función de balanceo de cargas de conmutación por error y se habilita la función de balanceo de cargas ponderado, los backends aptos son los que provienen del primero de los siguientes conjuntos que no está vacío:

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

Cuando se habilita la función de balanceo de cargas por conmutación por error y se inhabilita la función de 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 los que provienen del primero de los siguientes conjuntos 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 que cumplen con los requisitos consisten en todos los backends principales en buen estado.
    5. Los backends aptos consisten en todos los backends de conmutación por error en buen estado.
  • Cuando no hay backends en buen estado (principal 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 elegibles está vacío. Por lo tanto, el balanceador de cargas descarta los paquetes de 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 elegibles son todos los backends principales en mal estado.

Cuando se habilitan las funciones de conmutación por error y 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 peso distinto de cero (principal o de conmutación por error) está en buen estado, los backends aptos son los que provienen del primero de los siguientes conjuntos que no está vacío:
    1. Si el conjunto de backends principales en buen estado con ponderación distinta de cero está vacío, los backends aptos son todos los backends de conmutación por error en buen estado con ponderación distinta de cero.
    2. Si el conjunto de backends de conmutación por error 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 peso distinto de cero.
    4. Si la proporción de la cantidad de backends principales en buen estado con 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 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 peso distinto de cero (principales 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 con un peso distinto de cero, el conjunto de backends elegibles estará vacío. En consecuencia, el balanceador de cargas descarta los paquetes de las conexiones nuevas.
    • Si la política de conmutación por error no está configurada para descartar conexiones nuevas cuando no hay backends principales y de conmutación por error en buen estado con peso distinto de cero, los backends elegibles son los 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 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 ponderación 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 se 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, lo que selecciona 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 de forma explícita una afinidad de sesión, la afinidad de sesión NONE es la predeterminada.

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

    • El balanceador de cargas siempre selecciona el mismo backend apto para una conexión y, de manera más general, siempre selecciona el mismo backend apto para todos los paquetes con características idénticas, según lo define la 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 la ponderación de cada backend apto permanece constante.

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

  • 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 (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, en el que 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 igual a 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 ponderación 0, el backend apto b con ponderación 2 y el backend apto c con ponderación 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 conexiones

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 combinación de protocolo y afinidad de sesión no admite el seguimiento de conexiones, 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 los 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, si la combinación de protocolo y afinidad de sesión admite el seguimiento de conexiones, según los siguientes eventos y reglas:

  • Se quitan las entradas inactivas: Una entrada de la tabla de seguimiento de conexión se quita después de 60 segundos si un Maglev no procesa paquetes entrantes nuevos. 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 una 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.

  • Cuando las conexiones no persisten en la conmutación por error: Cuando se configura al menos un backend de conmutación por error y la configuración de vaciado de conexiones en la conmutación por error está inhabilitada, el balanceador de cargas quita todas las entradas de la tabla de seguimiento de conexiones después de que el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error, sujeto a las siguientes reglas:

    • El balanceador de cargas no quita de forma proactiva las entradas de la tabla de seguimiento de conexiones en el momento en que el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error. En su lugar, el balanceador de cargas quita cada entrada de la tabla de seguimiento de conexiones cuando llega un paquete siguiente para la conexión, siempre que el conjunto de backends aptos no haya vuelto a cambiar.

    • Si el conjunto de backends elegibles cambia entre los backends principales y de conmutación por error, y viceversa (por ejemplo, de principal a conmutación por error y, luego, de vuelta a principal), y no llegaron paquetes para la conexión entre los eventos de cambio, se conserva la entrada de la tabla de seguimiento de conexiones, a menos que otro motivo o evento quite la entrada de la tabla de seguimiento de conexiones.

    Para obtener más información, consulta Vaciado de conexiones en la conmutación por error.

  • Cuando las conexiones no persisten en backends en mal estado: cuando la persistencia de la conexión en backends en mal estado está inhabilitada para el protocolo del paquete, el balanceador de cargas quita las entradas de la tabla de seguimiento de conexiones en backends en mal estado según las siguientes reglas:

    • El balanceador de cargas no quita de forma proactiva las entradas de la tabla de seguimiento de conexiones a un backend seleccionado anteriormente en el momento en que el backend deja de estar en buen estado. En su lugar, el balanceador de cargas quita una entrada de la tabla de seguimiento de conexiones cuando llega un paquete siguiente para la conexión, siempre que el backend seleccionado previamente permanezca en mal estado. Los paquetes posteriores de la conexión se tratan como una conexión nueva, ya que el balanceador de cargas selecciona un backend que cumple con los requisitos nuevo y crea una entrada nueva en la tabla de seguimiento de conexiones.

    • Si un backend seleccionado previamente cambia de buen estado a mal estado y, luego, vuelve a buen estado, y no llegaron paquetes para la conexión mientras el backend seleccionado previamente estaba en mal estado, se conserva la entrada de la tabla de seguimiento de conexiones, a menos que otro motivo o evento quite la entrada 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 de vaciado de conexiones configurable. El conteo para el tiempo de espera comienza cuando se recibe el comando para quitar (abandonar), detener o borrar un backend (incluidos los comandos de borrado que son el resultado de la reducción del grupo de instancias administrado). 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

La configuración de afinidad de sesión de un balanceador de cargas de red de transferencia externo regional 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 de los paquetes. 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 regionales 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 (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 tuplas o un hash de 3 tuplas de características de paquetes, lo que, en términos funcionales, 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 regionales admiten el seguimiento de conexiones según 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. Para la afinidad de sesión NONE, no se puede hacer un seguimiento de las conexiones de estos protocolos.

  • No se puede hacer un seguimiento de conexiones de todos los demás protocolos, como ICMP y ICMPv6, para todas las opciones de afinidad de sesión.

Cuando es posible realizar el seguimiento de conexiones, el modo de seguimiento de conexiones, el protocolo y la afinidad de sesión determinan el conjunto de características de los paquetes que se usan para crear el hash de paquetes 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 registran con hashes de 5 tuplas. Todos los demás paquetes se registran 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 conexión para fines de 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 de backend.

En la siguiente tabla, se resume lo siguiente:

  • Los hashes de paquetes que se usan para la selección de backend
  • 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 paquetes 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 conexiones 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 no fragmentado: 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 no fragmentado: 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 no fragmentado: 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 conexiones 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 no fragmentado: 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 persistencia de la conexión en backends en mal estado controla si las conexiones existentes pueden conservarse en una VM de backend seleccionada previamente si la VM seleccionada previamente tiene un estado incorrecto. La persistencia de la conexión en backends en mal estado requiere que la VM de backend siga siendo miembro de un grupo de instancias o NEG con balanceo de cargas, y que la combinación de protocolo y afinidad de sesión admita el seguimiento de conexiones.

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 describe el comportamiento de la persistencia de la conexión en backends en mal estado según la opción de persistencia de la conexión en backends en mal estado, el modo de seguimiento de conexiones, la afinidad de sesión 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 (afinidades de sesión NONE y CLIENT_IP_PORT_PROTO): Las conexiones persisten en backends en mal estado, sujetas a los otros eventos y reglas del paso administrar entradas de la tabla de seguimiento de conexiones.
  • TCP (todas las demás afinidades de sesión) y todos los demás protocolos: Las conexiones no persisten en backends en mal estado.
NEVER_PERSIST Todos los protocolos: Las conexiones no persisten en backends en mal estado.
ALWAYS_PERSIST

Esta opción solo se debe usar para casos de uso avanzados.
  • TCP (todas las afinidades de sesión); ESP, GRE, UDP (todas las afinidades de sesión excepto NONE): Las conexiones persisten en backends en mal estado, sujetas a los demás eventos y reglas del paso Administra las entradas de la tabla de seguimiento de conexiones.
  • ESP, GRE, UDP (afinidad de sesión NONE): No aplicable porque no se puede realizar un seguimiento de la conexión.
 No es posible realizar la configuración.

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 de hash de 5 tuplas para las conexiones TCP en estas 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 conexión 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 por el cliente).
  • Si el backend en mal estado envía un paquete de restablecimiento de TCP (RST) o no responde a los paquetes, es posible que el cliente vuelva a intentarlo con una conexión nueva, lo que permite que el balanceador de cargas seleccione un backend apto diferente. (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 quitados, detenidos o borrados

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

  • Se quita una instancia de máquina virtual (VM) de un grupo de instancias de backend (esto incluye abandonar 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 de la escala verticalmente 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 con 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 que entra 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 peso distinto de cero (sin importar el estado de la verificación de estado) son backends aptos más preferibles en el paso Identifica los backends aptos.

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

  • Si los backends aptos cambian sus ponderaciones 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 único o un parámetro request-path.

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

Conmutación por error

La función de conmutación por error te permite influir en el conjunto de backends aptos clasificando los grupos de instancias de backend o los NEG y sus extremos de la siguiente manera:

  • Los backends principales son VMs o extremos en un grupo de instancias o NEG que se configura como un grupo de backends principal.
  • Los backends de conmutación por error son VMs o extremos en un grupo de instancias o NEG que se configura como un grupo de backends de conmutación por error.

De forma predeterminada, cuando agregas un grupo de instancias o un NEG a un servicio de backend, el grupo de instancias o el NEG es un grupo de backend principal. Puedes agregar hasta 50 grupos de backend principales y 50 grupos de backend de conmutación por error a un servicio de backend.

Para habilitar la función de conmutación por error, debes configurar el servicio de backend del balanceador de cargas con lo siguiente:

  • Al menos un grupo de backends principal que no esté vacío
  • Al menos un grupo de backends de conmutación por error no vacío

Cuando la conmutación por error está habilitada, los siguientes factores determinan el conjunto de backends aptos:

  • El estado de cada backend
  • La proporción de conmutación por error en la política de conmutación por error
  • El parámetro de configuración Descarta el tráfico si los backends están en mal estado en la política de conmutación por error
  • 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

Puedes ajustar los siguientes parámetros de configuración en la política de conmutación por error de un servicio de backend. La política de conmutación por error solo es relevante si la conmutación por error está habilitada.

  • Proporción de conmutación por error: Es un número entre 0.0 y 1.0, inclusive.
  • 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 el tráfico si los backends no están en buen estado funcionan en conjunto con otros factores para controlar el conjunto de backends aptos.
  • Vaciado de conexiones en la conmutación por error: Es un valor booleano que controla si las conexiones persisten en los backends seleccionados con anterioridad 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 determina cuándo el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error. La proporción 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 establecer la proporción de conmutación por error en un número que funcione para tu caso de uso en lugar de depender de este valor predeterminado.

Vaciado de conexiones en conmutación por error

El 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 anteriormente 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 que permiten el seguimiento de conexiones: Las conexiones persisten, siempre que exista una entrada correspondiente en 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 el paso para administrar 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 rastrear, consulta la tabla en la sección Modo 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 es útil en las siguientes situaciones:

  • Aplica parches a las VMs de backend. Antes de aplicar el parche, puedes configurar backends principales en buen estado con 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 inhabilitas el vaciado de conexiones en la conmutación por error, 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 apto diferente. Luego, el backend diferente cierra la conexión con un restablecimiento de TCP, de modo que las VMs de cliente puedan establecer rápidamente una conexión nueva con el balanceador de cargas.

  • Una sola VM de backend para la coherencia de los datos. Si necesitas asegurarte de que el conjunto de backends elegibles no tenga más de una VM o un extremo miembro, inhabilitar el vaciado de conexiones en la conmutación por error 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, consulta Define una política de conmutación por error.

Prácticas recomendadas y orientación

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

Controla la fragmentación de UDP

Los balanceadores de cargas de red de transferencia externos regionales 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.
  • Las redes de VPC deGoogle Cloud 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 regional 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 de backend y seguimiento de conexiones. 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 se pueden distribuir al mismo backend apto con más frecuencia de la 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 regional desde un solo cliente.

  • Si la VM 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?