Balanceadores de cargas de red de transferencia internos como próximos saltos

El balanceador de cargas de red de transferencia interno es un balanceador de cargas regional que te permite ejecutar y escalar tus servicios detrás de una dirección IP interna. Puedes usar un balanceador de cargas de red de transferencia interno como próximo salto al que se reenvían los paquetes en la ruta a su destino final. Para ello, configura el balanceador de cargas como el próximo salto en una ruta estática.

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

Un próximo salto del balanceador de cargas de red de transferencia 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.

  • Para 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 en cada red de VPC. Cada balanceador de cargas de red de transferencia interno opera dentro de una sola red de VPC y distribuye el tráfico a las interfaces de red de las VMs 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 balanceador de cargas de red de transferencia interno envía paquetes a nic0 de las VMs de backend, y el segundo balanceador de cargas de red de transferencia interna envía paquetes a nic1 en los mismos backends.

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

Beneficios de usar su balanceador de cargas de red de transferencia interno como próximo 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 VMs de cliente envían paquetes a los backends del balanceador de cargas a través del enrutamiento de red de VPC, en forma de bump-in-the-wire.

El uso de un balanceador de cargas de red de transferencia interno como próximo salto de una ruta estática proporciona los mismos beneficios que un balanceador de cargas de red de transferencia interna independiente. 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 de red de transferencia internos como próximos saltos.

Rutas

Puedes crear una ruta estática para traspasar el tráfico de TCP, UDP y otro tráfico de protocolo a un balanceador de cargas de red de transferencia interno en el que dicho balanceador de cargas sea el próximo 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

Puedes especificar un siguiente salto de balanceador de cargas de red interno de dos maneras:

  • Usa el nombre y la región de la regla de reenvío
  • Usa la dirección IP de la regla de reenvío

Para obtener detalles sobre el proyecto y la red de VPC en la que puede residir un siguiente salto de balanceador de cargas de red de transferencia interno, consulta Siguientes saltos y características.

Puedes intercambiar rutas estáticas con los siguientes saltos del balanceador de cargas de red interno de transferencia mediante el intercambio de tráfico entre redes de VPC. Para obtener más información, consulta Opciones para intercambiar rutas estáticas.

Afinidad de sesión de IP de cliente

Los balanceadores de cargas de red de transferencia internos ofrecen 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 red de transferencia interno no es el próximo 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 red de transferencia interno como un próximo 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 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, incluso cuando el próximo salto es un balanceador de cargas de transferencia interno. Por ejemplo, supongamos que tu ruta de subred es 10.140.0.0/20. El destino de una ruta estática 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 que usan balanceadores de cargas de red de transferencia internos como próximo salto se limitan a lo siguiente:

  • Una red de VPC individual. El balanceador de cargas y la ruta estática 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 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 estará disponible para los recursos de cualquier región.

Anuncia la ruta estática

Para anunciar el prefijo (destino) de la ruta estática, puedes usar el modo de anuncio 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 de red de transferencia interno solo está disponible para las VMs, 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 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 de red de transferencia interno está disponible para las VMs, 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 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 Regional Accesible por routers en la misma región
Inhabilitado Global Accesible por routers en la misma región
Habilitado Regional 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 Balanceadores de cargas de red de transferencia internos y redes conectadas.

Orden de las operaciones

Debes crear un balanceador de cargas de red de transferencia interno para poder crear una ruta estática que la use como próximo 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 próximo salto de balanceador de cargas de red de transferencia 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 próximo salto que haga referencia a un balanceador de cargas de red de transferencia 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 use ese balanceador de cargas como siguiente salto.

