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

En esta página, se describen los siguientes conceptos para ayudarte a comprender mejor y personalizar cómo los balanceadores de cargas de red de transferencia interna distribuyen el tráfico: afinidad de sesión, seguimiento de conexiones, fragmentación de UDP y conmutación por error.

La forma en que un balanceador de cargas de red de transferencia interno distribuye conexiones nuevas depende de si configuraste la conmutación por error:

  • Si no configuraste la conmutación por error, un balanceador de cargas de red de transferencia interno distribuye las conexiones nuevas a las VMs de backend en buen estado, si al menos una VM de backend está en buen estado. Cuando todas las VM de backend están en mal estado, el balanceador de cargas distribuye las conexiones nuevas entre todos los backends como último recurso. En esta situación, el balanceador de cargas enruta cada conexión nueva a una VM de backend en mal estado.

  • Si configuraste la conmutación por error, un balanceador de cargas de red de transferencia interno distribuye las conexiones nuevas entre las VMs en su grupo activo, según una política de conmutación por error que configures. Cuando todas las VM de backend están en mal estado, puedes elegir uno de los siguientes comportamientos:

    • El balanceador de cargas distribuye el tráfico solo a las VM principales (predeterminado). Esto se hace como último recurso. Las VM de copia de seguridad se excluyen de esta distribución de conexiones de último recurso.
    • El balanceador de cargas se configura para abandonar tráfico.

El método para distribuir conexiones nuevas depende de la configuración de afinidad de sesión del balanceador de cargas.

Con la verificación de estado se controla la distribución de conexiones nuevas. De forma predeterminada, las conexiones TCP persisten en backends en mal estado. Para obtener más detalles y cómo cambiar este comportamiento, consulta Persistencia de conexiones en backends en mal estado.

Selección de backend y seguimiento de conexiones

Los balanceadores de cargas de red de transferencia internos usan algoritmos configurables de selección de backend y seguimiento de conexiones para determinar cómo se distribuye el tráfico a las VMs de backend. Los balanceadores de cargas de red de transferencia internos usan el siguiente algoritmo para distribuir paquetes entre las VMs de backend (en su grupo activo, si configuraste la conmutación por error):

  1. Si el balanceador de cargas tiene una entrada en su tabla de seguimiento de conexiones que coincide con las características de un paquete entrante, el paquete se envía al backend que especifica la entrada de la tabla de seguimiento de conexiones. Se considera que el paquete forma parte de una conexión ya establecida, por lo que el paquete se envía a la VM de backend que el balanceador de cargas determinó y registró en su tabla de seguimiento de conexiones.

  2. Cuando el balanceador de cargas hace lo siguiente cuando recibe un paquete que no tiene una entrada de seguimiento de conexión:

    1. El balanceador de cargas selecciona un backend. El balanceador de cargas calcula un hash según la afinidad de sesión configurada. El balanceador de cargas usa este hash para seleccionar un backend:

      • Si al menos un backend está en buen estado, el hash selecciona uno de los backends en buen estado.
      • Si todos los backends están en mal estado y no hay una política de conmutación por error configurada, el hash selecciona uno de los backends.
      • Si todos los backends están en mal estado, hay una política de conmutación por error configurada y la política de conmutación por error no está configurada para descartar tráfico en esta situación, el hash selecciona uno de los backends de VM principales.

      La afinidad de sesión predeterminada, NONE, usa un hash de 5 tuplas de la dirección IP de origen, el puerto de origen, la dirección IP de destino, el puerto de destino y el protocolo del paquete.

      La selección del backend se puede personalizar mediante un algoritmo de hash que usa menos información. Para ver todas las opciones compatibles, consulta las opciones de afinidad de sesión.

    2. El balanceador de cargas agrega una entrada a su tabla de seguimiento de conexiones. En esta entrada, se registra el backend seleccionado para la conexión del paquete a fin de que todos los paquetes futuros de esta conexión se envíen al mismo backend. El uso del seguimiento de conexiones depende del protocolo:

      Para los paquetes TCP y UDP, el seguimiento de conexiones siempre está habilitado y no se puede desactivar. De forma predeterminada, el seguimiento de conexiones es de 5 tuplas, pero se puede configurar para que sea menor que 5.

      Cuando el hash de seguimiento de conexión es de 5 tuplas, los paquetes TCP SYN siempre crean una entrada nueva en la tabla de seguimiento de conexiones.

      El seguimiento de conexiones predeterminado de 5 tuplas se usa en los siguientes casos:

      • el modo de seguimiento es PER_CONNECTION (todas las afinidades de sesión), o,
      • el modo de seguimiento es PER_SESSION, y la afinidad de sesión es NONE, o,
      • el modo de seguimiento es PER_SESSION, y la afinidad de sesión es CLIENT_IP_PORT_PROTO.

      Para obtener más detalles sobre cuándo se habilita el seguimiento de conexiones y qué método se usa cuando dicho seguimiento está habilitado, consulta el modo de seguimiento de conexiones.

      Además, ten en cuenta lo siguiente:

      • 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. Si deseas obtener detalles para personalizar el tiempo de espera de inactividad, consulta Tiempo de espera de inactividad.
      • Según el protocolo, el balanceador de cargas podría quitar las entradas de la tabla de seguimiento de conexiones cuando los backends están en mal estado. Para obtener detalles e información sobre cómo personalizar este comportamiento, consulta Persistencia de la conexión en backends en mal estado.

