Descripción general del balanceo de cargas de redes TCP/UDP externo basado en servicios de backend

El balanceo de cargas de red TCP/UDP externo de Google Cloud (a partir de ahora, balanceo de cargas de red) es un balanceador de cargas regional de transferencia. Un balanceador de cargas de red distribuye el tráfico externo entre instancias de máquinas virtuales (VM) en la misma región.

Puedes configurar un balanceador de cargas de red para el tráfico de TCP, UDP, ICMP y ESP. La compatibilidad con el ESP y el ICMP se encuentran en la fase de vista previa.

Un balanceador de cargas de red puede recibir tráfico de los siguientes servidores:

  • Cualquier cliente en Internet
  • VM de Google Cloud con IP externas
  • VM de Google Cloud que tienen acceso a Internet a través de Cloud NAT o NAT basada en la instancia

El balanceo de cargas de red tiene las siguientes características:

  • Es un servicio administrado.
  • El balanceo de cargas de red se implementa mediante las herramientas de redes virtuales de Andromeda y Google Maglev.
  • Los balanceadores de cargas de red no son proxies.
    • Las VM de backend reciben paquetes con balanceo de cargas, direcciones IP de origen y destino, y el protocolo del paquete y, si el protocolo se basa en puertos, los puertos de origen y de destino sin cambios.
    • Las VM de backend finalizan las conexiones de balanceo de cargas.
    • Las respuestas de las VM de backend van directo a los clientes, no pasan a través del balanceador de cargas. El término del sector para esto es retorno directo del servidor.

Los balanceadores de cargas de red basados en servicios de backend tienen las siguientes características:

  • Backends de grupos de instancias administrados. Los balanceadores de cargas de red basados en servicios de backend admiten el uso de grupos de instancias administrados (MIG) como backends. Los grupos de instancias administrados automatizan ciertos aspectos de la administración de backend y proporcionan una mejor escalabilidad y confiabilidad en comparación con los grupos de instancias no administrados.
  • Control detallado de la distribución del tráfico. La configuración de un servicio de backend contiene un conjunto de valores, como políticas de verificaciones de estado, afinidad de sesión, seguimiento de conexiones, vaciado de conexiones, y conmutación por error. La mayoría de estas opciones de configuración tienen valores predeterminados que te permiten comenzar con rapidez.
  • Verificaciones de estado. Los balanceadores de cargas de red basados en servicios de backend usan verificaciones de estado que coinciden con el tipo de tráfico (TCP, SSL, HTTP, HTTPS o HTTP/2) que distribuyen.

Arquitectura

En el siguiente diagrama, se ilustran los componentes de un balanceador de cargas de red:

Balanceador de cargas de red TCP/UDP externo con servicio de backend regional
Balanceo de cargas de red con servicio de backend regional

El balanceador de cargas está compuesto por varios componentes de configuración. Un solo balanceador de cargas puede tener lo siguiente:

  • Una o más direcciones IP externas regionales
  • Una o más reglas de reenvío externas regionales
  • Un servicio de backend externo regional
  • Uno o más grupos de instancias de backend
  • Verificación de estado asociada al servicio de backend

Además, debes crear reglas de firewall que permitan que el tráfico del balanceo de cargas y los sondeos de verificación de estado lleguen a las VM de backend.

Dirección IP

Un balanceador de cargas de red requiere al menos una regla de reenvío. La regla de reenvío hace referencia a una sola dirección IP externa regional. Se puede acceder a las direcciones IP externas regionales desde cualquier lugar en Internet, pero provienen de un grupo único para cada región de Google Cloud.

Cuando creas una regla de reenvío, puedes especificar el nombre o la dirección IP de una dirección IP externa regional reservada existente. Si no especificas una dirección IP, la regla de reenvío hará referencia a una dirección IP externa regional efímera. Usa una dirección IP reservada si necesitas mantenerla asociada a tu proyecto para reutilizarla después de borrar una regla de reenvío o si necesitas varias reglas de reenvío para hacer referencia a la misma dirección IP.

El balanceo de cargas de red admite direcciones IP externas regionales de nivel Estándar y de nivel Premium. La dirección IP y la regla de reenvío deben usar el mismo nivel de red.

Si deseas conocer los pasos para reservar una dirección IP, consulta Direcciones IP externas.

Regla de reenvío

