Balanceadores de cargas TCP/UDP internos como siguientes saltos

El balanceo de cargas TCP/UDP interno es un balanceador de cargas regional que te permite ejecutar y escalar tus servicios detrás de una dirección IP de balanceo de cargas interno. Puedes usar un balanceador de cargas 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 eso, configura el balanceador de cargas como el siguiente salto en una ruta estática personalizada.

Esta configuración es útil en los siguientes casos:

  • Es útil cuando necesitas balancear la carga del tráfico en varias VM que funcionan como dispositivos de traducción de direcciones de red (NAT) virtuales.

  • Cuando necesitas un balanceador de cargas para que funcione como el siguiente salto de una ruta predeterminada. Cuando las instancias de máquinas virtuales (VM) en tu red de nube privada virtual (VPC) envían tráfico a Internet, se enruta el tráfico a través de dispositivos virtuales de puerta de enlace de carga balanceada.

  • Es útil cuando necesitas enviar tráfico a través de varios balanceadores de cargas en dos o más direcciones con el mismo conjunto de VM de varios NIC que los backends. A fin de hacerlo, debes crear un balanceador de cargas y usarlo como el siguiente salto para una ruta estática personalizada en cada red de VPC. Cada balanceador de cargas TCP/UDP interno opera dentro de una sola red de VPC; distribuye el tráfico a las interfaces de red de las VM de backend en esa red.

Balanceo de cargas a varios NIC (haz clic para agrandar)
Balanceo de cargas a varios NIC (haz clic para agrandar)

En el diagrama anterior, un grupo de instancias de VM funciona como backend para dos balanceadores de cargas diferentes. Este caso práctico se llama balanceadores de cargas TCP/UDP internos como siguientes saltos con backends comunes porque se balancean las cargas de varios NIC (nic0 y nic1, en este caso) en las VM de backend. Esta implementación está permitida porque el balanceo de cargas de TCP/UDP interno admite el balanceo de cargas a cualquier interfaz en instancias de VM de backend (no solo a la interfaz principal nic0).

Por el contrario, dos conjuntos de instancias de VM pueden funcionar como backends para dos balanceadores de cargas diferentes. Puedes usar dos conjuntos de backends cuando tienes diferentes perfiles de tráfico para el tráfico entrante y saliente. Este caso práctico se llama balanceadores de cargas TCP/UDP internos como siguientes saltos con diferentes backends porque solo se balancean las cargas de las interfaces principales (nic0) en las VM de backend. Se muestra esta configuración en el siguiente diagrama:

Balanceo de cargas a un solo NIC (haz clic para agrandar)
Balanceo de cargas a un solo NIC (haz clic para agrandar)

Puedes crear una ruta estática personalizada para traspasar el tráfico de TCP y UDP a un balanceador de cargas TCP/UDP interno en el que dicho balanceador de cargas sea el siguiente salto de la ruta estática. La ruta puede ser la ruta predeterminada (0.0.0.0/0), un prefijo CIDR externo (enrutable públicamente) o un prefijo CIDR interno, si el prefijo no entra en conflicto con una ruta de subred. Por ejemplo, puedes reemplazar la ruta predeterminada (0.0.0.0/0) por una ruta que dirige el tráfico a las VM de backend de terceros para el procesamiento de paquetes.

Para usar la ruta estática personalizada, las instancias de VM en cada red de VPC deben estar en la misma región que el balanceador de cargas asociado.

Si un Cloud Router está en la misma región que un balanceador de cargas, puedes anunciar esta ruta a otras redes conectadas mediante los anuncios de ruta personalizados de Cloud Router. Para obtener más información, consulta la página sobre el balanceo de cargas TCP/UDP interno y redes conectadas.

Para obtener más información, consulte:

Beneficios de usar el balanceador de cargas TCP/UDP interno como siguiente salto

Cuando el balanceador de cargas es un siguiente salto para una ruta estática, no debes configurar explícitamente a tus clientes a fin de enviar tráfico al balanceador de cargas o a cada VM de backend. Puedes integrar tus VM de backend con el modo bump-in-the-wire.

El uso de un balanceador de cargas TCP/UDP interno como siguiente salto de una ruta estática proporciona los mismos beneficios que el balanceo de cargas TCP/UDP interno. La verificación de estado del balanceador de cargas garantiza que las conexiones nuevas se enruten a las VM de backend en buen estado. Si usas un grupo de instancias administrado como backend, puedes configurar el ajuste de escala automático para aumentar o reducir el conjunto de VM según la demanda del servicio.