Opciones de afinidad de sesión

La afinidad de sesión controla la distribución de las conexiones nuevas de los clientes a las VM de backend del balanceador de cargas. Configura la afinidad de sesión cuando las VM de backend necesiten realizar un seguimiento de la información de estado de sus clientes. Este es un requisito común para las aplicaciones web.

La afinidad de sesión funciona según el criterio del mejor esfuerzo.

Los balanceadores de cargas de red de transferencia internos admiten las siguientes opciones de afinidad de sesión, que se especifican para todo el servicio de backend interno, no para cada grupo de instancias de backend.

  • Ninguna (NONE). Hash de 5 tuplas de la dirección IP de origen, el puerto de origen, el protocolo, la dirección IP de destino y el puerto de destino
  • IP de cliente, sin destino (CLIENT_IP_NO_DESTINATION). Hash de 1 tupla creado solo a partir de la dirección IP de origen.
  • IP de cliente (CLIENT_IP). Hash de 2 tuplas de la dirección IP de origen y la dirección IP de destino. Los balanceadores de cargas de red de transferencia externos llaman a esta opción de afinidad de sesión IP de cliente, IP de destino.
  • IP de cliente, IP de destino, protocolo (CLIENT_IP_PROTO). Hash de 3 tuplas de la dirección IP de origen, dirección IP de destino y protocolo
  • IP de cliente, puerto de cliente, IP de destino, puerto de destino, protocolo (CLIENT_IP_PORT_PROTO). Hash de 5 tuplas de la dirección IP de origen, puerto de origen, protocolo, dirección IP de destino y puerto de destino

A menos que uses el balanceador de cargas como el siguiente salto para una ruta estática personalizada, la dirección IP de destino de un paquete debe coincidir con la dirección IP de la regla de reenvío del balanceador de cargas a fin de que el paquete se entregue al balanceador de cargas. Para las consideraciones de uso del balanceador de cargas como salto siguiente para una ruta estática personalizada, afinidad de sesión y balanceador de cargas de red de transferencia interno de próximo salto.

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 que se analizó anteriormente. 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, el hash de selección del 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, al menos, incluya 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 internos. Una política de seguimiento de conexiones incluye la siguiente configuración:

Modo de seguimiento de conexiones

El modo de seguimiento especifica el algoritmo de seguimiento de conexión que se usará. Hay dos modos de seguimiento: PER_CONNECTION (predeterminado) y PER_SESSION.

  • PER_CONNECTION (predeterminado). En este modo, siempre se realiza un seguimiento del tráfico de TCP y UDP por 5 tuplas, sin importar la configuración de afinidad de sesión. Esto implica que la clave para el seguimiento de conexión (5 tuplas) puede ser diferente de la configuración configurada de afinidad de sesión (por ejemplo, 3 tuplas con la configuración CLIENT_IP_PROTO). Como resultado, la afinidad de la sesión puede dividirse y las conexiones nuevas de una sesión pueden seleccionar un backend diferente si el conjunto de backends o su estado cambian.

  • PER_SESSION. En este modo, se realiza un seguimiento del tráfico de TCP y UDP según la afinidad de sesión configurada. Es decir, si la afinidad de sesión es CLIENT_IP o CLIENT_IP_PROTO, la configuración de este modo da como resultado un seguimiento de conexión de 2 o 3 tuplas, respectivamente. Esto puede ser conveniente en situaciones en las que la afinidad de interrupción es costosa y debe evitarse incluso después de agregar más backends.

