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

El balanceo de cargas TCP/UDP interno de Google Cloud 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 interno a la que solo pueden acceder las instancias internas de máquina virtual (VM).

El balanceo de cargas 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 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)

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

  • Tráfico de TCP o UDP (no ambos)
  • Un servicio de backend con esquema de balanceo de cargas: internal
  • VM de backend en una red de VPC
  • VM de backend en todas las zonas dentro de una región
  • Clientes en cualquier región si el acceso global está habilitado

Un balanceador de cargas TCP/UDP interno no es compatible con los siguientes componentes:

Acceso del cliente

Puedes habilitar el acceso global para permitir que las instancias de VM de cliente de cualquier región accedan a tu balanceador de cargas 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. Todavía 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 TCP/UDP internos abordan muchos casos prácticos. En esta sección, se proporcionan algunos ejemplos de alto nivel.

Ejemplos de acceso

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

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

Para obtener ejemplos detallados, consulta Balanceo de cargas 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. Por ejemplo, si incorporas balanceadores de cargas 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 que utiliza balanceadores de cargas HTTP(S) externos y balanceadores de cargas TCP/UDP internos:

Aplicación web de tres niveles con balanceo de cargas HTTP(S) y balanceo de cargas TCP/UDP interno (haz clic para ampliar)
Aplicación web de tres niveles con balanceo de cargas HTTP(S) y balanceo de cargas 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 global disponible en Internet que balancea el tráfico de cargas con el balanceo de cargas 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 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 HTTP(S), acceso global y balanceo de cargas TCP/UDP interno (haz clic para ampliar)
Aplicación web de tres niveles con balanceo de cargas HTTP(S), acceso global y balanceo de cargas TCP/UDP interno (haz clic para ampliar)

Cómo funciona el balanceo de cargas 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 redes virtuales.

A diferencia de un balanceador de cargas basado en dispositivos o instancias de VM, un balanceador de cargas TCP/UDP interno no interrumpe las conexiones de los clientes. En lugar de enviar tráfico a un balanceador de cargas y, luego, a los backends en buen estado, los clientes envían tráfico de forma directa a los backends en buen estado:

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

El balanceador de cargas supervisa el estado de 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 TCP/UDP interno con varios grupos de instancias de backend distribuye conexiones entre las 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 la distribución de tráfico.

Puedes usar cualquier tipo de grupos de instancias, sin administrar, 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 o Windows adecuado o procesos que proporcionen una funcionalidad equivalente. Este entorno invitado se debe poder comunicar 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.

Alta disponibilidad

El balanceador de cargas TCP/UDP interno tiene alta disponibilidad por diseño. No existen pasos especiales para que el balanceador de cargas esté con 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 el software con 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, utiliza 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 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 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 utiliza 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 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.

Especifica la dirección IP para un balanceador de cargas 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

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

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

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 TCP/UDP internos no son proxies, pasan el tráfico a los backends en el mismo protocolo y puerto.

Un balanceador de cargas 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 consecuencias:

  • La subred que especificas para la regla de reenvío no debe ser la misma que las subredes que utilizan 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 seleccionas. De forma 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 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:

  • Especificar al menos uno y hasta cinco puertos, por número
  • Especificar 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

Puedes configurar múltiples reglas de reenvío interno para el mismo balanceador de cargas interno. Cada regla de reenvío debe tener una dirección IP única y solo puede hacer referencia a un solo 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 interno, asegúrate de configurar el software que se ejecuta en las VM de backend para que se vincule a todas las direcciones IP necesarias. La dirección IP de destino de 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 crear una regla de reenvío secundaria, consulta Crea una regla de reenvío en otra subred.

En ese ejemplo, dos reglas de reenvío, una que usa 10.1.2.99 y otra que usa 10.5.6.99, se configuran para el mismo balanceador de cargas. Las VM de backend se deben configurar para recibir paquetes en cualquiera de estas direcciones IP. Una forma de hacerlo es configurar los backends para que se vinculen a cualquier dirección IP (0.0.0.0/0).

Servicio de backend

Cada balanceador de cargas 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 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 de 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:

  • Región: 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 sin administrar, 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 en la 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 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 sin administrar 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 entre 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 basada en la red de la interfaz de red inicial (o única) que utilizan 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. 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 TCP/UDP internos usan la condición 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 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 dado que las verificaciones de estado basadas en HTTP ofrecen opciones apropiadas para ese protocolo. La entrega de 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 las VM de backend no entregan tráfico de tipo HTTP, debes usar una verificación de estado SSL o TCP.

Independientemente del tipo de verificación de estado que crees, Google Cloud envía sondeos de verificación de estado a la dirección IP del balanceador de cargas TCP/UDP interno, lo que 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 a los sondeos de verificación de estado y tráfico con balanceo de cargas enviados a la dirección IP del balanceador de cargas. Para obtener más información, consulta la sección sobre destino de paquetes de sondeo.

Verificaciones de estado y tráfico UDP

Google Cloud 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 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 estado de Google Cloud. Por ejemplo, puedes ejecutar un servidor HTTP simple en cada VM de backend que muestra una respuesta HTTP 200 a Google Cloud. En este ejemplo, debes usar tu propia lógica de ejecución en la VM de backend para asegurarte de que el servidor HTTP muestre 200 solo si el servicio de UDP está configurado y en ejecución 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 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 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 TCP/UDP interno distribuye conexiones nuevas depende de si configuraste la conmutación por error:

  • Si no configuraste la conmutación por error, un balanceador de cargas TCP/UDP interno distribuye conexiones nuevas entre todas 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 conexiones nuevas entre todos los backends como último recurso.

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

De forma predeterminada, el método para distribuir conexiones nuevas utiliza 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 VM todavía administra 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. Configura una afinidad de sesión cuando las VM de backend necesiten realizar un seguimiento de la información de estado de sus clientes cuando envían 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, las cuales especificas para todo el servicio de backend interno y no para cada grupo de instancias de backend:

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

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

Independientemente de la opción de afinidad de sesión que selecciones, Google Cloud 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. 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 TCP/UDP interno como el siguiente salto para una ruta estática personalizada, consulta Conceptos de siguiente salto para el balanceo de cargas TCP/UDP interno.

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

Qué sigue