Configure a comutação por falha para balanceadores de carga de rede de encaminhamento interno

Este guia usa um exemplo para ensinar a configurar a comutação por falha para um Google Cloud Network Load Balancer de encaminhamento interno. Antes de seguir este guia, familiarize-se com o seguinte:

• Conceitos do balanceador de carga de rede de encaminhamento interno
• Conceitos de comutação por falha para balanceadores de carga de rede de passagem interna
• Vista geral das regras de firewall
• Conceitos de verificação de saúde

Autorizações

Para seguir este guia, tem de criar instâncias e modificar uma rede num projeto. Deve ser proprietário ou editor do projeto, ou ter todas as seguintes funções do IAM do Compute Engine:

Tarefa	Função necessária
Crie redes, sub-redes e componentes do balanceador de carga	Administrador da rede
Adicione e remova regras de firewall	Administrador de segurança
Crie instâncias	Administrador de instâncias do Compute

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

• Controlo de acesso
• Condições do IAM

Configuração

Este guia mostra como configurar e testar um Network Load Balancer de encaminhamento interno que usa a comutação por falha. Os passos nesta secção descrevem como configurar o seguinte:

1. Uma rede VPC de exemplo com sub-redes personalizadas
2. Regras de firewall que permitem ligações recebidas a VMs de back-end
3. VMs de back-end:
   • Um back-end principal num grupo de instâncias não gerido na zona us-west1-a
   • Um back-end de alternativa num grupo de instâncias não gerido na zona us-west1-c
4. Uma VM do cliente para testar as ligações e observar o comportamento de comutação por falha
5. Os seguintes componentes do balanceador de carga de rede de encaminhamento interno:
   • Uma verificação de funcionamento para o serviço de back-end
   • Um serviço de back-end interno na região us-west1 para gerir a distribuição de ligações entre as VMs de back-end
   • Uma regra de encaminhamento interna e um endereço IP interno para o front-end do balanceador de carga

A arquitetura para este exemplo tem o seguinte aspeto:

Exemplo de comutação por falha simples para um Network Load Balancer de passagem interno (clique para aumentar).

Neste exemplo, os grupos de instâncias não geridos são usados para os back-ends principal e de alternativa. Para mais informações, consulte os grupos de instâncias suportados.

Configurar uma rede, uma região e uma sub-rede

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

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

• Região: a região é us-west1.

• Sub-rede: a sub-rede, lb-subnet, usa o intervalo de IPs 10.1.2.0/24.

Nota: pode alterar o nome da rede, da região e dos parâmetros da sub-rede. No entanto, os passos seguintes neste guia usam os parâmetros de rede, região e sub-rede, conforme descrito acima.

Para criar a rede e a sub-rede de exemplo, siga estes passos.

Consola

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

   Aceda a redes de VPC

2. Clique em Criar rede de VPC.

3. Introduza um Nome de lb-network.

4. Na secção Subnets (Sub-redes):

   • Defina o Subnet creation mode (Modo de criação de sub-rede) como Custom (Personalizado).
   • Na secção Nova sub-rede, introduza as seguintes informações:
     • Nome: lb-subnet
     • Região: us-west1
     • Intervalo de endereços IP: 10.1.2.0/24
     • Clique em Concluído.

5. Clique em Criar.

gcloud

1. Crie a rede VPC personalizada:

   gcloud compute networks create lb-network --subnet-mode=custom
   

2. Crie uma sub-rede na rede lb-network na região us-west1:

   gcloud compute networks subnets create lb-subnet \
       --network=lb-network \
       --range=10.1.2.0/24 \
       --region=us-west1
   

API

Faça um pedido POST ao método networks.insert.

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

{
 "routingConfig": {
   "routingMode": "REGIONAL"
 },
 "name": "lb-network",
 "autoCreateSubnetworks": false
}

Faça um pedido POST ao método subnetworks.insert. Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
 "name": "lb-subnet",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.1.2.0/24",
 "privateIpGoogleAccess": false
}

Configurar regras de firewall

Este exemplo usa as seguintes regras de firewall:

• fw-allow-lb-subnet: uma regra de entrada, aplicável a todos os destinos na rede VPC, que permite o tráfego de origens no intervalo 10.1.2.0/24. Esta regra permite o tráfego de entrada de qualquer origem no lb-subnet para as instâncias (VMs) que estão a ser equilibradas.

• fw-allow-ssh: uma regra de entrada aplicada às instâncias com balanceamento de carga, que permite a conetividade SSH de entrada na porta TCP 22 a partir de qualquer endereço. Pode escolher um intervalo de IPs de origem mais restritivo para esta regra. Por exemplo, pode especificar os intervalos de IPs dos sistemas a partir dos quais planeia iniciar sessões SSH. Este exemplo usa a etiqueta de destino allow-ssh para identificar as VMs às quais a regra de firewall se aplica.

• fw-allow-health-check: uma regra de entrada, aplicável às instâncias com balanceamento de carga, que permite o tráfego dos sistemas de verificação de estado (130.211.0.0/22 e 35.191.0.0/16). Este exemplo usa a etiqueta de destino allow-health-check para identificar as instâncias às quais deve aplicar-se. Google Cloud

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.

Nota: tem de criar uma regra de firewall para permitir verificações de funcionamento a partir dos intervalos de IP dos sistemas de sondagem. Google Cloud Consulte os intervalos de IPs de sondagem para mais informações.

Consola

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

   Aceder a Políticas de firewall

2. Clique em Criar regra de firewall e introduza as seguintes informações para criar a regra que permite o tráfego de sub-rede:

   • Nome: fw-allow-lb-subnet
   • Rede: lb-network
   • Prioridade: 1000
   • Direção do tráfego: entrada
   • Ação na correspondência: permitir
   • Alvos: todas as instâncias na rede
   • Filtro de origem: intervalos IPv4
   • Intervalos IPv4 de origem: 10.1.2.0/24
   • Protocolos e portas: permitir tudo

3. Clique em Criar.

4. Clique novamente em Criar regra de firewall para criar a regra que permite ligações SSH de entrada:

   • Nome: fw-allow-ssh
   • Rede: lb-network
   • Prioridade: 1000
   • Direção do tráfego: entrada
   • Ação na correspondência: permitir
   • Objetivos: etiquetas de objetivo 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 e, em seguida, escreva: tcp:22

