Balanceadores de cargas TCP/UDP internos como siguientes saltos

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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 interno. Puedes usar un balanceador de cargas de TCP/UDP interno como siguiente salto al que 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.

Antes de revisar la información de esta página, ya deberías estar familiarizado con los siguientes conceptos:

Un siguiente salto del balanceador de cargas de TCP/UDP interno es útil en los siguientes casos:

  • Balanceo de cargas de tráfico en varias VM que funcionan como VM de puerta de enlace o de router.

  • A fin de usar los dispositivos virtuales de puerta de enlace como el salto siguiente para una ruta predeterminada, Con esta configuración, las instancias de máquinas virtuales (VM) en tu red de nube privada virtual (VPC) envían tráfico a Internet a través de un conjunto de VM de puerta de enlace virtual con balanceo de cargas.

  • Para enviar tráfico a través de varios balanceadores de cargas en dos o más direcciones con el mismo conjunto de puertas de enlace de NIC múltiples o VM de router que son 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.

Arquitectura

En el siguiente diagrama, un grupo de instancias de VM de VM del router funciona como backend para dos balanceadores de cargas diferentes. El primer balanceo de cargas de TCP/UDP interno envía paquetes a nic0 de las VM de backend, y el segundo balanceo de cargas de TCP/UDP interno envía paquetes a nic1 en los mismos backends.

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

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 se necesita una configuración especial dentro de los sistemas operativos invitados de las VM cliente en la red de VPC en la que se define la ruta. Las VM de cliente envían paquetes a los backends del balanceador de cargas a través del enrutamiento de red de VPC, en forma de conexión por cable.

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.

Rutas

Puedes crear una ruta estática personalizada para traspasar el tráfico de TCP, UDP y otro tráfico de protocolo 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 un prefijo de CIDR externo (enrutable públicamente) o un prefijo de 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.

Opciones para especificar el siguiente salto

Tienes dos opciones sobre cómo especificar el balanceador de cargas como el siguiente salto.

Opción de especificación Red de siguiente salto Se puede exportar a redes con intercambio de tráfico
El nombre de la regla de reenvío y la región del balanceador de cargas La ruta y el balanceador de cargas del siguiente salto deben estar en la misma red de VPC Sí, mediante la exportación de rutas personalizadas (aplicables a las rutas sin etiquetas de instancia)
Dirección IP interna de la regla de reenvío El balanceador de cargas del siguiente salto puede estar en la misma red de VPC que la ruta o en una red de VPC con intercambio de tráfico Sí, siempre se exporta (excepto las rutas con etiquetas de instancia)

Afinidad de sesión de IP de cliente

El balanceo de cargas TCP/UDP interno ofrece dos opciones de afinidad de sesión de “dirección IP de cliente” similares:

  • IP de cliente (CLIENT_IP): un hash de dos tuplas de la dirección IP de origen y la dirección IP de destino de un paquete. Cuando un balanceador de cargas de TCP/UDP interno no es el siguiente salto de una ruta, los paquetes enviados a la dirección IP de la regla de reenvío del balanceador de cargas comparten una dirección IP de destino común: la dirección IP de la regla de reenvío. En este caso, una de las direcciones que usa el hash de dos tuplas permanece constante. Por lo tanto, si la cantidad de backends configurados y en buen estado no cambia y los paquetes tienen direcciones IP de origen idénticas, esta opción de afinidad de sesión de dos tuplas selecciona el mismo backend.
  • IP de cliente, sin destino (CLIENT_IP_NO_DESTINATION): Es un hash de una tupla de la dirección IP de origen de un paquete. Cuando usas un balanceador de cargas de TCP/UDP interno como un siguiente salto, la dirección IP de destino a menudo varía, ya que las direcciones IP de destino son las que especifica el atributo de destino de la ruta. En esta situación, la afinidad de sesión de la IP de cliente (CLIENT_IP) del hash de dos tuplas no puede seleccionar el mismo backend incluso cuando la cantidad de backends configurados y en buen estado no cambia y los paquetes tienen direcciones IP de origen idénticas. (Una excepción a esta regla es cuando solo se configura un backend). Si necesitas que los paquetes con direcciones IP de origen idénticas se enruten al mismo backend, debes usar la opción de afinidad de sesión de IP de cliente, sin destino (CLIENT_IP_NO_DESTINATION).

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

Anuncia la ruta estática personalizada