La configuración del modo de seguimiento de conexión es redundante si la afinidad de sesión se establece en NONE o CLIENT_IP_PORT_PROTO. A fin de obtener información sobre cómo funcionan estos modos de seguimiento con diferentes opciones de configuración de afinidad de sesión para cada protocolo, consulta la siguiente tabla.

Selección de backend Modo de seguimiento de conexiones
Configuración de afinidad de sesión Método hash para la selección de backend PER_CONNECTION (predeterminada) PER_SESSION
Predeterminado: sin afinidad de sesión

NONE

 Hash de 5 tuplas Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 5 tuplas

IP de cliente, sin destino

CLIENT_IP_NO_DESTINATION

 Hash de 1 tupla Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 1 tupla

IP de cliente

CLIENT_IP

(igual que la IP de cliente, la IP de destino para los balanceadores de cargas de red de transferencia externos)

 Hash de 2 tuplas Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 2 tuplas

IP de cliente, IP de destino, protocolo

CLIENT_IP_PROTO

 Hash de 3 tuplas Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 3 tuplas

IP de cliente, puerto de cliente, IP de destino, puerto de destino, protocolo

CLIENT_IP_PORT_PROTO

 Hash de 5 tuplas Seguimiento de conexión de 5 tuplas Seguimiento de conexión de 5 tuplas

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

Persistencia de la conexión en backends en mal estado

La persistencia de la conexión en la configuración de backends en mal estado controla si una conexión existente persiste en un backend seleccionado después de que ese backend esté en mal estado (siempre y cuando el backend permanezca en el grupo de instancias de backend configurado del balanceador de cargas).

El comportamiento descrito en esta sección no se aplica a los casos en los que quitas una VM de backend de su grupo de instancias o quitas el grupo de instancias del servicio de backend. En esos casos, las conexiones establecidas solo se conservan como se describe en el vaciado de conexiones.

Las siguientes opciones de persistencia de la conexión están disponibles:

  • DEFAULT_FOR_PROTOCOL (predeterminada)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

En la siguiente tabla, se 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.

Opción de persistencia de conexión en backends en mal estado Modo de seguimiento de conexiones
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: las conexiones persisten en backends en mal estado (todas las afinidades de sesión).

UDP: Las conexiones nunca se conservan en backends en mal estado.

TCP: las conexiones persisten en backends en mal estado si la afinidad de sesión es NONE o CLIENT_IP_PORT_PROTO.

UDP: Las conexiones nunca se conservan en backends en mal estado.
NEVER_PERSIST TCP, UDP: Las conexiones nunca se conservan en backends en mal estado.
ALWAYS_PERSIST

TCP, UDP: las conexiones persisten en backends en mal estado (todas las afinidades de sesión).

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.

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, es posible que las conexiones del mismo cliente se distribuyan 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 del cliente también es una VM de backend del balanceador de cargas, la misma VM de backend (que también es la VM del cliente) siempre responde a las conexiones que se envían a la dirección IP de la regla de reenvío del balanceador de cargas. Esto sucede independientemente de si la VM de backend está en buen estado. Sucede en todo el tráfico enviado 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 es un proceso que se aplica a las conexiones establecidas en los siguientes casos:

  • Se quita una VM o extremo de un backend (grupo de instancias o NEG).
  • Un backend quita una VM o extremo (por reemplazo, abandono, actualizaciones o reducción de la escala verticalmente).

De forma predeterminada, el vaciado de conexiones está inhabilitado. Cuando se inhabilita, las conexiones establecidas se finalizan lo más rápido posible. Cuando el vaciado de conexiones está habilitado, las conexiones establecidas pueden persistir durante un tiempo de espera configurable, tras lo cual finaliza la instancia de VM de backend.

Para obtener más información sobre cómo se habilita 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 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.

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 VMs 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 una descripción general conceptual detallada de la conmutación por error en los balanceadores de cargas de red de transferencia internos, consulta Conmutación por error para balanceadores de cargas de red de transferencia internos.

¿Qué sigue?