5. Clique em Criar.

6. Clique em Criar regra de firewall pela terceira vez para criar a regra que permite as Google Cloud verificações de funcionamento:

   • Nome: fw-allow-health-check
   • Rede: lb-network
   • Prioridade: 1000
   • Direção do tráfego: entrada
   • Ação na correspondência: permitir
   • Objetivos: etiquetas de objetivo especificadas
   • Etiquetas de segmentação: allow-health-check
   • Filtro de origem: intervalos IPv4
   • Intervalos de IPv4 de origem: 130.211.0.0/22 e 35.191.0.0/16
   • Protocolos e portas: permitir tudo

7. Clique em Criar.

gcloud

1. Crie a regra de firewall fw-allow-lb-subnet para permitir a comunicação de com a sub-rede:

   gcloud compute firewall-rules create fw-allow-lb-subnet \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=10.1.2.0/24 \
       --rules=tcp,udp,icmp
   

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

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

3. Crie a regra fw-allow-health-check para permitir Google Cloud verificações de funcionamento.

   gcloud compute firewall-rules create fw-allow-health-check \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-health-check \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --rules=tcp,udp,icmp
   

API

Crie a regra de firewall fw-allow-lb-subnet fazendo um pedido POST ao método firewalls.insert. Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

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

{
 "name": "fw-allow-lb-subnet",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "priority": 1000,
 "sourceRanges": [
   "10.1.2.0/24"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   },
   {
     "IPProtocol": "udp"
   },
   {
     "IPProtocol": "icmp"
   }
 ],
 "direction": "INGRESS",
 "logConfig": {
   "enable": false
 },
 "disabled": false
}

Crie a regra de firewall fw-allow-ssh fazendo um pedido POST ao método firewalls.insert. Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

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

{
 "name": "fw-allow-ssh",
      "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "priority": 1000,
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS",
"logConfig": {
  "enable": false
},
"disabled": false
}

Crie a regra de firewall fw-allow-health-check fazendo um pedido POST ao método firewalls.insert. Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

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

{
 "name": "fw-allow-health-check",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "priority": 1000,
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "allow-health-check"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   },
   {
     "IPProtocol": "udp"
   },
   {
     "IPProtocol": "icmp"
   }
 ],
 "direction": "INGRESS",
 "logConfig": {
   "enable": false
 },
 "disabled": false
}

Criar VMs de back-end e grupos de instâncias

Neste passo, vai criar as VMs de back-end e os grupos de instâncias não geridos:

• O grupo de instâncias ig-a em us-west1-a é um back-end principal com duas VMs:
  • vm-a1
  • vm-a2
• O grupo de instâncias ig-c em us-west1-c é um back-end de comutação por falha com duas VMs:
  • vm-c1
  • vm-c2

Os back-ends principal e de ativação pós-falha são colocados em zonas separadas para clareza das instruções e para processar a ativação pós-falha caso uma zona fique inativa.

Cada VM principal e de cópia de segurança está configurada para executar um servidor Web Apache nas portas TCP 80 e 443. A cada VM é atribuído um endereço IP interno no intervalo lb-subnet para acesso do cliente e um endereço IP externo (público) efémero para acesso SSH. Para obter informações sobre a remoção de endereços IP externos, consulte o artigo sobre a remoção de endereços IP externos de VMs de back-end.

Por predefinição, o Apache está configurado para ser associado a qualquer endereço IP. Os balanceadores de carga de rede de encaminhamento interno entregam pacotes preservando o endereço IP de destino.

Certifique-se de que o software de servidor executado nas VMs principal e de cópia de segurança está a ouvir no endereço IP da regra de encaminhamento interno do balanceador de carga. Se configurar várias regras de encaminhamento interno, certifique-se de que o seu software escuta o endereço IP interno associado a cada uma delas. O endereço IP de destino de um pacote enviado para uma VM de back-end por um balanceador de carga de rede de encaminhamento direto interno é o endereço IP interno da regra de encaminhamento.

Para simplificar as instruções, todas as VMs principais e de cópia de segurança executam o Debian GNU/Linux 12.

Consola

Crie VMs de back-end

1. Na Google Cloud consola, aceda à página Instâncias de VM.

   Aceder às instâncias de VM

2. Repita os passos seguintes para criar quatro VMs, usando as seguintes combinações de nomes e zonas.

   • Nome: vm-a1, zona: us-west1-a
   • Nome: vm-a2, zona: us-west1-a
   • Nome: vm-c1, zona: us-west1-c
   • Nome: vm-c2, zona: us-west1-c

3. Clique em Criar instância.

4. Defina o Nome conforme indicado no passo 2.

5. Para a Região, escolha us-west1 e escolha uma Zona, conforme indicado no passo 2.

6. Na secção Disco de arranque, certifique-se de que a imagem selecionada é o Debian GNU/Linux 12 (bookworm). Clique em Escolher para alterar a imagem, se necessário.

7. Clique em Opções avançadas.

8. Clique em Rede e configure os seguintes campos:

   1. Para Etiquetas de rede, introduza allow-health-check e allow-ssh.
   2. Para Interfaces de rede, selecione o seguinte:
      • Rede: lb-network
      • Subnet: lb-subnet

9. Clique em Gestão. Introduza o seguinte script no campo Script de arranque. O conteúdo do script é idêntico para todas as quatro VMs:

   #! /bin/bash
   apt-get update
   apt-get install apache2 -y
   a2ensite default-ssl
   a2enmod ssl
   vm_hostname="$(curl -H "Metadata-Flavor:Google" \
   http://metadata.google.internal/computeMetadata/v1/instance/name)"
   echo "Page served from: $vm_hostname" | \
   tee /var/www/html/index.html
   systemctl restart apache2
   

10. Clique em Criar.

Crie grupos de instâncias

1. Na Google Cloud consola, aceda à página Grupos de instâncias.

   Aceda a Grupos de instâncias

2. Repita os passos seguintes para criar dois grupos de instâncias não geridos, cada um com duas VMs, usando estas combinações.

   • Grupo de instâncias: ig-a, zona: us-west1-a, VMs: vm-a1 e vm-a2
   • Grupo de instâncias: ig-c, zona: us-west1-c, VMs: vm-c1 e vm-c2

3. Clique em Criar grupo de instâncias.

4. Clique em Novo grupo de instâncias não gerido.