Requisitos de backend

  • Debes configurar todas las VMs de backend del balanceador de cargas de red de transferencia interno para permitir el reenvío de IP (--can-ip-forward = True). Si deseas obtener más información, consulta Consideraciones comunes de próximos saltos de balanceadores de cargas de red de transferencia internos y de instancias.

  • No se puede usar un balanceador de cargas de red de transferencia interno con backends que sean nodos de Google Kubernetes Engine (GKE) como próximo salto para una ruta estática. 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 red de transferencia interno como próximo salto, Google Cloud reenvía todo el tráfico de todos los puertos a las VMs 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 próximo 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

  • Reglas de reenvío compatibles. Google Cloud solo admite reglas de reenvío del balanceador de cargas de red de traspaso interno del próximo salto. Google Cloud no admite reglas de reenvío de próximo salto que usan otros balanceadores de cargas, reenvío de protocolos o extremos de Private Service Connect.

  • Métodos de especificación y red y proyecto de la regla de reenvío. Puedes especificar una regla de reenvío de próximo salto mediante uno de los siguientes tres métodos. El método de especificación que uses determina si la red de la regla de reenvío debe coincidir con la red de la ruta y en qué proyecto se puede ubicar la regla de reenvío:

    • Por nombre (--next-hop-ilb) y región (--next-hop-ilb-region) de la regla de reenvío: Cuando especificas una regla de reenvío de próximo salto por nombre y región, la red de la regla de reenvío debe coincidir con la red de VPC de la ruta. La regla de reenvío debe estar ubicada en el mismo proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto host de VPC compartida).

    • Por vínculo de recurso de la regla de reenvío: El vínculo del recurso de una regla de reenvío usa el siguiente formato /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, donde PROJECT_ID es el ID del proyecto que contiene la regla de reenvío, REGION es la región de la regla de reenvío y FORWARDING_RULE_NAME es el nombre de la regla de reenvío. Cuando especificas una regla de reenvío de próximo salto por su vínculo de recurso, la red de la regla de reenvío debe coincidir con la red de VPC de la ruta. La regla de reenvío se puede ubicar en ya sea en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto host de VPC compartida) o en un proyecto de servicio de VPC compartida.

    • Por una dirección IPv4 de la regla de reenvío: cuando especificas una regla de reenvío de próximo salto por su dirección IPv4, la red de la regla de reenvío puede ser tanto la red de VPC de la ruta como una red de VPC con intercambio de tráfico. La regla de reenvío se puede ubicar ya sea en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto host de VPC compartida) o en un proyecto de servicio de VPC compartida.

  • Efecto del acceso global. Las rutas estáticas personalizadas que usan los próximos saltos del balanceador de cargas de red de transferencia 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 próximo salto de balanceador de cargas de red de transferencia interno se descartan.

  • Cuando todos los backends están en mal estado. Cuando todos los backends de un balanceador de cargas de red de transferencia interno no aprueban las verificaciones de estado, las rutas que usan ese próximo 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). Los balanceadores de cargas de red de transferencia internos de próximo salto y las reglas de reenvío del balanceador de cargas de red de transferencia interno con una dirección IP común son funciones excluyentes entre sí. Un balanceador de cargas de red de transferencia interno de próximo salto debe usar una dirección IP que sea única para la regla de reenvío del balanceador de cargas para 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 red de transferencia internos).

  • Varias rutas con los mismos destinos y prioridades, pero diferentes balanceadores de cargas de red de transferencia internos de próximo salto. Google Cloud nunca distribuye el tráfico entre dos o más balanceadores de cargas de red de transferencia internos de próximo salto mediante ECMP. En cambio, Google Cloud selecciona solo un balanceador de cargas de red de transferencia interno de próximo salto mediante un algoritmo interno y determinista. Para evitar esta ambigüedad, puedes usar etiquetas de red únicas para cada ruta.

    Google Cloud selecciona un solo próximo salto cuando las rutas estáticas con diferentes próximos saltos de balanceador de cargas de red de transferencia interno tienen la misma prioridad y el mismo destino.

  • Varias rutas con los mismos destinos, prioridades y balanceadores de cargas de red de transferencia internos de próximo salto. Sin una etiqueta de red, Google Cloud no te permite crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y próximo salto de balanceador de cargas de red de transferencia interno. Con las etiquetas de red, puedes crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y próximo salto de balanceador de cargas de red de transferencia interno.

Casos de uso

Puedes usar un balanceador de cargas de red de transferencia interno como próximo 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 de red de transferencia interno es un balanceador de cargas de transferencia 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 VMs del dispositivo virtual que funcionan como backends para el balanceador de cargas de red de transferencia interno.

Usa un balanceador de cargas de red de transferencia interno como el próximo 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 de uso de NAT.
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 que tienen un próximo salto de la puerta de enlace a Internet predeterminada. Se incluyen las rutas estáticas personalizadas que usan balanceadores de cargas de red de transferencia internos de próximo 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 de red de transferencia interno con dispositivos virtuales de firewall como backends.
  • En la red de VPC hub, crea una ruta estática y establece que el próximo salto sea el balanceador de cargas de red de transferencia 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
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 de red de transferencia 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 de red de transferencia 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.
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 red de transferencia interno a partir del 22 de junio de 2021.

  • Para habilitar el hash simétrico en balanceadores de cargas de red de transferencia internos existentes, debes volver a crear la regla de reenvío y la ruta del próximo salto, como se describe en Habilita el hash simétrico.

  • El hash simétrico solo es compatible con los balanceadores de cargas de red de transferencia internos.

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

    • IP de cliente (CLIENT_IP)
    • IP de cliente y protocolo (CLIENT_IP_PROTO)
    • IP de cliente, protocolo y puerto (CLIENT_IP_PORT_PROTO)

    Para obtener más información sobre estos parámetros de configuración, consulta Opciones de afinidad de sesión.

  • De forma opcional, puedes usar SNAT si tu caso de uso lo requiere por algún motivo.

¿Qué sigue?