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 de TCP o UDP entre las instancias de máquina virtual (VM) de una misma región.

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 y su IP de origen no cambia.
    • 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.

En esta página, se describe cómo funciona el balanceo de cargas de red que tiene un servicio de backend en lugar de un grupo de destino. Anteriormente, la única opción para un balanceador de cargas de red era el balanceador de cargas de red basado en grupos de destino. En comparación con los grupos de destino, los servicios de backend te brindan un control más detallado sobre el comportamiento de tu balanceador de cargas.

  • La configuración de un servicio de backend contiene un conjunto de valores, como verificaciones de estado, afinidad de sesión, tiempos de espera para el vaciado de conexiones y políticas de conmutación por error. La mayoría de estas opciones de configuración tienen valores predeterminados que permiten una configuración sencilla para comenzar rápidamente.
  • 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. Los balanceadores de cargas basados en grupos de destino solo admiten verificaciones de estado HTTP heredadas.
  • Los balanceadores de cargas de red basados en servicios de backend admiten el uso de grupos de instancias administrados 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. Los balanceadores de cargas basados en grupos de destino solo admiten grupos de instancias no administrados.

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 para permitir que admitan los sondeos de verificación de estado en 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 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 se coincide con una regla de reenvío, que es una combinación de una dirección IP, un protocolo y uno o más puertos, o bien un rango de puertos particulares. 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 la siguiente sección.

Varias reglas de reenvío

Puedes configurar varias reglas de reenvío externas regionales para el mismo balanceador de cargas de red TCP/UDP externo. 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.
  • Si debes configurar diferentes protocolos, puertos o rangos de puertos con la misma dirección IP externa.

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 de TCP o UDP, pero no ambos, en la dirección IP y los puertos especificados por una o más reglas de reenvío externas regionales. El servicio de backend permite que el tráfico se entregue a las VM de backend en la misma dirección IP y en los mismos puertos a los que se envió el tráfico. El servicio de backend y todas las reglas de reenvío asociadas deben usar el mismo protocolo.

  • Distribución de tráfico. Un servicio de backend permite distribuir el tráfico de acuerdo con una afinidad de sesión configurable. 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 TCP/UDP externo 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. El balanceador de cargas de TCP/UDP externo tiene alta disponibilidad por su diseño. No se necesitan pasos especiales para que el balanceador de cargas tenga alta disponibilidad porque el mecanismo no depende de un solo dispositivo ni de una instancia de VM. Solo necesitas asegurarte de que las instancias de VM de backend se implementen en varias zonas para que el balanceador de cargas pueda solucionar posibles problemas en una zona determinada.

  • 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 y tráfico UDP

Google Cloud no ofrece una verificación de estado que use el protocolo UDP. Cuando usas el balanceo de cargas de red con tráfico UDP, debes ejecutar un servicio basado en TCP en las VM de backend para proporcionar información de verificación de estado.

En esta configuración, se balancean las cargas de las solicitudes del cliente mediante el protocolo UDP y se usa un servicio de TCP para proporcionar información a los sistemas de sondeo de verificación de estado de Google Cloud. Por ejemplo, puedes ejecutar un servidor HTTP simple en cada VM de backend que muestre una respuesta HTTP 200 a los sondeos de verificación de estado. En este ejemplo, 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. Para aceptar el tráfico de cualquier dirección IP en Internet, debes crear una regla de firewall de permiso de entrada para el protocolo y los puertos relevantes mediante 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.

Además, debido a que el balanceo de cargas de red usa verificaciones de estado de Google Cloud, 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

Todos los componentes de un balanceador de cargas de red deben existir en el mismo proyecto. Cuando se usa una VPC compartida, esto significa que todos los componentes de un balanceador de cargas deben existir en un proyecto de servicio o en el proyecto host. Por ejemplo, no puedes colocar algunos componentes en el proyecto host y otros componentes en un proyecto de servicio, y no puedes distribuir backends entre proyectos de servicio.

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 las instancias cuya carga se balancea. Se debe definir una regla de reenvío regional externa en el mismo proyecto que las instancias en el grupo de destino (el proyecto de servicio). 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 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 se configura para abandonar tráfico.

