Configura el balanceo de cargas de TCP/UDP interno

En esta guía se usa un ejemplo para enseñar los aspectos principales del balanceo de cargas de TCP/UDP interno de Google Cloud. Antes de seguir esta guía, familiarízate con la siguiente documentación:

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 funciones de IAM de Compute Engine que se detallan a continuación:

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:

Configuración

En esta guía, se muestra cómo configurar y probar un balanceador de cargas TCP/UDP interno. En esta sección, se explica cómo configurar los siguientes puntos:

  1. Una red de VPC de muestra con subredes personalizadas
  2. Reglas de firewall que permiten conexiones entrantes a VM de backend
  3. Cuatro VM de backend:
    • Dos VM en un grupo de instancias no administrado en la zona us-west1-a
    • Dos VM en un grupo de instancias no administrado en la zona us-west1-c
  4. Una VM de cliente para probar conexiones
  5. Los siguientes componentes del balanceador de cargas de TCP/UDP interno:
    • Una verificación de estado del servicio de backend
    • Un servicio de backend interno en la región us-west1 para administrar la distribución de conexiones en los dos grupos de instancias zonales
    • Una regla de reenvío interno y una dirección IP interna para el frontend del balanceador de cargas

Así se ve la arquitectura de este ejemplo:

Configuración de ejemplo de balanceo de cargas TCP/UDP interno (haz clic para ampliarlo)
Configuración de ejemplo del balanceo de cargas de TCP/UDP interno (haz clic para ampliar)

Configura una red, una región y una subred

El ejemplo del balanceador de cargas de TCP/UDP interno descrito en esta página se crea en una red de VPC de modo personalizado llamada lb-network.

Las VM de backend de este ejemplo y los componentes del balanceador de cargas se encuentran en la región y la subred que se incluyen a continuación:

  • Región: us-west1
  • Subred: lb-subnet, con el rango de direcciones IP principales 10.1.2.0/24

Para demostrar el acceso global, en este ejemplo, se crea una segunda VM de cliente de prueba en una región y una subred diferentes:

  • Región: europe-west1
  • Subred: europe-subnet, con el rango de direcciones IP principales 10.3.4.0/24

Para crear la red y la subred de ejemplo, sigue estos pasos:

Console

  1. En Cloud Console, ve a la página Redes de VPC.
    Ir a las redes de VPC
  2. Haga clic en Crear red de VPC.
  3. En Nombre ingresa lb-network.
  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: lb-subnet
      • Región:: us-west1
      • Rangos de direcciones IP: 10.1.2.0/24
      • Haz clic en Listo.
    • Haz clic en Agregar subred e ingresa la siguiente información:
      • Nombre: europe-subnet
      • Región:: europe-west1
      • Rangos de direcciones IP: 10.3.4.0/24
      • Haz clic en Listo.
  5. Haz clic en Crear.

gcloud

  1. Crea la red de VPC personalizada:

    gcloud compute networks create lb-network --subnet-mode=custom
    1. Dentro de la red lb-network, crea una subred para backends en la región us-west1 y otra subred a fin de probar el acceso global en la región europe-west1:
    gcloud compute networks subnets create lb-subnet \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-west1

    gcloud compute networks subnets create europe-subnet \
    --network=lb-network \
    --range=10.3.4.0/24 \
    --region=europe-west1

api

Realiza una solicitud POST al método networks.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

Realiza dos solicitudes POST al método subnetworks.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "lb-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "ipCidrRange": "10.1.2.0/24",
  "privateIpGoogleAccess": false
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/europe-west1/subnetworks

{
  "name": "europe-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
   "ipCidrRange": "10.3.4.0/24",
   "privateIpGoogleAccess": false
}

Configura las reglas de firewall

En este ejemplo se usan las siguientes reglas de firewall:

  • fw-allow-lb-access: es una regla de entrada aplicable a todos los destinos en la red de VPC, de modo que se admite el tráfico de las fuentes en los rangos 10.1.2.0/24 y 10.3.4.0/24. Con esta regla se permite el tráfico entrante desde cualquier cliente ubicado en cualquiera de las dos subredes. Más adelante te permitirá configurar y probar el acceso global.

  • fw-allow-ssh: es una regla de entrada aplicable a las instancias con balanceo de cargas y que 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 solo los rangos de IP del sistema desde el cual iniciarás sesiones SSH. En este ejemplo se usa la etiqueta de destino allow-ssh para identificar las VM a las que se debe aplicar.

  • fw-allow-health-check: es una regla de entrada aplicable a las instancias 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.

Console

  1. En Google Cloud Console, ve a la página Firewall.
    Ir al 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-lb-access
    • Red: lb-network
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: todas las instancias de la red
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 10.1.2.0/24 y 10.3.4.0/24
    • Protocolos y puertos: permitir todos
  3. Haz clic en Crear.
  4. Vuelve a hacer clic en Crear regla de firewall para crear la regla que permitirá conexiones SSH entrantes:
    • Nombre: fw-allow-ssh
    • Red: lb-network
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-ssh
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 0.0.0.0/0
    • Protocolos y puertos: elige Protocolos y puertos especificados y escribe tcp:22
  5. Haz clic en Crear.
  6. 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: lb-network
    • Prioridad: 1000
    • Dirección del tráfico: entrada
    • Acción si hay coincidencia: permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de destino: allow-health-check
    • Filtro de fuente: Rangos de IPv4
    • Rangos de IPv4 de origen: 130.211.0.0/22 y 35.191.0.0/16
    • Protocolos y puertos: permitir todos
  7. Haz clic en Crear.

gcloud

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

    gcloud compute firewall-rules create fw-allow-lb-access \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.1.2.0/24,10.3.4.0/24 \
    --rules=tcp,udp,icmp

  2. Crea la regla de firewall fw-allow-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-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  3. Crea la regla fw-allow-health-check para permitir las verificaciones de estado de Google Cloud.

    gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-network \
    --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

api

Crea la regla de firewall fw-allow-lb-access mediante una solicitud POST al método firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-lb-access",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "priority": 1000,
  "sourceRanges": [
    "10.1.2.0/24", "10.3.4.0/24"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    },
    {
      "IPProtocol": "udp"
    },
    {
      "IPProtocol": "icmp"
    }
  ],
  "direction": "INGRESS",
  "logConfig": {
    "enable": false
  },
  "disabled": false
}

Crea la regla de firewall fw-allow-ssh mediante una solicitud POST al método firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
       "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "priority": 1000,
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS",
 "logConfig": {
   "enable": false
 },
 "disabled": false
}

Crea la regla de firewall fw-allow-health-check mediante una solicitud POST al método firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "priority": 1000,
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "allow-health-check"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    },
    {
      "IPProtocol": "udp"
    },
    {
      "IPProtocol": "icmp"
    }
  ],
  "direction": "INGRESS",
  "logConfig": {
    "enable": false
  },
  "disabled": false
}

Crea grupos de instancias y VM de backend

En este ejemplo se usan dos grupos de instancias no administrados, cada uno con dos VM de backend (servidor). Para demostrar la naturaleza regional del balanceo de cargas TCP/UDP interno, los dos grupos de instancias se colocan en zonas diferentes: us-west1-a y us-west1-c.

  • El grupo de instancias ig-a contiene estas dos VM:
    • vm-a1
    • vm-a2
  • El grupo de instancias ig-c contiene estas dos VM:
    • vm-c1
    • vm-c2

El tráfico a las cuatro VM de backend cuenta con balanceo de cargas.

