Esta página foi traduzida pela API Cloud Translation.

Configurar um balanceador de carga de aplicativo interno entre regiões com back-ends de grupo de instâncias de VM

Neste documento, fornecemos instruções para configurar um balanceador de carga de aplicativo interno entre regiões para seus serviços executados em instâncias de máquina virtual (VM) do Compute Engine.

Antes de começar

Antes de seguir as instruções deste guia, familiarize-se com os itens abaixo:

Visão geral do balanceador de carga de aplicativo interno, incluindo a seção Limitações
Visão geral das regras de firewall da VPC

Configurar um recurso de certificado SSL

Crie um recurso de certificado SSL do Gerenciador de certificados conforme descrito a seguir:

Recomendamos o uso de um certificado gerenciado pelo Google.

Permissões

Para seguir as instruções deste guia, você precisa ser capaz de criar instâncias e modificar uma rede em um projeto. É necessário ser um proprietário ou editor de projeto, ou ter todos os seguintes papéis do IAM do Compute Engine:

Tarefa	Papel necessário
Criar redes, sub-redes e componentes do balanceador de carga	Administrador de rede do Compute
Adicionar e remover regras de firewall	Administrador de segurança do Compute
Criar instâncias	Administrador da instância da computação

Para mais informações, consulte estes guias:

Visão geral da configuração

É possível configurar o balanceador de carga como mostrado no seguinte diagrama:

Implantação de alta disponibilidade do balanceador de carga de aplicativo interno entre regiões. — Implantação de alta disponibilidade do balanceador de carga de aplicativo interno entre regiões (clique para ampliar).

Conforme mostrado no diagrama, este exemplo cria um balanceador de carga de aplicativo interno entre regiões em uma rede VPC, com um serviço de back-end e dois grupos de instâncias gerenciadas de back-end nas regiões REGION_A e REGION_B.

O diagrama mostra estes elementos:

Uma rede VPC com as seguintes sub-redes:
- Sub-rede SUBNET_A e uma sub-rede somente proxy em REGION_A.
- Sub-rede SUBNET_B e uma sub-rede somente proxy em REGION_B.
É preciso criar sub-redes somente proxy em todas as regiões de uma rede VPC em que você usa balanceadores de carga de aplicativo internos entre regiões. A sub-rede somente proxy da região é compartilhada com todos os balanceadores de carga de aplicativo internos entre regiões que estão na região. Os endereços de origem dos pacotes enviados dos balanceadores de carga para os back-ends do serviço são alocados por meio da sub-rede somente proxy. Neste exemplo, a sub-rede somente proxy da região REGION_A tem um intervalo de endereços IP primário 10.129.0.0/23. A região REGION_B tem um intervalo de endereços IP primário 10.130.0.0/23, que é o tamanho de sub-rede recomendado.
A configuração de alta disponibilidade tem back-ends de grupo de instâncias gerenciadas para implantações de VM do Compute Engine nas regiões REGION_A e REGION_B. Se os back-ends de uma região ficarem inativos, o tráfego fará o failover para a outra região.
Um serviço de back-end global que monitora o uso e a integridade dos back-ends.
Um mapa de URL global que analisa o URL de uma solicitação e encaminha solicitações para serviços de back-end específicos com base no host e no caminho do URL de solicitação.
Um proxy HTTP ou HTTPS de destino global, que recebe uma solicitação do usuário e a encaminha para o mapa de URL. Em HTTPS, configure um recurso de certificado SSL global. O proxy de destino usa o certificado SSL para descriptografar o tráfego SSL se você configurar o balanceamento de carga HTTPS. O proxy de destino pode encaminhar o tráfego para suas instâncias usando HTTP ou HTTPS.
Regras de encaminhamento global, que têm o endereço IP interno regional do balanceador de carga, para encaminhar cada solicitação recebida ao 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 dos back-ends. Observe as seguintes condições:
- O endereço IP pode (mas não precisa) vir da mesma sub-rede que os grupos de instâncias de back-end.
- O endereço IP não pode vir de uma sub-rede exclusiva de proxy reservada que tenha a sinalização --purpose definida como GLOBAL_MANAGED_PROXY.
- Se você quiser usar o mesmo endereço IP interno com várias regras de encaminhamento, defina a sinalização --purpose do endereço IP como SHARED_LOADBALANCER_VIP.
Opcional: configure políticas de roteamento de DNS do tipo GEO para rotear o tráfego do cliente para o VIP do balanceador de carga na região mais próxima do cliente.

Configurar a rede e as sub-redes

Na rede VPC, configure uma sub-rede em cada região em que os back-ends estão configurados. Além disso, configure um proxy-only-subnet em cada região em que você quer configurar o balanceador de carga.

Neste exemplo, usamos a seguinte rede VPC, região e sub-redes:

Rede. Uma rede VPC de modo personalizado denominada NETWORK.
Sub-redes para back-ends.
- uma sub-rede chamada SUBNET_A na região REGION_A usa 10.1.2.0/24 para o intervalo de IP primário.
- uma sub-rede chamada SUBNET_B na região REGION_B usa 10.1.3.0/24 para o intervalo de IP primário.
Sub-redes para proxies.
- uma sub-rede chamada PROXY_SN_A na região REGION_A usa 10.129.0.0/23 para o intervalo de IP primário.
- uma sub-rede chamada PROXY_SN_B na região REGION_B usa 10.130.0.0/23 para o intervalo de IP primário.

Os balanceadores de carga de aplicativo internos entre regiões podem ser acessados de qualquer região dentro da VPC. Assim, clientes de qualquer região podem acessar globalmente os back-ends do balanceador de carga.

Configurar as sub-redes de back-end

Console

No Console do Google Cloud, acesse a página Redes VPC.