Para anunciar el prefijo (destino) de la ruta estática personalizada, puedes usar un anuncio de ruta personalizado de Cloud Router. El permiso del anuncio de ruta depende del parámetro de configuración de acceso global del balanceador de cargas, de la siguiente manera:

  • Cuando el acceso global está inhabilitado, el balanceador de cargas TCP/UDP interno solo está disponible para las VM, los túneles de Cloud VPN y los adjuntos de Cloud Interconnect (VLAN) que se encuentren en la misma región que el balanceador de cargas. En consecuencia, un anuncio de ruta personalizado para el prefijo de una ruta estática personalizada solo tiene sentido si el Cloud Router y el balanceador de cargas están en la misma región.

  • Cuando el acceso global está habilitado, el balanceador de cargas TCP/UDP interno está disponible para las VM, los túneles de Cloud VPN y los adjuntos de Cloud Interconnect (VLAN) que se encuentren en cualquier región. Con el enrutamiento dinámico global, los sistemas locales pueden usar la ruta estática personalizada desde cualquier región conectada.

En la siguiente tabla, se resume la accesibilidad del balanceador de cargas.

Acceso global Modo de enrutamiento dinámico de la red de VPC Acceso al balanceador de cargas
inhabilitado Discos Accesible por routers en la misma región
inhabilitado Global Accesible por routers en la misma región
Habilitado Discos Accesible por todos los routers de cualquier región
Habilitado Global Accesible por todos los routers de cualquier región

Para obtener más información, consulta Balanceo de cargas de TCP/UDP interno y redes conectadas.

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, o 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 ese balanceador de cargas 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 de TCP/UDP interno como siguiente salto, Google Cloud reenvía todo el tráfico de 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 de TCP/UDP interno, que es el siguiente salto de la ruta, admite sin problemas el reenvío de todo el tráfico para los protocolos que admiten las redes de VPC de Google Cloud (como TCP, ICMP y UDP).

Consideraciones adicionales

  • Efecto del acceso global. Las rutas estáticas personalizadas que usan los siguientes saltos del balanceador de cargas de TCP/UDP interno se programan en todas las regiones. La posibilidad de que el siguiente salto se pueda usar depende del parámetro de configuración de acceso global del balanceador de cargas. Con el acceso global habilitado, se puede acceder al siguiente salto del balanceador de cargas en todas las regiones de la red de VPC. Con el acceso global inhabilitado, solo se puede acceder al siguiente salto del balanceador de cargas en la misma región del balanceador de cargas. Con el acceso global inhabilitado, los paquetes enviados desde otra región a una ruta mediante un siguiente salto de balanceador de cargas TCP/UDP interno se descartan.
  • Cuando todos los backends están en mal estado. Cuando todos los backends de un balanceador de cargas de TCP/UDP interno fallan las verificaciones de estado, las rutas que usan ese siguiente salto de balanceador de cargas aún están activas. Los paquetes que procesa la ruta se envían a uno de los backends del balanceador de cargas del siguiente salto según la distribución de tráfico.

  • No se admiten las reglas de reenvío que usen una dirección IP interna común (--purpose=SHARED_LOADBALANCER_VIP). El balanceador de cargas de TCP/UDP interno de siguiente salto y las reglas de reenvío del balanceador de cargas de TCP/UDP interno con una dirección IP común son funciones excluyentes entre sí. Un balanceador de cargas de TCP/UDP interno de siguiente salto debe usar una dirección IP que sea única para la regla de reenvío del balanceador de cargas a fin de que solo se haga referencia a un servicio de backend (un balanceador de cargas) sin ninguna ambigüedad. Es posible que las reglas de reenvío que usan una dirección IP interna común hagan referencia a diferentes servicios de backend (diferentes balanceadores de cargas de TCP/UDP internos).

  • El mismo destino y varios balanceadores de cargas de TCP/UDP internos de siguiente salto. Si creas dos o más rutas estáticas personalizadas con el mismo destino mediante diferentes siguientes saltos del balanceador de cargas de TCP/UDP interno, Google Cloud nunca distribuye el tráfico entre los siguientes saltos del balanceador de cargas mediante ECMP. Si las rutas tienen prioridades únicas, Google Cloud usa el balanceador de cargas de TCP/UDP interno de siguiente salto de la ruta con la prioridad más alta. Si las rutas tienen las mismas prioridades, Google Cloud selecciona solo un balanceador de cargas de TCP/UDP interno de siguiente salto. En esta última situación, como se ilustra en el siguiente diagrama, Google Cloud usa un algoritmo determinista interno para seleccionar una sola regla de reenvío de siguiente salto (forwarding-rule-a), sin importar otras rutas con la misma prioridad.

    Google Cloud selecciona un solo salto siguiente cuando las rutas estáticas con diferentes saltos de balanceador de cargas TCP/UDP interno tienen la misma prioridad y el mismo destino.
  • Varios destinos y el mismo balanceador de cargas de TCP/UDP interno de siguiente salto.

    Con etiquetas de instancia:

    Si usas etiquetas de instancia (también llamadas etiquetas de red), puedes usar el mismo balanceador de cargas TCP/UDP interno de siguiente salto para varias rutas estáticas personalizadas con el mismo destino y la misma prioridad.

    Sin etiquetas de instancia: Si no usas etiquetas de instancia, no puedes crear múltiples rutas estáticas personalizadas que tengan la misma combinación de destino, prioridad y balanceador de cargas de TCP/UDP interno de siguiente salto. Por ejemplo, se pueden crear route-x, route-y y route-z, pero no se puede crear route-x-copy.

    Las rutas estáticas que no tienen etiquetas de instancias no se pueden crear con el mismo destino, la misma prioridad y el mismo salto de balanceador de cargas TCP/UDP interno.
  • Etiquetas de instancia.

    Puedes especificar etiquetas de instancia (también llamadas etiquetas de red) para que la ruta del siguiente salto solo se aplique a las instancias de cliente que se configuraron con la etiqueta. Esto te permite seleccionar qué instancias de cliente se propagan con qué ruta etiquetada de siguiente salto y a qué conjunto de dispositivos enrutar el tráfico.

    No es necesario segregar las diferentes instancias de cliente a redes de VPC independientes, ya que cada una apunta a su balanceador de cargas de TCP/UDP interno preferido, que realiza un frontend de un conjunto de dispositivos.

  • Varias rutas al mismo prefijo de destino. Con las etiquetas de instancia, puedes especificar varias rutas al mismo destino con diferentes balanceadores de cargas internos como siguientes saltos. Puedes usar diferentes etiquetas de instancia o prioridades diferentes para estas mismas rutas de destino.

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. Los paquetes se entregan a las VM de backend sin alterar la información de origen o destino (direcciones, o direcciones y puertos).

    El enrutamiento, el filtrado de paquetes, el proxy y la traducción de direcciones son responsabilidad de las VM del dispositivo virtual que funcionan como backends para el balanceador de cargas TCP/UDP interno.

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 tengan un siguiente salto de la puerta de enlace de Internet predeterminada. Se incluyen las rutas estáticas personalizadas que usan balanceadores de cargas TCP/UDP internos de siguiente salto.

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.