Especificaciones

Las siguientes son especificaciones para usar balanceadores de cargas TCP/UDP internos como siguientes saltos.

Afinidad de sesión de IP de cliente

La afinidad de sesión de IP de cliente es una opción de afinidad de sesión disponible. Es una afinidad de dos tuplas que usa la dirección IP de origen y destino como entradas para una función hash.

Cuando se usa un balanceador de cargas TCP/UDP interno, la dirección IP de destino es la dirección IP de la regla de reenvío del balanceador de cargas. La afinidad de sesión de IP de cliente en este contexto significa que las conexiones de un cliente con una dirección IP de origen constante se entregan a la misma VM de backend si está en buen estado.

En cambio, cuando se usa un balanceador de cargas TCP/UDP interno como siguiente salto para una ruta estática, la dirección IP de destino varía porque las VM de backend del balanceador de cargas procesan paquetes y los enrutan a diferentes destinos. El uso de la afinidad de sesión de IP de cliente en este contexto no hace que la misma VM de backend procese los paquetes, incluso si el cliente tiene una dirección IP de origen constante.

Rango de destino

El destino de una ruta estática personalizada no puede ser igual o más específico que una ruta de subred. Ten en cuenta que más específico significa que la máscara de subred es más larga. Esta regla se aplica a todas las rutas estáticas personalizadas, incluso cuando el siguiente salto es un balanceador de cargas TCP/UDP interno. Por ejemplo, supongamos que tu ruta de subred es 10.140.0.0/20. El destino de una ruta estática personalizada no puede ser el mismo (10.140.0.0/20) y no puede ser más específico, como en 10.140.0.0/22.

La misma red de VPC y región

Las rutas estáticas personalizadas que usan balanceadores de cargas TCP/UDP internos como siguientes saltos se limitan a lo siguiente:

  • Una red de VPC individual. El balanceador de cargas y la ruta estática personalizada deben estar en la misma red de VPC.

  • Una región individual o todas las regiones. A menos que configures el acceso global, la ruta estática personalizada solo estará disponible para recursos en la misma región que el balanceador de cargas. Se aplica esta restricción regional aunque la ruta en sí misma sea parte de la tabla de enrutamiento para toda la red de VPC. Si habilitas el acceso global, la ruta estática personalizada estará disponible para los recursos de cualquier región.

Orden de las operaciones

Debes crear un balanceador de cargas TCP/UDP interno para poder crear una ruta estática personalizada que la use como siguiente salto. El balanceador de cargas debe existir antes de que puedas crear la ruta. Si intentas crear una ruta que haga referencia a un balanceador de cargas inexistente, Google Cloud mostrará un error.

Especifica un siguiente salto de balanceador de cargas TCP/UDP interno mediante el nombre de la regla de reenvío y la región del balanceador de cargas, no mediante la dirección IP interna asociada con la regla de reenvío.

Después de crear una ruta con un siguiente salto que haga referencia a un balanceador de cargas TCP/UDP interno, no puedes borrar el balanceador de cargas, a menos que borres la ruta primero. Específicamente, no puedes borrar una regla de reenvío interna hasta que ninguna ruta estática personalizada use esa regla de reenvío como siguiente salto.

Requisitos de backend

  • Debes configurar todas las VM de backend del balanceador de cargas de TCP/UDP interno a fin de permitir el reenvío de IP (--can-ip-forward = True). Si deseas obtener más información, consulta el artículo sobre consideraciones para el enrutamiento basado en instancias o en el balanceador de cargas.

  • No se puede usar un balanceador de cargas TCP/UDP interno con backends que sean nodos de Google Kubernetes Engine (GKE) como siguiente salto para una ruta estática personalizada. El software en los nodos solo puede enrutar el tráfico a los pods si el destino coincide con una dirección IP administrada por el clúster, no con un destino arbitrario.

Procesamiento de TCP, UDP y otro tráfico de protocolo

Cuando se implementa un balanceador de cargas TCP/UDP interno como siguiente salto, Google Cloud reenvía todo el tráfico de TCP y UDP a todos los puertos a las VM de backend, independientemente de lo siguiente:

  • El protocolo y la configuración de puertos de la regla de reenvío
  • La configuración del protocolo del servicio de backend

