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 Platform. 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 la red
Agregar y quitar reglas de firewall Administrador de seguridad
Crea instancias Administrador de instancias

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 de cliente para probar conexiones
  5. Los siguientes componentes internos del balanceador de cargas TCP/UDP:
    • 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:

Ejemplo de configuración de balanceo de cargas TCP/UDP interno (haz clic para ampliarlo)
Ejemplo de configuración de balanceo de cargas TCP/UDP interno (haz clic para ampliarlo)

Configura una red, una región y una subred

Necesitas una red de VPC con una subred como mínimo. Un balanceador de cargas TCP/UDP interno es regional. El tráfico dentro de la red de VPC se enruta al balanceador de cargas si su fuente proviene de una subred en la misma región que el balanceador.

En este ejemplo, se usan la red de VPC, la región y la subred que se describen a continuación:

  • Red: la red es una red de VPC de modo personalizado llamada lb-network.

  • Región: la región es us-west1.

  • Subred: lb-subnet, la subred, usa el rango de IP 10.1.2.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 Platform Console.
    Ir a la página Redes 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:
    • Establece 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
      • Rango de direcciones IP: 10.1.2.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

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

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

api

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

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks
{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

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

POST 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
}

Configura las reglas de firewall

En este ejemplo, se usan las siguientes reglas de firewall:

  • fw-allow-lb-subnet: una regla de entrada, aplicable a todos los objetivos en la red de VPC, que permite el tráfico de fuentes en el rango 10.1.2.0/24. Esta regla permite el tráfico entrante desde cualquier fuente dentro de lb-subnet a las instancias (VM) en las que se aplica el balanceo de cargas.

  • fw-allow-ssh: una regla de entrada, aplicable a las instancias en las que se realiza el 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 que iniciarás sesiones SSH. En este ejemplo, se usa la etiqueta de destino allow-ssh para identificar las VM a las que debe aplicarse.

  • fw-allow-health-check: una regla de entrada, aplicable a las instancias en las que se realiza el balanceo de cargas, que permite el tráfico de los sistemas de verificación de estado de GCP (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 se debe aplicar.

Sin estas reglas de firewall, la regla predeterminada de entrada denegada bloquea el tráfico entrante a las instancias de backend.

Console

  1. Ve a la página Reglas de firewall en Google Cloud Platform Console.
    Ir a la página Reglas de 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-subnet
    • 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 origen: IP ranges
    • Rangos de IP de origen: 10.1.2.0/24
    • Protocolos y puertos: permitir todos
  3. Haz clic en Crear.
  4. Haz clic en Crear regla de firewall de nuevo para crear la regla que permite 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 origen: 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. Haz clic en Crear.
  6. Haz clic en Crear regla de firewall por tercera vez a fin de crear la regla para permitir las verificaciones de estado de GCP:
    • 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 origen: 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-subnet para permitir la comunicación con la subred:

    gcloud compute firewall-rules create fw-allow-lb-subnet \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.1.2.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, GCP 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 GCP.

    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-subnet mediante una solicitud POST al método firewalls.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
{
  "name": "fw-allow-lb-subnet",
  "network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
  "priority": 1000,
  "sourceRanges": [
    "10.1.2.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://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.

POST 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. Cada una de las cuatro ejecuta un servidor web Apache en los puertos TCP 80 y 443. A cada uno se le asigna una dirección IP interna en 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 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 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 9.

Console

Crea VM de backend

  1. Ve a la página Instancias de VM en Google Cloud Platform 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. Para la Región, elige us-west1 y una Zona como se indica en el paso 2.
  6. En la sección Disco de arranque, asegúrate de que la imagen seleccionada sea Debian GNU/Linux 9 Stretch. 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 Secuencia de comandos de inicio, copia y pega el siguiente contenido de secuencia de comandos. El contenido de la 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
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2

  8. Haz clic en Crear.

Crea grupos de instancias

  1. Dirígete a la página Grupos de instancias en Google Cloud Platform 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. Establece Nombre como se indica en el paso 2.
  5. 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.
  6. En la sección Tipo de grupo, selecciona Grupo de instancias no administrado.
  7. En Red, ingresa lb-network.
  8. Para la 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. Ejecuta el siguiente comando cuatro veces a fin de crear las cuatro VM 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-9 \
    --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
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'

  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

Realiza cuatro solicitudes POST al método instances.insert para crear cuatro VM de backend:

POST 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-9-stretch-v20190618",
        "diskType": "projects/[PROJECT_ID]/zones/us-west1-a/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\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\nsystemctl restart apache2"
      }
    ]
  },
  "scheduling": {
    "preemptible": false
  },
  "deletionProtection": false
}

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

POST 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"
}

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

POST 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"
    }
  ]
}

