Configura un balanceador de cargas de red de transferencia interno para dispositivos de terceros

En Google Cloud, puedes integrar dispositivos de terceros con alta disponibilidad y escalamiento horizontal. Para hacerlo, configura una ruta estática y establece su próximo salto al balanceador de cargas de red de transferencia interno de Google Cloud. Esto permite que el balanceador de cargas balancee las cargas del tráfico de un prefijo de destino a un grupo de dispositivos de VM de terceros con verificación de estado.

En esta guía, se usa un ejemplo a fin de enseñarte a configurar un balanceador de cargas de red de transferencia interno para que sea el siguiente salto. Antes de seguir con esta guía, familiarízate con lo siguiente:

Permisos

Para seguir esta guía, debes crear instancias y modificar una red en un proyecto. Debes ser propietario o editor de un proyecto o tener todas las siguientes funciones de IAM de Compute Engine:

Tarea Función requerida
Crear redes, subredes y componentes del balanceador de cargas Administrador de redes
Agrega y quita reglas de firewall Administrador de seguridad
Crea instancias Administrador de instancias de Compute

Si deseas obtener más información, consulta las siguientes guías:

Configura balanceadores de cargas de red de transferencia internos como siguientes saltos con backends comunes

En esta guía se muestra cómo usar un balanceador de cargas de red de transferencia interno como el siguiente salto para una ruta estática a fin de integrar dispositivos virtuales de escalamiento horizontal.

La solución que se analiza en esta guía crea VMs de dispositivo que ejecutan Debian Linux. Las VM de ejemplo no realizan ningún filtrado de paquetes, pero puedes agregar esa funcionalidad si modificas la configuración de red de este ejemplo o si usas software de enrutamiento o filtrado de paquetes diferente.

En los pasos de esta sección, se describe cómo configurar los siguientes recursos:

  • Redes de VPC de muestra y subredes personalizadas
  • Reglas de firewall de Google Cloud que permiten conexiones entrantes a máquinas virtuales (VM) del dispositivo de backend
  • Rutas estáticas
  • Dos VMs cliente para probar las conexiones
  • Los siguientes componentes del balanceador de cargas de red de transferencia interno:
    • VMs de backend en un grupo de instancias administrado (MIG)
    • Una verificación de estado del servicio de las VM
    • Un servicio de backend interno en la región us-west1 para administrar la distribución de conexiones entre las VM de backend
    • Una regla de reenvío interno y una dirección IP interna para el frontend del balanceador de cargas

En este ejemplo, se muestra el balanceo de cargas a varias NIC de backend, como se describe en Balanceo de cargas a varias NIC.

La topología se ve de esta forma:

Ejemplo detallado de varios NIC del próximo salto para el balanceador de cargas de red de transferencia interna
Ejemplo detallado de varios NIC del próximo salto para el balanceador de cargas de red de transferencia interna (haz clic para agrandar)

En el diagrama se muestran algunos de los recursos que el ejemplo crea:

  • Instancias de aplicación detrás de un balanceador de cargas de red de transferencia interno (fr-ilb1, en este ejemplo). Las instancias de la aplicación solo tienen direcciones IP internas.
  • Cada instancia de aplicación tiene habilitada la marca can-ip-forward. Sin esta marca, una VM de Compute Engine solo puede transmitir un paquete si la dirección IP de origen del paquete coincide con la dirección IP interna de la VM, una dirección IP de un rango de IP de alias o una dirección IP de una regla de reenvío que se resuelve en la VM. La marca can-ip-forward cambia este comportamiento para que la VM pueda transmitir paquetes con cualquier dirección IP de origen.
  • Una ruta estática con destino 10.50.1.0/24 y el próximo salto establecidos en la regla de reenvío del balanceador de cargas, fr-ilb1.

El diagrama también muestra el flujo de tráfico:

  • La red de VPC testing tiene una ruta estática para el tráfico que se destina a la subred 10.50.1.0/24. Esta ruta dirige el tráfico al balanceador de cargas.
  • El balanceador de cargas reenvía el tráfico a una de las instancias de la aplicación según la afinidad de sesión configurada. La afinidad de sesión solo afecta el tráfico de TCP.