5. Defina o Nome conforme indicado no passo 2.

6. Na secção Localização, escolha us-west1 para a Região e, em seguida, escolha uma Zona, conforme indicado no passo 2.

7. Para Rede, introduza lb-network.

8. Para Sub-rede, introduza lb-subnet.

9. Na secção Instâncias de VM, adicione as VMs conforme indicado no passo 2.

10. Clique em Criar.

gcloud

1. Crie quatro VMs executando o seguinte comando quatro vezes, usando estas quatro combinações para VM_NAME e ZONE. O conteúdo do script é idêntico para todas as quatro VMs.

   • VM_NAME de vm-a1 e ZONE de us-west1-a
   • VM_NAME de vm-a2 e ZONE de us-west1-a
   • VM_NAME de vm-c1 e ZONE de us-west1-c
   • VM_NAME de vm-c2 e ZONE de us-west1-c

   gcloud compute instances create VM_NAME \
       --zone=ZONE \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --tags=allow-ssh,allow-health-check \
       --subnet=lb-subnet \
       --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://metadata.google.internal/computeMetadata/v1/instance/name)"
         echo "Page served from: $vm_hostname" | \
         tee /var/www/html/index.html
         systemctl restart apache2'
   

2. Crie os dois grupos de instâncias não geridos em cada zona:

   gcloud compute instance-groups unmanaged create ig-a \
       --zone=us-west1-a
   gcloud compute instance-groups unmanaged create ig-c \
       --zone=us-west1-c
   

3. Adicione as VMs aos grupos de instâncias adequados:

   gcloud compute instance-groups unmanaged add-instances ig-a \
       --zone=us-west1-a \
       --instances=vm-a1,vm-a2
   gcloud compute instance-groups unmanaged add-instances ig-c \
       --zone=us-west1-c \
       --instances=vm-c1,vm-c2
   

API

Crie quatro VMs de back-end fazendo quatro pedidos POST ao método instances.insert.

Para as quatro VMs, use os seguintes nomes e zonas de VMs:

• VM_NAME de vm-a1 e ZONE de us-west1-a
• VM_NAME de vm-a2 e ZONE de us-west1-a
• VM_NAME de vm-c1 e ZONE de us-west1-c
• VM_NAME de vm-c2 e ZONE de us-west1-c

Substitua o seguinte:

• PROJECT_ID: o ID do seu projeto
• ZONE: a zona da instância

• DEBIAN_IMAGE_NAME: o nome da imagem Debian para a instância. Pode obter o DEBIAN_IMAGE_NAME atual executando o seguinte comando gcloud:

  gcloud compute images list \
   --filter="family=debian-12"
  

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances

{
 "name": "VM_NAME",
 "tags": {
   "items": [
     "allow-health-check",
     "allow-ssh"
   ]
 },
 "machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/machineTypes/e2-standard-2",
 "canIpForward": false,
 "networkInterfaces": [
   {
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
     "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
     "accessConfigs": [
       {
         "type": "ONE_TO_ONE_NAT",
         "name": "external-nat",
         "networkTier": "PREMIUM"
       }
     ]
   }
 ],
 "disks": [
   {
     "type": "PERSISTENT",
     "boot": true,
     "mode": "READ_WRITE",
     "autoDelete": true,
     "deviceName": "VM_NAME",
     "initializeParams": {
       "sourceImage": "projects/debian-cloud/global/images/DEBIAN_IMAGE_NAME",
       "diskType": "projects/PROJECT_ID/zones/ZONE/diskTypes/pd-standard",
       "diskSizeGb": "10"
     }
   }
 ],
 "metadata": {
   "items": [
     {
       "key": "startup-script",
       "value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
     }
   ]
 },
 "scheduling": {
   "preemptible": false
 },
 "deletionProtection": false
}

Crie dois grupos de instâncias fazendo um pedido POST ao método instanceGroups.insert. Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups

