Conceptos de balanceo de cargas TCP/UDP interno

El balanceo de cargas TCP/UDP interno es un balanceador de cargas regional que te permite ejecutar y escalar tus servicios detrás de una dirección IP de balanceo de cargas privada que solo es accesible para tus instancias de máquina virtual internas.

Descripción general

El balanceo de cargas TCP/UDP interno de Google Cloud Platform (GCP) distribuye el tráfico entre las instancias de VM en la misma región en una red de VPC mediante una dirección IP privada interna (RFC 1918).

Como se muestra en el siguiente diagrama de alto nivel, un servicio de balanceo de cargas TCP/UDP interno tiene un frontend (la regla de reenvío) y un backend (el servicio de backend y los grupos de instancias).

Ejemplo de balanceador de cargas TCP/UDP interno de alto nivel (haz clic para ampliar)
Ejemplo de balanceador de cargas TCP/UDP interno de alto nivel (haz clic para ampliar)

Protocolos, esquema y alcance

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

Un balanceador de cargas TCP/UDP interno usa un único servicio de backend con un esquema de balanceo de cargas interno, lo que significa que balancea el tráfico dentro de GCP en las instancias. No puedes usarlo para balancear el tráfico que se origina en Internet.

El alcance de un balanceador de cargas TCP/UDP interno es regional, no global. Esto significa que un balanceador de cargas TCP/UDP interno no puede abarcar varias regiones. Dentro de una sola región, el balanceador de cargas administra todas las zonas. Consulta Regiones y zonas.

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

Casos prácticos

Ejemplos de acceso

Puedes acceder a un balanceador de cargas TCP/UDP interno en la red de VPC desde una red conectada mediante estos métodos:

  • Intercambio de tráfico entre redes de VPC
  • Cloud VPN y Cloud Interconnect

Para ver ejemplos detallados, consulta la página sobre el balanceo de cargas TCP/UDP interno y redes conectadas.

Ejemplo de servicio web de tres niveles

Puedes usar el balanceo de cargas TCP/UDP interno junto con otros balanceadores de cargas, como los balanceadores de cargas de HTTP(S), en los que tu nivel web usa el balanceador de cargas externo, que luego depende de los servicios detrás del balanceador de cargas interno.

El siguiente diagrama muestra un ejemplo de una configuración de tres niveles mediante balanceadores de cargas TCP/UDP internos y HTTP(S) externos:

Aplicación web de 3 niveles con balanceo de cargas HTTP(S) y balanceo de cargas TCP/UDP interno (haz clic para agrandar)
Aplicación web de 3 niveles con balanceo de cargas HTTP(S) y balanceo de cargas TCP/UDP interno (haz clic para agrandar)

Cómo funciona el balanceo de cargas TCP/UDP interno

El balanceo de cargas TCP/UDP interno tiene las siguientes características:

  • El balanceador de cargas es un servicio administrado.
  • El balanceador de cargas no es un proxy.
  • Se implementa en redes virtuales.
  • No hay un dispositivo intermedio ni un punto único de fallo.
  • Las respuestas de las VM de backend van directo a los clientes, no pasan a través del balanceador de cargas.

A diferencia de un balanceador de cargas basado en instancias o dispositivos, el balanceo de cargas TCP/UDP interno no finaliza las conexiones de los clientes. En lugar de enviar tráfico a un balanceador de cargas y, luego, a backends, el tráfico se envía de forma directa a los backends. El entorno invitado de GCP en Linux o Windows configura cada VM de backend con la dirección IP del balanceador de cargas y las redes virtuales de GCP administran la entrega del tráfico, además de ajustar la escala según corresponda.

Arquitectura

Un balanceador de cargas TCP/UDP interno con varios grupos de instancias de backend distribuye conexiones entre VM de backend en todos esos grupos de instancias. Consulta la distribución del tráfico para obtener detalles sobre el método de distribución y sus opciones de configuración.

Puedes usar cualquier tipo de grupo de instancias: no administrados, administrados zonales o administrados regionales, pero no grupos de extremos de red (NEG), como backends para el balanceador de cargas.

En la alta disponibilidad se describe cómo diseñar un balanceador de cargas interno que no dependa de una sola zona.