Seguimiento de conexiones y hash coherente

El balanceo de cargas de red usa una tabla de seguimiento de conexión y un algoritmo de hash coherente configurable para determinar cómo se distribuye el tráfico en las VM de backend.

Si el balanceador de cargas tiene una entrada en la tabla de seguimiento de conexiones de un paquete entrante que forma parte de una conexión ya establecida, el paquete se envía a la VM de backend que se determinó antes. El backend que se determinó previamente se registra en la tabla de seguimiento de conexiones del balanceador de cargas.

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

  • Si no se configuró ninguna afinidad de sesión, el balanceador de cargas crea un hash de cinco 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. El balanceador de cargas usa este hash para seleccionar un backend que se encuentre en buen estado.
  • Si configuraste una opción de afinidad de sesión, el balanceador de cargas aún creará un hash, pero a partir de menos fragmentos de información, como se describe en afinidad de sesión.
  • Si el paquete es uno de TCP o uno de UDP en el que la afinidad de sesión se establece en un elemento que no sea NONE, el balanceador de cargas registra el backend seleccionado en su tabla de seguimiento de conexión. Las entradas de la tabla de seguimiento de conexión vencen después de 60 segundos si no se usan.

Comportamiento de las conexiones persistentes

  • Tráfico de TCP. En los paquetes de TCP, el resultado de la verificación de estado de una VM de backend solo controla la distribución de paquetes en las conexiones nuevas. Mientras una VM de backend siga siendo miembro de su grupo de instancias y mientras ese grupo permanezca configurado como un backend para el balanceador de cargas, los paquetes que forman parte de la misma conexión TCP se enviarán a la VM de backend seleccionada previamente, incluso si el resultado de la verificación de estado de esa VM cambió a mal estado. Si el backend en mal estado responde a los paquetes, la conexión no se interrumpirá. Si el backend en mal estado rechaza paquetes o no responde a ellos, el cliente puede volver a intentarlo con una conexión nueva y se puede seleccionar un backend diferente en buen estado para la conexión que se vuelve a intentar.

    Si quitas una VM de backend de su grupo de instancias o si quitas el grupo de instancias del servicio de backend, las conexiones establecidas solo se conservarán como se describe en el vaciado de conexiones.

  • Tráfico UDP. Debido a que el tráfico UDP no tiene sesión, todos los paquetes UDP se procesan sin usar una tabla de seguimiento de conexión de forma predeterminada. Las conexiones UDP no se conservan en backends en mal estado. Sin embargo, si la afinidad de sesión se establece en cualquier valor que no sea NONE, se hará un seguimiento de las conexiones UDP (como las conexiones TCP), pero no se conservarán en backends en mal estado (a diferencia de las conexiones TCP).

En la siguiente tabla, se describe el momento en que el balanceador de cargas usa el seguimiento de conexión y el comportamiento de la conexión persistente para cada protocolo.

Protocolo Seguimiento de conexiones Conserva conexiones en backends en mal estado
TCP SIEMPRE ENCENDIDA
UDP Predeterminado: Desactivado
El seguimiento de conexiones se ACTIVA cuando la afinidad de sesión
se establece en cualquier otra propiedad que no sea NONE.
NO

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. Por ejemplo, puedes dirigir conexiones nuevas del mismo cliente a la misma VM de backend; esto está sujeto a los conceptos que se analizan en la sección de seguimiento de conexiones y hash coherente.

Los balanceadores de cargas de red admiten las siguientes opciones de afinidad de sesión, que se especifican para todo el servicio de backend externo regional, no por cada grupo de instancias de backend por separado.

