Descripción general del balanceo de cargas de redes TCP/UDP externo basado en grupos de destino

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 sin proxy.

El balanceo de cargas de red distribuye el tráfico de TCP o UDP entre las instancias de máquina virtual (VM) de backend de una misma región en una red de nube privada virtual (VPC). 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

Cada balanceador de cargas de red admite tráfico de TCP o UDP (no ambos).

El alcance de un balanceador de cargas de red es regional, no global. Esto significa que todas las instancias de backend de un balanceador de cargas de red deben estar ubicadas en la misma región. Puedes colocar backends en cualquier zona de la región.

El balanceador de cargas de red admite todos los puertos. Puedes usar el balanceo de cargas de red para balancear las cargas de tráfico de TCP y UDP. Debido a que el balanceador de cargas es un balanceador de cargas de paso, tus backends finalizan la conexión TCP o los paquetes UDP balanceados. Por ejemplo, puedes ejecutar un servidor web HTTPS en tus backends y usar un balanceo de cargas de red para enrutar solicitudes a él, y finalizar TLS en los backends.

Arquitectura

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

Un balanceador de cargas de red siempre tiene un grupo de destino. Varias reglas de reenvío pueden hacer referencia al grupo de destino.

El grupo de destino es un backend para el balanceador de cargas. Especifica las instancias de backend entre las que se balancea las cargas del tráfico. Cada regla de reenvío es un frontend para el balanceador de cargas. Ten en cuenta que hay límites en la cantidad de reglas de reenvío y grupos de destino por proyecto.

Los balanceadores de cargas de red balancean la carga en tus sistemas en función de los datos del protocolo IP entrante, como la dirección, el puerto y el tipo de protocolo.

El balanceador de cargas de red es un balanceador de cargas de paso, por lo que tus backends reciben la solicitud original del cliente. El balanceador de cargas de red no aplica ninguna descarga o proxy de seguridad de la capa de transporte (TLS). El tráfico se enruta directamente a tus VM.

Cuando creas una regla de reenvío para el balanceador de cargas, recibes una dirección IP virtual (VIP) efímera o reservas una VIP que se origina en un bloque de red regional.

Luego debes asociar esa regla de reenvío con tus grupos de destino. La VIP se enruta mediante anycast desde los puntos de presencia globales de Google, pero los backends para un balanceador de cargas de red son regionales. El balanceador de cargas no puede tener backends que abarquen múltiples regiones.

Puedes usar firewalls de Google Cloud para controlar o filtrar el acceso a las VM de backend.

El balanceador de cargas de red examina los puertos de origen y de destino, la dirección IP y el protocolo para determinar cómo reenviar paquetes. Para el tráfico de TCP, puedes modificar el comportamiento de reenvío del balanceador de cargas mediante la configuración de la afinidad de sesión. El balanceador de cargas de red reenvía los paquetes a la primera interfaz de red (nic0) de las instancias en el grupo de destino.

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 externa regional asociada con la regla de reenvío del balanceador de cargas.

Algoritmo de distribución de cargas

De forma predeterminada, el valor de afinidad de sesión se establece en NONE para distribuir el tráfico a las instancias. Cloud Load Balancing selecciona una instancia según un hash de la IP y el puerto de origen; la IP y el puerto de destino, y el protocolo. Esto significa que las conexiones TCP entrantes se distribuyen entre instancias, y cada conexión nueva puede ir a una instancia diferente. Todos los paquetes para una conexión se dirigen a la misma instancia hasta que se cierra la conexión. Las conexiones establecidas no se tienen en cuenta en el proceso de balanceo de cargas.

A pesar de la configuración de afinidad de sesión, todos los paquetes para una conexión se dirigen a la instancia elegida hasta que se cierra la conexión. Una conexión existente no tiene impacto en las decisiones de balanceo de cargas para las nuevas conexiones entrantes. Esto puede provocar una pérdida de balance entre backends si se usan conexiones TCP de larga duración.

Puedes elegir una configuración de afinidad de sesión diferente si necesitas que varias conexiones de un cliente vayan a la misma instancia.

Grupos de destino

