Configure um Application Load Balancer interno entre regiões com contentores do Cloud Storage

Este documento mostra como criar um Application Load Balancer interno entre regiões para encaminhar pedidos de conteúdo estático para contentores do Cloud Storage.

Antes de começar

Certifique-se de que a configuração cumpre os seguintes pré-requisitos.

Instale a CLI Google Cloud

Algumas das instruções neste guia só podem ser executadas através da CLI do Google Cloud. Para a instalar, consulte o documento Instale a CLI gcloud.

Pode encontrar comandos relacionados com o equilíbrio de carga no documento Referências da API e da CLI gcloud.

Autorizações

Para seguir este guia, tem de criar contentores do Cloud Storage e recursos de rede no seu projeto. Tem de ser proprietário ou editor do projeto, ou ter as seguintes funções IAM do Compute Engine:

Tarefa Função necessária
Crie redes, sub-redes e componentes do balanceador de carga Função de administrador de rede de computação (roles/compute.networkAdmin)
Adicione e remova regras de firewall Função de administrador de segurança do Compute (roles/compute.securityAdmin)
Crie contentores do Cloud Storage Função de administrador de objetos de armazenamento (roles/storage.objectAdmin)

Para mais informações, consulte os seguintes guias:

Configure um recurso de certificado SSL

Para um Application Load Balancer interno entre regiões que usa HTTPS como o protocolo de pedido e resposta, crie um recurso de certificado SSL com o Certificate Manager, conforme descrito num dos seguintes documentos:

Depois de criar o certificado, pode anexá-lo ao proxy de destino HTTPS.

Recomendamos a utilização de um certificado gerido pela Google.

Limitações

As seguintes limitações aplicam-se aos contentores do Cloud Storage quando atuam como back-ends de um balanceador de carga de aplicações interno entre regiões:

  • O acesso privado ao contentor não é suportado, pelo que o contentor de back-end tem de estar acessível publicamente através da Internet.

  • Os URLs assinados não são suportados.

  • A integração da RFC na nuvem não está disponível quando cria contentores de back-end para um balanceador de carga de aplicações interno entre regiões.

  • Quando usar um Application Load Balancer interno entre regiões para aceder a contentores de back-end, apenas o método HTTP GET é suportado. Pode transferir conteúdo do contentor, mas o carregamento de conteúdo para o contentor através do Application Load Balancer interno entre regiões não está disponível.

  • Não pode configurar um Application Load Balancer interno entre regiões com contentores do Cloud Storage num ambiente de VPC partilhada.

Vista geral da configuração

Pode configurar um Application Load Balancer interno entre regiões em várias regiões, conforme mostrado no diagrama seguinte:

Um Application Load Balancer interno entre regiões envia tráfego para um back-end do Cloud Storage.
Distribuir tráfego para o Cloud Storage (clique para aumentar).

Conforme mostrado no diagrama de arquitetura, este exemplo cria um equilibrador de carga de aplicações interno entre regiões numa rede da nuvem virtual privada (VPC) com dois contentores de back-end, em que cada contentor de back-end faz referência a um contentor do Cloud Storage. Os contentores do Cloud Storage estão localizados na região us-east1 e asia-east1.

Esta arquitetura de implementação oferece alta disponibilidade. Se o Application Load Balancer interno entre regiões numa região falhar, as políticas de encaminhamento de DNS encaminham o tráfego para um Application Load Balancer interno entre regiões noutra região.

Configure a rede e as sub-redes

Na rede VPC, configure uma sub-rede em cada região onde a regra de encaminhamento dos seus balanceadores de carga vai ser configurada. Além disso, configure um proxy-only-subnet em cada região na qual quer configurar o equilibrador de carga.

Este exemplo usa a seguinte rede de VPC, região e sub-redes:

  • Rede. A rede é uma rede VPC no modo personalizado denominada lb-network.

  • Sub-redes para o balanceador de carga. Uma sub-rede denominada subnet-us na região us-east1 usa 10.1.2.0/24 para o respetivo intervalo de IP principal. Uma sub-rede denominada subnet-asia na região asia-east1 usa 10.1.3.0/24 para o respetivo intervalo de IP principal.

  • Sub-rede para proxies Envoy. Uma sub-rede denominada proxy-only-subnet-us-east1 na região us-east1 usa 10.129.0.0/23 para o respetivo intervalo de IP principal. Uma sub-rede denominada proxy-only-subnet-asia-east1 na região asia-east1 usa 10.130.0.0/23 para o respetivo intervalo de IP principal.