Afinidad de sesión Método de hash coherente Seguimiento de conexiones Notas
Ninguno
(NONE)
Hash de 5 tuplas Seguimiento de 5 tuplas solo para TCP Para TCP, es lo mismo que para el IP de cliente, el puerto de cliente, la IP de destino, el puerto de destino y el protocolo (hash de 5 tuplas).
Para UDP, el seguimiento de conexiones está inhabilitado de forma predeterminada.
IP de cliente, IP de destino
(CLIENT_IP)
Hash de 2 tuplas de:
• la dirección IP de origen del paquete
• la dirección IP de destino del paquete
Seguimiento de 5 tuplas para TCP y UDP Usa esta opción cuando necesites que todas las conexiones de la misma dirección IP de origen sean entregadas por la misma VM de backend.
IP de cliente, IP de destino, protocolo
(CLIENT_IP_PROTO)
Hash de 3 tuplas de:
• la dirección IP de origen del paquete
• la dirección IP de destino del paquete
• el protocolo
Seguimiento de 5 tuplas para TCP y UDP
IP de cliente, puerto de cliente, IP de destino, puerto de destino, protocolo (5 tuplas)
(CLIENT_IP_PORT_PROTO)
Hash de 5 tuplas Seguimiento de 5 tuplas para TCP y UDP Para TCP, esto es equivalente a NONE.
Para UDP, esta opción habilita el seguimiento de conexiones.

Vaciado de conexiones

El vaciado de conexiones es un proceso que se aplica a las sesiones TCP establecidas cuando quitas 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 realizan actualizaciones progresivas o se reduce la escala verticalmente).

De manera predeterminada, el desvío de conexiones está habilitado. Cuando se habilita, permite que las conexiones TCP establecidas se conserven hasta que la VM ya no exista. Si inhabilitas el vaciado de conexiones, las conexiones TCP establecidas se finalizan lo más rápido posible.

Para obtener más información sobre cómo se activa el vaciado de conexiones y cómo habilitarlo, consulta Habilita el vaciado de conexiones.

Conmutación por error

Puedes configurar un balanceador de cargas TCP/UDP externo 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.

Fragmentación UDP

Si aplicas el balanceo de cargas a paquetes UDP, ten en cuenta lo siguiente:

  • Los paquetes sin fragmentar se manejan con normalidad en todas las configuraciones.
  • Los paquetes UDP pueden fragmentarse antes de llegar a Google Cloud. Es posible que las redes que no son de Google Cloud retrasen paquetes UDP fragmentados porque esperan que lleguen todos los fragmentos o descartan los paquetes fragmentados por completo. Las redes de Google Cloud reenvían fragmentos UDP a medida que llegan.

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 0-65535. Esto garantiza que todos los fragmentos lleguen a la misma regla de reenvío, incluso si no tienen el mismo puerto de destino.
  • Configura la afinidad de sesión como Ninguna (NONE). Esto indica que no se requiere mantener la afinidad, por lo que el balanceador de cargas usará un hash de 5 tuplas a fin de seleccionar un backend para paquetes sin fragmentar y un hash de 3 tuplas para los paquetes fragmentados.

Con esta configuración, los fragmentos UDP del mismo paquete se reenvían a la misma instancia para su reensamblaje.

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 0-65535. Esto garantiza que todos los fragmentos lleguen a la misma regla de reenvío, incluso si no tienen el mismo puerto de destino.

Limitaciones

  • Los grupos de extremos de red (NEG) no se admiten como backends para balanceadores de cargas de red.
  • Si tienes un balanceador de cargas basado en grupos de destino y un balanceador de cargas basado en servicios de backend con el mismo nombre, Cloud Console solo mostrará el balanceador de cargas basado en servicios de backend. Como solución alternativa, usa gcloud o la API para administrar el balanceador de cargas basado en grupos de destino con el mismo nombre.

¿Qué sigue?