Una regla de reenvío externa regional especifica el protocolo y los puertos en los que el balanceador de cargas acepta tráfico. Debido a que los balanceadores de cargas de red no son proxies, pasan el tráfico a los backends en el mismo protocolo y los mismos puertos, si el paquete lleva información del puerto. La regla de reenvío y la dirección IP forman el frontend del balanceador de cargas.

El balanceador de cargas conserva las direcciones IP de origen de los paquetes entrantes. La dirección IP de destino para los paquetes entrantes es la dirección IP asociada con la regla de reenvío del balanceador de cargas.

El tráfico entrante coincide con una regla de reenvío, que es una combinación de una dirección IP, un protocolo concretos y, si el protocolo se basa en puertos, uno de los puertos, un rango de puertos o todos los puertos. Luego, la regla de reenvío dirige el tráfico al servicio de backend del balanceador de cargas.

Un balanceador de cargas de red requiere al menos una regla de reenvío. Puedes definir varias reglas de reenvío para el mismo balanceador de cargas como se describe en Varias reglas de reenvío.

Protocolos de reglas de reenvío

El balanceo de cargas de red admite las siguientes opciones de protocolo para cada regla de reenvío: TCP, UDP y L3_DEFAULT (vista previa).

Usa las opciones TCP y UDP para configurar el balanceo de cargas de TCP o UDP. La opción del protocolo L3_DEFAULT permite que un balanceador de cargas de red equilibre la carga de tráfico de TCP, ICMP y ESP, UDP.

Además de admitir protocolos que no sean TCP ni UDP, L3_DEFAULT permite que una sola regla de reenvío entregue varios protocolos. Por ejemplo, los servicios IPSec suelen controlar una combinación de tráfico IKE y NAT-T basado en ESP y UDP. La opción L3_DEFAULT permite que se configure una sola regla de reenvío para procesar todos esos protocolos.

Las reglas de reenvío que usan los protocolos TCP o UDP pueden hacer referencia a un servicio de backend mediante el mismo protocolo que la regla de reenvío o un servicio de backend cuyo protocolo es UNSPECIFIED(vista previa). Las reglas de reenvío L3_DEFAULT solo pueden hacer referencia a un servicio de backend con el protocolo UNSPECIFIED.

En la siguiente tabla, se resume cómo usar esta configuración para diferentes protocolos.

Tráfico con balanceo de cargas Protocolo de regla de reenvío Protocolo de servicio de backend
TCP TCP TCP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP L3_DEFAULT UNSPECIFIED
ICMP (solo solicitud de eco) L3_DEFAULT UNSPECIFIED

Varias reglas de reenvío

Puedes configurar varias reglas de reenvío externas regionales para el mismo balanceador de cargas de red. Opcionalmente, cada regla de reenvío puede tener una dirección IP externa regional diferente, o múltiples reglas de reenvío pueden tener la misma dirección IP externa regional.

La configuración de múltiples reglas de reenvío externas regionales puede ser útil para estos casos prácticos:

  • Si debes configurar más de una dirección IP externa para el mismo servicio de backend.
  • Debes configurar diferentes protocolos y puertos o rangos de puertos no superpuestos para la misma dirección IP externa.

Para una dirección IP determinada, una regla de reenvío L3_DEFAULT puede coexistir con reglas de reenvío con otros protocolos (TCP o UDP), pero no con otra regla de reenvío L3_DEFAULT.

Un paquete que llega a la dirección IP del balanceador de cargas coincide con una regla de reenvío L3_DEFAULT solo si no hay una regla de reenvío más específica disponible (por ejemplo, para tráfico de TCP o UDP). Más específicamente, un paquete que llega a una dirección IP, un protocolo y un puerto coincide con una regla de reenvío L3_DEFAULT solo si no hay otras reglas de reenvío para esa dirección IP que coincidan con el protocolo y el puerto de destino del paquete.

Cuando uses varias reglas de reenvío, asegúrate de configurar el software que se ejecuta en tus VM de backend para que se vincule a todas las direcciones IP externas de las reglas de reenvío del balanceador de cargas.

Servicio de backend regional

Cada balanceador de cargas de red tiene un servicio de backend regional que define el comportamiento del balanceador de cargas y cómo se distribuye el tráfico a sus backends. El nombre del servicio de backend es el nombre del balanceador de cargas de red que se muestra en Google Cloud Console.