Para admitir este ejemplo y las opciones de configuración adicionales, cada una de las cuatro VM ejecuta un Apache Web Server que escucha en los siguientes puertos TCP: 80, 8008, 8080, 8088, 443 y 8443.

A cada VM se le asigna una dirección IP interna en la lb-subnet y una dirección IP externa (pública) y efímera. Puedes quitar las direcciones IP externas más adelante.

No se requiere direcciones IP externas para las VM de backend; sin embargo, son útiles en este ejemplo porque permiten que las VM de backend descarguen Apache de Internet y facilitan la conexión a través de SSH.

De forma predeterminada, Apache está configurado para vincularse a cualquier dirección IP. Los balanceadores de cargas TCP/UDP internos entregan paquetes mediante la preservación de la IP de destino. Asegúrate de que el software del servidor que se ejecuta en las VM de backend escuche la dirección IP de la regla de reenvío interno del balanceador de cargas. Si configuras múltiples reglas de reenvío interno, asegúrate de que el software escuche la dirección IP interna asociada con cada una. La dirección IP de destino de un paquete que un balanceador de cargas de TCP/UDP interno entrega a una VM de backend es la dirección IP interna de la regla de reenvío.

Para simplificar el instructivo, estas VM de backend ejecutan Debian GNU/Linux 10.

Console

Crea VM de backend

  1. En Google Cloud Console, ve a la página Instancias de VM.
    Ir a Instancias de VM
  2. Repite los siguientes pasos para crear cuatro VM con las siguientes combinaciones de nombre y zona:
    • Nombre: vm-a1, zona: us-west1-a
    • Nombre: vm-a2, zona: us-west1-a
    • Nombre: vm-c1, zona: us-west1-c
    • Nombre: vm-c2, zona: us-west1-c
  3. Haz clic en Crear instancia.
  4. En Nombre establece lo que se indica en el paso 2.
  5. En Región elige us-west1 y selecciona una opción de Zona, como se indica en el paso 2.
  6. En la sección Disco de arranque, asegúrate de que el sistema operativo Debian y la versión 10 (buster) estén seleccionados como opciones de disco de arranque. Haz clic en Elegir para cambiar la imagen si es necesario.

  7. Haz clic en Administración, seguridad, discos, herramientas de redes, usuario único y realiza los siguientes cambios:

    • Haz clic en Herramientas de redes y agrega las siguientes Etiquetas de red: allow-ssh y allow-health-check.
    • Haz clic en Editar  en Interfaces de red y realiza los siguientes cambios. Luego, haz clic en Listo:
      • Red: lb-network
      • Subred: lb-subnet
      • IP interna principal: efímera (automática)
      • IP externa: efímera

    • Haz clic en Administración. En el campo Secuencia de comandos de inicio, copia y pega el siguiente contenido de la secuencia de comandos. El contenido de secuencia de comandos es idéntico para las cuatro VM:

      #! /bin/bash
if [ -f /etc/startup_script_completed ]; then
exit 0
fi
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
file_ports="/etc/apache2/ports.conf"
file_http_site="/etc/apache2/sites-available/000-default.conf"
file_https_site="/etc/apache2/sites-available/default-ssl.conf"
http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088"
http_vh_prts="*:80 *:8008 *:8080 *:8088"
https_listen_prts="Listen 443\nListen 8443"
https_vh_prts="*:443 *:8443"
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
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
prt_conf="$(cat "$file_ports")"
prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")"
prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")"
echo "$prt_conf" | tee "$file_ports"
http_site_conf="$(cat "$file_http_site")"
http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")"
echo "$http_site_conf_2" | tee "$file_http_site"
https_site_conf="$(cat "$file_https_site")"
https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")"
echo "$https_site_conf_2" | tee "$file_https_site"
systemctl restart apache2
touch /etc/startup_script_completed

  8. Haz clic en Crear.

Crea grupos de instancias

  1. En Google Cloud Console, ve a la página Grupos de instancias.
    Ir a grupos de instancias
  2. Repite estos pasos para crear dos grupos de instancias no administrados, cada uno con dos VM, mediante estas combinaciones.
    • Grupo de instancias: ig-a, zona: us-west1-a, VM: vm-a1 y vm-a2
    • Grupo de instancias: ig-c, zona: us-west1-c, VM: vm-c1 y vm-c2
  3. Haz clic en Crear grupo de instancias.
  4. Haz clic en Crea un nuevo grupo de instancias no administrado.
  5. Configura Nombre como se indica en el paso 2.
  6. En la sección Ubicación, elige us-west1 para Región y, luego, elige una opción en Zona, como se indica en el paso 2.
  7. En Red, ingresa lb-network.
  8. En Subred, ingresa lb-subnet.
  9. En la sección Instancias de VM, agrega las VM como se indica en el paso 2.
  10. Haz clic en Crear.

gcloud

  1. A fin de crear cuatro VM, ejecuta el siguiente comando cuatro veces, con estas cuatro combinaciones para [VM-NAME] y [ZONE]. El contenido de la secuencia de comandos es idéntico para las cuatro VM.

    • [VM-NAME] de vm-a1 y [ZONE] de us-west1-a
    • [VM-NAME] de vm-a2 y [ZONE] de us-west1-a
    • [VM-NAME] de vm-c1 y [ZONE] de us-west1-c
    • [VM-NAME] de vm-c2 y [ZONE] de us-west1-c
    gcloud compute instances create [VM-NAME] \
    --zone=[ZONE] \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh,allow-health-check \
    --subnet=lb-subnet \
    --metadata=startup-script='#! /bin/bash
if [ -f /etc/startup_script_completed ]; then
exit 0
fi
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
file_ports="/etc/apache2/ports.conf"
file_http_site="/etc/apache2/sites-available/000-default.conf"
file_https_site="/etc/apache2/sites-available/default-ssl.conf"
http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088"
http_vh_prts="*:80 *:8008 *:8080 *:8088"
https_listen_prts="Listen 443\nListen 8443"
https_vh_prts="*:443 *:8443"
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
prt_conf="$(cat "$file_ports")"
prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")"
prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")"
echo "$prt_conf" | tee "$file_ports"
http_site_conf="$(cat "$file_http_site")"
http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")"
echo "$http_site_conf_2" | tee "$file_http_site"
https_site_conf="$(cat "$file_https_site")"
https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")"
echo "$https_site_conf_2" | tee "$file_https_site"
systemctl restart apache2
touch /etc/startup_script_completed'

  2. Crea los dos grupos de instancias no administrados en cada zona:

    gcloud compute instance-groups unmanaged create ig-a \
    --zone=us-west1-a
gcloud compute instance-groups unmanaged create ig-c \
    --zone=us-west1-c

  3. Agrega las VM a los grupos de instancias adecuados:

    gcloud compute instance-groups unmanaged add-instances ig-a \
    --zone=us-west1-a \
    --instances=vm-a1,vm-a2
gcloud compute instance-groups unmanaged add-instances ig-c \
    --zone=us-west1-c \
    --instances=vm-c1,vm-c2

api

Para las cuatro VM, usa los siguientes nombres de VM y zonas:

  • [VM-NAME] de vm-a1 y [ZONE] de us-west1-a
  • [VM-NAME] de vm-a2 y [ZONE] de us-west1-a
  • [VM-NAME] de vm-c1 y [ZONE] de us-west1-c
  • [VM-NAME] de vm-c2 y [ZONE] de us-west1-c

Puedes obtener el DEBIAN_IMAGE_NAME actual si ejecutas el siguiente comando de gcloud:

