Balanceadores de carga de red de paso a través internos como siguientes saltos

Un balanceador de carga de red de paso a través interno es un balanceador de carga regional que te permite ejecutar y escalar tus servicios mediante una dirección IP interna. Puedes usar un balanceador de carga de red de transferencia interno como el siguiente salto al que se reenvían los paquetes en la ruta hacia su destino final. Para ello, debes definir el balanceador de carga como el siguiente salto en una ruta estática.

Antes de consultar la información de esta página, debes familiarizarte con los conceptos que se indican a continuación:

Un siguiente salto de balanceador de carga de red de paso a través interno es útil en los siguientes casos:

  • Para equilibrar la carga del tráfico entre varias máquinas virtuales que funcionan como máquinas virtuales de pasarela o de router.

  • Para usar dispositivos virtuales de la pasarela como siguiente salto de una ruta predeterminada. Con esta configuración, las instancias de máquina virtual (VM) de tu red de nube privada virtual (VPC) envían tráfico a Internet a través de un conjunto de VMs de gateway virtual con balanceo de carga.

  • Para enviar tráfico a través de varios balanceadores de carga en dos o más direcciones usando el mismo conjunto de máquinas virtuales de pasarela o router con varias NIC como back-ends. Para ello, crea un balanceador de carga y úsalo como el siguiente salto de una ruta estática en cada red de VPC. Cada balanceador de carga de red de paso a través interno funciona en una sola red de VPC y distribuye el tráfico a las interfaces de red de las VMs de backend de esa red.

Arquitectura

En el siguiente diagrama, un grupo de instancias de VM de routers actúa como backend de dos balanceadores de carga diferentes. El primer balanceador de carga de red de paso a través interno envía paquetes a nic0 de las VMs de backend, y el segundo balanceador de carga de red de paso a través interno envía paquetes a nic1 en los mismos backends.

Balanceo de carga en varias NICs.
Balanceo de carga en varias NICs (haz clic para ampliar).

Ventajas de usar un balanceador de carga de red de paso a través interno como siguiente salto

Cuando el balanceador de carga es el siguiente salto de una ruta estática, no es necesario realizar ninguna configuración especial en los sistemas operativos invitados de las VMs cliente de la red de VPC en la que se define la ruta. Las VMs cliente envían paquetes a los backends del balanceador de carga a través del enrutamiento de la red de VPC, de forma bump-in-the-wire.

Usar un balanceador de carga de red de paso a través interno como siguiente salto de una ruta estática ofrece las mismas ventajas que un balanceador de carga de red de paso a través interno independiente. La comprobación del estado del balanceador de carga asegura que las conexiones nuevas se dirijan a las VMs de backend en buen estado. Si usas un grupo de instancias gestionadas como backend, puedes configurar el autoescalado para aumentar o reducir el conjunto de VMs en función de la demanda del servicio.

Especificaciones

A continuación, se indican las especificaciones para usar balanceadores de carga de red de paso a través internos como siguientes saltos.

Rutas

Puedes crear una ruta estática para enviar tráfico TCP, UDP y de otros protocolos a un balanceador de carga de red interno de tipo pasarela, donde el balanceador de carga es el siguiente salto de la ruta estática. La ruta puede ser un prefijo CIDR externo (con enrutamiento público) o un prefijo CIDR interno, siempre que el prefijo no entre en conflicto con una ruta de subred. Por ejemplo, puedes sustituir tu ruta predeterminada (0.0.0.0/0) por una ruta que dirija el tráfico a máquinas virtuales backend de terceros para procesar paquetes.

Opciones para especificar el siguiente salto

Puedes especificar un siguiente salto de balanceador de carga de red de paso a través interno de dos formas:

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

Para obtener información sobre el proyecto y la red de VPC en los que puede residir el siguiente salto de un balanceador de carga de red interno de tipo pasarela, consulta Siguientes saltos y funciones.

Puedes intercambiar rutas estáticas con los siguientes saltos de los balanceadores de carga de red de paso a través internos mediante el emparejamiento entre redes de VPC. Para obtener más información, consulta Opciones para intercambiar rutas estáticas.

Afinidad de sesión por IP de cliente

Los balanceadores de carga de red de paso a través internos ofrecen dos opciones de afinidad de sesión similares para la "dirección IP del cliente":

  • IP de cliente (CLIENT_IP): 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 carga de red de paso a través 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 carga comparten una dirección IP de destino común: la dirección IP de la regla de reenvío. En esta situación, una de las direcciones usadas por el hash de tupla doble permanece constante. Por lo tanto, si el número 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): un hash de una tupla de la dirección IP de origen de un paquete. Cuando usas un balanceador de carga de red interno de tipo pasarela como siguiente salto, la dirección IP de destino suele variar porque son las que se especifican en el atributo de destino de la ruta. En esta situación, la afinidad de sesión de la tupla de dos elementos IP de cliente (CLIENT_IP) no puede seleccionar el mismo backend aunque el número de backends configurados y en buen estado no cambie y los paquetes tengan 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 IP de cliente, sin destino (CLIENT_IP_NO_DESTINATION).