Cada servicio de backend define los siguientes parámetros de backend:

  • Protocolo. Un servicio de backend acepta el tráfico en la dirección IP y los puertos (si están configurados) especificados por una o más reglas de reenvío externas regionales. El servicio de backend pasa paquetes a las VM de backend mientras conserva las direcciones IP de origen y destino y el protocolo del paquete y, si el protocolo está basado en puertos, los puertos de origen y destino.

    Los servicios de backend que se usan con balanceadores de cargas de red admiten las siguientes opciones de protocolos: TCP, UDP o UNSPECIFIED (vista previa).

    Los servicios de backend con el protocolo UNSPECIFIED se pueden usar con cualquier regla de reenvío, sin importar el protocolo de reglas de reenvío. Solo se puede hacer referencia a los servicios de backend con un protocolo específico (TCP o UDP) mediante reglas de reenvío con el mismo protocolo (TCP o UDP). Las reglas de reenvío con el protocolo L3_DEFAULT solo pueden hacer referencia a los servicios de backend con el protocolo UNSPECIFIED.

    Consulta la especificación del protocolo de las reglas de reenvío para obtener una tabla con posibles combinaciones de protocolos de reglas de reenvío y servicios de backend.

  • Distribución de tráfico. Un servicio de backend permite distribuir el tráfico de acuerdo con una afinidad de sesión configurable y políticas de seguimiento de conexión. El servicio de backend también se puede configurar para habilitar el vaciado de conexiones y designar backends de conmutación por error para el balanceador de cargas.

  • Verificación de estado. Un servicio de backend debe tener una verificación de estado asociada regional.

Cada servicio de backend opera en una sola región y distribuye el tráfico a la primera interfaz de red (nic0) de las VM de backend. Los backends deben ser grupos de instancias ubicados en la misma región que el servicio de backend (y la regla de reenvío). Los backends pueden ser grupos de instancias no administrados zonales, administrados zonales o administrados regionales.

Los balanceadores de cargas de red basados en servicios de backend admiten grupos de instancias cuyas instancias miembro usan cualquier red de VPC en la misma región, siempre y cuando la red de VPC esté en el mismo proyecto que el servicio de backend. (Todas las VM dentro de un grupo de instancias determinado deben usar la misma red de VPC).

Grupos de instancias de backend

Un balanceador de cargas de red distribuye las conexiones entre las VM de backend contenidas en grupos de instancias administrados o no administrados. Los grupos de instancias pueden ser de alcance regional o zonal.

  • Grupos de instancias administrados regionales Usa los grupos de instancias administrados regionales si puedes implementar tu software mediante plantillas de instancias. Los grupos de instancias administrados regionales distribuyen de manera automática el tráfico entre varias zonas, lo que brinda la mejor opción para evitar posibles problemas en una zona determinada.

    Aquí se muestra un ejemplo de implementación con un grupo de instancias administrado regional. El grupo de instancias tiene una plantilla de instancias que define cómo se deben aprovisionar las instancias, y cada grupo implementa instancias dentro de tres zonas de la región us-central1.

    Balanceador de cargas de red con un grupo de instancias administrado regional
    Balanceo de cargas de red con un grupo de instancias administrado regional
  • Grupos de instancias zonales administrados o no administrados. Usa grupos de instancias zonales en diferentes zonas (en la misma región) para protegerte de posibles problemas en una zona determinada.

    Aquí se muestra un ejemplo de implementación con grupos de instancias zonales. Este balanceador de cargas proporciona disponibilidad en dos zonas.

    Balanceador de cargas de red con grupos de instancias zonales
    Balanceo de cargas de red con grupos de instancias zonales

Verificaciones de estado

El balanceo de cargas de red usa verificaciones de estado regionales para determinar qué instancias pueden recibir conexiones nuevas. Cada servicio de backend del balanceador de cargas de red debe estar asociado con una verificación de estado regional. Los balanceadores de cargas usan el resultado de la verificación de estado para determinar cómo enrutar conexiones nuevas a instancias de backend.

Para obtener más detalles sobre cómo funcionan las verificaciones de estado de Google Cloud, consulta Cómo funcionan las verificaciones de estado.

El balanceo de cargas de red admite los siguientes tipos de verificaciones de estado:

Verificaciones de estado para otro tráfico de protocolo