gcloud compute images list \
 --filter="family=debian-10"

Crea cuatro VM de backend mediante cuatro solicitudes POST al método instances.insert:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/[ZONE]/instances

{
  "name": "[VM-NAME]",
  "tags": {
    "items": [
      "allow-health-check",
      "allow-ssh"
    ]
  },
  "machineType": "https://www.googleapis.com/compute/v1/projects/project-id/zones/[ZONE]/machineTypes/e2-standard-2",
  "canIpForward": false,
  "networkInterfaces": [
    {
      "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet",
      "accessConfigs": [
        {
          "type": "ONE_TO_ONE_NAT",
          "name": "external-nat",
          "networkTier": "PREMIUM"
        }
      ]
    }
  ],
  "disks": [
    {
      "type": "PERSISTENT",
      "boot": true,
      "mode": "READ_WRITE",
      "autoDelete": true,
      "deviceName": "[VM-NAME]",
      "initializeParams": {
        "sourceImage": "projects/debian-cloud/global/images/debian-image-name",
        "diskType": "projects/project-id/zones/zone/diskTypes/pd-standard",
        "diskSizeGb": "10"
      }
    }
  ],
  "metadata": {
    "items": [
      {
        "key": "startup-script",
        "value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nfile_ports=\"/etc/apache2/ports.conf\"\nfile_http_site=\"/etc/apache2/sites-available/000-default.conf\"\nfile_https_site=\"/etc/apache2/sites-available/default-ssl.conf\"\nhttp_listen_prts=\"Listen 80\\nListen 8008\\nListen 8080\\nListen 8088\"\nhttp_vh_prts=\"*:80 *:8008 *:8080 *:8088\"\nhttps_listen_prts=\"Listen 443\\nListen 8443\"\nhttps_vh_prts=\"*:443 *:8443\"\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nprt_conf=\"$(cat \"$file_ports\")\"\nprt_conf_2=\"$(echo \"$prt_conf\" | sed \"s|Listen 80|${http_listen_prts}|\")\"\nprt_conf=\"$(echo \"$prt_conf_2\" | sed \"s|Listen 443|${https_listen_prts}|\")\"\necho \"$prt_conf\" | tee \"$file_ports\"\nhttp_site_conf=\"$(cat \"$file_http_site\")\"\nhttp_site_conf_2=\"$(echo \"$http_site_conf\" | sed \"s|*:80|${http_vh_prts}|\")\"\necho \"$http_site_conf_2\" | tee \"$file_http_site\"\nhttps_site_conf=\"$(cat \"$file_https_site\")\"\nhttps_site_conf_2=\"$(echo \"$https_site_conf\" | sed \"s|_default_:443|${https_vh_prts}|\")\"\necho \"$https_site_conf_2\" | tee \"$file_https_site\"\nsystemctl restart apache2"
      }
    ]
  },
  "scheduling": {
    "preemptible": false
  },
  "deletionProtection": false
}

Crea dos grupos de instancias mediante una solicitud POST al método instanceGroups.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups

{
  "name": "ig-a",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups

{
  "name": "ig-c",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet"
}

Agrega instancias a cada grupo de instancias mediante una solicitud POST al método instanceGroups.addInstances.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-a/addInstances

{
  "instances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-a/instances/vm-a1",
      "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-a/instances/vm-a2"
    }
  ]
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-c/addInstances

{
  "instances": [
    {
      "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-c/instances/vm-c1",
      "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-c/instances/vm-c2"
    }
  ]
}

Crea una VM cliente

En este ejemplo se crea una VM de cliente (vm-client) en la misma región en la que están las VM de backend (servidor). El cliente se usa para validar la configuración del balanceador de cargas y demostrar el comportamiento esperado, como se describe en la sección de pruebas.

Console

  1. En Google Cloud Console, ve a la página Instancias de VM.
    Ir a Instancias de VM
  2. Haga clic en Crear instancia.
  3. Configura el campo Nombre como vm-client.
  4. En Zona establece us-west1-a.
  5. Haz clic en Administración, seguridad, discos, herramientas de redes, usuario único y realiza los siguientes cambios:
    • Haz clic en Herramientas de redes y agrega allow-ssh a Etiquetas de red.
    • Haz clic en el botón Editar, en Interfaces de red, y realiza los siguientes cambios. Luego, haz clic en Listo:
      • Red: lb-network
      • Subred: lb-subnet
      • IP interna principal: efímera (automática)
      • IP externa: Efímera
  6. Haz clic en Crear.

gcloud

La VM de cliente puede estar en cualquier zona de la misma región que el balanceador de cargas y puede usar cualquier subred en esa región. En este ejemplo el cliente se encuentra en la zona us-west1-a y usa la misma subred que las VM de backend.

gcloud compute instances create vm-client \
    --zone=us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=lb-subnet

api

Realiza una solicitud POST al método instances.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances

{
  "name": "vm-client",
  "tags": {
    "items": [
      "allow-ssh"
    ]
  },
  "machineType": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-a/machineTypes/e2-standard-2",
  "canIpForward": false,
  "networkInterfaces": [
    {
      "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet",
      "accessConfigs": [
        {
          "type": "ONE_TO_ONE_NAT",
          "name": "external-nat",
          "networkTier": "PREMIUM"
        }
      ]
    }
  ],
  "disks": [
    {
      "type": "PERSISTENT",
      "boot": true,
      "mode": "READ_WRITE",
      "autoDelete": true,
      "deviceName": "vm-client",
      "initializeParams": {
        "sourceImage": "projects/debian-cloud/global/images/debian-image-name",
        "diskType": "projects/project-id/zones/us-west1-a/diskTypes/pd-standard",
        "diskSizeGb": "10"
      }
    }
  ],
  "scheduling": {
    "preemptible": false
  },
  "deletionProtection": false
}

Configura componentes del balanceador 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 usamos una verificación de estado de HTTP que solo comprueba si hay 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: Como necesitamos pasar tráfico HTTP a través del balanceador de cargas interno, debemos usar TCP, no UDP.

  • Regla de reenvío: en este ejemplo se crea una sola regla de reenvío interno.

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

Console

Crea el balanceador de cargas y configura un servicio de backend

  1. En Google Cloud Console, ve a la página Balanceo de cargas.
    Ir a 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. Configura el campo Nombre como be-ilb.
  7. Haz clic en Configuración de backend y realiza los siguientes cambios:
    1. Región: us-west1
    2. Red: lb-network
    3. En Backends, en la sección Nuevos backends, selecciona el grupo de instancias ig-a y haz clic en Listo.
    4. Haga clic en Agregar backend. En la sección Nuevos backends que aparece, selecciona el grupo de instancias ig-c y vuelve a hacer clic en Listo.
    5. En Verificación de estado, elige Crear una verificación de estado, ingresa la siguiente información y haz clic en Guardar:
      • Name: 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 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.
    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-ilb
    2. Subred: lb-subnet
    3. En IP interna elige Crear dirección IP, ingresa la siguiente información y haz clic en Reservar:
      • Name: ip-ilb
      • Dirección IP estática: permíteme elegir
      • Dirección IP personalizada: 10.1.2.99
    4. Puertos: elige Múltiples y, luego, ingresa 80,8008,8080,8088 en el Número de puerto.
    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. Haga clic en Revisar y finalizar. Comprueba toda la configuración.
  10. Haga clic en Crear.

