Configura el balanceo de cargas TCP/UDP interno

En esta guía, se usa un ejemplo para enseñar los aspectos principales del balanceo de cargas 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 siguientes funciones de IAM de Compute Engine:

Tarea Función requerida
Crear redes, subredes y componentes del balanceador de cargas Administrador de red
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:

Configuración

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

  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 cliente para probar conexiones
  5. Los siguientes componentes del balanceador de cargas 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 a 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 de balanceo de cargas TCP/UDP interno (haz clic para ampliar)

Configura una red, una región y una subred

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

Las VM de backend de este ejemplo y los componentes del balanceador de cargas se encuentran en esta región y subred:

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

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

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

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

Console

  1. Ve a la página Redes de VPC en Google Cloud Console.
    Ir a la página Red de VPC
  2. Haz clic en Crear red de VPC
  3. Ingresa un Nombre de lb-network.
  4. En la sección Subredes, realiza lo siguiente:
    • Configura el modo de creación de subred como Personalizado.
    • En la sección Subred nueva, 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 para 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.

PUBLICA https://www.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.

PUBICA https://www.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
}

PUBLICA https://www.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: una regla de entrada aplicable a todos los objetivos en la red de VPC, que permite el tráfico de las fuentes en los rangos 10.1.2.0/24 y 10.3.4.0/24. Esta regla permite el tráfico entrante de cualquier cliente ubicado en cualquiera de las dos subredes. Más tarde te permitirá configurar y probar el acceso global.

  • fw-allow-ssh: una regla de entrada, aplicable a las instancias con balanceo de cargas, 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. Ve a la página Firewall en Google Cloud Console.
    Ir a la página Firewall
  2. 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-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: IP ranges
    • Rangos de IP de origen: 10.1.2.0/24 y 10.3.4.0/24
    • Protocolos y puertos: permitir todos
  3. Haga clic en Crear.
  4. Vuelve a hacer clic en Crear regla de firewall para crear la regla que permita 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: IP ranges
    • Rangos de IP de origen: 0.0.0.0/0
    • Protocolos y puertos: elige Protocolos y puertos especificados y escribe: tcp:22
  5. Haga clic en Crear.
  6. Haz clic en Crear regla de firewall por tercera vez para crear la regla que permita 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: IP ranges
    • Rangos de IP 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.

PUBLICA https://www.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.

PUBLICA https://www.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.

PUBLICA https://www.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 tiene balanceo de cargas.

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

A cada una se le asigna una dirección IP interna en el lb-subnet y una dirección IP externa (pública) 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 preservando la IP de destino. Asegúrate de que el software del servidor que se ejecuta en las VM de backend esté escuchando en 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 en la dirección IP interna asociada con cada una. La dirección IP de destino de un paquete que un balanceador de cargas 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. Ve a la página Instancias de VM en Google Cloud Console.
    Ir a la página 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. Establece el Nombre como se indica en el paso 2.
  5. En Región, elige us-west1 y selecciona una 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 para las opciones de disco de arranque. Haz clic en Elegir para cambiar la imagen si es necesario.

  7. Haz clic en Administración, seguridad, discos, redes, instancia única 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 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

    • Haz clic en Administración. En el campo de 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
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

  8. Haz clic en Crear.

Crea grupos de instancias

  1. Ve a la página Grupos de instancias en Google Cloud Console.
    Ir a la página 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 Grupo de instancias no administrado nuevo.
  5. Configura Nombre como se indica en el paso 2.
  6. En la sección Ubicación, selecciona Zona única, elige us-west1 para la Región y, luego, elige una 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
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'

  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:

PUBLICA https://www.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/n1-standard-1",
  "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.

PUBLICA https://www.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"
}

PUBLICA https://www.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.

PUBLICA https://www.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"
    }
  ]
}

PUBLICA https://www.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 que 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. Ve a la página Instancias de VM en Google Cloud Console.
    Ir a la página Instancias de VM
  2. Haz clic en Crear instancia.
  3. Configura el campo Nombre como vm-client.
  4. Establece la Zona en 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.

PUBLICA https://www.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/n1-standard-1",
  "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 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 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 se crea 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. Haga clic en Crear balanceador de cargas.
  3. En Balanceo de cargas TCP, haz clic en Iniciar configuración.
  4. En Orientado a Internet o solo interno, selecciona Solo entre mis VM.
  5. Haga clic en Continue.
  6. Establece be-ilb como el Nombre.
  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 Elemento nuevo, selecciona el grupo de instancias ig-a y haz clic en Listo.
    4. Haga clic en Agregar backend. En la sección Elemento nuevo que aparece, selecciona el grupo de instancias ig-c y vuelve a hacer clic en Listo.
    5. 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: /
    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. Haga 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 Reservar una 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.1.2.99
    4. Puertos: Elige Múltiples y, luego, ingresa 80,8008,8080,8088 para 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. 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 \
    --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

  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 para 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 healthChecks.insert.

PUBLICA https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks

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

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

PUBLICA https://www.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/global/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.

PUBLICA https://www.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 tienen el siguiente aspecto: 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 los puertos 80, 8008, 8080 y 8088. Para enviar tráfico a esos otros puertos, agregue 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 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 a 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 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 balanceo de cargas) siempre reciben respuesta de la misma VM que realiza la solicitud.

El balanceo de cargas 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 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

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 TCP/UDP interno de ejemplo para que sea accesible a los clientes en todas las regiones. Los backends del balanceador de cargas de ejemplo deben ubicarse en una región (us-west1) de todos modos.

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

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

Console

