Configura el balanceo de cargas TCP/UDP interno para dispositivos de terceros

En esta guía, se usa un ejemplo a fin de enseñarte a configurar un balanceador de cargas TCP/UDP interno de Google Cloud para que sea el siguiente salto. Antes de seguir esta guía, familiarízate con los siguientes conceptos:

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
Crear instancias Administrador de instancias de Compute

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

Balanceo de cargas a un solo NIC de backend

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 integra dispositivos virtuales para que no tengas que volver a configurar de forma explícita tus clientes a fin de enviar tráfico a cada dispositivo virtual. En el ejemplo de esta guía de configuración, se envía todo el tráfico a través de un conjunto de dispositivos virtuales de firewall con balanceo de cargas.

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 las VM de backend
  • Una ruta estática personalizada
  • Una VM cliente para probar conexiones
  • Los siguientes componentes del balanceador de cargas TCP/UDP interno son:
    • VM de backend en un grupo de instancias administrado
    • Una verificación de estado de los dispositivos de VM de backend
    • 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

La topología se ve así:

Ejemplo de un solo NIC del siguiente salto para balanceo de cargas TCP/UDP interno (haz clic para agrandar)
Ejemplo de un solo NIC del siguiente salto para balanceo de cargas 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, VM que ejecutan el software del dispositivo de firewall) detrás de un balanceador de cargas 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 una de las direcciones IP de 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).
  • La instancia de aplicación realiza la traducción de direcciones de red de origen (SNAT) para entregar paquetes al grupo de instancias en la red de VPC de production. En el caso del tráfico de retorno, se realiza la traducción de la dirección de red de destino (DNAT) para entregar paquetes a la instancia cliente en la red de VPC de testing.

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. Ve a la página Redes de VPC en Google Cloud Console.
    Ir a la página Redes de VPC
  2. Haz clic en Crear red de VPC
  3. En Nombre ingresa testing.
  4. En la sección Subredes, haz lo siguiente:
    • 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. Ve a la página Redes de VPC en Google Cloud Console.
    Ir a la página Redes de VPC
  2. Haz clic en Crear red de VPC
  3. En Nombre ingresa production.
  4. En la sección Subredes, haz lo siguiente:
    • 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. Cree 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-subnet: Una regla de entrada, aplicable a todos los destinos en la red testing, que permite el tráfico de fuentes en los rangos 10.30.1.0/24. Esta regla permite que las instancias y los dispositivos de VM de terceros en la testing-subnet se comuniquen.

  • fw-allow-production-subnet: Una regla de entrada, aplicable a todos los destinos en la red production, que permite el tráfico de fuentes en los rangos 10.50.1.0/24. Esta regla permite que las instancias y los dispositivos de VM de terceros en la production-subnet se comuniquen.

  • fw-allow-testing-ssh: Una regla de entrada aplicada a las instancias de VM en la red de VPC de testing, que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un rango de IP fuente 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 en la red de VPC de production, que 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, aplicable a los dispositivos de VM de terceros con balanceo de cargas, que permite el tráfico 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. Ve a la página Firewall en Google Cloud Console.
    Ir a la página Firewall
  2. Haz clic en Crear regla de firewall e ingresa la siguiente información para crear la regla que permitirá el tráfico de subred:
    • Nombre: fw-allow-testing-subnet
    • 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
    • Protocolos y puertos: permitir todos
  3. Haga clic en Crear.
  4. Haz clic en Crear regla de firewall y, luego, ingresa la siguiente información para crear la regla a fin de permitir el tráfico de subred:
    • Nombre: fw-allow-production-subnet
    • 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.50.1.0/24
    • Protocolos y puertos: permitir todos
  5. Haz clic en Crear.
  6. Vuelve a hacer clic en Crear regla de firewall para crear la regla que permitirá conexiones SSH entrantes:
    • 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: IP ranges
    • Rangos de IP de origen: 0.0.0.0/0
    • Protocolos y puertos: Elige Protocolos y puertos especificados y escribe: tcp:22
  7. Haga clic en Crear.
  8. Vuelve a hacer clic en Crear regla de firewall para crear la regla que permitirá conexiones SSH entrantes:
    • 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: IP ranges
    • Rangos de IP de origen: 0.0.0.0/0
    • Protocolos y puertos: Elige Protocolos y puertos especificados y escribe: tcp:22
  9. Haga clic en Crear.
  10. Haz clic en Crear regla de firewall por tercera vez para crear la regla que permitirá las verificaciones de estado de Google Cloud:
    • 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: IP ranges
    • Rangos de IP de origen: 130.211.0.0/22 y 35.191.0.0/16
    • Protocolos y puertos: permitir todos
  11. Haz clic en Crear.