Las instancias que participan como VM de backend para balanceadores de cargas TCP/UDP internos deben ejecutar el entorno invitado de Linux, el entorno invitado de Windows o algún otro proceso que proporcione una funcionalidad equivalente. Este entorno invitado debe permitir comunicarse con el servidor de metadatos (metadata.google.internal, 169.254.169.254) para leer los metadatos de la instancia a fin de generar rutas locales y aceptar el tráfico enviado a la dirección IP interna del balanceador de cargas.

En este diagrama, se ilustra la distribución de tráfico entre las VM ubicadas en dos grupos de instancias diferentes. El tráfico enviado de la instancia del cliente a la dirección IP del balanceador de cargas (10.10.10.9) se distribuye entre las VM de backend en cualquier grupo de instancias. Las respuestas enviadas de cualquiera de las VM de backend activas se entregan directamente a la VM de cliente.

Puedes usar el balanceo de cargas TCP/UDP interno con una red de VPC de modo personalizado o automático. También puedes crear balanceadores de cargas TCP/UDP internos con una red heredada existente.

Solo las VM de cliente en la región pueden acceder al balanceador de cargas TCP/UDP interno. Las VM de cliente en la misma red de VPC deben estar ubicadas en la misma región, pero no necesariamente en la misma subred, para enviar paquetes a un balanceador de cargas TCP/UDP interno. También puedes comunicarte con un balanceador de cargas TCP/UDP interno desde un sistema cliente en una red diferente, siempre que esa otra red esté conectada de forma correcta a la red de VPC en la que se define el balanceador de cargas. Consulta la página sobre el balanceo de cargas TCP/UDP interno y las redes conectadas.

Alta disponibilidad

El balanceador de cargas TCP/UDP interno tiene alta disponibilidad por diseño. No hay 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.

En las siguientes recomendaciones, se describe cómo implementar instancias de VM de backend para que no dependas de una sola zona:

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

  • Si usas grupos de instancias no administrados o administrados zonales, usa varios grupos de instancias en diferentes zonas (en la misma región) para el mismo servicio de backend. Usar varias zonas te protege ante posibles problemas en cualquier zona.

Componentes

Un balanceador de cargas TCP/UDP interno consta de los siguientes componentes de GCP.

Componente Propósito Requisitos
Dirección IP interna Esta es la dirección del balanceador de cargas. La dirección IP interna debe estar en la misma subred que la regla de reenvío interna. La subred debe estar en la misma región que el servicio de backend.
Regla de reenvío interno Una regla de reenvío interno en combinación con la dirección IP interna es el frontend del balanceador de cargas. Define el protocolo y los puertos que acepta el balanceador de cargas y dirige el tráfico a un servicio de backend interno regional. Las reglas de reenvío para balanceadores de cargas TCP/UDP internos deben cumplir con lo siguiente:
• Tener un load-balancing-scheme de INTERNAL
• Usar un ip-protocol de TCP o UDP que coincida con el protocol del servicio de backend
• Hacer referencia a una subnet en la red de VPC en la misma región que el servicio de backend
Servicio de backend interno regional El servicio de backend interno regional define el protocolo que se usa para comunicarse con los backends (grupos de instancias) y especifica una verificación de estado. Los backends pueden ser grupos de instancias no administrados, administrados zonales o administrados regionales. El servicio de backend debe cumplir con lo siguiente:
• Tener un load-balancing-scheme de INTERNAL
• Usar un protocol de TCP o UDP que coincida con el protocol de la regla de reenvío
• Tener una verificación de estado asociada
• Hacer referencia a backends en la misma región. Los grupos de instancias de backend pueden estar en cualquier subred de la región. El servicio de backend en sí no está vinculado a ninguna subred específica.
Verificación de estado Cada servicio de backend debe tener una verificación de estado asociada. La verificación de estado define los parámetros según los cuales GCP considera que los backends que administra son aptos para recibir tráfico. Solo las VM en buen estado en los grupos de instancias de backend recibirán el tráfico enviado de las VM de cliente a la dirección IP del balanceador de cargas. Aunque la regla de reenvío y el servicio de backend pueden usar TCP o UDP, GCP no tiene una verificación de estado para el tráfico UDP. Para obtener más información, consulta las verificaciones de estado y tráfico UDP.

Dirección IP interna

El balanceo de cargas TCP/UDP interno usa una dirección IPv4 interna (privada, RFC 1918) del rango de IP principal de la subred que seleccionas cuando se crea la regla de reenvío interno. La dirección IP no puede ser de un rango de IP secundario de la subred.