gcloud

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

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

  2. Crea el servicio de backend para el tráfico HTTP:

    gcloud compute backend-services create be-ilb \
    --load-balancing-scheme=internal \
    --protocol=tcp \
    --region=us-west1 \
    --health-checks=hc-http-80 \
    --health-checks-region=us-west1

  3. Agrega los dos grupos de instancias al servicio de backend:

    gcloud compute backend-services add-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-a \
    --instance-group-zone=us-west1-a
gcloud compute backend-services add-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-c \
    --instance-group-zone=us-west1-c

  4. Crea una regla de reenvío para el servicio de backend. Cuando crees la regla de reenvío, especifica 10.1.2.99 como la dirección IP interna en la subred.

    gcloud compute forwarding-rules create fr-ilb \
    --region=us-west1 \
    --load-balancing-scheme=internal \
    --network=lb-network \
    --subnet=lb-subnet \
    --address=10.1.2.99 \
    --ip-protocol=TCP \
    --ports=80,8008,8080,8088 \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

api

Para crear la verificación de estado, realiza una solicitud POST al método regionHealthChecks.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionHealthChecks

{
  "name": "hc-http-80",
  "type": "HTTP",
  "httpHealthCheck": {
    "port": 80
  }
}

Crea el servicio de backend regional mediante una solicitud POST al método regionBackendServices.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices

{
  "name": "be-ilb",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-a/instanceGroups/ig-a",
      "balancingMode": "CONNECTION"
    },
    {
      "group": "https://www.googleapis.com/compute/v1/projects/project-id/zones/us-west1-c/instanceGroups/ig-c",
      "balancingMode": "CONNECTION"
    }
  ],
  "healthChecks": [
    "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/healthChecks/hc-http-80"
  ],
  "loadBalancingScheme": "INTERNAL",
  "connectionDraining": {
    "drainingTimeoutSec": 0
   }
}

Para crear la regla de reenvío, realiza una solicitud POST al método forwardingRules.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
  "name": "fr-ilb",
  "IPAddress": "10.1.2.99",
  "IPProtocol": "TCP",
  "ports": [
    "80", "8008", "8080", "8088"
  ],
  "loadBalancingScheme": "INTERNAL",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "backendService": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices/be-ilb",
  "networkTier": "PREMIUM"
}

Prueba

Mediante estas pruebas se muestra cómo validar la configuración del balanceador de cargas y conocer su comportamiento esperado.

Prueba de balanceo de cargas

En esta prueba, se contacta al balanceador de cargas desde una VM de cliente diferente, es decir, no desde una VM de backend del balanceador de cargas. El comportamiento esperado consiste en que el tráfico se distribuya entre las cuatro VM de backend porque no se configuró ninguna afinidad de sesión.

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

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

  2. Realiza una solicitud web al balanceador de cargas mediante curl para establecer contacto con su dirección IP. Repite la solicitud para que puedas ver que las respuestas provienen de diferentes VM de backend. El nombre de la VM que genera la respuesta se muestra en el texto de la respuesta HTML, en virtud del contenido de /var/www/html/index.html en cada VM de backend. Las respuestas esperadas se ven de la siguiente manera: Page served from: vm-a1, Page served from: vm-a2, etcétera.

    curl http://10.1.2.99

    La regla de reenvío está configurada para entregar en los puertos 80, 8008, 8080 y 8088. Para enviar tráfico a esos otros puertos, agrega dos puntos (:) y el número de puerto después de la dirección IP, de esta manera:

    curl http://10.1.2.99:8008

    • Si agregas una etiqueta de servicio a la regla de reenvío interno, puedes usar DNS interno para contactar al balanceador de cargas con su nombre de servicio.

      curl http://web-test.fr-ilb.il4.us-west1.lb.project-id.internal

Haz ping a la dirección IP del balanceador de cargas

En esta prueba se demuestra un comportamiento esperado: no puedes hacer ping a la dirección IP del balanceador de cargas. Esto se debe a que los balanceadores de cargas de TCP/UDP internos se implementan en la programación de red virtual. No son dispositivos diferentes.

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

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

  2. Intenta hacer ping en la dirección IP del balanceador de cargas. Observa que no recibes una respuesta y que se agota el tiempo de espera del comando ping después de 10 segundos en este ejemplo.

    timeout 10 ping 10.1.2.99

Envía solicitudes desde VM con balanceo de cargas

En esta prueba se demuestra que, de forma predeterminada, las solicitudes al balanceador de cargas que se originan en cualquiera de las VM de backend (las VM de servidor en las que se aplica el balanceo de cargas) siempre reciben respuestas de la misma VM que realiza la solicitud.

El balanceo de cargas de TCP/UDP interno se implementa mediante la programación de red virtual y la configuración de VM en el SO invitado. En las VM de Linux, el entorno invitado de Linux realiza la configuración local mediante la instalación de una ruta en la tabla de enrutamiento del SO invitado. Debido a esta ruta local, el tráfico orientado a la dirección IP del balanceador de cargas permanece en la misma VM con balanceo de cargas. (Esta ruta local es diferente de las rutas en la red de VPC).

  1. Conéctate a una VM de backend, como vm-a1:

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

  2. Realiza una solicitud web al balanceador de cargas (por dirección IP o nombre del servicio) mediante curl. Repite la solicitud y ten en cuenta que la respuesta se envía desde la VM de backend que realiza la solicitud. La respuesta esperada cuando se realiza una prueba desde vm-a1 siempre es: Page served from: vm-a1.

    curl http://10.1.2.99

  3. Inspecciona la tabla de enrutamiento local en busca de un destino que coincida con la dirección IP del balanceador de cargas, 10.1.2.99. Esta ruta es una parte necesaria del balanceo de cargas TCP/UDP interno, pero también demuestra por qué una solicitud desde una VM detrás del balanceador de cargas siempre recibe respuestas de la misma VM.

    ip route show table local | grep 10.1.2.99

Este comportamiento predeterminado no se aplica cuando la VM de backend que envía la solicitud tiene una ruta --next-hop-ilb con un destino de siguiente salto que es su propia dirección IP de balanceo de cargas. Cuando la VM se orienta a la dirección IP especificada en la ruta, otra VM con balanceo de cargas puede responder a la solicitud.

Por ejemplo, puedes crear una ruta de destino de 192.168.1.0/24 con un --next-hop-ilb de 10.20.1.1.

Una VM que está detrás del balanceador de cargas puede orientarse a 192.168.1.1. Debido a que la dirección no está en la tabla de enrutamiento local, se envía la VM para que las rutas de Google Cloud sean aplicables. Si no hay otras rutas aplicables con mayor prioridad, se elige la ruta --next-hop-ilb.

Para obtener más información, consulta Balanceadores de cargas TCP/UDP internos como siguientes saltos.

Opciones de configuración adicionales

En esta sección se expande el ejemplo de configuración para proporcionar opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes realizarlas en cualquier orden.

Habilita el acceso global

Puedes habilitar el acceso global para tu balanceador de cargas de TCP/UDP interno de ejemplo a fin de que sea accesible a los clientes en todas las regiones. De todos modos, los backends del balanceador de cargas de ejemplo deben ubicarse en una región (us-west1).

Balanceo de cargas TCP/UDP interno con acceso global (haz clic para ampliar)
Balanceo de cargas de TCP/UDP interno con acceso global (haz clic para ampliar)

Para configurar el acceso global, realiza los siguientes cambios de configuración.

Console

