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 se compila en la pila de virtualización de red de Andromeda.

El balanceo de cargas TCP/UDP interno distribuye el tráfico entre las instancias de máquina virtual (VM) internas en la misma región en una red de nube privada virtual (VPC). Te permite ejecutar y escalar tus servicios detrás de una dirección IP interna a la que solo pueden acceder los sistemas en la misma red de VPC o los sistemas conectados a tu red de VPC.

Un servicio de balanceo de cargas TCP/UDP interno tiene un frontend (la regla de reenvío) y un backend (el servicio de backend). Puedes usar grupos de instancias o NEG zonales de GCE_VM_IP como backends en el servicio de backend. En este ejemplo se muestran los backends de grupos de instancias.

Ejemplo de balanceador de cargas de TCP/UDP interno de alto nivel
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:

Casos de uso

Usa el balanceo de cargas de TCP/UDP interno en las siguientes circunstancias:

  • Necesitas un balanceador de cargas de capa 4 de alto rendimiento y de traspaso para el tráfico de TCP o UDP.
  • Si se entrega tráfico a través de TLS (SSL), es aceptable que tus backends finalicen el tráfico SSL en lugar de que lo haga el balanceador de cargas. El balanceador de cargas de TCP/UDP interno no puede finalizar el tráfico SSL.

  • Úsalo si debes reenviar los paquetes originales sin proxy. Por ejemplo, si necesitas que se conserve la dirección IP de origen de cliente.

  • Si tienes una configuración existente que usa un balanceador de cargas de paso y deseas migrarla sin cambios.

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 HTTP(S) externos, el balanceador de cargas HTTP(S) externo es el nivel web y depende de los servicios detrás del balanceador de cargas TCP/UDP 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
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
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)

Usa balanceadores de cargas de TCP/UDP internos como siguientes saltos

Puedes usar un balanceador de cargas de TCP/UDP interno como la próxima puerta de enlace a la cual se reenvían los paquetes en la ruta a su destino final. Para ello, configura el balanceador de cargas como el siguiente salto en una ruta estática personalizada.

Un balanceador de cargas de TCP/UDP interno implementado como siguiente salto en una ruta personalizada procesa todo el tráfico sin importar el protocolo (TCP, UDP o ICMP).

A continuación, figura una arquitectura de muestra que usa un balanceador de cargas de TCP/UDP interno como siguiente salto 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.

Caso práctico de NAT (haz clic para ampliar)
Caso práctico de NAT (haz clic para ampliar)

Los casos de uso adicionales incluyen los siguientes:

  • 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 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. En las VM creadas a partir de imágenes de Google Cloud, el agente invitado (anteriormente, el entorno invitado de Windows o el entorno de invitado de Linux) instala la ruta local para la dirección IP del balanceador de cargas. Las instancias de Google Kubernetes Engine basadas en Container-Optimized OS implementan esto mediante iptables en su lugar.

Las redes virtuales de Google Cloud administran la entrega y el escalamiento del tráfico según corresponda.

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)
  • VM de backend especificadas como:
  • 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

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

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.

Direcciones IP para paquetes de solicitud y devolución

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

Por lo tanto, los paquetes llegan a las VM de backend del balanceador de cargas con la dirección IP de destino del balanceador de cargas. Este tipo de balanceador de cargas no es un proxy, y este es el comportamiento esperado. Por lo tanto, el software que se ejecuta en las VM de backend del balanceador de cargas debe realizar las siguientes acciones:

  • Escuchar (vinculado a) la dirección IP del balanceador de cargas o cualquier dirección IP (0.0.0.0 o ::)
  • Escuchar (vinculado a) un puerto incluido en la regla de reenvío del balanceador de cargas

Los paquetes de retorno se envían directamente desde las VM de backend del balanceador de cargas al cliente. Las direcciones IP de origen y destino del paquete de retorno 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.

Arquitectura

Un balanceador de cargas TCP/UDP interno con varios backends distribuye conexiones entre todos esos backends. 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 grupos de instancias o NEG zonales, pero no una combinación de ambos, como backends para un balanceador de cargas TCP/UDP interno:

  • Si eliges grupos de instancias, puedes usar los no administrados, administrados zonales, administrados regionales o una combinación de estos tipos.
  • Si eliges NEG zonales, debes usar NEG zonales de GCE_VM_IP.

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.

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 y especifica una verificación de estado. Los backends pueden ser grupos de instancias no administrados, administrados zonales, administrados regionales o NEG zonales con extremos de GCE_VM_IP. 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 regla de reenvío y todos los backends deben estar en la misma región que el servicio de backend
• Estar asociados 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 de backend en buen estado reciben tráfico enviado de las VM 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:

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. Hay puntos adicionales que se deben considerar según el tipo de backend:

    Backends de grupos de instancias

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

    Backends de NEG zonales

    • Es posible que diferentes extremos del mismo NEG zonal de GCE_VM_IP usen identificadores de interfaz diferentes.
    • Si especificas un nombre de VM y una dirección IP cuando agregas un extremo al NEG zonal, Google Cloud verifica que el extremo sea una dirección IP interna principal de la NIC de la VM que se encuentra en la red de VPC del NEG seleccionada. Las validaciones fallidas muestran mensajes de error que indican que el extremo no coincide con la dirección IP principal de la NIC de la VM en la red del NEG.
    • Si no especificas direcciones IP cuando agregas extremos al NEG zonal, Google Cloud selecciona la dirección IP interna principal de la NIC de la red de VPC del NEG seleccionada.
  • 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.

Arquitectura con alta disponibilidad

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

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

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