Intervalo 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 siguiente salto es un balanceador de carga de red interno de tipo pasarela. Por ejemplo, supongamos que la ruta de tu subred es 10.140.0.0/20. El destino de una ruta estática no puede ser el mismo (10.140.0.0/20) ni más específico, como en 10.140.0.0/22.

Misma red VPC y región

Las rutas estáticas que usan balanceadores de carga de red de paso a través internos como siguientes saltos están limitadas a lo siguiente:

  • Una sola red de VPC. El balanceador de carga y la ruta estática deben estar en la misma red VPC.

  • Una sola región o todas las regiones. A menos que configure el acceso global, la ruta estática solo estará disponible para los recursos de la misma región que el balanceador de carga. Esta restricción regional se aplica aunque la ruta en sí forme parte de la tabla de enrutamiento de toda la red VPC. Si habilitas el acceso global, la ruta estática estará disponible para los recursos de cualquier región.

Anunciar 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 ámbito del anuncio de ruta depende del ajuste de acceso global del balanceador de carga, como se indica a continuación:

  • Cuando el acceso mundial está inhabilitado, el balanceador de carga de red con paso a través interno solo está disponible para las VMs, los túneles de Cloud VPN y los adjuntos de Cloud Interconnect (VLANs) que se encuentran en la misma región que el balanceador de carga. Por lo tanto, un anuncio de ruta personalizada para el prefijo de una ruta estática solo tiene sentido si el router de Cloud y el balanceador de carga están en la misma región.

  • Cuando el acceso global está habilitado, el balanceador de carga de red con paso a través interno está disponible para las máquinas virtuales, los túneles de Cloud VPN y las vinculaciones de Cloud Interconnect (VLANs) que se encuentren en cualquier región. Con el enrutamiento dinámico global, los sistemas locales pueden usar la ruta estática de cualquier región conectada.

En la siguiente tabla se resume la accesibilidad del balanceador de carga.

Acceso global Modo de enrutamiento dinámico de la red VPC Acceso al balanceador de carga
Inhabilitado Regional Los routers de la misma región pueden acceder a ella.
Inhabilitado Global Los routers de la misma región pueden acceder a ella.
Habilitado Regional Accesible para todos los routers de cualquier región
Habilitado Global Accesible para todos los routers de cualquier región

Para obtener más información, consulta Balanceadores de carga de red de paso a través internos y redes conectadas.

Orden de las operaciones

Debes crear un balanceador de carga de red de paso a través interno antes de poder crear una ruta estática que lo use como salto siguiente. El balanceador de carga debe existir para que puedas crear la ruta. Si intentas crear una ruta que haga referencia a un balanceador de carga que no existe,se devuelve un error. Google Cloud

Para especificar el siguiente salto de un balanceador de carga de red de paso a través interno, usa el nombre de la regla de reenvío y la región del balanceador de carga, o bien la dirección IP interna asociada a la regla de reenvío.

Después de crear una ruta con un siguiente salto que haga referencia a un balanceador de carga de red de paso a través interno, no podrás eliminar el balanceador de carga a menos que elimines primero la ruta. En concreto, no puedes eliminar una regla de reenvío interna hasta que ninguna ruta estática utilice ese balanceador de carga como siguiente salto.

Requisitos del backend

  • Debes configurar todas las VMs de backend del balanceador de carga de red de paso a través interno para que permitan el reenvío de IP (--can-ip-forward = True). Para obtener más información, consulta la sección Consideraciones comunes a las instancias y a los saltos siguientes del balanceador de carga de red de paso a través interno.

  • No puedes usar un balanceador de carga de red interno de tipo pases directos cuyos backends sean nodos de Google Kubernetes Engine (GKE) como siguiente salto de una ruta estática. El software de los nodos solo puede enrutar el tráfico a los pods si el destino coincide con una dirección IP gestionada por el clúster, no con un destino arbitrario.

Procesamiento del tráfico de TCP, UDP y otros protocolos

Cuando se implementa un balanceador de carga de red de paso a través interno como siguiente salto, Google Cloud reenvía todo el tráfico de todos los puertos a las VMs de backend, independientemente de lo siguiente:

  • La configuración del protocolo y el puerto de la regla de reenvío
  • Configuración del protocolo del servicio de backend

El balanceador de carga de red interno de tipo pasarela, que es el siguiente salto de la ruta, admite sin problemas el reenvío de todo el tráfico de los protocolos admitidos por las redes de VPC (como TCP, UDP e ICMP). Google Cloud