Para casos prácticos adicionales, consulta Balanceadores de cargas TCP/UDP internos como siguientes saltos.

Configura redes, regiones y subredes

En este ejemplo, se usan las siguientes redes de VPC, regiones y subredes:

  • Redes: En este ejemplo, se requieren dos redes, cada una con al menos una subred. Cada VM de dispositivo de terceros de backend debe tener al menos dos interfaces de red, una en cada red de VPC. En este ejemplo, las redes son redes de VPC en modo personalizado denominadas testing y production. En este ejemplo, la red testing contiene el cliente y el balanceador de cargas. La red production contiene la VM de destino.

  • Región: Las subredes se encuentran en la región us-west1. Las subredes deben estar en la misma región porque las instancias de VM son recursos zonales.

  • Subredes: Las subredes, testing-subnet y production-subnet, usan los rangos de direcciones IP primarias 10.30.1.0/24 y 10.50.1.0/24, respectivamente.

Para crear las redes y las subredes de ejemplo, sigue estos pasos.

Console

Crea la red testing y la testing-subnet:

  1. En la consola de Google Cloud, ve a la página Redes de VPC.

    Ir a las redes de VPC

  2. Haga clic en Crear red de VPC.

  3. En Nombre ingresa testing.

  4. En la sección Subredes:

    • Establece Modo de creación de subred en Personalizado.
    • En la sección Nueva subred, ingresa la siguiente información:
      • Nombre: testing-subnet
      • Región: us-west1
      • Rangos de direcciones IP: 10.30.1.0/24
      • Haz clic en Listo.

  5. Haz clic en Crear.

Crea la red production y la production-subnet:

  1. En la consola de Google Cloud, ve a la página Redes de VPC.

    Ir a las redes de VPC

  2. Haga clic en Crear red de VPC.

  3. En Nombre ingresa production.

  4. En la sección Subredes:

    • Establece Modo de creación de subred en Personalizado.
    • En la sección Nueva subred, ingresa la siguiente información:
      • Nombre: production-subnet
      • Región: us-west1
      • Rangos de direcciones IP: 10.50.1.0/24
      • Haz clic en Listo.

  5. Haz clic en Crear.

gcloud

  1. Crea las redes de VPC en modo personalizado:

    gcloud compute networks create testing --subnet-mode=custom

    gcloud compute networks create production --subnet-mode=custom

  2. Crea subredes en las redes testing y production en la región us-west1:

    gcloud compute networks subnets create testing-subnet \
    --network=testing \
    --range=10.30.1.0/24 \
    --region=us-west1

    gcloud compute networks subnets create production-subnet \
    --network=production \
    --range=10.50.1.0/24 \
    --region=us-west1

Configura las reglas de firewall

En este ejemplo se usan las siguientes reglas de firewall:

  • fw-allow-testing-from-both: Es una regla de entrada aplicable a todos los destinos de la red testing. Esta regla permite el tráfico proveniente de las fuentes pertenecientes a los rangos de direcciones IP 10.30.1.0/24 y 10.50.1.0/24. Estos dos rangos cubren las direcciones IP internas principales de las VM en ambas redes.

  • fw-allow-production-from-both: Es una regla de entrada aplicable a todos los destinos de la red production. Esta regla permite el tráfico proveniente de las fuentes pertenecientes a los rangos de direcciones IP 10.30.1.0/24 y 10.50.1.0/24. Estos dos rangos cubren las direcciones IP internas principales de las VM en ambas redes.

  • fw-allow-testing-ssh: Una regla de entrada aplicada a las instancias de VM de la red de VPC testing. Esta regla permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un rango de IP de origen más restrictivo para esta regla. Por ejemplo, puedes especificar los rangos de IP de los sistemas desde los que planeas iniciar sesiones SSH. En este ejemplo, se usa la etiqueta de destino allow-ssh para identificar las VM a las que se aplica la regla de firewall.

  • fw-allow-production-ssh: Una regla de entrada aplicada a las instancias de VM de la red de VPC production. Esta regla permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Al igual que la regla fw-allow-testing-ssh, puedes elegir un rango de IP de origen más restrictivo para esta regla.

  • fw-allow-health-check: Una regla de entrada para las VM de dispositivo de terceros con balanceo de cargas. Esta regla permite el tráfico proveniente de los sistemas de verificación de estado de Google Cloud (130.211.0.0/22 y 35.191.0.0/16). En este ejemplo, se usa la etiqueta de destino allow-health-check para identificar las instancias a las que debe aplicarse.

  • fw-allow-production-health-check: Una regla de entrada para las VM de dispositivo de terceros con balanceo de cargas. Esta regla permite el tráfico proveniente de los sistemas de verificación de estado de Google Cloud (130.211.0.0/22 y 35.191.0.0/16). En este ejemplo, se usa la etiqueta de destino allow-health-check para identificar las instancias a las que debe aplicarse.