El método para distribuir conexiones nuevas depende de la configuración de afinidad de sesión del balanceador de cargas.

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 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. Configura la afinidad de sesión cuando las VM de backend necesiten realizar un seguimiento de la información de estado de sus clientes. Este es un requisito común para las aplicaciones que necesitan mantener el estado, incluidas las aplicaciones web.

La afinidad de sesión funciona según el criterio del mejor esfuerzo.

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:

Tipo Significado Protocolos compatibles
Ninguna Esta es la configuración predeterminada.

Funciona de la misma manera que la IP de cliente, el protocolo y el puerto.

Tráfico de TCP y UDP
IP de cliente Las conexiones desde la misma dirección IP de origen y destino se envían a la misma instancia, según un hash de 2 tuplas de lo siguiente:
  • Dirección de origen en el paquete de IP
  • Dirección de destino en el paquete de IP
Tráfico de TCP y UDP
IP de cliente y protocolo Las conexiones desde la misma dirección IP de origen y destino y el protocolo se dirigen a la misma instancia, en función de un hash de 3 tuplas de lo siguiente:
  • Dirección de origen en el paquete de IP
  • Dirección de destino en el paquete de IP
  • Protocolo (TCP o UDP)
Tráfico de TCP y UDP
IP de cliente, protocolo y puerto Los paquetes se envían a los backends mediante un hash creado a partir de la siguiente información:
  • Dirección IP de origen del paquete
  • El puerto de origen del paquete (si está presente)
  • Dirección IP de destino del paquete
  • El puerto de destino del paquete (si está presente)
  • protocolo
La dirección de origen, la dirección de destino y la información del protocolo se obtienen del encabezado del paquete de IP. El puerto de origen y el puerto de destino, si están presentes, se obtienen del encabezado de Capa 4.
Por ejemplo, los segmentos de TCP y los datagramas de UDP no fragmentados siempre incluyen un puerto de origen y un puerto de destino. Los datagramas de UDP fragmentados no incluyen información del puerto.
Cuando no hay información de puertos, el hash quíntuple se considera efectivamente un hash triple.
Solo el tráfico de TCP

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 TCP/UDP interno de siguiente salto

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

Conmutación por error

El balanceo de cargas TCP/UDP interno te permite designar algunos backends como backends de conmutación por error. Estos backends solo se usan cuando la cantidad de VM en buen estado en los grupos de instancias de backend principales disminuye por debajo de un umbral configurable. De forma predeterminada, si todas las VM principales y de conmutación por error están en mal estado, como último recurso, Google Cloud distribuirá nuevas conexiones solo entre todas las VM principales.

Cuando agregas un backend a un servicio de backend del balanceador de cargas TCP/UDP interno, de forma predeterminada, ese backend es uno primario. Puedes designar un backend para que sea de conmutación por error cuando lo agregues al servicio de backend del balanceador de cargas o si editas el servicio de backend más adelante.

Para obtener una descripción general detallada del concepto de la conmutación por error en el balanceo de cargas TCP/UDP interno, consulta la descripción general de la conmutación por error para el balanceo de cargas TCP/UDP interno.

Subdivisión

La subdivisión de los balanceadores de cargas TCP/UDP internos te permite escalar tu balanceador de cargas TCP/UDP interno a fin de admitir una mayor cantidad de instancias de VM de backend por servicio de backend interno.

Para obtener información sobre cómo la subdivisión afecta este límite, consulta la sección “Servicios de backend” de las cuotas y los límites de recursos del balanceo de cargas.

De forma predeterminada, la subdivisión está inhabilitada, lo que limita el servicio de backend a una distribución de hasta 250 instancias de backend o extremos. Si tu servicio de backend necesita admitir más de 250 backends, puedes habilitar la subdivisión. Cuando se habilita la subdivisión, se selecciona un subconjunto de instancias de backend para cada conexión de cliente.

En el siguiente diagrama, se muestra un modelo reducido de la diferencia entre estos dos modos de operación.

Compara un balanceador de cargas TCP/UDP interno sin y con subdivisión (haz clic para ampliar)
Compara un balanceador de cargas TCP/UDP interno sin y con subdivisión (haz clic para ampliar)

Sin la subdivisión, el conjunto completo de backends en buen estado se usa mejor, y las conexiones de clientes nuevas se distribuyen entre todos los backends en buen estado según la distribución de tráfico. La subposición impone restricciones de balanceo de cargas, pero permite que el balanceador de cargas admita más de 250 backends.

Para obtener instrucciones de configuración, consulta Subdivisión.

Advertencias relacionadas con la subdivisión

  • Cuando la subdivisión está habilitada, no todos los backends recibirán tráfico de un remitente determinado, incluso cuando la cantidad de backends sea pequeña.
  • Consulta la página de cuotas para ver la cantidad máxima de instancias de backend cuando la subdivisión está habilitada.
  • Solo la afinidad de sesión de 5 tuplas es compatible con la subdivisión.
  • La duplicación de paquetes no es compatible con la subdivisión.
  • Si se habilita o se inhabilita la subdivisión, se interrumpen las conexiones existentes.
  • Cuando se usa la subdivisión a través de Cloud VPN o Cloud Interconnect y no hay suficientes puertas de enlace de VPN (< 10) en Google Cloud, es probable que solo uses la subdivisión de backends del balanceador de cargas. Si los paquetes para una sola conexión TCP se enrutan a una puerta de enlace de VPN diferente, experimentarás el restablecimiento de la conexión. Debe haber suficientes puertas de enlace de VPN en Google Cloud para usar todos los grupos de backend. Si el tráfico de una sola conexión TCP se redirecciona a una puerta de enlace de VPN diferente, se producirán restablecimientos de la conexión.

Límites

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

¿Qué sigue?