Consideraciones adicionales

  • Reglas de reenvío admitidas: Google Cloud solo se admiten las reglas de reenvío de balanceadores de carga de red internos de transferencia directa de siguiente salto. Google Cloud No se admiten las reglas de reenvío de siguiente salto que usan otros balanceadores de carga, la redirección de protocolos ni los endpoints de Private Service Connect.

  • Métodos de especificación y red y proyecto de la regla de reenvío. Puede especificar una regla de reenvío de salto siguiente mediante uno de los tres métodos siguientes. El método de especificación que utilices determinará si la red de la regla de reenvío debe coincidir con la red de la ruta y en qué proyecto se puede encontrar la regla de reenvío.

    Elige uno de los siguientes métodos y asegúrate de que la versión de IP de tu regla de reenvío coincida con la versión de IP de la ruta estática que crees:

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

    • Por enlace de recurso de regla de reenvío: el enlace de recurso de una regla de reenvío usa el 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 especifiques una regla de reenvío del siguiente salto por su enlace de recurso, la red de la regla de reenvío debe coincidir con la red VPC de la ruta. La regla de reenvío puede estar en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto del host de VPC compartida) o en un proyecto de servicio de VPC compartida.

    • Por la dirección IP de una regla de reenvío: cuando especifiques una regla de reenvío de próximo salto por su dirección IPv4 o IPv6, la red de la regla de reenvío puede ser la red de VPC de la ruta o una red de VPC conectada a la red de VPC de la ruta mediante el emparejamiento entre redes de VPC o Network Connectivity Center. Network Connectivity Center admite un balanceador de carga de red de paso a través interno de siguiente salto en una VPC de radio sujeta a los requisitos de conectividad de Network Connectivity Center. La regla de reenvío puede estar en el proyecto que contiene la red de la regla de reenvío (un proyecto independiente o un proyecto del host de VPC compartida) o en un proyecto de servicio de VPC compartida.

  • Efecto del acceso global. Las rutas estáticas personalizadas que usan saltos siguientes de balanceadores de carga de red de paso a través internos se programan en todas las regiones. Si el siguiente salto se puede usar o no, depende de la configuración de acceso global del balanceador de carga. Si el acceso global está habilitado, se puede acceder al siguiente salto del balanceador de carga en todas las regiones de la red de VPC. Si el acceso global está inhabilitado, solo se puede acceder al siguiente salto del balanceador de carga en la misma región que el balanceador de carga. Si el acceso global está inhabilitado, los paquetes enviados desde otra región a una ruta que use un balanceador de carga de red con paso a través interno como siguiente salto se descartarán.

  • Cuando todos los backends están en mal estado. Cuando todas las backends de un balanceador de carga de red interno de tipo pasarela fallan en las comprobaciones de estado, las rutas que usan el siguiente salto de ese balanceador de carga siguen activas. Los paquetes procesados por la ruta se envían a uno de los backends del balanceador de carga del siguiente salto según la distribución del tráfico.

  • No se admiten reglas de reenvío que usen una dirección IP interna común (--purpose=SHARED_LOADBALANCER_VIP). Los balanceadores de carga de red de paso a través internos del siguiente salto y las reglas de reenvío de balanceadores de carga de red de paso a través internos con una dirección IP común son funciones mutuamente exclusivas. Un balanceador de carga de red de pases interno de siguiente salto debe usar una dirección IP única para la regla de reenvío del balanceador de carga, de modo que solo se haga referencia a un servicio de backend (un balanceador de carga) de forma inequívoca. 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 carga de red de transferencia internos).

  • Varias rutas con los mismos destinos y prioridades, pero con diferentes balanceadores de carga de red de paso a través internos del siguiente salto. Google Cloud Nunca distribuye el tráfico entre dos o más balanceadores de carga de red de paso a través internos del siguiente salto mediante ECMP. En su lugar,Google Cloud selecciona solo un balanceador de carga de red de paso a través interno del siguiente salto mediante un algoritmo interno determinista. Para evitar esta ambigüedad, puedes usar etiquetas de red únicas para cada ruta.

    Google Cloud selecciona un único siguiente salto cuando las rutas estáticas con diferentes siguientes saltos de balanceador de carga de red de paso a través interno tienen la misma prioridad y el mismo destino.

  • Varias rutas con los mismos destinos, prioridades y saltos siguientes balanceadores de carga de red de transferencia interna. Sin una etiqueta de red, Google Cloud no Google Cloud te permite crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y siguiente salto del balanceador de carga de red de paso a través interno. Con las etiquetas de red, puedes crear varias rutas estáticas que tengan la misma combinación de destino, prioridad y siguiente salto del balanceador de carga de red de paso a través interno.

Casos prácticos