Se especifica la dirección IP para un balanceador de cargas TCP/UDP interno cuando creas la regla de reenvío. Puedes optar por recibir una dirección IP efímera o usar una dirección IP reservada.

Reglas de reenvío

El balanceo de cargas TCP/UDP interno requiere que haya al menos una regla de reenvío interna en una subred en la misma región que el servicio de backend y los grupos de instancias (en conjunto, sus componentes de backend). Una regla de reenvío interno debe estar en la misma región y usar el mismo protocolo que el servicio de backend del balanceador de cargas.

La regla de reenvío se encuentra donde se definen los puertos en los que el balanceador de cargas acepta tráfico. Los balanceadores de cargas TCP/UDP internos no son proxies; pasan el tráfico a backends en el mismo puerto en el que se recibe el tráfico. Debes especificar al menos un número de puerto por regla de reenvío.

Además de los puertos, debes hacer referencia a una subred específica en tu red de VPC cuando crees una regla de reenvío interno. La subred que especifiques para la regla de reenvío no tiene que ser la misma que cualquiera de las subredes que usan las VM de backend. Sin embargo, la regla de reenvío, la subred y el servicio de backend deben estar todos en la misma región. Cuando creas una regla de reenvío interno, GCP elige una dirección IP interna disponible del rango de direcciones IP principal de la subred que selecciones. Si no, puedes especificar una dirección IP interna en el rango de IP principal de la subred.

Reglas de reenvío y especificaciones de puertos

Cuando creas una regla de reenvío interno, debes elegir una de las siguientes especificaciones de puerto:

  • Especifica al menos uno y hasta cinco puertos, por número
  • Especifica ALL para reenviar el tráfico a todos los puertos

Crea una regla de reenvío interna que admita todos los puertos para reenviar todo el tráfico de un protocolo determinado (como TCP) a un solo balanceador de cargas interno. Esto permite que las VM de backend ejecuten varias aplicaciones, una por puerto. El tráfico enviado a un puerto determinado se entrega a la aplicación correspondiente y todas las aplicaciones usan la misma dirección IP.

Si te preocupa abrir aplicaciones de backend en todos los puertos, puedes implementar reglas de firewall en las VM de backend para configurar el alcance del tráfico recibido a los puertos esperados.

No puedes modificar las reglas de reenvío después de crearlas. Si necesitas cambiar los puertos especificados o la dirección IP interna para una regla de reenvío interno, debes borrar y reemplazar la regla de reenvío.

Múltiples reglas de reenvío

Puedes configurar múltiples reglas de reenvío interno para el mismo balanceador de cargas interno. Cada regla de reenvío debe tener su propia dirección IP única y solo puede hacer referencia a un único servicio de backend. Varias reglas de reenvío internas pueden hacer referencia al mismo servicio de backend.

La configuración de varias reglas de reenvío interno puede ser útil si necesitas más de una dirección IP para el mismo balanceador de cargas TCP/UDP interno o si necesitas asociar ciertos puertos con diferentes direcciones IP. Cuando uses varias reglas de reenvío internas, asegúrate de configurar el software que se ejecuta en tus VM de backend a fin de que se una a todas las direcciones IP necesarias, ya que las direcciones IP de destino para los paquetes entregados a través del balanceador de cargas es la dirección IP interna asociada con la respectiva regla de reenvío interno.

En la página sobre la configuración del balanceo de cargas TCP/UDP interno, consulta el procedimiento para crear una regla de reenvío secundaria. En ese ejemplo, dos reglas de reenvío, una con 10.1.2.99 y la otra con 10.5.6.99, están configuradas para el mismo balanceador de cargas. Las VM de backend deben configurarse para recibir paquetes en cualquiera de estas direcciones IP. Una forma de hacerlo es configurar los backends para que se unan a cualquier dirección IP (0.0.0.0/0).

Servicio de backend

Cada balanceador de cargas TCP/UDP interno usa un servicio de backend interno regional. El nombre del servicio de backend es el nombre del balanceador de cargas TCP/UDP interno que se muestra en GCP Console.

El servicio de backend acepta el tráfico dirigido a él por una o más reglas de reenvío interno. Un servicio de backend interno regional acepta tráfico de TCP o UDP, pero no ambos, y entrega tráfico a VM de backend en los mismos puertos a los que se envió tráfico, según la regla de reenvío.