Google Cloud no ofrece ninguna verificación de estado específica del protocolo más allá de las que se enumeran aquí. Cuando usas el balanceo de cargas de red para balancear las cargas de un protocolo que no sea TCP, debes ejecutar un servicio basado en TCP en las VM de backend a fin de proporcionar la información de verificación de estado requerida.

Por ejemplo, si realizas un balanceo de cargas del tráfico de UDP, las solicitudes del cliente se balancean mediante el protocolo UDP, y debes ejecutar un servicio de TCP para proporcionar información a los sistemas de sondeo de verificación de estado de Google Cloud. Para lograrlo, puedes ejecutar un servidor HTTP simple en cada VM de backend que muestre una respuesta HTTP 200 a los sistemas de sondeo de la verificación de estado. Debes usar tu propia lógica que se ejecuta en la VM de backend para asegurarte de que el servidor HTTP muestre 200 solo si el servicio de UDP está en ejecución y configurado de forma correcta.

Reglas de firewall

Debido a que el balanceo de cargas de red es un balanceador de cargas de paso, puedes controlar el acceso a los backends del balanceador de cargas con las reglas de firewall de Google Cloud. Debes crear reglas de firewall de permiso de entrada o una política de firewall jerárquica de permiso de entrada para autorizar las verificaciones de estado y el tráfico en el que realizas el balanceo de cargas.

Las reglas de reenvío y las reglas de firewall de permiso de entrada o las políticas de firewall jerárquicas de permiso de entrada trabajan juntas de la siguiente manera: una regla de reenvío especifica el protocolo y, si están definidos, los requisitos del puerto que un paquete debe cumplir para que se lo reenvíe a una VM de backend. Las reglas de firewall de permiso de entrada controlan si los paquetes reenviados se entregan a la VM o se descartan. Todas las redes de VPC tienen una regla de firewall de entrada denegada implícita que bloquea los paquetes entrantes de cualquier fuente. La red de VPC predeterminada de Google Cloud incluye un conjunto limitado de reglas de firewall de permiso de entrada prepropagadas.

  • Para aceptar el tráfico de cualquier dirección IP en Internet, debes crear una regla de firewall de permiso de entrada con el rango de origen 0.0.0.0/0. Para permitir solo el tráfico de ciertos rangos de direcciones IP, usa rangos de origen más restrictivos.

  • Como práctica recomendada de seguridad, las reglas de firewall de permiso de entrada solo deben autorizar los protocolos y puertos IP que necesitas. La restricción de la configuración del protocolo (y, si es posible, el puerto) es muy importante cuando se usan reglas de reenvío cuyo protocolo se establece en L3_DEFAULT. Las reglas de reenvío L3_DEFAULT reenvían paquetes para todos los protocolos IP admitidos (en todos los puertos si el protocolo y el paquete tienen información del puerto).

  • El balanceo de cargas de red usa las verificaciones de estado de Google Cloud. Por lo tanto, siempre debes permitir el tráfico de los rangos de direcciones IP de verificación de estado. Puede especificarse que estas reglas de firewall de permiso de entrada sean específicas para el protocolo y los puertos de la verificación de estado del balanceador de cargas.

Direcciones IP para paquetes de solicitud y devolución

Cuando una VM de backend recibe un paquete con balanceo de cargas de un cliente, el origen y el destino del paquete son los siguientes:

  • Fuente: Es la dirección IP externa asociada con una VM de Google Cloud o una dirección IP enrutable por Internet de un sistema que se conecta al balanceador de cargas.
  • Destino: Es la dirección IP de la regla de reenvío del balanceador de cargas.

Debido a que el balanceador de cargas es un balanceador de cargas de paso (no un proxy), los paquetes llegan a la dirección IP de destino de la regla de reenvío del balanceador de cargas. El software que se ejecuta en las VM de backend se debe configurar para hacer lo siguiente:

  • Detecta (vincula) la dirección IP de la regla de reenvío del balanceador de cargas o cualquier dirección IP (0.0.0.0 o ::)
  • Si el protocolo de la regla de reenvío del balanceador de cargas admite puertos: Detecta (vincula a) un puerto que se incluye en la regla de reenvío del balanceador de cargas.