Sin estas reglas de firewall, la regla de entrada predeterminada denegada bloquea el tráfico entrante a las instancias de backend. Debes crear una regla de firewall para permitir las verificaciones de estado de los rangos de IP de los sistemas de sondeo de Google Cloud. Consulta los rangos de IP de sondeo para obtener más información.

Console

  1. En la consola de Google Cloud, ve a la página Políticas de firewall.

    Ir a Políticas de firewall

  2. Haz clic en Crear regla de firewall y, luego, ingresa la siguiente información para crear la regla que permitirá que las VM de prueba reciban paquetes de las subredes de prueba y producción:

    • Nombre: fw-allow-testing-from-both
    • Red: testing
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: todas las instancias de la red
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 10.30.1.0/24, 10.50.1.0/24
    • Protocolos y puertos: permitir todos

  3. Haz clic en Crear.

  4. Haz clic en Crear regla de firewall y, luego, ingresa la siguiente información para crear la regla que permitirá que las VM de producción reciban paquetes de las subredes de pruebas y producción:

    • Nombre: fw-allow-production-from-both
    • Red: production
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: todas las instancias de la red
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 10.30.1.0/24, 10.50.1.0/24
    • Protocolos y puertos: permitir todos

  5. Haz clic en Crear.

  6. Haz clic en Crear regla de firewall para crear la regla que permite conexiones SSH entrantes en el entorno de pruebas:

    • Nombre: fw-allow-testing-ssh
    • Red: testing
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-ssh
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 0.0.0.0/0
    • Protocolos y puertos: Elige Protocolos y puertos especificados y escribe: tcp:22

  7. Haz clic en Crear.

  8. Haz clic en Crear regla de firewall para crear la regla que permite conexiones SSH entrantes en el entorno de producción:

    • Nombre: fw-allow-production-ssh
    • Red: production
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-ssh
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 0.0.0.0/0
    • Protocolos y puertos: Elige Protocolos y puertos especificados y escribe: tcp:22

  9. Haz clic en Crear.

  10. Haz clic en Crear regla de firewall para crear la regla que permite las verificaciones de estado de Google Cloud en el entorno de pruebas:

    • Nombre: fw-allow-health-check
    • Red: testing
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-health-check
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 130.211.0.0/22 y 35.191.0.0/16
    • Protocolos y puertos: tcp

  11. Haz clic en Crear.

  12. Haz clic en Crear regla de firewall para crear la regla que permite las verificaciones de estado de Google Cloud en el entorno de producción:

    • Nombre: fw-allow-production-health-check
    • Red: production
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-health-check
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 130.211.0.0/22 y 35.191.0.0/16
    • Protocolos y puertos: tcp

  13. Haz clic en Crear.