gcloud

  1. Crea la regla de firewall fw-allow-testing-subnet para permitir la comunicación desde la subred:

    gcloud compute firewall-rules create fw-allow-testing-subnet \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.30.1.0/24 \
        --rules=tcp,udp,icmp
    
  2. Crea la regla de firewall fw-allow-production-subnet para permitir la comunicación desde la subred:

    gcloud compute firewall-rules create fw-allow-production-subnet \
        --network=production \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.50.1.0/24 \
        --rules=tcp,udp,icmp
    
  3. Crea la regla de firewall fw-allow-testing-ssh para permitir la conectividad SSH a las VM que tengan 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 que tengan 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,udp,icmp
    

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 tus 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 \
        --region=us-west1 \
        --network-interface subnet=testing-subnet,address="" \
        --network-interface subnet=production-subnet \
        --tags=allow-ssh,allow-health-check \
        --image-family=debian-9 \
        --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 -H "Metadata-Flavor:Google" $md_net/0/gateway)"
        nic0_mask="$(curl -H "Metadata-Flavor:Google" $md_net/0/subnetmask)"
        nic1_gw="$(curl -H "Metadata-Flavor:Google" $md_net/1/gateway)"
        nic1_mask="$(curl -H "Metadata-Flavor:Google" $md_net/1/subnetmask)"
        nic1_addr="$(curl -H "Metadata-Flavor:Google" $md_net/1/ip)"
        # Start iptables:
        /sbin/iptables -t nat -F
        /sbin/iptables -t nat -A POSTROUTING \
        -s "$nic0_gw/$nic0_mask" \
        -d "$nic1_gw/$nic1_mask" \
        -o eth1 \
        -j SNAT \
        --to-source "$nic1_addr"
        /sbin/iptables-save
        # 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 \
        --size=3
    

Crea los recursos de balanceo de cargas

Con estos pasos se configuran todos los componentes del balanceador de cargas de TCP/UDP interno; se comienza con la verificación de estado y el servicio de backend y, luego, se configuran 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 TCP/UDP interno.

  • Servicio de backend: Aunque en este ejemplo el servicio de backend especifica el protocolo TCP, cuando el balanceador de cargas es el siguiente salto para una ruta, el tráfico de TCP y UDP se envía a los backends del balanceador de cargas.

  • 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 balanceador de cargas y configura un servicio de backend

  1. Ve a la página Balanceo de cargas en Google Cloud Console.
    Ir a la página Balanceo de cargas
  2. Haz 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. Configura el campo Nombre como ilb1.
  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 Elemento nuevo, selecciona el grupo de instancias third-party-instance-group y haz clic en Listo.
    4. En Verificación de estado, elige Crear otra verificació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 tu 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. 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 Individual y, luego, ingresa 80 para 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 utilizan 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.

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 un servicio de backend interno en la región us-west1.

    gcloud compute backend-services create ilb1 \
        --health-checks-region=us-west1 \
        --load-balancing-scheme=internal \
        --region=us-west1 \
        --health-checks=hc-http-80
    
  3. Agrega el grupo de instancias que contiene los dispositivos virtuales de terceros como un backend en el servicio de backend.

    gcloud compute backend-services add-backend ilb1 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
  4. Crea la regla de reenvío interno y conéctala al servicio de backend para completar la configuración del balanceador de cargas. Recuerda que el protocolo (TCP) y el puerto (80) del balanceador de cargas interno no limitan los puertos ni los protocolos que se envían a las instancias de backend (los dispositivos virtuales de terceros) cuando el balanceador de cargas se usa como el siguiente salto de una ruta.

    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
    

Crea la ruta estática que define el balanceador de cargas como el siguiente salto

Cuando creas una ruta estática, no puedes usar next-hop-address para apuntar a la dirección IP de la regla de reenvío del balanceador de cargas. Esto se debe a que cuando usas next-hop-address, Google Cloud pasa tráfico a la instancia de VM asignada a esa dirección IP, y un balanceador de cargas no es una instancia de VM. En cambio, si deseas designar un balanceador de cargas como siguiente salto, debes usar la marca next-hop-ilb, como se demuestra en este ejemplo.

Console

  1. Ve a la página Rutas en Google Cloud Console.
    Ir a la página Rutas
  2. Haz clic en Crear ruta.
  3. En la ruta Nombre, 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. Asegúrate de que las etiquetas no estén especificadas, ya que no son compatibles con esta función.
  7. Para el Siguiente salto de la ruta, selecciona Especificar un balanceador de cargas TCP/UDP interno de la regla de reenvío.
  8. En la región del siguiente salto, selecciona us-west1.
  9. Para el nombre de la regla de reenvío, selecciona fr-ilb1.
  10. Haz clic en Crear.