Un recurso de grupo de destino define un grupo de instancias que deben recibir tráfico entrante a partir de las reglas de reenvío. Cuando una regla de reenvío dirige el tráfico a un grupo de destino, Cloud Load Balancing elige una instancia de estos grupos de destino en función de un hash de la IP y el puerto de origen, y la IP y el puerto de destino. Cada grupo de destino opera en una sola región y distribuye el tráfico a la primera interfaz de red (nic0) de la instancia de backend. Para obtener más información sobre cómo se distribuye el tráfico en las instancias, consulta la sección algoritmo de distribución de cargas.

Los balanceadores de cargas de red no son proxies. Las respuestas de las VM de backend van directo a los clientes, no pasan a través del balanceador de cargas. El balanceador de cargas conserva las direcciones IP de origen de los paquetes. La dirección IP de destino para los paquetes entrantes es la dirección IP externa regional asociada con la regla de reenvío del balanceador de cargas. Por lo tanto, sucede lo siguiente:

  • Las instancias que participan como VM de backend para los balanceadores de cargas de red deben ejecutar el entorno invitado de Linux o el entorno invitado de Windows adecuados, o algún otro proceso que proporcione una funcionalidad equivalente.

    El entorno de SO invitado (o un proceso equivalente) es responsable de configurar las rutas locales en cada VM de backend. Estas rutas permiten que la VM acepte paquetes con un destino que coincida con la dirección IP de la regla de reenvío del balanceador de cargas.

  • En las instancias de backend que aceptan el tráfico con balanceo de cargas, debes configurar el software para que se vincule con la dirección IP asociada a la regla de reenvío del balanceador de cargas (o a cualquier dirección IP, 0.0.0.0/0).

El balanceo de cargas de red es compatible con el escalador automático de Cloud Load Balancing, que permite a los usuarios realizar ajuste de escala automático en los grupos de instancias de un grupo de destino en función de la utilización del backend. Para obtener más información, consulta la sección sobre Escalamiento según el uso de CPU.

Si deseas que tu grupo de destino contenga una sola instancia de VM, deberías considerar usar la característica de reenvío de protocolos en su lugar.

Los grupos de destino solo se pueden usar con reglas de reenvío que controlen el tráfico de TCP y UDP. Para todos los demás protocolos, debes crear una instancia de destino. Debes crear un grupo de destino antes de poder usarlo con una regla de reenvío. Cada proyecto puede tener hasta 50 grupos de destino.

Reglas de reenvío

Las reglas de reenvío funcionan junto con los grupos de destino para admitir el balanceo de cargas. Para usar el balanceo de cargas, debes crear una regla de reenvío que dirija el tráfico hacia grupos de destino específicos. No es posible balancear la carga de tu tráfico sin una regla de reenvío.

Cada regla de reenvío coincide con una dirección IP específica, un protocolo y, opcionalmente, un rango de puertos en un solo grupo de destino. Cuando el tráfico se envía a una dirección IP externa entregada por una regla de reenvío, esta dirige ese tráfico al grupo de destino correspondiente.

Si aplicas el balanceo de cargas a paquetes UDP que pueden fragmentarse antes de llegar a tu red de VPC de Google Cloud, consulta la sección sobre balanceo de cargas y paquetes UDP fragmentados.

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 grupo de destino.
  • Debes configurar diferentes protocolos o rangos de puertos con la misma dirección IP externa para el mismo grupo de destino.

Cuando uses múltiples 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 necesarias. Esto es necesario porque la dirección IP de destino de los paquetes enviados a través del balanceador de cargas es la dirección IP externa regional asociada con la respectiva regla de reenvío externa regional.

Verificaciones de estado

Las verificaciones de estado garantizan que Compute Engine reenvíe las conexiones nuevas solo a las instancias que están activas y listas para recibirlas. Compute Engine envía solicitudes de verificación de estado a cada instancia según la frecuencia especificada. Una vez que una instancia supera la cantidad permitida de fallas de verificación de estado, ya no se la considera apta para recibir tráfico nuevo.

Para permitir un cierre y apagado ordenados de conexiones TCP, las conexiones existentes no se terminan de forma activa. Sin embargo, no se garantiza que las conexiones existentes a un backend en mal estado sigan siendo viables durante períodos prolongados. Si es posible, deberás iniciar un proceso de cierre ordenado lo antes posible para tu backend en mal estado.

El verificador de estado continúa realizando consultas a instancias en mal estado y muestra una instancia al grupo cuando se produce la cantidad especificada de verificaciones correctas. Si todas las instancias están marcadas como UNHEALTHY, el balanceador de cargas dirige el tráfico nuevo a todas las instancias existentes.

