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

En esta página, se explican los conceptos sobre cómo los balanceadores de cargas de red de transferencia interna 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 equilibrar 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 captura el proceso de selección de backend y seguimiento de conexiones.

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

Para 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, haz lo siguiente:

  • Si el modo de seguimiento de conexiones del balanceador de cargas es PER_CONNECTION, sigue 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 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).

• Para 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 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 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 lo envía 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, 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 del grupo activo.

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.

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

• Sin política de conmutación por error: El conjunto de backends aptos depende solo de las verificaciones de estado:

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

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

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

  • Cuando al menos un backend está en buen estado, el conjunto de backends aptos consiste en todos los backends en buen estado del grupo activo.

    • El grupo activo puede constar de todos los backends principales en buen estado o de todos los backends de conmutación por error en buen estado. La membresía en el grupo activo se determina según la proporción de conmutación por error configurada, la cantidad de backends principales en buen estado y la cantidad total de backends principales.

    • Independientemente de la proporción de conmutación por error, si no hay backends de conmutación por error en buen estado, pero hay al menos un backend principal en buen estado, el grupo activo consta de todos los backends principales en buen estado.

  • Cuando no hay backends en buen estado y la política de conmutación por error del balanceador de cargas está configurada para descartar conexiones nuevas, en esta situación, el conjunto de backends aptos está vacío. El balanceador de cargas descarta los paquetes de la conexión.

  • Cuando no hay backends en buen estado y la política de conmutación por error del balanceador de cargas no está configurada para descartar conexiones nuevas, en esta situación, las verificaciones de estado no son relevantes. Los backends aptos consisten en todos los backends principales.

2.2 Selecciona un backend apto.

El balanceador de cargas usa hash coherente para seleccionar un backend apto. El balanceador de cargas mantiene los valores hash de los backends aptos, asignados 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 lo asigna al mismo círculo unitario, y selecciona un backend apto en la circunferencia del círculo. El conjunto de características de paquetes que se usan para calcular el hash de paquetes se define mediante la configuración de afinidad de sesión.

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

• El balanceador de cargas asigna conexiones nuevas a backends aptos de la manera más coherente posible, incluso si cambia la cantidad de backends aptos. Los siguientes beneficios del hash coherente muestran cómo el balanceador de cargas selecciona backends aptos para posibles conexiones nuevas que no tienen entradas de 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, si el conjunto de backends aptos no cambia.

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

  • Cuando se quita un backend apto, aproximadamente 1/N posibles 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.3 Crea una entrada de la tabla de seguimiento de conexiones.

Después de seleccionar un backend, el balanceador de cargas crea una entrada de 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 conexiones y la afinidad de sesión que configuraste.

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

• Se quita una entrada de la tabla de seguimiento de conexiones después de que la conexión estuvo inactiva. 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 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 lleva la marca SYN y se procesa como se describe en el paso Comprueba 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 vaciado de conexiones en la configuración de conmutación por error y por recuperación, el balanceador de cargas quita todas las entradas de la tabla de seguimiento de conexiones cuando cambia el grupo activo durante la conmutación por error o por recuperación. Para obtener más información, consulta Vaciado de conexiones en la conmutación por error y el resguardo.

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

• Las entradas de la tabla de seguimiento de conexiones se quitan después del tiempo de espera del 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 interna usan la afinidad de sesión para seleccionar un backend de un conjunto de backends aptos, como se describe en los pasos Identifica backends aptos y Selecciona un backend apto en 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 internos admiten la siguiente configuración de afinidad de sesión. Cada configuración de afinidad de sesión usa hash coherente para seleccionar un backend apto. La configuración de afinidad de sesión determina qué campos del encabezado IP y de los encabezados de la capa 4 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.

Afinidad de sesión y balanceador de cargas de red de transferencia interno de próximo salto

Cuando configuras una ruta estática para usar un balanceador de cargas de red de transferencia interno de próximo salto, el balanceador de cargas usa el mismo método de selección de backend y seguimiento de conexiones. La selección de backend se sigue realizando calculando un hash según la afinidad de sesión configurada. Excepto por la afinidad de sesión CLIENT_IP_NO_DESTINATION (hash de 1 tupla), el hash de selección de backend depende, en parte, de la dirección IP de destino del paquete.

Cuando un balanceador de cargas de red de transferencia interno es el 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.

Si la cantidad de VMs de backend configuradas y en buen estado es constante (cuando la conmutación por error no está configurada o, cuando está configurada, pero no se producen eventos de conmutación por error ni de recuperación), el balanceador de cargas se comporta de la siguiente manera:

• Si solo hay una VM de backend configurada y en buen estado (en el grupo activo, si la conmutación por error está configurada), no importa qué afinidad de sesión uses, ya que todos los valores hash se asignan a la única VM de backend.

