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

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 existente en la tabla de seguimiento de conexiones. La nivel de detalle 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 hayas configurado. 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 envía el paquete 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 persiste, consulta el paso Administra las entradas de la tabla de seguimiento de conexiones.

2. Pasos para la selección del backend

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

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

2.1 Identifica los backends aptos

Los backends aptos son los backends que son candidatos para 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.

Conmutación por error Backends aptos

Cuando se inhabilita la función de balanceo de cargas de conmutación por error, todos los backends configurados son backends principales. El conjunto de backends aptos se define de la siguiente manera:

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

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

  • Cuando al menos un backend (principal o de conmutación por error) está en buen estado, los backends aptos son 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 constan de 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. 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 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.

2.2 Ajusta los servidores de backend aptos para la afinidad zonal

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

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

2.3 Selecciona un backend apto

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

Cuando 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 de 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.

    • 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 el parámetro de configuración de afinidad de sesión, si el conjunto de backends aptos no cambia.

    • Si se agrega o quita un backend que cumple con los requisitos, el hashing coherente tiene como objetivo minimizar la interrupción de las asignaciones a los otros 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 se siguen asignando 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 del backend):

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

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

2.4 Crea una entrada de tabla de seguimiento de conexiones

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

Para obtener información sobre 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 según los siguientes eventos y reglas:

  • Se quitan las entradas inactivas: se quita una entrada de la tabla de seguimiento de conexiones después de un período determinado si el balanceador de cargas no procesa paquetes de entrada nuevos. A menos que configures un tiempo de espera de inactividad personalizado, el balanceador de cargas usa un tiempo de espera de inactividad predeterminado de 600 segundos. Para obtener más información, consulta Tiempo de espera inactivo.

  • Las entradas se expulsan cuando las tablas de seguimiento de conexiones de clientes están llenas: Las tablas de seguimiento de conexiones para los balanceadores de cargas de red de transferencia internos se implementan en sistemas de clientes, como un host que ejecuta una instancia de VM, un host que alimenta un adjunto de VLAN o un host que ejecuta un túnel de Cloud VPN. Cuando la tabla de seguimiento de conexiones de un cliente está llena, se quitan las entradas de las conexiones que se usaron con menos frecuencia.

  • 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 aptos cambia entre 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 mantiene la entrada de la tabla de seguimiento de conexión, a menos que otro motivo o evento quite la entrada de la tabla de seguimiento de conexión.

    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 con anterioridad en el momento en que el backend pasa a estar en mal estado. En cambio, 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 hasta el tiempo de espera comienza cuando se recibe el comando para quitar (abandonar), detener o borrar un backend (incluidos los comandos de eliminación que son el resultado de reducir la escala verticalmente de un 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 interno define el hash de paquetes para la selección de backend y, según el modo de seguimiento de conexiones, el hash de paquetes para el seguimiento de conexiones.

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

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

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

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

O

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

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

1 NONE La afinidad de sesión 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 las características del paquete, lo que funcionalmente es el mismo comportamiento que cuando se establece CLIENT_IP_PORT_PROTO.

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

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

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

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

Política de seguimiento de conexiones

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

Modo de seguimiento de conexiones

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

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

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

  • PER_CONNECTION: Este es el modo de seguimiento de conexiones predeterminado y más detallado. Cada conexión se define como un hash de 5 o 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 paquetes 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)
O
CLIENT_IP_PORT_PROTO
  • TCP y UDP sin fragmentar: Hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: hash de 3 tuplas
  • TCP y UDP no fragmentado: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
  • TCP y UDP no fragmentado: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
CLIENT_IP_PROTO
  • Todos los protocolos: Hash de 3 tuplas
  • TCP y UDP no fragmentado: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los protocolos: Seguimiento de conexión activado, hash de 3 tuplas
CLIENT_IP
  • Todos los protocolos: Hash de 2 tuplas
  • TCP y UDP no fragmentado: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los protocolos: Seguimiento de conexión activado, hash de 2 tuplas
CLIENT_IP_NO_DESTINATION
  • Todos los protocolos: Hash de 1 tupla
  • TCP y UDP no fragmentado: Seguimiento de conexión activado, hash de 5 tuplas
  • UDP fragmentado y todos los demás protocolos: Seguimiento de conexión activado, hash de 3 tuplas
  • Todos los protocolos: Seguimiento de conexión activado, hash de 1 tupla

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

Persistencia de la conexión en backends en mal estado

El parámetro de configuración Persistencia de la conexión en backends en mal estado controla si las conexiones existentes pueden persistir en una VM de backend seleccionada previamente si la VM seleccionada previamente deja de estar en buen estado. 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.

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, SCTP (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, SCTP (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.

 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 backends aptos).

Tiempo de espera inactivo

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

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

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

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

Vaciado de conexiones para backends quitados, detenidos o borrados

El vaciado de conexiones proporciona una cantidad mínima de tiempo configurable para que las conexiones existentes persistan 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.

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 backend 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 Descartar el tráfico si los backends están en mal estado en la política de conmutación por error

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.
  • Descarta 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. La proporción de conmutación por error y el parámetro de configuración Descarta el tráfico si los backends están en mal estado funcionan junto 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 con anterioridad cuando el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error.

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

Opción de vaciado de conexiones en conmutación por error Comportamiento cuando el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error
Habilitados (configuración predeterminada) Todos los protocolos: Las conexiones persisten, siempre que exista una entrada en la tabla de seguimiento de conexiones correspondiente, 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 Administra las entradas de la tabla de seguimiento de conexiones.
Inhabilitado Todos los protocolos: Las conexiones no persisten cuando el conjunto de backends aptos cambia entre los backends principales y los de conmutación por error.

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

  • Aplica parches a las VMs de backend. Antes de aplicar el parche, puedes configurar los backends principales en buen estado para que fallen las verificaciones de estado, de modo que los backends elegibles puedan ser backends de conmutación por error en buen estado. 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.

  • VM de backend única para la coherencia de los datos. Si necesitas asegurarte de que el conjunto de backends aptos no tenga más de una VM o extremo miembro, inhabilitar el vaciado de conexiones en la conmutación por error reduce la posibilidad de que se produzcan inconsistencias 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 interno siguiendo estos lineamientos operativos. En las siguientes secciones, se proporcionan los requisitos técnicos para administrar paquetes UDP fragmentados y las prácticas recomendadas para probar la distribución de carga desde un solo cliente.

Cómo controlar la fragmentación de UDP

Los balanceadores de cargas de red de transferencia internos pueden procesar paquetes UDP fragmentados y no fragmentados. Si tu aplicación usa paquetes UDP fragmentados, ten en cuenta lo siguiente:
  • Los paquetes UDP pueden fragmentarse antes de llegar a una red de VPC de 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 son deGoogle Cloud y el equipo de red local pueden reenviar fragmentos UDP a medida que llegan, retrasar los paquetes UDP fragmentados hasta que todos los fragmentos hayan llegado, o descartar paquetes UDP fragmentados. Para obtener más información, consulta la documentación del proveedor de red o el equipo de red.

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

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

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

Prueba desde un solo cliente

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

  • Si la VM del cliente no es un backend del balanceador de cargas: Las conexiones nuevas se procesan como se describe en los pasos de Selección 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 podrían 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 interno 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?