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 los paquetes de balanceo de cargas con las direcciones IP de origen y destino del paquete, el protocolo y, si el protocolo está basado en puertos, los puertos de origen y de destino no se modifican.
    • 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 estos parámetros 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 los sondeos de verificación de estado y tráfico del balanceo de cargas 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 backends en el mismo protocolo y 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 el tráfico de TCP, ICMP, ESP y UDP.

Además de admitir protocolos que no sean TCP y 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 de 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 otro reenvío de 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 precisamente, un paquete que llega a una dirección IP, un protocolo y un puerto coincide con una regla de reenvío de L3_DEFAULT solo si no hay otras reglas de reenvío para esa dirección IP que coincidan con la protocolo y el puerto de destino.

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 los protocolos, las direcciones IP de origen y destino 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 protocolo: 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 las combinaciones posibles del protocolo de servicio de backend y la regla de reenvío.

  • Distribución de tráfico. un servicio de backend permite distribuir el tráfico de acuerdo con las políticas de afinidad de sesión y seguimiento de conexiones configurables. 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 VM de backend contenidas dentro de 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 entrada permitida o una política de firewall jerárquica de entrada para permitir las verificaciones de estado y el tráfico en el que realizas el balanceo de cargas.

Las reglas de reenvío y la entrada permiten que las reglas de firewall o las políticas de firewall jerárquicas funcionen juntas de la siguiente manera: una regla de reenvío especifica el protocolo y, si está definido, los requisitos del puerto que debe cumplir un paquete para que se reenvíen a un VM de backend. Las reglas de firewall de entrada permiten que se controlen si los paquetes reenviados se entregan a la VM o se descartan. Todas las redes de VPC tienen una regla de firewall de denegación de entrada 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 entrada permitida 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 permitir 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 de puerto).

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

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 y seguimiento de conexiones de backend 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 la tabla de seguimiento de conexiones que coincide con las características de un paquete entrante, el paquete se envía al backend especificado por la entrada de la tabla de seguimiento de conexiones. Se considera que el paquete es 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 conexión.
  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 los backends estén en mal estado, en cuyo caso se considerarán todos los backends siempre que la política de conmutación por error no se configurara para disminuir 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 5 tuplas, los paquetes TCP SYN se tratan de manera diferente. A diferencia de los paquetes que no son SYN, descartan cualquier entrada de seguimiento de conexión coincidente y siempre seleccionan un backend nuevo.

        El seguimiento de conexión predeterminado de 5 tuplas se usa en los siguientes casos:

        • el modo de seguimiento es PER_CONNECTION (todos los 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 se habilita 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 de seguimiento se usa, consulta Modo de seguimiento de conexión.

      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 entradas de la tabla de seguimiento de conexiones cuando los backends están en mal estado. Para obtener detalles y cómo personalizar este comportamiento, consulta Persistencia de conexiones 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 la conexión, 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 conexión 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 conexión, 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 la conexión 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 que se describen 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 conexión de 2 y 3 tuplas, respectivamente, para todos los protocolos (excepto ICMP, a los que no se puede hacer un seguimiento de la conexión) 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 estos modos de seguimiento funcionan con diferentes configuraciones 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 conexión, 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 este 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 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 en la opción de 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 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

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 continúa 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 podría volver a intentarlo con una conexión nueva, lo que deja que el balanceador de cargas seleccione otro backend en buen estado. Los paquetes SYN de TCP siempre seleccionan un backend nuevo y en buen estado.

Para obtener información sobre cómo cambiar el comportamiento de la 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 manera predeterminada, el desvío de conexiones está inhabilitado. Cuando está inhabilitado, 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, después de lo cual se 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 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 con la herramienta de línea de comandos de gcloud o configura allPorts en 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 la conexión. 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 sin fragmentar (que tienen información de puerto) y un hash de 3 tuplas para los paquetes fragmentados (que carecen de información de puertos). 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 la conexión 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 de puertos).

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 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:

    • Crea o modifica un balanceador de cargas de red cuya regla de reenvío use el protocolo L3_DEFAULT.
    • Crea o modifica un balanceador de cargas de red cuyo protocolo de servicio de backend esté configurado como UNSPECIFIED.
    • Configura 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.

¿Qué sigue?