El balanceo de cargas de red se basa en verificaciones de estado HTTP heredadas para determinar el estado de la instancia. Incluso si tu servicio no usa HTTP, debes ejecutar un servidor web básico en cada instancia que el sistema de verificación de estado pueda consultar.

Las verificaciones de estado de HTTPS heredadas no son compatibles con los balanceadores de cargas de red y no se pueden usar con la mayoría de los demás tipos de balanceadores de cargas.

Ruta de acceso de retorno

Google Cloud usa rutas especiales no definidas en tu red de VPC para las verificaciones de estado. Para obtener más información, consulta la sección sobre rutas de acceso de retorno del balanceador de cargas.

Reglas de firewall

Las verificaciones de estado de los balanceadores de cargas de red se envían desde estos rangos de IP. Deberás crear reglas de firewall de entrada permitida que acepten el tráfico de esos rangos.

El balanceo de cargas de red es un balanceador de cargas de paso, lo que significa que las reglas de firewall deben permitir el tráfico de las direcciones IP de origen del cliente. Si tu servicio está abierto a Internet, es más fácil permitir el tráfico de todos los rangos de IP. Si deseas restringir el acceso a fin de que solo se permitan ciertas direcciones IP de origen, puedes configurar reglas de firewall para hacer cumplir esa restricción, pero debes permitir el acceso desde los rangos de IP de verificación de estado.

Si deseas ver un ejemplo de regla de firewall y de configuración, consulta las Reglas para el balanceo de cargas de red.

Arquitectura de VPC compartida

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. Debe definirse una regla de reenvío regional externa en el mismo proyecto que las instancias en el grupo de destino (el proyecto de servicio). El grupo de destino debe definirse en el mismo proyecto y en la misma región donde existen las instancias en el grupo de destino. Las verificaciones de estado asociadas con el grupo de destino también deben definirse en el mismo proyecto.

Distribución de tráfico

La forma en que un balanceador de cargas de red basado en grupos de destino distribuye conexiones nuevas depende de cómo se haya configurado la afinidad de sesión.

Afinidad de sesión

La afinidad de sesión controla el método de hash usado para distribuir conexiones nuevas de clientes a las VM de backend del balanceador de cargas. Los balanceadores de cargas de red basados en grupos de destino usan el parámetro sessionAffinity para configurar la afinidad de sesión.

Para obtener más información, consulta cómo usar grupos de destino.

Balanceo de cargas y paquetes UDP fragmentados

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

  1. Los paquetes sin fragmentar se manejan con normalidad en todas las configuraciones.
  2. Los paquetes UDP pueden fragmentarse antes de llegar a Google Cloud. Las redes que intervienen pueden esperar que lleguen todos los fragmentos antes de reenviarlos (esto causa demoras), o pueden perder fragmentos. Google Cloud no espera que lleguen todos los fragmentos; los envía en cuanto llegan.
  3. Debido a que los fragmentos UDP posteriores no contienen el puerto de destino, pueden ocurrir problemas en las siguientes situaciones:

    • Si la afinidad de sesión de los grupos de destino se establece en NONE (afinidad de 5 tuplas), los fragmentos posteriores se podrían perder, porque el balanceador de cargas no puede calcular el hash de 5 tuplas.
    • Si hay más de una regla de reenvío de UDP para la misma dirección IP con balanceo de cargas, los fragmentos posteriores podrían llegar a una regla de reenvío incorrecta.

Si se esperan paquetes UDP fragmentados, haz lo siguiente:

  • Establece la afinidad de sesión en NONE, CLIENT_IP_PROTO o CLIENT_IP.
    • Establecer la afinidad de sesión en NONE indica que no es necesario mantener la afinidad. Por lo tanto, el balanceador de cargas usa un hash de 5 tuplas a fin de seleccionar un backend para paquetes no fragmentados, pero un hash de 3 tuplas para paquetes fragmentados.
    • Establecer la afinidad de sesión en CLIENT_IP_PROTO o CLIENT_IP significa que los puertos de origen y destino no se utilizan para el hash y, por lo tanto, el mismo hash se calcula para paquetes fragmentados y no fragmentados.
  • Usa una sola regla de reenvío de UDP por dirección IP con balanceo de cargas. Esto garantiza que todos los fragmentos lleguen a la misma regla de reenvío.

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.

¿Qué sigue?