Configurar un balanceador de carga de aplicación interno entre regiones con backends de grupos de instancias de VM

En este documento se proporcionan instrucciones para configurar un balanceador de carga de aplicaciones interno multirregional para los servicios que se ejecutan en instancias de máquina virtual de Compute Engine.

Antes de empezar

Antes de seguir esta guía, familiarízate con lo siguiente:

Configurar un recurso de certificado SSL

Crea un recurso de certificado SSL de Certificate Manager tal como se describe en los siguientes artículos:

Te recomendamos que uses un certificado gestionado por Google.

Permisos

Para seguir esta guía, debes poder crear instancias y modificar una red en un proyecto. Debes ser propietario o editor del proyecto, o bien tener todos los roles de gestión de identidades y accesos de Compute Engine que se indican a continuación.

Tarea Rol necesario
Crear redes, subredes y componentes de balanceador de carga Administrador de red de Compute
Añadir y eliminar reglas de cortafuegos Administrador de seguridad de Compute
Crear instancias Administrador de instancias de Compute

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

Descripción general de la configuración

Puede configurar el balanceador de carga como se muestra en el siguiente diagrama:

Despliegue de alta disponibilidad de balanceadores de carga de aplicación internos entre regiones.
Implementación de alta disponibilidad de balanceador de carga de aplicación interno entre regiones (haz clic para ampliar).

Como se muestra en el diagrama, en este ejemplo se crea un balanceador de carga de aplicaciones interno entre regiones en una red de VPC, con un servicio de backend y dos grupos de instancias gestionados de backend en las regiones REGION_A y REGION_B.

En el diagrama se muestra lo siguiente:

  1. Una red de VPC con las siguientes subredes:

    • Subred SUBNET_A y una subred de solo proxy en REGION_A.
    • Subred SUBNET_B y una subred de solo proxy en REGION_B.

    Debes crear subredes de solo proxy en cada región de una red de VPC en la que uses balanceadores de carga de aplicación internos entre regiones. La subred de solo proxy de la región se comparte entre todos los balanceadores de carga de aplicaciones internos entre regiones de la región. Las direcciones de origen de los paquetes enviados desde el balanceador de carga a los backends de tu servicio se asignan desde la subred solo proxy. En este ejemplo, la subred solo proxy de la región REGION_A tiene un intervalo de direcciones IP principal de 10.129.0.0/23 y la de REGION_B tiene un intervalo de direcciones IP principal de 10.130.0.0/23, que es el tamaño de subred recomendado.

  2. La configuración de alta disponibilidad tiene backends de grupos de instancias gestionados para las implementaciones de máquinas virtuales de Compute Engine en las regiones REGION_A y REGION_B. Si los backends de una región no funcionan, el tráfico se redirige a la otra región.

  3. Un servicio de backend global que monitoriza el uso y el estado de los backends.

  4. Un mapa de URLs global que analiza la URL de una solicitud y reenvía las solicitudes a servicios de backend específicos en función del host y la ruta de la URL de la solicitud.

  5. Un proxy HTTP o HTTPS de destino global recibe una solicitud del usuario y la reenvía al mapa de URLs. En el caso de HTTPS, configura un recurso de certificado SSL global. El proxy de destino usa el certificado SSL para descifrar el tráfico SSL si configuras el balanceo de carga HTTPS. El proxy de destino puede reenviar tráfico a tus instancias mediante HTTP o HTTPS.

  6. Las reglas de reenvío globales tienen la dirección IP interna regional de tu balanceador de carga para reenviar cada solicitud entrante al proxy de destino.

    La dirección IP interna asociada a la regla de reenvío puede proceder de una subred de la misma red y región que los backends. Ten en cuenta las siguientes condiciones:

    • La dirección IP puede (pero no tiene por qué) proceder de la misma subred que los grupos de instancias de backend.
    • La dirección IP no debe proceder de una subred reservada de solo proxy que tenga el valor GLOBAL_MANAGED_PROXY en su marca --purpose.
    • Si quieres usar la misma dirección IP interna con varias reglas de reenvío, define el valor de la marca de dirección IP --purpose como SHARED_LOADBALANCER_VIP.
  7. Opcional: configura políticas de enrutamiento de DNS de tipo GEO para enrutar el tráfico de los clientes a la dirección IP virtual del balanceador de carga en la región más cercana al cliente.

Configurar la red y las subredes

En la red de VPC, configura una subred en cada región en la que estén configurados tus back-ends. Además, configura una proxy-only-subnet en cada región en la que quieras configurar el balanceador de carga.

En este ejemplo se usan la siguiente red VPC, región y subredes:

  • Red La red es una red de VPC en modo personalizado llamada NETWORK.

  • Subredes para back-ends.

    • Una subred llamada SUBNET_A en la región REGION_A usa 10.1.2.0/24 para su intervalo de IPs principal.
    • Una subred llamada SUBNET_B en la región REGION_B usa 10.1.3.0/24 para su intervalo de IPs principal.
  • Subredes para proxies.

    • Una subred llamada PROXY_SN_A en la región REGION_A usa 10.129.0.0/23 para su intervalo de IP principal.
    • Una subred llamada PROXY_SN_B en la región REGION_B usa 10.130.0.0/23 como intervalo de IP principal.

Se puede acceder a los balanceadores de carga de aplicaciones internos entre regiones desde cualquier región de la VPC. De esta forma, los clientes de cualquier región pueden acceder a los backends de tu balanceador de carga a nivel mundial.

Configurar las subredes de backend

Consola

  1. En la Google Cloud consola, ve a la página Redes de VPC.

    Ir a redes de VPC

  2. Haz clic en Crear red VPC.

  3. Asigne un nombre a la red.

  4. En la sección Subredes, selecciona Personalizado en Modo de creación de subredes.

  5. Crea una subred para los back-ends del balanceador de carga. En la sección Nueva subred, introduce la siguiente información:

    • Asigna un nombre a la subred.
    • Selecciona una región: REGION_A
    • Introduce un intervalo de direcciones IP: 10.1.2.0/24
  6. Haz clic en Listo.

  7. Haz clic en Añadir subred.

  8. Crea una subred para los back-ends del balanceador de carga. En la sección Nueva subred, introduce la siguiente información:

    • Asigna un nombre a la subred.
    • Selecciona una región: REGION_B
    • Introduce un intervalo de direcciones IP: 10.1.3.0/24
  9. Haz clic en Listo.

  10. Haz clic en Crear.

gcloud

  1. Crea la red de VPC personalizada con el comando gcloud compute networks create:

    gcloud compute networks create NETWORK \
        --subnet-mode=custom
    
  2. Crea una subred en la red NETWORK de la región REGION_A con el comando gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_A \
        --network=NETWORK \
        --range=10.1.2.0/24 \
        --region=REGION_A
    
  3. Crea una subred en la red NETWORK de la región REGION_B con el comando gcloud compute networks subnets create:

    gcloud compute networks subnets create SUBNET_B \
        --network=NETWORK \
        --range=10.1.3.0/24 \
        --region=REGION_B
    

Terraform

Para crear la red de VPC, usa el recurso google_compute_network.

resource "google_compute_network" "default" {
  auto_create_subnetworks = false
  name                    = "lb-network-crs-reg"
  provider                = google-beta
}

Para crear las subredes de VPC en la red lb-network-crs-reg, usa el recurso google_compute_subnetwork.

resource "google_compute_subnetwork" "subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.1.2.0/24"
  name          = "lbsubnet-uswest1"
  network       = google_compute_network.default.id
  region        = "us-west1"
}
resource "google_compute_subnetwork" "subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.1.3.0/24"
  name          = "lbsubnet-useast1"
  network       = google_compute_network.default.id
  region        = "us-east1"
}

API

Realiza una solicitud POST al método networks.insert. Sustituye PROJECT_ID por el ID de tu proyecto.

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

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Realiza una solicitud POST al método subnetworks.insert. Sustituye PROJECT_ID por el ID de tu proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/lb-network-crs-reg",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

