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

• Descripción general de las rutas
• Descripción general del balanceador de cargas de red de transferencia interna

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.

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

Nota: Esta función no admite direcciones IPv6.

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

Precaución: Cuando envíes tráfico a los servicios y las APIs de Google, no enrutes el tráfico a través de una VM de próximo salto ni un balanceador de cargas de red de transferencia interno de próximo salto. En su lugar, enruta dicho tráfico a través de una puerta de enlace de Internet predeterminada de siguiente salto. Esto incluye el tráfico a los servicios y las API de Google que se envían a través del Acceso privado a Google.

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.

Nota: Un balanceador de cargas cuya regla de reenvío usa el protocolo L3_DEFAULT no puede ser el próximo salto para una ruta estática. Si se crea esta ruta estática, el tráfico se descarta de manera silenciosa.

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 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 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 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 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 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 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 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 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 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 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 personalizada 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 personalizada 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 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 de red de transferencia interno con backends que sean nodos de Google Kubernetes Engine (GKE) como próximo 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

Importante: La información de esta sección solo se aplica a las rutas personalizadas creadas antes del 15 de mayo de 2021.

Si se creó un balanceador de cargas de red de transferencia interno como ruta de próximos saltos antes del 15 de mayo de 2021, el balanceador de cargas reenvía solo el tráfico de TCP y UDP en todos los puertos a las VMs de backend, sin importar la regla de reenvío o la configuración del servicio de backend. El resto del tráfico, como los pings ICMP, se controlará mediante la siguiente ruta más específica en tu red de VPC.

Si una ruta creada antes del 15 de mayo de 2021 aún estába en funcionamiento el 16 de agosto de 2021, se migró de forma automática para reenviar todo el tráfico de protocolo a partir del 16 de agosto de 2021.

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

• El mismo destino y varios balanceadores de cargas de red de transferencia internos de próximo salto. Si creas dos o más rutas estáticas personalizadas con el mismo destino mediante diferentes próximos saltos del balanceador de cargas de red de transferencia interno, Google Cloud nunca distribuye el tráfico entre los próximos saltos del balanceador de cargas mediante ECMP. Si las rutas tienen prioridades únicas, Google Cloud usa el balanceador de cargas de red de transferencia interno de próximo 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 red interno de próximo 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 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.

• Varios destinos y el mismo balanceador de cargas de red de transferencia interno de próximo salto.

  Con etiquetas de instancia:

  Si usas etiquetas de instancia (también llamadas etiquetas de red), puedes usar el mismo balanceador de cargas de red de transferencia interno de próximo 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 próximo salto de balanceador de cargas de red de transferencia interno. 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 próximo salto de balanceador de cargas de red de transferencia 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 red de transferencia interno preferido, que realiza un frontend de un conjunto de dispositivos.

  Nota: Las rutas etiquetadas no se exportan ni se importan a través del intercambio de tráfico.

• 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 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 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 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 personalizada 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 (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 (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 (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?

• A fin de configurar un balanceador de cargas de red de transferencia interno para que sea el próximo salto, consulta Configura un balanceador de cargas de red de transferencia interno para dispositivos de terceros o Implementa una red de concentrador y radio mediante un balanceador de cargas como próximo salto.
• Para configurar y probar un balanceador de cargas de red de transferencia interno, consulta Configura un balanceador de cargas de red de transferencia interno con backends de grupos de instancias de VM.
• Para solucionar problemas de próximo salto del balanceador de cargas de red de transferencia interno, consulta Soluciona problemas de balanceadores de cargas de red de transferencia interna.