Descripción general del balanceo de cargas de TCP/UDP interno

El balanceo de cargas de TCP/UDP interno de Google Cloud es un balanceador de cargas regional que te permite ejecutar y escalar los servicios detrás de una dirección IP de balanceo de cargas interno a la que solo pueden acceder tus instancias internas de máquina virtual (VM).

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

Como se muestra en el siguiente diagrama de alto nivel, un servicio de balanceo de cargas de 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 un balanceador de cargas de TCP/UDP interno de alto nivel (haz clic para ampliar)
Ejemplo de un balanceador de cargas de TCP/UDP interno de alto nivel (haz clic para ampliar)

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 TCP/UDP interno admite los siguientes componentes:

  • Un servicio de backend con esquema de balanceo de cargas INTERNAL y el protocolo TCP o UDP (pero no ambos)
  • Grupos de instancias administrados y no administrados de backend que se encuentran en una región y red de VPC
  • Una o más reglas de reenvío, cada una con el protocolo TCP o UDP, que coincide con el protocolo del servicio de backend
  • Cada regla de reenvío con su propia dirección IP única o varias reglas de reenvío que comparten una dirección IP común
  • Cada regla de reenvío con hasta cinco puertos o todos los puertos
  • Si el acceso global está habilitado, los clientes de cualquier región
  • Si el acceso global está inhabilitado, los clientes en la misma región que el balanceador de cargas

Un balanceador de cargas de TCP/UDP interno no es compatible con lo siguiente:

Acceso del cliente

Puedes habilitar el acceso global para permitir que las instancias de VM de cliente de cualquier región accedan al balanceador de cargas de TCP/UDP interno. La VM de cliente debe estar en la misma red o en una red de VPC conectada mediante el intercambio de tráfico entre redes de VPC.

En la siguiente tabla, se muestra un resumen del acceso del cliente.

Acceso global inhabilitado Acceso global habilitado
Los clientes deben estar en la misma región que el balanceador de cargas. También deben estar en la misma red de VPC que el balanceador de cargas o en una red de VPC que esté conectada a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC. Los clientes pueden estar en cualquier región. Aún deben estar en la misma red de VPC que el balanceador de cargas o en una red de VPC que esté conectada a la red de VPC del balanceador de cargas mediante el intercambio de tráfico entre redes de VPC.
Los clientes locales pueden acceder al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de interconexión (VLAN). Estos túneles o adjuntos deben estar en la misma región que el balanceador de cargas. Los clientes locales pueden acceder al balanceador de cargas a través de túneles de Cloud VPN o adjuntos de interconexión (VLAN). Estos túneles o adjuntos pueden estar en cualquier región.

Casos de uso

Los balanceadores de cargas de TCP/UDP internos abordan muchos casos de uso. En esta sección, se proporcionan algunos ejemplos de alto nivel.

Ejemplos de acceso

Puedes acceder a un balanceador de cargas de TCP/UDP interno en tu red de VPC desde una red conectada mediante lo siguiente:

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

Para ver ejemplos detallados, consulta Balanceo de cargas de TCP/UDP interno y redes conectadas.

Ejemplo de servicio web de tres niveles

Puedes usar el balanceo de cargas de TCP/UDP interno junto con otros balanceadores de cargas. Por ejemplo, si incorporas balanceadores de cargas de HTTP(S) externos, el balanceador de cargas externo es el nivel web y depende de los servicios detrás del balanceador de cargas interno.

En el siguiente diagrama, se muestra un ejemplo de una configuración de tres niveles en la que se usan balanceadores de cargas de HTTP(S) externos y balanceadores de cargas de TCP/UDP internos:

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

Ejemplo de servicio web de tres niveles con acceso global

Si habilitas el acceso global, las VM de nivel web pueden estar en otra región, como se muestra en el siguiente diagrama.