{
 "name": "ig-a",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups

{
 "name": "ig-c",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}

Adicione instâncias a cada grupo de instâncias fazendo um pedido POST ao método instanceGroups.addInstances. Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-a/addInstances

{
 "instances": [
   {
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a1",
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a2"
   }
 ]
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-c/addInstances

{
 "instances": [
   {
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-c1",
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-c2"
   }
 ]
}

Criar uma VM de cliente

Este exemplo cria uma VM cliente (vm-client) na mesma região que o balanceador de carga. O cliente é usado para demonstrar como funciona a comutação por falha.

Consola

1. Na Google Cloud consola, aceda à página Instâncias de VM.

   Aceder às instâncias de VM

2. Clique em Criar instância.

3. Defina o Nome como vm-client.

4. Defina a Zona como us-west1-a.

5. Clique em Opções avançadas.

6. Clique em Rede e configure os seguintes campos:

   1. Para etiquetas de rede, introduza allow-ssh.
   2. Para Interfaces de rede, selecione o seguinte:
      • Rede: lb-network
      • Subnet: lb-subnet

7. Clique em Criar.

gcloud

A VM do cliente pode estar em qualquer zona na mesma região que o balanceador de carga e pode usar qualquer sub-rede nessa região. Neste exemplo, o cliente está na zona us-west1-a e usa a mesma sub-rede usada pelas VMs principal e de cópia de segurança.

gcloud compute instances create vm-client \
    --zone=us-west1-a \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=lb-subnet

API

Faça um pedido POST ao método instances.insert.

Substitua o seguinte:

• PROJECT_ID: o ID do seu projeto

• DEBIAN_IMAGE_NAME: o nome da imagem Debian para a instância. Pode obter o DEBIAN_IMAGE_NAME atual executando o seguinte comando gcloud:

  gcloud compute images list \
   --filter="family=debian-12"
  

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances

{
 "name": "vm-client",
 "tags": {
   "items": [
     "allow-ssh"
   ]
 },
 "machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/machineTypes/e2-standard-2",
 "canIpForward": false,
 "networkInterfaces": [
   {
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
     "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
     "accessConfigs": [
       {
         "type": "ONE_TO_ONE_NAT",
         "name": "external-nat",
         "networkTier": "PREMIUM"
       }
     ]
   }
 ],
 "disks": [
   {
     "type": "PERSISTENT",
     "boot": true,
     "mode": "READ_WRITE",
     "autoDelete": true,
     "deviceName": "vm-client",
     "initializeParams": {
       "sourceImage": "projects/debian-cloud/global/images/DEBIAN_IMAGE_NAME",
       "diskType": "projects/PROJECT_ID/zones/us-west1-a/diskTypes/pd-standard",
       "diskSizeGb": "10"
     }
   }
 ],
 "scheduling": {
   "preemptible": false
 },
 "deletionProtection": false
}

Configurar componentes do balanceador de carga

Estes passos configuram todos os componentes do balanceador de carga de rede de encaminhamento interno, começando pela verificação de estado e pelo serviço de back-end e, em seguida, pelos componentes de front-end:

• Verificação de funcionamento: este exemplo usa uma verificação de funcionamento de HTTP que verifica simplesmente uma resposta HTTP 200 (OK). Para mais informações, consulte a secção de verificações de funcionamento da vista geral do balanceador de carga de rede de encaminhamento interno.

• Serviço de back-end: uma vez que o exemplo passa tráfego HTTP através do balanceador de carga, a configuração especifica TCP e não UDP. Para ilustrar a comutação por falha, este serviço de back-end tem uma taxa de comutação por falha de 0.75.

• Regra de encaminhamento: este exemplo cria uma única regra de encaminhamento interno.

• Endereço IP interno: neste exemplo, especificamos um endereço IP interno, 10.1.2.99, quando criamos a regra de encaminhamento.

Consola

Inicie a configuração

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda ao balanceamento de carga

2. Clique em Criar equilibrador de carga.
3. Para Tipo de balanceador de carga, selecione Balanceador de carga de rede (TCP/UDP/SSL) e clique em Seguinte.
4. Para Proxy ou passagem, selecione Passagem do balanceador de carga e clique em Seguinte.
5. Para Público ou interno, selecione Interno e clique em Seguinte.
6. Clique em Configurar.

Configuração básica

1. Defina o Nome como be-ilb.
2. Defina a Região como us-west1.
3. Defina Rede como lb-network.
4. Clique em Configuração de back-end e faça as seguintes alterações:
   1. Para Back-ends, na secção Novo item, selecione o grupo de instâncias.ig-a Certifique-se de que a opção Usar este grupo de instâncias como um grupo de comutação por falha para a cópia de segurança não está selecionada. Clique em Concluído.
   2. Clique em Adicionar back-end. Na secção Novo item apresentada, selecione o grupo de instâncias ig-c. Selecione Usar este grupo de instâncias como um grupo de comutação por falha para a cópia de segurança. Clique em Concluído.
   3. Para Verificação de funcionamento, escolha Criar outra verificação de funcionamento, introduza as seguintes informações e clique em Guardar e continuar:
      • Nome: hc-http-80
      • Protocolo: HTTP
      • Porta: 80
      • Protocolo proxy: NONE
      • Caminho do pedido: / tenha em atenção que, quando usa a consola para criar o balanceador de carga, a verificação de funcionamento é global. Google Cloud Se quiser criar uma verificação de funcionamento regional, use gcloud ou a API.
   4. Clique em Configurações avançadas. Na secção Política de alternativa, configure o seguinte:
      • Rácio de comutação por falha: 0.75
      • Selecione Ativar esgotamento de ligações na comutação por falha.
   5. Verifique se existe uma marca de verificação azul junto a Configuração de back-end antes de continuar. Se não o fez, reveja este passo.
5. Clique em Configuração do front-end. Na secção Novo IP e porta de front-end, faça as seguintes alterações:
   1. Nome: fr-ilb
   2. Subnetwork: ilb-subnet
   3. Em IP interno, escolha Reservar um endereço IP interno estático, introduza as seguintes informações e clique em Reservar:
      • Nome: ip-ilb
      • Endereço IP estático: deixar-me escolher
      • Endereço IP personalizado: 10.1.2.99
   4. Portas: escolha Única e introduza 80 para o Número da porta.
   5. Antes de continuar, verifique se existe uma marca de verificação azul junto a Configuração do frontend. Se não o fez, reveja este passo.
6. Clique em Rever e finalizar. Verifique as definições.
7. Clique em Criar.

gcloud

1. Crie uma nova verificação de funcionamento de HTTP para testar a conetividade TCP às VMs na porta 80.

   gcloud compute health-checks create http hc-http-80 \
       --region=us-west1 \
       --port=80
   

2. Crie o serviço de back-end para o tráfego HTTP:

   gcloud compute backend-services create be-ilb \
       --load-balancing-scheme=internal \
       --protocol=tcp \
       --region=us-west1 \
       --health-checks=hc-http-80 \
       --health-checks-region=us-west1 \
       --failover-ratio 0.75
   

3. Adicione o back-end principal ao serviço de back-end:

   gcloud compute backend-services add-backend be-ilb \
       --region=us-west1 \
       --instance-group=ig-a \
       --instance-group-zone=us-west1-a
   

4. Adicione o back-end de alternativa ao serviço de back-end:

   gcloud compute backend-services add-backend be-ilb \
       --region=us-west1 \
       --instance-group=ig-c \
       --instance-group-zone=us-west1-c \
       --failover
   

5. Crie uma regra de encaminhamento para o serviço de back-end. Quando criar a regra de encaminhamento, especifique 10.1.2.99 para o IP interno na sub-rede.

   gcloud compute forwarding-rules create fr-ilb \
       --region=us-west1 \
       --load-balancing-scheme=internal \
       --network=lb-network \
       --subnet=lb-subnet \
       --address=10.1.2.99 \
       --ip-protocol=TCP \
       --ports=80 \
       --backend-service=be-ilb \
       --backend-service-region=us-west1
   

API

Crie a verificação de funcionamento fazendo um pedido POST ao método regionHealthChecks.insert. Substitua PROJECT_ID pelo ID do seu projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionHealthChecks

{
"name": "hc-http-80",
"type": "HTTP",
"httpHealthCheck": {
  "port": 80
}
}

Crie o serviço de back-end regional fazendo um pedido POST ao método regionBackendServices.insert. Substitua PROJECT_ID pelo ID do seu projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices

{
"name": "be-ilb",
"backends": [
  {
    "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-a",
    "balancingMode": "CONNECTION"
  },
  {
    "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-c",
    "balancingMode": "CONNECTION"
    "failover": true
  }
],
"failoverPolicy": {
  "failoverRatio": 0.75
},
"healthChecks": [
  "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/healthChecks/hc-http-80"
],
"loadBalancingScheme": "INTERNAL",
"connectionDraining": {
  "drainingTimeoutSec": 0
 }
}

Crie a regra de encaminhamento fazendo um pedido POST ao método forwardingRules.insert. Substitua PROJECT_ID pelo ID do seu projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules

{
"name": "fr-ilb",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
  "80", "8008", "8080", "8088"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"backendService": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}

Testes

Estes testes mostram como validar a configuração do equilibrador de carga e saber mais sobre o respetivo comportamento esperado.

Procedimento de teste do cliente

Este procedimento contacta o balanceador de carga a partir da VM do cliente. Vai usar este procedimento para concluir os outros testes.

1. Ligue-se à instância de VM do cliente.

   gcloud compute ssh vm-client --zone=us-west1-a
   

2. Faça um pedido Web ao equilibrador de carga através de curl para contactar o respetivo endereço IP.

   curl http://10.1.2.99
   

3. Tenha em atenção o texto devolvido pelo comando curl. O nome da VM de back-end que gera a resposta é apresentado nesse texto; por exemplo: Page served from: vm-a1

Testar o estado inicial

Depois de configurar o balanceador de carga de exemplo, todas as quatro VMs de back-end devem estar em bom estado:

• As duas VMs principais, vm-a1 e vm-a2
• As duas VMs de cópia de segurança, vm-c1 e vm-c2

Siga o procedimento de teste do cliente. Repita o segundo passo algumas vezes. O comportamento esperado é que o tráfego seja publicado pelas duas VMs principais, vm-a1 e vm-a2, porque ambas estão em bom estado. Deve ver cada VM principal a apresentar uma resposta aproximadamente metade do tempo porque não foi configurada nenhuma afinidade de sessão para este equilibrador de carga.

Testar a comutação por falha

Este teste simula a falha de vm-a1 para que possa observar o comportamento de comutação por falha.

1. Estabeleça ligação à VM vm-a1.

   gcloud compute ssh vm-a1 --zone=us-west1-a
   

2. Pare o servidor Web Apache. Após dez segundos, Google Cloud considera que esta VM não está em bom estado. (A verificação de funcionamento hc-http-80 que criou na configuração usa o intervalo de verificação predefinido de cinco segundos e o limite não saudável de duas sondagens com falhas consecutivas.)

   sudo apachectl stop
   

3. Siga o procedimento de teste do cliente. Repita o segundo passo algumas vezes. O comportamento esperado é que o tráfego seja publicado pelas duas VMs de cópia de segurança, vm-c1 e vm-c2. Uma vez que apenas uma VM principal, vm-a2, está em bom estado, a proporção de VMs principais em bom estado em relação ao total de VMs principais é de 0.5. Este número é inferior ao limite de comutação por falha de 0.75, pelo que Google Cloud reconfigurou o conjunto ativo do equilibrador de carga para usar as VMs de cópia de segurança. Deve ver cada VM de backup a fornecer uma resposta aproximadamente metade das vezes desde que não tenha sido configurada nenhuma afinidade de sessão para este equilibrador de carga.

Teste de reversão

Este teste simula a reposição reiniciando o servidor Apache em vm-a1.

1. Estabeleça ligação à VM vm-a1.

   gcloud compute ssh vm-a1 --zone=us-west1-a
   

2. Inicie o servidor Web Apache e aguarde 10 segundos.

   sudo apachectl start
   

3. Siga o procedimento de teste do cliente. Repita o segundo passo algumas vezes. O comportamento esperado é que o tráfego seja publicado pelas duas VMs principais, vm-a1 e vm-a2. Com ambas as VMs principais em bom estado, a relação entre VMs principais em bom estado e o total de VMs principais é 1.0, superior ao limite de comutação por falha de 0.75, pelo que o Google Cloud configurou o conjunto ativo para usar novamente as VMs principais.

Adicionar mais VMs de back-end

Esta secção expande a configuração de exemplo adicionando mais VMs primárias e de cópia de segurança ao balanceador de carga. Para tal, cria mais dois grupos de instâncias de back-end para demonstrar que pode distribuir VMs primárias e de cópia de segurança por várias zonas na mesma região:

• Um terceiro grupo de instâncias, ig-d em us-west1-c, funciona como um back-end principal com duas VMs:
  • vm-d1
  • vm-d2
• Um quarto grupo de instâncias, ig-b em us-west1-a, funciona como um back-end de comutação por falha com duas VMs:
  • vm-b1
  • vm-b2

A arquitetura modificada para este exemplo tem o seguinte aspeto:

Comutação por falha do balanceador de carga de rede de passagem interna de várias zonas (clique para aumentar).

Crie VMs e grupos de instâncias adicionais

Siga estes passos para criar as VMs primárias e de backup adicionais, bem como os respetivos grupos de instâncias não geridos.

Consola

Crie VMs de back-end

1. Na Google Cloud consola, aceda à página Instâncias de VM.

   Aceder às instâncias de VM

2. Repita os passos seguintes para criar quatro VMs, usando as seguintes combinações de nomes e zonas.

   • Nome: vm-b1, zona: us-west1-a
   • Nome: vm-b2, zona: us-west1-a
   • Nome: vm-d1, zona: us-west1-c
   • Nome: vm-d2, zona: us-west1-c

3. Clique em Criar instância.

4. Defina o Nome conforme indicado no passo 2.

5. Para a Região, escolha us-west1 e escolha uma Zona, conforme indicado no passo 2.

6. Na secção Disco de arranque, certifique-se de que a imagem selecionada é o Debian GNU/Linux 12 (bookworm). Clique em Escolher para alterar a imagem, se necessário.

7. Clique em Opções avançadas e faça as seguintes alterações:

   • Clique em Rede e adicione as seguintes etiquetas de rede: allow-ssh e allow-health-check
   • Clique no botão de edição em Interfaces de rede e faça as seguintes alterações. Em seguida, clique em Concluído:
     • Rede: lb-network
     • Subnet: lb-subnet
     • IP interno principal: efémero (automático)
     • IP externo: efémero

   • Clique em Gestão. No campo Script de arranque, copie e cole o seguinte conteúdo do script. O conteúdo do script é idêntico para todas as quatro VMs:

     #! /bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://metadata.google.internal/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2
     

8. Clique em Criar.

Crie grupos de instâncias

1. Na Google Cloud consola, aceda à página Grupos de instâncias.

   Aceda a Grupos de instâncias

2. Repita os passos seguintes para criar dois grupos de instâncias não geridos, cada um com duas VMs, usando estas combinações.

   • Grupo de instâncias: ig-b, zona: us-west1-a, VMs: vm-b1 e vm-b2
   • Grupo de instâncias: ig-d, zona: us-west1-c, VMs: vm-d1 e vm-d2

3. Clique em Criar grupo de instâncias.

4. Clique em Novo grupo de instâncias não gerido.

5. Defina o Nome conforme indicado no passo 2.

6. Na secção Localização, escolha us-west1 para a Região e, em seguida, escolha uma Zona, conforme indicado no passo 2.

7. Para Rede, introduza lb-network.

8. Para Sub-rede, introduza lb-subnet.

9. Na secção Instâncias de VM, adicione as VMs conforme indicado no passo 2.

10. Clique em Criar.

gcloud

1. Crie quatro VMs executando o seguinte comando quatro vezes, usando estas quatro combinações para VM_NAME e ZONE. O conteúdo do script é idêntico para todas as quatro VMs.

   • VM_NAME de vm-b1 e ZONE de us-west1-a
   • VM_NAME de vm-b2 e ZONE de us-west1-a
   • VM_NAME de vm-d1 e ZONE de us-west1-c
   • VM_NAME de vm-d2 e ZONE de us-west1-c

   gcloud compute instances create VM_NAME \
       --zone=ZONE \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --tags=allow-ssh,allow-health-check \
       --subnet=lb-subnet \
       --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://metadata.google.internal/computeMetadata/v1/instance/name)"
         echo "Page served from: $vm_hostname" | \
         tee /var/www/html/index.html
         systemctl restart apache2'
   

2. Crie os dois grupos de instâncias não geridos em cada zona:

   gcloud compute instance-groups unmanaged create ig-b \
       --zone=us-west1-a
   gcloud compute instance-groups unmanaged create ig-d \
       --zone=us-west1-c
   

3. Adicione as VMs aos grupos de instâncias adequados:

   gcloud compute instance-groups unmanaged add-instances ig-b \
       --zone=us-west1-a \
       --instances=vm-b1,vm-b2
   gcloud compute instance-groups unmanaged add-instances ig-d \
       --zone=us-west1-c \
       --instances=vm-d1,vm-d2
   

API

Crie quatro VMs de back-end fazendo quatro pedidos POST ao método instances.insert.

Para as quatro VMs, use os seguintes nomes e zonas de VMs:

• VM_NAME de vm-b1 e ZONE de us-west1-a
• VM_NAME de vm-b2 e ZONE de us-west1-a
• VM_NAME de vm-d1 e ZONE de us-west1-c
• VM_NAME de vm-d2 e ZONE de us-west1-c

Substitua o seguinte:

• PROJECT_ID: o ID do seu projeto

• DEBIAN_IMAGE_NAME: o nome da imagem Debian para a instância. Pode obter o DEBIAN_IMAGE_NAME atual executando o seguinte comando gcloud:

  gcloud compute images list \
   --filter="family=debian-12"
  

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances

{
 "name": "VM_NAME",
 "tags": {
   "items": [
     "allow-health-check",
     "allow-ssh"
   ]
 },
 "machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/machineTypes/e2-standard-2",
 "canIpForward": false,
 "networkInterfaces": [
   {
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
     "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
     "accessConfigs": [
       {
         "type": "ONE_TO_ONE_NAT",
         "name": "external-nat",
         "networkTier": "PREMIUM"
       }
     ]
   }
 ],
 "disks": [
   {
     "type": "PERSISTENT",
     "boot": true,
     "mode": "READ_WRITE",
     "autoDelete": true,
     "deviceName": "VM_NAME",
     "initializeParams": {
       "sourceImage": "projects/debian-cloud/global/images/DEBIAN_IMAGE_NAME",
       "diskType": "projects/PROJECT_ID/zones/ZONE/diskTypes/pd-standard",
       "diskSizeGb": "10"
     }
   }
 ],
 "metadata": {
   "items": [
     {
       "key": "startup-script",
       "value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
     }
   ]
 },
 "scheduling": {
   "preemptible": false
 },
 "deletionProtection": false
}

Crie dois grupos de instâncias fazendo um pedido POST ao método instanceGroups.insert. Substitua PROJECT_ID pelo ID do seu projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups

{
 "name": "ig-b",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups

{
 "name": "ig-d",
 "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
 "subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}

Adicione instâncias a cada grupo de instâncias fazendo um pedido POST ao método instanceGroups.addInstances. Substitua PROJECT_ID pelo ID do seu projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-b/addInstances

{
 "instances": [
   {
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-b1",
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-b2"
   }
 ]
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-d/addInstances

{
 "instances": [
   {
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-d1",
     "instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-d2"
   }
 ]
}

Adicionar um back-end principal

Pode usar este procedimento como modelo para adicionar um grupo de instâncias não gerido ao serviço de back-end de um Network Load Balancer de encaminhamento interno existente como back-end principal. Para a configuração de exemplo, este procedimento mostra como adicionar o grupo de instâncias ig-d como um back-end principal ao equilibrador de carga be-ilb.

Consola

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. No separador Balanceadores de carga, clique no nome de um balanceador de carga de TCP interno ou UDP interno existente (neste exemplo, be-ilb).

3. Clique em Editar .

4. Na Configuração de back-end, clique em Adicionar back-end e selecione um grupo de instâncias não gerido (neste exemplo, ig-d).

5. Certifique-se de que a opção Usar este grupo de instâncias como um grupo de comutação por falha para a cópia de segurança não está selecionada.

6. Clique em Concluído e, de seguida, em Atualizar.

gcloud

Use o seguinte comando gcloud para adicionar um back-end principal a um serviço de back-end de um Network Load Balancer de passagem interno existente.

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
   --instance-group INSTANCE_GROUP_NAME \
   --instance-group-zone INSTANCE_GROUP_ZONE \
   --region REGION

Substitua o seguinte:

• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga. Para o exemplo, use be-ilb.
• INSTANCE_GROUP_NAME: o nome do grupo de instâncias a adicionar como um back-end principal. Para o exemplo, use ig-d.
• INSTANCE_GROUP_ZONE: é a zona onde o grupo de instâncias está definido. Para o exemplo, use us-west1-c.
• REGION: a região do balanceador de carga. Para o exemplo, use us-west1.

API

Adicione um back-end principal a um serviço de back-end existente com o método regionBackendServices.patch.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "backends":
  [
    {
      "balancingMode": "connection",
      "failover": false,
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/INSTANCE_GROUP_ZONE/instanceGroups/INSTANCE_GROUP_NAME"
    }
  ]
}

Substitua o seguinte:

• PROJECT_ID: o ID do seu projeto
• REGION: a região do balanceador de carga. Para o exemplo, use us-west1.
• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga. Para o exemplo, use be-ilb.
• INSTANCE_GROUP_NAME: o nome do grupo de instâncias a adicionar como um back-end principal. Para o exemplo, use ig-d.
• INSTANCE_GROUP_ZONE: a zona onde o grupo de instâncias está definido. Para o exemplo, use us-west1-c.

Adicionar um back-end de alternativa

Pode usar este procedimento como modelo para adicionar um grupo de instâncias não gerido ao serviço de back-end de um Network Load Balancer de encaminhamento interno existente como um back-end de failover. Para a configuração de exemplo, este procedimento mostra como adicionar o grupo de instâncias ig-b como um motor de processamento de reserva ao equilibrador de carga be-ilb.

Consola

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. No separador Balanceadores de carga, clique no nome de um balanceador de carga existente do tipo TCP/UDP (interno) (neste exemplo, be-ilb).

3. Clique em Editar .

4. Na Configuração de back-end, clique em Adicionar back-end e selecione um grupo de instâncias não gerido (neste exemplo, ig-b).

5. Selecione Usar este grupo de instâncias como um grupo de alternativa para a cópia de segurança.

6. Clique em Concluído e, de seguida, em Atualizar.

gcloud

Use o seguinte comando gcloud para adicionar um back-end de alternativa a um serviço de back-end de um Network Load Balancer de passagem interno existente.

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
   --instance-group INSTANCE_GROUP_NAME \
   --instance-group-zone INSTANCE_GROUP_ZONE \
   --region REGION \
   --failover

Substitua o seguinte:

• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga. Para o exemplo, use be-ilb.
• INSTANCE_GROUP_NAME: o nome do grupo de instâncias a adicionar como um back-end principal. Para o exemplo, use ig-b.
• INSTANCE_GROUP_ZONE: é a zona onde o grupo de instâncias está definido. Para o exemplo, use us-west1-a.
• REGION é a região do balanceador de carga. Para o exemplo, use us-west1.

API

Adicione um back-end de alternativa a um serviço de back-end existente com o método regionBackendServices.patch.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "backends":
  [
    {
      "balancingMode": "connection",
      "failover": true,
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/INSTANCE_GROUP_ZONE/instanceGroups/INSTANCE_GROUP_NAME"
    }
  ]
}

Substitua o seguinte:

• PROJECT_ID: o ID do seu projeto
• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga. Para o exemplo, use be-ilb.
• INSTANCE_GROUP_NAME: o nome do grupo de instâncias a adicionar como um back-end principal. Para o exemplo, use ig-b.
• INSTANCE_GROUP_ZONE: é a zona onde o grupo de instâncias está definido. Para o exemplo, use us-west1-a.
• REGION: a região do balanceador de carga. Para o exemplo, use us-west1.

Converter um back-end principal ou de alternativa

Pode converter um back-end principal num back-end de alternativa ou vice-versa, sem ter de remover o grupo de instâncias do serviço de back-end do Network Load Balancer de passagem interno.

Consola

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. No separador Balanceadores de carga, clique no nome de um balanceador de carga existente do tipo TCP/UDP (interno).

3. Clique em Editar .

4. Na Configuração de back-end, clique no nome de um dos grupos de instâncias de back-end. Em seguida:

   • Para tornar o grupo de instâncias um back-end de alternativa, selecione Usar este grupo de instâncias como um grupo de alternativa para cópia de segurança.
   • Para tornar o grupo de instâncias um back-end principal, desmarque a opção Usar este grupo de instâncias como um grupo de alternativa em caso de falha para a cópia de segurança.

5. Clique em Concluído e, de seguida, em Atualizar.

gcloud

Use o seguinte comando gcloud para converter um back-end principal existente num back-end de alternativa:

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
   --instance-group INSTANCE_GROUP_NAME \
   --instance-group-zone INSTANCE_GROUP_ZONE \
   --region REGION \
   --failover

Use o seguinte comando gcloud para converter um back-end de alternativa existente num back-end principal:

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
   --instance-group INSTANCE_GROUP_NAME \
   --instance-group-zone INSTANCE_GROUP_ZONE \
   --region REGION \
   --no-failover

Substitua o seguinte:

• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga
• INSTANCE_GROUP_NAME: o nome do grupo de instâncias a adicionar como um back-end principal
• INSTANCE_GROUP_ZONE: a zona onde o grupo de instâncias está definido
• REGION: a região do balanceador de carga

API

Converta um back-end principal num back-end de alternativa ou vice-versa através do método regionBackendServices.patch.

Para converter um back-end principal num back-end de alternativa:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "backends":
  [
    {
      "failover": true,
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/INSTANCE_GROUP_ZONE/instanceGroups/INSTANCE_GROUP_NAME"
    }
  ]
}

Para converter um back-end de alternativa num back-end principal:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "backends":
  [
    {
      "failover": false,
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/INSTANCE_GROUP_ZONE/instanceGroups/INSTANCE_GROUP_NAME"
    }
  ],
}

Substitua o seguinte:

• PROJECT_ID: o ID do seu projeto
• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga
• INSTANCE_GROUP_NAME: o nome do grupo de instâncias a adicionar como um back-end principal
• INSTANCE_GROUP_ZONE: a zona onde o grupo de instâncias está definido
• REGION: a região do balanceador de carga

Configurar políticas de comutação por falha

Esta secção descreve como gerir uma política de comutação por falha para o serviço de back-end de um Network Load Balancer de encaminhamento interno. Uma política de alternativa consiste no seguinte:

• Rácio de comutação por falha
• Diminuir o tráfego quando todas as VMs de back-end estão em mau estado de funcionamento
• Drenagem da ligação na comutação por falha

Para mais informações sobre os parâmetros de uma política de alternativa, consulte:

• Definir uma taxa de alternativa
• Eliminar tráfego quando não existe uma VM em bom estado
• Drenagem de ligações em caso de comutação por falha e recuperação

Definir uma política de alternativa

As instruções seguintes descrevem como definir a política de comutação por falha para um Network Load Balancer de encaminhamento interno existente.

Consola

Para definir uma política de alternativa através da consola Google Cloud , tem de ter, pelo menos, um back-end de alternativa.

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. No separador Balanceadores de carga, clique no nome de um balanceador de carga existente do tipo TCP/UDP (interno).

3. Clique em Editar .

4. Certifique-se de que tem, pelo menos, um back-end de alternativa. Pelo menos, um dos back-ends do balanceador de carga tem de ter a opção Usar este grupo de instâncias como um grupo de alternativa para cópia de segurança selecionada.

5. Clique em Configurações avançadas.

   • Para a Política de alternativa, defina a Rácio de alternativa para um valor entre 0.0 e 1.0, inclusive.
   • Selecione a caixa junto a Ativar eliminação de tráfego se quiser eliminar o tráfego quando todas as VMs ativas e todas as VMs de cópia de segurança estiverem em mau estado.
   • Selecione a caixa junto a Ativar esgotamento de ligações na comutação por falha se quiser terminar rapidamente as ligações existentes durante a comutação por falha.

6. Clique em Rever e finalizar e, de seguida, em Atualizar.

gcloud

Para definir uma política de comutação por falha através da CLI gcloud, atualize o serviço de back-end do balanceador de carga:

gcloud compute backend-services update BACKEND_SERVICE_NAME \
   --region REGION \
   --failover-ratio FAILOVER_RATIO \
   --drop-traffic-if-unhealthy \
   --no-connection-drain-on-failover

Substitua o seguinte:

• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga. Para o exemplo, use be-ilb.
• REGION: a região do balanceador de carga. Para o exemplo, use us-west1.
• FAILOVER_RATIO: a taxa de ativação pós-falha. Os valores possíveis estão entre 0.0 e 1.0, inclusive. Para o exemplo, use 0.75.
• --drop-traffic-if-unhealthy indica ao balanceador de carga que elimine o tráfego quando todas as VMs principais e todas as VMs de cópia de segurança não estiverem em bom estado. Altere esta opção para --no-drop-traffic-if-unhealthy se quiser distribuir o tráfego entre todas as VMs principais quando todas as VMs de back-end estiverem em mau estado.
• --no-connection-drain-on-failover indica ao balanceador de carga que termine rapidamente as ligações TCP existentes durante a comutação por falha. Use --connection-drain-on-failover para ativar a drenagem da ligação durante a transferência de controlo.

API

Use o método regionBackendServices.patch para definir a política de alternativa.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

{
  "failoverPolicy":
  {
    "failoverRatio": FAILOVER_RATIO,
    "dropTrafficIfUnhealthy": [true|false],
    "disableConnectionDrainOnFailover": [true|false]
  }
}

Substitua o seguinte:

• PROJECT_ID: o ID do seu projeto
• REGION: a região do balanceador de carga
• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga
• FAILOVER_RATIO: a taxa de ativação pós-falha. Os valores possíveis estão entre 0.0 e 1.0, inclusive.
• A definição de dropTrafficIfUnhealthy como true indica ao balanceador de carga que elimine o tráfego quando todas as VMs principais e todas as VMs de backup estiverem em mau estado. Defina esta opção como false se quiser distribuir o tráfego entre todas as VMs principais quando todas as VMs de back-end estiverem em mau estado.
• A definição de disableConnectionDrainOnFailover como true indica ao equilibrador de carga que termine rapidamente as ligações TCP existentes quando faz uma comutação por falha. Defina esta opção como false para ativar a drenagem de ligações durante a comutação por falha.

Visualizar uma política de comutação por falha

As instruções seguintes descrevem como ver a política de comutação por falha existente para um Network Load Balancer de encaminhamento interno.

Consola

A consola Google Cloud mostra as definições da política de comutação por falha existentes quando edita um Network Load Balancer de encaminhamento interno. Consulte o artigo sobre como definir uma política de comutação por falha para obter instruções.

gcloud

Para listar as definições da política de comutação por falha através da CLI gcloud, use o seguinte comando. As definições não definidas numa política de alternativa usam os valores predefinidos da política de alternativa.

gcloud compute backend-services describe BACKEND_SERVICE_NAME \
   --region REGION \
   --format="get(failoverPolicy)"

Substitua o seguinte:

• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga
• REGION: a região do balanceador de carga

API

Use o método regionBackendServices.get para ver a política de comutação por falha.

A resposta ao pedido da API mostra a política de alternativa. Segue-se um exemplo.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_NAME

Substitua o seguinte:

• PROJECT_ID: o ID do seu projeto
• REGION: a região do balanceador de carga
• BACKEND_SERVICE_NAME: o nome do serviço de back-end do balanceador de carga

{
...
"failoverPolicy": {
  "disableConnectionDrainOnFailover": false,
  "dropTrafficIfUnhealthy": false,
  "failoverRatio": 0.75
...
}

O que se segue?

• Consulte a Vista geral do balanceador de carga de rede de encaminhamento interno para ver os princípios importantes.
• Consulte Conceitos de comutação por falha para equilibradores de carga de rede de passagem interna para ver informações importantes sobre a comutação por falha.
• Consulte o artigo Configure um balanceador de carga de rede de encaminhamento interno para ver um exemplo de configuração de um balanceador de carga de rede de encaminhamento interno.
• Consulte o artigo Registo e monitorização do balanceador de carga de rede de encaminhamento interno para obter informações sobre a configuração do registo e da monitorização do balanceador de carga de rede de encaminhamento interno.
• Consulte o artigo Balanceadores de carga de rede de encaminhamento interno e redes ligadas para ver informações sobre o acesso a balanceadores de carga de rede de encaminhamento interno a partir de redes de pares ligadas à sua rede VPC.
• Consulte o artigo Resolva problemas com balanceadores de carga de rede de encaminhamento interno para ver informações sobre como resolver problemas com o seu balanceador de carga de rede de encaminhamento interno.
• Limpe a configuração do balanceador de carga.