gcloud

  1. Crea la regla de firewall fw-allow-testing-subnet para permitir que las VM de prueba reciban paquetes de las subredes testing y production:

    gcloud compute firewall-rules create fw-allow-testing-from-both \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  2. Crea la regla de firewall fw-allow-production-subnet para permitir que las VM de producción reciban paquetes de las subredes testing y production:

    gcloud compute firewall-rules create fw-allow-production-from-both \
    --network=production \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

  3. Crea la regla de firewall fw-allow-testing-ssh para permitir la conectividad SSH a las VM con la etiqueta de red allow-ssh. Cuando omites source-ranges, Google Cloud interpreta que la regla significa cualquier fuente.

    gcloud compute firewall-rules create fw-allow-testing-ssh \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  4. Crea la regla de firewall fw-allow-production-ssh para permitir la conectividad SSH a las VM con la etiqueta de red allow-ssh.

    gcloud compute firewall-rules create fw-allow-production-ssh \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  5. Crea la regla fw-allow-health-check para permitir las verificaciones de estado de Google Cloud en las VM de los dispositivos de terceros en la red testing.

    gcloud compute firewall-rules create fw-allow-testing-health-check \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp

  6. Crea la regla de firewall fw-allow-production-health-check para permitir las verificaciones de estado de Google Cloud en las VM de los dispositivos de terceros en la red production.

    gcloud compute firewall-rules create fw-allow-production-health-check \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp

Crea dispositivos virtuales de terceros

En los siguientes pasos, se demuestra cómo crear una plantilla de instancias y un grupo de instancias regional administrado con más de una interfaz de red. Este grupo de instancias se usa como el dispositivo virtual de terceros para este ejemplo.

Console

Debes usar gcloud para este paso porque necesitas crear una plantilla de instancias con más de una interfaz de red. En este momento, la consola de Google Cloud no admite la creación de plantillas de instancias con más de una interfaz de red.

gcloud

  1. Crea un archivo local llamado config.sh y, luego, inserta el siguiente contenido:

    #!/bin/bash
# Enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf
# Read VM network configuration:
md_vm="http://metadata.google.internal/computeMetadata/v1/instance/"
md_net="$md_vm/network-interfaces"
nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )"
nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')"
nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")"
nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")"
nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")"
nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')"
# Source based policy routing for nic1
echo "100 rt-nic1" >> /etc/iproute2/rt_tables
sudo ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
sleep 1
sudo ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
sudo ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1
# Use a web server to pass the health check for this example.
# You should use a more complete test in production.
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html
sudo systemctl restart apache2

  2. Crea una plantilla de instancias para los dispositivos virtuales de terceros. La plantilla de instancias debe incluir la marca --can-ip-forward para que las instancias de VM creadas a partir de la plantilla puedan reenviar paquetes de otras instancias en las redes testing y production.

    gcloud compute instance-templates create third-party-template-multinic \
    --region=us-west1 \
    --network-interface subnet=testing-subnet,address="" \
    --network-interface subnet=production-subnet \
    --tags=allow-ssh,allow-health-check,my-network-tag \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --can-ip-forward \
    --metadata=startup-script="$(< config.sh)"

  3. Crea un grupo de instancias administrado para tus dispositivos virtuales de terceros. Con este comando, se crea un grupo de instancias regional administrado, en el que luego se puede realizar un ajuste de escala automático en us-west1.

    gcloud compute instance-groups managed create third-party-instance-group \
    --region=us-west1 \
    --template=third-party-template-multinic \
    --size=3

Crea los recursos de balanceo de cargas

Con estos pasos se configuran todos los componentes del balanceador de cargas de red de transferencia interno; se comienza con la verificación de estado y el servicio de backend y, luego, los componentes de frontend:

  • Verificación de estado: En este ejemplo, se usa la verificación de estado HTTP que busca una respuesta HTTP 200 (OK). Para obtener más información, consulta la sección de verificaciones de estado de la descripción general del balanceador de cargas de red de transferencia interno.

  • Servicio de backend: aunque en este servicio de backend del ejemplo se especifica el protocolo TCP, cuando el balanceador de cargas es el siguiente salto para una ruta, Google Cloud reenvía tráfico para todos los protocolos (TCP, UDP e ICMP).

  • Regla de reenvío: Aunque en este ejemplo la regla de reenvío especifica el puerto TCP 80, cuando el balanceador de cargas es el siguiente salto para una ruta, el tráfico en cualquier puerto TCP o UDP se envía a los backends del balanceador de cargas.

  • Dirección IP interna: En este ejemplo, se especifica una dirección IP interna, 10.30.1.99, para la regla de reenvío.