Los paquetes de retorno se envían directamente desde las VM de backend del balanceador de cargas al cliente. Las direcciones IP de origen y destino del paquete de retorno dependen del protocolo:

  • TCP está orientado a la conexión, por lo que las VM de backend deben responder con paquetes cuyas direcciones IP de origen coincidan con la dirección IP de la regla de reenvío. De esta forma, el cliente puede asociar los paquetes de respuesta con la conexión TCP adecuada.
  • UDP, ICMP y ESP no tienen conexión. Las VM de backend pueden enviar paquetes de respuesta cuyas direcciones IP de origen coincidan con la dirección IP de la regla de reenvío o con cualquier dirección IP asignada para la VM. En términos prácticos, la mayoría de los clientes esperan que la respuesta provenga de la misma dirección IP a la que enviaron paquetes.

En la siguiente tabla, se muestra un resumen de los orígenes y destinos de los paquetes de respuesta:

Tipo de tráfico Origen Destino
TCP Es la dirección IP de la regla de reenvío del balanceador de cargas. Es el origen del paquete solicitante.
UDP, ESP, ICMP En la mayoría de los casos prácticos, la dirección IP de la regla de reenvío del balanceador de cargas Es el origen del paquete solicitante.

Cuando una VM tiene una dirección IP externa o cuando usas Cloud NAT, también es posible establecer la dirección IP de origen del paquete de respuesta a la dirección IPv4 interna principal de la NIC de la VM. Google Cloud o Cloud NAT cambian la dirección IP de origen del paquete de respuesta a la dirección IPv4 externa de la NIC o a una dirección IPv4 externa de Cloud NAT para enviar el paquete de respuesta a la dirección IP externa del cliente. No usar la dirección IP de la regla de reenvío como origen es una situación avanzada porque el cliente recibe un paquete de respuesta de una dirección IP externa que no coincide con la dirección IP a la que envió un paquete de solicitud.

Ruta de acceso de retorno

El balanceo de cargas de red usa rutas especiales fuera de tu red de VPC para dirigir las solicitudes y los sondeos de verificación de estado entrantes a cada VM de backend.

El balanceador de cargas conserva las direcciones IP de origen de los paquetes. Las respuestas de las VM de backend van directo a los clientes, no pasan a través del balanceador de cargas. El término del sector para esto es retorno directo del servidor.

Arquitectura de VPC compartida

A excepción de la dirección IP, todos los componentes de un balanceador de cargas de red deben existir en el mismo proyecto. En la siguiente tabla, se resumen los componentes de la VPC compartida para el balanceo de cargas de red:

Dirección IP Regla de reenvío Componentes de backend
Debe definirse una dirección IP externa regional en el mismo proyecto que el balanceador de cargas o el proyecto host de VPC compartida. Se debe definir una regla de reenvío regional externa en el mismo proyecto que las instancias del servicio de backend.

El servicio de backend regional debe definirse en el mismo proyecto y en la misma región donde existen las instancias del grupo de instancias de backend.

Las verificaciones de estado asociadas al servicio de backend deben definirse en el mismo proyecto y en la misma región que el servicio de backend.

Distribución de tráfico

La forma en que un balanceador de cargas de red distribuye las 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 distribuye conexiones nuevas a las VM 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 distribuye las conexiones nuevas entre las VM 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

El balanceo de cargas de red usa algoritmos configurables de selección de backend y seguimiento de conexiones para determinar cómo se distribuye el tráfico a las VM de backend.

El balanceo de cargas de red usa el siguiente algoritmo para distribuir paquetes entre las VM 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 actualmente 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 5 tuplas de la dirección IP de origen del paquete, el puerto de origen, la dirección IP de destino, el puerto de destino y el protocolo
      • Para paquetes UDP fragmentados y todos los demás protocolos, un hash de 3 tuplas de la dirección IP de origen del paquete, la dirección IP de destino y el protocolo

      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:

      • 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 y ESP. El seguimiento de conexiones solo está habilitado si la afinidad de sesión se establece en un elemento que no sea NONE.

      • Paquetes ICMP. 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. Este valor de tiempo de espera de inactividad de 60 segundos no se puede configurar.
      • 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 grupo de instancias de backend.

El balanceo de cargas de red admite 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.

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 UDP y ESP, el seguimiento de conexiones se habilita cuando la afinidad de sesión seleccionada no es NONE. Se realiza un seguimiento de los paquetes UDP y ESP 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, 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 y ESP fragmentados: Seguimiento de conexión de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP, UDP, ESP: 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 y ESP fragmentados: Seguimiento de conexión de 3 tuplas
  • Todos los demás protocolos: Seguimiento de conexión desactivado
  • TCP, UDP, ESP: 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 y ESP fragmentados: 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 y ESP fragmentados: 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 la persistencia de la conexión controla si una conexión existente permanece en un backend seleccionado después de que ese backend se encuentre en mal estado (siempre que 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).

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, UDP: las conexiones persisten en backends en mal estado si la afinidad de sesión no es NONE.