Los servicios de backend deben tener al menos un grupo de instancias de backend y una verificación de estado asociada. Los backends pueden ser grupos de instancias no administrados, administrados zonales o administrados regionales en la misma región que el servicio de backend (y la regla de reenvío). El servicio de backend distribuye el tráfico a las VM de backend y administra la afinidad de sesión, si está configurada.

Verificación de estado

El servicio de backend del balanceador de cargas debe estar asociado con una verificación de estado. Se usan rutas especiales fuera de la red de VPC para facilitar las comunicaciones entre los sistemas de verificación de estado y los backends.

Puedes usar una verificación de estado existente o definir una nueva. Los balanceadores de cargas TCP/UDP internos solo envían tráfico a las VM de backend que aprueban sus verificaciones de estado. Sin embargo, si todas las VM de backend fallan sus verificaciones de estado, GCP distribuye el tráfico entre todas ellas.

Puedes usar cualquiera de los siguientes protocolos de verificación de estado. El protocolo de la verificación de estado no tiene que coincidir con el protocolo del balanceador de cargas en sí mismo.

  • HTTP, HTTPS o HTTP/2: si tus VM de backend entregan tráfico mediante HTTP, HTTPS o HTTP/2, es mejor usar una verificación de estado que coincida con ese protocolo, ya que las que están basadas en HTTP ofrecen opciones apropiadas para ese protocolo. Ten en cuenta que entregar tráfico de tipo HTTP a través de un balanceador de cargas TCP/UDP interno significa que el protocolo del balanceador de cargas es TCP.
  • SSL o TCP: si tus VM de backend no entregan tráfico de tipo HTTP, debes usar una verificación de estado SSL o TCP.

Sin importar el tipo de verificación de estado que crees, GCP envía sondeos de verificación de estado a la dirección IP del balanceador de cargas TCP/UDP interno mediante una simulación de cómo se entregaría el tráfico de balanceo de cargas. El software que se ejecuta en las VM de backend debe responder al tráfico de balanceo de cargas y a los sondeos de verificación de estado enviados a la dirección IP del balanceador de cargas en sí mismo. Para obtener más información, consulta la página sobre el destino de los paquetes de verificación de estado.

Verificaciones de estado y tráfico UDP

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

En esta configuración, se balancean las cargas de las solicitudes de los clientes mediante el protocolo UDP y se usa un servicio TCP para proporcionar información a los que realizan los sondeos de verificación de estado de GCP. Por ejemplo, puedes ejecutar un servidor HTTP simple en cada VM de backend que muestra una respuesta HTTP 200 a GCP. 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 UDP está en ejecución y configurado de forma correcta.

Distribución del tráfico

La forma en la que un balanceador de cargas TCP/UDP interno distribuye nuevas conexiones depende de si configuraste o no la conmutación por error:

  • Si no configuraste la conmutación por error, un balanceador de cargas TCP/UDP interno distribuye las conexiones nuevas entre todas tus 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.

  • Si configuraste la conmutación por error, un balanceador de cargas TCP/UDP interno distribuye una nueva conexión entre las VM en su grupo activo, de acuerdo con una política de conmutación por error que configures. Cuando todas las VM de backend están en mal estado, puedes optar por dejar de recibir tráfico.

De manera predeterminada, el método para distribuir nuevas conexiones usa un hash calculado a partir de cinco datos: la dirección IP del cliente, el puerto de origen, la dirección IP de la regla de reenvío interno del balanceador de cargas, el puerto de destino y el protocolo. Puedes modificar el método de distribución de tráfico para el tráfico de TCP si especificas una opción de afinidad de sesión.

Con la verificación de estado se controla la distribución de conexiones nuevas. Una sesión de TCP establecida se mantendrá en una VM de backend en mal estado, si esta todavía administra la conexión.

Opciones de afinidad de sesión

La afinidad de sesión controla la distribución de conexiones nuevas de los clientes a las VM de backend del balanceador de cargas. Configura la afinidad de sesión cuando las VM de backend necesiten realizar un seguimiento de la información de estado de sus clientes cuando envíen tráfico de TCP. Este es un requisito común para las aplicaciones web.

La afinidad de sesión funciona según el criterio del mejor esfuerzo para el tráfico de TCP. Debido a que el protocolo UDP no admite sesiones, la afinidad de sesión no afecta al tráfico UDP.