gcloud

Crea una ruta avanzada con el siguiente salto establecido en la regla de reenvío del balanceador de cargas y el rango de destino establecido en la ruta 10.50.1.0/24.

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=fr-ilb1 \
    --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-9 \
        --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-9 \
        --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 la implementación de un solo NIC

Esta prueba se comunica con la VM de destino de ejemplo en la red de VPC de production de la VM de cliente en la red de VPC de testing. El balanceador de cargas se usa como el siguiente salto porque enruta el paquete con el destino 10.50.1.100 a través del balanceador de cargas, en lugar de enviarlo a la dirección IP del balanceador.

En este ejemplo, el software iptables en las VM del dispositivo de backend en buen estado del balanceador de cargas procesa NAT para el paquete.

  1. Conéctate a la instancia de VM de cliente.

    gcloud compute ssh testing-vm --zone=us-west1-a
    
  2. Realiza una solicitud web al software del servidor web de la instancia de destino mediante curl. El resultado esperado es el contenido de la página de índice en la instancia de destino (Page served from: destination-instance).

    curl http://10.50.1.100
    

Configura los balanceadores de cargas TCP/UDP internos como siguientes saltos con backends comunes

Puedes expandir el ejemplo por balanceo de cargas a varios NIC de backend, como se describe en Balanceo de cargas a varios NIC.

Ejemplo detallado de varios NIC del siguiente salto para el balanceo de cargas TCP/UDP interno (haz clic para agrandar)
Ejemplo detallado de varios NIC del siguiente salto para el balanceo de cargas TCP/UDP interno (haz clic para agrandar)
  1. 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,udp,icmp
    
  2. Crea la nueva plantilla de instancia.

    Para que esta configuración funcione sin problemas con las verificaciones de estado, debes configurar el enrutamiento basado en políticas a fin de garantizar que los paquetes de respuesta de verificación de estado de salida salgan por la interfaz correcta. Las verificaciones de estado usan direcciones IP externas como fuentes para los sondeos de verificación de estado. Los sistemas operativos invitados eligen la NIC saliente en función de la dirección IP de destino. Si la dirección IP de destino no se encuentra dentro del rango de la subred, la NIC saliente se establece de manera predeterminada en nic0. En esos casos, debes configurar una tabla de enrutamiento independiente para cada interfaz de red mediante el enrutamiento basado en políticas.

    Ten en cuenta que el enrutamiento de políticas basadas en el origen no funciona en los sistemas operativos Windows o Mac.

    En la plantilla de VM de backend, agrega el siguiente enrutamiento de políticas, en el que 10.50.1.0/24 es la subred con el balanceador de cargas y eth1 de la VM con varios NIC. La puerta de enlace predeterminada es 10.50.1.1:

    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-9 \
        --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")"
        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")"
        # 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 eth1 table rt-nic1
        ip route add 130.211.0.0/22 via $nic1_gw dev eth1 table rt-nic1
        # Start iptables:
        iptables -t nat -F
        iptables -t nat -A POSTROUTING \
        -s $nic0_gw/$nic0_mask \
        -d $nic1_gw/$nic1_mask \
        -o eth1 \
        -j SNAT \
        --to-source $nic1_addr
        iptables -t nat -A POSTROUTING \
        -s $nic1_gw/$nic1_mask \
        -d $nic0_gw/$nic0_mask \
        -o eth0 \
        -j SNAT \
        --to-source $nic0_addr
        iptables-save
        # 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'
    
  3. Actualiza el grupo de instancias.

    gcloud compute instance-groups managed set-instance-template \
        third-party-instance-group \
        --region us-west1 \
        --template=third-party-template-multinic
    
  4. Vuelve a crear el grupo de instancias administrado con la nueva plantilla third-party-template-multinic.

    gcloud compute instance-groups managed rolling-action replace \
        third-party-instance-group \
        --region us-west1
    

    Espera unos minutos para que las instancias estén listas. Puedes verificar el progreso con el comando list-instances.

    gcloud compute instance-groups managed list-instances \
        third-party-instance-group \
        --region us-west1
    

    El resultado debería verse así:

    NAME                             ZONE        STATUS   ACTION  INSTANCE_TEMPLATE              VERSION_NAME                        LAST_ERROR
    third-party-instance-group-5768  us-west1-a  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    third-party-instance-group-4zf4  us-west1-b  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    third-party-instance-group-f6lm  us-west1-c  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    
  5. Configura los recursos del balanceador de cargas en la red de VPC de production.

    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
    
    gcloud compute backend-services add-backend ilb2 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
    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
    
    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
    

Prueba el balanceo de cargas en una implementación de varios 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
    

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
    

Próximos pasos