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:
- Implemente um certificado gerido pela Google em várias regiões emitido pela sua instância do CA Service
- Implemente um certificado gerido pela Google em várias regiões com autorização de DNS
- Implemente um certificado autogerido em várias regiões
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:
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ãous-east1
usa10.1.2.0/24
para o respetivo intervalo de IP principal. Uma sub-rede denominadasubnet-asia
na regiãoasia-east1
usa10.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ãous-east1
usa10.129.0.0/23
para o respetivo intervalo de IP principal. Uma sub-rede denominadaproxy-only-subnet-asia-east1
na regiãoasia-east1
usa10.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
Na Google Cloud consola, aceda à página Redes VPC.
Clique em Criar rede de VPC.
Em Nome, introduza
lb-network
.Na secção Sub-redes, defina o Modo de criação de sub-redes como Personalizado.
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
- Nome:
Clique em Concluído.
Clique em Adicionar sub-rede.
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
- Nome:
Clique em Concluído.
Clique em Criar.
gcloud
Crie uma rede VPC personalizada, denominada
lb-network
, com o comandogcloud compute networks create
.gcloud compute networks create lb-network --subnet-mode=custom
Crie uma sub-rede na
lb-network
rede de VPC na regiãous-east1
com o comandogcloud compute networks subnets create
.gcloud compute networks subnets create subnet-us \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-east1
Crie uma sub-rede na
lb-network
rede de VPC na regiãoasia-east1
com o comandogcloud 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
Na Google Cloud consola, aceda à página Redes VPC.
Clique no nome da rede de VPC que criou.
No separador Sub-rede, clique em Adicionar sub-rede.
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
.
- Em Nome, introduza
Clique em Adicionar.
Crie outra sub-rede só de proxy na região
asia-east1
. No separador Sub-rede, clique em Adicionar sub-rede.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
.
- Em Nome, introduza
Clique em Adicionar.
gcloud
Crie uma sub-rede só de proxy na região
us-east1
com o 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
Crie uma sub-rede só de proxy na região
asia-east1
com o 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
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-sefw-allow-ssh
.
Consola
Na Google Cloud consola, aceda à página Políticas de firewall.
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.
- Nome:
Clique em Criar.
gcloud
Crie a regra de firewall
fw-allow-ssh
para permitir a conetividade SSH a VMs com a etiqueta de redeallow-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
- Na Google Cloud consola, aceda à página Recipientes do Cloud Storage.
Clique em
Criar.Na caixa Dê um nome ao seu contentor, introduza um nome globalmente exclusivo que siga as diretrizes de nomenclatura.
Clique em Escolher onde quer armazenar os seus dados.
Defina o Tipo de localização como Região.
Na lista de regiões, selecione us-east1.
Clique em Criar.
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
Crie o primeiro contentor na região
us-east1
com o comandogcloud storage buckets create
.gcloud storage buckets create gs://BUCKET1_NAME \ --default-storage-class=standard \ --location=us-east1 \ --uniform-bucket-level-access
Crie o segundo contentor na região
asia-east1
com o comandogcloud 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:
- Na Google Cloud consola, aceda à página Recipientes do Cloud Storage.
Na lista de contentores, clique no nome do contentor que quer tornar público.
Selecione o separador Permissões junto à parte superior da página.
Na secção Autorizações, clique no botão
Conceder acesso. É apresentada a caixa de diálogo Conceder acesso.No campo Novos principais, introduza
allUsers
.No campo Selecionar uma função, introduza
Storage Object Viewer
na caixa de filtro e selecione Visualizador de objetos do Storage nos resultados filtrados.Clique em Guardar.
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:
- Dois contentores de back-end. Os contentores de back-end funcionam como um wrapper para os contentores do Cloud Storage que criou anteriormente.
- Mapa do URL
- Proxy de destino
- Duas regras de encaminhamento globais com endereços IP regionais. As regras de encaminhamento são atribuídas a endereços IP das sub-redes criadas para as regras de encaminhamento do balanceador de carga. Se tentar atribuir um endereço IP à regra de encaminhamento a partir da sub-rede apenas proxy, a criação da regra de encaminhamento falha.
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:
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 deINTERNAL_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
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
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çãohttp://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg
usa o back-endbackend-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-endbackend-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
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.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ãoasia-east1
com o comandogcloud 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
Obtenha o endereço IP da regra de encaminhamento do balanceador de carga (
http-fw-rule-1
), que se encontra na regiãous-east1
.gcloud compute forwarding-rules describe http-fw-rule-1 \ --global
Obtenha o endereço IP da regra de encaminhamento do balanceador de carga (
http-fw-rule-2
), que se encontra na regiãoasia-east1
.gcloud compute forwarding-rules describe http-fw-rule-2 \ --global
Crie uma VM de cliente para testar a conetividade
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
Estabeleça uma ligação SSH à VM do cliente.
gcloud compute ssh client-a --zone=us-east1-c
Neste exemplo, o Application Load Balancer interno entre regiões tem endereços IP virtuais (VIP) de front-end nas regiões
us-east1
easia-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
Elimine a regra de encaminhamento (
http-fw-rule-1
) na regiãous-east1
para simular uma indisponibilidade regional e verifique se o cliente na regiãous-east
ainda consegue aceder aos dados do contentor de back-end.gcloud compute forwarding-rules delete http-fw-rule-1 \ --global
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?
- Vista geral do balanceador de carga de aplicações interno
- Sub-redes só de proxy para balanceadores de carga baseados no Envoy
- Faça a gestão de certificados
- Limpe uma configuração de equilíbrio de carga