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

En esta página, se describen los siguientes conceptos para ayudarte a comprender mejor y personalizar la forma en que los balanceadores de cargas de red de transferencia externos distribuyen el tráfico: afinidad de sesión, seguimiento de conexiones, balanceo de cargas ponderado, vaciado de conexiones, fragmentación de UDP y conmutación por error.

La forma en que los balanceadores de cargas de red de transferencia externos distribuyen 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 externo distribuye las conexiones nuevas a sus 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 nuevas conexiones 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 externo distribuye las conexiones nuevas entre las VMs de backend en buen estado en su grupo activo, de acuerdo con la 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 descarta el tráfico.

Para obtener detalles sobre cómo se distribuyen las conexiones, consulta la siguiente sección Selección de backend y seguimiento de conexiones.

Para obtener detalles sobre cómo funciona la conmutación por error, consulta la sección Conmutación por error.

Selección de backend y seguimiento de conexiones

Los balanceadores de cargas de red de transferencia externos 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 externos 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. Usa este hash para seleccionar un backend entre los que están en buen estado (a menos que todos estén en mal estado, en cuyo caso se considerarán todos los backends, siempre y cuando la política de conmutación por error no se haya configurado para descartar el tráfico en esta situación). La afinidad de sesión predeterminada, NONE, usa los siguientes algoritmos de hash:

      • Para paquetes TCP y UDP sin fragmentar, 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.
      • Para paquetes UDP fragmentados y todos los demás protocolos, un hash de 3 tuplas de la dirección IP de origen, la dirección IP 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.

      Además, ten en cuenta lo siguiente:

      Si habilitas el balanceo de cargas ponderado, la selección de backend basada en hash se pondera en función de los pesos informados por las instancias de backend. Por ejemplo:

      • Considera un servicio de backend configurado con afinidad de sesión establecida en NONE y una regla de reenvío con el protocolo UDP. Si hay dos instancias de backend en buen estado con pesos 1 y 4, los backends obtendrán el 20% y el 80% de los paquetes UDP, respectivamente.
      • Considera un servicio de backend configurado con afinidad de sesión de 3 tuplas y seguimiento de conexión. La afinidad de sesión es CLIENT_IP_PROTO y el modo de seguimiento de conexiones es PER_SESSION. Si hay tres instancias de backend en buen estado con ponderaciones 0, 2 y 6, los backends obtendrán tráfico para el 0%, el 25% y el 75% de las nuevas direcciones IP de origen (las direcciones IP para las que no hay entradas de tablas de seguimiento de conexiones existentes), respectivamente. El tráfico de las conexiones existentes se dirigirá a los backends asignados previamente.
        Precaución: Si las ponderaciones cambian con frecuencia, el balanceo de cargas ponderado puede ser perjudicial para la afinidad de sesión. Hay varios balanceadores de cargas y el seguimiento de conexiones no se replica en ellos. Para la afinidad de sesión sostenida, se recomienda que no uses el balanceo de cargas ponderado o que lo uses con poca frecuencia.

   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:

      • Paquetes de TCP. 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 es de 5 tuplas, los paquetes de TCP SYN se tratan de manera diferente. A diferencia de los paquetes que no son SYN, descartan cualquier entrada de seguimiento de conexiones que coincida y siempre seleccionan un backend nuevo.
        
        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.

      • Paquetes UDP, ESP y GRE. El seguimiento de conexiones solo está habilitado si la afinidad de sesión se configura en un elemento que no sea NONE.

      • Paquetes ICMP y ICMPv6. No se puede usar el seguimiento de conexiones.

      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:

      • Una entrada en la tabla de seguimiento de conexión vence 60 segundos después de que el balanceador de cargas procesa el último paquete que coincidió con la entrada. Para obtener más información, consulta Tiempo de espera inactivo.
      • 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. La afinidad de sesión se especifica para todo el servicio de backend externo regional, no por cada backend.

Los balanceadores de cargas de red de transferencia externos admiten las siguientes opciones de afinidad de sesión:

• 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, IP de destino (CLIENT_IP). Hash de 2 tuplas de la dirección IP de origen y 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

Para obtener información sobre cómo estas opciones de afinidad de sesión afectan la selección del backend y los métodos de seguimiento de conexiones, consulta esta tabla.

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 externos. Una política de seguimiento de conexiones incluye la siguiente configuración:

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

Modo de seguimiento de conexiones