Modificar la regla de reenvío del balanceador de cargas

  1. Ve a la página Balanceo de cargas en Google Cloud Console.
    Ir a la página 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. Haga clic en Configuración de frontend.

  4. Haz clic en el ícono de lápiz.

  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 del 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. Asegúrate de que la regla de reenvío permita el acceso global.

    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://www.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. Ve a la página Instancias de VM en Google Cloud Console.
    Ir a la página Instancias de VM
  2. Haz clic en Crear instancia.
  3. Configura el campo Nombre como vm-client2.
  4. Establece la Zona en 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.

PUBLICA https://www.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/n1-standard-1",
  "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 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 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.

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. Ve a la página Plantillas de instancias de VM en Google Cloud Console.
    Ir a la página Plantillas de instancias de VM
  2. Haga clic en Crear plantilla de instancias.
  3. Configura el campo Nombre como template-vm-ilb.
  4. Elige un tipo de máquina.
  5. Para Disco de arranque, haz clic en Cambiar, 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. Haga clic en Administración, seguridad, discos, 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
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

  8. Haz clic en Crear.

Grupo de instancias administrado

  1. Ve a la página Grupos de instancias de VM en Google Cloud Console.
    Ir a la página Grupos de instancias de VM
  2. Haz clic en Crear grupo de instancias.
  3. Establece ig-ilb como el Nombre.
  4. En Ubicación, elige Zona múltiple y establece la Región en us-west1.
  5. Establece la Plantilla de instancia 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 HTTP porque el grupo de instancias es un backend para el balanceo de cargas TCP/UDP interno.
  7. Establece la Cantidad mínima de instancias en 1 y la Cantidad máxima de instancias 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 TCP/UDP interno. En este ejemplo, usa hc-http-80.
  9. Haga 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
         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'

  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 en el 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 interno, puedes quitar sus direcciones IP externas. Quitar las direcciones IP externas evita que las VM de backend accedan a Internet de forma directa.

Console

  1. Ve a la página Instancias de VM en Google Cloud Console.
    Ir a la página 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 la página 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] con 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] con el nombre de la VM y [ZONE] con 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 con el nombre de la VM y us-west1-a con la zona de la VM.

PUBLICA https://www.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 el puerto o 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 que instala Apache también lo configura para aceptar conexiones HTTPS en los puertos 443 y 8443.

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

Este procedimiento te muestra cómo reemplazar la regla de reenvío de ejemplo del balanceador de cargas con 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 Balanceo de cargas TCP/UDP interno y reglas de reenvío con una dirección IP común.

Console

Borra tu regla de reenvío y crea una nueva

  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 tu balanceador de cargas de be-ilby haz clic en Editar.
  3. Haga 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. Haga 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 utilice la palabra clave ALL. Los otros 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 realizando una solicitud DELETE al método forwardingRules.delete.

BORRA https://www.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.

PUBLICA https://www.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 HTTPS en los puertos 443 y 8443. El indicador --insecure es obligatorio porque cada servidor de 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 distribuyen entre todas las VM de backend.

Acepta tráfico en múltiples puertos usando 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 que instala Apache también lo configura para aceptar conexiones HTTPS en los puertos 443 y 8443.

Una estrategia alternativa para configurar una sola regla de reenvío para aceptar el tráfico en todos los puertos es crear varias reglas de reenvío, cada una de las cuales admite cinco puertos o menos.

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

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

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 estática interna (reservada) para 10.1.2.99 y configura su marca --purpose en SHARED_LOADBALANCER_VIP. Se requiere el indicador --purpose para que dos reglas de reenvío internas puedan usar la misma dirección IP interna.

    gcloud beta 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 realizando una solicitud DELETE al método forwardingRules.delete.

BORRA https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/forwardingRules/fr-ilb

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

PUBLICA https://www.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 realizando dos solicitudes POST al método forwardingRules.insert.

PUBLICA https://www.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 HTTPS en los puertos 443 y 8443. El indicador --insecure es obligatorio porque cada servidor de 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 distribuyen 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.

Este procedimiento te muestra cómo actualizar el servicio de backend para el balanceador de cargas TCP/UDP interno de ejemplo, de modo que se use la afinidad de sesión basada en un hash creado a partir de las direcciones IP del cliente y la dirección IP de la regla de reenvío interno del balanceador de cargas.

Console

  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 be-ilb (el nombre del servicio de backend que creaste para este ejemplo) y haz clic 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 gcloud para actualizar el servicio de backend be-ilb y especificar 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.

APLICA UN PARCHE https://www.googleapis.com/compute/v1/projects/project-id/regions/us-west1/backendServices/be-ilb

{
  "sessionAffinity": "CLIENT_IP"
}

Si deseas obtener más información sobre el uso de la afinidad de sesión para influir en la distribución del tráfico, además de una descripción de cada opción, consulta la distribución de tráfico.

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.

Sujetos a las reglas de firewall, los clientes en cualquier subred de la región pueden contactar la dirección IP interna del balanceador de cargas TCP/UDP.

Console

Agrega la segunda subred

  1. Ve a la página Redes de VPC en Google Cloud Console.
    Ir a la página Red de VPC
  2. Haz clic en Crear red de VPC
  3. Haga clic en lb-network.
  4. En la sección Subredes, sigue estos pasos:
    • Haz clic en Agregar subred.
    • En la sección Subred nueva, ingresa la siguiente información:
      • Nombre: second-subnet
      • Región:: us-west1
      • Rangos de direcciones IP: 10.5.6.0/24
      • Haga clic en Add.

Agrega la segunda regla de reenvío

  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 tu balanceador de cargas de be-ilby haz clic en Editar.
  3. Haga 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 para 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.

PUBLICA https://www.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.

PUBLICA https://www.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 nueva regla de reenvío

  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 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 manejan las solicitudes, sin importar el protocolo (HTTP o HTTPS) o la dirección IP que se usa.

Qué sigue