Conceptos de balanceo de cargas de red

El balanceo de cargas de red es un balanceador de cargas regional sin proxy.

Descripción general

El balanceo de cargas de red de Google Cloud Platform (GCP) distribuye el tráfico entre las instancias de VM en la misma región en una red de VPC.

En un balanceador de cargas de red, las reglas de reenvío dirigen el tráfico de TCP y UDP a través de backends regionales.

Puedes usar el balanceo de cargas de red para balancear las cargas del tráfico de UDP, TCP y SSL en los puertos que no son compatibles con los balanceadores de cargas de proxy TCP y proxy SSL.

En el siguiente diagrama, se muestran los usuarios de California, Nueva York y Singapur. Todos se conectan a sus recursos de backend, que son myapp, test y travel. Cuando un usuario de Singapur se conecta al backend en el oeste de Estados Unidos, el tráfico entra 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 ampliar)
Ejemplo de balanceo de cargas de red (haz clic para ampliar)

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 que se balancean las cargas del tráfico.

Un balanceador de cargas de red balancea el tráfico proveniente de Internet. No puedes usarlo para balancear las cargas del tráfico que se origina en GCP 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. Consulta Regiones y zonas.

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

  • Si necesitas balancear las cargas del tráfico de UDP o de un puerto TCP que no sea compatible con otros balanceadores de cargas.
  • Si es 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.
  • Si la autogestión de los certificados SSL del balanceador de cargas es aceptable para tu caso. Los certificados SSL administrados por Google solo están disponibles para el balanceo de cargas de proxy SSL y HTTPS.
  • Si debes reenviar los paquetes originales sin proxy.
  • Si tienes una configuración existente que usa un balanceador de cargas de paso y deseas migrarla sin cambios.

Consulta la página sobre cómo elegir un balanceador de cargas y la descripción general del balanceo de cargas para obtener más información acerca de cómo los balanceadores de cargas de Cloud se diferencian entre sí.

Acerca del balanceo de cargas de red

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

  • Es un servicio administrado.
  • 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 para los paquetes es la dirección IP externa regional asociada con la regla de reenvío del balanceador de cargas.

Por consiguiente, sucede lo siguiente:

  • Las instancias que participan como VM de backend para balanceadores de cargas de red se deben ejecutar en el entorno de invitado de Linux, el entorno de invitado de Windows 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 tráfico con balanceo de cargas, debes configurar el software para que se vincule a la dirección IP asociada con la regla de reenvío del balanceador de cargas (o a cualquier dirección IP, 0.0.0.0/0).

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 transferencia 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 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 múltiples regiones.

Puedes usar firewalls de GCP 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 si configuras la afinidad de sesión.

Algoritmo de distribución de cargas

De forma predeterminada, para distribuir el tráfico a las instancias, el valor de afinidad de sesión se establece en NONE. El balanceo de cargas de Google Cloud 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. Consulta sessionAffinity en la documentación de grupos de destino para obtener más información.

Grupos de destino

Un recurso de grupo de destino define un grupo de instancias que deben recibir tráfico entrante a partir las reglas de reenvío. Cuando una regla de reenvío dirige el tráfico a un grupo de destino, el balanceo de cargas de Google Cloud 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. Consulta la sección sobre el algoritmo de distribución de cargas para obtener más información sobre cómo se distribuye el tráfico en las instancias.

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 máquina virtual, deberías considerar usar la característica de reenvío de protocolo 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 del uso de CPU. Para obtener más información, consulta la sección sobre el escalamiento en función del uso de CPU.

Obtén más información sobre los grupos de destino y cómo configurarlos.

Reglas de reenvío

Las reglas de reenvío funcionan junto con los grupos y las instancias de destino para asistir a las características de balanceo de cargas y de reenvío de protocolos. Para usar el balanceo de cargas y el reenvío de protocolos, debes crear una regla de reenvío que dirija el tráfico a grupos de destino específicos (para el balanceo de cargas) o instancias de destino (para el reenvío de protocolos). No es posible usar ninguna de estas características sin una regla de reenvío.

Los recursos de reglas de reenvío se encuentran en la colección de reglas de reenvío. Cada regla de reenvío hace coincidir una dirección IP, un protocolo y, como opción, un rango de puertos particulares con un solo grupo o instancia de destino. Cuando el tráfico se envía a una dirección IP externa entregada por una regla de reenvío, esta dirige el tráfico al grupo o instancias de destino correspondientes. Puedes crear hasta 50 objetos de regla de reenvío por proyecto.

Obtén más información sobre las reglas de reenvío y cómo configurarlas.

Si usas balanceo de cargas en paquetes UDP que pueden fragmentarse antes de llegar a tu red de nube privada virtual (VPC) de Google Cloud Platform (GCP), consulta la sección sobre balanceo de cargas y paquetes UDP fragmentados.

Múltiples reglas de reenvío

Puedes configurar múltiples reglas de reenvío externas regionales para el mismo balanceador de cargas TCP/UDP de red. Cada regla de reenvío puede tener una dirección IP externa regional única, o múltiples reglas de reenvío pueden hacer referencia a la misma dirección IP externa regional. Múltiples reglas de reenvío pueden hacer referencia al mismo proxy de destino.

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 las direcciones IP de destino de los paquetes enviados a través del balanceador de cargas incluyen 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 instancias que estén activas y listas para recibirlas. Compute Engine envía solicitudes de verificación de estado a cada instancia con la frecuencia especificada. Una vez que una instancia supera la cantidad permitida de fallas de verificación de estado, ya no se considera una instancia 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 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.

Ruta de acceso de retorno

GCP usa rutas especiales no definidas en la red de VPC para las verificaciones de estado. Para obtener información completa sobre esto, lee acerca de las rutas de acceso de retorno del balanceador de cargas.

Reglas de firewall y balanceo de cargas de red

Las verificaciones de estado de los balanceadores de cargas de red se envían desde los siguientes rangos de IP. Deberás crear reglas de firewall de entrada permitida que acepten el tráfico de esos rangos. Si deseas obtener una regla de firewall de ejemplo, consulta las reglas para el balanceo de cargas de red.

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

Consulta el parámetro sessionAffinity en los 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 opciones de configuración.
  2. Los paquetes UDP pueden fragmentarse antes de llegar a GCP. Las redes que intervienen pueden esperar a que lleguen todos los fragmentos antes de reenviarlos (esto causa demoras), o pueden perder fragmentos. GCP no espera a que lleguen todos los fragmentos; reenvía cada fragmento en cuanto llega.
  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 pueden 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 para 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 la sección sobre cómo configurar 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 del tráfico entre un conjunto de instancias de Apache.

Comenzar

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...