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:
- Descripción general del balanceador de carga de aplicación interno, incluida la sección Limitaciones
- Descripción general de las reglas de cortafuegos de VPC
Configurar un recurso de certificado SSL
Crea un recurso de certificado SSL de Certificate Manager tal como se describe en los siguientes artículos:
- Despliega un certificado autogestionado global.
- Crea un certificado gestionado por Google emitido por tu instancia del servicio de autoridad de certificación.
- Crea un certificado gestionado por Google con autorización de DNS.
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:
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:
Una red de VPC con las siguientes subredes:
- Subred
SUBNET_A
y una subred de solo proxy enREGION_A
. - Subred
SUBNET_B
y una subred de solo proxy enREGION_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 de10.129.0.0/23
y la deREGION_B
tiene un intervalo de direcciones IP principal de10.130.0.0/23
, que es el tamaño de subred recomendado.- Subred
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
yREGION_B
. Si los backends de una región no funcionan, el tráfico se redirige a la otra región.Un servicio de backend global que monitoriza el uso y el estado de los backends.
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.
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.
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
comoSHARED_LOADBALANCER_VIP
.
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ónREGION_A
usa10.1.2.0/24
para su intervalo de IPs principal. - Una subred llamada
SUBNET_B
en la regiónREGION_B
usa10.1.3.0/24
para su intervalo de IPs principal.
- Una subred llamada
Subredes para proxies.
- Una subred llamada
PROXY_SN_A
en la regiónREGION_A
usa10.129.0.0/23
para su intervalo de IP principal. - Una subred llamada
PROXY_SN_B
en la regiónREGION_B
usa10.130.0.0/23
como intervalo de IP principal.
- Una subred llamada
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
En la Google Cloud consola, ve a la página Redes de VPC.
Haz clic en Crear red VPC.
Asigne un nombre a la red.
En la sección Subredes, selecciona Personalizado en Modo de creación de subredes.
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
Haz clic en Listo.
Haz clic en Añadir subred.
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
Haz clic en Listo.
Haz clic en Crear.
gcloud
Crea la red de VPC personalizada con el comando
gcloud compute networks create
:gcloud compute networks create NETWORK \ --subnet-mode=custom
Crea una subred en la red
NETWORK
de la regiónREGION_A
con el comandogcloud compute networks subnets create
:gcloud compute networks subnets create SUBNET_A \ --network=NETWORK \ --range=10.1.2.0/24 \ --region=REGION_A
Crea una subred en la red
NETWORK
de la regiónREGION_B
con el comandogcloud 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
.
Para crear las subredes de VPC en la red lb-network-crs-reg
, usa el recurso google_compute_subnetwork
.
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:
En la Google Cloud consola, ve a la página Redes de VPC.
- Haga clic en el nombre de la red VPC.
- En la pestaña Subred, haz clic en Añadir subred.
- Asigna un nombre a la subred de solo proxy.
- Selecciona una región: REGION_A
- En la lista Propósito, selecciona Proxy gestionado entre regiones.
- En el campo Intervalo de direcciones IP, introduce
10.129.0.0/23
. - Haz clic en Añadir.
Crea la subred de solo proxy en REGION_B
- En la pestaña Subred, haz clic en Añadir subred.
- Asigna un nombre a la subred de solo proxy.
- Selecciona una región: REGION_B
- En la lista Propósito, selecciona Proxy gestionado entre regiones.
- En el campo Intervalo de direcciones IP, introduce
10.130.0.0/23
. - 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
.
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 destinoallow-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
y35.191.0.0/16
). En este ejemplo se usa la etiqueta de destinoload-balanced-backend
para identificar las VMs a las que se aplica la regla de cortafuegos. Google Cloudfw-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
y8080
desde los proxies gestionados del balanceador de carga de aplicaciones interno. En este ejemplo se usa la etiqueta de destinoload-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
En la Google Cloud consola, ve a la página Políticas de cortafuegos.
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.
- Nombre:
Haz clic en Crear.
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
y35.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 puerto80
para ponerse en contacto con tus VMs, pero no puede usar HTTPS en el puerto443
para hacerlo.
- Nombre:
Haz clic en Crear.
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
y10.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.
- Nombre:
Haz clic en Crear.
gcloud
Crea la regla de cortafuegos
fw-ilb-to-backends
para permitir la conectividad SSH a las VMs con la etiqueta de redallow-ssh
. Si omitesource-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
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
Cree la regla
fw-backends
para permitir que los proxies del balanceador de carga de aplicaciones interno se conecten a sus backends. Definesource-ranges
en los intervalos asignados de tu subred de solo proxy, por ejemplo,10.129.0.0/23
y10.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
.
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
En la Google Cloud consola, ve a la página Plantillas de instancia.
- Haz clic en Crear plantilla de instancia.
- En Nombre, escribe
gil7-backendeast1-template
. - 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
. - Haz clic en Advanced options (Opciones avanzadas).
- Haga clic en Redes y configure los siguientes campos:
- En Etiquetas de red, introduce
allow-ssh
yload-balanced-backend
. - En Interfaces de red, selecciona lo siguiente:
- Red: NETWORK
- Subred: SUBNET_B
- En Etiquetas de red, introduce
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
Haz clic en Crear.
Haz clic en Crear plantilla de instancia.
En Nombre, escribe
gil7-backendwest1-template
.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
.Haz clic en Advanced options (Opciones avanzadas).
Haga clic en Redes y configure los siguientes campos:
- En Etiquetas de red, introduce
allow-ssh
yload-balanced-backend
. - En Interfaces de red, selecciona lo siguiente:
- Red: NETWORK
- Subred: SUBNET_A
- En Etiquetas de red, introduce
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
Haz clic en Crear.
En la consola, ve a la página Grupos de instancias. Google Cloud
- Haz clic en Crear grupo de instancias.
- 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.
- En Nombre, escribe
gl7-ilb-mig-a
. - En Ubicación, selecciona Una sola zona.
- En Región, selecciona REGION_A.
- En Zona, selecciona ZONE_A.
- En Plantilla de instancia, selecciona
gil7-backendwest1-template
. 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.
- En Modo de autoescalado, selecciona
Haz clic en Crear.
Haz clic en Crear grupo de instancias.
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.
En Nombre, escribe
gl7-ilb-mig-b
.En Ubicación, selecciona Una sola zona.
En Región, selecciona REGION_B.
En Zona, selecciona ZONE_B.
En Plantilla de instancia, selecciona
gil7-backendeast1-template
.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.
- En Modo de autoescalado, selecciona
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.
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'
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
.
Para crear el grupo de instancias gestionado, usa el recurso google_compute_instance_group_manager
.
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
oSUBNET_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
En la Google Cloud consola, ve a la página Balanceo de carga.
- Haga clic en Crear balanceador de carga.
- En Tipo de balanceador de carga, selecciona Balanceador de carga de aplicación (HTTP/HTTPS) y haz clic en Siguiente.
- En Público o interno, selecciona Interno y haz clic en Siguiente.
- 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.
- Haz clic en Configurar.
Configuración básica
- Asigna un nombre al balanceador de carga.
- En Red, selecciona NETWORK.
Configurar el frontend con dos reglas de reenvío
Para HTTP:
- Haz clic en Configuración de frontend.
- Asigne un nombre a la regla de reenvío.
- En la lista Región de la subred, selecciona REGION_A.
Reservar una subred de solo proxy
- En la lista Subred, selecciona SUBNET_A.
- 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.
- Haz clic en Listo.
- Para añadir la segunda regla de reenvío, haz clic en Añadir IP y puerto de frontend.
- Asigne un nombre a la regla de reenvío.
- En la lista Región de la subred, selecciona REGION_B.
Reservar una subred de solo proxy
- En la lista Subred, selecciona SUBNET_B.
- 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.
- 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:
- Crea un certificado gestionado por Google emitido por tu instancia del servicio de autoridad de certificación.
- Crea un certificado gestionado por Google con autorización de DNS.
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.
- Haz clic en Configuración de frontend.
- Asigne un nombre a la regla de reenvío.
- En el campo Protocol (Protocolo), selecciona
HTTPS (includes HTTP/2)
. - Asegúrate de que el Puerto esté configurado como
443
. - En la lista Región de la subred, selecciona REGION_A.
Reservar una subred de solo proxy
- En la lista Subred, selecciona SUBNET_A.
- 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.
- En la sección Añadir certificado, selecciona el certificado.
- Opcional: Para añadir certificados además del certificado SSL principal, sigue estos pasos:
- Haz clic en Añadir certificado.
- Selecciona el certificado de la lista.
- 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 .
- Haz clic en Listo.
- Asigna un nombre a la configuración del frontend.
- En el campo Protocol (Protocolo), selecciona
HTTPS (includes HTTP/2)
. - Asegúrate de que el Puerto esté configurado como
443
. - En la lista Región de la subred, selecciona REGION_B.
Reservar una subred de solo proxy
- En la lista Subred, selecciona SUBNET_B.
- 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.
- En la sección Añadir certificado, selecciona el certificado.
- Opcional: Para añadir certificados además del certificado SSL principal, sigue estos pasos:
- Haz clic en Añadir certificado.
- Selecciona el certificado de la lista.
- 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 .
- Haz clic en Listo.
- Haz clic en Configuración de backend.
- En la lista Crear o seleccionar servicios de backend, haz clic en Crear un servicio de backend.
- Asigna un Nombre al servicio de backend.
- En Protocol (Protocolo), selecciona HTTP.
- En Puerto con nombre, introduce
http
. - En la lista Tipo de backend, selecciona Grupo de instancias.
- 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.
- 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.
- Haz clic en Reglas de enrutamiento.
- En Modo, selecciona Regla sencilla de host y ruta.
- Asegúrate de que solo haya un servicio de backend para cualquier host y cualquier ruta sin coincidencia.
- Haz clic en Revisar y finalizar.
- Revisa los ajustes de configuración de tu balanceador de carga.
- Haz clic en Crear.
Añade la segunda configuración de frontend:
Configurar las reglas de enrutamiento
Revisar la configuración
gcloud
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
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
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
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
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:
- Crea un certificado gestionado por Google emitido por tu instancia del servicio de autoridad de certificación.
- Crea un certificado gestionado por Google con autorización de DNS.
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
Crea dos reglas de reenvío: una con una dirección IP virtual (
10.1.2.99
) en la regiónREGION_B
y otra con una dirección IP virtual (10.1.3.99
) en la regiónREGION_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
.
Para crear el servicio de backend, usa el recurso google_compute_backend_service
.
Para crear el mapa de URLs, usa el recurso google_compute_url_map
.
Para crear el proxy HTTP de destino, usa el recurso google_compute_target_http_proxy
.
Para crear las reglas de reenvío, usa el recurso google_compute_forwarding_rule
.
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.
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
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
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
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
Verifica la conmutación por error a los back-ends de la región
REGION_A
cuando los back-ends de la regiónREGION_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 deREGION_B
:gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \ --balancing-mode=UTILIZATION \ --instance-group=gl7-ilb-mig-b \ --instance-group-zone=ZONE_B
Conéctate mediante SSH a una VM cliente de REGION_B.
gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B
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 enREGION_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:
En la Google Cloud consola, ve a la página Balanceo de carga.
- Haz clic en Back-ends.
- Haz clic en gil7-backend-service (el nombre del servicio de backend que has creado para este ejemplo) y, a continuación, en Editar.
- En la página Detalles del servicio de backend, haz clic en Configuración avanzada.
- En Afinidad de sesión, selecciona el tipo de afinidad de sesión que quieras.
- 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.
En la Google Cloud consola, ve a la página Reglas de cortafuegos.
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.
- Nombre:
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.
En la Google Cloud consola, ve a la página Reglas de cortafuegos.
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.
- Nombre:
Haz clic en Crear.
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.
- Nombre:
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.
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
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
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
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
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
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 registrosPor ejemplo,
service.example.com
REGION_A
yREGION_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
En la Google Cloud consola, ve a la página Balanceo de carga.
- Haga clic en el nombre del balanceador de carga que quiera modificar.
- Haz clic en Editar.
- Haz clic en Configuración de frontend.
- Despliega Funciones avanzadas. En Tiempo de espera de HTTP Keep-Alive, introduce un valor de tiempo de espera.
- Haz clic en Actualizar.
- 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 serie5xx
se considera un error. - El método
consecutiveGatewayFailure
(outlierDetection.consecutiveGatewayFailure
), en el que solo los códigos de estado HTTP502
,503
y504
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
En la Google Cloud consola, ve a la página Balanceo de carga.
Haga clic en el nombre del balanceador de carga cuyo servicio de backend quiera editar.
En la página Detalles del balanceador de carga, haga clic en
Editar.En la página Editar balanceador de carga de aplicación interno entre regiones, haz clic en Configuración de backend.
En la página Configuración de backend, haga clic en
Editar en el servicio de backend que quiera modificar.Desplázate hacia abajo y despliega la sección Configuración avanzada.
En la sección Detección de valores atípicos, selecciona la casilla Habilitar.
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.Haz clic en Guardar.
Para actualizar el servicio de backend, haz clic en Actualizar.
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
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.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 backendPROJECT_ID
: el ID de tu proyectoREGION_A
yREGION_B
: las regiones en las que se ha configurado el balanceador de carga.SERVERLESS_NEG_NAME
: el nombre del primer NEG sin servidorSERVERLESS_NEG_NAME_2
: el nombre del segundo NEG sin servidor
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
- Convertir un balanceador de carga de aplicaciones a IPv6
- Descripción general del balanceador de carga de aplicaciones interno
- Subredes de solo proxy para balanceadores de carga basados en Envoy
- Gestionar certificados
- Limpiar una configuración de balanceo de carga