Configurar un balanceador de carga de red de paso a través interno para aplicaciones de terceros

En Google Cloud, puedes integrar dispositivos de terceros de forma altamente disponible y escalable. Para ello, configura una ruta estática y define su salto siguiente como el Google Cloud balanceador de carga de red de paso a través interno. De esta forma, el balanceador de carga puede balancear la carga del tráfico de un prefijo de destino a un grupo de aplicaciones de VM de terceros con comprobación del estado.

En esta guía se usa un ejemplo para mostrarte cómo configurar un balanceador de carga de red de paso a través interno como siguiente salto. Antes de seguir 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 tener el rol de propietario o editor del proyecto, o bien tener todos los roles de gestión de identidades y accesos de Compute Engine siguientes:

Tarea Rol necesario
Crear redes, subredes y componentes de balanceador de carga Administrador de red
Añadir y eliminar reglas de cortafuegos Administrador de seguridad
Crear instancias Administrador de instancias de Compute

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

Configurar balanceadores de carga de red de paso a través internos como siguientes saltos con backends comunes

En esta guía se explica cómo usar un balanceador de carga de red de transferencia interna como el siguiente salto de una ruta estática para integrar dispositivos virtuales escalados horizontalmente.

La solución que se describe en esta guía crea VMs de dispositivo que ejecutan Debian Linux. Las VMs de ejemplo no realizan ningún filtrado de paquetes, pero puedes añadir esa función modificando la configuración de red de este ejemplo o usando otro software de filtrado o enrutamiento de paquetes.

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

  • Redes de VPC y subredes personalizadas de ejemplo
  • Google Cloud reglas de cortafuegos que permiten las conexiones entrantes a las máquinas virtuales (VMs) del dispositivo backend
  • Rutas estáticas
  • Dos máquinas virtuales de cliente para probar las conexiones
  • Los siguientes componentes del balanceador de carga de red de paso a través interno:
    • Máquinas virtuales de backend de un grupo de instancias gestionado
    • Una comprobación del estado de las VMs de backend
    • Un servicio de backend interno en la región us-west1 para gestionar la distribución de conexiones entre las VMs de backend
    • Una regla de reenvío interna y una dirección IP interna para el frontend del balanceador de carga

En este ejemplo se muestra el balanceo de carga en varias NICs de backend, tal como se describe en Balanceo de carga en varias NICs.

La topología tiene este aspecto:

Ejemplo detallado de varias NICs de siguiente salto para el balanceador de carga de red de paso a través interno.
Ejemplo detallado de varias NICs de siguiente salto para un balanceador de carga de red de paso a través interno (haz clic para ampliar).

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

  • Instancias de aplicación detrás de un balanceador de carga de red de paso a través interno (fr-ilb1 en este ejemplo). Las instancias de la aplicación solo tienen direcciones IP internas.
  • Cada instancia de la 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 intervalo de IP de alias o una dirección IP de una regla de reenvío que se resuelva 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 el destino 10.50.1.0/24 y el siguiente salto configurado en la regla de reenvío del balanceador de carga 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 va a la subred 10.50.1.0/24. Esta ruta dirige el tráfico al balanceador de carga.
  • El balanceador de carga reenvía el tráfico a una de las instancias de la aplicación en función de la afinidad de sesión configurada. La afinidad de sesión solo afecta al tráfico TCP.

Para ver más casos prácticos, consulta Balanceadores de carga TCP/UDP internos como siguiente salto.

Configurar las redes, la región y las subredes

En este ejemplo se usan las siguientes redes de VPC, región y subredes:

  • Redes: en este ejemplo se necesitan 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. Las redes de este ejemplo son redes de VPC en modo personalizado llamadas testing y production. La red testing de este ejemplo contiene el cliente y el balanceador de carga. 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, ya que las instancias de VM son recursos zonales.

  • Subredes: las subredes testing-subnet y production-subnet usan los intervalos de direcciones IP principales 10.30.1.0/24 y 10.50.1.0/24, respectivamente.

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

Consola