É possível aceder aos balanceadores de carga de aplicações internos entre regiões a partir de qualquer região na VPC. Assim, os clientes de qualquer região podem aceder globalmente aos back-ends do balanceador de carga.

Configure as sub-redes para a regra de encaminhamento do balanceador de carga

Consola

  1. Na Google Cloud consola, aceda à página Redes VPC.

    Aceda a redes de VPC

  2. Clique em Criar rede de VPC.

  3. Em Nome, introduza lb-network.

  4. Na secção Sub-redes, defina o Modo de criação de sub-redes como Personalizado.

  5. Na secção Nova sub-rede, introduza as seguintes informações:

    • Nome: subnet-us
    • Selecione uma região: us-east1
    • Intervalo de endereços IP: 10.1.2.0/24
  6. Clique em Concluído.

  7. Clique em Adicionar sub-rede.

  8. Crie outra sub-rede para a regra de encaminhamento do balanceador de carga numa região diferente. Na secção Nova sub-rede, introduza as seguintes informações:

    • Nome: subnet-asia
    • Região: asia-east1
    • Intervalo de endereços IP: 10.1.3.0/24
  9. Clique em Concluído.

  10. Clique em Criar.

gcloud

  1. Crie uma rede VPC personalizada, denominada lb-network, com o comando gcloud compute networks create.

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. Crie uma sub-rede na lb-networkrede de VPC na região us-east1 com o 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. Crie uma sub-rede na lb-networkrede de VPC na região asia-east1 com o 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
    

Configure as sub-redes só de proxy

Uma sub-rede só de proxy fornece um conjunto de endereços IP que o Google Cloud usa para executar proxies Envoy em seu nome. Google Cloud Os proxies terminam as ligações do cliente e criam novas ligações aos backends.

Esta sub-rede apenas de proxy é usada por todos os equilibradores de carga regionais baseados no Envoy na mesma região que a rede VPC. Só pode existir uma sub-rede apenas de proxy ativa para uma determinada finalidade, por região e por rede. Neste exemplo, criamos duas sub-redes apenas de proxy: uma na região us-east1 e outra na região asia-east1.

Consola

  1. Na Google Cloud consola, aceda à página Redes VPC.

    Aceda a redes de VPC

  2. Clique no nome da rede de VPC que criou.

  3. No separador Sub-rede, clique em Adicionar sub-rede.

  4. Introduza as seguintes informações:

    • Em Nome, introduza proxy-only-subnet-us.
    • Para Região, introduza us-east1.
    • Em Finalidade, selecione Proxy gerido entre regiões.
    • Para o Intervalo de endereços IP, introduza 10.129.0.0/23.
  5. Clique em Adicionar.

  6. Crie outra sub-rede só de proxy na região asia-east1. No separador Sub-rede, clique em Adicionar sub-rede.

  7. Introduza as seguintes informações:

    • Em Nome, introduza proxy-only-subnet-asia.
    • Para Região, introduza asia-east1.
    • Em Finalidade, selecione Proxy gerido entre regiões.
    • Para o Intervalo de endereços IP, introduza 10.130.0.0/23.
  8. Clique em Adicionar.

gcloud

  1. Crie uma sub-rede só de proxy na região us-east1 com o 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. Crie uma sub-rede só de proxy na região asia-east1 com o 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
    

Configure uma regra de firewall

Este exemplo usa a seguinte regra de firewall:

  • Uma regra de entrada que permite o acesso SSH na porta 22 à VM do cliente. Neste exemplo, esta regra de firewall chama-se fw-allow-ssh.

Consola

  1. Na Google Cloud consola, aceda à página Políticas de firewall.

    Aceder a Políticas de firewall

  2. Clique em Criar regra de firewall para criar a regra que permite ligações SSH de entrada na VM do cliente:

    • Nome: fw-allow-ssh
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação na correspondência: Permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de segmentação: allow-ssh
    • Filtro de origem: intervalos IPv4
    • Intervalos IPv4 de origem: 0.0.0.0/0
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Selecione a caixa de verificação TCP e, de seguida, introduza 22 para o número da porta.
  3. Clique em Criar.

gcloud

  1. Crie a regra de firewall fw-allow-ssh para permitir a conetividade SSH a VMs com a etiqueta de rede allow-ssh. Quando omite --source-ranges, Google Cloud interpreta a regra como qualquer origem.

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

Configure os contentores do Cloud Storage

O processo de configuração dos seus contentores do Cloud Storage é o seguinte:

  • Crie os contentores.
  • Copie conteúdo para os contentores.

Crie contentores do Cloud Storage