Console

Inicia la configuración

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. Haz clic en Crear balanceador de cargas.
  3. En Tipo de balanceador de cargas, selecciona Balanceador de cargas de red (TCP/UDP/SSL) y haz clic en Siguiente.
  4. En Proxy o de transferencia, selecciona Balanceador de cargas de transferencia y haz clic en Siguiente.
  5. En Orientado al público o interno, selecciona Interno y haz clic en Siguiente.
  6. Haz clic en Configurar.

Crea el primer balanceador de cargas

  1. Configura el campo Nombre como ilb1.
  2. Establece la región en us-west1.
  3. Establece la Red en testing.
  4. Haz clic en Configuración de backend y realiza los siguientes cambios:
    1. En Backends, en la sección Nuevo elemento, selecciona el grupo de instancias third-party-instance-group y haz clic en Listo.
    2. En Verificación de estado, elige Crear otra comprobación de estado, ingresa la siguiente información y haz clic en Guardar y continuar:
      • Nombre: hc-http-80
      • Protocolo: HTTP
      • Puerto: 80
      • Protocolo de proxy: NONE
      • Ruta de la solicitud: / Ten en cuenta que cuando usas la consola de Google Cloud para crear el balanceador de cargas, la verificación de estado es global. Si quieres crear una verificación de estado regional, usa gcloud o la API.
    3. En Afinidad de sesión, selecciona IP de cliente.
    4. Verifica que haya una marca de verificación azul junto a Configuración de backend antes de continuar. Si no, revisa este paso.
  5. Haz clic en Configuración de frontend. En la sección IP y puerto de frontend nuevos, realiza los siguientes cambios:
    1. Nombre: fr-ilb1
    2. Subred: testing-subnet
    3. En IP interna elige Reserva una nueva dirección IP interna estática, ingresa la siguiente información y haz clic en Reservar:
      • Nombre: ip-ilb
      • Dirección IP estática: permíteme elegir
      • Dirección IP personalizada: 10.30.1.99
    4. Puertos: elige Único e ingresa 80 en el Número de puerto. Recuerda que la elección de un protocolo y un puerto para el balanceador de cargas no limita los protocolos ni los puertos que se usan cuando el balanceador de cargas es el siguiente salto de una ruta.
    5. Verifica que haya una marca de verificación azul junto a Configuración de frontend antes de continuar. Si no, revisa este paso.
  6. Haz clic en Revisar y finalizar. Vuelve a verificar la configuración.
  7. Haz clic en Crear.

Inicia tu configuración

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. Haz clic en Crear balanceador de cargas.
  3. En Tipo de balanceador de cargas, selecciona Balanceador de cargas de red (TCP/UDP/SSL) y haz clic en Siguiente.
  4. En Proxy o de transferencia, selecciona Balanceador de cargas de transferencia y haz clic en Siguiente.
  5. En Orientado al público o interno, selecciona Interno y haz clic en Siguiente.
  6. Haz clic en Configurar.