Realiza una solicitud POST al método subnetworks.insert. Sustituye PROJECT_ID por el ID de tu proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Configurar la subred de solo proxy

Una subred de solo proxy proporciona un conjunto de direcciones IP que Google Cloud usa para ejecutar proxies de Envoy en tu nombre. Los proxies terminan las conexiones del cliente y crean nuevas conexiones con los back-ends.

Todos los balanceadores de carga regionales basados en Envoy de la misma región que la red de VPC usan esta subred de solo proxy. Solo puede haber una subred solo proxy activa para un propósito determinado por región y por red.

Consola

Si usas la consola de Google Cloud , puedes esperar y crear la subred de solo proxy más adelante en la página Balanceo de carga.

Si quieres crear la subred de solo proxy ahora, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Redes de VPC.

    Ir a redes de VPC

  2. Haga clic en el nombre de la red VPC.
  3. En la pestaña Subred, haz clic en Añadir subred.
  4. Asigna un nombre a la subred de solo proxy.
  5. Selecciona una región: REGION_A
  6. En la lista Propósito, selecciona Proxy gestionado entre regiones.
  7. En el campo Intervalo de direcciones IP, introduce 10.129.0.0/23.
  8. Haz clic en Añadir.

Crea la subred de solo proxy en REGION_B

  1. En la pestaña Subred, haz clic en Añadir subred.
  2. Asigna un nombre a la subred de solo proxy.
  3. Selecciona una región: REGION_B
  4. En la lista Propósito, selecciona Proxy gestionado entre regiones.
  5. En el campo Intervalo de direcciones IP, introduce 10.130.0.0/23.
  6. Haz clic en Añadir.

gcloud

Crea las subredes de solo proxy con el comando gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23
    

Terraform

Para crear la subred de solo proxy de la VPC en la red lb-network-crs-reg, usa el recurso google_compute_subnetwork.

resource "google_compute_subnetwork" "proxy_subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.129.0.0/23"
  name          = "proxy-only-subnet1"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-west1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}
resource "google_compute_subnetwork" "proxy_subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.130.0.0/23"
  name          = "proxy-only-subnet2"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-east1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

API

Crea las subredes de solo proxy con el método subnetworks.insert. Sustituye PROJECT_ID por el ID de tu proyecto.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": " PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   

Configurar reglas de cortafuegos

En este ejemplo se usan las siguientes reglas de cortafuegos:

  • fw-ilb-to-backends. Una regla de entrada, aplicable a las instancias que se van a balancear, que permite la conectividad SSH entrante en el puerto TCP 22 desde cualquier dirección. Puedes elegir un intervalo de direcciones IP de origen más restrictivo para esta regla. Por ejemplo, puedes especificar solo los intervalos de direcciones IP del sistema desde el que inicias sesiones SSH. En este ejemplo se usa la etiqueta de destino allow-ssh para identificar las VMs a las que se aplica la regla de cortafuegos.

  • fw-healthcheck. Una regla de entrada, aplicable a las instancias que se están balanceando de carga, que permite todo el tráfico TCP de los sistemas de comprobación del estado (en 130.211.0.0/22 y 35.191.0.0/16). En este ejemplo se usa la etiqueta de destino load-balanced-backend para identificar las VMs a las que se aplica la regla de cortafuegos. Google Cloud

  • fw-backends. Una regla de entrada, aplicable a las instancias que se van a balancear, que permite el tráfico TCP en los puertos 80, 443 y 8080 desde los proxies gestionados del balanceador de carga de aplicaciones interno. En este ejemplo se usa la etiqueta de destino load-balanced-backend para identificar las VMs a las que se aplica la regla de cortafuegos.

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

Las etiquetas de destino definen las instancias de backend. Si no se incluyen las etiquetas de destino, las reglas de cortafuegos se aplican a todas las instancias de backend de la red de VPC. Cuando crees las VMs de backend, asegúrate de incluir las etiquetas de destino especificadas, tal como se muestra en Crear un grupo de instancias gestionado.

Consola

  1. En la Google Cloud consola, ve a la página Políticas de cortafuegos.

    Ir a Políticas de cortafuegos

  2. Haz clic en Crear regla de cortafuegos para crear la regla que permita las conexiones SSH entrantes:

    • Nombre: fw-ilb-to-backends
    • Red: NETWORK
    • Sentido del tráfico: entrada
    • Acción tras coincidencia: Permitir
    • Objetivos: Etiquetas de destino especificadas
    • Etiquetas de destino: allow-ssh
    • Filtro de origen: Intervalos de IPv4
    • Intervalos de IPv4 de origen: 0.0.0.0/0
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla TCP y, a continuación, introduce 22 como número de puerto.
  3. Haz clic en Crear.

  4. Vuelve a hacer clic en Crear regla de cortafuegos para crear la regla que permita las comprobaciones del estado deGoogle Cloud :

    • Nombre: fw-healthcheck
    • Red: NETWORK
    • Sentido del tráfico: entrada
    • Acción tras coincidencia: Permitir
    • Objetivos: Etiquetas de destino especificadas
    • Etiquetas de destino: load-balanced-backend
    • Filtro de origen: Intervalos de IPv4
    • Intervalos de IPv4 de origen: 130.211.0.0/22 y 35.191.0.0/16
    • Protocolos y puertos:

      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla TCP y, a continuación, introduce 80 como número de puerto.

      Como práctica recomendada, limita esta regla a los protocolos y puertos que coincidan con los que usa tu comprobación del estado. Si usas tcp:80 para el protocolo y el puerto, Google Cloud puede usar HTTP en el puerto 80 para ponerse en contacto con tus VMs, pero no puede usar HTTPS en el puerto 443 para hacerlo.

  5. Haz clic en Crear.

  6. Haz clic en Crear regla de cortafuegos por tercera vez para crear la regla que permita que los servidores proxy del balanceador de carga se conecten a los backends:

    • Nombre: fw-backends
    • Red: NETWORK
    • Sentido del tráfico: entrada
    • Acción tras coincidencia: Permitir
    • Objetivos: Etiquetas de destino especificadas
    • Etiquetas de destino: load-balanced-backend
    • Filtro de origen: Intervalos de IPv4
    • Intervalos de IPv4 de origen: 10.129.0.0/23 y 10.130.0.0/23
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla TCP y, a continuación, introduce 80, 443, 8080 en los números de puerto.
  7. Haz clic en Crear.

gcloud

  1. Crea la regla de cortafuegos fw-ilb-to-backends para permitir la conectividad SSH a las VMs con la etiqueta de red allow-ssh. Si omite source-ranges, Google Cloud interpreta que la regla se aplica a cualquier fuente.

    gcloud compute firewall-rules create fw-ilb-to-backends \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. Crea la regla fw-healthcheck para permitir Google Cloud las comprobaciones del estado. En este ejemplo, se permite todo el tráfico TCP de los verificadores de comprobación del estado. Sin embargo, puede configurar un conjunto de puertos más reducido para satisfacer sus necesidades.

    gcloud compute firewall-rules create fw-healthcheck \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --target-tags=load-balanced-backend \
        --rules=tcp
    
  3. Cree la regla fw-backends para permitir que los proxies del balanceador de carga de aplicaciones interno se conecten a sus backends. Define source-ranges en los intervalos asignados de tu subred de solo proxy, por ejemplo, 10.129.0.0/23 y 10.130.0.0/23.

    gcloud compute firewall-rules create fw-backends \
        --network=NETWORK \
        --action=allow \
        --direction=ingress \
        --source-ranges=source-range \
        --target-tags=load-balanced-backend \
        --rules=tcp:80,tcp:443,tcp:8080
    

Terraform

Para crear las reglas de cortafuegos, usa el recurso google_compute_firewall.