Acessar redes VPC
Clique em Criar rede VPC.
Atribua um Nome à rede.
Na seção Sub-redes, defina o Modo de criação da sub-rede como Personalizado.
Crie uma sub-rede para os back-ends do balanceador de carga. Na seção Nova sub-rede, insira as informações a seguir:
- Forneça um Nome para a sub-rede.
- Selecione uma Região: REGION_A
- Digite um Intervalo de endereço IP: 10.1.2.0/24
Clique em Concluído.
Clique em Add subnet.
Crie uma sub-rede para os back-ends do balanceador de carga. Na seção Nova sub-rede, insira as seguintes informações:
- Forneça um Nome para a sub-rede.
- Selecione uma Região: REGION_B
- Digite um Intervalo de endereço 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=custom
```

Crie uma sub-rede na rede NETWORK na região REGION_A com o comando gcloud compute networks subnets create:

gcloud compute networks subnets create SUBNET_A \
    --network=NETWORK \
    --range=10.1.2.0/24 \
    --region=REGION_A

Crie uma sub-rede na rede NETWORK na região REGION_B com o comando gcloud 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.

resource "google_compute_network" "default" {
  auto_create_subnetworks = false
  name                    = "lb-network-crs-reg"
  provider                = google-beta
}

Para criar sub-redes VPC na rede lb-network-crs-reg, use o recurso google_compute_subnetwork.

resource "google_compute_subnetwork" "subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.1.2.0/24"
  name          = "lbsubnet-uswest1"
  network       = google_compute_network.default.id
  region        = "us-west1"
}

resource "google_compute_subnetwork" "subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.1.3.0/24"
  name          = "lbsubnet-useast1"
  network       = google_compute_network.default.id
  region        = "us-east1"
}

API

Faça uma solicitação POST ao método networks.insert. Substitua PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
 "routingConfig": {
   "routingMode": "regional"
 },
 "name": "NETWORK",
 "autoCreateSubnetworks": false
}

Faça uma solicitação POST ao método subnetworks.insert. Substitua PROJECT_ID pelo ID do 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 uma solicitação POST ao método subnetworks.insert. Substitua PROJECT_ID pelo ID do 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",
}

Configurar a sub-rede somente proxy

Uma sub-rede somente proxy fornece um conjunto de endereços IP que o Google Cloud usa para executar proxies Envoy em seu nome. Os proxies encerram as conexões do cliente e criam novas conexões com os back-ends.

Essa sub-rede somente proxy é usada por todos os balanceadores de carga regionais baseados no Envoy que estão na mesma região que a rede VPC. Só pode haver uma sub-rede somente proxy ativa para uma determinada finalidade, por região e por rede.

Console

Se você estiver usando o Console do Google Cloud, poderá esperar e criar a sub-rede somente proxy depois na página Balanceamento de carga.

Se você quiser criar a sub-rede somente proxy agora, siga estas etapas:

No Console do Google Cloud, acesse a página Redes VPC.

Acessar redes VPC
Clique no nome da rede VPC.
Na guia Sub-rede, clique em Adicionar sub-rede.
Forneça um Nome para a sub-rede somente proxy.
Selecione uma Região: REGION_A
Na lista Finalidade, selecione Proxy gerenciado entre regiões.
No campo Intervalo de endereços IP, insira 10.129.0.0/23.
Clique em Adicionar.

Crie a sub-rede somente proxy em REGION_B

Na guia Sub-rede, clique em Adicionar sub-rede.
Forneça um Nome para a sub-rede somente proxy.
Selecione uma Região: REGION_B
Na lista Finalidade, selecione Proxy gerenciado entre regiões.
No campo Intervalo de endereços IP, insira 10.130.0.0/23.
Clique em Adicionar.

gcloud

Crie a sub-rede somente 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 somente proxy VPC na rede lb-network-crs-reg, use o recurso google_compute_subnetwork.

resource "google_compute_subnetwork" "proxy_subnet_a" {
  provider      = google-beta
  ip_cidr_range = "10.129.0.0/23"
  name          = "proxy-only-subnet1"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-west1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

resource "google_compute_subnetwork" "proxy_subnet_b" {
  provider      = google-beta
  ip_cidr_range = "10.130.0.0/23"
  name          = "proxy-only-subnet2"
  network       = google_compute_network.default.id
  purpose       = "GLOBAL_MANAGED_PROXY"
  region        = "us-east1"
  role          = "ACTIVE"
  lifecycle {
    ignore_changes = [ipv6_access_type]
  }
}

API

Crie as sub-redes somente proxy com o método subnetworks.insert, substituindo PROJECT_ID pelo ID do 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"
    }

Configurar regras de firewall

Este exemplo usa as seguintes regras de firewall:

fw-ilb-to-backends. Uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite a conectividade SSH de entrada na porta TCP 22 proveniente de qualquer endereço. Escolha um intervalo de endereços IP de origem mais restritivo para esta regra. Por exemplo, é possível especificar apenas os intervalos de endereços IP do sistema do qual você inicia as sessões SSH. Neste exemplo, usamos a tag de destino allow-ssh para identificar as VMs a que a regra de firewall se aplica.
fw-healthcheck. Uma regra de entrada, aplicável às instâncias cuja carga está sendo balanceada, que permite todo o tráfego TCP dos sistemas de verificação de integridade do Google Cloud (em 130.211.0.0/22 e 35.191.0.0/16). Este exemplo usa a tag de destino load-balanced-backend para identificar as VMs a que a regra de firewall se aplica.
fw-backends. Uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite o tráfego TCP nas portas 80, 443 e 8080 dos proxies gerenciados do balanceador de carga de aplicativo interno. Neste exemplo, usamos a tag de destino load-balanced-backend para identificar as VMs a que a regra de firewall se aplica.

Sem essas regras de firewall, a regra padrão de negação de entrada bloqueará o tráfego que chega para as instâncias de back-end.

As tags de destino definem as instâncias de back-end. Sem as tags de destino, as regras de firewall se aplicam a todas as instâncias de back-end na rede VPC. Ao criar as VMs de back-end, inclua as tags de destino especificadas, conforme mostrado em Como criar um grupo gerenciado de instâncias.

Console

No Console do Google Cloud, acesse a página políticas de Firewall.

Acessar as políticas de firewall
Clique em Criar regra de firewall para criar a regra que autorize conexões SSH de entrada:
- Name: fw-ilb-to-backends
- Rede: NETWORK
- Direção do tráfego: entrada
- Ação na correspondência: permitir
- Destinos: tags de destino especificadas
- Tags de meta: allow-ssh
- Filtro de origem: intervalos IPv4
- Intervalos IPv4 de origem: 0.0.0.0/0
- Protocolos e portas:
  - Escolha Protocolos e portas especificados.
  - Marque a caixa de seleção tcp e insira 22 como o número da porta.
Clique em Criar.
Clique em Criar regra de firewall pela segunda vez para criar a regra que autorize as verificações de integridade do Google Cloud:
- Name: fw-healthcheck
- Rede: NETWORK
- Direção do tráfego: entrada
- Ação na correspondência: permitir
- Destinos: tags de destino especificadas
- Tags de meta: load-balanced-backend
- Filtro de origem: intervalos IPv4
- Intervalos IPv4 de origem: 130.211.0.0/22 e 35.191.0.0/16
- Protocolos e portas:
  - Escolha Protocolos e portas especificados.
  - Marque a caixa de seleção tcp e insira 80 como o número da porta.
  Como prática recomendada, limite esta regra somente aos protocolos e portas que correspondem aos usados por sua verificação de integridade. Se você usar tcp:80 para o protocolo e a porta, o Google Cloud poderá usar HTTP na porta 80 para entrar em contato com suas VMs, mas não poderá usar HTTPS na porta 443 para entrar em contato com elas.
Clique em Criar.
Clique em Criar regra de firewall uma terceira vez para criar a regra que permite que os servidores proxy do balanceador de carga se conectem aos back-ends:
- Name: fw-backends
- Rede: NETWORK
- Direção do tráfego: entrada
- Ação na correspondência: permitir
- Destinos: tags de destino especificadas
- Tags de meta: load-balanced-backend
- Filtro de origem: intervalos IPv4
- Intervalos IPv4 de origem: 10.129.0.0/23 e 10.130.0.0/23
- Protocolos e portas:
  - Escolha Protocolos e portas especificados.
  - Marque a caixa de seleção tcp e insira 80, 443, 8080 como os números da porta.
Clique em Criar.

gcloud

Crie a regra de firewall fw-ilb-to-backends que permita a conectividade SSH para VMs com a tag de rede allow-ssh. Se você omitir source-ranges, o Google Cloud interpretará que a regra autoriza a conexão proveniente de qualquer origem.
```
gcloud compute firewall-rules create fw-ilb-to-backends \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```
Crie a regra fw-healthcheck para permitir verificações de integridade do Google Cloud. Neste exemplo, é permitido todo o tráfego TCP de sondagens de verificação de integridade. No entanto, é possível configurar um conjunto mais restrito de portas para atender às 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=tcp
```