Sujeto al orden de enrutamiento, el balanceador de cargas del dispositivo de firewall de siguiente salto en la red de VPC hub está disponible en las siguientes redes de radio:

  • a clientes en la misma región que el balanceador de cargas, si el acceso global está inhabilitado
  • a los clientes en todas las regiones, si el acceso global está habilitado, 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 de uso, las VM de backend son instancias de dispositivos virtuales (por ejemplo, inspección de paquetes, enrutamiento o VM de puerta de enlace) con NIC en varias redes de VPC. Estas instancias de dispositivos virtuales pueden ser soluciones comerciales de terceros o soluciones que compilas tú mismo. 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 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.

Hash simétrico

En el ejemplo anterior, no se usa la traducción de direcciones de red de origen (SNAT). No se requiere SNAT porque Google Cloud usa el hash simétrico. Esto significa que cuando los paquetes pertenecen al mismo flujo, Google Cloud calcula el mismo hash. En otras palabras, el hash no cambia cuando la dirección IP:puerto se intercambia con la dirección IP:puerto de destino.

Notas:

  • El hash simétrico se habilita de forma automática cuando creas la regla de reenvío del balanceador de cargas de TCP/UDP interno a partir del 22 de junio de 2021.

  • Para habilitar el hash simétrico en balanceadores de cargas de TCP/UDP internos existentes, debes volver a crear la regla de reenvío y la ruta del siguiente salto, como se describe en Habilita el hash simétrico.

  • El hash simétrico solo es compatible con el balanceo de cargas TCP/UDP interno.

  • El hash simétrico es compatible con los siguientes tipos de afinidad de sesión para los protocolos TCP y UDP:

    • IP de cliente (2 tuplas)
    • IP y protocolo de cliente (3 tuplas)
    • IP de cliente, protocolo y puerto (5 tuplas)
  • De forma opcional, puedes usar SNAT si tu caso de uso lo requiere por algún motivo.

¿Qué sigue?