Neste exemplo, cria dois contentores do Cloud Storage, um na região us-east1 e outro na região asia-east1. Para implementações de produção, recomendamos que escolha um contentor de várias regiões, que replica automaticamente os objetos em várias Google Cloud regiões. Isto pode melhorar a disponibilidade do seu conteúdo e melhorar a tolerância a falhas na sua aplicação.

Consola

  1. Na Google Cloud consola, aceda à página Recipientes do Cloud Storage.

    Aceda a Recipientes

  2. Clique em Criar.

  3. Na caixa Dê um nome ao seu contentor, introduza um nome globalmente exclusivo que siga as diretrizes de nomenclatura.

  4. Clique em Escolher onde quer armazenar os seus dados.

  5. Defina o Tipo de localização como Região.

  6. Na lista de regiões, selecione us-east1.

  7. Clique em Criar.

  8. Clique em Recipientes para regressar à página de recipientes do Cloud Storage. Use estas instruções para criar um segundo contentor, mas defina a Localização como asia-east1.

gcloud

  1. Crie o primeiro contentor na região us-east1 com o comando gcloud storage buckets create.

    gcloud storage buckets create gs://BUCKET1_NAME \
        --default-storage-class=standard \
        --location=us-east1 \
        --uniform-bucket-level-access
    
  2. Crie o segundo contentor na região asia-east1 com o comando gcloud storage buckets create.

    gcloud storage buckets create gs://BUCKET2_NAME \
        --default-storage-class=standard \
        --location=asia-east1 \
        --uniform-bucket-level-access
    

Substitua as variáveis BUCKET1_NAME e BUCKET2_NAME pelos nomes dos contentores do Cloud Storage.

Copie ficheiros gráficos para os seus contentores do Cloud Storage

Para lhe permitir testar a configuração, copie um ficheiro gráfico de um contentor do Cloud Storage público para os seus próprios contentores do Cloud Storage.

Execute os seguintes comandos no Cloud Shell, substituindo as variáveis do nome do contentor pelos nomes dos seus contentores do Cloud Storage exclusivos:

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/

Torne os seus contentores do Cloud Storage legíveis publicamente

Para tornar todos os objetos num contentor legíveis para todos na Internet pública, conceda ao principal allUsers a função de leitor de objetos do armazenamento (roles/storage.objectViewer).

Consola

Para conceder a todos os utilizadores acesso à visualização de objetos nos seus contentores, repita o seguinte procedimento para cada contentor:

  1. Na Google Cloud consola, aceda à página Recipientes do Cloud Storage.

    Aceda a Recipientes

  2. Na lista de contentores, clique no nome do contentor que quer tornar público.

  3. Selecione o separador Permissões junto à parte superior da página.

  4. Na secção Autorizações, clique no botão Conceder acesso. É apresentada a caixa de diálogo Conceder acesso.

  5. No campo Novos principais, introduza allUsers.

  6. No campo Selecionar uma função, introduza Storage Object Viewer na caixa de filtro e selecione Visualizador de objetos do Storage nos resultados filtrados.

  7. Clique em Guardar.

  8. Clique em Permitir acesso público.

gcloud

Para conceder a todos os utilizadores acesso à visualização de objetos nos seus contentores, execute o 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

Substitua as variáveis do nome do contentor pelos nomes únicos dos seus contentores do Cloud Storage.

Configure o balanceador de carga com contentores de back-end

Esta secção mostra como criar os seguintes recursos para um balanceador de carga de aplicações interno entre regiões:

Neste exemplo, pode usar HTTP ou HTTPS como o protocolo de pedido e resposta entre o cliente e o balanceador de carga. Para criar um balanceador de carga HTTPS, tem de adicionar um recurso de certificado SSL ao front-end do balanceador de carga.