resource "google_compute_firewall" "fw_healthcheck" {
  name          = "gl7-ilb-fw-allow-hc"
  provider      = google-beta
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16", "35.235.240.0/20"]
  allow {
    protocol = "tcp"
  }
}
resource "google_compute_firewall" "fw_ilb_to_backends" {
  name          = "fw-ilb-to-fw"
  provider      = google-beta
  network       = google_compute_network.default.id
  source_ranges = ["0.0.0.0/0"]
  allow {
    protocol = "tcp"
    ports    = ["22", "80", "443", "8080"]
  }
}
resource "google_compute_firewall" "fw_backends" {
  name          = "gl7-ilb-fw-allow-ilb-to-backends"
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["10.129.0.0/23", "10.130.0.0/23"]
  target_tags   = ["http-server"]
  allow {
    protocol = "tcp"
    ports    = ["80", "443", "8080"]
  }
}

API

Crea la regla de cortafuegos fw-ilb-to-backends haciendo una solicitud POST al método firewalls.insert y sustituyendo PROJECT_ID por el ID de tu proyecto.

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

{
 "name": "fw-ilb-to-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

Crea la regla de cortafuegos fw-healthcheck haciendo una solicitud POST al método firewalls.insert y sustituyendo PROJECT_ID por el ID de tu proyecto.

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

{
 "name": "fw-healthcheck",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

Crea la regla de cortafuegos fw-backends para permitir el tráfico TCP en la subred de proxy del método firewalls.insert. Sustituye PROJECT_ID por el ID de tu proyecto.

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

{
 "name": "fw-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "10.129.0.0/23",
   "10.130.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

Crear un grupo de instancias gestionado

En esta sección se muestra cómo crear una plantilla y un grupo de instancias gestionado. El grupo de instancias gestionado proporciona instancias de VM que ejecutan los servidores backend de un balanceador de carga de aplicaciones interno entre regiones de ejemplo. En tu grupo de instancias, puedes definir un servicio HTTP y asignar un nombre de puerto al puerto correspondiente. El servicio de backend del balanceador de carga reenvía el tráfico a los puertos con nombre. El tráfico de los clientes se balancea entre los servidores de backend. Para fines de demostración, los backends sirven sus propios nombres de host.

Consola

  1. En la Google Cloud consola, ve a la página Plantillas de instancia.

    Ir a Plantillas de instancia

    1. Haz clic en Crear plantilla de instancia.
    2. En Nombre, escribe gil7-backendeast1-template.
    3. Asegúrate de que el disco de arranque esté configurado con una imagen de Debian, como Debian GNU/Linux 12 (bookworm). En estas instrucciones se usan comandos que solo están disponibles en Debian, como apt-get.
    4. Haz clic en Advanced options (Opciones avanzadas).
    5. Haga clic en Redes y configure los siguientes campos:
      1. En Etiquetas de red, introduce allow-ssh y load-balanced-backend.
      2. En Interfaces de red, selecciona lo siguiente:
        • Red: NETWORK
        • Subred: SUBNET_B
    6. Haz clic en Gestión. Introduce la siguiente secuencia de comandos en el campo Secuencia de comandos de inicio.

      #! /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.

    8. Haz clic en Crear plantilla de instancia.

    9. En Nombre, escribe gil7-backendwest1-template.

    10. Asegúrate de que el disco de arranque esté configurado con una imagen de Debian, como Debian GNU/Linux 12 (bookworm). En estas instrucciones se usan comandos que solo están disponibles en Debian, como apt-get.

    11. Haz clic en Advanced options (Opciones avanzadas).

    12. Haga clic en Redes y configure los siguientes campos:

      1. En Etiquetas de red, introduce allow-ssh y load-balanced-backend.
      2. En Interfaces de red, selecciona lo siguiente:
        • Red: NETWORK
        • Subred: SUBNET_A
    13. Haz clic en Gestión. Introduce la siguiente secuencia de comandos en el campo Secuencia de comandos de inicio.

      #! /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
      
    14. Haz clic en Crear.

  2. En la consola, ve a la página Grupos de instancias. Google Cloud

    Ir a Grupos de instancias

    1. Haz clic en Crear grupo de instancias.
    2. Selecciona Nuevo grupo de instancias gestionado (sin reconocimiento del estado). Para obtener más información, consulta Grupos de instancias gestionados con o sin reconocimiento del estado.
    3. En Nombre, escribe gl7-ilb-mig-a.
    4. En Ubicación, selecciona Una sola zona.
    5. En Región, selecciona REGION_A.
    6. En Zona, selecciona ZONE_A.
    7. En Plantilla de instancia, selecciona gil7-backendwest1-template.
    8. Especifica el número de instancias que quieres crear en el grupo.

      En este ejemplo, especifica las siguientes opciones en Escalado automático:

      • En Modo de autoescalado, selecciona Off:do not autoscale.
      • En Número máximo de instancias, introduce 2.

      Opcionalmente, en la sección Autoescalado de la interfaz de usuario, puede configurar el grupo de instancias para que añada o elimine instancias automáticamente en función del uso de la CPU de las instancias.

    9. Haz clic en Crear.

    10. Haz clic en Crear grupo de instancias.

    11. Selecciona Nuevo grupo de instancias gestionado (sin reconocimiento del estado). Para obtener más información, consulta Grupos de instancias gestionados con o sin reconocimiento del estado.

    12. En Nombre, escribe gl7-ilb-mig-b.

    13. En Ubicación, selecciona Una sola zona.

    14. En Región, selecciona REGION_B.

    15. En Zona, selecciona ZONE_B.

    16. En Plantilla de instancia, selecciona gil7-backendeast1-template.

    17. Especifica el número de instancias que quieres crear en el grupo.

      En este ejemplo, especifica las siguientes opciones en Escalado automático:

      • En Modo de autoescalado, selecciona Off:do not autoscale.
      • En Número máximo de instancias, introduce 2.

      Opcionalmente, en la sección Auto escalado de la interfaz de usuario, puede configurar el grupo de instancias para que añada o elimine instancias automáticamente en función del uso de la CPU de las instancias.

    18. Haz clic en Crear.

gcloud

Las instrucciones de la CLI de gcloud de esta guía presuponen que usas Cloud Shell u otro entorno con bash instalado.

  1. Crea una plantilla de instancia de VM con un servidor HTTP con el comando gcloud compute instance-templates create.

    gcloud compute instance-templates create gil7-backendwest1-template \
      --region=REGION_A \
      --network=NETWORK \
      --subnet=SUBNET_A \
      --tags=allow-ssh,load-balanced-backend \
      --image-family=debian-12 \
      --image-project=debian-cloud \
      --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'
    
    gcloud compute instance-templates create gil7-backendeast1-template \
        --region=REGION_B \
        --network=NETWORK \
        --subnet=SUBNET_B \
        --tags=allow-ssh,load-balanced-backend \
        --image-family=debian-12 \
        --image-project=debian-cloud \
        --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 gestionado en la zona con el comando gcloud compute instance-groups managed create.

    gcloud compute instance-groups managed create gl7-ilb-mig-a \
        --zone=ZONE_A \
        --size=2 \
        --template=gil7-backendwest1-template
    
    gcloud compute instance-groups managed create gl7-ilb-mig-b \
        --zone=ZONE_B \
        --size=2 \
        --template=gil7-backendeast1-template
    

Terraform

Para crear la plantilla de instancia, usa el recurso google_compute_instance_template.

resource "google_compute_instance_template" "instance_template_a" {
  name         = "gil7-backendwest1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-west1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_a.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}
resource "google_compute_instance_template" "instance_template_b" {
  name         = "gil7-backendeast1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-east1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_b.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}

Para crear el grupo de instancias gestionado, usa el recurso google_compute_instance_group_manager.

resource "google_compute_region_instance_group_manager" "mig_a" {
  name     = "gl7-ilb-miga"
  provider = google-beta
  region   = "us-west1"
  version {
    instance_template = google_compute_instance_template.instance_template_a.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}
resource "google_compute_region_instance_group_manager" "mig_b" {
  name     = "gl7-ilb-migb"
  provider = google-beta
  region   = "us-east1"
  version {
    instance_template = google_compute_instance_template.instance_template_b.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}

API

Crea la plantilla de instancia con el método instanceTemplates.insert y sustituye PROJECT_ID por el ID de tu proyecto.

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

{
  "name":"gil7-backendwest1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_A/subnetworks/SUBNET_A",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

Crea un grupo de instancias gestionadas en cada zona con el método instanceGroupManagers.insert. Sustituye PROJECT_ID por el ID de tu proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl7-ilb-mig-a",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil7-backendwest1-template",
  "baseInstanceName": "gl7-ilb-mig-b",
  "targetSize": 2
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates

{
  "name":"gil7-backendeast1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

Crea un grupo de instancias gestionadas en cada zona con el método instanceGroupManagers.insert. Sustituye PROJECT_ID por el ID de tu proyecto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl7-ilb-mig-b",
  "zone": "projects/PROJECT_ID/zones/ZONE_B",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil7-backendwest1-template",
  "baseInstanceName": "gl7-ilb-mig-b",
  "targetSize": 2
}

Configurar el balanceador de carga

En este ejemplo se muestra cómo crear los siguientes recursos de balanceador de carga de aplicaciones interno entre regiones:

  • Una comprobación del estado de HTTP global.
  • Un servicio de backend global con los grupos de instancias gestionados como backend.
  • Una asignación de URLs. Asegúrate de hacer referencia a un mapa de URLs global para el proxy HTTP(S) de destino. Un mapa de URLs global enruta las solicitudes a un servicio de backend global en función de las reglas que definas para el host y la ruta de una URL entrante. Una regla de proxy de destino global puede hacer referencia a un mapa de URLs global.
  • Un certificado SSL global (para HTTPS).
  • Un proxy de destino global.
  • Dos reglas de reenvío globales con direcciones IP regionales. En la dirección IP de la regla de reenvío, usa el intervalo de direcciones IP SUBNET_A o SUBNET_B. Si intentas usar la subred de solo proxy, no se podrá crear la regla de reenvío.

Consola

Selecciona el tipo de balanceador de carga

  1. En la Google Cloud consola, ve a la página Balanceo de carga.

    Ir a Balanceo de carga

  2. Haga clic en Crear balanceador de carga.
  3. En Tipo de balanceador de carga, selecciona Balanceador de carga de aplicación (HTTP/HTTPS) y haz clic en Siguiente.
  4. En Público o interno, selecciona Interno y haz clic en Siguiente.
  5. En Implementación en una sola región o en varias regiones, selecciona La mejor opción para cargas de trabajo entre regiones y haz clic en Siguiente.
  6. Haz clic en Configurar.

Configuración básica

  1. Asigna un nombre al balanceador de carga.
  2. En Red, selecciona NETWORK.

Configurar el frontend con dos reglas de reenvío

Para HTTP:

  1. Haz clic en Configuración de frontend.
    1. Asigne un nombre a la regla de reenvío.
    2. En la lista Región de la subred, selecciona REGION_A.

      Reservar una subred de solo proxy

    3. En la lista Subred, selecciona SUBNET_A.
    4. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
      • Asigna un nombre a la dirección IP estática.
      • En la lista Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, introduce 10.1.2.99.
      • Selecciona Reservar.
  2. Haz clic en Listo.
  3. Para añadir la segunda regla de reenvío, haz clic en Añadir IP y puerto de frontend.
    1. Asigne un nombre a la regla de reenvío.
    2. En la lista Región de la subred, selecciona REGION_B.

      Reservar una subred de solo proxy

    3. En la lista Subred, selecciona SUBNET_B.
    4. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
      • Asigna un nombre a la dirección IP estática.
      • En la lista Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, introduce 10.1.3.99.
      • Selecciona Reservar.
  4. Haz clic en Listo.

En el caso de HTTPS:

Si usas HTTPS entre el cliente y el balanceador de carga, necesitas uno o varios recursos de certificado SSL para configurar el proxy. Para crear un all-regions certificado gestionado por Google, consulta la siguiente documentación:

Una vez que hayas creado el certificado gestionado por Google, adjunta el certificado directamente al proxy de destino. Los balanceadores de carga de aplicaciones internos entre regiones no admiten mapas de certificados.

Para crear un certificado all-regions autogestionado, consulta la siguiente documentación: Desplegar un certificado autogestionado regional.

  1. Haz clic en Configuración de frontend.
    1. Asigne un nombre a la regla de reenvío.
    2. En el campo Protocol (Protocolo), selecciona HTTPS (includes HTTP/2).
    3. Asegúrate de que el Puerto esté configurado como 443.
    4. En la lista Región de la subred, selecciona REGION_A.

      Reservar una subred de solo proxy

    5. En la lista Subred, selecciona SUBNET_A.
    6. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
      • Asigna un nombre a la dirección IP estática.
      • En la lista Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, introduce 10.1.3.99.
      • Selecciona Reservar.
    7. En la sección Añadir certificado, selecciona el certificado.
    8. Opcional: Para añadir certificados además del certificado SSL principal, sigue estos pasos:
      1. Haz clic en Añadir certificado.
      2. Selecciona el certificado de la lista.
    9. Selecciona una política de SSL de la lista Política de SSL. Si no has creado ninguna política de SSL, se aplicará una política de SSL predeterminada Google Cloud .
    10. Haz clic en Listo.

    Añade la segunda configuración de frontend:

    1. Asigna un nombre a la configuración del frontend.
    2. En el campo Protocol (Protocolo), selecciona HTTPS (includes HTTP/2).
    3. Asegúrate de que el Puerto esté configurado como 443.
    4. En la lista Región de la subred, selecciona REGION_B.

      Reservar una subred de solo proxy

    5. En la lista Subred, selecciona SUBNET_B.
    6. En la lista Dirección IP, haz clic en Crear dirección IP. Se abrirá la página Reservar una dirección IP interna estática.
      • Asigna un nombre a la dirección IP estática.
      • En la lista Dirección IP estática, selecciona Permitirme elegir.
      • En el campo Dirección IP personalizada, introduce 10.1.3.99.
      • Selecciona Reservar.
    7. En la sección Añadir certificado, selecciona el certificado.
    8. Opcional: Para añadir certificados además del certificado SSL principal, sigue estos pasos:
      1. Haz clic en Añadir certificado.
      2. Selecciona el certificado de la lista.
    9. Selecciona una política de SSL de la lista Política de SSL. Si no has creado ninguna política de SSL, se aplicará una política de SSL predeterminada Google Cloud .
    10. Haz clic en Listo.
    Configurar el servicio de backend
    1. Haz clic en Configuración de backend.
    2. En la lista Crear o seleccionar servicios de backend, haz clic en Crear un servicio de backend.
    3. Asigna un Nombre al servicio de backend.
    4. En Protocol (Protocolo), selecciona HTTP.
    5. En Puerto con nombre, introduce http.
    6. En la lista Tipo de backend, selecciona Grupo de instancias.
    7. En la sección Nuevo backend:
      • En la lista Grupo de instancias, selecciona gl4-ilb-miga en REGION_A.
      • Define Port numbers (Transferir números) en 80.
      • Haz clic en Listo.
      • Para añadir otro backend, haz clic en Añadir backend.
      • En la lista Grupo de instancias, selecciona gl4-ilb-migb en REGION_B.
      • Define Port numbers (Transferir números) en 80.
      • Haz clic en Listo.
    8. En la lista Comprobación del estado, haga clic en Crear una comprobación del estado.
      • En el campo Name (Nombre), introduce global-http-health-check.
      • Define Protocol (Protocolo) como HTTP.
      • Define Puerto como 80.
      • Haz clic en Guardar.

    Configurar las reglas de enrutamiento

    1. Haz clic en Reglas de enrutamiento.
    2. En Modo, selecciona Regla sencilla de host y ruta.
    3. Asegúrate de que solo haya un servicio de backend para cualquier host y cualquier ruta sin coincidencia.

    Revisar la configuración

    1. Haz clic en Revisar y finalizar.
    2. Revisa los ajustes de configuración de tu balanceador de carga.
    3. Haz clic en Crear.

gcloud

  1. Define la comprobación del estado de HTTP con el comando gcloud compute health-checks create http.

    gcloud compute health-checks create http global-http-health-check \
       --use-serving-port \
       --global
    
  2. Define el servicio backend con el comando gcloud compute backend-services create.

    gcloud compute backend-services create BACKEND_SERVICE_NAME \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --enable-logging \
      --logging-sample-rate=1.0 \
      --health-checks=global-http-health-check \
      --global-health-checks \
      --global
    
  3. Añade backends al servicio de backend con el comando gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --balancing-mode=UTILIZATION \
      --instance-group=gl7-ilb-mig-a \
      --instance-group-zone=ZONE_A \
      --global
    
    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
      --balancing-mode=UTILIZATION \
      --instance-group=gl7-ilb-mig-b \
      --instance-group-zone=ZONE_B \
      --global
    
  4. Crea el mapa de URLs con el comando gcloud compute url-maps create.

    gcloud compute url-maps create gl7-gilb-url-map \
      --default-service=BACKEND_SERVICE_NAME \
      --global
    
  5. Crea el proxy de destino.

    En HTTP:

    Crea el proxy de destino con el comando gcloud compute target-http-proxies create.

    gcloud compute target-http-proxies create gil7-http-proxy \
      --url-map=gl7-gilb-url-map \
      --global
    

    Para HTTPS:

    Para crear un certificado gestionado por Google, consulta la siguiente documentación:

    Una vez que hayas creado el certificado gestionado por Google, adjúntalo directamente al proxy de destino. Los balanceadores de carga de aplicaciones internos entre regiones no admiten mapas de certificados.

    Para crear un certificado autogestionado, consulta la siguiente documentación:

    Asigna las rutas de los archivos a nombres de variables.

    export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
    
    export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE
    

    Crea un certificado SSL de todas las regiones con el comando gcloud beta certificate-manager certificates create.

    gcloud certificate-manager certificates create gilb-certificate \
      --private-key-file=$LB_PRIVATE_KEY \
      --certificate-file=$LB_CERT \
      --scope=all-regions
    

    Usa el certificado SSL para crear un proxy de destino con el comando gcloud compute target-https-proxies create.

    gcloud compute target-https-proxies create gil7-https-proxy \
      --url-map=gl7-gilb-url-map \
      --certificate-manager-certificates=gilb-certificate \
      --global
    
  6. Crea dos reglas de reenvío: una con una dirección IP virtual (10.1.2.99) en la región REGION_B y otra con una dirección IP virtual (10.1.3.99) en la región REGION_A. Para obtener más información, consulta Reservar una dirección IPv4 interna estática.

    En el caso de las redes personalizadas, debes hacer referencia a la subred en la regla de reenvío. Ten en cuenta que se trata de la subred de la VM, no de la subred del proxy.

    En HTTP:

    Usa el comando gcloud compute forwarding-rules create con las marcas correctas.

    gcloud compute forwarding-rules create FWRULE_A \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_A \
      --subnet-region=REGION_A \
      --address=10.1.2.99 \
      --ports=80 \
      --target-http-proxy=gil7-http-proxy \
      --global
    
    gcloud compute forwarding-rules create FWRULE_B \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_B \
      --subnet-region=REGION_B \
      --address=10.1.3.99 \
      --ports=80 \
      --target-http-proxy=gil7-http-proxy \
      --global
    

    Para HTTPS:

    Usa el comando gcloud compute forwarding-rules create con las marcas correctas.

    gcloud compute forwarding-rules create FWRULE_A \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_A \
      --subnet-region=REGION_A \
      --address=10.1.2.99 \
      --ports=443 \
      --target-https-proxy=gil7-https-proxy \
      --global
    
    gcloud compute forwarding-rules create FWRULE_B \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=NETWORK \
      --subnet=SUBNET_B \
      --subnet-region=REGION_B \
      --address=10.1.3.99 \
      --ports=443 \
      --target-https-proxy=gil7-https-proxy \
      --global
    

Terraform

Para crear la comprobación del estado, usa el recurso google_compute_health_check.

resource "google_compute_health_check" "default" {
  provider = google-beta
  name     = "global-http-health-check"
  http_health_check {
    port_specification = "USE_SERVING_PORT"
  }
}

Para crear el servicio de backend, usa el recurso google_compute_backend_service.

resource "google_compute_backend_service" "default" {
  name                  = "gl7-gilb-backend-service"
  provider              = google-beta
  protocol              = "HTTP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  timeout_sec           = 10
  health_checks         = [google_compute_health_check.default.id]
  backend {
    group           = google_compute_region_instance_group_manager.mig_a.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
  backend {
    group           = google_compute_region_instance_group_manager.mig_b.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
}

Para crear el mapa de URLs, usa el recurso google_compute_url_map.

resource "google_compute_url_map" "default" {
  name            = "gl7-gilb-url-map"
  provider        = google-beta
  default_service = google_compute_backend_service.default.id
}

Para crear el proxy HTTP de destino, usa el recurso google_compute_target_http_proxy.

resource "google_compute_target_http_proxy" "default" {
  name     = "gil7target-http-proxy"
  provider = google-beta
  url_map  = google_compute_url_map.default.id
}

Para crear las reglas de reenvío, usa el recurso google_compute_forwarding_rule.

resource "google_compute_global_forwarding_rule" "fwd_rule_a" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_a]
  ip_address            = "10.1.2.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-a"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_a.id
}
resource "google_compute_global_forwarding_rule" "fwd_rule_b" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_b]
  ip_address            = "10.1.3.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-b"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_b.id
}

Para saber cómo aplicar o quitar una configuración de Terraform, consulta Comandos básicos de Terraform.

API

Para crear la comprobación del estado, haz una solicitud POST al método healthChecks.insert y sustituye PROJECT_ID por el ID de tu proyecto.

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

{
"name": "global-http-health-check",
"type": "HTTP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

Crea el servicio de backend global haciendo una solicitud POST al método backendServices.insert y sustituyendo PROJECT_ID por el ID de tu proyecto.

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

{
"name": "BACKEND_SERVICE_NAME",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl7-ilb-mig-a",
    "balancingMode": "UTILIZATION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl7-ilb-mig-b",
    "balancingMode": "UTILIZATION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-http-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Crea el mapa de URLs haciendo una solicitud POST al método urlMaps.insert y sustituyendo PROJECT_ID por el ID de tu proyecto.

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

{
"name": "l7-ilb-map",
"defaultService": "projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME"
}

Para HTTP:

Crea el proxy HTTP de destino haciendo una solicitud POST al método targetHttpProxies.insert y sustituyendo PROJECT_ID por el ID de tu proyecto.

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

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map"
}

Para crear la regla de reenvío, haz una solicitud POST al método forwardingRules.insert y sustituye PROJECT_ID por el ID de tu proyecto.

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

{
"name": "FWRULE_A",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "gil7forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Para HTTPS:

Lee los archivos de certificado y clave privada y, a continuación, crea el certificado SSL. En el siguiente ejemplo se muestra cómo hacerlo con Python.

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

        Returns:
        Dictionary with information about the new regional SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

    return response

Crea el proxy HTTPS de destino enviando una solicitud POST al método targetHttpsProxies.insert y sustituyendo PROJECT_ID por el ID de tu proyecto.

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

{
"name": "l7-ilb-proxy",
"urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-map",
"sslCertificates": /projects/PROJECT_ID/global/sslCertificates/SSL_CERT_NAME
}

Para crear la regla de reenvío, haz una solicitud POST al método globalForwardingRules.insert y sustituye PROJECT_ID por el ID de tu proyecto.

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

{
"name": "FWRULE_A",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules

{
"name": "FWRULE_B",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetHttpsProxies/l7-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Probar el balanceador de carga

Crear una instancia de máquina virtual para probar la conectividad

  1. Crea una VM cliente:

    gcloud compute instances create l7-ilb-client-a \
        --image-family=debian-12 \
        --image-project=debian-cloud \
        --network=NETWORK \
        --subnet=SUBNET_A \
        --zone=ZONE_A \
        --tags=allow-ssh
    
    gcloud compute instances create l7-ilb-client-b \
        --image-family=debian-12 \
        --image-project=debian-cloud \
        --network=NETWORK \
        --subnet=SUBNET_B \
        --zone=ZONE_B \
        --tags=allow-ssh
    
  2. Usa SSH para conectarte a cada instancia de cliente.

    gcloud compute ssh l7-ilb-client-a --zone=ZONE_A
    
    gcloud compute ssh l7-ilb-client-b --zone=ZONE_B
    
  3. Verificar que la dirección IP está sirviendo su nombre de host

    • Verifica que la VM cliente pueda acceder a ambas direcciones IP. El comando devuelve el nombre de la VM de backend que ha atendido la solicitud:

      curl 10.1.2.99
      
      curl 10.1.3.99
      

      Para probar HTTPS, sustituye curl por la siguiente línea de comandos:

      curl -k 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.2.99:443
      
      curl -k 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.3.99:443
      

      Sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación. Por ejemplo, test.example.com.

      La marca -k hace que curl omita la validación del certificado.

    • Opcional: Usa el registro DNS configurado para resolver la dirección IP más cercana a la VM del cliente. Por ejemplo, DNS_NAME puede ser service.example.com.

      curl DNS_NAME
      

Ejecuta 100 solicitudes y confirma que están balanceadas.

Para HTTP:

  {
    RESULTS=
    for i in {1..100}
    do
        RESULTS="$RESULTS:$(curl --silent 10.1.2.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl --silent 10.1.3.99)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

Para HTTPS:

En las siguientes secuencias de comandos, sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación, por ejemplo, test.example.com.

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.2.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.2.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

  {
    RESULTS=
    for i in {1..100}
    do
       RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.3.99:443)"
    done
    echo ""
    echo " Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
  }
  

Prueba de conmutación por error

  1. Verifica la conmutación por error a los back-ends de la región REGION_A cuando los back-ends de la región REGION_B no estén en buen estado o no se pueda acceder a ellos. Para simular una conmutación por error, elimina todos los back-ends de REGION_B:

    gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
       --balancing-mode=UTILIZATION \
       --instance-group=gl7-ilb-mig-b \
       --instance-group-zone=ZONE_B
    
  2. Conéctate mediante SSH a una VM cliente de REGION_B.

    gcloud compute ssh l7-ilb-client-b \
       --zone=ZONE_B
    
  3. Envía solicitudes a la dirección IP balanceada de carga en la región REGION_B. El resultado del comando muestra las respuestas de las VMs backend en REGION_A.

    En la siguiente secuencia de comandos, sustituye DOMAIN_NAME por el nombre de dominio de tu aplicación (por ejemplo, test.example.com).

    {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://DOMAIN_NAME:443' --connect-to DOMAIN_NAME:443:10.1.3.99:443)"
    done
    echo "***"
    echo "*** Results of load-balancing to 10.1.3.99: "
    echo "***"
    echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
    echo
    }
    

Opciones de configuración adicionales

En esta sección se amplía el ejemplo de configuración para ofrecer opciones de configuración alternativas y adicionales. Todas las tareas son opcionales. Puedes realizarlas en el orden que prefieras.

Habilitar la afinidad de sesión

En estos procedimientos se muestra cómo actualizar un servicio de backend del balanceador de carga de aplicaciones interno regional o del balanceador de carga de aplicaciones interno entre regiones de ejemplo para que el servicio de backend use la afinidad de cookies generada, la afinidad de campos de encabezado o la afinidad de cookies HTTP.

Cuando se habilita la afinidad de cookies generadas, el balanceador de carga emite una cookie en la primera solicitud. En cada solicitud posterior con la misma cookie, el balanceador de carga dirige la solicitud a la misma instancia o endpoint de máquina virtual (VM) de backend. En este ejemplo, la cookie se llama GCILB.

Cuando la afinidad de campo de encabezado está habilitada, el balanceador de carga dirige las solicitudes a las VMs o los endpoints de backend de un grupo de endpoints de red (NEG) en función del valor del encabezado HTTP denominado en la marca --custom-request-header. La afinidad de campo de encabezado solo es válida si la política de localidad del balanceo de carga es RING_HASH o MAGLEV y el hash coherente del servicio de backend especifica el nombre del encabezado HTTP.

Cuando la afinidad de cookies HTTP está habilitada, el balanceador de carga dirige las solicitudes a las VMs de backend o a los endpoints de un NEG en función de una cookie HTTP denominada en la marca HTTP_COOKIE con la marca opcional --affinity-cookie-ttl. Si el cliente no proporciona la cookie en su solicitud HTTP, el proxy genera la cookie y la devuelve al cliente en un encabezado Set-Cookie. La afinidad de cookies HTTP solo es válida si la política de localidad del balanceo de carga es RING_HASH o MAGLEV y el hash coherente del servicio de backend especifica la cookie HTTP.

Consola

Para habilitar o cambiar la afinidad de sesión de un servicio de backend, sigue estos pasos:

  1. En la Google Cloud consola, ve a la página Balanceo de carga.

    Ir a Balanceo de carga

  2. Haz clic en Back-ends.
  3. Haz clic en gil7-backend-service (el nombre del servicio de backend que has creado para este ejemplo) y, a continuación, en Editar.
  4. En la página Detalles del servicio de backend, haz clic en Configuración avanzada.
  5. En Afinidad de sesión, selecciona el tipo de afinidad de sesión que quieras.
  6. Haz clic en Actualizar.

gcloud

Usa los siguientes comandos de la CLI de Google Cloud para actualizar el servicio de backend a diferentes tipos de afinidad de sesión:

    gcloud compute backend-services update gil7-backend-service \
        --session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] \
        --global
    

API

Para definir la afinidad de sesión, haz una solicitud `PATCH` al método backendServices/patch.

    PATCH https://compute.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/backendServices/gil7-backend-service
    {
    "sessionAffinity": ["GENERATED_COOKIE" | "HEADER_FIELD" | "HTTP_COOKIE" | "CLIENT_IP" ]
    }
    

Restringir los clientes que pueden enviar tráfico al balanceador de carga

Puedes impedir que los clientes se conecten a una IP virtual de una regla de reenvío de un balanceador de carga de aplicaciones interno configurando reglas de cortafuegos de salida en estos clientes. Define estas reglas de cortafuegos en VMs de cliente específicas en función de las cuentas de servicio o las etiquetas.

No puede usar reglas de cortafuegos para restringir el tráfico entrante a IPs virtuales de reglas de reenvío de balanceadores de carga de aplicaciones internos específicos. Por lo general, cualquier cliente de la misma red de VPC y de la misma región que la IP virtual de la regla de reenvío puede enviar tráfico a la IP virtual de la regla de reenvío.

Además, todas las solicitudes a los back-ends proceden de proxies que usan direcciones IP del intervalo de la subred de solo proxy. No se pueden crear reglas de cortafuegos que permitan o denieguen el tráfico de entrada en estos backends en función del VIP de la regla de reenvío que utilice un cliente.

A continuación, se muestran algunos ejemplos de cómo usar reglas de cortafuegos de salida para restringir el tráfico a la dirección IP virtual de la regla de reenvío del balanceador de carga.

Consola

Para identificar las VMs de cliente, etiqueta las VMs específicas que quieras restringir. Estas etiquetas se usan para asociar reglas de cortafuegos con las VMs de cliente etiquetadas. A continuación, añade la etiqueta al campo TARGET_TAG siguiendo estos pasos.

Para configurarlo, puedes usar una o varias reglas de cortafuegos.

Regla de cortafuegos de salida única

Puedes configurar una regla de salida de cortafuegos para denegar todo el tráfico de salida que vaya desde las VMs de cliente etiquetadas a la VIP de un balanceador de carga.

  1. En la Google Cloud consola, ve a la página Reglas de cortafuegos.

    Ir a reglas de cortafuegos

  2. Haga clic en Crear regla de cortafuegos para crear la regla que deniegue el tráfico de salida de las VMs de cliente etiquetadas a la IP virtual de un balanceador de carga.

    • Nombre: fr-deny-access
    • Red: lb-network
    • Prioridad: 100
    • Dirección del tráfico: Salida
    • Acción tras coincidencia: Denegar
    • Objetivos: Etiquetas de destino especificadas
    • Etiquetas de destino: TARGET_TAG
    • Filtro de destino: Intervalos de IP
    • Intervalos de IPs de destino: 10.1.2.99
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla tcp y, a continuación, introduce 80 como número de puerto.
  3. Haz clic en Crear.

Varias reglas de cortafuegos de salida

Una estrategia más escalable consiste en definir dos reglas. Una regla predeterminada de baja prioridad que restringe el acceso de todos los clientes a la IP virtual del balanceador de carga. Una segunda regla de mayor prioridad que permite que un subconjunto de clientes etiquetados accedan a la dirección IP virtual del balanceador de carga. Solo las VMs etiquetadas pueden acceder a la IP virtual.

  1. En la Google Cloud consola, ve a la página Reglas de cortafuegos.

    Ir a reglas de cortafuegos

  2. Haga clic en Crear regla de cortafuegos para crear la regla de menor prioridad que deniegue el acceso de forma predeterminada:

    • Nombre: fr-deny-all-access-low-priority
    • Red: lb-network
    • Prioridad: 200
    • Dirección del tráfico: Salida
    • Acción tras coincidencia: Denegar
    • Objetivos: Etiquetas de destino especificadas
    • Etiquetas de destino: TARGET_TAG
    • Filtro de destino: Intervalos de IP
    • Intervalos de IPs de destino: 10.1.2.99
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla TCP y, a continuación, introduce 80 como número de puerto.
  3. Haz clic en Crear.

  4. Haga clic en Crear regla de cortafuegos para crear la regla de mayor prioridad que permita el tráfico de determinadas instancias etiquetadas.

    • Nombre: fr-allow-some-access-high-priority
    • Red: lb-network
    • Prioridad: 100
    • Dirección del tráfico: Salida
    • Acción tras coincidencia: Permitir
    • Objetivos: Etiquetas de destino especificadas
    • Etiquetas de destino: TARGET_TAG
    • Filtro de destino: Intervalos de IP
    • Intervalos de IPs de destino: 10.1.2.99
    • Protocolos y puertos:
      • Elige Protocolos y puertos especificados.
      • Selecciona la casilla TCP y, a continuación, introduce 80 como número de puerto.
  5. Haz clic en Crear.

gcloud

Para identificar las VMs de cliente, etiqueta las VMs específicas que quieras restringir. A continuación, añade la etiqueta al campo TARGET_TAG siguiendo estos pasos.

Para configurarlo, puedes usar una o varias reglas de cortafuegos.

Regla de cortafuegos de salida única

Puedes configurar una regla de salida de cortafuegos para denegar todo el tráfico de salida que vaya desde las VMs de cliente etiquetadas a la VIP de un balanceador de carga.

gcloud compute firewall-rules create fr-deny-access \
    --network=lb-network \
    --action=deny \
    --direction=egress \
    --rules=tcp \
    --priority=100 \
    --destination-ranges=10.1.2.99 \
    --target-tags=TARGET_TAG

Varias reglas de cortafuegos de salida

Un enfoque más escalable consiste en definir dos reglas: una regla predeterminada de baja prioridad que impida que todos los clientes accedan a la dirección IP virtual del balanceador de carga y una segunda regla de mayor prioridad que permita que un subconjunto de clientes etiquetados accedan a la dirección IP virtual del balanceador de carga. Solo las VMs etiquetadas pueden acceder a la VIP.

  1. Crea la regla de menor prioridad:

    gcloud compute firewall-rules create fr-deny-all-access-low-priority \
        --network=lb-network \
        --action=deny \
        --direction=egress \
        --rules=tcp \
        --priority=200 \
        --destination-ranges=10.1.2.99
    
  2. Crea la regla de mayor prioridad:

    gcloud compute firewall-rules create fr-allow-some-access-high-priority \
        --network=lb-network \
        --action=allow \
        --direction=egress \
        --rules=tcp \
        --priority=100 \
        --destination-ranges=10.1.2.99 \
        --target-tags=TARGET_TAG
    

Para usar cuentas de servicio en lugar de etiquetas para controlar el acceso, usa la opción --target-service-accounts en lugar de la marca --target-tags al crear reglas de cortafuegos.

Escalar el acceso restringido a los back-ends de los balanceadores de carga de aplicaciones internos en función de las subredes

Mantener reglas de cortafuegos independientes o añadir nuevas direcciones IP con balanceo de carga a las reglas existentes, tal como se describe en la sección anterior, resulta poco práctico a medida que aumenta el número de reglas de reenvío. Una forma de evitarlo es asignar direcciones IP de reglas de reenvío desde una subred reservada. Después, se puede permitir o bloquear el tráfico de las instancias o cuentas de servicio etiquetadas usando la subred reservada como intervalo de destino de las reglas de cortafuegos. De esta forma, puedes controlar de forma eficaz el acceso a un grupo de IPs virtuales de reglas de reenvío sin tener que mantener reglas de salida de cortafuegos por IP virtual.

A continuación, se indican los pasos generales para configurar esta opción, suponiendo que creará todos los demás recursos de balanceador de carga necesarios por separado.

gcloud

  1. Crea una subred regional para asignar direcciones IP con balanceo de carga a las reglas de reenvío:

    gcloud compute networks subnets create l7-ilb-restricted-subnet \
        --network=lb-network \
        --region=us-west1 \
        --range=10.127.0.0/24
    
  2. Crea una regla de reenvío que tome una dirección de la subred. En el siguiente ejemplo se usa la dirección 10.127.0.1 de la subred creada en el paso anterior.

    gcloud compute forwarding-rules create l7-ilb-forwarding-rule-restricted \
        --load-balancing-scheme=INTERNAL_MANAGED \
        --network=lb-network \
        --subnet=l7-ilb-restricted-subnet \
        --address=10.127.0.1 \
        --ports=80 \
        --global \
        --target-http-proxy=gil7-http-proxy
    
  3. Crea una regla de cortafuegos para restringir el tráfico destinado al intervalo de direcciones IP de la subred de la regla de reenvío (l7-ilb-restricted-subnet):

    gcloud compute firewall-rules create restrict-traffic-to-subnet \
        --network=lb-network \
        --action=deny \
        --direction=egress \
        --rules=tcp:80 \
        --priority=100 \
        --destination-ranges=10.127.0.0/24 \
        --target-tags=TARGET_TAG
    

Usar la misma dirección IP en varias reglas de reenvío internas

Para que varias reglas de reenvío internas compartan la misma dirección IP interna, debe reservar la dirección IP y definir su marca --purpose en SHARED_LOADBALANCER_VIP.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP
Si necesitas redirigir el tráfico HTTP a HTTPS, puedes crear dos reglas de reenvío que usen una dirección IP común. Para obtener más información, consulta el artículo Configurar el redireccionamiento de HTTP a HTTPS para balanceadores de carga de aplicaciones internos.

Configurar políticas de enrutamiento de DNS

Si tus clientes se encuentran en varias regiones, puede que quieras que tu balanceador de carga de aplicación interno entre regiones sea accesible mediante VIPs en esas regiones. Esta configuración multirregión minimiza la latencia y los costes de tránsito de red. Además, te permite configurar una solución de balanceo de carga global basada en DNS que proporciona resiliencia frente a las interrupciones regionales. Para obtener más información, consulta Gestionar políticas de enrutamiento de DNS y comprobaciones de estado.

gcloud

Para crear una entrada DNS con un TTL de 30 segundos, usa el comando gcloud dns record-sets create.

gcloud dns record-sets create DNS_ENTRY --ttl="30" \
  --type="A" --zone="service-zone" \
  --routing-policy-type="GEO" \
  --routing-policy-data="REGION_A=gil7-forwarding-rule-a@global;REGION_B=gil7-forwarding-rule-b@global" \
  --enable-health-checking

Haz los cambios siguientes:

  • DNS_ENTRY: nombre de DNS o de dominio del conjunto de registros

    Por ejemplo, service.example.com

  • REGION_A y REGION_B: las regiones en las que has configurado el balanceador de carga

API

Crea el registro DNS haciendo una solicitud POST al método ResourceRecordSets.create. Sustituye PROJECT_ID por el ID de tu proyecto.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/SERVICE_ZONE/rrsets
{
  "name": "DNS_ENTRY",
  "type": "A",
  "ttl": 30,
  "routingPolicy": {
    "geo": {
      "items": [
        {
          "location": "REGION_A",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        },
        {
          "location": "REGION_B",
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "globalL7ilb",
                "ipAddress": "IP_ADDRESS_B",
                "port": "80",
                "ipProtocol": "tcp",
                "networkUrl": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
                "project": "PROJECT_ID"
              }
            ]
          }
        }
      ]
    }
  }
}

Actualizar el tiempo de espera de keep-alive HTTP del cliente

El balanceador de carga creado en los pasos anteriores se ha configurado con un valor predeterminado para el tiempo de espera de keep-alive HTTP del cliente.

Para actualizar el tiempo de espera de keep-alive HTTP del cliente, sigue estas instrucciones.

Consola

  1. En la Google Cloud consola, ve a la página Balanceo de carga.

    Ve a Balanceo de carga.

  2. Haga clic en el nombre del balanceador de carga que quiera modificar.
  3. Haz clic en Editar.
  4. Haz clic en Configuración de frontend.
  5. Despliega Funciones avanzadas. En Tiempo de espera de HTTP Keep-Alive, introduce un valor de tiempo de espera.
  6. Haz clic en Actualizar.
  7. Para revisar los cambios, haz clic en Revisar y finalizar y, a continuación, en Actualizar.

gcloud

En el caso de un balanceador de carga HTTP, actualiza el proxy HTTP de destino con el comando gcloud compute target-http-proxies update:

      gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --global
    

En el caso de un balanceador de carga HTTPS, actualiza el proxy HTTPS de destino con el comando gcloud compute target-https-proxies update:

      gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --global
    

Haz los cambios siguientes:

  • TARGET_HTTP_PROXY_NAME: nombre del proxy HTTP de destino.
  • TARGET_HTTPS_PROXY_NAME: nombre del proxy HTTPS de destino.
  • HTTP_KEEP_ALIVE_TIMEOUT_SEC: el valor del tiempo de espera de HTTP Keep-Alive de 5 a 600 segundos.

Habilitar la detección de valores atípicos

Puedes habilitar la detección de valores atípicos en los servicios de backend globales para identificar los NEGs sin servidor que no estén en buen estado y reducir el número de solicitudes que se envían a esos NEGs.

La detección de valores atípicos se habilita en el servicio backend mediante uno de los siguientes métodos:

  • El método consecutiveErrors (outlierDetection.consecutiveErrors), en el que un código de estado HTTP de la serie 5xx se considera un error.
  • El método consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), en el que solo los códigos de estado HTTP 502, 503 y 504 se consideran errores.

Sigue estos pasos para habilitar la detección de anomalías en un servicio backend. Ten en cuenta que, incluso después de habilitar la detección de valores atípicos, algunas solicitudes se pueden enviar al servicio no operativo y devolver un código de estado 5xx a los clientes. Para reducir aún más la tasa de error, puedes configurar valores más agresivos para los parámetros de detección de valores atípicos. Para obtener más información, consulta el campo outlierDetection.

Consola

  1. En la Google Cloud consola, ve a la página Balanceo de carga.

    Ir a Balanceo de carga

  2. Haga clic en el nombre del balanceador de carga cuyo servicio de backend quiera editar.

  3. En la página Detalles del balanceador de carga, haga clic en Editar.

  4. En la página Editar balanceador de carga de aplicación interno entre regiones, haz clic en Configuración de backend.

  5. En la página Configuración de backend, haga clic en Editar en el servicio de backend que quiera modificar.

  6. Desplázate hacia abajo y despliega la sección Configuración avanzada.

  7. En la sección Detección de valores atípicos, selecciona la casilla Habilitar.

  8. Haz clic en Editar para configurar la detección de valores atípicos.

    Verifica que las siguientes opciones estén configuradas con estos valores:

    Propiedad Valor
    Errores consecutivos 5
    Intervalo 1000
    Tiempo base de expulsión 30000
    Porcentaje máximo de expulsión 50
    Aplicar errores consecutivos 100

    En este ejemplo, el análisis de detección de anomalías se ejecuta cada segundo. Si el número de códigos de estado HTTP 5xx consecutivos que recibe un proxy Envoy es cinco o más, el endpoint de backend se expulsa del grupo de balanceo de carga de ese proxy Envoy durante 30 segundos. Cuando el porcentaje de aplicación es del 100%, el servicio backend aplica la expulsión de los endpoints que no están en buen estado de los grupos de balanceo de carga de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los endpoints de backend del grupo de balanceo de carga.

  9. Haz clic en Guardar.

  10. Para actualizar el servicio de backend, haz clic en Actualizar.

  11. Para actualizar el balanceador de carga, en la página Editar balanceador de carga de aplicación interno entre regiones, haz clic en Actualizar.

gcloud

  1. Exporta el servicio backend a un archivo YAML.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
      --destination=BACKEND_SERVICE_NAME.yaml --global
    

    Sustituye BACKEND_SERVICE_NAME por el nombre del servicio backend.

  2. Edita la configuración YAML del servicio backend para añadir los campos de detección de valores atípicos, tal como se destaca en la siguiente configuración YAML, en la sección outlierDetection:

    En este ejemplo, el análisis de detección de anomalías se ejecuta cada segundo. Si el número de códigos de estado HTTP 5xx consecutivos que recibe un proxy Envoy es cinco o más, el endpoint de backend se expulsa del grupo de balanceo de carga de ese proxy Envoy durante 30 segundos. Cuando el porcentaje de aplicación es del 100%, el servicio backend aplica la expulsión de los endpoints que no están en buen estado de los grupos de balanceo de carga de esos proxies de Envoy específicos cada vez que se ejecuta el análisis de detección de valores atípicos. Si se cumplen las condiciones de expulsión, se puede expulsar hasta el 50% de los endpoints de backend del grupo de balanceo de carga.

    name: BACKEND_SERVICE_NAME
    backends:
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
      group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
      group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: 30
      consecutiveErrors: 5
      enforcingConsecutiveErrors: 100
      interval:
        nanos: 0
        seconds: 1
      maxEjectionPercent: 50
    port: 80
    selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
    sessionAffinity: NONE
    timeoutSec: 30
    ...
    

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre del servicio de backend
    • PROJECT_ID: el ID de tu proyecto
    • REGION_A y REGION_B: las regiones en las que se ha configurado el balanceador de carga.
    • SERVERLESS_NEG_NAME: el nombre del primer NEG sin servidor
    • SERVERLESS_NEG_NAME_2: el nombre del segundo NEG sin servidor
  3. Actualiza el servicio de backend importando la configuración más reciente.

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
      --source=BACKEND_SERVICE_NAME.yaml --global
    

    La detección de valores atípicos ahora está habilitada en el servicio de backend.

Siguientes pasos