Modifica la regla de reenvío del balanceador de cargas

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

  2. En la columna Nombre, haz clic en el balanceador de cargas TCP/UDP interno. El balanceador de cargas de ejemplo se llama be-ilb.

  3. Haz clic en Configuración de frontend.

  4. Haz clic en Editar .

  5. En Acceso global, selecciona Habilitar.

  6. Haz clic en Listo.

  7. Haz clic en Actualizar.

En la página Detalles del balanceador de cargas, verifica que la configuración de frontend indique Regional (REGION) con acceso global.

gcloud

  1. Actualiza la regla de reenvío del balanceador de cargas de ejemplo, fr-ilb, para incluir la marca --allow-global-access.

    gcloud compute forwarding-rules update fr-ilb \
   --region=us-west1 \
   --allow-global-access

  2. Puedes usar el comando forwarding-rules describe para determinar si una regla de reenvío tiene habilitado el acceso global. Por ejemplo:

    gcloud compute forwarding-rules describe fr-ilb \
   --region=us-west1 \
   --format="get(name,region,allowGlobalAccess)"

    La palabra True aparece en la salida, después del nombre y la región de la regla de reenvío, cuando el acceso global está habilitado.

api

Realiza una solicitud PATCH al método forwardingRules/patch.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules/fr-ilb

{
  "allowGlobalAccess": true
}

Crea un cliente de VM para probar el acceso global

Console

  1. En Google Cloud Console, ve a la página Instancias de VM.
    Ir a Instancias de VM
  2. Haga clic en Crear instancia.
  3. Configura el campo Nombre como vm-client2.
  4. En Zona establece europe-west1-b.
  5. Haz clic en Administración, seguridad, discos, herramientas de redes, usuario único y realiza los siguientes cambios:
    • Haz clic en Herramientas de redes y agrega allow-ssh a Etiquetas de red.
    • Haz clic en el botón Editar, en Interfaces de red, y realiza los siguientes cambios. Luego, haz clic en Listo:
      • Red: lb-network
      • Subred: europe-subnet
      • IP interna principal: efímera (automática)
      • IP externa: Efímera
  6. Haz clic en Crear.

gcloud

La VM de cliente puede estar en cualquier zona de la misma región que el balanceador de cargas y puede usar cualquier subred en esa región. En este ejemplo el cliente se encuentra en la zona europe-west1-b y usa la misma subred que las VM de backend.

gcloud compute instances create vm-client2 \
    --zone=europe-west1-b \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=europe-subnet

api

Realiza una solicitud POST al método instances.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/europe-west1-b/instances

{
  "name": "vm-client2",
  "tags": {
    "items": [
      "allow-ssh"
    ]
  },
  "machineType": "https://www.googleapis.com/compute/v1/projects/project-id/zones/europe-west1-b/machineTypes/e2-standard-2",
  "canIpForward": false,
  "networkInterfaces": [
    {
      "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
      "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/europe-west1/subnetworks/europe-subnet",
      "accessConfigs": [
        {
          "type": "ONE_TO_ONE_NAT",
          "name": "external-nat",
          "networkTier": "PREMIUM"
        }
      ]
    }
  ],
  "disks": [
    {
      "type": "PERSISTENT",
      "boot": true,
      "mode": "READ_WRITE",
      "autoDelete": true,
      "deviceName": "vm-client2",
      "initializeParams": {
        "sourceImage": "projects/debian-cloud/global/images/debian-image-name",
        "diskType": "projects/project-id/zones/europe-west1-b/diskTypes/pd-standard",
        "diskSizeGb": "10"
      }
    }
  ],
  "scheduling": {
    "preemptible": false
  },
  "deletionProtection": false
}

Conéctate al cliente de VM y prueba la conectividad

gcloud compute ssh vm-client2 --zone=europe-west1-b

Prueba conectarte al balanceador de cargas en todos los puertos configurados, como lo hiciste desde vm-client en la región us-west1. Prueba la conectividad de HTTP en los cuatro puertos configurados en la regla de reenvío:

curl http://10.1.2.99
curl http://10.1.2.99:8008
curl http://10.1.2.99:8080
curl http://10.1.2.99:8088

Configura grupos de instancias administrados

Con la configuración de ejemplo, se crearon dos grupos de instancias no administrados. En su lugar, puedes usar grupos de instancias administrados, incluidos los grupos de instancias administrados zonales y regionales, como backends para el balanceo de cargas de TCP/UDP interno.

Los grupos de instancias administrados requieren que crees una plantilla de instancias. En este procedimiento se muestra cómo reemplazar los dos grupos de instancias zonales no administrados del ejemplo por un solo grupo de instancias administrado regional. Un grupo de instancias administrado regional crea VM de forma automática en varias zonas de la región, lo que simplifica la distribución del tráfico de producción entre las zonas.

En tu grupo de instancias, puedes definir un servicio de backend y mapear un nombre de puerto al puerto pertinente. El servicio de balanceo de cargas reenvía el tráfico al puerto especificado.

Los grupos de instancias administrados también admiten el ajuste de escala automático y la reparación automática. Si usas el ajuste de escala automático con balanceo de cargas TCP/UDP interno, no podrás ajustar la escala según el balanceo de cargas.

En este procedimiento se muestra cómo modificar el servicio de backend para el balanceador de cargas TCP/UDP interno de ejemplo a fin de que use un grupo de instancias administrado regional.

Console

Plantilla de instancias

  1. En Google Cloud Console, ve a la página Plantillas de instancia de VM.
    Ir a plantillas de instancias de VM
  2. Haga clic en Crear plantilla de instancias.
  3. Ingresa template-vm-ilb en Nombre.
  4. Elige un tipo de máquina.
  5. Para Disco de arranque, haz clic en Cambiar y elige el sistema operativo Debian y la versión 10 (buster).
  6. Haz clic en Guardar para confirmar las opciones de este disco de arranque.

  7. Haz clic en Administración, seguridad, discos, herramientas de redes, usuario único.

    • Haz clic en Herramientas de redes y realiza los siguientes cambios:
      • Red: lb-network
      • Subred: lb-subnet
      • Etiquetas de red: allow-ssh y allow-health-check
    • Haz clic en Administración. En el campo Secuencia de comandos de inicio, copia y pega el siguiente contenido de la secuencia de comandos:
    #! /bin/bash
if [ -f /etc/startup_script_completed ]; then
exit 0
fi
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
file_ports="/etc/apache2/ports.conf"
file_http_site="/etc/apache2/sites-available/000-default.conf"
file_https_site="/etc/apache2/sites-available/default-ssl.conf"
http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088"
http_vh_prts="*:80 *:8008 *:8080 *:8088"
https_listen_prts="Listen 443\nListen 8443"
https_vh_prts="*:443 *:8443"
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
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
prt_conf="$(cat "$file_ports")"
prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")"
prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")"
echo "$prt_conf" | tee "$file_ports"
http_site_conf="$(cat "$file_http_site")"
http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")"
echo "$http_site_conf_2" | tee "$file_http_site"
https_site_conf="$(cat "$file_https_site")"
https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")"
echo "$https_site_conf_2" | tee "$file_https_site"
systemctl restart apache2
touch /etc/startup_script_completed

  8. Haz clic en Crear.