Para criar os componentes de equilíbrio de carga mencionados acima através da CLI gcloud, siga estes passos:

  1. Crie dois contentores de back-end, um para cada contentor do Cloud Storage, com o comando gcloud compute backend-buckets create. Os contentores de back-end têm um esquema de balanceamento de carga de INTERNAL_MANAGED.

    gcloud compute backend-buckets create backend-bucket-cats \
        --gcs-bucket-name=BUCKET1_NAME \
        --load-balancing-scheme=INTERNAL_MANAGED
    
    gcloud compute backend-buckets create backend-bucket-dogs \
        --gcs-bucket-name=BUCKET2_NAME \
        --load-balancing-scheme=INTERNAL_MANAGED
    
  2. Crie um mapa de URLs para encaminhar pedidos recebidos para o contentor de back-end com o comando gcloud compute url-maps create.

    gcloud compute url-maps create lb-map \
        --default-backend-bucket=backend-bucket-cats \
        --global
    
  3. Configure as regras de anfitrião e caminho do mapa de URLs com o comando gcloud compute url-maps add-path-matcher.

    Neste exemplo, o bucket de back-end predefinido é backend-bucket-cats, que processa todos os caminhos existentes no mesmo. No entanto, qualquer pedido de segmentação http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg usa o back-end backend-bucket-dogs. Por exemplo, se a pasta /love-to-fetch/ também existir no seu back-end predefinido (backend-bucket-cats), o balanceador de carga dá prioridade ao back-end backend-bucket-dogs porque existe uma regra de caminho 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. Crie um proxy de destino com o comando gcloud compute target-http-proxies create.

    Para o tráfego HTTP, crie um proxy HTTP de destino para encaminhar pedidos para o mapa de URLs:

    gcloud compute target-http-proxies create http-proxy \
        --url-map=lb-map \
        --global
    

    Para o tráfego HTTPS, crie um proxy HTTPS de destino para encaminhar pedidos para o mapa de URLs. O proxy é a parte do balanceador de carga que contém o certificado SSL para um balanceador de carga HTTPS. Depois de criar o certificado, pode anexá-lo ao proxy de destino HTTPS.

    gcloud compute target-https-proxies create https-proxy \
        --url-map=lb-map \
        --certificate-manager-certificates=CERTIFICATE_NAME \
        --global
    

    Substitua CERTIFICATE_NAME pelo nome do certificado SSL que criou com o Gestor de certificados.

  5. Crie duas regras de encaminhamento global, uma com um endereço IP na região us-east1 e outra com um endereço IP na região asia-east1 com o comando gcloud compute forwarding-rules create.

    Se quiser reservar um endereço IP interno estático para a regra de encaminhamento do balanceador de carga, consulte o artigo Reserve um endereço IP interno estático. Reservar um endereço IP é opcional para uma regra de encaminhamento HTTP; no entanto, tem de reservar um endereço IP para uma regra de encaminhamento HTTPS.

    Neste exemplo, um endereço IP efémero está associado à regra de encaminhamento HTTP do balanceador de carga. Um endereço IP efémero permanece constante enquanto a regra de encaminhamento existir. Se precisar de eliminar a regra de encaminhamento e recriá-la, a regra de encaminhamento pode receber um novo endereço IP.

    Para o tráfego HTTP, crie as regras de encaminhamento globais para encaminhar os pedidos recebidos para o proxy HTTP de destino:

    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 o tráfego HTTPS, crie as regras de encaminhamento globais para encaminhar os pedidos recebidos para o proxy HTTPS de destino:

    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
    

Envie um pedido HTTP para o balanceador de carga

Envie um pedido de uma VM de cliente interna para a regra de encaminhamento do balanceador de carga.

Obtenha o endereço IP da regra de encaminhamento do balanceador de carga

  1. Obtenha o endereço IP da regra de encaminhamento do balanceador de carga (http-fw-rule-1), que se encontra na região us-east1.

    gcloud compute forwarding-rules describe http-fw-rule-1 \
        --global
    
  2. Obtenha o endereço IP da regra de encaminhamento do balanceador de carga (http-fw-rule-2), que se encontra na região asia-east1.

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

Crie uma VM de cliente para testar a conetividade

  1. Crie uma VM de cliente na região 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. Estabeleça uma ligação SSH à VM do cliente.

    gcloud compute ssh client-a --zone=us-east1-c
    
  3. Neste exemplo, o Application Load Balancer interno entre regiões tem endereços IP virtuais (VIP) de front-end nas regiões us-east1 e asia-east1 na rede VPC. Faça um pedido HTTP ao VIP em qualquer uma das regiões através do 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
    

Teste a alta disponibilidade

  1. Elimine a regra de encaminhamento (http-fw-rule-1) na região us-east1 para simular uma indisponibilidade regional e verifique se o cliente na região us-east ainda consegue aceder aos dados do contentor de back-end.

    gcloud compute forwarding-rules delete http-fw-rule-1 \
        --global
    
  2. Faça um pedido HTTP ao VIP da regra de encaminhamento em qualquer uma das regiões através do 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
    

    Se fizer um pedido HTTP ao VIP na região us-east1, as políticas de encaminhamento de DNS detetam que este VIP não está a responder e devolvem o VIP mais adequado seguinte ao cliente (neste exemplo, asia-east1). Este comportamento ajuda a garantir que a sua aplicação permanece ativa mesmo durante interrupções regionais.

O que se segue?