ICMP: no aplicable, ya que ICMP no se puede rastrear en conexiones.

Esta opción solo se debe usar para casos de uso avanzados.

No es posible realizar la configuració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.

Vaciado de conexiones

El vaciado de conexiones es un proceso que se aplica a las conexiones establecidas cuando sucede lo siguiente:

  • se quita una VM de backend de un grupo de instancias, o
  • cuando un grupo de instancias administrado quita una VM de backend (por reemplazo, abandono, cuando se actualiza o reduce el escalamiento)
  • cuando se quita un grupo de instancias 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 habilitar el vaciado de conexiones y cómo habilitarlo, consulta Habilita el vaciado de conexiones.

Fragmentación UDP

El balanceo de cargas de red procesa los paquetes UDP fragmentados y no fragmentados. Los paquetes sin fragmentar se manejan con normalidad en todas las configuraciones. 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.
  • Las redes de VPC de Google Cloud reenvían fragmentos UDP a medida que llegan (sin esperar a que lleguen todos los fragmentos).
  • Las redes que no son de Google 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. Consulta la otra documentación del proveedor de red o del equipo de red para obtener más detalles.

Si se esperan paquetes UDP fragmentados, haz lo siguiente:

  • 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, incluso si no tienen el mismo puerto de destino. Para configurar todos los puertos, configura --ports=ALL mediante la herramienta de línea de comandos de gcloud, o configura allPorts como True mediante la API.

  • Usa uno de los siguientes enfoques para configurar el servicio de backend:

    • Inhabilita la afinidad de sesión y el seguimiento de conexiones. Establece la afinidad de sesión en NONE. El balanceador de cargas usa un hash de 5 tuplas a fin de seleccionar un backend para los paquetes no fragmentados (que tienen información del puerto) y un hash de 3 tuplas para los paquetes fragmentados (que carecen de información del puerto). En esta configuración, los paquetes UDP fragmentados y no fragmentados del mismo cliente se pueden reenviar a backends diferentes.
    • Habilita la afinidad de sesión de 2 o 3 tuplas y el seguimiento de conexiones. Establece la afinidad de sesión en CLIENT_IP o CLIENT_IP_PROTO y el modo de seguimiento de conexiones en PER_SESSION. En esta configuración, los paquetes UDP fragmentados y no fragmentados del mismo cliente se reenvían al mismo backend (sin usar información del puerto).

Usa instancias de destino como backends

Si usas instancias de destino como backends para el balanceador de cargas de red y esperas paquetes UDP fragmentados, 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, incluso si no tienen el mismo puerto de destino. Para configurar todos los puertos, configura --ports=ALL mediante gcloud, o configura allPorts en True mediante la API.

Conmutación por error

Puedes configurar un balanceador de cargas de red para distribuir conexiones entre instancias de máquina virtual (VM) en grupos de instancias de backend principales y, si es necesario, cambiar a grupos de instancias de backend 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 las VM de backend principales no están en buen estado.

De forma predeterminada, cuando agregas un backend al servicio de backend de un balanceador de cargas de red, ese backend será 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.

Si quieres obtener más detalles sobre cómo funciona la conmutación por error, consulta Descripción general de la conmutación por error para el balanceo de cargas de red.

Limitaciones

  • Los grupos de extremos de red (NEG) no se admiten como backends para balanceadores de cargas de red.
  • Los balanceadores de cargas de red basados en servicios de backend no son compatibles con Google Kubernetes Engine.
  • No puedes usar Google Cloud Console para realizar las siguientes tareas:

    • Crear o modificar un balanceador de cargas de red cuya regla de reenvío usa el protocolo L3_DEFAULT.
    • Crear o modificar un balanceador de cargas de red cuyo protocolo de servicio de backend está configurado como UNSPECIFIED.
    • Configurar una política de seguimiento de conexiones para un servicio de backend

    En su lugar, usa la herramienta de línea de comandos de gcloud o la API de REST.

  • Los balanceadores de cargas de red no admiten el intercambio de tráfico entre redes de VPC.

¿Qué sigue?