Crea el segundo balanceador de cargas

  1. Configura el campo Nombre como ilb2.
  2. Establece la región en us-west1.
  3. Establece la Red en production.
  4. Haz clic en Configuración de backend y realiza los siguientes cambios:
    1. En Backends, en la sección Nuevo elemento, selecciona el grupo de instancias third-party-instance-group y haz clic en Listo.
    2. En Verificación de estado, selecciona hc-http-80.
    3. En Afinidad de sesión, selecciona IP de cliente.
    4. Verifica que haya una marca de verificación azul junto a Configuración de backend antes de continuar. Si no, revisa este paso.
  5. Haz clic en Configuración de frontend. En la sección IP y puerto de frontend nuevos, realiza los siguientes cambios:
    1. Nombre: fr-ilb2
    2. Subred: production-subnet
    3. En IP interna elige Reserva una nueva dirección IP interna estática, ingresa la siguiente información y haz clic en Reservar:
      • Nombre: ip-ilb2
      • Dirección IP estática: permíteme elegir
      • Dirección IP personalizada: 10.50.1.99
    4. Puertos: elige Único e ingresa 80 en el Número de puerto. Recuerda que la elección de un protocolo y un puerto para el balanceador de cargas no limita los protocolos ni los puertos que se usan cuando el balanceador de cargas es el siguiente salto de una ruta.
    5. Verifica que haya una marca de verificación azul junto a Configuración de frontend antes de continuar. Si no, revisa este paso.
  6. Haz clic en Revisar y finalizar. Vuelve a verificar la configuración.

  7. Haz clic en Crear.

  8. Configura los recursos del balanceador de cargas en la red de VPC de production.

gcloud

  1. Crea una verificación de estado HTTP nueva para probar la conectividad TCP a las VM en 80.

    gcloud compute health-checks create http hc-http-80 \
    --region=us-west1 \
    --port=80

  2. Crea dos servicios de backend internos en la región us-west1.

    gcloud compute backend-services create ilb1 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=testing \
    --session-affinity=CLIENT_IP

    gcloud compute backend-services create ilb2 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=production \
    --session-affinity=CLIENT_IP

  3. Agrega los grupos de instancias que contienen los dispositivos virtuales de terceros como backends en los servicios de backend.

    gcloud compute backend-services add-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services add-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  4. Crea las reglas de reenvío interno y conéctalas a los servicios de backend para completar la configuración del balanceador de cargas. Recuerda que el protocolo (TCP) y el puerto (80) de los balanceadores de cargas no limitan los puertos ni los protocolos que se envían a las instancias de backend (los dispositivos virtuales de terceros) cuando se usan los balanceadores de cargas como los siguientes saltos de las rutas.

    gcloud compute forwarding-rules create fr-ilb1 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=testing \
    --subnet=testing-subnet \
    --region=us-west1 \
    --backend-service=ilb1 \
    --address=10.30.1.99

    gcloud compute forwarding-rules create fr-ilb2 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=production \
    --subnet=production-subnet \
    --region=us-west1 \
    --backend-service=ilb2 \
    --address=10.50.1.99

Crea las rutas estáticas que definan los balanceadores de cargas como los siguientes saltos

Crea dos rutas estáticas que usen un balanceador de cargas de próximo salto.

Console

Crea la primera ruta

  1. En la consola de Google Cloud, ve a la página Rutas.

    Ir a Rutas

  2. Haz clic en Crear ruta.

  3. Para el Nombre de la ruta, ingresa ilb-nhop-dest-10-50-1.

  4. Selecciona la red testing.

  5. Para el Rango de IP de destino, ingresa 10.50.1.0/24.

  6. En Etiquetas de instancia, ingresa my-network-tag.

  7. Para el Siguiente salto de la ruta, selecciona Especificar una regla de reenvío del balanceador de cargas interno TCP/UDP.

    Para especificar la dirección IP del balanceador de cargas como siguiente salto, usa la CLI de gcloud o la API.

  8. Especifica el nombre de la regla de reenvío. Para el nombre de la regla de reenvío, selecciona fr-ilb1.

  9. Haz clic en Crear.

Crea la segunda ruta

  1. Haz clic en Crear ruta.
  2. Para el Nombre de la ruta, ingresa ilb-nhop-dest-10-30-1.
  3. Selecciona la red testing.
  4. Para el Rango de IP de destino, ingresa 10.30.1.0/24.

  5. Para el Siguiente salto de la ruta, selecciona Especificar una regla de reenvío del balanceador de cargas interno TCP/UDP.

    Para especificar la dirección IP del balanceador de cargas como siguiente salto, usa la CLI de gcloud o la API.

  6. Para el nombre de la regla de reenvío, selecciona fr-ilb2.

  7. Haz clic en Crear.