En este ejemplo de aplicación de varios niveles, se muestra la siguiente información:

  • Un nivel web orientado a Internet con disponibilidad global que balancea las cargas del tráfico con el balanceo de cargas de HTTP(S)
  • Un nivel de base de datos de backend interno con balanceo de cargas en la región us-east1 al que accede el nivel web global
  • Una VM de cliente que forma parte del nivel web en la región europe-west1 y que accede al nivel de base de datos interno con balanceo de cargas ubicado en us-east1
Aplicación web de tres niveles con balanceo de cargas de HTTP(S), acceso global y balanceo de cargas de TCP/UDP interno (haz clic para ampliar)
Aplicación web de tres niveles con balanceo de cargas de HTTP(S), acceso global y balanceo de cargas de TCP/UDP interno (haz clic para ampliar)

VPC compartida

En la siguiente tabla, se resumen los requisitos de los componentes para el balanceo de cargas de TCP/UDP interno que se usa con una red de VPC compartida. Para ver un ejemplo, consulta Crea un balanceador de cargas de TCP/UDP interno en la página Aprovisiona la VPC compartida.

Dirección IP Regla de reenvío Componentes de backend
Debe definirse una dirección IP interna en el mismo proyecto que las VM de backend.

Para que el balanceador de cargas esté disponible en una red de VPC compartida, la dirección IP interna de Google Cloud debe definirse en el mismo proyecto de servicio en el que se encuentran las VM de backend y debe hacer referencia a una subred en la red de VPC compartida deseada en el proyecto host. La dirección en sí proviene del rango de IP principal de la subred a la que se hace referencia.

Si creas una dirección IP interna en un proyecto de servicio y la subred de la dirección IP se encuentra en la red de VPC del proyecto de servicio, el balanceador de cargas de TCP/UDP interno es local para el proyecto de servicio. No es local para ningún proyecto host de VPC compartida.
Se debe definir una regla de reenvío interna en el mismo proyecto que las VM de backend.

Para que el balanceador de cargas esté disponible en una red de VPC compartida, la regla de reenvío interno debe definirse en el mismo proyecto de servicio en el que se encuentran las VM de backend y debe hacer referencia a la misma subred (en la red de VPC compartida) a la que hace referencia la dirección IP interna asociada.

Si creas una regla de reenvío interno en un proyecto de servicio y la subred de la regla de reenvío se encuentra en la red de VPC del proyecto de servicio, el balanceador de cargas de TCP/UDP interno es local para el proyecto de servicio. No es local para ningún proyecto host de VPC compartida.
En una situación de VPC compartida, las VM de backend se ubican en un proyecto de servicio. En ese proyecto de servicio, debe definirse un servicio de backend interno regional y una verificación de estado.

Otros casos de uso

  • Mediante un balanceador de cargas de TCP/UDP interno como el salto siguiente a una puerta de enlace NAT: puedes enrutar el tráfico a los backends del dispositivo virtual de tu puerta de enlace o firewall a través de un balanceador de cargas de TCP/UDP interno.
  • Concentrador y radio: intercambio de rutas de salto siguiente mediante el intercambio de tráfico entre redes de VPC para configurar una topología de concentrador y radio con los dispositivos virtuales de firewall de salto siguiente ubicados en la red de VPC de hub. Las rutas que usan el balanceador de cargas como el salto siguiente en la red de VPC de hub se pueden usar en cada red de spoke.
  • Balanceo de cargas a varias NIC en las VM de backend.

Para obtener más información sobre estos casos de uso, consulta Balanceadores de cargas de TCP/UDP internos como saltos siguientes.

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

Un balanceador de cargas TCP/UDP interno tiene las siguientes características:

  • Es un servicio administrado.
  • No es un proxy.
  • Se implementa en herramientas de redes virtuales.