Los balanceadores de cargas TCP/UDP internos admiten las siguientes opciones de afinidad de sesión, que se especifican para todo el servicio de backend interno, no para cada grupo de instancias de backend:

  • Ninguno: esta es la configuración predeterminada, que es, en efecto, lo mismo que el puerto y el protocolo IP de cliente.
  • IP de cliente: dirige las solicitudes de un cliente específico a la misma VM de backend en función de un hash creado a partir de la dirección IP del cliente y la dirección IP de destino.
  • IP de cliente y protocolo: dirige las solicitudes de un cliente en particular a la misma VM de backend en función de un hash creado a partir de tres datos: la dirección IP del cliente, la dirección IP de destino y el protocolo del balanceador de cargas (TCP o UDP).
  • IP de cliente, protocolo y puerto: dirige las solicitudes de un cliente específico a la misma VM de backend en función de un hash creado a partir de estos cinco datos:

    • Dirección IP de origen del cliente que envía la solicitud
    • Puerto de origen del cliente que envía la solicitud
    • Dirección IP de destino
    • Puerto de destino
    • Protocolo (TCP o UDP)

    La dirección IP de destino es la dirección IP de la regla de reenvío del balanceador de cargas, a menos que los paquetes se entreguen al balanceador de cargas debido a una ruta estática personalizada. Si un balanceador de cargas TCP/UDP interno es el próximo salto de una ruta, consulta la página sobre afinidad de sesión y balanceador de cargas TCP/UDP interno de próximo salto.

Afinidad de sesión y balanceador de cargas TCP/UDP interno de siguiente salto

Sin importar la opción de afinidad de sesión que elijas, GCP usa el destino del paquete. Cuando se envía un paquete de forma directa al balanceador de cargas, el destino del paquete coincide con la dirección IP de la regla de reenvío del balanceador de cargas.

Sin embargo, cuando se usa un balanceador de cargas TCP/UDP interno como el siguiente salto para una ruta estática personalizada, es probable que el destino del paquete no sea la dirección IP de la regla de reenvío del balanceador de cargas. Para los paquetes con un destino dentro del rango de destino de la ruta, la ruta se dirige al balanceador de cargas.

Afinidad de sesión y condición de verificación de estado

Cambiar las condiciones de estado de VM de backend puede causar una pérdida de afinidad de sesión. Por ejemplo, si una VM de backend está en mal estado y hay al menos otra VM de backend en buen estado, un balanceador de cargas TCP/UDP interno no distribuirá conexiones nuevas a la VM en mal estado. Si un cliente tenía afinidad de sesión con esa VM en mal estado, se dirigirá a la otra VM de backend en buen estado y perderá su afinidad de sesión.

Prueba conexiones de un solo cliente

Cuando se prueban las conexiones a la dirección IP de un balanceador de cargas TCP/UDP interno desde un único sistema cliente, debes tener en cuenta lo siguiente:

Si el sistema cliente no es una VM cuyas cargas se balancean, es decir, no es una VM de backend, las conexiones nuevas se entregan a las VM de backend en buen estado del balanceador de cargas. Sin embargo, debido a que todas las opciones de afinidad de sesión dependen de al menos la dirección IP del sistema cliente, es posible que las conexiones del mismo cliente se distribuyan a la misma VM de backend con más frecuencia de lo esperado. Esto significa que no puedes supervisar con precisión la distribución del tráfico a través de un balanceador de cargas TCP/UDP interno si te conectas a él desde un solo cliente. La cantidad de clientes que se necesita para supervisar la distribución del tráfico varía según el tipo de balanceador de cargas, el tipo de tráfico y la cantidad de backends en buen estado.

Si la VM de cliente también es una VM de backend del balanceador de cargas, a las conexiones enviadas a la dirección IP de la regla de reenvío del balanceador de cargas siempre las responde la propia VM de cliente/backend. Esto sucede sin importar si la VM de backend está o no en buen estado y sucede para todo el tráfico que se envía a la dirección IP del balanceador de cargas, no solo el tráfico en el protocolo y los puertos especificados en la regla de reenvío interno del balanceador de cargas. Para obtener más información, consulta la página sobre cómo enviar solicitudes desde VM con balanceo de cargas.

Límites

Para obtener información sobre cuotas y límites, consulta las cuotas de recursos de balanceo de cargas.

Próximos pasos