La habilitación del seguimiento de conexiones depende solo del protocolo del tráfico con balanceo de cargas y de la configuración de afinidad de sesión. El modo de seguimiento especifica el algoritmo de seguimiento de conexiones que se usará cuando esté habilitado el seguimiento de conexiones. Hay dos modos de seguimiento: PER_CONNECTION (predeterminado) y PER_SESSION.

• PER_CONNECTION (predeterminado). Este es el modo de seguimiento predeterminado. Con este modo de seguimiento de conexiones, siempre se realiza un seguimiento del tráfico de TCP por 5 tuplas, sin importar la configuración de afinidad de sesión. Para el tráfico de UDP, ESP y GRE, el seguimiento de conexiones se habilita cuando la afinidad de sesión seleccionada no es NONE. Se realiza un seguimiento de los paquetes UDP, ESP y GRE mediante los métodos de seguimiento descritos en esta tabla.

• PER_SESSION. 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 conexiones de 2 y 3 tuplas, respectivamente, para todos los protocolos (excepto ICMP e ICMPv6, a los que no se puede hacer un seguimiento de conexiones). Para otras configuraciones de afinidad de sesión, el modo PER_SESSION se comporta de manera idéntica al modo PER_CONNECTION.

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)	TCP y UDP sin fragmentar: Hash de 5 tuplas UDP fragmentado y todos los otros protocolos: Hash de 3 tuplas	TCP: Seguimiento de conexión de 5 tuplas Todos los demás protocolos: Seguimiento de conexión desactivado	TCP: Seguimiento de conexión de 5 tuplas Todos los demás protocolos: Seguimiento de conexión desactivado
IP de cliente, IP de destino (CLIENT_IP)	Todos los protocolos: Hash de 2 tuplas	TCP y UDP no fragmentado: Seguimiento de conexión de 5 tuplas UDP fragmentado, ESP y GRE: seguimiento de conexión de 3 tuplas Todos los demás protocolos: Seguimiento de conexión desactivado	TCP, UDP, ESP, GRE: Seguimiento de conexiones de 2 tuplas Todos los demás protocolos: Seguimiento de conexión desactivado
IP de cliente, IP de destino, protocolo (CLIENT_IP_PROTO)	Todos los protocolos: Hash de 3 tuplas	TCP y UDP no fragmentado: Seguimiento de conexión de 5 tuplas UDP fragmentado, ESP y GRE: seguimiento de conexión de 3 tuplas Todos los demás protocolos: Seguimiento de conexión desactivado	TCP, UDP, ESP, GRE: Seguimiento de conexión de 3 tuplas Todos los demás protocolos: Seguimiento de conexión desactivado
IP de cliente, puerto de cliente, IP de destino, puerto de destino, protocolo (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 de 5 tuplas UDP fragmentado, ESP y GRE: seguimiento de conexión de 3 tuplas Todos los demás protocolos: Seguimiento de conexión desactivado	TCP y UDP no fragmentado: Seguimiento de conexión de 5 tuplas UDP fragmentado, ESP y GRE: seguimiento de conexión de 3 tuplas Todos los demás protocolos: Seguimiento de conexión desactivado

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

El comportamiento descrito en esta sección no se aplica a los casos en los que quitas una instancia de backend de un grupo de instancias o quitas un extremo de backend de su NEG, o quitas el grupo de instancias o el NEG 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). Todos los demás protocolos: las conexiones nunca persisten 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. Todos los demás protocolos: las conexiones nunca persisten en backends en mal estado.
NEVER_PERSIST	Todos los protocolos: las conexiones nunca persisten en backends en mal estado.
ALWAYS_PERSIST	TCP: las conexiones persisten en backends en mal estado (todas las afinidades de sesión). ESP, GRE, UDP: las conexiones persisten en backends en mal estado si la afinidad de sesión no es NONE. ICMP, ICMPv6: No aplicable porque no se puede realizar un seguimiento de la conexión. Esta opción solo se debe usar para casos de uso avanzados.	No es posible realizar la configuración.

Nota: Cuando el balanceador de cargas mueve una conexión desde un backend en mal estado, el balanceador de cargas crea una entrada de tabla de seguimiento nueva. La entrada nueva asigna la conexión a un backend diferente según la afinidad de sesión configurada. La entrada nueva sigue siendo válida como cualquier otra. Si el backend en mal estado vuelve a estar en buen estado, esto solo no hará que se quite la entrada de la tabla de seguimiento de conexiones (a menos que active una conmutación por recuperación y se haya inhabilitado el vaciado de conexiones en conmutación por error y conmutación por recuperación).

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

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

