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 describe el proceso de selección de backend y seguimiento de conexiones.

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

En el caso de una conexión existente, el balanceador de cargas usa la tabla de seguimiento de conexiones para identificar el backend seleccionado anteriormente para esa conexión.

El balanceador de cargas intenta hacer coincidir cada paquete con balanceo de cargas con una entrada en su tabla de seguimiento de conexiones mediante el siguiente proceso:

• Si el paquete es un paquete TCP con la marca SYN, sucede lo siguiente:

  • 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, independientemente de 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).

• Si la afinidad de sesión configurada no admite el seguimiento de conexiones para el protocolo del paquete, continúa con el paso Identifica los backends aptos. Para obtener información sobre qué protocolos se pueden rastrear, consulta la tabla en la sección Modo de seguimiento de conexiones.

• Para todos los demás paquetes, el balanceador de cargas verifica si el paquete coincide con una entrada existente de la tabla de seguimiento de conexiones. La tupla de conexión (un conjunto de características del paquete) que se usa para comparar el paquete con las entradas existentes de la tabla de seguimiento de conexiones depende del modo de seguimiento de conexiones y de la afinidad de sesión que configuraste. Para obtener información sobre qué tupla de conexión se usa para el seguimiento de conexiones, 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 Crea una entrada de la tabla de seguimiento de conexiones.

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

Para una conexión nueva, el balanceador de cargas usa el algoritmo de 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

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

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

Sin política de conmutación por error, balanceo de cargas ponderado inhabilitado

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

• 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.

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

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

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

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

El conjunto de backends aptos depende de la configuración de las verificaciones de estado y 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, utilizando 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 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.
  • 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.
  • Los backends aptos constan de todos los backends de conmutación por error 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 cargas está configurada para descartar conexiones nuevas cuando no hay backends en buen estado, el conjunto de backends aptos estará vacío. El balanceador de cargas descarta los paquetes de las conexiones nuevas.
  • Si la política de conmutación por error del balanceador de cargas no está configurada para descartar conexiones nuevas cuando no hay backends en buen estado, las verificaciones de estado no son relevantes. Los backends aptos son todos los backends principales.

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

El conjunto de backends aptos depende de las verificaciones de 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 sea verdadera de esta lista ordenada:

  • Si no hay backends principales en buen estado con una ponderación distinta de cero, los backends aptos son todos los backends de conmutación por error en buen estado con una ponderación distinta de cero.
  • Si no hay backends de conmutación por error en buen estado y con ponderación distinta de cero, los backends aptos son todos los backends principales en buen estado y con ponderación distinta de cero.
  • 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 y con un peso distinto de cero.
  • Si la proporción de la cantidad de backends principales en buen estado y con un peso distinto 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 y con un peso distinto de cero.
  • Los backends aptos constan de todos los backends de conmutación por error en buen estado y con ponderación distinta 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 cargas está configurada para descartar conexiones nuevas cuando no hay backends en buen estado, el conjunto de backends aptos estará vacío. El balanceador de cargas descarta los paquetes de las conexiones nuevas.

  • Si la política de conmutación por error del balanceador de cargas no está configurada para descartar conexiones nuevas cuando ningún backend está en buen estado, el conjunto de backends aptos es 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 conmutación por error en mal estado y con un peso distinto de cero
    • Todos los backends principales en buen estado y con peso cero
    • Todos los backends en buen estado y sin conmutación por error de peso
    • Todos los backends principales en mal estado y con peso cero
    • Todos los backends de conmutación por error en mal estado y con ponderación cero

2.2 Selecciona un backend apto

El balanceador de cargas usa el hash coherente para seleccionar un backend apto. El balanceador de cargas mantiene hashes de los backends aptos, asignados 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 el parámetro de configuración de afinidad de sesión.

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

• En los siguientes dos ejemplos, se muestra cómo el balanceo de cargas ponderado afecta la selección de un 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 un peso de 0, el backend apto b con un peso de 2 y el backend apto 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 cargas asigna conexiones nuevas a los backends aptos de la manera más coherente posible, incluso si cambia la cantidad de backends aptos o sus pesos. Los siguientes beneficios del hashing coherente muestran cómo el balanceador de cargas selecciona los backends aptos para posibles conexiones nuevas que no tienen entradas en la tabla de seguimiento de conexiones:

  • El balanceador de cargas selecciona el mismo backend para todas las conexiones nuevas posibles que tengan características de paquetes idénticas, como se define en la 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.

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

    • Si no se configura el balanceo de cargas ponderado, aproximadamente 1/N conexiones nuevas 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 posibles conexiones nuevas 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.

    • Si se agrega o quita un backend apto, o si 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.

