Configura un balanceador de cargas de aplicaciones interno entre regiones con buckets de Cloud Storage

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:

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:

Un balanceador de cargas de aplicaciones interno entre regiones envía tráfico a un backend de Cloud Storage.
Distribución del tráfico a Cloud Storage (haz clic para ampliar).

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ón us-east1 usa 10.1.2.0/24 para su rango de IP principal. Una subred llamada subnet-asia en la región asia-east1 usa 10.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ón us-east1 usa 10.129.0.0/23 para su rango de IP principal. Una subred llamada proxy-only-subnet-asia-east1 en la región asia-east1 usa 10.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

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

    Ir a las redes de VPC

  2. Haz clic en Crear red de VPC.

  3. En Nombre, ingresa lb-network.

  4. En la sección Subredes, establece Modo de creación de subred como Personalizado.

  5. 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
  6. Haz clic en Listo.

  7. Haz clic en Agregar subred.

  8. 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
  9. Haz clic en Listo.

  10. Haz clic en Crear.

gcloud

  1. Crea una red de VPC personalizada, llamada lb-network, con el comando gcloud compute networks create.

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. Crea una subred en la red de VPC lb-network en la región us-east1 con el comando gcloud compute networks subnets create.

    gcloud compute networks subnets create subnet-us \
        --network=lb-network \
        --range=10.1.2.0/24 \
        --region=us-east1
    
  3. Crea una subred en la red de VPC lb-network en la región asia-east1 con el comando gcloud 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

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

    Ir a las redes de VPC

  2. Haz clic en el nombre de la red de VPC que creaste.

  3. En la pestaña Subred, haz clic en Agregar subred.

  4. Ingresa la siguiente información:

    • Nombre: proxy-only-subnet-us
    • Región: us-east1
    • Rango de direcciones IP: 10.129.0.0/23
  5. Haz clic en Agregar.

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

  7. Ingresa la siguiente información:

    • Nombre: proxy-only-subnet-asia
    • Región: asia-east1
    • Rango de direcciones IP: 10.130.0.0/23
  8. Haz clic en Agregar.

gcloud

  1. Crea una subred de solo proxy en la región us-east1 con el comando gcloud 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
    
  2. Crea una subred de solo proxy en la región asia-east1 con el comando gcloud 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 llama fw-allow-ssh.

Console

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

    Ir a Políticas de firewall

  2. 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.
  3. Haz clic en Crear.

gcloud

  1. Crea la regla de firewall fw-allow-ssh para permitir la conectividad SSH a las VM con la etiqueta de red allow-ssh. Cuando omites --source-ranges,Google Cloud interpreta que la regla significa cualquier fuente.

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    

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

  1. En la consola de Google Cloud, ve a la página Buckets de Cloud Storage.

    Ir a Buckets

  2. Haga clic en Crear.

  3. En el cuadro Asigna un nombre a tu bucket, ingresa un nombre global único que siga los lineamientos de nomenclatura.

  4. Haz clic en Elige dónde almacenar tus datos.

  5. Configura Tipo de ubicación como Región.

  6. En la lista de regiones, selecciona us-east1.

  7. Haz clic en Crear.

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

  1. Crea el primer bucket en la región us-east1 con el comando gcloud storage buckets create.

    gcloud storage buckets create gs://BUCKET1_NAME \
        --default-storage-class=standard \
        --location=us-east1 \
        --uniform-bucket-level-access
    
  2. Crea el segundo bucket en la región asia-east1 con el comando gcloud 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:

  1. En la consola de Google Cloud, ve a la página Buckets de Cloud Storage.

    Ir a Buckets

  2. En la lista de buckets, haz clic en el nombre del bucket que deseas hacer público.

  3. Selecciona la pestaña Permisos cerca de la parte superior de la página.

  4. En la sección Permisos, haz clic en el botón Otorgar acceso. Aparecerá el diálogo Otorgar acceso.

  5. En el campo Principales nuevas, ingresa allUsers.

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

  7. Haz clic en Guardar.

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

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:

  1. Crea dos buckets de backend, uno en la región us-east1 y otro en la región asia-east1 con el comando gcloud beta compute backend-buckets create. Los buckets de backend tienen un esquema de balanceo de cargas de INTERNAL_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
    
  2. 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
    
  3. 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 para http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg usa el backend de backend-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 backend backend-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
    
  4. 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.

  5. 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ón asia-east1 con el comando gcloud 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

  1. 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ón us-east1.

    gcloud compute forwarding-rules describe http-fw-rule-1 \
        --global
    
  2. 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ón asia-east1.

    gcloud compute forwarding-rules describe http-fw-rule-2 \
        --global
    

Crea una VM cliente para probar la conectividad

  1. 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
    
  2. Establece una conexión SSH a la VM del cliente.

    gcloud compute ssh client-a --zone=us-east1-c
    
  3. En este ejemplo, el balanceador de cargas de aplicaciones interno entre regiones tiene direcciones IP virtuales (VIP) de frontend en las regiones us-east1 y asia-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

  1. Borra la regla de reenvío (http-fw-rule-1) en la región us-east1 para simular una interrupción regional y verificar si el cliente en la región us-east aún puede acceder a los datos del bucket de backend.

    gcloud compute forwarding-rules delete http-fw-rule-1 \
        --global
    
  2. 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?