Crie a regra fw-backends para permitir que os proxies do balanceador de carga interno se conectem aos seus back-ends. Defina source-ranges para os intervalos alocados da sub-rede somente proxy, por exemplo, 10.129.0.0/23 and 10.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.

resource "google_compute_firewall" "fw_healthcheck" {
  name          = "gl7-ilb-fw-allow-hc"
  provider      = google-beta
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["130.211.0.0/22", "35.191.0.0/16", "35.235.240.0/20"]
  allow {
    protocol = "tcp"
  }
}

resource "google_compute_firewall" "fw_ilb_to_backends" {
  name          = "fw-ilb-to-fw"
  provider      = google-beta
  network       = google_compute_network.default.id
  source_ranges = ["0.0.0.0/0"]
  allow {
    protocol = "tcp"
    ports    = ["22", "80", "443", "8080"]
  }
}

resource "google_compute_firewall" "fw_backends" {
  name          = "gl7-ilb-fw-allow-ilb-to-backends"
  direction     = "INGRESS"
  network       = google_compute_network.default.id
  source_ranges = ["10.129.0.0/23", "10.130.0.0/23"]
  target_tags   = ["http-server"]
  allow {
    protocol = "tcp"
    ports    = ["80", "443", "8080"]
  }
}

API

Crie a regra de firewall fw-ilb-to-backends fazendo uma solicitação POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do 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 uma solicitação POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do 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 proxy para o método firewalls.insert, substituindo PROJECT_ID pelo ID do 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"
}

criar um grupo gerenciado de instâncias

Nesta seção, você verá como criar um modelo e um grupo de instâncias gerenciadas. O grupo gerenciado de instâncias fornece instâncias de VM que executam os servidores de back-end de um exemplo de balanceador de carga de aplicativo interno entre regiões. Para o grupo de instâncias, é possível 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. É feito o balanceamento de carga do tráfego dos clientes para os servidores de back-end. Para fins de demonstração, os back-ends veiculam nomes de host próprios.

Console

No console do Google Cloud, acesse a página Modelos de instância.

Acessar "Modelos de instância"
1. Clique em Criar modelo de instância.
2. Em Nome, insira gil7-backendeast1-template.
3. Verifique se Disco de inicialização está definido como uma imagem Debian, como Debian GNU/Linux 12 (bookworm): Estas instruções usam comandos que estão disponíveis apenas no Debian, como apt-get.
4. Clique em Opções avançadas.
5. Clique em Rede e configure os seguintes campos:
  1. Em Tags de rede, insira allow-ssh e load-balanced-backend.
  2. Em Interfaces de rede, selecione o seguinte:
    - Rede: NETWORK
    - Sub-rede: SUBNET_B
6. Clique em Gerenciamento. Insira o script a seguir no campo Script de inicialização.
```
#! /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
```
7. Clique em Criar.
8. Clique em Criar modelo de instância.
9. Em Nome, insira gil7-backendwest1-template.
10. Verifique se Disco de inicialização está definido como uma imagem Debian, como Debian GNU/Linux 12 (bookworm): Estas instruções usam comandos que estão disponíveis apenas no Debian, como apt-get.
11. Clique em Opções avançadas.
12. Clique em Rede e configure os seguintes campos:
  1. Em Tags de rede, insira allow-ssh e load-balanced-backend.
  2. Em Interfaces de rede, selecione o seguinte:
    - Rede: NETWORK
    - Sub-rede: SUBNET_A
13. Clique em Gerenciamento. Insira o script a seguir no campo Script de inicialização.
```
#! /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
```
14. Clique em Criar.
No Console do Google Cloud, acesse a página Grupos de instâncias.

Acesse grupo de instâncias
1. Clique em Criar grupo de instâncias.
2. Selecione Novo grupo gerenciado de instâncias (sem estado). Para mais informações, consulte MIGs sem estado ou com estado.
3. Em Nome, insira gl7-ilb-mig-a.
4. Em Local, selecione Zona única.
5. Em Região, selecione REGION_A.
6. Em Zona, selecione ZONE_A.
7. Em Modelo de instância, selecione gil7-backendwest1-template.
8. Especifique o número de instâncias que você quer criar no grupo.
  
  Neste exemplo, especifique as seguintes opções em Escalonamento automático:
  - Em Modo de escalonamento automático, selecione Off:do not autoscale.
  - Em Número máximo de instâncias, insira 2.
  Se preferir, na seção Escalonamento automático da IU, configure o grupo de instâncias para adicionar ou remover instâncias automaticamente com base no uso de CPU da instância.