gcloud

Crea rutas estáticas con el próximo salto establecido en la regla de reenvío de cada balanceador de cargas y cada rango de destino configurado de manera acorde.

Para la marca --next-hop-ilb, puedes especificar un nombre de regla de reenvío o la dirección IP de la regla de reenvío. Una dirección IP de la regla de reenvío de próximo salto puede ubicarse en la misma red de VPC que contiene la ruta o en una red de VPC con intercambio de tráfico. Para obtener más información, consulta Proyecto y red de próximo salto.

En el ejemplo, la primera ruta usa la dirección IP 10.30.1.99, mientras que la segunda ruta usa el nombre de regla de reenvío fr-ilb12.

De manera opcional, puedes especificar una o más etiquetas de instancia en la ruta. La ruta se puede aplicar a VM específicas si especificas etiquetas de red en la ruta. Si no especificas ninguna etiqueta de red, la ruta se aplica a todas las VM de la red de VPC. En este ejemplo, la ruta usa my-network-tag para la etiqueta de red de la ruta.

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=10.30.1.99 \
    --tags=my-network-tag

gcloud compute routes create ilb-nhop-dest-10-30-1 \
    --network=production \
    --destination-range=10.30.1.0/24 \
    --next-hop-ilb=fr-ilb2 \
    --next-hop-ilb-region=us-west1

Crea la instancia de VM de testing

En este ejemplo, se crea una instancia de VM con la dirección IP 10.30.1.100 en la testing-subnet (10.30.1.0/24) en la red de VPC de testing.

gcloud

  1. Crea el testing-vm mediante la ejecución del siguiente comando.

    gcloud compute instances create testing-vm \
    --zone=us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh,my-network-tag \
    --subnet=testing-subnet \
    --private-network-ip 10.30.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

Crea la instancia de VM de production

En este ejemplo, se crea una instancia de VM con la dirección IP 10.50.1.100 en la production-subnet (10.50.1.0/24) en la red de VPC de production.

gcloud

production-vm puede estar en cualquier zona de la misma región que el balanceador de cargas y puede usar cualquier subred de esa región. En este ejemplo, production-vm está en la zona us-west1-a.

  1. Crea el production-vm mediante la ejecución del siguiente comando.

    gcloud compute instances create production-vm \
    --zone=us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=production-subnet \
    --private-network-ip 10.50.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://metadata.google.internal/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

Prueba el balanceo de cargas en una implementación de varias NIC

  1. Verifica el estado de los backends del balanceador de cargas.

    gcloud compute backend-services get-health ilb1 --region us-west1

    gcloud compute backend-services get-health ilb2 --region us-west1

  2. Prueba la conectividad desde la VM de testing.

    gcloud compute ssh testing-vm --zone=us-west1-a

    curl http://10.50.1.99

    exit

  3. Prueba la conectividad desde la VM de production.

    gcloud compute ssh production-vm --zone=us-west1-a

    curl http://10.30.1.99

    exit

Habilita el hash simétrico

Cuando se calcula el hash que se asigna a la instancia de backend, Google Cloud ignora la dirección de las direcciones IP y los puertos. El valor de hash coherente calculado de un paquete TCP/UDP es el mismo sin importar la dirección de la que provenga el paquete. Esto se denomina hash simétrico.

Para habilitar este comportamiento de hash en los balanceadores de cargas de red de transferencia internos existentes, debes volver a crear la regla de reenvío y la ruta del siguiente salto.

Para obtener más información, consulta Hash simétrico.

Borra y vuelve a crear las reglas de reenvío

Console