2.3 Crea una entrada de tabla de seguimiento de conexiones

Después de seleccionar un backend, el balanceador de cargas crea una entrada de 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 las opciones de configuración y qué características de paquetes se usan para el hash, consulta la sección Modo de seguimiento de conexiones.

El balanceador de cargas quita las entradas de la tabla de seguimiento de conexiones según las siguientes reglas:

• Una entrada de la tabla de seguimiento de conexión se quita después de que la conexión estuvo 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 quitan cuando se cierra una conexión TCP con un paquete FIN o RST. Cualquier conexión TCP nueva siempre incluye la marca SYN y se procesa como se describe en el paso Verifica 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 el parámetro de configuración de vaciado de conexiones en conmutación por error y por recuperación, el balanceador de cargas quita todas las entradas de la tabla de seguimiento de conexiones cuando los backends aptos cambian de backends principales a backends de conmutación por error (conmutación por error) o de backends de conmutación por error a backends principales (conmutación por recuperación). Para obtener más información, consulta Vaciado de conexiones en conmutación por error y recuperación.

• Las entradas de la tabla de seguimiento de conexiones se pueden quitar si un backend deja de estar en buen estado. Este comportamiento depende del modo de seguimiento de conexiones, el protocolo y el parámetro de configuración de persistencia de conexión en backends en mal estado. Para obtener más información, consulta Persistencia de conexiones en backends en mal estado.

• Las entradas de la tabla de seguimiento de conexiones se quitan después del tiempo de espera de vaciado de conexiones que se produce después de un evento, como borrar una VM de backend o quitar una VM de backend de un grupo de instancias o un NEG. Para obtener más información, consulta Habilita el vaciado 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 cargas. Los balanceadores de cargas de red de transferencia externos usan la afinidad de sesión para seleccionar un backend de un conjunto de backends aptos, como se describe en los pasos Identifica los backends aptos y Selecciona un backend apto de la sección Selección de backend y 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.

Los balanceadores de cargas de red de transferencia externos admiten los siguientes parámetros de configuración de afinidad de sesión. Cada parámetro de configuración de afinidad de sesión usa el hash coherente para seleccionar un backend apto. El parámetro de configuración de afinidad de sesión determina qué campos de los encabezados IP y TCP/UDP se usan para calcular el hash.

Para obtener información sobre cómo los diferentes parámetros de configuración de afinidad de sesión afectan la selección del backend y los métodos de seguimiento de conexiones, consulta la tabla en la sección Modo de seguimiento de conexiones.

Política de seguimiento de conexiones

En esta sección, se describen los parámetros de configuración que controlan el comportamiento del seguimiento de conexiones de los balanceadores de cargas de red de transferencia externos. Una política de seguimiento de conexiones incluye los siguientes parámetros de configuración:

• Modo de seguimiento de conexiones
• Persistencia de la conexión en backends en mal estado
• Tiempo de espera inactivo

Modo de seguimiento de conexiones

Cuando es posible el seguimiento de conexiones, la tabla de seguimiento de conexiones del balanceador de cargas asigna tuplas de conexión a backends seleccionados previamente en una tabla hash. El conjunto de características de paquetes que componen cada tupla de conexión depende del modo de seguimiento de conexión y de la afinidad de sesión.

Los balanceadores de cargas de red de transferencia externos admiten el seguimiento de conexiones según el protocolo y las opciones de 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 se pueden rastrear por conexión.

El modo de seguimiento de conexión hace referencia a la granularidad de cada tupla de conexión en la tabla de seguimiento de conexión del balanceador de cargas. La tupla de conexión puede ser de 5 o 3 tuplas (modo PER_CONNECTION), o bien puede coincidir con el parámetro de configuración de afinidad de sesión (modo PER_SESSION).

• PER_CONNECTION: Este es el modo de seguimiento de conexiones predeterminado. Este modo de seguimiento de conexión usa un hash de 5 o 3 tuplas. Los paquetes no fragmentados que incluyen información de puerto, 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 usa un hash que consta de las mismas características de paquetes que el hash de afinidad de sesión. Según la afinidad de sesión elegida, PER_SESSION puede generar conexiones que coincidan con mayor frecuencia con una entrada existente de la tabla de seguimiento de conexiones, lo que reduce la frecuencia con la que el hash de afinidad de sesión debe seleccionar un backend.

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

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 configuración de persistencia de la conexión controla si una conexión existente persiste en una VM o extremo de backend seleccionado después de que ese backend esté en mal estado, siempre que el backend permanezca en el grupo de backend configurado del balanceador de cargas (en un grupo de instancias o un NEG).

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 resumen las opciones de persistencia de la conexión y cómo persisten las conexiones para diferentes protocolos, opciones de afinidad de sesión y modos de seguimiento.

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