A diferencia de un balanceador de cargas de proxy, un balanceador de cargas de TCP/UDP interno no finaliza las conexiones de los clientes y, luego, abre conexiones nuevas a los backends. En cambio, un balanceador de cargas de TCP/UDP interno enruta las conexiones originales directamente de los clientes a los backends en buen estado, sin interrupciones.

  • No hay un dispositivo intermedio ni un punto único de fallo.
  • Las solicitudes del cliente a la dirección IP del balanceador de cargas se dirigen directamente a las VM de backend en buen estado.
  • Las respuestas de las VM de backend en buen estado se dirigen directamente a los clientes, no pasan a través del balanceador de cargas. Las respuestas de TCP usan el retorno directo del servidor. Para obtener más información, consulta Solicitud de TCP y UDP, y paquetes de retorno.

El balanceador de cargas supervisa el estado de la VM mediante sondeos de verificación de estado. Para obtener más información, consulta la sección Verificación de estado.

El entorno invitado de Linux, el entorno invitado de Windows o un proceso equivalente de Google Cloud configuran cada VM de backend con la dirección IP del balanceador de cargas. Las redes virtuales de Google Cloud administran la entrega y el escalamiento del tráfico según corresponda.

Arquitectura

Un balanceador de cargas de TCP/UDP interno con varios grupos de instancias de backend distribuye conexiones entre VM de backend en todos esos grupos de instancias. Para obtener más información sobre el método de distribución y las opciones de configuración, consulta Distribución de tráfico.

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 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 de TCP/UDP internos deben ejecutar el entorno invitado de Linux o Windows adecuado o algún otro proceso que proporcione una funcionalidad equivalente. Este entorno invitado se debe poder comunicar con el servidor de metadatos (metadata.google.internal169.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 de TCP/UDP interno con una red de VPC de modo personalizado o automático. También puedes crear balanceadores de cargas de TCP/UDP internos con una red heredada existente.

Alta disponibilidad

El balanceador de cargas de TCP/UDP interno tiene alta disponibilidad por su diseño. No existen pasos especiales para hacer que el balanceador de cargas tenga alta disponibilidad porque el mecanismo no depende de un solo dispositivo o instancia de VM.

Para asegurarte de que las instancias de VM de backend se implementen en varias zonas, sigue estas recomendaciones de implementación:

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

  • 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 de posibles problemas en cualquier zona.

Componentes

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

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 y red de VPC 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 de TCP/UDP internos deben cumplir con los siguientes requisitos:
• 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 misma red de VPC y 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 los siguientes requisitos:
• Tener un load-balancing-scheme de INTERNAL
• Usar un protocol de TCP o UDP, que coincida con el ip-protocol de la regla de reenvío
• Tener una verificación de estado asociada
• Tener una región asociada. La región de la regla de reenvío y todos los grupos de instancias de backend deben ser iguales que la región del servicio de backend
• Estar asociado con una sola red de VPC. Cuando no se especifica, la red se infiere en función de la red que usa cada interfaz de red predeterminada de VM de backend (nic0).

Aunque el servicio de backend no esté vinculado a una subred específica, la subred de la regla de reenvío debe estar en la misma red de VPC que el servicio de backend.
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 Google Cloud considera que los backends que administra son aptos para recibir tráfico. Solo las VM en buen estado de los grupos de instancias de backend reciben 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, Google Cloud no tiene una verificación de estado para el tráfico de UDP. Para obtener más información, consulta Verificaciones de estado y tráfico de UDP.

Dirección IP interna

El balanceo de cargas de TCP/UDP interno usa una dirección IPv4 interna del rango de IP principal de la subred que seleccionas cuando creas la regla de reenvío interno. La dirección IP no puede ser de un rango de IP secundario de la subred.

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

Reglas de firewall

El balanceador de cargas de TCP/UDP interno requiere las siguientes reglas de firewall:

En el ejemplo de Configura las reglas de firewall, se muestra cómo crear ambas.

Reglas de reenvío

Una regla de reenvío especifica el protocolo y los puertos en los que el balanceador de cargas acepta el tráfico. Debido a que los balanceadores de cargas de TCP/UDP internos no son proxies, pasan el tráfico a los backends en el mismo protocolo y puerto.

Un balanceador de cargas de TCP/UDP interno requiere al menos una regla de reenvío interno. Puedes definir varias reglas de reenvío para el mismo balanceador de cargas.

La regla de reenvío debe hacer referencia a una subred específica en la misma red de VPC y región que los componentes de backend del balanceador de cargas. Este requisito tiene las siguientes implicaciones:

  • No es necesario que la subred que especificas para la regla de reenvío sea la misma que las subredes que usan las VM de backend. Sin embargo, la subred debe estar en la misma región que la regla de reenvío.
  • Cuando creas una regla de reenvío interno, Google Cloud elige una dirección IP interna regional disponible del rango de direcciones IP principal de la subred que selecciones. Como alternativa, puedes especificar una dirección IP interna en el rango de IP principal de la subred.

Reglas de reenvío y acceso global

Las reglas de reenvío del balanceador de cargas de TCP/UDP interno son regionales, incluso cuando el acceso global está habilitado. Después de habilitar el acceso global, la marca allowGlobalAccess de la regla de reenvío interno regional se configura como true.

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 un puerto (hasta cinco) por número
  • Especifica ALL para reenviar el tráfico a todos los puertos.

Una regla de reenvío interno que admite todos los puertos TCP o UDP permite que las VM de backend ejecuten varias aplicaciones, cada una en su propio 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.

Cuando necesites reenviar el tráfico a más de cinco puertos específicos, combina las reglas de firewall con las reglas de reenvío. Cuando crees la regla de reenvío, especifica todos los puertos y, luego, crea las reglas de firewall de entrada allow que solo permiten el tráfico en los puertos deseados. Aplica las reglas de firewall a las VM de backend.

No puedes modificar una regla de reenvío después de crearla. Si necesitas cambiar los puertos especificados o la dirección IP interna de una regla de reenvío interno, debes borrarla y volver a crearla.

Varias reglas de reenvío para un solo servicio de backend

Puedes configurar varias reglas de reenvío interno que todas hagan referencia al mismo servicio de backend interno. Un balanceador de cargas de TCP/UDP interno requiere al menos una regla de reenvío interno.

Configurar varias reglas de reenvío para el mismo servicio de backend te permite hacer lo siguiente, ya sea mediante TCP o UDP (no ambos):

  • Asignar varias direcciones IP al balanceador de cargas. Puedes crear varias reglas de reenvío, cada una con una dirección IP única. Cada regla de reenvío puede especificar todos los puertos o un conjunto de hasta cinco puertos.

  • Asignar un conjunto específico de puertos con la misma dirección IP al balanceador de cargas. Puedes crear varias reglas de reenvío que compartan la misma dirección IP, y cada regla de reenvío debe usar un conjunto específico de hasta cinco puertos. Esta es una alternativa a la configuración de una sola regla de reenvío que especifique todos los puertos.

Para obtener más información sobre situaciones que involucren dos o más reglas de reenvío interno que compartan una dirección IP interna común, consulta Varias reglas de reenvío con la misma dirección IP.

Cuando uses varias reglas de reenvío interno, asegúrate de configurar el software que se ejecuta en las VM de backend para vincularlo a todas las direcciones IP de la regla de reenvío o a cualquier dirección (0.0.0.0/0). La dirección IP de destino para un paquete entregado a través del balanceador de cargas es la dirección IP interna asociada con la regla de reenvío interno correspondiente. Para obtener más información, consulta Solicitud de TCP y UDP, y paquetes de retorno.

Servicio de backend

Cada balanceador de cargas de TCP/UDP interno tiene un servicio de backend interno regional que define los parámetros y el comportamiento de backend. El nombre del servicio de backend es el nombre del balanceador de cargas de TCP/UDP interno 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 los puertos especificados por una o más reglas de reenvío interno. El servicio de backend permite que el tráfico se entregue a las VM de backend en los mismos puertos a los que se envió el tráfico. El protocolo del servicio de backend debe coincidir con el protocolo de la regla de reenvío.

  • Distribución de tráfico. Un servicio de backend permite distribuir el tráfico de acuerdo con una afinidad de sesión configurable.

  • Verificación de estado. Un servicio de backend debe tener una verificación de estado asociada.

Cada servicio de backend opera en una sola región y distribuye el tráfico para las VM de backend en una sola red de VPC:

  • Regionalidad. Los backends son grupos de instancias 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, administrados zonales o administrados regionales.

  • Red de VPC. Todas las VM de backend deben tener una interfaz de red en la red de VPC asociada con el servicio de backend. Puedes especificar de forma explícita una red del servicio de backend o usar una red implícita. En cualquier caso, la subred de cada regla de reenvío interno debe estar en la red de VPC del servicio de backend.

Interfaces de red y servicios de backend

Cada servicio de backend opera en una sola red de VPC y región de Google Cloud. La red de VPC se puede especificar de forma implícita o explícita con la marca --network en el comando gcloud compute backend-services create:

  • Cuando se especifica de forma explícita, la marca --network de la VPC del servicio de backend identifica la interfaz de red en cada VM de backend a la que se balancea la carga del tráfico. Cada VM de backend debe tener una interfaz de red en la red de VPC especificada. En este caso, los identificadores de interfaz de red (nic0 a nic7) pueden ser diferentes entre las VM de backend. Por ejemplo:

    • Diferentes VM de backend en el mismo grupo de instancias no administrado pueden usar identificadores de interfaz distintos si cada VM tiene una interfaz en la red de VPC especificada.
    • El identificador de interfaz no necesita ser el mismo en todos los grupos de instancias de backend. Puede ser nic0 en las VM de backend en un grupo de instancias de backend y nic2 en las VM de backend en otro grupo de instancias de backend.
  • Si no incluyes la marca --network cuando creas el servicio de backend, este elige una red en función de la red de la interfaz de red inicial (o única) que usan todas las VM de backend. Esto significa que nic0 debe estar en la misma red de VPC para todas las VM en todos los grupos de instancias de backend.

Verificación de estado

El servicio de backend del balanceador de cargas debe estar asociado con una verificación de estado global o regional. Las rutas especiales fuera de la red de VPC facilitan la comunicación 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 de TCP/UDP internos usan el estado de verificación de estado para determinar cómo enrutar conexiones nuevas, como se describe en la sección Distribución de tráfico.

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:

  • HTTP, HTTPS o HTTP/2. Si las 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 debido a que las verificaciones de estado basadas en HTTP ofrecen opciones adecuadas para ese protocolo. La entrega de tráfico de tipo HTTP a través de un balanceador de cargas de TCP/UDP interno significa que el protocolo del balanceador de cargas es TCP.
  • SSL o TCP. Si las VM de backend no entregan tráfico de tipo HTTP, debes usar una verificación de estado de SSL o TCP.

Sin importar el tipo de verificación de estado que crees, Google Cloud envía sondeos de verificación de estado a la dirección IP de la regla de reenvío del balanceador de cargas de TCP/UDP interno a la interfaz de red en la VPC que selecciona el servicio de backend del balanceador de cargas. Esto simula la forma en que se entrega el tráfico con balanceo de cargas. El software que se ejecuta en las VM de backend debe responder al tráfico con balanceo de cargas y a los sondeos de verificación de estado enviados a la dirección IP del balanceador de cargas. Si deseas obtener más información, consulta Destino para paquetes de sondeo.

Verificaciones de estado y tráfico de UDP

Google Cloud no ofrece una verificación de estado que use el protocolo UDP. Cuando usas el balanceo de cargas de 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 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 Google Cloud. 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.

Solicitud de TCP y UDP, y paquetes de retorno

Cuando un sistema cliente envía un paquete de TCP o UDP a un balanceador de cargas de TCP/UDP interno, el origen y el destino del paquete son los siguientes:

  • Origen: la dirección IP interna principal del cliente o la dirección IP de uno de los rangos de IP de alias del cliente
  • Destino: la dirección IP de la regla de reenvío del balanceador de cargas

Cuando el balanceador de cargas envía un paquete de respuesta, el origen y el destino de ese paquete dependen del protocolo:

  • El TCP está orientado a la conexión, y los balanceadores de cargas de TCP/UDP internos usan el retorno directo del servidor. Esto significa que los paquetes de respuesta se envían desde la dirección IP de la regla de reenvío del balanceador de cargas.
  • En cambio, UDP no tiene conexión. De forma predeterminada, los paquetes de retorno se envían desde la dirección IP interna principal de la interfaz de red de la instancia de backend. Sin embargo, puedes cambiar este comportamiento. Por ejemplo, si configuras un servidor UDP para que se vincule a la dirección IP de la regla de reenvío, los paquetes de respuesta se enviarán desde la dirección IP de la regla de reenvío.

En la siguiente tabla, se muestra un resumen de los orígenes y destinos de los paquetes de respuesta:

Tipo de tráfico Origen Destino
TCP Es la dirección IP de la regla de reenvío del balanceador de cargas. Es el origen del paquete solicitante.
UDP Depende del software del servidor UDP. Es el origen del paquete solicitante.

Distribución de tráfico

La forma en que un balanceador de cargas de TCP/UDP interno 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 TCP/UDP interno distribuye las 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 las conexiones nuevas 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 TCP/UDP interno distribuye las conexiones nuevas entre las VM en su grupo activo, según una 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.

De forma predeterminada, el método para distribuir las conexiones nuevas 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 las conexiones nuevas. Una sesión de TCP establecida se mantendrá en una VM de backend en mal estado si esta VM todavía controla la conexión.

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. Debes configurar una afinidad de sesión cuando las VM de backend necesiten realizar un seguimiento de la información de estado de los clientes cuando se envía 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 de UDP.

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

  • Ninguna. Esta es la configuración predeterminada, que es, en efecto, la mismo que la de la IP de cliente, el protocolo y el puerto.
  • 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 de TCP/UDP interno es un salto siguiente para una ruta, consulta la siguiente sección de este artículo: Afinidad de sesión y balanceador de cargas de TCP/UDP interno de salto siguiente.

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

Sin importar la opción de afinidad de sesión que selecciones, Google Cloud usa el destino del paquete. Cuando se envía un paquete directamente 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 de TCP/UDP interno como el salto siguiente 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. En los paquetes con un destino dentro del rango de destino de la ruta, la ruta se dirige al balanceador de cargas.

Si deseas usar un balanceador de cargas de TCP/UDP interno como el siguiente salto para una ruta estática personalizada, consulta Balanceadores de cargas de TCP/UDP internos como saltos siguientes.

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

Cambiar los estados de las 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 una VM de backend en buen estado, el balanceador de cargas de TCP/UDP interno no distribuye las conexiones nuevas a la VM en mal estado. Si un cliente tiene afinidad de sesión con esa VM en mal estado, se dirige a la otra VM de backend en buen estado, en lugar de 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 de 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 mayor frecuencia de lo esperado.

    Esto significa que no puedes supervisar con precisión la distribución de tráfico a través de un balanceador de cargas de TCP/UDP interno si te conectas a este desde un solo cliente. La cantidad de clientes que se necesita para supervisar la distribución de 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 es una VM de backend del balanceador de cargas, la VM de cliente o backend siempre responde a las conexiones enviadas a la dirección IP de la regla de reenvío del balanceador de cargas. Esto sucede sin importar si la VM de backend está en buen estado. Sucede en todo el tráfico enviado a la dirección IP del balanceador de cargas, no solo en el tráfico del protocolo y los puertos especificados en la regla de reenvío interno del balanceador de cargas.

    Para obtener más información, consulta Envía solicitudes desde VM con balanceo de cargas.

Límites

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

Próximos pasos