Borra tu regla de reenvío y crea una nueva

  1. En la consola de Google Cloud, ve a la página Balanceo de cargas.

    Ir a Balanceo de cargas

  2. Haz clic en tu balanceador de cargas be-ilb y, luego, en Editar.

  3. Haga clic en Configuración de frontend.

  4. Mantén el puntero sobre la regla de reenvío y haz clic en Borrar para quitarla.

  5. Haz clic en Agregar IP y puerto de frontend.

  6. En la sección IP y puerto de frontend nuevos, realiza los siguientes cambios:

    1. Nombre: FORWARDING_RULE_NAME
    2. Subred: SUBNET_NAME
    3. En IP interna selecciona IP_ADDRESS
    4. Puertos: PORT_NUMBER o ALL
    5. Haz clic en Listo.
    6. Verifica que haya una marca de verificación azul junto a Configuración de frontend antes de continuar. Si no, revisa este paso.

  7. Haz clic en Revisar y finalizar. Vuelve a verificar la configuración.

  8. Haz clic en Crear.

gcloud

  1. Borra las reglas de reenvío existentes.

    gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
    --region=REGION

  2. Crea reglas de reenvío de reemplazo con el mismo nombre.

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=internal \
    --ports=PORT_NUMBER or `ALL` \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --region=REGION \
    --backend-service=BACKEND_SERVICE_NAME \
    --address=IP_ADDRESS

Cuándo no se necesita SNAT

Como se demuestra en el ejemplo anterior, no se necesita traducción de direcciones de red de origen (SNAT) cuando se cumplen todas las siguientes condiciones:

  • La regla de reenvío para el balanceador de cargas de red de transferencia interno se creó el 22 de junio de 2021 o después de esa fecha.
  • La ruta estática que hace referencia a la regla de reenvío se creó el 22 de junio de 2021 o después de esa fecha.
  • El servicio de backend del balanceador de cargas de red de transferencia interno no usa la configuración de afinidad de sesión NONE.

Puedes convertir una ruta del balanceador de cargas de red de transferencia interno de siguiente salto existente para usar el hash simétrico mediante estos pasos:

  • Asegúrate de que el servicio de backend del balanceador de cargas de red de transferencia interno no use la configuración de afinidad de sesión NONE.

  • Crea una regla de reenvío de reemplazo que haga referencia al mismo servicio de backend. La regla de reenvío de reemplazo usa una dirección IP diferente.

  • Crea una ruta estática de reemplazo que haga referencia a la regla de reenvío nueva. Asegúrate de que esta ruta de reemplazo tenga una prioridad más alta que la ruta existente.

  • Borra la ruta existente de menor prioridad (con referencia a la regla de reenvío anterior) y borra la regla de reenvío anterior.

Limpieza

  1. En la configuración del balanceador de cargas, quita el backend de los servicios de backend.

    gcloud compute backend-services remove-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

    gcloud compute backend-services remove-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

  2. Borra las rutas.

    gcloud compute routes delete ilb-nhop-dest-10-50-1

    gcloud compute routes delete ilb-nhop-dest-10-30-1

  3. En la configuración del balanceador de cargas, borra las reglas de reenvío.

    gcloud compute forwarding-rules delete fr-ilb1 \
    --region=us-west1

    gcloud compute forwarding-rules delete fr-ilb2 \
    --region=us-west1

  4. En la configuración del balanceador de cargas, borra los servicios de backend.

    gcloud compute backend-services delete ilb1 \
    --region=us-west1

    gcloud compute backend-services delete ilb2 \
    --region=us-west1

  5. En la configuración del balanceador de cargas, borra la verificación de estado.

    gcloud compute health-checks delete hc-http-80 \
    --region=us-west1

    Si usaste la consola de Google Cloud, la verificación de estado es global. Por lo tanto, el comando es el siguiente:

    gcloud compute health-checks delete hc-http-80 \
     --global

  6. Borra el grupo de instancias administrado.

    gcloud compute instance-groups managed delete third-party-instance-group \
    --region=us-west1

  7. Borra las plantillas de instancias.

    gcloud compute instance-templates delete third-party-template

    gcloud compute instance-templates delete third-party-template-multinic

  8. Borra las instancias de prueba y producción.

    gcloud compute instances delete testing-vm \
    --zone=us-west1-a

    gcloud compute instances delete production-vm \
    --zone=us-west1-a

¿Qué sigue?