Cuando una conexión TCP con seguimiento de 5 tuplas se mantiene en un backend en mal estado, ocurre lo siguiente:

• 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 en buen estado. Los paquetes de TCP SYN siempre seleccionan un backend nuevo y en buen estado.

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.

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.

Balanceo de cargas ponderado

El balanceo de cargas ponderado para los balanceadores de cargas de red de transferencia externos usa la información de ponderación que informa una verificación de estado HTTP. El balanceo de cargas ponderado requiere que configures lo siguiente:

• La política de localidad del balanceador de cargas del servicio de backend (localityLbPolicy) debe ser WEIGHTED_MAGLEV.
• El servicio de backend debe usar una verificación de estado de HTTP.
• Las respuestas de verificación de estado de cada VM de backend o extremo 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 varían de 0 a 1000.

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

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

Cuando se usa el balanceo de cargas ponderado, el balanceador de cargas clasifica las VMs o los extremos de backend, primero según si tienen un peso mayor que cero o igual a cero, y luego según las verificaciones de estado. El estado de la verificación de estado se determina según los criterios de éxito para las verificaciones de estado HTTP, HTTPS y HTTP/2.

Para obtener más información sobre cómo el balanceo de cargas ponderado influye en qué backends son aptos, consulta los pasos Identifica los backends aptos y Selecciona un backend apto en la sección Selección de backend y seguimiento de conexiones.

El balanceo de cargas ponderado se puede usar en las siguientes situaciones:

• Si algunas conexiones procesan más datos que otras, o algunas conexiones duran más que otras, la distribución de la carga del backend podría volverse desigual. Cuando se indica una ponderación menor por instancia, una instancia con carga alta puede reducir su cuota de conexiones nuevas, a la vez que mantiene las conexiones existentes.

• Si un backend está sobrecargado y la asignación de más conexiones puede interrumpir las conexiones existentes, esos backends se asignan una ponderación de cero a sí mismos. Cuando se indica una ponderación de cero, una instancia de backend deja de entregar conexiones nuevas, pero continúa entregando servicios a las existentes.

• Si un backend vacía las conexiones existentes antes del mantenimiento, se asigna ponderación cero a sí mismo. Cuando se indica una ponderación de cero, la instancia de backend deja de entregar conexiones nuevas, pero continúa entregando servicios a las existentes.

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

Vaciado de conexiones

El vaciado 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 cargas cuando se realiza una de las siguientes acciones:

• 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 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 para las acciones mencionadas está inhabilitado. Para obtener información sobre cómo se activa el vaciado de conexiones y cómo habilitarlo, consulta Habilita el vaciado de conexiones.

Fragmentación 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.

Conmutación por error

Puedes configurar un balanceador de cargas de red de transferencia externo para distribuir conexiones entre instancias o extremos de VM en backends principales (grupos de instancias o NEG) y, si es necesario, cambiar a backends de conmutación por error. La conmutación por error proporciona otro método para aumentar la disponibilidad y, también, te brinda un mayor control sobre cómo administrar la carga de trabajo cuando los backends principales no están en buen estado.

De forma predeterminada, cuando agregas un backend al servicio de backend del balanceador de cargas de red de transferencia externo, ese backend es el principal. Puedes designar un backend para que sea de conmutación por error cuando lo agregues al servicio de backend del balanceador de cargas o si editas el servicio de backend más adelante.

Para obtener más información sobre cómo se usa la conmutación por error para la selección de backend y el seguimiento de conexiones, consulta los pasos Identifica backends aptos y Crea una entrada de tabla de seguimiento de conexiones en 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 Descripción general de la conmutación por error para los balanceadores de cargas de red de transferencia externos.

¿Qué sigue?

• Si quieres configurar un balanceador de cargas de red de transferencia externo con un servicio de backend solo para el tráfico de TCP o UDP (compatible con el tráfico IPv4 e IPv6), consulta Configura un balanceador de cargas de red de transferencia de transferencia externo con un servicio de backend.
• Si quieres configurar un balanceador de cargas de red de transferencia externo para varios protocolos IP (compatibles con el tráfico de IPv4 e IPv6), consulta Configura un balanceador de cargas de red de traspaso externo para varios protocolos de IP.
• Para configurar un balanceador de cargas de red de transferencia externo con un backend de NEG zonal, consulta Configura un balanceador de cargas de red de transferencia externo con NEG zonales.
• Para obtener información sobre cómo hacer la transición de un balanceador de cargas de red de transferencia externo desde un backend de grupo de destino a un servicio de backend regional, consulta Transición de un balanceador de cargas de red de transferencia externo de un grupo de destino a un servicio de backend.