Grupo de instancias administrado

  1. En Google Cloud Console, ve a la página Grupos de instancias.
    Ir a grupos de instancias de VM
  2. Haga clic en Crear grupo de instancias.
  3. Configura el campo Nombre como ig-ilb.
  4. En Ubicación, elige Varias zonas y establece Región en us-west1.
  5. Establece Plantilla de instancias en template-vm-ilb.
  6. Configura el ajuste de escala automático (opcional). No puedes usar el ajuste de escala automático en el grupo de instancias en función del uso del balanceo de cargas de HTTP porque el grupo de instancias es un backend para el balanceo de cargas de TCP/UDP interno.
  7. En Cantidad mínima de instancias, establece el valor en 1 y, en Cantidad máxima de instancias, establece el valor en 6.
  8. Configura la reparación automática (opcional). Si configuras la reparación automática, debes usar la misma verificación de estado que usa el servicio de backend para el balanceador de cargas de TCP/UDP interno. En este ejemplo usa hc-http-80.
  9. Haz clic en Crear.

gcloud

  1. Crea la plantilla de instancias. De forma opcional, puedes establecer otros parámetros, como el tipo de máquina, para que los use la plantilla de imágenes.

    gcloud compute instance-templates create template-vm-ilb \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh,allow-health-check \
    --subnet=lb-subnet \
    --region=us-west1 \
    --network=lb-network \
       --metadata=startup-script='#! /bin/bash
         if [ -f /etc/startup_script_completed ]; then
         exit 0
         fi
         apt-get update
         apt-get install apache2 -y
         a2ensite default-ssl
         a2enmod ssl
         file_ports="/etc/apache2/ports.conf"
         file_http_site="/etc/apache2/sites-available/000-default.conf"
         file_https_site="/etc/apache2/sites-available/default-ssl.conf"
         http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088"
         http_vh_prts="*:80 *:8008 *:8080 *:8088"
         https_listen_prts="Listen 443\nListen 8443"
         https_vh_prts="*:443 *:8443"
         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
         prt_conf="$(cat "$file_ports")"
         prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")"
         prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")"
         echo "$prt_conf" | tee "$file_ports"
         http_site_conf="$(cat "$file_http_site")"
         http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")"
         echo "$http_site_conf_2" | tee "$file_http_site"
         https_site_conf="$(cat "$file_https_site")"
         https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")"
         echo "$https_site_conf_2" | tee "$file_https_site"
         systemctl restart apache2
         touch /etc/startup_script_completed'

  2. Crea un grupo de instancias administrado regional con la plantilla:

    gcloud compute instance-groups managed create ig-ilb \
    --template=template-vm-ilb \
    --region=us-west1 \
    --size=6

  3. Agrega el grupo de instancias administrado regional como un backend al servicio de backend que ya creaste:

    gcloud compute backend-services add-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-ilb \
    --instance-group-region=us-west1

  4. Desconecta los dos grupos de instancias no administrados (zonales) del servicio de backend:

    gcloud compute backend-services remove-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-a \
    --instance-group-zone=us-west1-a
gcloud compute backend-services remove-backend be-ilb \
    --region=us-west1 \
    --instance-group=ig-c \
    --instance-group-zone=us-west1-c

Quita direcciones IP externas de las VM de backend

Cuando creaste las VM de backend, a cada una se le asignó una dirección IP externa efímera para que pudiera descargar Apache a través de una secuencia de comandos de inicio. Debido a que a las VM de backend solo las usa un balanceador de cargas TCP/UDP interno, puedes quitar sus direcciones IP externas. Quitar las direcciones IP externas evita que las VM de backend accedan a Internet directamente.

Console

  1. En Google Cloud Console, ve a la página Instancias de VM.
    Ir a Instancias de VM
  2. Repite los siguientes pasos para cada VM de backend.
  3. Haz clic en el nombre de la VM de backend (por ejemplo, vm-a1) para ver Detalles de instancia de VM.
  4. Haz clic en Editar .
  5. En la sección Interfaces de red, haz clic en el botón Editar.
  6. En la ventana emergente IP externa, selecciona Ninguna y haz clic en Listo.
  7. Haz clic en Guardar.

gcloud

  1. Si deseas buscar la zona de una instancia (por ejemplo, si usas un grupo de instancias administrado regional), ejecuta el siguiente comando para cada instancia a fin de determinar su zona. Reemplaza [SERVER-VM] por el nombre de la VM que deseas buscar.

    gcloud compute instances list --filter="name=[SERVER-VM]"

  2. Repite el siguiente paso para cada VM de backend. Reemplaza [SERVER-VM] por el nombre de la VM y [ZONE] por la zona de la VM.

    gcloud compute instances delete-access-config [SERVER-VM] \
    --zone=[ZONE] \
    --access-config-name=external-nat

api

Realiza una solicitud POST al método instances.deleteAccessConfig para cada VM de backend, y reemplaza vm-a1 por el nombre de la VM y us-west1-a por la zona de la VM.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a1/deleteAccessConfig?accessConfig=external-nat&networkInterface=None

Acepta tráfico en todos los puertos

La regla de reenvío del balanceador de cargas, no su servicio de backend, determina los puertos en los que el balanceador de cargas acepta tráfico. Para obtener información sobre el propósito de cada componente, consulta Componentes.

Cuando creaste este ejemplo de regla de reenvío del balanceador de cargas, configuraste los puertos 80, 8008, 8080 y 8088. La secuencia de comandos de inicio con la que se instala Apache también sirve para configurar Apache a fin de que acepte conexiones HTTPS en los puertos 443 y 8443.

Para admitir estos seis puertos, puedes configurar la regla de reenvío a fin de aceptar el tráfico en todos los puertos. Con esta estrategia también puedes configurar las reglas del firewall que admiten conexiones entrantes en las VM de backend para que solo permitan determinados puertos.

Este procedimiento te muestra cómo reemplazar la regla de reenvío del balanceador de cargas de ejemplo por una que acepte el tráfico en todos los puertos.

Para obtener más información sobre el balanceo de cargas y las reglas de reenvío, consulta Reglas balanceo de cargas TCP/UDP internas y de reenvío con una dirección IP común.

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. Haz clic en Configuración de frontend.
  4. Coloca el cursor sobre tu regla de reenvío 10.1.2.9 y haz clic en el ícono de la papelera para borrarla.
  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: fr-ilb
    2. Subred: lb-subnet
    3. En IP interna selecciona ip-ilb
    4. Puertos: todos
    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 la regla de reenvío existente, fr-ilb.

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

  2. Crea una regla de reenvío de reemplazo, con el mismo nombre, cuya configuración de puerto use la palabra clave ALL. Los demás parámetros de la regla de reenvío siguen siendo los mismos.

    gcloud compute forwarding-rules create fr-ilb \
    --region=us-west1 \
    --load-balancing-scheme=internal \
    --network=lb-network \
    --subnet=lb-subnet \
    --address=10.1.2.99 \
    --ip-protocol=TCP \
    --ports=ALL \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

api

Borra la regla de reenvío mediante una solicitud DELETE al método forwardingRules.delete.

DELETE https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules/fr-ilb

Para crear la regla de reenvío, realiza una solicitud POST al método forwardingRules.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
  "name": "fr-ilb",
  "IPAddress": "10.1.2.99",
  "IPProtocol": "TCP",
  "allPorts": true,
  "loadBalancingScheme": "INTERNAL",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "backendService": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices/be-ilb",
  "networkTier": "PREMIUM"
}

Prueba el tráfico en la configuración de todos los puertos

Conéctate a la instancia de VM de cliente y prueba las conexiones HTTP y HTTPS.

  • Conéctate a la VM de cliente:

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

  • Prueba la conectividad HTTP en los cuatro puertos:

    curl http://10.1.2.99