POST 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 de 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 Platform Console.
    Ir a la página Instancias de VM
  2. Haz clic en Crear instancia.
  3. Establece el Nombre como vm-client.
  4. Configura la Zona como us-west1-a.
  5. Haz clic en Administración, seguridad, discos, redes, instancia única y realiza los siguientes cambios:
    • Haz clic en Herramientas de redes y agrega allow-ssh a las 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-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=lb-subnet

api

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

POST 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-NAME]",
      "initializeParams": {
        "sourceImage": "projects/debian-cloud/global/images/debian-9-stretch-v20190618",
        "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 10.1.2.99, una dirección IP interna, 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 de Google Cloud Platform Console.
    Ir a la página Balanceo de cargas
  2. Haz clic en Crear balanceador de cargas.
  3. En Balanceo de cargas TCP, haz clic en Iniciar configuración.
  4. En Orientado a Internet o solo interno, selecciona Solo entre mis VM.
  5. Haz clic en Continuar.
  6. Establece el 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 Elemento nuevo, selecciona el grupo de instancias ig-a y haz clic en Listo.
    4. Haz 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 proxy: NONE
      • Ruta de 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. 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: ilb-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 Individual y, luego, ingresa 80 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. 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 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 \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

api

Crea la verificación de estado mediante una solicitud POST al método healthChecks.insert.

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

POST 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
  }
}

Crea la regla de reenvío mediante una solicitud POST al método forwardingRules.insert.

POST 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"
  ],
  "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"
}

Realiza pruebas

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 con curl para contactar la 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 este aspecto: Page served from: vm-a1, Page served from: vm-a2 y demás.

    curl http://10.1.2.99

    • 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 observa que la respuesta se envía desde la VM de backend que realiza la solicitud. La respuesta esperada cuando se realiza la prueba desde vm-a1 es siempre la siguiente: 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 con opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes realizarlas en cualquier orden.

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. Dirígete a la página Plantillas de instancias de VM en Google Cloud Platform Console.
    Ir a la página Plantillas de instancias de VM
  2. Haz clic en Crear plantilla de instancias.
  3. Establece el Nombre como template-vm-ilb.
  4. Elige un tipo de máquina.
  5. En Disco de arranque, haz clic en Cambiar, elige Debian GNU/Linux 9 Stretch y, luego, haz clic en Seleccionar.
  6. Haz clic en Administración, seguridad, discos, herramientas de redes, instancia única.
    • 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 de Secuencia de comandos de inicio, copia y pega el siguiente contenido de secuencia de comandos. 
      #! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" 
      
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | 
      
tee /var/www/html/index.html
systemctl restart apache2
  7. Haz clic en Crear.

Grupo de instancias administrado

  1. Ve a la página Instancias de VM en Google Cloud Platform Console.
    Ir a la página Grupos de instancias de VM
  2. Haz clic en Crear grupo de instancias.
  3. Establece el Nombre como ig-ilb.
  4. En Ubicación, elige Zona múltiple y establece la Región en us-west1.
  5. Establece la 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 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. 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-9 \
    --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
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'

  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 Platform 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 la 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 se debe 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

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

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

Acepta tráfico en múltiples puertos

El componente que controla el puerto para el tráfico entrante es la regla de reenvío interno. En este procedimiento, se muestra cómo reemplazar la regla de reenvío para el puerto 80 por una que acepte tráfico en los puertos 80 y 443. Cuando creas las VM de backend, la secuencia de comandos de inicio que instala y configura Apache también lo configura para entregar tráfico HTTPS en el puerto 443. Debes reemplazar una regla de reenvío porque GCP no admite la actualización de reglas de reenvío.

gcloud

  1. Borra tu 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 para los puertos 80 y 443. Los otros parámetros para esta regla, incluida la dirección IP y el servicio de backend, son 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=80,443 \
    --backend-service=be-ilb \
    --backend-service-region=us-west1

  3. 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:

      curl http://10.1.2.99

    • Prueba la conectividad HTTPS. La marca --insecure es obligatoria porque la configuración del servidor Apache en la configuración de ejemplo usa certificados autofirmados.

      curl https://10.1.2.99 --insecure

    • Observa que todas las VM de backend controlan las solicitudes HTTP (en el puerto 80) y HTTPS (en el puerto 443).

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 TCP/UDP interno de ejemplo a fin de que use la afinidad de sesión basada en las direcciones IP de cliente.

El balanceador de cargas dirige las solicitudes de un cliente particular a la misma VM de backend según un hash creado a partir de la dirección IP del cliente y la del balanceador de cargas (la dirección IP interna de una regla de reenvío interno).

Console

  1. Ve a la página Balanceo de cargas de Google Cloud Platform 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 de gcloud para actualizar el servicio de backend be-ilb y especifica la afinidad de sesión de la IP de cliente:

gcloud compute backend-services update be-ilb \
    --session-affinity CLIENT_IP

api

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

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

  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 para esta regla, incluido el servicio de backend y la dirección IP, son los mismos que usa 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

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

Próximos pasos

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Esta página
Comentarios sobre la documentación
Balanceo de cargas
Comentarios sobre el producto