Este documento fornece instruções para configurar um Application Load Balancer interno entre regiões para os seus serviços executados em instâncias de máquinas virtuais (VMs) do Compute Engine.
Antes de começar
Antes de seguir este guia, familiarize-se com o seguinte:
- Vista geral do equilibrador de carga de aplicações interno, incluindo a secção Limitações
- Vista geral das regras de firewall de VPC
Configure um recurso de certificado SSL
Crie um recurso de certificado SSL do Certificate Manager, conforme descrito no seguinte:
- Implemente um certificado autogerido global.
- Crie um certificado gerido pela Google emitido pela sua instância do Certificate Authority Service.
- Crie um certificado gerido pela Google com autorização de DNS.
Recomendamos a utilização de um certificado gerido pela Google.
Autorizações
Para seguir este guia, tem de conseguir criar instâncias e modificar uma rede num projeto. Tem de ser proprietário ou editor do projeto, ou ter todas as funções do IAM do Compute Engine seguintes.
| Tarefa | Função necessária |
|---|---|
| Crie redes, sub-redes e componentes do balanceador de carga | Administrador de rede de Calcular |
| Adicione e remova regras de firewall | Administrador de segurança de computação |
| Crie instâncias | Administrador de instâncias do Compute |
Para mais informações, consulte os seguintes guias:
Vista geral da configuração
Pode configurar o equilibrador de carga, conforme mostrado no diagrama seguinte:
Conforme mostrado no diagrama, este exemplo cria um Application Load Balancer interno entre regiões numa rede VPC, com um serviço de back-end e dois grupos de instâncias geridos de back-end nas regiões REGION_A e REGION_B.
O diagrama mostra o seguinte:
Uma rede da VPC com as seguintes sub-redes:
- Sub-rede
SUBNET_Ae uma sub-rede só de proxy emREGION_A. - Sub-rede
SUBNET_Be uma sub-rede só de proxy emREGION_B.
Tem de criar sub-redes apenas de proxy em cada região de uma rede VPC onde usa balanceadores de carga de aplicações internos entre regiões. A sub-rede apenas de proxy da região é partilhada entre todos os balanceadores de carga de aplicações internos entre regiões na região. Os endereços de origem dos pacotes enviados do balanceador de carga para os back-ends do seu serviço são atribuídos a partir da sub-rede apenas de proxy. Neste exemplo, a sub-rede apenas de proxy para a região
REGION_Atem um intervalo de endereços IP principal de10.129.0.0/23e, paraREGION_B, tem um intervalo de endereços IP principal de10.130.0.0/23, que é o tamanho de sub-rede recomendado.- Sub-rede
A configuração de alta disponibilidade tem back-ends de grupos de instâncias geridas para implementações de VMs do Compute Engine nas regiões
REGION_AeREGION_B. Se os back-ends numa região estiverem inativos, o tráfego é transferido para a outra região.Um serviço de back-end global que monitoriza a utilização e o estado de funcionamento dos back-ends.
Um mapa de URLs global que analisa o URL de um pedido e encaminha pedidos para serviços de back-end específicos com base no anfitrião e no caminho do URL do pedido.
Um proxy HTTP ou HTTPS de destino global recebe um pedido do utilizador e encaminha-o para o mapa de URLs. Para HTTPS, configure um recurso de certificado SSL global. O proxy de destino usa o certificado SSL para desencriptar o tráfego SSL se configurar o equilíbrio de carga HTTPS. O proxy de destino pode encaminhar o tráfego para as suas instâncias através de HTTP ou HTTPS.
As regras de encaminhamento global têm o endereço IP interno regional do seu balanceador de carga para encaminhar cada pedido recebido para o proxy de destino.
O endereço IP interno associado à regra de encaminhamento pode ser proveniente de uma sub-rede na mesma rede e região que os back-ends. Tenha em atenção as seguintes condições:
- O endereço IP pode (mas não tem de) ser proveniente da mesma sub-rede que os grupos de instâncias de back-end.
- O endereço IP não pode ser proveniente de uma sub-rede só de proxy reservada com a respetiva flag
--purposedefinida comoGLOBAL_MANAGED_PROXY. - Se quiser usar o mesmo endereço IP interno com várias regras de encaminhamento,
defina a flag
--purposedo endereço IP comoSHARED_LOADBALANCER_VIP.
Opcional: configure políticas de encaminhamento de DNS do tipo
GEOpara encaminhar o tráfego de clientes para o VIP do balanceador de carga na região mais próxima do cliente.
Configure a rede e as sub-redes
Na rede VPC, configure uma sub-rede em cada região onde os seus back-ends estão configurados. Além disso, configure um proxy-only-subnet
em cada região onde 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
NETWORK.Sub-redes para back-ends.
- Uma sub-rede denominada
SUBNET_Ana regiãoREGION_Ausa10.1.2.0/24para o respetivo intervalo de IP principal. - Uma sub-rede denominada
SUBNET_Bna regiãoREGION_Busa10.1.3.0/24para o respetivo intervalo de IP principal.
- Uma sub-rede denominada
Sub-redes para proxies.
- Uma sub-rede denominada
PROXY_SN_Ana regiãoREGION_Ausa10.129.0.0/23para o respetivo intervalo de IP principal. - Uma sub-rede denominada
PROXY_SN_Bna regiãoREGION_Busa10.130.0.0/23para o respetivo intervalo de IP principal.
- Uma sub-rede denominada
É 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 de back-end
Consola
Na Google Cloud consola, aceda à página Redes VPC.
Clique em Criar rede de VPC.
Indique um Nome para a rede.
Na secção Sub-redes, defina o Modo de criação de sub-redes como Personalizado.
Crie uma sub-rede para os back-ends do balanceador de carga. Na secção Nova sub-rede, introduza as seguintes informações:
- Indique um Nome para a sub-rede.
- Selecione uma região: REGION_A
- Introduza um intervalo de endereços IP:
10.1.2.0/24
Clique em Concluído.
Clique em Adicionar sub-rede.
Crie uma sub-rede para os back-ends do balanceador de carga. Na secção Nova sub-rede, introduza as seguintes informações:
- Indique um Nome para a sub-rede.
- Selecione uma região: REGION_B
- Introduza um intervalo de endereços IP:
10.1.3.0/24
Clique em Concluído.
Clique em Criar.
gcloud
Crie a rede VPC personalizada com o comando
gcloud compute networks create:gcloud compute networks create NETWORK \ --subnet-mode=customCrie uma sub-rede na rede
NETWORKna regiãoREGION_Acom o comandogcloud compute networks subnets create:gcloud compute networks subnets create SUBNET_A \ --network=NETWORK \ --range=10.1.2.0/24 \ --region=REGION_ACrie uma sub-rede na rede
NETWORKna regiãoREGION_Bcom o 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 criar a rede VPC, use o recurso google_compute_network.
Para criar as sub-redes VPC na rede lb-network-crs-reg, use o recurso google_compute_subnetwork.
API
Faça um pedido POST ao
método networks.insert.
Substitua PROJECT_ID pelo ID do seu projeto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks
{
"routingConfig": {
"routingMode": "regional"
},
"name": "NETWORK",
"autoCreateSubnetworks": false
}
Faça um pedido POST ao
método subnetworks.insert.
Substitua PROJECT_ID pelo ID do seu projeto.
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",
}
Faça um pedido POST ao
método subnetworks.insert.
Substitua PROJECT_ID pelo ID do seu projeto.
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",
}
Configure a sub-rede só de proxy
Uma sub-rede apenas de proxy fornece um conjunto de endereços IP que Google Cloud usa para executar proxies Envoy em seu nome. 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 só de proxy ativa para uma determinada finalidade, por região e por rede.
Consola
Se estiver a usar a Google Cloud consola, pode esperar e criar a sub-rede apenas de proxy mais tarde na página Equilíbrio de carga.
Se quiser criar a sub-rede apenas de proxy agora, siga estes passos:
Na Google Cloud consola, aceda à página Redes VPC.
- Clique no nome da rede de VPC.
- No separador Sub-rede, clique em Adicionar sub-rede.
- Indique um nome para a sub-rede só de proxy.
- Selecione uma região: REGION_A
- Na lista Finalidade, selecione Proxy gerido entre regiões.
- No campo Intervalo de endereços IP, introduza
10.129.0.0/23. - Clique em Adicionar.
Crie a sub-rede só de proxy em REGION_B
- No separador Sub-rede, clique em Adicionar sub-rede.
- Indique um nome para a sub-rede só de proxy.
- Selecione uma região: REGION_B
- Na lista Finalidade, selecione Proxy gerido entre regiões.
- No campo Intervalo de endereços IP, introduza
10.130.0.0/23. - Clique em Adicionar.
gcloud
Crie as sub-redes só de proxy com o 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 criar a sub-rede apenas de proxy da VPC na rede lb-network-crs-reg, use o recurso google_compute_subnetwork.
API
Crie as sub-redes só de proxy com o método
subnetworks.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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"
}
Configure regras de firewall
Este exemplo usa as seguintes regras de firewall:
fw-ilb-to-backends. Uma regra de entrada, aplicável às instâncias com balanceamento de carga, que permite a conetividade SSH de entrada na porta TCP
22a partir de qualquer endereço. Pode escolher um intervalo de endereços IP de origem mais restritivo para esta regra. Por exemplo, pode especificar apenas os intervalos de endereços IP do sistema a partir do qual inicia sessões SSH. Este exemplo usa a etiqueta de destinoallow-sshpara identificar as VMs às quais a regra de firewall se aplica.fw-healthcheck. Uma regra de entrada, aplicável às instâncias com balanceamento de carga, que permite todo o tráfego TCP dos Google Cloud sistemas de verificação de estado (em
130.211.0.0/22e35.191.0.0/16). Este exemplo usa a etiqueta de destinoload-balanced-backendpara identificar as VMs às quais a regra de firewall se aplica.fw-backends. Uma regra de entrada, aplicável às instâncias com balanceamento de carga, que permite o tráfego TCP nas portas
80,443e8080dos proxies geridos do balanceador de carga de aplicações interno. Este exemplo usa a etiqueta de destinoload-balanced-backendpara identificar as VMs às quais a regra de firewall se aplica.
Sem estas regras de firewall, a regra de negação predefinida de entrada bloqueia o tráfego de entrada para as instâncias de back-end.
As etiquetas de destino definem as instâncias de back-end. Sem as etiquetas de destino, as regras da firewall aplicam-se a todas as instâncias de back-end na rede VPC. Quando criar as VMs de back-end, certifique-se de que inclui as etiquetas de destino especificadas, conforme mostrado em Criar um grupo de instâncias gerido.
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:
- Nome:
fw-ilb-to-backends - Rede: 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
22para o número da porta.
- Nome:
Clique em Criar.
Clique em Criar regra de firewall uma segunda vez para criar a regra que permite as Google Cloud verificações de funcionamento:
- Nome:
fw-healthcheck - Rede: NETWORK
- Direção do tráfego: entrada
- Ação na correspondência: Permitir
- Objetivos: etiquetas de destino especificadas
- Etiquetas de segmentação:
load-balanced-backend - Filtro de origem: intervalos IPv4
- Intervalos de IPv4 de origem:
130.211.0.0/22e35.191.0.0/16 Protocolos e portas:
- Escolha Protocolos e portas especificados.
- Selecione a caixa de verificação TCP e, de seguida, introduza
80para o número da porta.
Como prática recomendada, limite esta regra apenas aos protocolos e às portas que correspondam aos usados pela sua verificação de funcionamento. Se usar
tcp:80para o protocolo e a porta, Google Cloud pode usar o HTTP na porta80para contactar as suas VMs, mas não pode usar o HTTPS na porta443para as contactar.
- Nome:
Clique em Criar.
Clique em Criar regra de firewall pela terceira vez para criar a regra que permite que os servidores proxy do balanceador de carga se liguem aos back-ends:
- Nome:
fw-backends - Rede: NETWORK
- Direção do tráfego: entrada
- Ação na correspondência: Permitir
- Objetivos: etiquetas de destino especificadas
- Etiquetas de segmentação:
load-balanced-backend - Filtro de origem: intervalos IPv4
- Intervalos de IPv4 de origem:
10.129.0.0/23e10.130.0.0/23 - Protocolos e portas:
- Escolha Protocolos e portas especificados.
- Selecione a caixa de verificação TCP e, de seguida, introduza
80, 443, 8080para os números de porta.
- Nome:
Clique em Criar.
gcloud
Crie a regra de firewall
fw-ilb-to-backendspara permitir a conetividade SSH a VMs com a etiqueta de redeallow-ssh. Quando omitesource-ranges, Google Cloud interpreta a regra como qualquer origem.gcloud compute firewall-rules create fw-ilb-to-backends \ --network=NETWORK \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22Crie a regra
fw-healthcheckpara permitir Google Cloud verificações de funcionamento. Este exemplo permite todo o tráfego TCP de sondas de verificação de estado. No entanto, pode configurar um conjunto mais restrito de portas para satisfazer as suas necessidades.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=tcpCrie a regra
fw-backendspara permitir que os proxies do balanceador de carga de aplicações interno se liguem aos seus back-ends. Definasource-rangespara os intervalos atribuídos da sua sub-rede só de proxy, por exemplo,10.129.0.0/23e10.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 criar as regras de firewall, use o recurso google_compute_firewall.
API
Crie a regra de firewall fw-ilb-to-backends fazendo um pedido POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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"
}
Crie a regra de firewall fw-healthcheck fazendo um pedido POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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"
}
Crie a regra de firewall fw-backends para permitir o tráfego TCP na sub-rede de proxy para o método firewalls.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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"
}
Crie um grupo de instâncias geridas
Esta secção mostra como criar um modelo e um grupo de instâncias gerido. O grupo de instâncias gerido fornece instâncias de VM que executam os servidores de back-end de um balanceador de carga de aplicações interno entre regiões de exemplo. Para o seu grupo de instâncias, pode definir um serviço HTTP e mapear um nome de porta para a porta relevante. O serviço de back-end do balanceador de carga encaminha o tráfego para as portas nomeadas. O tráfego dos clientes é equilibrado em termos de carga para os servidores de back-end. Para fins de demonstração, os back-ends publicam os respetivos nomes de anfitriões.
Consola
Na Google Cloud consola, aceda à página Modelos de instâncias.
- Clique em Criar modelo de instância.
- Em Nome, introduza
gil7-backendeast1-template. - Certifique-se de que o Disco de arranque está definido para uma imagem Debian, como
Debian GNU/Linux 12 (bookworm). Estas instruções usam comandos que só estão disponíveis no Debian, como
apt-get. - Clique em Opções avançadas.
- Clique em Rede e configure os seguintes campos:
- Para Etiquetas de rede, introduza
allow-ssheload-balanced-backend. - Para Interfaces de rede, selecione o seguinte:
- Rede: NETWORK
- Subnet: SUBNET_B
- Para Etiquetas de rede, introduza
Clique em Gestão. Introduza o seguinte script no campo Script de arranque.
#! /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
Clique em Criar.
Clique em Criar modelo de instância.
Em Nome, introduza
gil7-backendwest1-template.Certifique-se de que o Disco de arranque está definido para uma imagem Debian, como Debian GNU/Linux 12 (bookworm). Estas instruções usam comandos que só estão disponíveis no Debian, como
apt-get.Clique em Opções avançadas.
Clique em Rede e configure os seguintes campos:
- Para Etiquetas de rede, introduza
allow-ssheload-balanced-backend. - Para Interfaces de rede, selecione o seguinte:
- Rede: NETWORK
- Subnet: SUBNET_A
- Para Etiquetas de rede, introduza
Clique em Gestão. Introduza o seguinte script no campo Script de arranque.
#! /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
Clique em Criar.
Na Google Cloud consola, aceda à página Grupos de instâncias.
- Clique em Criar grupo de instâncias.
- Selecione Novo grupo de instâncias gerido (sem estado). Para mais informações, consulte o artigo Grupos de instâncias geridos sem estado ou com estado.
- Em Nome, introduza
gl7-ilb-mig-a. - Para Localização, selecione Zona única.
- Para Região, selecione REGION_A.
- Para Zona, selecione ZONE_A.
- Para Modelo de instância, selecione
gil7-backendwest1-template. Especifique o número de instâncias que quer criar no grupo.
Para este exemplo, especifique as seguintes opções em Ajuste automático de escala:
- Para o Modo de ajuste automático de escala, selecione
Off:do not autoscale. - Para Número máximo de instâncias, introduza
2.
Opcionalmente, na secção Ajuste de escala automático da IU, pode configurar o grupo de instâncias para adicionar ou remover automaticamente instâncias com base na utilização do CPU das instâncias.
- Para o Modo de ajuste automático de escala, selecione
Clique em Criar.
Clique em Criar grupo de instâncias.
Selecione Novo grupo de instâncias gerido (sem estado). Para mais informações, consulte o artigo Grupos de instâncias geridos sem estado ou com estado.
Em Nome, introduza
gl7-ilb-mig-b.Para Localização, selecione Zona única.
Para Região, selecione REGION_B.
Para Zona, selecione ZONE_B.
Para Modelo de instância, selecione
gil7-backendeast1-template.Especifique o número de instâncias que quer criar no grupo.
Para este exemplo, especifique as seguintes opções em Ajuste automático de escala:
- Para o Modo de ajuste automático de escala, selecione
Off:do not autoscale. - Para Número máximo de instâncias, introduza
2.
Opcionalmente, na secção Ajuste de escala automático da IU, pode configurar o grupo de instâncias para adicionar ou remover automaticamente instâncias com base na utilização do CPU das instâncias.
- Para o Modo de ajuste automático de escala, selecione
Clique em Criar.
gcloud
As instruções da CLI gcloud neste guia pressupõem que está a usar o Cloud Shell ou outro ambiente com o bash instalado.
Crie um modelo de instância de VM com um servidor HTTP com o 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'Crie um grupo de instâncias gerido na zona com o 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-templategcloud compute instance-groups managed create gl7-ilb-mig-b \ --zone=ZONE_B \ --size=2 \ --template=gil7-backendeast1-template
Terraform
Para criar o modelo de instância, use o recurso google_compute_instance_template.
Para criar o grupo de instâncias gerido, use o recurso google_compute_instance_group_manager.
API
Crie o modelo de instância com o método instanceTemplates.insert, substituindo PROJECT_ID pelo ID do projeto.
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
}
]
}
}
Crie um grupo de instâncias gerido em cada zona com o método instanceGroupManagers.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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
}
]
}
}
Crie um grupo de instâncias gerido em cada zona com o método instanceGroupManagers.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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
}
Configure o balanceador de carga
Este exemplo mostra como criar os seguintes recursos do balanceador de carga de aplicações interno entre regiões:
- Uma verificação de funcionamento de HTTP global.
- Um serviço de back-end global com os grupos de instâncias geridas como back-end.
- Um mapa do URL. Certifique-se de que faz referência a um mapa de URLs global para o proxy HTTP(S) de destino. Um mapa de URLs global encaminha pedidos para um serviço de back-end global com base nas regras que define para o anfitrião e o caminho de um URL recebido. Um mapa de URLs global pode ser referenciado por uma regra de proxy de destino global.
- Um certificado SSL global (para HTTPS).
- Um proxy de destino global.
Duas regras de encaminhamento globais com endereços IP regionais. Para o endereço IP da regra de encaminhamento, use o intervalo de endereços IP
SUBNET_AouSUBNET_B. Se tentar usar a sub-rede apenas de proxy, a criação da regra de encaminhamento falha.
Consola
Selecione o tipo de balanceador de carga
Na Google Cloud consola, aceda à página Equilíbrio de carga.
- Clique em Criar equilibrador de carga.
- Em Tipo de balanceador de carga, selecione Balanceador de carga de aplicações (HTTP/HTTPS) e clique em Seguinte.
- Para Público ou interno, selecione Interno e clique em Seguinte.
- Para a Implementação em várias regiões ou numa única região, selecione Melhor para cargas de trabalho em várias regiões e clique em Seguinte.
- Clique em Configurar.
Configuração básica
- Indique um nome para o balanceador de carga.
- Para Rede, selecione NETWORK.
Configure o front-end com duas regras de encaminhamento
Para HTTP:
- Clique em Configuração do front-end.
- Indique um nome para a regra de encaminhamento.
- Na lista Região da sub-rede, selecione REGION_A.
Reserve uma sub-rede só de proxy
- Na lista Sub-rede, selecione SUBNET_A.
- Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
- Indique um nome para o endereço IP estático.
- Na lista Endereço IP estático, selecione Permitir-me escolher.
- No campo Endereço IP personalizado, introduza
10.1.2.99. - Selecione Reservar.
- Clique em Concluído.
- Para adicionar a segunda regra de encaminhamento, clique em Adicionar IP e porta de front-end.
- Indique um nome para a regra de encaminhamento.
- Na lista Região da sub-rede, selecione REGION_B.
Reserve uma sub-rede só de proxy
- Na lista Sub-rede, selecione SUBNET_B.
- Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
- Indique um nome para o endereço IP estático.
- Na lista Endereço IP estático, selecione Permitir-me escolher.
- No campo Endereço IP personalizado, introduza
10.1.3.99. - Selecione Reservar.
- Clique em Concluído.
Para HTTPS:
Se estiver a usar o protocolo HTTPS entre o cliente e o balanceador de carga,
precisa de um ou mais recursos de certificado SSL para configurar o proxy.
Para criar um all-regionscertificado gerido pela Google, consulte a seguinte documentação:
- Crie um certificado gerido pela Google emitido pela sua instância do Certificate Authority Service.
- Crie um certificado gerido pela Google com autorização de DNS.
Depois de criar o certificado gerido pela Google, anexe o certificado diretamente ao proxy de destino. Os mapas de certificados não são suportados por equilibradores de carga de aplicações internos entre regiões.
Para criar um certificado autogerido all-regions, consulte a seguinte documentação:
Implemente um certificado autogerido regional.
- Clique em Configuração do front-end.
- Indique um nome para a regra de encaminhamento.
- No campo Protocolo, selecione
HTTPS (includes HTTP/2). - Certifique-se de que a Porta está definida como
443. - Na lista Região da sub-rede, selecione REGION_A.
Reserve uma sub-rede só de proxy
- Na lista Sub-rede, selecione SUBNET_A.
- Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
- Indique um nome para o endereço IP estático.
- Na lista Endereço IP estático, selecione Permitir-me escolher.
- No campo Endereço IP personalizado, introduza
10.1.3.99. - Selecione Reservar.
- Na secção Adicionar certificado, selecione o certificado.
- Opcional: para adicionar certificados além do certificado SSL principal:
- Clique em Adicionar certificado.
- Selecione o certificado na lista.
- Selecione uma política SSL na lista Política SSL. Se não tiver criado nenhuma política de SSL, é aplicada uma política de SSL predefinida Google Cloud .
- Clique em Concluído.
- Indique um nome para a configuração do front-end.
- No campo Protocolo, selecione
HTTPS (includes HTTP/2). - Certifique-se de que a Porta está definida como
443. - Na lista Região da sub-rede, selecione REGION_B.
Reserve uma sub-rede só de proxy
- Na lista Sub-rede, selecione SUBNET_B.
- Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
- Indique um nome para o endereço IP estático.
- Na lista Endereço IP estático, selecione Permitir-me escolher.
- No campo Endereço IP personalizado, introduza
10.1.3.99. - Selecione Reservar.
- Na secção Adicionar certificado, selecione o certificado.
- Opcional: para adicionar certificados além do certificado SSL principal:
- Clique em Adicionar certificado.
- Selecione o certificado na lista.
- Selecione uma política SSL na lista Política SSL. Se não tiver criado nenhuma política de SSL, é aplicada uma política de SSL predefinida Google Cloud .
- Clique em Concluído.
- Clique em Configuração de back-end.
- Na lista Criar ou selecionar serviços de back-end, clique em Criar um serviço de back-end.
- Indique um nome para o serviço de back-end.
- Para Protocolo, selecione HTTP.
- Em Porta com nome, introduza
http. - Na lista Tipo de back-end, selecione Grupo de instâncias.
- Na secção Novo back-end:
- Na lista Grupo de instâncias, selecione
gl4-ilb-migaem REGION_A. - Defina Transferir números como
80. - Para o Modo equilibrado, selecione Utilization.
- Clique em Concluído.
- Para adicionar outro back-end, clique em Adicionar back-end.
- Na lista Grupo de instâncias, selecione
gl4-ilb-migbem REGION_B. - Defina Transferir números como
80. - Clique em Concluído.
- Na lista Verificação de funcionamento, clique em Criar uma verificação de funcionamento.
- No campo Nome, introduza
global-http-health-check. - Defina Protocol como
HTTP. - Defina Porta como
80. - Clique em Guardar.
- Clique em Regras de encaminhamento.
- Para Modo, selecione Regra de anfitrião e caminho simples.
- Certifique-se de que existe apenas um serviço de back-end para qualquer anfitrião não correspondente e qualquer caminho não correspondente.
- Clique em Rever e finalizar.
- Reveja as definições de configuração do equilibrador de carga.
- Clique em Criar.
Adicione a segunda configuração da interface:
Configure as regras de encaminhamento
Reveja a configuração
gcloud
Defina a verificação de funcionamento de HTTP com o comando
gcloud compute health-checks create http.gcloud compute health-checks create http global-http-health-check \ --use-serving-port \ --global
Defina o serviço de back-end com o 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
Adicione back-ends ao serviço de back-end com o 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
Crie o mapa de URLs com o comando
gcloud compute url-maps create.gcloud compute url-maps create gl7-gilb-url-map \ --default-service=BACKEND_SERVICE_NAME \ --global
Crie o proxy de destino.
Para HTTP:
Crie o proxy de destino com o 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 criar um certificado gerido pela Google, consulte a seguinte documentação:
- Crie um certificado gerido pela Google emitido pela sua instância do Certificate Authority Service.
- Crie um certificado gerido pela Google com autorização de DNS.
Depois de criar o certificado gerido pela Google, anexe o certificado diretamente ao proxy de destino. Os mapas de certificados não são suportados por equilibradores de carga de aplicações internos entre regiões.
Para criar um certificado autogerido, consulte a seguinte documentação:
Atribua os caminhos dos ficheiros a nomes de variáveis.
export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
export LB_PRIVATE_KEY=PATH_TO_LB_PRIVATE_KEY_FILE
Crie um certificado SSL de todas as regiões com o 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
Use o certificado SSL para criar um proxy de destino com o comando
gcloud compute target-https-proxies creategcloud compute target-https-proxies create gil7-https-proxy \ --url-map=gl7-gilb-url-map \ --certificate-manager-certificates=gilb-certificate \ --global
Crie duas regras de encaminhamento, uma com um VIP (
10.1.2.99) na regiãoREGION_Be outra com um VIP (10.1.3.99) na regiãoREGION_A. Para mais informações, consulte o artigo Reserve um endereço IPv4 interno estático.Para redes personalizadas, tem de fazer referência à sub-rede na regra de encaminhamento. Tenha em atenção que esta é a sub-rede da VM e não a sub-rede do proxy.
Para HTTP:
Use o comando
gcloud compute forwarding-rules createcom as flags corretas.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:
Use o comando
gcloud compute forwarding-rules createcom as flags corretas.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 criar a verificação de funcionamento, use o recurso google_compute_health_check.
Para criar o serviço de back-end, use o recurso google_compute_backend_service.
Para criar o mapa de URLs, use o recurso google_compute_url_map.
Para criar o proxy HTTP de destino, use o recurso google_compute_target_http_proxy.
Para criar as regras de encaminhamento, use o recurso google_compute_forwarding_rule.
Para saber como aplicar ou remover uma configuração do Terraform, consulte os comandos básicos do Terraform.
API
Crie a verificação de funcionamento fazendo um pedido POST ao método healthChecks.insert, substituindo PROJECT_ID pelo ID do seu projeto.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks
{
"name": "global-http-health-check",
"type": "HTTP",
"httpHealthCheck": {
"portSpecification": "USE_SERVING_PORT"
}
}
Crie o serviço de back-end global fazendo um pedido POST ao método backendServices.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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"
}
Crie o mapa de URLs fazendo um pedido POST ao método urlMaps.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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:
Crie o proxy HTTP de destino fazendo um pedido POST ao método targetHttpProxies.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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"
}
Crie a regra de encaminhamento fazendo um pedido POST ao método forwardingRules.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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:
Ler os ficheiros de certificado e chave privada e, em seguida, criar o certificado SSL. O exemplo seguinte mostra como o fazer com Python.
Crie o proxy HTTPS de destino fazendo um pedido POST ao método
targetHttpsProxies.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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
}
Crie a regra de encaminhamento fazendo um pedido POST ao método globalForwardingRules.insert, substituindo PROJECT_ID pelo ID do seu projeto.
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"
}
Teste o balanceador de carga
Crie uma instância de VM para testar a conetividade
Crie uma VM de 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-sshgcloud 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-sshUse o SSH para estabelecer ligação a cada instância do cliente.
gcloud compute ssh l7-ilb-client-a --zone=ZONE_A
gcloud compute ssh l7-ilb-client-b --zone=ZONE_B
Verifique se o endereço IP está a publicar o respetivo nome do anfitrião
Confirme se a VM do cliente consegue alcançar ambos os endereços IP. O comando devolve o nome da VM de back-end que serviu o pedido:
curl 10.1.2.99
curl 10.1.3.99
Para testes HTTPS, substitua
curlpela seguinte linha de comando: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
Substitua DOMAIN_NAME pelo nome do domínio da sua aplicação, por exemplo,
test.example.com.A flag
-kfaz com que o curl ignore a validação de certificados.Opcional: use o registo de DNS configurado para resolver o endereço IP mais próximo da VM do cliente. Por exemplo, DNS_NAME pode ser
service.example.com.curl DNS_NAME
Execute 100 pedidos e confirme que têm o balanceamento de carga
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:
Nos scripts seguintes, substitua DOMAIN_NAME pelo nome do domínio da sua aplicação, por exemplo, 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
}
Teste de comutação por falha
Verifique a comutação por falha para back-ends na região
REGION_Aquando os back-ends na regiãoREGION_Bnão estiverem em bom estado ou estiverem inacessíveis. Para simular uma comutação por falha, remova todos os 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
Ligue-se através de SSH a uma VM cliente em REGION_B.
gcloud compute ssh l7-ilb-client-b \ --zone=ZONE_B
Envie pedidos para o endereço IP com balanceamento de carga na região
REGION_B. O resultado do comando mostra as respostas das VMs de back-end emREGION_A.No script seguinte, substitua DOMAIN_NAME pelo nome de domínio da sua aplicação, por exemplo,
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 }
Opções de configuração adicionais
Esta secção expande o exemplo de configuração para oferecer opções de configuração alternativas e adicionais. Todas as tarefas são opcionais. Pode realizá-las por qualquer ordem.
Ative a afinidade de sessão
Estes procedimentos mostram como atualizar um serviço de back-end para o exemplo de balanceador de carga de aplicações interno regional ou balanceador de carga de aplicações interno entre regiões, de modo que o serviço de back-end use afinidade de cookies gerados, afinidade de campos de cabeçalho ou afinidade de cookies HTTP.
Quando a afinidade de cookie gerado está ativada, o equilibrador de carga emite um cookie no primeiro pedido. Para cada pedido subsequente com o mesmo cookie, o balanceador de carga direciona o pedido para a mesma instância de máquina virtual (VM) ou ponto final de back-end. Neste exemplo, o cookie tem o nome GCILB.
Quando a afinidade do campo de cabeçalho está ativada, o balanceador de carga encaminha pedidos para VMs ou pontos finais de back-end num grupo de pontos finais de rede (NEG) com base no valor do cabeçalho HTTP denominado no parâmetro --custom-request-header.
A afinidade do campo de cabeçalho só é válida se a política de localidade de equilíbrio de carga for RING_HASH ou MAGLEV e o hash consistente do serviço de back-end especificar o nome do cabeçalho HTTP.
Quando a afinidade de cookies HTTP está ativada, o balanceador de carga encaminha pedidos para VMs ou pontos finais de back-end num NEG, com base num cookie HTTP denominado no parâmetro HTTP_COOKIE com o parâmetro --affinity-cookie-ttl opcional. Se o cliente não fornecer o cookie no respetivo pedido HTTP, o proxy gera o cookie e devolve-o ao cliente num cabeçalho Set-Cookie. A afinidade de cookies HTTP só é válida se a política de localidade de equilíbrio de carga for RING_HASH ou MAGLEV e o hash consistente do serviço de back-end especificar o cookie HTTP.
Consola
Para ativar ou alterar a afinidade de sessão para um serviço de back-end:
Na Google Cloud consola, aceda à página Equilíbrio de carga.
- Clique em Back-ends.
- Clique em gil7-backend-service (o nome do serviço de back-end que criou para este exemplo) e, de seguida, clique em Editar.
- Na página Detalhes do serviço de back-end, clique em Configuração avançada.
- Em Afinidade de sessão, selecione o tipo de afinidade de sessão que quer.
- Clique em Atualizar.
gcloud
Use os seguintes comandos da CLI gcloud para atualizar o serviço de back-end para diferentes tipos de afinidade de sessão:
gcloud compute backend-services update gil7-backend-service \
--session-affinity=[GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | CLIENT_IP] \
--global
API
Para definir a afinidade da sessão, faça um pedido `PATCH` ao 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" ]
}
Restrinja os clientes que podem enviar tráfego para o balanceador de carga
Pode restringir a ligação de clientes a um VIP de regra de encaminhamento do Application Load Balancer interno configurando regras de firewall de saída nestes clientes. Defina estas regras de firewall em VMs de cliente específicas com base em contas de serviço ou etiquetas.
Não pode usar regras de firewall para restringir o tráfego de entrada a VIPs de regras de encaminhamento de balanceadores de carga de aplicações internos específicos. Geralmente, qualquer cliente na mesma rede VPC e na mesma região que o VIP da regra de encaminhamento pode enviar tráfego para o VIP da regra de encaminhamento.
Além disso, todos os pedidos para back-ends provêm de proxies que usam endereços IP no intervalo de sub-rede apenas de proxy. Não é possível criar regras de firewall que permitam ou neguem o tráfego de entrada nestes back-ends com base no VIP da regra de encaminhamento usado por um cliente.
Seguem-se alguns exemplos de como usar regras de firewall de saída para restringir o tráfego ao VIP da regra de encaminhamento do equilibrador de carga.
Consola
Para identificar as VMs de cliente, etiquete as VMs específicas que quer restringir. Estas etiquetas são usadas para associar regras de firewall às VMs de cliente etiquetadas. Em seguida, adicione a etiqueta ao campo TARGET_TAG
nos passos seguintes.
Use uma única regra de firewall ou várias regras para configurar esta opção.
Regra de firewall de saída única
Pode configurar uma regra de saída da firewall para negar todo o tráfego de saída que vai das VMs de cliente etiquetadas para o VIP de um equilibrador de carga.
Na Google Cloud consola, aceda à página Regras de firewall.
Clique em Criar regra de firewall para criar a regra que recusa o tráfego de saída de VMs de cliente etiquetadas para o VIP de um balanceador de carga.
- Nome:
fr-deny-access - Rede:
lb-network - Prioridade:
100 - Direção do tráfego: saída
- Ação na correspondência: Recusar
- Objetivos: etiquetas de destino especificadas
- Etiquetas de segmentação:
TARGET_TAG - Filtro de destino: Intervalos de IP
- Intervalos de IP de destino:
10.1.2.99 - Protocolos e portas:
- Escolha Protocolos e portas especificados.
- Selecione a caixa de verificação tcp e, de seguida, introduza
80para o número da porta.
- Nome:
Clique em Criar.
Várias regras de firewall de saída
Uma abordagem mais escalável envolve a definição de duas regras. Uma regra predefinida de baixa prioridade que restringe o acesso de todos os clientes ao VIP do equilibrador de carga. Uma segunda regra de prioridade mais elevada que permite que um subconjunto de clientes etiquetados aceda ao VIP do balanceador de carga. Apenas as VMs etiquetadas podem aceder ao VIP.
Na Google Cloud consola, aceda à página Regras de firewall.
Clique em Criar regra de firewall para criar a regra de prioridade inferior para negar o acesso por predefinição:
- Nome:
fr-deny-all-access-low-priority - Rede:
lb-network - Prioridade:
200 - Direção do tráfego: saída
- Ação na correspondência: Recusar
- Objetivos: etiquetas de destino especificadas
- Etiquetas de segmentação:
TARGET_TAG - Filtro de destino: Intervalos de IP
- Intervalos de IP de destino:
10.1.2.99 - Protocolos e portas:
- Escolha Protocolos e portas especificados.
- Selecione a caixa de verificação TCP e, de seguida, introduza
80para o número da porta.
- Nome:
Clique em Criar.
Clique em Criar regra de firewall para criar a regra de prioridade mais elevada para permitir tráfego de determinadas instâncias etiquetadas.
- Nome:
fr-allow-some-access-high-priority - Rede:
lb-network - Prioridade:
100 - Direção do tráfego: saída
- Ação na correspondência: Permitir
- Objetivos: etiquetas de destino especificadas
- Etiquetas de segmentação:
TARGET_TAG - Filtro de destino: Intervalos de IP
- Intervalos de IP de destino:
10.1.2.99 - Protocolos e portas:
- Escolha Protocolos e portas especificados.
- Selecione a caixa de verificação TCP e, de seguida, introduza
80para o número da porta.
- Nome:
Clique em Criar.
gcloud
Para identificar as VMs de cliente, etiquete as VMs específicas que quer restringir. Em seguida, adicione a etiqueta ao campo TARGET_TAG
nestes passos.
Use uma única regra de firewall ou várias regras para configurar esta opção.
Regra de firewall de saída única
Pode configurar uma regra de saída da firewall para negar todo o tráfego de saída que vai das VMs de cliente etiquetadas para o VIP de um equilibrador 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
Várias regras de firewall de saída
Uma abordagem mais escalável envolve a definição de duas regras: uma regra predefinida de baixa prioridade que restringe o acesso de todos os clientes ao VIP do balanceador de carga e uma segunda regra de prioridade mais elevada que permite que um subconjunto de clientes etiquetados aceda ao VIP do balanceador de carga. Apenas as VMs etiquetadas podem aceder ao VIP.
Crie a regra de prioridade inferior:
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.99Crie a regra de prioridade mais elevada:
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 contas de serviço em vez de etiquetas para controlar o acesso, use a opção --target-service-accounts em vez da flag --target-tags ao criar regras de firewall.
Dimensione o acesso restrito a back-ends do balanceador de carga de aplicações internos com base em sub-redes
A manutenção de regras de firewall separadas ou a adição de novos endereços IP com balanceamento de carga às regras existentes, conforme descrito na secção anterior, torna-se inconveniente à medida que o número de regras de encaminhamento aumenta. Uma forma de evitar esta situação é atribuir endereços IP de regras de encaminhamento a partir de uma sub-rede reservada. Em seguida, o tráfego de instâncias etiquetadas ou contas de serviço pode ser permitido ou bloqueado através da sub-rede reservada como o intervalo de destino para regras de firewall. Isto permite-lhe controlar eficazmente o acesso a um grupo de VIPs de regras de encaminhamento sem ter de manter regras de saída da firewall por VIP.
Seguem-se os passos gerais para configurar esta opção, partindo do princípio de que vai criar todos os outros recursos do balanceador de carga necessários separadamente.
gcloud
Crie uma sub-rede regional para usar na atribuição de endereços IP com balanceamento de carga para regras de encaminhamento:
gcloud compute networks subnets create l7-ilb-restricted-subnet \ --network=lb-network \ --region=us-west1 \ --range=10.127.0.0/24Crie uma regra de encaminhamento que obtenha um endereço da sub-rede. O exemplo seguinte usa o endereço
10.127.0.1da sub-rede criada no passo 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-proxyCrie uma regra de firewall para restringir o tráfego destinado aos endereços IP no intervalo da sub-rede da regra de encaminhamento (
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
Use o mesmo endereço IP entre várias regras de encaminhamento interno
Para que várias regras de encaminhamento interno partilhem o mesmo endereço IP interno, tem de reservar o endereço IP e definir a respetiva flag --purpose como SHARED_LOADBALANCER_VIP.
gcloud
gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
--region=REGION \
--subnet=SUBNET_NAME \
--purpose=SHARED_LOADBALANCER_VIP
Configure políticas de encaminhamento de DNS
Se os seus clientes estiverem em várias regiões, pode querer tornar o Application Load Balancer interno entre regiões acessível através de VIPs nestas regiões. Esta configuração multirregião minimiza a latência e os custos de trânsito de rede. Além disso, permite-lhe configurar uma solução de balanceamento de carga global baseada em DNS que oferece resiliência contra interrupções regionais. Para mais informações, consulte o artigo Faça a gestão das políticas de encaminhamento de DNS e das verificações de estado.
gcloud
Para criar uma entrada DNS com um TTL de 30 segundos, use o 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
Substitua o seguinte:
DNS_ENTRY: DNS ou nome de domínio do conjunto de registosPor exemplo,
service.example.comREGION_AeREGION_B: as regiões onde configurou o balanceador de carga
API
Crie o registo DNS fazendo um pedido POST ao
método.ResourceRecordSets.create
Substitua PROJECT_ID pelo ID do seu projeto.
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"
}
]
}
}
]
}
}
}
Atualize o tempo limite de manutenção ativa de HTTP do cliente
O balanceador de carga criado nos passos anteriores foi configurado com um valor predefinido para o tempo limite de manutenção ativa do HTTP do cliente.Para atualizar o limite de tempo limite de manutenção ativa HTTP do cliente, siga as instruções abaixo.
Consola
Na Google Cloud consola, aceda à página Equilíbrio de carga.
- Clique no nome do equilibrador de carga que quer modificar.
- Clique em Editar.
- Clique em Configuração do front-end.
- Expanda Funcionalidades avançadas. Para Limite de tempo de manutenção ativa de HTTP, introduza um valor de limite de tempo.
- Clique em Atualizar.
- Para rever as alterações, clique em Rever e finalizar e, de seguida, clique em Atualizar.
gcloud
Para um balanceador de carga HTTP, atualize o proxy HTTP de destino através do 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
Para um balanceador de carga HTTPS, atualize o proxy HTTPS de destino com o 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
Substitua o seguinte:
TARGET_HTTP_PROXY_NAME: o nome do proxy HTTP de destino.TARGET_HTTPS_PROXY_NAME: o nome do proxy HTTPS de destino.HTTP_KEEP_ALIVE_TIMEOUT_SEC: o valor de tempo limite de manutenção ativa de HTTP de 5 para 600 segundos.
Ative a deteção de valores atípicos
Pode ativar a deteção de valores outliers em serviços de back-end globais para identificar NEGs sem servidor não íntegros e reduzir o número de pedidos enviados para os NEGs sem servidor não íntegros.
A deteção de valores atípicos é ativada no serviço de back-end através de um dos seguintes métodos:
- O método
consecutiveErrors(outlierDetection.consecutiveErrors), em que um código de estado HTTP da série5xxé considerado um erro. - O método
consecutiveGatewayFailure(outlierDetection.consecutiveGatewayFailure), no qual apenas os códigos de estado HTTP502,503e504se qualificam como um erro.
Siga estes passos para ativar a deteção de valores atípicos para um serviço de back-end existente. Tenha em atenção que, mesmo depois de ativar a deteção de valores atípicos, alguns pedidos podem ser enviados para o serviço não saudável e devolver um código de estado 5xx aos clientes. Para reduzir ainda mais a taxa de erro, pode configurar valores mais agressivos para os parâmetros de deteção de valores atípicos. Para mais informações, consulte o campo
outlierDetection.
Consola
Na Google Cloud consola, aceda à página Equilíbrio de carga.
Clique no nome do balanceador de carga cujo serviço de back-end quer editar.
Na página Detalhes do equilibrador de carga, clique em Editar.
Na página Editar Application Load Balancer interno entre regiões, clique em Configuração do back-end.
Na página Configuração de back-end, clique em Editar para o serviço de back-end que quer modificar.
Desloque a página para baixo e expanda a secção Configurações avançadas.
Na secção Deteção de valores atípicos, selecione a caixa de verificação Ativar.
Clique em Editar para configurar a deteção de valores atípicos.
Verifique se as seguintes opções estão configuradas com estes valores:
Propriedade Valor Erros consecutivos 5 Intervalo 1000 Tempo de ejeção base 30000 Percentagem máxima de rejeição 50 Aplicação de erros consecutivos 100 Neste exemplo, a análise de deteção de valores atípicos é executada a cada segundo. Se o número de códigos de estado HTTP consecutivos recebidos por um proxy do Envoy for igual ou superior a cinco, o ponto final de back-end é rejeitado do conjunto de equilíbrio de carga desse proxy do Envoy durante 30 segundos.
5xxQuando a percentagem de aplicação é definida como 100%, o serviço de back-end aplica a rejeição de pontos finais não íntegros dos conjuntos de equilíbrio de carga desses proxies Envoy específicos sempre que a análise de deteção de valores atípicos é executada. Se as condições de rejeição forem cumpridas, é possível rejeitar até 50% dos pontos finais de back-end do conjunto de equilíbrio de carga.Clique em Guardar.
Para atualizar o serviço de back-end, clique em Atualizar.
Para atualizar o balanceador de carga, na página Editar balanceador de carga de aplicações interno entre regiões, clique em Atualizar.
gcloud
Exporte o serviço de back-end para um ficheiro YAML.
gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME.yaml --global
Substitua
BACKEND_SERVICE_NAMEpelo nome do serviço de back-end.Edite a configuração YAML do serviço de back-end para adicionar os campos de deteção de valores atípicos, conforme realçado na seguinte configuração YAML, na secção
outlierDetection:Neste exemplo, a análise de deteção de valores atípicos é executada a cada segundo. Se o número de códigos de estado HTTP consecutivos recebidos por um proxy do Envoy for igual ou superior a cinco, o ponto final de back-end é rejeitado do conjunto de equilíbrio de carga desse proxy do Envoy durante 30 segundos.
5xxQuando a percentagem de aplicação é definida como 100%, o serviço de back-end aplica a rejeição de pontos finais não íntegros dos conjuntos de equilíbrio de carga desses proxies Envoy específicos sempre que a análise de deteção de valores atípicos é executada. Se as condições de rejeição forem cumpridas, é possível rejeitar até 50% dos pontos finais de back-end do conjunto de equilíbrio 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 ...Substitua o seguinte:
BACKEND_SERVICE_NAME: o nome do serviço de back-endPROJECT_ID: o ID do seu projetoREGION_AeREGION_B: as regiões onde o balanceador de carga foi configurado.SERVERLESS_NEG_NAME: o nome do primeiro NEG sem servidorSERVERLESS_NEG_NAME_2: o nome do segundo NEG sem servidor
Atualize o serviço de back-end importando a configuração mais recente.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME.yaml --global
A deteção de valores atípicos está agora ativada no serviço de back-end.
O que se segue?
- Converta o balanceador de carga de aplicações para IPv6
- 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