El balanceador de cargas procesa solo el tráfico de TCP y UDP, y omite el resto del tráfico, como ICMP. La siguiente ruta más específica de tu red de VPC controla el tráfico que no usa el protocolo TCP o UDP. Las rutas para el tráfico no TCP y no UDP tienen las siguientes características:

  • No tienen un balanceador de cargas TCP/UDP interno como el siguiente salto.
  • Se eligen de acuerdo con el orden de enrutamiento.

Por ejemplo, supongamos que tienes las siguientes rutas en tu red de VPC:

  • Destino: 1.1.1.1/32, siguiente salto: balanceador de cargas TCP/UDP interno
  • Destino: 1.0.0.0/8, siguiente salto: puerta de enlace de Internet predeterminada

Para los clientes que se encuentran en la misma región que el balanceador de cargas (o en cualquier región cuando el acceso global está habilitado), el tráfico de TCP y UDP que se destina a 1.1.1.1/32 usa la ruta con el siguiente salto del balanceador de cargas TCP/UDP.

Para el tráfico que no TCP y no UDP (como los pings ICMP), se usa la ruta 1.0.0.0/8.

Especificaciones adicionales

  • Una ruta estática personalizada no puede usar etiquetas de red si la ruta tiene un balanceador de cargas TCP/UDP interno como el siguiente salto de la ruta.

  • No puedes crear varias rutas estáticas personalizadas con la misma prioridad, el mismo destino y el mismo balanceador de cargas TCP/UDP interno en el siguiente salto. En consecuencia, cada ruta estática personalizada con el mismo balanceador de cargas como siguiente salto debe tener al menos un destino único o una prioridad única.

  • Si tienes diferentes balanceadores de cargas TCP/UDP internos como siguientes saltos para varias rutas que tienen el mismo destino y prioridad, Google Cloud no distribuye el tráfico entre los balanceadores de cargas. En cambio, Google Cloud elige solo uno de los balanceadores de cargas como el siguiente salto para todo el tráfico que coincide con el destino e ignora el resto.

  • Cuando usas un balanceador de cargas TCP/UDP interno como el siguiente salto para una ruta estática personalizada, no puedes usar la marca --purpose=SHARED_LOADBALANCER_VIP con la dirección IP de la regla de reenvío interna. Esto se debe a que la dirección IP interna compartida puede hacer referencia indirectamente a más de un servicio de backend.

Para obtener más información, consulta Descripción general de las rutas.

Casos de uso

Puedes usar un balanceador de cargas TCP/UDP interno como siguiente salto en varias implementaciones y topologías.

Para cada ejemplo, ten en cuenta los siguientes lineamientos:

  • Cada interfaz de VM debe estar en una red de VPC independiente.

  • No puedes usar VM de backend o balanceadores de cargas para enrutar tráfico entre subredes en la misma red de VPC porque las rutas de subred no se pueden anular.

  • El balanceador de cargas TCP/UDP interno es un balanceador de cargas de paso directo definido por software. Únicamente las VM de backend realizan las operaciones de NAT y proxies: los dispositivos virtuales de firewall.

Usa un balanceador de cargas TCP/UDP interno como siguiente salto a una puerta de enlace NAT

En este caso práctico, se balancea la carga del tráfico de las VM internas a varias instancias de puerta de enlace NAT que enrutan el tráfico a Internet.

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

Concentrador y radio: intercambio de rutas de siguiente salto mediante el intercambio de tráfico entre redes de VPC

Además de intercambiar rutas de subred, puedes configurar el intercambio de tráfico entre redes de VPC para exportar y también importar rutas estáticas y dinámicas personalizadas. Se excluyen las rutas estáticas personalizadas que usen etiquetas de red o que tengan un siguiente salto de la puerta de enlace de Internet predeterminada.