curl http://10.1.2.99:8008
curl http://10.1.2.99:8080
curl http://10.1.2.99:8088

  • Prueba la conectividad de HTTPS en los puertos 443 y 8443. La marca --insecure es obligatoria, ya que cada servidor Apache en la configuración de ejemplo usa un certificado autofirmado.

    curl https://10.1.2.99 --insecure
 curl https://10.1.2.99:8443 --insecure

  • Observa que las solicitudes HTTP (en los cuatro puertos) y las solicitudes HTTPS (en ambos puertos) se distribuyan entre todas las VM de backend.

Acepta tráfico en varios puertos mediante dos reglas de reenvío

Cuando creaste este ejemplo de regla de reenvío del balanceador de cargas, configuraste los puertos 80, 8008, 8080 y 8088. La secuencia de comandos de inicio con la que se instala Apache también sirve para configurar Apache a fin de que acepte conexiones HTTPS en los puertos 443 y 8443.

Una estrategia alternativa a la configuración de una regla de reenvío única para aceptar el tráfico en todos los puertos consiste en crear varias reglas de reenvío, y que cada una admita cinco puertos o menos.

Mediante este procedimiento se muestra cómo reemplazar la regla de reenvío del balanceador de cargas de ejemplo con dos reglas de reenvío: una que controla el tráfico en los puertos 80, 8008, 8080 y 8088, y otra que controla el tráfico en los puertos 443 y 8443.

Para obtener más información sobre el balanceo de cargas y las reglas de reenvío, consulta Reglas balanceo de cargas TCP/UDP internas y de reenvío con una dirección IP común.

Console

  1. En Google Cloud Console, ve a la página Reglas de reenvío.
    Ir a Reglas de reenvío
  2. Selecciona fr-ilb.
  3. Haz clic en Borrar.
  4. Ve a la página Balanceo de cargas.
    Ir a la página Balanceo de cargas
  5. Selecciona tu balanceador de cargas TCP/UDP interno. En este ejemplo, be-ilb.
  6. Haz clic en Editar.
  7. Haga clic en Configuración de frontend.
  8. Haz clic en Agregar IP y puerto de frontend.
  9. En la sección IP y puerto de frontend nuevos, realiza los siguientes cambios:
    1. Nombre: fr-ilb-http
    2. Subred: lb-subnet
    3. En Propósito, selecciona Compartido.
    4. En IP interna elige Reserva una nueva dirección IP interna estática, ingresa la siguiente información y haz clic en Reservar:
      • Nombre: internal-10-1-2-99
      • Dirección IP estática: permíteme elegir
      • Dirección IP personalizada: 10.1.2.99
      • Haga clic en Reservar.
    5. Puertos: elige Múltiples y, luego, ingresa 80,8008,8080,8088 en el Número de puerto.
    6. Haga clic en Listo.
  10. Haz clic en Agregar IP y puerto de frontend.
  11. En la sección IP y puerto de frontend nuevos, realiza los siguientes cambios:
    1. Nombre: fr-ilb-https
    2. Subred: lb-subnet
    3. En Propósito, selecciona Compartido.
    4. En Dirección IP, selecciona internal-10-1-2-99.
    5. Puertos: elige Múltiples y, luego, ingresa 443,8443 en el Número de puerto.
    6. Haga clic en Listo.
    7. Verifica que haya una marca de verificación azul junto a Configuración de frontend antes de continuar. Si no, revisa este paso.
  12. Haz clic en Revisar y finalizar. Vuelve a verificar la configuración.
  13. Haz clic en Actualizar.

gcloud

  1. Borra la regla de reenvío existente, fr-ilb.

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

  2. Crea una dirección IP interna (reservada) y estática para 10.1.2.99 y establece su marca --purpose en SHARED_LOADBALANCER_VIP. Se requiere la marca --purpose para que dos reglas de reenvío interno puedan usar la misma dirección IP interna.

    gcloud compute addresses create internal-10-1-2-99 \
    --region=us-west1 \
    --subnet=lb-subnet \
    --addresses=10.1.2.99 \
    --purpose=SHARED_LOADBALANCER_VIP
    1. Crea dos reglas de reenvío de reemplazo con los siguientes parámetros:
    gcloud compute forwarding-rules create fr-ilb-http \
    --region=us-west1 \
    --load-balancing-scheme=internal \
    --network=lb-network \
    --subnet=lb-subnet \
    --address=10.1.2.99 \
    --ip-protocol=TCP \
    --ports=80,8008,8080,8088 \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

    gcloud compute forwarding-rules create fr-ilb-https \
    --region=us-west1 \
    --load-balancing-scheme=internal \
    --network=lb-network \
    --subnet=lb-subnet \
    --address=10.1.2.99 \
    --ip-protocol=TCP \
    --ports=443,8443 \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

api

Borra la regla de reenvío mediante una solicitud DELETE al método forwardingRules.delete.

DELETE https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules/fr-ilb

Crea una dirección IP interna (reservada) y estática para 10.1.2.99 y establece su propósito en SHARED_LOADBALANCER_VIP mediante una solicitud POST al método addresses.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/addresses

{
  "name": "internal-10-1-2-99",
  "address": "10.1.2.99",
  "prefixLength": 32,
  "addressType": INTERNAL,
  "purpose": SHARED_LOADBALANCER_VIP,
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet"
}

Crea dos reglas de reenvío mediante dos solicitudes POST al método forwardingRules.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
  "name": "fr-ilb-http",
  "IPAddress": "10.1.2.99",
  "IPProtocol": "TCP",
  "ports": [
    "80", "8008", "8080",  "8088"
  ],
  "loadBalancingScheme": "INTERNAL",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "backendService": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices/be-ilb",
  "networkTier": "PREMIUM"
}

{
  "name": "fr-ilb-https",
  "IPAddress": "10.1.2.99",
  "IPProtocol": "TCP",
  "ports": [
    "443", "8443"
  ],
  "loadBalancingScheme": "INTERNAL",
  "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "backendService": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices/be-ilb",
  "networkTier": "PREMIUM"
}

Prueba el tráfico en la configuración de varios puertos

Conéctate a la instancia de VM de cliente y prueba las conexiones HTTP y HTTPS.

  • Conéctate a la VM de cliente:

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

  • Prueba la conectividad HTTP en los cuatro puertos:

    curl http://10.1.2.99
curl http://10.1.2.99:8008
curl http://10.1.2.99:8080
curl http://10.1.2.99:8088

  • Prueba la conectividad de HTTPS en los puertos 443 y 8443. La marca --insecure es obligatoria, ya que cada servidor Apache en la configuración de ejemplo usa un certificado autofirmado.

    curl https://10.1.2.99 --insecure
curl https://10.1.2.99:8443 --insecure

  • Observa que las solicitudes HTTP (en los cuatro puertos) y las solicitudes HTTPS (en ambos puertos) se distribuyan entre todas las VM de backend.

Usa la afinidad de sesión

En la configuración de ejemplo, se crea un servicio de backend sin afinidad de sesión.

En este procedimiento, se muestra cómo actualizar el servicio de backend para el balanceador de cargas de TCP/UDP interno de ejemplo a fin de que use la afinidad de sesión en función de un hash que se creó a partir de las direcciones IP del cliente y de la regla de reenvío interno del balanceador de cargas.

Para conocer los tipos de afinidad de sesión compatibles, consulta Opciones de afinidad de sesión.