Puedes usar un balanceador de carga de red de paso a través interno como próximo salto en varias implementaciones y topologías.

En cada ejemplo, ten en cuenta las siguientes directrices:

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

  • No puedes usar máquinas virtuales de backend ni balanceadores de carga para enrutar el tráfico entre subredes de la misma red de VPC, ya que las rutas de subred no se pueden anular.

  • El balanceador de carga de red de paso a través interno es un balanceador de carga de paso a través definido por software. Los paquetes se entregan a las VMs backend sin que se modifique 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 actúan como backend del balanceador de carga de red de paso a través interno.

Usar un balanceador de carga de red de paso a través interno como siguiente salto a una pasarela NAT

En este caso práctico, se balancea la carga del tráfico de las máquinas virtuales internas a varias instancias de pasarela de NAT que dirigen el tráfico a Internet.

Caso práctico de NAT.
Caso práctico de NAT (haz clic en la imagen para ampliarla).

Hub y spoke: intercambiar rutas de salto siguiente mediante el emparejamiento entre redes de VPC

Además de intercambiar rutas de subred, puedes configurar el emparejamiento entre redes de VPC para exportar e importar rutas estáticas y dinámicas personalizadas. Se excluyen las rutas estáticas que tienen como siguiente salto la pasarela de Internet predeterminada. Se incluyen las rutas estáticas personalizadas que usan balanceadores de carga de red de paso a través internos del siguiente salto.

Puedes configurar una topología de concentrador y radios con tus dispositivos virtuales de cortafuegos de salto siguiente ubicados en la red de VPC hub haciendo lo siguiente:

  • En la red de hub VPC, crea un balanceador de carga de red interno de tipo Pasarela con dispositivos virtuales de cortafuegos como back-ends.
  • En la red de VPC hub, crea una ruta estática y define el siguiente salto como el balanceador de carga de red interno de transferencia.
  • Conecta la red de VPC hub a cada una de las redes de VPC spoke mediante el emparejamiento entre redes de VPC.
  • En cada emparejamiento, configura la red hub para que exporte sus rutas personalizadas y la red spoke correspondiente para que importe rutas personalizadas. La ruta con el balanceador de carga como siguiente salto es una de las rutas que exporta la red hub.

Según el orden de enrutamiento, el balanceador de carga del dispositivo de cortafuegos de salto siguiente de la red de VPC hub está disponible en las redes de radio:

  • a los clientes de la misma región que el balanceador de carga, si el acceso global está inhabilitado
  • a los clientes de todas las regiones, si el acceso global está habilitado, según el orden de enrutamiento.
Hub y spoke.
Topología de concentrador y radios (haz clic en la imagen para ampliarla).

Balanceo de carga en varias NICs

En el siguiente caso práctico, las VMs de backend son instancias de dispositivos virtuales (por ejemplo, VMs de inspección de paquetes, enrutamiento o pasarela) con NICs en varias redes de VPC. Estas instancias de dispositivos virtuales pueden ser soluciones comerciales de terceros o soluciones que hayas creado tú mismo. Los dispositivos virtuales son máquinas virtuales de Compute Engine con varias NICs.

En este ejemplo se muestra un único conjunto de dispositivos virtuales de backend en un grupo de instancias de máquina virtual gestionadas.

En la red de VPC llamada testing, el balanceador de carga de red de paso a través interno tiene una regla de reenvío llamada fr-ilb1. En el ejemplo, este balanceador de carga distribuye el tráfico a la interfaz nic0.

En la red de VPC llamada production, otro balanceador de carga de red de paso a través interno tiene una regla de reenvío llamada fr-ilb2. Este balanceador de carga distribuye el tráfico a otra interfaz, nic1 en este ejemplo.

Tráfico con balanceo de carga de varias NICs.
Tráfico con balanceo de carga de varias NICs (haz clic para ampliar).

Para obtener información detallada sobre la configuración, consulta Balanceo de carga en varias NICs de backend.

Funciones hash simétricas

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

Notas:

  • El cifrado simétrico se habilita automáticamente cuando creas la regla de reenvío del balanceador de carga de red interno de pasarela el 22 de junio del 2021 o después.

  • Para habilitar el hashing simétrico en los balanceadores de carga de red de paso a través internos, debes volver a crear la regla de reenvío y la ruta del siguiente salto, tal como se describe en Habilitar el hashing simétrico.

  • El cifrado simétrico solo se admite con balanceadores de carga de red de paso a través internos.

  • El cifrado simétrico se admite 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, protocolo y puerto de cliente (CLIENT_IP_PORT_PROTO)

    Para obtener más información sobre estos ajustes, consulta las opciones de afinidad de sesión.

  • También puedes usar SNAT si tu caso práctico lo requiere por algún motivo.

Siguientes pasos