Para configurar una topología de concentrador y radio con tus dispositivos virtuales de firewall de siguiente salto ubicados en la red de VPC hub, sigue estos pasos:

  • En la red de VPC hub, crea un balanceador de cargas TCP/UDP interno con dispositivos virtuales de firewall como backends.
  • En la red de VPC hub, crea una ruta estática personalizada y establece que el siguiente salto sea el balanceador de cargas TCP/UDP interno.
  • Conecta la red de VPC hub a cada una de las redes de VPC spoke mediante el intercambio de tráfico entre redes de VPC.
  • Por cada intercambio de tráfico, configura la red hub para que exporte sus rutas personalizadas y configura la red spoke correspondiente a fin de que importe las rutas personalizadas. La ruta con el siguiente salto del balanceador de cargas es una de las rutas que exporta la red hub.

El balanceador de cargas del dispositivo de firewall de siguiente salto en la red de VPC hub se puede usar en cada red spoke, según el orden de enrutamiento.

Concentrador y radio (haz clic para ampliar)
Concentrador y radio (haz clic para ampliar)

Balanceo de cargas a varios NIC

En el siguiente caso práctico, las VM de backend son instancias de dispositivos virtuales (por ejemplo, instancias de firewall o puertas de enlace NAT) con NIC en varias redes de VPC. Un tercero puede proporcionar las instancias de firewall y las puertas de enlace NAT como dispositivos virtuales. Los dispositivos virtuales son VM de Compute Engine con varios NIC.

En este ejemplo, se muestra un conjunto único de dispositivos virtuales de backend en un grupo de instancias de VM administrado.

En la red de VPC llamada testing, el balanceador de cargas TCP/UDP interno tiene una regla de reenvío llamada fr-ilb1. En el ejemplo, este balanceador de cargas distribuye el tráfico a la interfaz nic0 en cada dispositivo virtual, pero podría ser cualquier NIC.

En la red de VPC llamada production, un balanceador de cargas TCP/UDP interno diferente tiene una regla de reenvío llamada fr-ilb2. Este balanceador de cargas distribuye el tráfico a una interfaz diferente, nic1 en este ejemplo.

Tráfico con balanceo de cargas de varios NIC (haz clic para agrandar)
Tráfico con balanceo de cargas de varios NIC (haz clic para ampliar)

Para ver una configuración detallada, consulta el artículo sobre el balanceo de cargas a varios NIC de backend.

Usa un balanceador de cargas TCP/UDP interno como siguiente salto con un solo NIC

En el caso práctico anterior, las VM de backend son instancias de dispositivos virtuales (por ejemplo, instancias de firewall o puertas de enlace NAT) con NIC en varias redes de VPC.

En los siguientes ejemplos, se muestran dos conjuntos de dispositivos virtuales de backend en dos grupos de instancias de VM administrados.

Los backends se resumen de esta manera:

Instancias de balanceo de cargas para tráfico de testing a production Instancias de balanceo de cargas para tráfico de production a testing
fw-instance-a
fw-instance-b
fw-instance-c
fw-instance-d
fw-instance-e
fw-instance-f

En la dirección de testing a production, el tráfico se origina en la red de VPC llamada testing. En la red testing, el balanceador de cargas TCP/UDP interno tiene una regla de reenvío llamada fr-ilb1. En este ejemplo, se usan balanceadores de cargas TCP/UDP internos con servicios de backend que no tienen un parámetro network especificado. Esto significa que cada balanceador de cargas solo distribuye el tráfico a la interfaz de red principal de cada VM de backend.

Tráfico con balanceo de cargas de NIC individual (<code>prueba</code> a <code>producción</code>) (haz clic para agrandar)
Tráfico con balanceo de cargas de NIC individual (testing a production) (haz clic para agrandar)

En la dirección de production a testing, el tráfico se origina en la red de VPC llamada production. En la red production, un balanceador de cargas TCP/UDP interno diferente tiene una regla de reenvío llamada fr-ilb2. Otra vez, en este ejemplo, se usan balanceadores de cargas TCP/UDP internos con servicios de backend que no tienen un parámetro network especificado. Esto significa que cada balanceador de cargas solo distribuye el tráfico a la interfaz de red principal de cada VM de backend. Debido a que cada dispositivo virtual puede tener solo un nic0, esta implementación requiere un segundo conjunto de dispositivos virtuales, el primero corresponde al balanceo de cargas de testing a production y el segundo corresponde al balanceo de cargas de production a testing.

Tráfico con balanceo de cargas de NIC individual (<code> producción</code> a <code>prueba</code>) (haz clic para agrandar)
Tráfico con balanceo de cargas de NIC individual (production a testing) (haz clic para agrandar)

Qué sigue