Crea la red testing y la testing-subnet:

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

    Ir a redes de VPC

  2. Haz clic en Crear red VPC.

  3. Asigne un Nombre de testing.

  4. En la sección Subredes:

    • Elige Personalizado en Modo de creación de subred.
    • En la sección Nueva subred, introduce la siguiente información:
      • Nombre: testing-subnet
      • Región: us-west1
      • Intervalo 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 Google Cloud consola, ve a la página Redes de VPC.

    Ir a redes de VPC

  2. Haz clic en Crear red VPC.

  3. Asigne un Nombre de production.

  4. En la sección Subredes:

    • Elige Personalizado en Modo de creación de subred.
    • En la sección Nueva subred, introduce la siguiente información:
      • Nombre: production-subnet
      • Región: us-west1
      • Intervalo 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 de 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

Configurar reglas de cortafuegos

En este ejemplo se usan las siguientes reglas de cortafuegos:

  • fw-allow-testing-from-both: una regla de entrada aplicable a todos los destinos de la red testing. Esta regla permite el tráfico procedente de orígenes incluidos en los intervalos de direcciones IP 10.30.1.0/24 y 10.50.1.0/24. Estos dos intervalos cubren las direcciones IP internas principales de las VMs de ambas redes.

  • fw-allow-production-from-both: una regla de entrada aplicable a todos los destinos de la red production. Esta regla permite el tráfico procedente de orígenes incluidos en los intervalos de direcciones IP 10.30.1.0/24 y 10.50.1.0/24. Estos dos intervalos cubren las direcciones IP internas principales de las VMs de ambas redes.

  • fw-allow-testing-ssh: 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 intervalo de IPs de origen más restrictivo para esta regla. Por ejemplo, puedes especificar los intervalos de IPs de los sistemas desde los que tienes previsto iniciar sesiones SSH. En este ejemplo se usa la etiqueta de destino allow-ssh para identificar las VMs a las que se aplica la regla de cortafuegos.

  • fw-allow-production-ssh: 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 con la regla fw-allow-testing-ssh, puede elegir un intervalo de IPs de origen más restrictivo para esta regla.

  • fw-allow-health-check: una regla de entrada para las VMs de la aplicación de terceros que se están balanceando. Esta regla permite el tráfico de los sistemas de comprobación del estado (Google Cloud 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 se debe aplicar.130.211.0.0/22

  • fw-allow-production-health-check: una regla de entrada para las VMs de la aplicación de terceros que se están balanceando. Esta regla permite el tráfico de los sistemas de comprobación del estado (Google Cloud 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 se debe aplicar.130.211.0.0/22

Sin estas reglas de cortafuegos, la regla denegar predeterminada de entrada bloquea el tráfico entrante a las instancias de backend. Debes crear una regla de cortafuegos para permitir las comprobaciones de estado de los intervalos de direcciones IP de los sistemas de sondeo de Google Cloud . Consulta los intervalos de IPs de sondeo para obtener más información.

Consola

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

    Ir a Políticas de cortafuegos

  2. Haz clic en Crear regla de cortafuegos e introduce la siguiente información para crear la regla que permita que las VMs de prueba reciban paquetes de las subredes de prueba y de producción:

    • Nombre: fw-allow-testing-from-both
    • Red: testing
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción tras coincidencia: permitir
    • Destinos: todas las instancias de la red
    • Filtro de origen: Intervalos de IPv4
    • Intervalos 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 cortafuegos e introduce la siguiente información para crear la regla que permita que las VMs de producción reciban paquetes de las subredes de prueba y de producción:

    • Nombre: fw-allow-production-from-both
    • Red: production
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción tras coincidencia: permitir
    • Destinos: todas las instancias de la red
    • Filtro de origen: Intervalos de IPv4
    • Intervalos 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 cortafuegos para crear la regla que permita las 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 tras coincidencia: permitir
    • Destinos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-ssh
    • Filtro de origen: Intervalos de IPv4
    • Intervalos 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 cortafuegos para crear la regla que permita las 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 tras coincidencia: permitir
    • Destinos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-ssh
    • Filtro de origen: Intervalos de IPv4
    • Intervalos 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 cortafuegos para crear la regla que permita las comprobaciones del estado en el entorno de pruebas:Google Cloud

    • Nombre: fw-allow-health-check
    • Red: testing
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción tras coincidencia: permitir
    • Destinos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-health-check
    • Filtro de origen: Intervalos de IPv4
    • Intervalos 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 cortafuegos para crear la regla que permita Google Cloud comprobaciones del estado en el entorno de producción:

    • Nombre: fw-allow-production-health-check
    • Red: production
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción tras coincidencia: permitir
    • Destinos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-health-check
    • Filtro de origen: Intervalos de IPv4
    • Intervalos 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 cortafuegos fw-allow-testing-subnet para permitir que las VMs 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 cortafuegos fw-allow-production-subnet para permitir que las VMs 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 cortafuegos fw-allow-testing-ssh para permitir la conectividad SSH a las VMs con la etiqueta de red allow-ssh. Si omite source-ranges, Google Cloud interpreta que la regla se aplica a 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 cortafuegos fw-allow-production-ssh para permitir la conectividad SSH a las VMs 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 Google Cloud las comprobaciones del estado a las VMs del dispositivo 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 cortafuegos fw-allow-production-health-check para permitir que lasGoogle Cloud comprobaciones del estado se realicen en las VMs del dispositivo de terceros de 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

Crear las aplicaciones virtuales de terceros

En los siguientes pasos se muestra cómo crear una plantilla de instancia y un grupo de instancias regional gestionado con más de una interfaz de red. Este grupo de instancias se usa como dispositivo virtual de terceros en este ejemplo.

Consola

Debes usar gcloud en este paso porque tienes que crear una plantilla de instancia con más de una interfaz de red. Actualmente, la Google Cloud consola no admite la creación de plantillas de instancia con más de una interfaz de red.

gcloud

  1. Crea un archivo local llamado config.sh e 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 instancia para tus aplicaciones virtuales de terceros. La plantilla de instancia 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 de 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 gestionado para tus aplicaciones virtuales de terceros. Este comando crea un grupo de instancias regionales administrado, que se puede autoescalar en us-west1.

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

Crear los recursos de balanceo de carga

En estos pasos se configuran todos los componentes del balanceador de carga de red de pases interno, empezando por la comprobación de estado y el servicio de backend, y, a continuación, los componentes de frontend:

  • Comprobación del estado: en este ejemplo, la comprobación del estado de HTTP comprueba si hay una respuesta HTTP 200 (OK). Para obtener más información, consulta la sección de comprobaciones del estado del artículo sobre el balanceador de carga de red interno de pases.

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

  • Regla de reenvío: aunque esta regla de reenvío de ejemplo especifica el puerto TCP 80, cuando el balanceador de carga es el siguiente salto de una ruta, el tráfico de cualquier puerto TCP o UDP se envía a los back-ends del balanceador de carga.

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

Consola

Iniciar la configuración

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

    Ir a Balanceo de carga

  2. Haga clic en Crear balanceador de carga.
  3. En Tipo de balanceador de carga, selecciona Balanceador de carga de red (TCP/UDP/SSL) y haz clic en Siguiente.
  4. En Proxy o pasarela, selecciona Balanceador de carga de pasarela y haz clic en Siguiente.
  5. En Público o interno, selecciona Interno y haz clic en Siguiente.
  6. Haz clic en Configurar.

Crear el primer balanceador de carga

  1. Asigna el valor ilb1 a Nombre.
  2. Asigna el valor us-west1 a Región.
  3. Define Red como testing.
  4. Haz clic en Configuración de backend y haz los siguientes cambios:
    1. En Backends (Back-ends), en la sección New item (Nuevo elemento), selecciona el grupo de instancias third-party-instance-group y haz clic en Done (Hecho).
    2. En Comprobación del estado, elige Crear otra comprobación del estado, introduce 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 para crear tu balanceador de carga, la comprobación del estado es global. Google Cloud Si quieres crear una comprobación del estado regional, usa gcloud o la API.
    3. En Afinidad de sesión, selecciona IP de cliente.
    4. Comprueba que haya una marca de verificación azul junto a Configuración del backend antes de continuar. Si no es así, revisa este paso.
  5. Haz clic en Configuración de frontend. En la sección IP de frontend y puerto nuevos, haz los siguientes cambios:
    1. Nombre: fr-ilb1
    2. Subred: testing-subnet
    3. En IP interna, elige Reservar dirección IP estática interna, introduce la siguiente información y haz clic en Reservar:
      • Nombre: ip-ilb
      • Dirección IP estática: Quiero elegir
      • Dirección IP personalizada: 10.30.1.99
    4. Puertos: elige Único e introduce 80 en el campo Número de puerto. Recuerda que la elección de un protocolo y un puerto para el balanceador de carga no limita los protocolos y los puertos que se usan cuando el balanceador de carga es el siguiente salto de una ruta.
    5. Verifica que haya una marca de verificación azul junto a Configuración del frontend antes de continuar. Si no es así, revisa este paso.
  6. Haz clic en Revisar y finalizar. Comprueba tu configuración.
  7. Haz clic en Crear.

Iniciar la configuración

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

    Ir a Balanceo de carga

  2. Haga clic en Crear balanceador de carga.
  3. En Tipo de balanceador de carga, selecciona Balanceador de carga de red (TCP/UDP/SSL) y haz clic en Siguiente.
  4. En Proxy o pasarela, selecciona Balanceador de carga de pasarela y haz clic en Siguiente.
  5. En Público o interno, selecciona Interno y haz clic en Siguiente.
  6. Haz clic en Configurar.

Crear el segundo balanceador de carga

  1. Asigna el valor ilb2 a Nombre.
  2. Asigna el valor us-west1 a Región.
  3. Define Red como production.
  4. Haz clic en Configuración de backend y haz los siguientes cambios:
    1. En Backends (Back-ends), en la sección New item (Nuevo elemento), selecciona el grupo de instancias third-party-instance-group y haz clic en Done (Hecho).
    2. En Comprobación del estado, selecciona hc-http-80.
    3. En Afinidad de sesión, selecciona IP de cliente.
    4. Comprueba que haya una marca de verificación azul junto a Configuración del backend antes de continuar. Si no es así, revisa este paso.
  5. Haz clic en Configuración de frontend. En la sección IP de frontend y puerto nuevos, haz los siguientes cambios:
    1. Nombre: fr-ilb2
    2. Subred: production-subnet
    3. En IP interna, elige Reservar dirección IP estática interna, introduce la siguiente información y haz clic en Reservar:
      • Nombre: ip-ilb2
      • Dirección IP estática: Quiero elegir
      • Dirección IP personalizada: 10.50.1.99
    4. Puertos: elige Único e introduce 80 en el campo Número de puerto. Recuerda que la elección de un protocolo y un puerto para el balanceador de carga no limita los protocolos y los puertos que se usan cuando el balanceador de carga es el siguiente salto de una ruta.
    5. Verifica que haya una marca de verificación azul junto a Configuración del frontend antes de continuar. Si no es así, revisa este paso.
  6. Haz clic en Revisar y finalizar. Comprueba tu configuración.

  7. Haz clic en Crear.

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

gcloud

  1. Crea una comprobación del estado de HTTP para probar la conectividad TCP a las VMs en el puerto 80.

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

  2. Crea dos servicios 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. Añade los grupos de instancias que contengan 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 internas y conéctalas a los servicios de backend para completar la configuración del balanceador de carga. Recuerda que el protocolo (TCP) y el puerto (80) de los balanceadores de carga no limitan los puertos ni los protocolos que se reenvían a las instancias de backend (los dispositivos virtuales de terceros) cuando los balanceadores de carga se usan 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

Crear las rutas estáticas que definen los balanceadores de carga como los siguientes saltos

Crea dos rutas estáticas que usen un balanceador de carga de siguiente salto.

Consola

Crear la primera ruta

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

    Ir a Rutas

  2. Haz clic en Crear ruta.

  3. En Nombre de la ruta, introduce ilb-nhop-dest-10-50-1.

  4. Selecciona la red testing.

  5. En Intervalo de IP de destino, introduce 10.50.1.0/24.

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

  7. En Siguiente salto de la ruta, selecciona Especificar una regla de reenvío para el balanceador de carga TCP/UDP interno.

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

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

  9. Haz clic en Crear.

Crear la segunda ruta

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

  5. En Siguiente salto de la ruta, selecciona Especificar una regla de reenvío para el balanceador de carga TCP/UDP interno.

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

  6. En Nombre de la regla de reenvío, selecciona fr-ilb2.

  7. Haz clic en Crear.

gcloud

Crea rutas estáticas con el siguiente salto definido en la regla de reenvío de cada balanceador de carga y cada intervalo de destino configurado en consecuencia.

En el caso de la marca --next-hop-ilb, puede especificar el nombre o la dirección IP de una regla de reenvío. La dirección IP de una regla de reenvío de siguiente salto puede estar en la misma red de VPC que contiene la ruta o en una red de VPC emparejada. Para obtener más información, consulta Proyecto y red del 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 la regla de reenvío fr-ilb12.

Si quieres, puedes especificar una o varias etiquetas de instancia en la ruta. La ruta se puede aplicar a VMs específicas si se especifican etiquetas de red en la ruta. Si no especifica ninguna etiqueta de red, la ruta se aplica a todas las máquinas virtuales 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

Crear la instancia de VM testing

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

gcloud

  1. Crea el testing-vm ejecutando el 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'

Crear la instancia de VM production

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

gcloud

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

  1. Crea el production-vm ejecutando el 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'

Probar el balanceo de carga en una implementación con varias NICs

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

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

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

    curl http://10.50.1.99

    exit

  3. Prueba la conectividad desde la VM production.

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

    curl http://10.30.1.99

    exit

Habilitar el cifrado simétrico

Al calcular el hash asignado 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 independientemente de la dirección de la que proceda el paquete. Esto se denomina hash simétrico.

Para habilitar este comportamiento de hashing 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.

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

Eliminar y volver a crear las reglas de reenvío

Consola

Eliminar una regla de reenvío y crear otra

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

    Ir a Balanceo de carga

  2. Haz clic en tu balanceador de carga be-ilb y, a continuación, en Editar.

  3. Haz clic en Configuración de frontend.

  4. Coloca el puntero sobre la regla de reenvío y haz clic en Eliminar para quitarla.

  5. Haz clic en Añadir IP y puerto de frontend.

  6. En la sección IP de frontend y puerto nuevos, haz 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 del frontend antes de continuar. Si no es así, revisa este paso.

  7. Haz clic en Revisar y finalizar. Comprueba tu configuración.

  8. Haz clic en Crear.

gcloud

  1. Elimina las reglas de reenvío que tengas.

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

  2. Crea reglas de reenvío de sustitución 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 requiere SNAT

Como se ha demostrado en el ejemplo anterior, no es necesario usar la traducción de direcciones de red de origen (SNAT) si se cumplen todas las condiciones siguientes:

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

Para convertir una ruta de un balanceador de carga de red de paso a través interno de siguiente salto en una ruta que use el hashing simétrico, sigue estos pasos:

  • Asegúrate de que el servicio de backend del balanceador de carga de red de paso a través interno no use el NONEajuste de afinidad de sesión

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

  • Crea una ruta estática de sustitución que haga referencia a la nueva regla de reenvío. Asegúrate de que esta ruta de sustitución tenga una prioridad mayor que la ruta actual.

  • Elimina la ruta de menor prioridad (que hace referencia a la regla de reenvío anterior) y, a continuación, elimina la regla de reenvío anterior.

Limpieza

  1. En la configuración del balanceador de carga, 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. Elimina las rutas.

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

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

  3. En las configuraciones del balanceador de carga, elimina 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 las configuraciones del balanceador de carga, elimina los servicios de backend.

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

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

  5. En las configuraciones del balanceador de carga, elimina la comprobación del estado.

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

    Si has usado la consola Google Cloud , la comprobación del estado es global. Por lo tanto, el comando es el siguiente:

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

  6. Elimina el grupo de instancias gestionado.

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

  7. Elimina las plantillas de instancia.

    gcloud compute instance-templates delete third-party-template

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

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

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

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

Siguientes pasos