• Si hay dos o más VMs de backend configuradas y en buen estado (en el grupo activo, si la conmutación por error está configurada), la afinidad de sesión es importante:

  • 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 del paquete, sin importar las direcciones IP de destino del paquete, usa la afinidad de sesión CLIENT_IP_NO_DESTINATION. Según los patrones de tráfico, algunas VMs de backend pueden recibir más paquetes o más conexiones que otras.

  • Si usas una opción de afinidad de sesión que no sea CLIENT_IP_NO_DESTINATION, el balanceador de cargas selecciona una VM de backend según la información que incluya, al menos, ambas direcciones IP: la de origen y la de destino del paquete. Los paquetes que se envían desde el mismo cliente, con la misma dirección IP de origen, pero con diferentes direcciones IP de destino, se pueden enrutar a diferentes VMs de backend.

Política de seguimiento de conexiones

En esta sección, se describe la configuración que controla el comportamiento de seguimiento de conexiones de los balanceadores de cargas de red de transferencia interna. Una política de seguimiento de conexiones incluye la siguiente 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

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 los paquetes que componen cada tupla de conexión se determina según el modo de seguimiento de conexiones y la afinidad de sesión.

Los balanceadores de cargas de red de transferencia internos realizan un seguimiento de las conexiones de todos los protocolos que admiten.

El modo de seguimiento de conexión hace referencia al nivel de detalle de cada tupla de conexión en la tabla de seguimiento de conexiones del balanceador de cargas. La tupla de conexión puede ser de 5 o 3 tuplas (modo PER_CONNECTION), o bien puede coincidir con la 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 tuplas o un hash de 3 tuplas. Se realiza un seguimiento de los paquetes no fragmentados que incluyen información de puerto, como los paquetes TCP y los paquetes UDP no fragmentados, con valores hash de 5 tuplas. Se realiza un seguimiento de todos los demás paquetes con hash de 3 tuplas.

• PER_SESSION: Este modo de seguimiento de conexiones usa un hash que consta de las mismas características de paquetes que usa 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 trabajan 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.

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

De forma predeterminada, una entrada en la tabla de seguimiento de conexiones vence 600 segundos después de que el balanceador de cargas procesa el último paquete que coincidió con la entrada. Este valor de tiempo de espera de inactividad predeterminado solo se puede modificar cuando el seguimiento de conexión es inferior a 5 tuplas (es decir, cuando la afinidad de sesión está configurada para CLIENT_IP o CLIENT_IP_PROTO) y el modo de seguimiento es PER_SESSION).

El valor de tiempo de espera de inactividad máximo configurable es de 57,600 segundos (16 horas).

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

Conexiones para implementaciones de un solo cliente

Cuando se prueban las conexiones a la dirección IP de un balanceador de cargas de red de transferencia interno que solo tiene un cliente, debes tener en cuenta lo siguiente:

• Si la VM del cliente no es una VM a la que se le aplica el balanceo de cargas, es decir, no es una VM de backend, las conexiones nuevas se entregan a las VMs de backend en buen estado del balanceador de cargas. Sin embargo, como todas las opciones de afinidad de sesión dependen, al menos, de la dirección IP del sistema del cliente, las conexiones del mismo cliente podrían distribuirse a la misma VM de backend con mayor frecuencia de la que esperas.

  Esto significa que no puedes supervisar con precisión la distribución de tráfico a través de un balanceador de cargas de red de transferencia interno si te conectas a este desde un solo cliente. La cantidad de clientes que se necesita para supervisar la distribución de tráfico varía según el tipo de balanceador de cargas, el tipo de tráfico y la cantidad de backends en buen estado.

• Si la VM de cliente también es una VM de backend del balanceador de cargas, la misma VM de backend (que también es la VM de cliente) siempre responde a las conexiones enviadas a la dirección IP de la regla de reenvío del balanceador de cargas. Esto sucede sin importar si la VM de backend está en buen estado. Sucede en todo el tráfico que se envía a la dirección IP del balanceador de cargas, no solo en el tráfico del protocolo y los puertos especificados en la regla de reenvío interno del balanceador de cargas.

  Para obtener más información, consulta Envía solicitudes desde VM con balanceo de cargas.

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 produce una de las siguientes acciones:

• 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 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 paquetes UDP pueden fragmentarse antes de llegar a una red de VPC de Google Cloud.
• 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 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

Un balanceador de cargas de red de transferencia interno te permite designar algunos backends como backends de conmutación por error. Estos backends solo se usan cuando la cantidad de VM en buen estado en los grupos de instancias de backend principales disminuye por debajo de un umbral configurable. De forma predeterminada, si todas las VM principales y de conmutación por error están en mal estado, como último recurso,Google Cloud distribuye las conexiones nuevas solo entre todas las VM principales.

Cuando agregas un backend a un servicio de backend del balanceador de cargas de red de transferencia interno, de forma predeterminada, ese backend es uno primario. 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 los 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 Conmutación por error para los balanceadores de cargas de red de transferencia interna.

¿Qué sigue?

• Para configurar y probar un balanceador de cargas de red de transferencia interno que usa la conmutación por error, consulta Configura la conmutación por error para balanceadores de cargas de red de transferencia internos.
• Para configurar y probar un balanceador de cargas de red de transferencia interno, consulta Configura un balanceador de cargas de red de transferencia interno.