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

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

Selección de backend y seguimiento de conexiones

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

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

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

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

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

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

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

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

• En el caso del resto de los paquetes, el balanceador de carga comprueba si el paquete coincide con una entrada de la tabla de seguimiento de conexiones. La tupla de conexión (un conjunto de características de paquetes) que se usa para comparar el paquete con las entradas de la tabla de seguimiento de conexiones depende del modo de seguimiento de conexiones y de la afinidad de sesión que hayas configurado. Para obtener información sobre qué tupla de conexión se usa para el seguimiento de conexiones, consulta la tabla de la sección Modo de seguimiento de conexiones.

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

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

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

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

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

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

2.1 Identificar back-ends aptos

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

Política de no conmutación por error

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

• Cuando al menos un backend está en buen estado, todos los backends aptos están en buen estado.

• Cuando todos los backends están en mal estado, los backends aptos son todos los backends.

Política de conmutación por error configurada

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

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

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

• Cuando no hay backends en buen estado, los backends aptos se definen de la siguiente manera:

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

2.2 Ajustar los back-ends aptos para la afinidad zonal

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

• La afinidad zonal está inhabilitada
• El cliente es incompatible con la afinidad zonal
• No se produce una coincidencia zonal con la zona de un cliente compatible

Si la afinidad zonal está habilitada, un cliente es compatible con ella y se produce una coincidencia zonal, las nuevas conexiones del cliente se dirigen a un conjunto ajustado de back-ends aptos. Para obtener más información, consulta las siguientes secciones:

• Cómo ZONAL_AFFINITY_STAY_WITHIN_ZONE funciona

• Cómo funcionan ZONAL_AFFINITY_SPILL_CROSS_ZONE y la proporción de desbordamiento

2.3 Selecciona un backend apto

El balanceador de carga usa el hash coherente para seleccionar un backend apto. El balanceador de carga mantiene los hashes de los backends aptos, asignados a un círculo unitario. Cuando procesa un paquete de una conexión que no está en la tabla de seguimiento de conexiones, el balanceador de carga calcula un hash de las características del paquete y asigna ese hash al mismo círculo unitario, seleccionando un backend apto en la circunferencia del círculo. El conjunto de características de los paquetes que se usa para calcular el hash de los paquetes se define en el ajuste de afinidad de sesión.

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

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

  • El balanceador de carga selecciona el mismo backend para todas las conexiones nuevas posibles que tengan las mismas características de paquete, tal como se define en la afinidad de sesión, si el conjunto de backends aptos no cambia.

  • Cuando se añade un nuevo backend apto, se asignan aproximadamente 1/N nuevas conexiones posibles al backend recién añadido. En esta situación, N es el número de back-ends aptos después de añadir el nuevo back-end.

  • Cuando se elimina un backend apto, se asignan aproximadamente 1/N posibles conexiones nuevas a uno de los N-1 backends restantes. En esta situación, N es el número de back-ends antes de que se elimine el back-end apto.

2.4 Crear una entrada de tabla de seguimiento de conexiones

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

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

• Una entrada de la tabla de seguimiento de conexiones se elimina después de que la conexión haya estado inactiva. Si no configuras un tiempo de espera inactivo personalizado, el balanceador de carga usará un tiempo de espera inactivo predeterminado de 600 segundos. Para obtener más información, consulta Tiempo de espera por inactividad.

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

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

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

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

Afinidad de sesión

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

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

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

Afinidad de sesión y balanceador de carga de red de paso a través interno del siguiente salto

Cuando un balanceador de carga de red de paso a través interno es el siguiente 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 carga. En su lugar, la dirección IP de destino del paquete puede ser cualquier dirección IP que se ajuste al intervalo de destino de la ruta estática.

Seleccionar un backend apto depende de calcular un hash de las características del paquete. A excepción de la CLIENT_IP_NO_DESTINATION afinidad de sesión (hash de 1 tupla), el hash depende, en parte, de la dirección IP de destino del paquete.

El balanceador de carga selecciona el mismo backend para todas las conexiones nuevas posibles que tengan las mismas características de paquete, tal como se define en la afinidad de sesión, si el conjunto de backends aptos no cambia. Si necesitas que la misma VM de backend procese todos los paquetes de un cliente basándose únicamente en la dirección IP de origen, independientemente de las direcciones IP de destino, usa la CLIENT_IP_NO_DESTINATIONafinidades de sesión.

Política de seguimiento de conexiones

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

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

Modo de seguimiento de la conexión