Console

  1. En Google Cloud Console, ve a la página Balanceo de cargas.
    Ir a balanceo de cargas
  2. Haz clic en be-ilb (nombre del servicio de backend que creaste para este ejemplo) y, luego, en Editar.
  3. En la página Editar balanceador de cargas interno, haz clic en Configuración de backend.
  4. Selecciona IP de cliente en el menú emergente Afinidad de sesión.
  5. Haz clic en Actualizar.

gcloud

Usa el siguiente comando de gcloud para actualizar el servicio de backend be-ilb y especifica la afinidad de sesión de IP de cliente:

gcloud compute backend-services update be-ilb \
    --region=us-west1 \
    --session-affinity CLIENT_IP

api

Realiza una solicitud PATCH al método regionBackendServices/patch.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb

{
  "sessionAffinity": "CLIENT_IP"
}

Configura una política de seguimiento de conexiones

En esta sección, se muestra cómo actualizar el servicio de backend para cambiar la política predeterminada de seguimiento de conexiones del balanceador de cargas.

Una política de seguimiento de conexión incluye la siguiente configuración:

gcloud

Usa el siguiente comando gcloud compute backend-services para actualizar la política de seguimiento de conexiones del servicio de backend:

gcloud compute backend-services update BACKEND_SERVICE \
    --region=REGION \
    --tracking-mode=TRACKING_MODE \
    --connection-persistence-on-unhealthy-backends=CONNECTION_PERSISTENCE_BEHAVIOR \
    --idle-timeout-sec=IDLE_TIMEOUT_VALUE

Reemplaza los marcadores de posición por valores válidos:

  • BACKEND_SERVICE: El servicio de backend que estás actualizando.
  • REGION: Es la región del servicio de backend que deseas actualizar.
  • TRACKING_MODE: Es el modo de seguimiento de conexión que se usará para los paquetes entrantes. Si deseas obtener la lista de valores admitidos, consulta Modo de seguimiento.
  • CONNECTION_PERSISTENCE_BEHAVIOR: Es el comportamiento de la conexión persistente cuando los backends están en mal estado. Para obtener la lista de los valores admitidos, consulta Persistencia de conexiones en backends en mal estado.

  • IDLE_TIMEOUT_VALUE: Es la cantidad de segundos que se debe mantener una entrada de la tabla de seguimiento de conexión después de que el balanceador de cargas procese el último paquete que coincidió con la entrada.

    Solo puedes modificar esta propiedad cuando el seguimiento de conexión sea inferior a 5 tuplas (es decir, cuando la afinidad de sesión está configurada para ser CLIENT_IP o bien, puedes hacer lo siguiente: CLIENT_IP_PROTO, y el modo de seguimiento es el siguiente: PER_SESSION).

    El valor predeterminado es 600 segundos (10 minutos). El valor de tiempo de espera de inactividad máximo configurable es de 57,600 segundos (16 horas).

Crea una regla de reenvío en otra subred

En este procedimiento, se crea una segunda dirección IP y regla de reenvío en una subred diferente a fin de demostrar que se pueden crear múltiples reglas de reenvío para un balanceador de cargas TCP/UDP interno. La región de la regla de reenvío debe coincidir con la región del servicio de backend.

Los clientes en cualquier subred de la región están sujetos a las reglas de firewall y pueden contactarse con la dirección IP interna del balanceador de cargas de TCP/UDP.

Console

Agrega la segunda subred

  1. En Cloud Console, ve a la página Redes de VPC.
    Ir a las redes de VPC
  2. Haga clic en Crear red de VPC.
  3. Haz clic en lb-network.
  4. En la sección Subredes, haz lo siguiente:
    • Haz clic en Agregar subred.
    • En la sección Nueva subred, ingresa la siguiente información:
      • Nombre: second-subnet
      • Región:: us-west1
      • Rango de direcciones IP: 10.5.6.0/24
      • Haz clic en Agregar.

Agrega la segunda regla de reenvío

  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. Haz clic en Configuración de frontend.
  4. Haz clic en Agregar IP y puerto de frontend.
  5. En la sección IP y puerto de frontend nuevos, realiza los siguientes cambios:
    1. Nombre: fr-ilb-2
    2. Subred: second-subnet
    3. En IP interna selecciona ip-ilb
    4. Puertos: 80, 443.
    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.
  6. Haz clic en Revisar y finalizar. Vuelve a verificar la configuración.
  7. Haz clic en Crear.

gcloud

  1. Crea una segunda subred en la red lb-network, en la región us-west1:

    gcloud compute networks subnets create second-subnet \
   --network=lb-network \
   --range=10.5.6.0/24 \
   --region=us-west1

  2. Crea una segunda regla de reenvío para los puertos 80 y 443. Los otros parámetros de esta regla, incluido el servicio de backend y la dirección IP, son los mismos que los de la regla de reenvío principal, fr-ilb.

    gcloud compute forwarding-rules create fr-ilb-2 \
   --region=us-west1 \
   --load-balancing-scheme=internal \
   --network=lb-network \
   --subnet=second-subnet \
   --address=10.5.6.99 \
   --ip-protocol=TCP \
   --ports=80,443 \
   --backend-service=be-ilb \
   --backend-service-region=us-west1

api

Realiza una solicitud POST al método subnetworks.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "second-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
  "ipCidrRange": "10.5.6.0/24",
  "privateIpGoogleAccess": false
}

Para crear la regla de reenvío, realiza una solicitud POST al método forwardingRules.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
 "name": "fr-ilb-2",
 "IPAddress": "10.5.6.99",
 "IPProtocol": "TCP",
 "ports": [
   "80", "443"
 ],
 "loadBalancingScheme": "INTERNAL",
 "subnetwork": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/subnetworks/lb-subnet",
 "network": "https://www.googleapis.com/compute/v1/projects/project-id/global/networks/lb-network",
 "backendService": "https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices/be-ilb",
 "networkTier": "PREMIUM"
}

Prueba la regla de reenvío nueva

  1. Conéctate a la instancia de VM de cliente y prueba las conexiones HTTP y HTTPS en las direcciones IP.

    • Conéctate a la VM de cliente:
    gcloud compute ssh vm-client --zone=us-west1-a
    • Prueba la conectividad HTTP en las direcciones IP:
    curl http://10.1.2.99
curl http://10.5.6.99
    • Prueba la conectividad de HTTPS. El uso de --insecure es obligatorio porque la configuración del servidor Apache en la configuración de ejemplo usa certificados autofirmados.
    curl https://10.1.2.99 --insecure
curl https://10.5.6.99 --insecure
    • Observa que todas las VM de backend manejen las solicitudes, sin importar el protocolo (HTTP o HTTPS) o la dirección IP que se usa.

Usa la subdivisión de backend

En la configuración de ejemplo, se crea un servicio de backend sin subdivisión.

En este procedimiento, se muestra cómo habilitar la subdivisión en el servicio de backend para el balanceador de cargas de TCP/UDP interno de ejemplo a fin de que la implementación pueda escalar a una mayor cantidad de instancias de backend.

Solo debes habilitar la subdivisión si necesitas admitir más de 250 VM de backend en un solo balanceador de cargas.

Para obtener más información sobre este caso de uso, consulta Subdivisión de backend.

gcloud

Usa el siguiente comando de gcloud para actualizar el servicio de backend be-ilb y especifica la política de subdivisión:

gcloud compute backend-services update be-ilb \
    --subsetting-policy=CONSISTENT_HASH_SUBSETTING

api

Realiza una solicitud PATCH al método regionBackendServices/patch.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb

{
  "subsetting":
    {
      "policy": CONSISTENT_HASH_SUBSETTING
    }
}

¿Qué sigue?