• Si el backend en mal estado sigue respondiendo a los paquetes, la conexión continúa hasta que se restablece o se cierra (ya sea por el backend en mal estado o el cliente).
• Si el backend en mal estado envía un paquete de restablecimiento de TCP (RST) o no responde a los paquetes, el cliente puede volver a intentarlo con una conexión nueva, lo que permite que el balanceador de cargas seleccione otro backend en buen estado. Los paquetes de TCP SYN siempre seleccionan un backend nuevo y en buen estado.

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

Tiempo de espera inactivo

Las entradas de las tablas de seguimiento de conexiones vencen 60 segundos después de que el balanceador de cargas procesa el último paquete que coincidió con la entrada. No se puede modificar este valor de tiempo de espera de inactividad.

Balanceo de cargas ponderado

Precaución: Si las ponderaciones cambian con frecuencia, el balanceo de cargas ponderado puede ser perjudicial para la afinidad de sesión. Hay varios balanceadores de cargas y el seguimiento de conexiones no se replica en ellos. Para la afinidad de sesión sostenida, te recomendamos que no uses balanceo de cargas o usarlo con poca frecuencia.

Puedes configurar un balanceador de cargas de red para distribuir el tráfico entre las instancias de backend del balanceador de cargas según las ponderaciones que informa una verificación de estado HTTP mediante el balanceo de cargas ponderado.

El balanceo de cargas ponderado requiere que configures lo siguiente:

• Debes establecer la política del balanceador de cargas de localidad (localityLbPolicy) del servicio de backend como WEIGHTED_MAGLEV.
• Debes configurar el servicio de backend con una verificación de estado de HTTP. Las respuestas de verificación de estado de HTTP deben contener un campo de encabezado de respuesta HTTP personalizado X-Load-Balancing-Endpoint-Weight para especificar los pesos con valores de 0 a 1000 para cada instancia de backend.

Si usas el mismo backend (grupo de instancias o NEG) para varios balanceadores de cargas de red de transferencia externos basados en servicios de backend mediante el balanceo de cargas ponderado, te recomendamos usar una request-path única para cada verificación de estado del servicio de backend. Esto permite que la instancia de extremo asigne diferentes ponderaciones a los servicios de backend diferentes. A fin de obtener más información, consulta Criterios de éxito para verificaciones de estado HTTP, HTTPS y HTTP/2.

A fin de seleccionar un backend para una conexión nueva, se les asigna un orden de prioridad estricto según su ponderación y estado, como se muestra en la siguiente tabla:

Peso	En buen estado	Prioridad de selección del backend
Ponderación mayor que cero	Sí	4
Ponderación mayor que cero	No	3
Ponderación igual a cero.	Sí	2
Ponderación igual a cero.	No	1

Solo los backends de mayor prioridad son aptos para la selección de backend. Si todos los backends aptos tienen ponderación cero, el balanceador de cargas distribuye las conexiones nuevas entre todos los backends aptos y los trata con la misma ponderación. Para ver ejemplos del balanceo de cargas ponderado, consulta Selección de backend y seguimiento de conexiones.

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

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

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

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

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

Vaciado de conexiones

El vaciado de conexiones 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).
• Se quita un backend de un servicio de backend.

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

Nota: Las siguientes recomendaciones sobre cómo manejar paquetes de UDP fragmentados con balanceadores de cargas de red de transferencia externos basados en servicios de backend son diferentes de las recomendaciones para balanceadores de cargas de red de transferencia externos basados en grupos de destino heredados.

Los balanceadores de cargas de red de transferencia externos basados en servicios de backend pueden procesar paquetes UDP fragmentados y no fragmentados. Si tu aplicación usa paquetes UDP fragmentados, ten en cuenta lo siguiente:

• Los paquetes UDP pueden fragmentarse antes de llegar a una red de 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 o L3_DEFAULT por dirección IP con balanceo de cargas y configura la regla de reenvío para aceptar tráfico en todos los puertos. Esto garantiza que todos los fragmentos lleguen a la misma regla de reenvío. Aunque los paquetes fragmentados (que no sea el primer fragmento) no tienen un puerto de destino, configurar la regla de reenvío para procesar el tráfico en todos los puertos también la configura para recibir fragmentos UDP que no tienen información de puertos. A fin de configurar todos los puertos, usa Google Cloud CLI para configurar --ports=ALL o usa la API a fin de configurar allPorts en True.

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

Conmutación por error

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

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

Para obtener más detalles sobre cómo funciona la conmutación por error, consulta Descripción general de los balanceadores de cargas de red de transferencia externos.

¿Qué sigue?

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