Configura el balanceo de cargas TCP/UDP 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 personalizada y establece su siguiente salto al balanceador de cargas TCP/UDP 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 TCP/UDP 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
Agregar y quitar 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 los balanceadores de cargas TCP/UDP internos como siguientes saltos con backends comunes

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

La solución que se analiza en esta guía crea VM de dispositivo que ejecutan Debian Linux y iptables. Las VM de ejemplo no realizan ningún filtrado de paquetes, pero puedes agregar esa funcionalidad si modificas la configuración de iptables 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 personalizadas
  • Dos VM cliente para probar las conexiones
  • Los siguientes componentes del balanceador de cargas de TCP/UDP interno:
    • VM 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 así:

Ejemplo detallado de varios NIC del siguiente salto para el balanceo de cargas TCP/UDP interno
Ejemplo detallado de varias NIC del siguiente salto para el balanceo de cargas de TCP/UDP interno (haz clic para agrandar)

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

  • Instancias de aplicación (en este caso, las VM que ejecutan el software de iptables) detrás de un balanceador de cargas de TCP/UDP 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 personalizada con destino 10.50.1.0/24 y el siguiente 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 personalizada 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/2410.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 Cloud Console, ve a la página Redes de VPC.

    Ir a 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 Cloud Console, ve a la página Redes de VPC.

    Ir a 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 personalizadas:

    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 Google Cloud Console, ve a la página Firewall.

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

    • Name: 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: IP ranges
    • Rangos de IP 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:

    • Name: 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: IP ranges
    • Rangos de IP 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:

    • Name: 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: IP ranges
    • Rangos de IP de origen0.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:

    • Name: 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: IP ranges
    • Rangos de IP de origen0.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:

    • Name: 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: IP ranges
    • Rangos de IP 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:

    • Name: 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: IP ranges
    • Rangos de IP 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 mediante el software iptables como un dispositivo virtual de terceros.

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, Cloud Console no admite la creación de plantillas de instancias con más de una interfaz de red.

gcloud

  1. 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 \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --can-ip-forward \
        --metadata=startup-script='#! /bin/bash
        # Enable IP forwarding:
        echo 1 > /proc/sys/net/ipv4/ip_forward
        echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
        # Read VM network configuration:
        md_vm="http://169.254.169.254/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
        ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
        sleep 1
        ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
        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.
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        echo "Example web page to pass health check" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
    
  2. 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 TCP/UDP 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 balanceo de cargas de TCP/UDP 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 y 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

Crea el primer balanceador de cargas

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

    Ir al balanceo de cargas

  2. Haga clic en Crear balanceador de cargas.

  3. En Balanceo de cargas TCP, haz clic en Iniciar configuración.

  4. En Orientado a Internet o solo interno, selecciona Solo entre mis VM.

  5. Haz clic en Continuar.

  6. Ingresa ilb1 en Nombre.

  7. Haz clic en Configuración de backend y realiza los siguientes cambios:

    1. Región: us-west1
    2. Red: testing
    3. En Backends, en la sección Nuevo elemento, selecciona el grupo de instancias third-party-instance-group y haz clic en Listo.
    4. 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 Cloud Console 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.
    5. En Afinidad de sesión, selecciona IP de cliente.
    6. Verifica que haya una marca de verificación azul junto a Configuración de backend antes de continuar. Si no, revisa este paso.
  8. 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 y luego 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.
  9. Haz clic en Revisar y finalizar. Vuelve a verificar la configuración.

  10. Haz clic en Crear.

Crea el segundo balanceador de cargas

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

    Ir al balanceo de cargas

  2. Haga clic en Crear balanceador de cargas.

  3. En Balanceo de cargas TCP, haz clic en Iniciar configuración.

  4. En Orientado a Internet o solo interno, selecciona Solo entre mis VM.

  5. Haga clic en Continuar.

  6. Ingresa ilb2 en Nombre.

  7. Haz clic en Configuración de backend y realiza los siguientes cambios:

    1. Región: us-west1
    2. Red: production
    3. En Backends, en la sección Nuevo elemento, selecciona el grupo de instancias third-party-instance-group y haz clic en Listo.
    4. En Verificación de estado, selecciona hc-http-80.
    5. En Afinidad de sesión, selecciona IP de cliente.
    6. Verifica que haya una marca de verificación azul junto a Configuración de backend antes de continuar. Si no, revisa este paso.
  8. 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: 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:
      • Name: ip-ilb2
      • Dirección IP estática: permíteme elegir
      • Dirección IP personalizada: 10.50.1.99
    4. Puertos: Elige Único y luego 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.
  9. Haz clic en Revisar y finalizar. Vuelve a verificar la configuración.

  10. Haz clic en Crear.

  11. 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 personalizadas a las que se muestre next-hop-ilb.

Console

Crea la primera ruta

  1. En Google Cloud Console, ve a la página Supervisión.

    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. Especifica una o más etiquetas de red (opcional). La ruta puede aplicarse 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.

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

    Para especificar la dirección IP del balanceador de cargas como siguiente salto, usa la herramienta 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. Haga 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 internos TCP/UDP.

    Para especificar la dirección IP del balanceador de cargas como siguiente salto, usa la herramienta 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 avanzadas con el siguiente 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 el nombre de la regla de reenvío o la dirección IP. Si especificas la dirección IP, esta se puede aprender entre pares sin tener que exportar la ruta personalizada. 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.

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-10 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=testing-subnet \
        --private-network-ip 10.30.1.100 \
        --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        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-10 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=production-subnet \
        --private-network-ip 10.50.1.100 \
        --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        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.100
    
    exit
    
  3. Prueba la conectividad desde la VM de production.

    gcloud compute ssh production-vm --zone=us-west1-a
    
    curl http://10.30.1.100
    

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 TCP/UDP 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 Google Cloud Console, 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 TCP/UDP interno se creó el 22 de junio de 2021 o después de esa fecha.
  • La ruta estática personalizada 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 TCP/UDP interno no usa el parámetro de configuración de afinidad de sesión NONE.

Puedes convertir una ruta del balanceador de cargas TCP/UDP 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 TCP/UDP interno no use el parámetro de 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 personalizada 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 Cloud Console, 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?