Descripción general del balanceo de cargas de redes TCP/UDP externo

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 entre instancias de máquinas virtuales (VM) que se encuentran en la misma región en una red de nube privada virtual (VPC). Un balanceador de cargas de red dirige el tráfico de TCP o UDP a través de backends regionales. Puedes usar el balanceo de cargas de red para balancear las cargas de tráfico de UDP, TCP y SSL en aquellos puertos no compatibles con los balanceadores de cargas del proxy de TCP ni los balanceadores cargas del proxy de SSL.

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

  • El balanceo de cargas de red 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 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.
  • El balanceador de cargas conserva las direcciones IP de origen de los paquetes.
  • La dirección IP de destino de los paquetes 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 el mismo destino que 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).

En el siguiente diagrama, se muestran usuarios de California, Nueva York y Singapur. Todos se conectan a sus recursos de backend, que son myapp, test y travel. Cuando un usuario en Singapur se conecta al backend en el oeste de Estados Unidos, el tráfico ingresa más cerca de Singapur, ya que el rango se enruta mediante Anycast. A partir de ahí, el tráfico se enruta al backend regional.

Tres backends regionales y tres reglas de reenvío (haz clic para agrandar la imagen)
Ejemplo de balanceo de cargas de red (haz clic para agrandar la imagen)

Para obtener información sobre la diferencia entre los balanceadores de cargas de Google Cloud, consulta los siguientes documentos:

Protocolos, esquema y alcance

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

Un balanceador de cargas de red usa un grupo de destino para contener las instancias de backend entre las cuales se balancean las cargas de tráfico.

Un balanceador de cargas de red balancea el tráfico proveniente de Internet. No puedes usarlo para balancear las cargas de tráfico que se origina en Google Cloud entre tus instancias.

El alcance de un balanceador de cargas de red es regional, no global. Esto significa que un balanceador de cargas de red no puede abarcar varias regiones. Dentro de una sola región, el balanceador de cargas administra todas las zonas.

Usa el balanceo de cargas de red en las siguientes circunstancias:

  • Úsalo si necesitas balancear las cargas de tráfico de UDP o de un puerto TCP que no sea compatible con otros balanceadores de cargas.
  • Úsalo cuando sea aceptable hacer que se desencripte el tráfico SSL mediante tus backends en lugar de hacerlo mediante el balanceador de cargas. El balanceador de cargas de red no puede realizar esta tarea. Cuando los backends desencriptan el tráfico SSL, hay una mayor carga de CPU en las VM.
  • Úsalo cuando la autogestión de los certificados SSL del balanceador de cargas sea aceptable para tu caso. Los certificados SSL administrados por Google solo están disponibles para el balanceo de cargas HTTP(S) y el balanceo de cargas de proxy SSL.
  • Úsalo si debes reenviar los paquetes originales sin proxy.
  • Úsalo si tienes una configuración existente que use un balanceador de cargas de paso y deseas migrarla sin cambios.

Arquitectura

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 de un bloque de red regional.

Luego, se asocia esa regla de reenvío con tus backends. 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 varias regiones.

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

El balanceador de cargas de red analiza 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 si configuras la afinidad de sesión.

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 ningún impacto en las decisiones de balanceo de cargas de las nuevas conexiones entrantes. Esto puede provocar un desequilibrio entre los backends si se usan conexiones TCP de larga duración.

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

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

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.

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.

Reglas de reenvío

Las reglas de reenvío funcionan junto con los grupos de destino para asistir al 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
  • Si 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. Las conexiones existentes no se terminan de forma activa, lo que permite que las instancias se apaguen de manera correcta y cierren las conexiones TCP.

El verificador de estado continúa realizando consultas a las instancias en mal estado y devuelve 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.

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 para que solo se permitan ciertas direcciones IP de origen, puedes configurar reglas de firewall a fin de 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.

Afinidad de sesión

El balanceo de cargas de red no usa la afinidad de sesión de servicios de backend. En su lugar, los balanceadores de cargas de red usan grupos de destino para la afinidad de sesión.

Para obtener más información, consulta el parámetro sessionAffinity en Usa 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 CLIENT_IP_PROTO o CLIENT_IP. No uses NONE (Hash de 5 tuplas). Debido a que CLIENT_IP_PROTO y CLIENT_IP no usan el puerto de destino a fin de calcular el hash, pueden calcular el mismo hash para el primer fragmento y los fragmentos posteriores.
  • 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.

Próximos pasos

  • Consulta Configura el balanceo de cargas de red para obtener información sobre la configuración de un balanceador de cargas de red y la distribución de tráfico entre un conjunto de instancias de Apache.