La tabla de seguimiento de conexiones del balanceador de carga asigna tuplas de conexión a back-ends seleccionados anteriormente en una tabla hash. El conjunto de características de los paquetes que componen cada tupla de conexión se determina mediante el modo de seguimiento de la conexión y la afinidad de sesión.

Los balanceadores de carga de red de paso a través internos monitorizan las conexiones de todos los protocolos que admiten.

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

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

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

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

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

Persistencia de la conexión en backends en mal estado

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

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

• DEFAULT_FOR_PROTOCOL (predeterminado)
• NEVER_PERSIST
• ALWAYS_PERSIST

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

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

Tiempo de espera de inactividad

De forma predeterminada, una entrada de la tabla de seguimiento de conexiones caduca 600 segundos después de que el balanceador de carga procese el último paquete que coincida con la entrada. Este valor de tiempo de espera predeterminado se puede modificar solo cuando el seguimiento de conexiones sea inferior a 5 tuplas (es decir, cuando la afinidad de sesión se haya configurado como CLIENT_IP o CLIENT_IP_PROTO, y el modo de seguimiento sea PER_SESSION).

El valor máximo de tiempo de espera por inactividad que se puede configurar es de 57.600 segundos (16 horas).

Para saber cómo cambiar el valor del tiempo de espera por inactividad, consulta Configurar una política de seguimiento de conexiones.

Conexiones para implementaciones de un solo cliente

Cuando pruebes las conexiones a la dirección IP de un balanceador de carga de red de paso a través interno que solo tenga un cliente, debes tener en cuenta lo siguiente:

• Si la VM cliente no es una VM con balanceo de carga (es decir, no es una VM de backend), las nuevas conexiones se envían a las VMs de backend en buen estado del balanceador de carga. Sin embargo, como todas las opciones de afinidad de sesión dependen al menos de la dirección IP del sistema cliente, es posible que las conexiones del mismo cliente se distribuyan a la misma VM backend con más frecuencia de lo que cabría esperar.

  En la práctica, esto significa que no puedes monitorizar con precisión la distribución del tráfico a través de un balanceador de carga de red de paso a través interno conectándote a él desde un solo cliente. El número de clientes necesarios para monitorizar la distribución del tráfico varía en función del tipo de balanceador de carga, el tipo de tráfico y el número de backends en buen estado.

• Si la VM de cliente también es una VM de backend del balanceador de carga, las conexiones enviadas a la dirección IP de la regla de reenvío del balanceador de carga siempre las responde la misma VM de backend (que también es la VM de cliente). Esto ocurre independientemente de si la VM de backend está en buen estado. Esto ocurre con todo el tráfico enviado a la dirección IP del balanceador de carga, no solo con el tráfico del protocolo y los puertos especificados en la regla de reenvío interna del balanceador de carga.

  Para obtener más información, consulta cómo enviar solicitudes desde VMs con balanceo de carga.

Purga de conexión

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

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

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

Fragmentación de UDP

• Los paquetes UDP pueden fragmentarse antes de llegar a una red VPC. Google Cloud
• Google Cloud Las redes de VPC reenvían fragmentos UDP a medida que llegan (sin esperar a que lleguen todos los fragmentos).
• Las redes que no sonGoogle Cloud y los equipos de red on-premise pueden reenviar fragmentos UDP a medida que llegan, retrasar los paquetes UDP fragmentados hasta que hayan llegado todos los fragmentos o descartar los paquetes UDP fragmentados. Para obtener más información, consulta la documentación del proveedor de la red o del equipo de red.

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

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

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

Conmutación por error

Un balanceador de carga de red de paso a través interno te permite designar algunos backends como backends de failover. Estos backends solo se usan cuando el número de VMs en buen estado de los grupos de instancias de backend principales ha descendido por debajo de un umbral configurable. De forma predeterminada, si todas las VMs principales y de conmutación por error no están en buen estado, como último recurso,Google Cloud distribuye las nuevas conexiones solo entre todas las VMs principales.

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

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

Para obtener más información sobre cómo funciona la conmutación por error, consulta Conmutación por error de balanceadores de carga de red de pases internos.

Siguientes pasos

• Para configurar y probar un balanceador de carga de red de paso a través interno que utilice la conmutación por error, consulta Configurar la conmutación por error de balanceadores de carga de red de paso a través internos.
• Para configurar y probar un balanceador de carga de red de paso a través interno, consulta Configurar un balanceador de carga de red de paso a través interno.