9. Clique em Criar.
10. Clique em Criar grupo de instâncias.
11. Selecione Novo grupo gerenciado de instâncias (sem estado). Para mais informações, consulte MIGs sem estado ou com estado.
12. Em Nome, insira gl7-ilb-mig-b.
13. Em Local, selecione Zona única.
14. Em Região, selecione REGION_B.
15. Em Zona, selecione ZONE_B.
16. Em Modelo de instância, selecione gil7-backendeast1-template.
17. Especifique o número de instâncias que você quer criar no grupo.
  
  Neste exemplo, especifique as seguintes opções em Escalonamento automático:
  - Em Modo de escalonamento automático, selecione Off:do not autoscale.
  - Em Número máximo de instâncias, insira 2.
  Se preferir, na seção Escalonamento automático da IU, configure o grupo de instâncias para adicionar ou remover instâncias automaticamente com base no uso de CPU da instância.
18. Clique em Criar.

gcloud

As instruções deste guia relativas à CLI gcloud pressupõem que você está usando o Cloud Shell ou outro ambiente com o bash instalado.

Crie um modelo de instância de VM com o servidor HTTP usando 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 gerenciado de instâncias 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-template

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

resource "google_compute_instance_template" "instance_template_a" {
  name         = "gil7-backendwest1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-west1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_a.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}

resource "google_compute_instance_template" "instance_template_b" {
  name         = "gil7-backendeast1-template"
  provider     = google-beta
  machine_type = "e2-small"
  region       = "us-east1"
  tags         = ["http-server"]

  network_interface {
    network    = google_compute_network.default.id
    subnetwork = google_compute_subnetwork.subnet_b.id
    access_config {
      # add external ip to fetch packages
    }
  }
  disk {
    source_image = "debian-cloud/debian-11"
    auto_delete  = true
    boot         = true
  }

  # install nginx and serve a simple web page
  metadata = {
    startup-script = <<-EOF1
      #! /bin/bash
      set -euo pipefail

      export DEBIAN_FRONTEND=noninteractive
      apt-get update
      apt-get install -y nginx-light jq

      NAME=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/hostname")
      IP=$(curl -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip")
      METADATA=$(curl -f -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=True" | jq 'del(.["startup-script"])')

      cat <<EOF > /var/www/html/index.html
      <pre>
      Name: $NAME
      IP: $IP
      Metadata: $METADATA
      </pre>
      EOF
    EOF1
  }
  lifecycle {
    create_before_destroy = true
  }
}

Para criar o grupo gerenciado de instâncias, use o recurso google_compute_instance_group_manager.

resource "google_compute_region_instance_group_manager" "mig_a" {
  name     = "gl7-ilb-miga"
  provider = google-beta
  region   = "us-west1"
  version {
    instance_template = google_compute_instance_template.instance_template_a.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}

resource "google_compute_region_instance_group_manager" "mig_b" {
  name     = "gl7-ilb-migb"
  provider = google-beta
  region   = "us-east1"
  version {
    instance_template = google_compute_instance_template.instance_template_b.id
    name              = "primary"
  }
  base_instance_name = "vm"
  target_size        = 2
}

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 gerenciado de instâncias em cada zona com o método instanceGroupManagers.insert, substituindo PROJECT_ID pelo ID do 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 gerenciado de instâncias em cada zona com o método instanceGroupManagers.insert, substituindo PROJECT_ID pelo ID do 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
}

Configurar o balanceador de carga

Neste exemplo, mostramos como criar os seguintes recursos do balanceador de carga de aplicativo interno entre regiões:

Uma verificação de integridade HTTP global.
Um serviço de back-end global com os grupos gerenciados de instâncias como back-end.
Um mapa de URL. Com relação ao proxy HTTP(S) de destino, faça referência a um mapa de URL global. Um mapa de URL global direciona as solicitações para um serviço de back-end global com base em regras definidas para o host e para o caminho de um URL de entrada. Um mapa de URL 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 global com endereços IP regionais. Para o endereço IP da regra de encaminhamento, use o intervalo de endereços IP SUBNET_A ou SUBNET_B. Se você tentar usar a sub-rede somente proxy, a criação da regra de encaminhamento falhará.

Console

Iniciar a configuração

No console do Google Cloud, acesse a página Balanceamento de carga.

Acessar o "Balanceamento de carga"
Clique em Criar balanceador de carga.
Em Tipo de balanceador de carga, selecione Balanceador de carga de aplicativo (HTTP/HTTPS) e clique em Próxima.
Em Voltado ao público ou interno, selecione Interno e clique em Próxima.
Em Implantação entre regiões ou região única, selecione Melhor para cargas de trabalho entre regiões e clique em Próxima.
Clique em Configurar.

Configuração básica

Dê um Nome para o balanceador de carga.
Em Rede, selecione NETWORK.

Configure o front-end com duas regras de encaminhamento

Para HTTP:

Clique em Configuração de front-end.

Dê um Nome para a regra de encaminhamento.
Na lista Região da sub-rede, selecione REGION_A.
Reservar uma sub-rede somente proxy

Na lista Sub-rede, selecione SUBNET_A.
Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.

Forneça um Nome para o endereço IP estático.
Na lista Endereço IP estático, selecione Quero escolher.
No campo Endereço IP, digite 10.1.2.99.
Selecione Reservar.

Clique em Concluído.
Para adicionar a segunda regra de encaminhamento, clique em Adicionar IP e porta do front-end.

Dê um Nome para a regra de encaminhamento.
Na lista Região da sub-rede, selecione REGION_B.
Reservar uma sub-rede somente proxy

Na lista Sub-rede, selecione SUBNET_B.
Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.

Forneça um Nome para o endereço IP estático.
Na lista Endereço IP estático, selecione Quero escolher.
No campo Endereço IP, digite 10.1.3.99.
Selecione Reservar.

Clique em Concluído.

Para HTTPS:

Se você usa o HTTPS entre o cliente e o balanceador de carga, um ou mais recursos de certificado SSL serão necessários para configurar o proxy. Para criar um all-regions certificado gerenciado pelo Google, consulte a seguinte documentação:

Depois de criar o certificado gerenciado pelo Google, anexe-o diretamente ao proxy de destino. Os mapas de certificado não são suportados por balanceadores de carga de aplicativo internos entre regiões.

Para criar um certificado autogerenciado all-regions, consulte a seguinte documentação: Implantar um certificado autogerenciado regional.

Clique em Configuração de front-end.

Dê um Nome para a regra de encaminhamento.
No campo Protocolo, selecione HTTPS (includes HTTP/2).
Verifique se a Porta está definida como 443.
Na lista Região da sub-rede, selecione REGION_A.
Reservar uma sub-rede somente proxy

Na lista Sub-rede, selecione SUBNET_A.
Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.

Forneça um Nome para o endereço IP estático.
Na lista Endereço IP estático, selecione Quero escolher.
No campo Endereço IP, digite 10.1.3.99.
Selecione Reservar.

Na seçã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 de SSL na lista Política de SSL. Se você não tiver criado políticas SSL, uma política padrão do Google Cloud SSL será aplicada.
Clique em Concluído.

Adicione a segunda configuração de front-end:

Forneça um Nome para a configuração do front-end.
No campo Protocolo, selecione HTTPS (includes HTTP/2).
Verifique se a Porta está definida como 443.
Na lista Região da sub-rede, selecione REGION_B.
Reservar uma sub-rede somente proxy

Na lista Sub-rede, selecione SUBNET_B.
Na lista de Endereços IP, clique em Criar endereço IP. A página Reservar um endereço IP interno estático é aberta.

Forneça um Nome para o endereço IP estático.
Na lista Endereço IP estático, selecione Quero escolher.
No campo Endereço IP, digite 10.1.3.99.
Selecione Reservar.

Na seçã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 de SSL na lista Política de SSL. Se você não tiver criado políticas SSL, uma política padrão do Google Cloud SSL será aplicada.
Clique em Concluído.

Configurar o serviço de back-end

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.
Forneça um Nome para o serviço de back-end.
Em Protocolo, selecione HTTP.
Em Porta nomeada, insira http.
Na lista Tipo de back-end, selecione Grupo de instâncias.
Na seção Novo back-end:

Na lista Grupo de instâncias, selecione gl4-ilb-miga em REGION_A.
Defina Números de portas como 80.
Clique em Concluído.
Para adicionar outro back-end, clique em Adicionar back-end.
Na lista Grupo de instâncias, selecione gl4-ilb-migb em REGION_B.
Defina Números de portas como 80.
Clique em Concluído.

Na seção Verificação de integridade, clique em Criar verificação de integridade.

No campo Nome, use global-http-health-check.
Defina o Protocolo como HTTP.
Defina a Porta como 80.
Clique em Salvar.

Configurar as regras de roteamento

Clique em Regras de roteamento.
Em Modo, selecione Regra de host e caminho simples.
Verifique se há apenas um serviço de back-end para qualquer host e caminho sem correspondência.

Analise a configuração

Clique em Analisar e finalizar.
Revise suas configurações do balanceador de carga.
Clique em Criar.

gcloud

Defina a verificação de integridade 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 URL 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 gerenciado pelo Google, consulte a seguinte documentação:
- Criar um certificado gerenciado pelo Google emitido pela instância do Certificate Authority Service.
- Criar um certificado gerenciado pelo Google com autorização de DNS.
Depois de criar o certificado gerenciado pelo Google, anexe-o diretamente ao proxy de destino. Os mapas de certificado não são suportados por balanceadores de carga de aplicativo internos entre regiões.

Para criar um certificado autogerenciado, consulte a seguinte documentação:
- Crie uma chave privada e um certificado.
Atribua os caminhos de arquivo aos 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 para todas as regiões usando 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 regional para criar um proxy de destino com o comando gcloud compute target-https-proxies create.
```
gcloud 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ão REGION_B e outra com um VIP (10.1.3.99) na região REGION_A. Para mais informações, consulte Reservar um endereço IPv4 interno estático.

Para redes personalizadas, referencie a sub-rede na regra de encaminhamento. Observe que esta é a sub-rede da VM, não a do proxy.

Para HTTP:

Use o comando gcloud compute forwarding-rules create com as sinalizações 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 create com as sinalizações 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 integridade, use o recurso google_compute_health_check.

resource "google_compute_health_check" "default" {
  provider = google-beta
  name     = "global-http-health-check"
  http_health_check {
    port_specification = "USE_SERVING_PORT"
  }
}

Para criar o serviço de back-end, use o recurso google_compute_backend_service.

resource "google_compute_backend_service" "default" {
  name                  = "gl7-gilb-backend-service"
  provider              = google-beta
  protocol              = "HTTP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  timeout_sec           = 10
  health_checks         = [google_compute_health_check.default.id]
  backend {
    group           = google_compute_region_instance_group_manager.mig_a.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
  backend {
    group           = google_compute_region_instance_group_manager.mig_b.instance_group
    balancing_mode  = "UTILIZATION"
    capacity_scaler = 1.0
  }
}

Para criar o mapa de URL, use o recurso google_compute_url_map.

resource "google_compute_url_map" "default" {
  name            = "gl7-gilb-url-map"
  provider        = google-beta
  default_service = google_compute_backend_service.default.id
}

Para criar o proxy HTTP de destino, use o recurso google_compute_target_http_proxy.

resource "google_compute_target_http_proxy" "default" {
  name     = "gil7target-http-proxy"
  provider = google-beta
  url_map  = google_compute_url_map.default.id
}

Para criar a regra de encaminhamento, use o recurso google_compute_forwarding_rule.

resource "google_compute_global_forwarding_rule" "fwd_rule_a" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_a]
  ip_address            = "10.1.2.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-a"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_a.id
}

resource "google_compute_global_forwarding_rule" "fwd_rule_b" {
  provider              = google-beta
  depends_on            = [google_compute_subnetwork.proxy_subnet_b]
  ip_address            = "10.1.3.99"
  ip_protocol           = "TCP"
  load_balancing_scheme = "INTERNAL_MANAGED"
  name                  = "gil7forwarding-rule-b"
  network               = google_compute_network.default.id
  port_range            = "80"
  target                = google_compute_target_http_proxy.default.id
  subnetwork            = google_compute_subnetwork.subnet_b.id
}

Para saber como aplicar ou remover uma configuração do Terraform, consulte Comandos básicos do Terraform.

API

Crie a verificação de integridade fazendo uma solicitação POST ao método healthChecks.insert, substituindo PROJECT_ID pelo ID do 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 regional fazendo uma solicitação POST ao método backendServices.insert, substituindo PROJECT_ID pelo ID do 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 URL fazendo uma solicitação POST ao método urlMaps.insert, substituindo PROJECT_ID pelo ID do 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 uma solicitação POST ao método targetHttpProxies.insert, substituindo PROJECT_ID pelo ID do 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 uma solicitação POST ao método forwardingRules.insert, substituindo PROJECT_ID pelo ID do 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:

Leia os arquivos do certificado e da chave privada e crie o certificado SSL. O exemplo a seguir mostra como fazer isso com Python.

from pathlib import Path
from pprint import pprint
from typing import Union

from googleapiclient import discovery


def create_regional_certificate(
    project_id: str,
    region: str,
    certificate_file: Union[str, Path],
    private_key_file: Union[str, Path],
    certificate_name: str,
    description: str = "Certificate created from a code sample.",
) -> dict:
    """
    Create a regional SSL self-signed certificate within your Google Cloud project.

    Args:
        project_id: project ID or project number of the Cloud project you want to use.
        region: name of the region you want to use.
        certificate_file: path to the file with the certificate you want to create in your project.
        private_key_file: path to the private key you used to sign the certificate with.
        certificate_name: name for the certificate once it's created in your project.
        description: description of the certificate.

        Returns:
        Dictionary with information about the new regional SSL self-signed certificate.
    """
    service = discovery.build("compute", "v1")

    # Read the cert into memory
    with open(certificate_file) as f:
        _temp_cert = f.read()

    # Read the private_key into memory
    with open(private_key_file) as f:
        _temp_key = f.read()

    # Now that the certificate and private key are in memory, you can create the
    # certificate resource
    ssl_certificate_body = {
        "name": certificate_name,
        "description": description,
        "certificate": _temp_cert,
        "privateKey": _temp_key,
    }
    request = service.regionSslCertificates().insert(
        project=project_id, region=region, body=ssl_certificate_body
    )
    response = request.execute()
    pprint(response)

    return response

Crie o proxy HTTPS de destino fazendo uma solicitação POST ao método targetHttpsProxies.insert, substituindo PROJECT_ID pelo ID do 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 uma solicitação POST ao método globalForwardingRules.insert, substituindo PROJECT_ID pelo ID do 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"
}

Testar o balanceador de carga

Criar uma instância de VM para testar a conectividade

Crie uma VM 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-ssh

gcloud 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-ssh

Use o SSH para se conectar 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á exibindo o nome do host
- Verifique se a VM cliente pode acessar os dois endereços IP. O comando retorna o nome da VM de back-end que veiculou a solicitação:
```
curl 10.1.2.99
```
```
curl 10.1.3.99
```
  Para testes HTTPS, substitua curl pela seguinte linha de comando:
```
curl -k 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443
```
```
curl -k 'https://test.example.com:443' --connect-to test.example.com:443:10.1.3.99:443
```
  A sinalização -k faz com que o curl ignore a validação do certificado.
- Opcional: use o registro DNS configurado para resolver o endereço IP mais próximo da VM cliente. Por exemplo, DNS_NAME pode ser service.example.com.
```
curl DNS_NAME
```

Executar 100 solicitações e confirmar o balanceamento de carga delas

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:

  {
    RESULTS=
    for i in {1..100}
    do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com: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://test.example.com:443' --connect-to test.example.com: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
  }

Testar o failover

Verifique o failover para back-ends na região REGION_A quando os back-ends em REGION_B não estiverem íntegros ou acessíveis. Para simular o failover, remova todos os back-ends de REGION_B:
```
gcloud compute backend-services remove-backend BACKEND_SERVICE_NAME \
   --balancing-mode=UTILIZATION \
   --instance-group=gl7-ilb-mig-b \
   --instance-group-zone=ZONE_B
```

Conecte-se usando SSH a uma VM cliente em REGION_B.

gcloud compute ssh l7-ilb-client-b \
   --zone=ZONE_B

Envie solicitações ao endereço IP com carga balanceada na região REGION_B. A resposta ao comando mostra as respostas das VMs de back-end em REGION_A:

{
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com: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
}

Outras opções de configuração

Nesta seção, o exemplo é detalhado para fornecer outras opções de configuração. Todas as tarefas são opcionais. É possível realizá-las em qualquer ordem.

Ativar a afinidade de sessão

Estes procedimentos mostram como atualizar um serviço de back-end do balanceador de carga de aplicativo interno regional de exemplo ou do balanceador de carga de aplicativo interno multirregional para que o serviço de back-end usa afinidade de cookie gerado, afinidade de campo de cabeçalho ou afinidade de cookie HTTP.

Quando a afinidade de cookie gerado é ativada, o balanceador de carga emite um cookie na primeira solicitação. Para cada solicitação subsequente com o mesmo cookie, o balanceador de carga direciona a solicitação para a mesma instância de máquina virtual (VM, na sigla em inglês) de back-end ou endpoint. Neste exemplo, o cookie é chamado de GCILB.

Quando a afinidade de campo de cabeçalho é ativada, o balanceador de carga encaminha solicitações para VMs ou endpoints de back-end em um NEG com base no valor do cabeçalho HTTP nomeado na sinalização --custom-request-header. A afinidade de campo de cabeçalho só será válida se a política de localidade de balanceamento 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 cookie HTTP é ativada, o balanceador de carga encaminha solicitações para VMs ou endpoints de back-end em um NEG, com base em um cookie HTTP nomeado na sinalização HTTP_COOKIE com a sinalização opcional --affinity-cookie-ttl. Se o cliente não fornecer o cookie na solicitação HTTP, o proxy gerará o cookie e o retornará ao cliente em um cabeçalho Set-Cookie. A afinidade de cookie HTTP só será válida se a política de localidade de balanceamento de carga for RING_HASH ou MAGLEV e o hash consistente do serviço de back-end especificar o cookie HTTP.

Console

Para ativar ou alterar a afinidade de sessão para um serviço de back-end:

No Console do Google Cloud, acesse a página Balanceamento de carga.

Acessar o "Balanceamento de carga"
Clique em Back-ends.
Clique em gil7-backend-service (o nome do serviço de back-end que você criou para este exemplo) e selecione Editar.
Na página Detalhes do serviço de back-end, clique em Configuração avançada.
Em Afinidade da sessão, selecione o tipo de afinidade da sessão.
Clique em Atualizar.

gcloud

Use os seguintes comandos da Google Cloud CLI 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 uma solicitação "PATCH" para o 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" ]
    }

Restringir quais clientes podem enviar tráfego ao balanceador de carga

Para impedir que os clientes se conectem a um VIP interno de regra de encaminhamento do balanceador de carga de aplicativo, configure regras de firewall de saída nesses clientes. Defina essas regras de firewall em VMs específicas de cliente com base em contas de serviço ou tags.

Não é possível usar regras de firewall para restringir o tráfego de entrada para VIPs específicos de regra de encaminhamento do balanceador de carga de aplicativo interno. Qualquer cliente na mesma rede VPC e na mesma região que o VIP de regra de encaminhamento geralmente envia tráfego para o VIP da regra de encaminhamento.

Além disso, todas as solicitações para back-ends vêm de proxies que usam endereços IP no intervalo de sub-rede somente proxy. Não é possível criar regras de firewall que permitam ou neguem o tráfego de entrada nesses back-ends com base na regra de encaminhamento VIP usada por um cliente.

Veja alguns exemplos de como usar regras de firewall de saída para restringir o tráfego ao VIP da regra de encaminhamento do balanceador de carga.

Console

Para identificar as VMs do cliente, marque as VMs específicas que você quer restringir. Essas tags são usadas para associar regras de firewall às VMs clientes marcadas. Em seguida, adicione a tag ao campo TARGET_TAG nas etapas a seguir.

Para configurar isso, use uma única regra de firewall ou várias regras.

Regra única de firewall de saída

É possível configurar uma regra de saída de firewall para negar todo o tráfego de saída proveniente de VMs cliente marcadas com tag para o VIP de um balanceador de carga.

No Google Cloud Console, acesse a página Regras de firewall.

Acessar as regras de firewall
Clique em Criar regra de firewall para criar a regra que nega o tráfego de saída das VMs clientes marcadas com tag ao VIP de um balanceador de carga.
- Name: fr-deny-access
- Rede: lb-network
- Prioridade: 100
- Direção do tráfego: saída
- Ação na correspondência: negar
- Destinos: tags de destino especificadas
- Tags de meta: 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.
  - Marque a caixa de seleção tcp e insira 80 como o número da porta.
Clique em Criar.

Várias regras de firewall de saída

Uma abordagem mais escalonável envolve a configuração de duas regras. Uma regra padrão de baixa prioridade que impeça todos os clientes de acessar o VIP do balanceador de carga. Uma segunda regra de prioridade mais alta que permita que um subconjunto de clientes marcados com tag acessem o VIP do balanceador de carga. Somente VMs com tags podem acessar o VIP.

No Google Cloud Console, acesse a página Regras de firewall.

Acessar as regras de firewall
Clique em Criar regra de firewall para criar a regra de prioridade mais baixa que nega acesso por padrão:
- Name: fr-deny-all-access-low-priority
- Rede: lb-network
- Prioridade: 200
- Direção do tráfego: saída
- Ação na correspondência: negar
- Destinos: tags de destino especificadas
- Tags de meta: 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.
  - Marque a caixa de seleção tcp e insira 80 como o número da porta.
Clique em Criar.
Clique em Criar regra de firewall para criar a regra de prioridade mais alta que permita o tráfego de determinadas instâncias marcadas com tag.
- Name: fr-allow-some-access-high-priority
- Rede: lb-network
- Prioridade: 100
- Direção do tráfego: saída
- Ação na correspondência: permitir
- Destinos: tags de destino especificadas
- Tags de meta: 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.
  - Marque a caixa de seleção tcp e insira 80 como o número da porta.
Clique em Criar.

gcloud

Para identificar as VMs do cliente, marque as VMs específicas que você quer restringir. Em seguida, adicione a tag ao campo TARGET_TAG nestas etapas.

Para configurar isso, use uma única regra de firewall ou várias regras.

Regra única de firewall de saída

É possível configurar uma regra de saída de firewall para negar todo o tráfego de saída proveniente de VMs cliente marcadas com tag para o VIP de um balanceador 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 escalonável envolve a configuração de duas regras: uma regra padrão de baixa prioridade, que restringe o acesso do VIP do balanceador de carga, e uma segunda, que permite que um subconjunto de clientes marcados acesse o VIP do balanceador de carga. Somente VMs com tags podem acessar o VIP.

Criar a regra de menor prioridade:

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

Criar a regra de prioridade mais alta:

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 tags para controlar o acesso, basta usar a opção --target-service-accounts em vez da sinalização --target-tags ao criar regras de firewall.

Escalonar o acesso restrito a back-ends internos do balanceador de carga do aplicativo com base em sub-redes

Manter regras de firewall separadas ou adicionar novos IPs de balanceamento de carga às regras existentes, conforme descrito na seção anterior, é inconveniente à medida que o número de regras de encaminhamento aumenta. Uma maneira de evitar isso é alocar os endereços IP da regra de encaminhamento de uma sub-rede reservada. Depois, o tráfego de instâncias marcadas com tags ou contas de serviço é permitido ou bloqueado usando a sub-rede reservada como o intervalo de destino das regras de firewall. Isso permite que você controle efetivamente o acesso a um grupo de VIPs de regras de encaminhamento sem precisar manter as regras de saída do firewall por VIP.

Veja a seguir as etapas de nível mais alto para configurar isso, pressupondo que você criará todos os outros recursos necessários do balanceador de carga separadamente.

gcloud

Crie uma sub-rede regional que será usada para alocar 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/24

Crie uma regra de encaminhamento que use um endereço da sub-rede. O exemplo a seguir usa o endereço 10.127.0.1 da sub-rede criada na etapa 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-proxy

Crie uma regra de firewall para restringir o tráfego destinado aos endereços IP do intervalo na 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

Usar o mesmo endereço IP entre várias regras de encaminhamento internas

Para que várias regras de encaminhamento interno compartilhem o mesmo endereço IP interno, é necessário reservar o endereço IP e definir a sinalização --purpose como SHARED_LOADBALANCER_VIP.

gcloud

gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
    --region=REGION \
    --subnet=SUBNET_NAME \
    --purpose=SHARED_LOADBALANCER_VIP

Se você precisar redirecionar o tráfego HTTP para HTTPS, crie duas regras de encaminhamento com um endereço IP comum. Para mais informações, consulte Configurar o redirecionamento HTTP para HTTPS em balanceadores de carga internos de aplicativos.

Configurar políticas de roteamento de DNS

Se os clientes estiverem em várias regiões, convém tornar o balanceador de carga de aplicativo interno entre regiões acessível por meio de VIPs nessas regiões. Essa configuração multirregional minimiza os custos de latência e trânsito de rede. Além disso, é possível 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 Gerenciar políticas de roteamento de DNS e verificações de integridade.

gcloud

Para criar uma entrada de 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:

DNS_ENTRY: nome de domínio ou DNS do conjunto de registros
Por exemplo, service.example.com.
REGION_A e REGION_B: as regiões em que o balanceador de carga foi configurado.

API

Crie o registro DNS fazendo uma solicitação POST ao método ResourceRecordSets.create. Substitua PROJECT_ID pelo ID do 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"
              }
            ]
          }
        }
      ]
    }
  }
}

Atualizar tempo limite do sinal de atividade HTTP do cliente

O balanceador de carga criado nas etapas anteriores foi configurado com um valor padrão para o tempo limite do sinal de atividade HTTP do cliente.

Para atualizar o tempo limite do sinal de atividade HTTP do cliente, use as instruções a seguir.

Console

No Console do Google Cloud, acesse a página Balanceamento de carga.

Acessar o "Balanceamento de carga"
Clique no nome do balanceador de carga que você quer modificar.
Clique em Editar.
Clique em Configuração de front-end.
Expanda Recursos avançados. Em Tempo limite de sinal de atividade HTTP, insira um valor de tempo limite.
Clique em Atualizar.
Para revisar as alterações, clique em Analisar e finalizar e depois em Atualizar.

gcloud

Para um balanceador de carga HTTP, atualize o proxy HTTP de destino usando o 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 usando 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:

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 do tempo limite do sinal de atividade HTTP de 5 a 600 segundos.

Ativar detecção de outliers

É possível ativar a detecção de outliers em serviços de back-end globais para identificar NEGs sem servidor não íntegros e reduzir o número de solicitações enviadas aos NEGs sem servidor não íntegros.

A detecção de outliers é ativada no serviço de back-end usando um dos seguintes métodos:

O método consecutiveErrors (outlierDetection.consecutiveErrors), em que um código de status HTTP da série 5xx se qualifica como erro.
O método consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), em que apenas os códigos de status HTTP 502, 503 e 504 se qualificam como erros.

Use as etapas a seguir para ativar a detecção de outliers para um serviço de back-end existente. Observe que, mesmo depois de ativar a detecção de outliers, algumas solicitações podem ser enviadas para o serviço não íntegro e retornar um código de status 5xx aos clientes. Para reduzir ainda mais a taxa de erro, configure valores mais agressivos nos parâmetros de detecção de outliers. Para mais informações, consulte o campo outlierDetection.

Console

No Console do Google Cloud, acesse a página Balanceamento de carga.

Acessar o "Balanceamento de carga"
Clique no nome do balanceador de carga em que está o serviço de back-end a ser editado.
Na página Detalhes do balanceador de carga, clique em Editar.
Na página Editar balanceador de carga de aplicativo interno entre regiões, clique em Configuração de back-end.
Na página Configuração de back-end, clique em Editar no serviço de back-end que você quer modificar.
Role para baixo e expanda a seção Advanced Configurations.
Na seção Detecção de outliers, marque a caixa de seleção Ativar.

Clique em Editar para configurar a detecção de outliers.

Verifique se as seguintes opções estão configuradas com estes valores:

Propriedade	Valor
Erros consecutivos	5
Interval	1000
Tempo base de expulsão	30000
Percentual máximo de expulsão	50
Como aplicar erros consecutivos	100

Neste exemplo, a análise de detecção de outliers é executada a cada segundo. Se o número de código de status HTTP 5xx consecutivos recebidos por um proxy Envoy for cinco ou mais, o endpoint de back-end será removido do pool de balanceamento de carga desse proxy Envoy por 30 segundos. Quando a porcentagem de aplicação é definida em 100%, o serviço de back-end aplica a remoção de endpoints não íntegros dos pools de balanceamento de carga desses proxies Envoy específicos sempre que a análise de detecção de outliers é executada. Se as condições de remoção forem atendidas, até 50% dos endpoints de back-end do pool de balanceamento de carga poderão ser removidos.

Clique em Salvar.
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 aplicativo interno entre regiões, clique em Atualizar.

gcloud

Exporte o serviço de back-end para um arquivo YAML.

gcloud compute backend-services export BACKEND_SERVICE_NAME \
  --destination=BACKEND_SERVICE_NAME.yaml --global

Substitua BACKEND_SERVICE_NAME pelo nome do serviço de back-end.

Edite a configuração YAML do serviço de back-end para adicionar os campos de detecção de outliers conforme destacado na seguinte configuração YAML, na seção outlierDetection:

Neste exemplo, a análise de detecção de outliers é executada a cada segundo. Se o número de código de status HTTP 5xx consecutivos recebidos por um proxy Envoy for cinco ou mais, o endpoint de back-end será removido do pool de balanceamento de carga desse proxy Envoy por 30 segundos. Quando a porcentagem de aplicação é definida em 100%, o serviço de back-end aplica a remoção de endpoints não íntegros dos pools de balanceamento de carga desses proxies Envoy específicos sempre que a análise de detecção de outliers é executada. Se as condições de remoção forem atendidas, até 50% dos endpoints de back-end do pool de balanceamento de carga poderão ser removidos.
```
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:
- BACKEND_SERVICE_NAME: o nome do serviço de back-end
- PROJECT_ID: ID do projeto
- REGION_A e REGION_B: as regiões em que o balanceador de carga foi configurado.
- SERVERLESS_NEG_NAME: o nome do primeiro NEG sem servidor
- SERVERLESS_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 detecção de outliers agora está ativada no serviço de back-end.

Configurar um balanceador de carga de aplicativo interno entre regiões com back-ends de grupo de instâncias de VM

Antes de começar

Configurar um recurso de certificado SSL

Permissões

Visão geral da configuração

Configurar a rede e as sub-redes

Configurar as sub-redes de back-end

Console

gcloud

Terraform

API

Configurar a sub-rede somente proxy

Console

gcloud

Terraform

API

Configurar regras de firewall

Console

gcloud

Terraform

API

criar um grupo gerenciado de instâncias

Console

gcloud

Terraform

API

Configurar o balanceador de carga

Console

Iniciar a configuração

gcloud

Terraform

API

Testar o balanceador de carga

Criar uma instância de VM para testar a conectividade

Executar 100 solicitações e confirmar o balanceamento de carga delas

Testar o failover

Outras opções de configuração

Ativar a afinidade de sessão

Console

gcloud

API

Restringir quais clientes podem enviar tráfego ao balanceador de carga

Console

Regra única de firewall de saída

Várias regras de firewall de saída

gcloud

Regra única de firewall de saída

Várias regras de firewall de saída

Escalonar o acesso restrito a back-ends internos do balanceador de carga do aplicativo com base em sub-redes

gcloud

Usar o mesmo endereço IP entre várias regras de encaminhamento internas

gcloud

Configurar políticas de roteamento de DNS

gcloud

API

Atualizar tempo limite do sinal de atividade HTTP do cliente

Console

gcloud

Ativar detecção de outliers

Console

gcloud

A seguir