En este documento, se muestra cómo crear un balanceador de cargas de aplicaciones interno entre regiones para enrutar las solicitudes de contenido estático a los buckets de Cloud Storage.
Antes de comenzar
Asegúrate de que tu configuración cumpla con los requisitos.
Instala Google Cloud CLI
En la versión preliminar, algunas de las instrucciones de esta guía solo se pueden realizar con Google Cloud CLI. Para instalarla, consulta el documento Instala gcloud CLI.
Encontrarás comandos relacionados con el balanceo de cargas en el documento API y referencias de la CLI de gcloud.
Permisos
Para seguir esta guía, debes crear buckets de Cloud Storage y recursos de red en tu proyecto. Debes ser propietario o editor de un proyecto o tener las siguientes funciones de IAM de Compute Engine:
Tarea | Función requerida |
---|---|
Crear redes, subredes y componentes del balanceador de cargas | Rol Compute Network Admin (roles/compute.networkAdmin )
|
Agregar y quitar reglas de firewall | Rol de administrador de seguridad de Compute (roles/compute.securityAdmin )
|
Crea buckets de Cloud Storage | Función de administrador de objetos de almacenamiento (roles/storage.objectAdmin )
|
Si deseas obtener más información, consulta las siguientes guías:
Configura un recurso de certificado SSL
Para un balanceador de cargas de aplicaciones interno entre regiones que use HTTPS como el protocolo de solicitud y respuesta, crea un recurso de certificado SSL con el Administrador de certificados como se describe en uno de los siguientes documentos:
- Crea un certificado administrado por Google emitido por tu instancia de Certificate Authority Service
- Implementa un certificado administrado por Google global con autorización de DNS
- Implementa un certificado autoadministrado global
Después de crear el certificado, puedes adjuntarlo al proxy de destino HTTPS.
Recomendamos que uses un certificado administrado por Google.
Limitaciones
Las siguientes limitaciones se aplican a los buckets de Cloud Storage cuando se entregan como backends a un balanceador de cargas de aplicaciones interno entre regiones:
No se admite el acceso a buckets privados, por lo que el bucket de backend debe ser de acceso público a través de Internet.
No se admiten las URLs firmadas.
La integración de Cloud CDN no está disponible cuando se crean buckets de backend para un balanceador de cargas de aplicaciones interno entre regiones.
Cuando se usa un balanceador de cargas de aplicaciones interno entre regiones para acceder a los buckets de backend, solo se admite el método
GET
de HTTP. Puedes descargar contenido del bucket, pero no está disponible la carga de contenido al bucket a través del balanceador de cargas de aplicaciones interno entre regiones.
Descripción general de la configuración
Puedes configurar un balanceador de cargas de aplicaciones interno entre regiones en varias regiones, como se muestra en el siguiente diagrama:
Como se muestra en el diagrama de arquitectura, en este ejemplo se crea un balanceador de cargas de aplicaciones interno entre regiones en una red de nube privada virtual (VPC) con dos buckets de backend, en los que cada bucket de backend hace referencia a un bucket de Cloud Storage. Los buckets de Cloud Storage se encuentran en las regiones us-east1
y asia-east1
.
Esta arquitectura de implementación ofrece alta disponibilidad. Si falla el balanceador de cargas de aplicaciones interno entre regiones en una región, las políticas de enrutamiento de DNS enrutan el tráfico a un balanceador de cargas de aplicaciones interno entre regiones en otra región.
Configura la red y las subredes
Dentro de la red de VPC, configura una subred en cada región en la que se debe configurar la regla de reenvío de tus balanceadores de cargas. Además, configura un proxy-only-subnet
en cada región en la que desees configurar el balanceador de cargas.
Este ejemplo usa la siguiente red de VPC, región y subredes:
Red. Es una red de VPC de modo personalizado con el nombre
lb-network
.Subredes para el balanceador de cargas. Una subred llamada
subnet-us
en la regiónus-east1
usa10.1.2.0/24
para su rango de IP principal. Una subred llamadasubnet-asia
en la regiónasia-east1
usa10.1.3.0/24
para su rango de IP principal.Subred para proxies de Envoy. Una subred llamada
proxy-only-subnet-us-east1
en la regiónus-east1
usa10.129.0.0/23
para su rango de IP principal. Una subred llamadaproxy-only-subnet-asia-east1
en la regiónasia-east1
usa10.130.0.0/23
para su rango de IP principal.
Se puede acceder a los balanceadores de cargas de aplicaciones internos entre regiones desde cualquier región dentro de la VPC. Los clientes de cualquier región pueden acceder de manera global a los backends del balanceador de cargas.
Configura las subredes para la regla de reenvío del balanceador de cargas
Console
En la consola de Google Cloud, ve a la página Redes de VPC.
Haz clic en Crear red de VPC.
En Nombre, ingresa
lb-network
.En la sección Subredes, establece Modo de creación de subred como Personalizado.
En la sección Subred nueva, ingresa la siguiente información:
- Nombre:
subnet-us
- Selecciona una Región:
us-east1
- Rangos de direcciones IP:
10.1.2.0/24
- Nombre:
Haz clic en Listo.
Haz clic en Agregar subred.
Crea otra subred para la regla de reenvío del balanceador de cargas en una región diferente. En la sección Nueva subred, ingresa la siguiente información:
- Nombre:
subnet-asia
- Región:
asia-east1
- Rangos de direcciones IP:
10.1.3.0/24
- Nombre:
Haz clic en Listo.
Haz clic en Crear.
gcloud
Crea una red de VPC personalizada, llamada
lb-network
, con el comandogcloud compute networks create
.gcloud compute networks create lb-network --subnet-mode=custom
Crea una subred en la red de VPC
lb-network
en la regiónus-east1
con el comandogcloud compute networks subnets create
.gcloud compute networks subnets create subnet-us \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-east1
Crea una subred en la red de VPC
lb-network
en la regiónasia-east1
con el comandogcloud compute networks subnets create
.gcloud compute networks subnets create subnet-asia \ --network=lb-network \ --range=10.1.3.0/24 \ --region=asia-east1
Configura la subred de solo proxy
Una subred solo de proxy proporciona un conjunto de direcciones IP que Google Cloud usa para ejecutar proxies de Envoy en tu nombre. Los proxies finalizan las conexiones del cliente y crean conexiones nuevas a los backends.
Todos los balanceadores de cargas regionales basados en Envoy usan esta subred de solo proxy en la misma región de la red de VPC. Solo puede haber una subred de solo proxy activa para un propósito determinado, por región, por red.
Console
En la consola de Google Cloud, ve a la página Redes de VPC.
Haz clic en el nombre de la red de VPC que creaste.
En la pestaña Subred, haz clic en Agregar subred.
Ingresa la siguiente información:
- Nombre:
proxy-only-subnet-us
- Región:
us-east1
- Rango de direcciones IP:
10.129.0.0/23
- Nombre:
Haz clic en Agregar.
Crea otra subred para la regla de reenvío del balanceador de cargas en una región diferente. En la pestaña Subred, haz clic en Agregar subred.
Ingresa la siguiente información:
- Nombre:
proxy-only-subnet-asia
- Región:
asia-east1
- Rango de direcciones IP:
10.130.0.0/23
- Nombre:
Haz clic en Agregar.
gcloud
Crea una subred de solo proxy en la región
us-east1
con el comandogcloud compute networks subnets create
.gcloud compute networks subnets create proxy-only-subnet-us \ --purpose=GLOBAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-east1 \ --network=lb-network \ --range=10.129.0.0/23
Crea una subred de solo proxy en la región
asia-east1
con el comandogcloud compute networks subnets create
.gcloud compute networks subnets create proxy-only-subnet-asia \ --purpose=GLOBAL_MANAGED_PROXY \ --role=ACTIVE \ --region=asia-east1 \ --network=lb-network \ --range=10.130.0.0/23
Configura una regla de firewall
En este ejemplo, se usa la siguiente regla de firewall:
Una regla de entrada que permite el acceso SSH en el puerto
22
a la VM del cliente En este ejemplo, esta regla de firewall se llamafw-allow-ssh
.
Console
En la consola de Google Cloud, ve a la página Políticas de firewall.
Haz clic en Crear regla de firewall para crear la regla que permite conexiones SSH entrantes en la VM del cliente:
- Nombre:
fw-allow-ssh
- Red:
lb-network
- Dirección del tráfico: Entrada
- Acción en caso de coincidencia: Permitir
- Destinos: Etiquetas de destino especificadas
- Etiquetas de destino:
allow-ssh
- Filtro de fuente: Rangos de IPv4
- Rangos de IPv4 de origen:
0.0.0.0/0
- Protocolos y puertos:
- Elige Protocolos y puertos especificados.
- Selecciona la casilla de verificación TCP y, luego, ingresa
22
para el número de puerto.
- Nombre:
Haz clic en Crear.
gcloud
Crea la regla de firewall
fw-allow-ssh
para permitir la conectividad SSH a las VM con la etiqueta de redallow-ssh
. Cuando omites--source-ranges
,Google Cloud interpreta que la regla significa cualquier fuente.gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
Configura tus buckets de Cloud Storage
El proceso para configurar los buckets de Cloud Storage es el siguiente:
- Se crean los buckets.
- Se copia el contenido en los buckets.
Crea buckets de Cloud Storage
En este ejemplo, se crean dos buckets de Cloud Storage, uno en la región us-east1
y otro en la región asia-east1
. Para implementaciones de producción, te recomendamos que elijas un bucket multirregión, que replica de manera automática los objetos en varias regiones de Google Cloud . Esto puede mejorar la disponibilidad de tu contenido y la tolerancia a errores en tu aplicación.
Console
- En la consola de Google Cloud, ve a la página Buckets de Cloud Storage.
Haga clic en
Crear.En el cuadro Asigna un nombre a tu bucket, ingresa un nombre global único que siga los lineamientos de nomenclatura.
Haz clic en Elige dónde almacenar tus datos.
Configura Tipo de ubicación como Región.
En la lista de regiones, selecciona us-east1.
Haz clic en Crear.
Haz clic en Buckets para volver a la página Buckets de Cloud Storage. Usa estas instrucciones para crear un segundo bucket, pero establece la Ubicación en asia-east1.
gcloud
Crea el primer bucket en la región
us-east1
con el comandogcloud storage buckets create
.gcloud storage buckets create gs://BUCKET1_NAME \ --default-storage-class=standard \ --location=us-east1 \ --uniform-bucket-level-access
Crea el segundo bucket en la región
asia-east1
con el comandogcloud storage buckets create
.gcloud storage buckets create gs://BUCKET2_NAME \ --default-storage-class=standard \ --location=asia-east1 \ --uniform-bucket-level-access
Reemplaza las variables BUCKET1_NAME y BUCKET2_NAME por los nombres de tus buckets de Cloud Storage.
Copia archivos gráficos en tus buckets de Cloud Storage
Para que puedas probar la configuración, copia un archivo gráfico de un bucket público de Cloud Storage en tus propios buckets de Cloud Storage.
Ejecuta los siguientes comandos en Cloud Shell y reemplaza las variables de nombre del bucket por los nombres únicos de tus buckets de Cloud Storage:
gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/never-fetch/
gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/
Haz que los buckets de Cloud Storage sean legibles de forma pública
Para que todos los objetos de un bucket sean legibles para todos en la Internet pública,
otorga a la principal allUsers
el rol de visualizador de objetos de Storage
(roles/storage.objectViewer
).
Console
A fin de otorgar a todos los usuarios acceso para ver objetos en tus buckets, repite el siguiente procedimiento para cada bucket:
- En la consola de Google Cloud, ve a la página Buckets de Cloud Storage.
En la lista de buckets, haz clic en el nombre del bucket que deseas hacer público.
Selecciona la pestaña Permisos cerca de la parte superior de la página.
En la sección Permisos, haz clic en el botón
Otorgar acceso. Aparecerá el diálogo Otorgar acceso.En el campo Principales nuevas, ingresa
allUsers
.En el campo Seleccionar un rol, ingresa
Storage Object Viewer
en el cuadro de filtro y selecciona Visualizador de objetos de almacenamiento a partir de los resultados filtrados.Haz clic en Guardar.
Haz clic en Permitir acceso público.
gcloud
Para otorgar a todos los usuarios acceso para ver objetos en tus buckets, ejecuta el comando buckets add-iam-policy-binding
.
gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME --member=allUsers --role=roles/storage.objectViewer
gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME --member=allUsers --role=roles/storage.objectViewer
Reemplaza las variables de nombre de bucket por los nombres de bucket únicos de Cloud Storage.
Configura el balanceador de cargas con buckets de backend
En esta sección, se muestra cómo crear los siguientes recursos para un balanceador de cargas de aplicaciones interno multirregional:
- Dos buckets de backend Los buckets de backend funcionan como un wrapper para los buckets de Cloud Storage que creaste antes.
- Mapa de URL
- Proxy de destino
- Dos reglas de reenvío global con direcciones IP regionales. A las reglas de reenvío se les asignan direcciones IP de las subredes creadas para las reglas de reenvío del balanceador de cargas. Si intentas asignar una dirección IP a la regla de reenvío desde la subred de solo proxy, la creación de la regla de reenvío fallará.
En este ejemplo, puedes usar HTTP o HTTPS como el protocolo de solicitud y respuesta entre el cliente y el balanceador de cargas. Si quieres crear un balanceador de cargas de HTTPS, debes agregar un recurso de certificado SSL al frontend del balanceador de cargas.
Para crear los componentes de balanceo de cargas mencionados anteriormente con gcloud CLI, sigue estos pasos:
Crea dos buckets de backend, uno en la región
us-east1
y otro en la regiónasia-east1
con el comandogcloud beta compute backend-buckets create
. Los buckets de backend tienen un esquema de balanceo de cargas deINTERNAL_MANAGED
.gcloud beta compute backend-buckets create backend-bucket-cats \ --gcs-bucket-name=BUCKET1_NAME \ --load-balancing-scheme=INTERNAL_MANAGED
gcloud beta compute backend-buckets create backend-bucket-dogs \ --gcs-bucket-name=BUCKET2_NAME \ --load-balancing-scheme=INTERNAL_MANAGED
Crea un mapa de URL para enrutar las solicitudes entrantes al bucket de backend con el comando
gcloud compute url-maps create
.gcloud compute url-maps create lb-map \ --default-backend-bucket=backend-bucket-cats \ --global
Configura las reglas de host y ruta de acceso del mapa de URL con el comando
gcloud compute url-maps add-path-matcher
.En este ejemplo, el bucket de backend predeterminado es
backend-bucket-cats
, que controla todas las rutas de acceso que existen en él. Sin embargo, cualquier solicitud segmentada parahttp://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg
usa el backend debackend-bucket-dogs
. Por ejemplo, si la carpeta/love-to-fetch/
también existe en tu backend predeterminado (backend-bucket-cats
), el balanceador de cargas prioriza el backendbackend-bucket-dogs
porque hay una regla de ruta específica para/love-to-fetch/*
.gcloud compute url-maps add-path-matcher lb-map \ --path-matcher-name=path-matcher-pets \ --new-hosts=* \ --backend-bucket-path-rules="/love-to-fetch/*=backend-bucket-dogs" \ --default-backend-bucket=backend-bucket-cats
Crea un proxy de destino con el comando
gcloud compute target-http-proxies create
.Para el tráfico HTTP, crea un proxy HTTP de destino para enrutar las solicitudes al mapa de URL:
gcloud compute target-http-proxies create http-proxy \ --url-map=lb-map \ --global
Para el tráfico HTTPS, crea un proxy HTTPS de destino para enrutar las solicitudes al mapa de URL. El proxy es la parte del balanceador de cargas que contiene el certificado SSL para el balanceo de cargas de HTTPS. Después de crear el certificado, puedes adjuntarlo al proxy HTTPS de destino.
gcloud compute target-https-proxies create https-proxy \ --url-map=lb-map \ --certificate-manager-certificates=CERTIFICATE_NAME \ --global
Reemplaza
CERTIFICATE_NAME
por el nombre del certificado SSL que creaste con el Administrador de certificados.Crea dos reglas de reenvío globales, una con una dirección IP en la región
us-east1
y otra con una dirección IP en la regiónasia-east1
con el comandogcloud compute forwarding-rules create
.Si deseas reservar una dirección IP interna estática para la regla de reenvío de tu balanceador de cargas, consulta Reserva una dirección IPv4 o IPv6 interna estática nueva. Reservar una dirección IP es opcional para una regla de reenvío HTTP. Sin embargo, debes reservar una dirección IP para una regla de reenvío HTTPS.
En este ejemplo, una dirección IP efímera está asociada con la regla de reenvío HTTP de tu balanceador de cargas. Una dirección IP efímera permanece constante mientras exista la regla de reenvío. Si necesitas borrar la regla de reenvío y volver a crearla, esta podría recibir una dirección IP nueva.
Para el tráfico HTTP, crea las reglas de reenvío globales para enrutar las solicitudes entrantes al proxy de destino HTTP:
gcloud compute forwarding-rules create http-fw-rule-1 \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=subnet-us \ --subnet-region=us-east1 \ --ports=80 \ --target-http-proxy=http-proxy \ --global-target-http-proxy \ --global
gcloud compute forwarding-rules create http-fw-rule-2 \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=subnet-asia \ --subnet-region=asia-east1 \ --ports=80 \ --target-http-proxy=http-proxy \ --global-target-http-proxy \ --global
Para el tráfico HTTPS, crea las reglas de reenvío globales para enrutar las solicitudes entrantes al proxy de destino HTTPS:
gcloud compute forwarding-rules create https-fw-rule-1 \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=subnet-us \ --subnet-region=us-east1 \ --address=RESERVED_IP_ADDRESS \ --ports=443 \ --target-https-proxy=https-proxy \ --global-target-https-proxy \ --global
gcloud compute forwarding-rules create https-fw-rule-2 \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=subnet-asia \ --subnet-region=asia-east1 \ --address=RESERVED_IP_ADDRESS \ --ports=443 \ --target-https-proxy=https-proxy \ --global-target-https-proxy \ --global
Envía una solicitud HTTP al balanceador de cargas
Envía una solicitud desde una VM de cliente interna a la regla de reenvío del balanceador de cargas.
Obtén la dirección IP de la regla de reenvío del balanceador de cargas
Obtén la dirección IP de la regla de reenvío del balanceador de cargas (
http-fw-rule-1
), que se encuentra en la regiónus-east1
.gcloud compute forwarding-rules describe http-fw-rule-1 \ --global
Obtén la dirección IP de la regla de reenvío del balanceador de cargas (
http-fw-rule-2
), que se encuentra en la regiónasia-east1
.gcloud compute forwarding-rules describe http-fw-rule-2 \ --global
Crea una VM cliente para probar la conectividad
Crea una VM de cliente en la región
us-east1
.gcloud compute instances create client-a \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=lb-network \ --subnet=subnet-us \ --zone=us-east1-c \ --tags=allow-ssh
Establece una conexión SSH a la VM del cliente.
gcloud compute ssh client-a --zone=us-east1-c
En este ejemplo, el balanceador de cargas de aplicaciones interno entre regiones tiene direcciones IP virtuales (VIP) de frontend en las regiones
us-east1
yasia-east1
de la red de VPC. Realiza una solicitud HTTP al VIP en cualquiera de las regiones con curl.curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
curl http://FORWARDING_RULE_IP_ADDRESS/never-fetch/three-cats.jpg --output three-cats.jpg
Cómo probar la alta disponibilidad
Borra la regla de reenvío (
http-fw-rule-1
) en la regiónus-east1
para simular una interrupción regional y verificar si el cliente en la regiónus-east
aún puede acceder a los datos del bucket de backend.gcloud compute forwarding-rules delete http-fw-rule-1 \ --global
Realiza una solicitud HTTP al VIP de la regla de reenvío en cualquiera de las regiones con curl.
curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
curl http://FORWARDING_RULE_IP_ADDRESS/never-fetch/three-cats.jpg --output three-cats.jpg
Si realizaste una solicitud HTTP a la VIP en la región
us-east1
, las políticas de enrutamiento de DNS detectan que esta VIP no responde y muestran la siguiente VIP más óptima al cliente (en este ejemplo,asia-east1
), lo que garantiza que tu aplicación siga funcionando incluso durante las interrupciones regionales.
¿Qué sigue?
- Descripción general del balanceador de cargas de aplicaciones interno
- Subredes de solo proxy para balanceadores de cargas basados en Envoy
- Administrar certificados
- Limpia una configuración de balanceo de cargas