Configure um balanceador de carga de rede de proxy interno entre regiões com back-ends de grupos de instâncias de VM

Este documento fornece instruções para configurar um balanceador de carga de rede de proxy interno entre regiões para os seus serviços executados em VMs do Compute Engine.

Antes de começar

Antes de seguir este guia, familiarize-se com o seguinte:

Autorizações

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

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

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

Vista geral da configuração

Pode configurar o equilibrador de carga, conforme mostrado no diagrama seguinte:

Implementação de alta disponibilidade do balanceador de carga de rede de proxy interno entre regiões.
Implementação de alta disponibilidade do Network Load Balancer do proxy interno entre regiões (clique para aumentar).

Conforme mostrado no diagrama, este exemplo cria um Network Load Balancer de proxy interno entre regiões numa rede VPC, com um serviço de back-end e dois grupos de instâncias geridos (MIGs) de back-end nas regiões REGION_A e REGION_B.

O diagrama mostra o seguinte:

  1. Uma rede da VPC com as seguintes sub-redes:

    • Sub-rede SUBNET_A e uma sub-rede só de proxy em REGION_A.
    • Sub-rede SUBNET_B e uma sub-rede só de proxy em REGION_B.

    Tem de criar sub-redes apenas de proxy em cada região de uma rede VPC onde usa balanceadores de carga de rede de proxy interno entre regiões. A sub-rede apenas de proxy da região é partilhada entre todos os equilibradores de carga de rede de proxy interno entre regiões na região. Os endereços de origem dos pacotes enviados do balanceador de carga para os back-ends do seu serviço são atribuídos a partir da sub-rede apenas de proxy. Neste exemplo, a sub-rede só de proxy para a região REGION_B tem um intervalo de endereços IP principal de 10.129.0.0/23 e, para REGION_A, tem um intervalo de endereços IP principal de 10.130.0.0/23, que é o tamanho de sub-rede recomendado.

  2. A configuração de alta disponibilidade tem back-ends de grupos de instâncias geridas para implementações de VMs do Compute Engine nas regiões REGION_A e REGION_B. Se os back-ends numa região estiverem inativos, o tráfego é transferido para a outra região.

  3. Um serviço de back-end global que monitoriza a utilização e o estado de funcionamento dos back-ends.

  4. Um proxy TCP de destino global, que recebe um pedido do utilizador e o encaminha para o serviço de back-end.

  5. Regras de encaminhamento globais, que têm o endereço IP interno regional do seu balanceador de carga e podem encaminhar cada pedido recebido para o proxy de destino.

    O endereço IP interno associado à regra de encaminhamento pode ser proveniente de uma sub-rede na mesma rede e região que os back-ends. Tenha em atenção as seguintes condições:

    • O endereço IP pode (mas não tem de) ser proveniente da mesma sub-rede que os grupos de instâncias de back-end.
    • O endereço IP não pode ser proveniente de uma sub-rede só de proxy reservada com a respetiva flag --purpose definida como GLOBAL_MANAGED_PROXY.
    • Se quiser usar o mesmo endereço IP interno com várias regras de encaminhamento, defina a flag --purpose do endereço IP como SHARED_LOADBALANCER_VIP.

Configure a rede e as sub-redes

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

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

  • Rede. A rede é uma rede VPC no modo personalizado denominada NETWORK.

  • Sub-redes para back-ends.

    • Uma sub-rede denominada SUBNET_A na região REGION_A usa 10.1.2.0/24 para o respetivo intervalo de IP principal.
    • Uma sub-rede denominada SUBNET_B na região REGION_B usa 10.1.3.0/24 para o respetivo intervalo de IP principal.

  • Sub-redes para proxies.

    • Uma sub-rede denominada PROXY_SN_A na região REGION_A usa 10.129.0.0/23 para o respetivo intervalo de IP principal.
    • Uma sub-rede denominada PROXY_SN_B na região REGION_B usa 10.130.0.0/23 para o respetivo intervalo de IP principal.

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

Configure as sub-redes de back-end

Consola

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

    Aceda a redes de VPC

  2. Clique em Criar rede de VPC.

  3. Indique um Nome para a rede.

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

  5. Crie uma sub-rede para os back-ends do balanceador de carga. Na secção Nova sub-rede, introduza as seguintes informações:

    • Indique um Nome para a sub-rede.
    • Selecione uma região: REGION_A
    • Introduza um intervalo de endereços IP: 10.1.2.0/24

  6. Clique em Concluído.

  7. Clique em Adicionar sub-rede.

  8. Crie uma sub-rede para os back-ends do balanceador de carga. Na secção Nova sub-rede, introduza as seguintes informações:

    • Indique um Nome para a sub-rede.
    • Selecione uma região: REGION_B
    • Introduza um intervalo de endereços IP: 10.1.3.0/24

  9. Clique em Concluído.

  10. Clique em Criar.

gcloud

  1. Crie a rede VPC personalizada com o comando gcloud compute networks create:

    gcloud compute networks create NETWORK \
    --subnet-mode=custom

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

  3. 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 as 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 um pedido POST ao método networks.insert. Substitua PROJECT_ID pelo ID do seu projeto.

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

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

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

{
 "name": "SUBNET_A",
 "network": "projects/PROJECT_ID/global/networks/lb-network-crs-reg",
 "ipCidrRange": "10.1.2.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_A",
}

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

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

{
 "name": "SUBNET_B",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "ipCidrRange": "10.1.3.0/24",
 "region": "projects/PROJECT_ID/regions/REGION_B",
}

Configure a sub-rede só de proxy

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

Esta sub-rede apenas de proxy é usada por todos os equilibradores de carga regionais baseados no Envoy na mesma região que a rede VPC. Só pode existir uma sub-rede só de proxy ativa para uma determinada finalidade, por região e por rede.

Consola

Se estiver a usar a Google Cloud consola, pode esperar e criar a sub-rede apenas de proxy mais tarde na página Equilíbrio de carga.

Se quiser criar a sub-rede apenas de proxy agora, siga estes passos:

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

    Aceda a redes de VPC

  2. Clique no nome da rede de VPC.
  3. No separador Sub-rede, clique em Adicionar sub-rede.
  4. Indique um nome para a sub-rede só de proxy.
  5. Selecione uma região: REGION_A
  6. Na lista Finalidade, selecione Proxy gerido entre regiões.
  7. No campo Intervalo de endereços IP, introduza 10.129.0.0/23.
  8. Clique em Adicionar.

Crie a sub-rede só de proxy em REGION_B

  1. No separador Sub-rede, clique em Adicionar sub-rede.
  2. Indique um nome para a sub-rede só de proxy.
  3. Selecione uma região: REGION_B
  4. Na lista Finalidade, selecione Proxy gerido entre regiões.
  5. No campo Intervalo de endereços IP, introduza 10.130.0.0/23.
  6. Clique em Adicionar.

gcloud

Crie as sub-redes só de proxy com o comando gcloud compute networks subnets create.

    gcloud compute networks subnets create PROXY_SN_A \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_A \
        --network=NETWORK \
        --range=10.129.0.0/23
    
    gcloud compute networks subnets create PROXY_SN_B \
        --purpose=GLOBAL_MANAGED_PROXY \
        --role=ACTIVE \
        --region=REGION_B \
        --network=NETWORK \
        --range=10.130.0.0/23

Terraform

Para criar a sub-rede apenas de proxy da VPC na rede lb-network-crs-reg, use o recurso google_compute_subnetwork.

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 só de proxy com o método subnetworks.insert, substituindo PROJECT_ID pelo ID do seu projeto.

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks

    {
      "name": " PROXY_SN_A",
      "ipCidrRange": "10.129.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_A",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }
   
    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks

    {
      "name": "PROXY_SN_B",
      "ipCidrRange": "10.130.0.0/23",
      "network": "projects/PROJECT_ID/global/networks/NETWORK",
      "region": "projects/PROJECT_ID/regions/REGION_B",
      "purpose": "GLOBAL_MANAGED_PROXY",
      "role": "ACTIVE"
    }

Configure regras de firewall

Este exemplo usa as seguintes regras de firewall:

  • fw-ilb-to-backends. Uma regra de entrada, aplicável às instâncias com balanceamento de carga, que permite a conetividade SSH de entrada na porta TCP 22 a partir de qualquer endereço. Pode escolher um intervalo de endereços IP de origem mais restritivo para esta regra. Por exemplo, pode especificar apenas os intervalos de endereços IP do sistema a partir do qual inicia sessões SSH. Este exemplo usa a etiqueta de destino allow-ssh para identificar as VMs às quais a regra de firewall se aplica.

  • fw-healthcheck. Uma regra de entrada, aplicável às instâncias com balanceamento de carga, que permite todo o tráfego TCP dos Google Cloud sistemas de verificação de estado (em 130.211.0.0/22 e 35.191.0.0/16). Este exemplo usa a etiqueta de destino load-balanced-backend para identificar as VMs às quais a regra de firewall se aplica.

  • fw-backends. Uma regra de entrada, aplicável às instâncias com balanceamento de carga, que permite o tráfego TCP nas portas 80, 443 e 8080 dos proxies geridos do balanceador de carga de rede do proxy interno. Este exemplo usa a etiqueta de destino load-balanced-backend para identificar as VMs às quais a regra de firewall se aplica.

Sem estas regras de firewall, a regra de negação predefinida de entrada bloqueia o tráfego de entrada para as instâncias de back-end.

As etiquetas de destino definem as instâncias de back-end. Sem as etiquetas de destino, as regras da firewall aplicam-se a todas as instâncias de back-end na rede VPC. Quando criar as VMs de back-end, certifique-se de que inclui as etiquetas de destino especificadas, conforme mostrado em Criar um grupo de instâncias gerido.

Consola

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

    Aceder a Políticas de firewall

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

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

  3. Clique em Criar.

  4. Clique em Criar regra de firewall uma segunda vez para criar a regra que permite as Google Cloud verificações de funcionamento:

    • Nome: fw-healthcheck
    • Rede: NETWORK
    • Direção do tráfego: entrada
    • Ação na correspondência: Permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de segmentação: load-balanced-backend
    • Filtro de origem: intervalos IPv4
    • Intervalos de IPv4 de origem: 130.211.0.0/22 e 35.191.0.0/16

    • Protocolos e portas:

      • Escolha Protocolos e portas especificados.
      • Selecione a caixa de verificação TCP e, de seguida, introduza 80 para o número da porta.

      Como prática recomendada, limite esta regra apenas aos protocolos e às portas que correspondam aos usados pela sua verificação de funcionamento. Se usar tcp:80 para o protocolo e a porta, Google Cloud pode usar o HTTP na porta 80 para contactar as suas VMs, mas não pode usar o HTTPS na porta 443 para as contactar.

  5. Clique em Criar.

  6. Clique em Criar regra de firewall pela terceira vez para criar a regra que permite que os servidores proxy do balanceador de carga se liguem aos back-ends:

    • Nome: fw-backends
    • Rede: NETWORK
    • Direção do tráfego: entrada
    • Ação na correspondência: Permitir
    • Objetivos: etiquetas de destino especificadas
    • Etiquetas de segmentação: load-balanced-backend
    • Filtro de origem: intervalos IPv4
    • Intervalos de IPv4 de origem: 10.129.0.0/23 e 10.130.0.0/23
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Selecione a caixa de verificação TCP e, de seguida, introduza 80, 443, 8080 para os números de porta.

  7. Clique em Criar.

gcloud

  1. Crie a regra de firewall fw-ilb-to-backends 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-ilb-to-backends \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  2. Crie a regra fw-healthcheck para permitir Google Cloud verificações de funcionamento. Este exemplo permite todo o tráfego TCP de sondas de verificação de estado. No entanto, pode configurar um conjunto mais restrito de portas para satisfazer as suas necessidades.

    gcloud compute firewall-rules create fw-healthcheck \
    --network=NETWORK \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp

  3. Crie a regra fw-backends para permitir que os proxies do balanceador de carga de rede do proxy interno se liguem aos seus back-ends. Defina source-ranges para os intervalos atribuídos da sua sub-rede só de proxy, por exemplo, 10.129.0.0/23 e 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

API

Crie a regra de firewall fw-ilb-to-backends fazendo um pedido POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
 "name": "fw-ilb-to-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "0.0.0.0/0"
 ],
 "targetTags": [
   "allow-ssh"
 ],
 "allowed": [
  {
    "IPProtocol": "tcp",
    "ports": [
      "22"
    ]
  }
 ],
"direction": "INGRESS"
}

Crie a regra de firewall fw-healthcheck fazendo um pedido POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
 "name": "fw-healthcheck",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "130.211.0.0/22",
   "35.191.0.0/16"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp"
   }
 ],
 "direction": "INGRESS"
}

Crie a regra de firewall fw-backends para permitir o tráfego TCP na sub-rede de proxy para o método firewalls.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
 "name": "fw-backends",
 "network": "projects/PROJECT_ID/global/networks/NETWORK",
 "sourceRanges": [
   "10.129.0.0/23",
   "10.130.0.0/23"
 ],
 "targetTags": [
   "load-balanced-backend"
 ],
 "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "80"
     ]
   },
 {
     "IPProtocol": "tcp",
     "ports": [
       "443"
     ]
   },
   {
     "IPProtocol": "tcp",
     "ports": [
       "8080"
     ]
   }
 ],
 "direction": "INGRESS"
}

Crie um grupo de instâncias geridas

Esta secção mostra como criar um modelo e um grupo de instâncias gerido. O grupo de instâncias gerido fornece instâncias de VMs que executam os servidores de back-end de um balanceador de carga de rede de proxy interno entre regiões de exemplo. Para o seu grupo de instâncias, pode definir um serviço HTTP e mapear um nome de porta para a porta relevante. O serviço de back-end do balanceador de carga encaminha o tráfego para as portas nomeadas. O tráfego dos clientes é equilibrado em termos de carga para os servidores de back-end. Para fins de demonstração, os back-ends publicam os respetivos nomes de anfitriões.

Consola

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

    Aceda a Modelos de instâncias

    1. Clique em Criar modelo de instância.
    2. Em Nome, introduza gil4-backendeast1-template.
    3. Certifique-se de que o Disco de arranque está definido para uma imagem Debian, como Debian GNU/Linux 12 (bookworm). Estas instruções usam comandos que só estão disponíveis no Debian, como apt-get.
    4. Clique em Opções avançadas.
    5. Clique em Rede e configure os seguintes campos:
      1. Para Etiquetas de rede, introduza allow-ssh e load-balanced-backend.
      2. Para Interfaces de rede, selecione o seguinte:
        • Rede: NETWORK
        • Subnet: SUBNET_B

    6. Clique em Gestão. Introduza o seguinte script no campo Script de arranque.

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

    7. Clique em Criar.

    8. Clique em Criar modelo de instância.

    9. Em Nome, introduza gil4-backendwest1-template.

    10. Certifique-se de que o Disco de arranque está definido para uma imagem Debian, como Debian GNU/Linux 12 (bookworm). Estas instruções usam comandos que só estão disponíveis no Debian, como apt-get.

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

    12. Clique em Rede e configure os seguintes campos:

      1. Para Etiquetas de rede, introduza allow-ssh e load-balanced-backend.
      2. Para Interfaces de rede, selecione o seguinte:
        • Rede: NETWORK
        • Subnet: SUBNET_A

    13. Clique em Gestão. Introduza o seguinte script no campo Script de arranque.

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

    14. Clique em Criar.

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

    Aceda a Grupos de instâncias

    1. Clique em Criar grupo de instâncias.
    2. Selecione Novo grupo de instâncias gerido (sem estado). Para mais informações, consulte o artigo Grupos de instâncias geridos sem estado ou com estado.
    3. Em Nome, introduza gl4-ilb-miga.
    4. Para Localização, selecione Zona única.
    5. Para Região, selecione REGION_A.
    6. Para Zona, selecione ZONE_A.
    7. Para Modelo de instância, selecione gil4-backendwest1-template.

    8. Especifique o número de instâncias que quer criar no grupo.

      Para este exemplo, especifique as seguintes opções em Ajuste automático de escala:

      • Para o Modo de ajuste automático de escala, selecione Off:do not autoscale.
      • Para Número máximo de instâncias, introduza 2.

      Opcionalmente, na secção Ajuste de escala automático da IU, pode configurar o grupo de instâncias para adicionar ou remover automaticamente instâncias com base na utilização do CPU das instâncias.

    9. Clique em Criar.

    10. Clique em Criar grupo de instâncias.

    11. Selecione Novo grupo de instâncias gerido (sem estado). Para mais informações, consulte o artigo Grupos de instâncias geridos sem estado ou com estado.

    12. Em Nome, introduza gl4-ilb-migb.

    13. Para Localização, selecione Zona única.

    14. Para Região, selecione REGION_B.

    15. Para Zona, selecione ZONE_B.

    16. Para Modelo de instância, selecione gil4-backendeast1-template.

    17. Especifique o número de instâncias que quer criar no grupo.

      Para este exemplo, especifique as seguintes opções em Ajuste automático de escala:

      • Para o Modo de ajuste automático de escala, selecione Off:do not autoscale.
      • Para Número máximo de instâncias, introduza 2.

      Opcionalmente, na secção Ajuste de escala automático da IU, pode configurar o grupo de instâncias para adicionar ou remover automaticamente instâncias com base na utilização do CPU das instâncias.

    18. Clique em Criar.

gcloud

As instruções da CLI gcloud neste guia pressupõem que está a usar o Cloud Shell ou outro ambiente com o bash instalado.

  1. Crie um modelo de instância de VM com um servidor HTTP com o comando gcloud compute instance-templates create.

    gcloud compute instance-templates create gil4-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 gil4-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'

  2. Crie um grupo de instâncias gerido na zona com o comando gcloud compute instance-groups managed create.

    gcloud compute instance-groups managed create gl4-ilb-miga \
    --zone=ZONE_A \
    --size=2 \
    --template=gil4-backendwest1-template

    gcloud compute instance-groups managed create gl4-ilb-migb \
    --zone=ZONE_B \
    --size=2 \
    --template=gil4-backendeast1-template

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":"gil4-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
       }
     ]
  }
}

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

{
  "name":"gil4-backendeast1-template",
  "properties":{
     "machineType":"e2-standard-2",
     "tags":{
       "items":[
         "allow-ssh",
         "load-balanced-backend"
       ]
     },
     "metadata":{
        "kind":"compute#metadata",
        "items":[
          {
            "key":"startup-script",
            "value":"#! /bin/bash\napt-get update\napt-get install
            apache2 -y\na2ensite default-ssl\na2enmod ssl\n
            vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
            \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
            echo \"Page served from: $vm_hostname\" | \\\ntee
            /var/www/html/index.html\nsystemctl restart apache2"
          }
        ]
     },
     "networkInterfaces":[
       {
         "network":"projects/PROJECT_ID/global/networks/NETWORK",
         "subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
         "accessConfigs":[
           {
             "type":"ONE_TO_ONE_NAT"
           }
         ]
       }
     ],
     "disks":[
       {
         "index":0,
         "boot":true,
         "initializeParams":{
           "sourceImage":"projects/debian-cloud/global/images/family/debian-12"
         },
         "autoDelete":true
       }
     ]
  }
}

Crie um grupo de instâncias gerido em cada zona com o método instanceGroupManagers.insert, substituindo PROJECT_ID pelo ID do seu projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-miga",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-miga",
  "targetSize": 2
}

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers

{
  "name": "gl4-ilb-migb",
  "zone": "projects/PROJECT_ID/zones/ZONE_A",
  "instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
  "baseInstanceName": "gl4-ilb-migb",
  "targetSize": 2
}

Configure o balanceador de carga

Este exemplo mostra como criar os seguintes recursos do balanceador de carga de rede de proxy interno entre regiões:

  • Uma verificação de funcionamento TCP global.
  • Um serviço de back-end global com os mesmos MIGs que o back-end.
  • Um proxy de destino global.
  • Duas regras de encaminhamento globais com endereços IP regionais. Para o endereço IP da regra de encaminhamento, use o intervalo de endereços IP SUBNET_A ou SUBNET_B. Se tentar usar a sub-rede apenas de proxy, a criação da regra de encaminhamento falha.

Disponibilidade do proxy

Por vezes, Google Cloud as regiões não têm capacidade de proxy suficiente para um novo balanceador de carga. Se isto acontecer, a Google Cloud consola apresenta uma mensagem de aviso de disponibilidade de proxy quando estiver a criar o equilibrador de carga. Para resolver este problema, pode fazer uma das seguintes ações:

  • Selecione uma região diferente para o balanceador de carga. Esta pode ser uma opção prática se tiver back-ends noutra região.
  • Selecione uma rede de VPC que já tenha uma sub-rede apenas de proxy atribuída.

  • Aguarde pela resolução do problema de capacidade.

Consola

Inicie a configuração

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

    Aceda a 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 Proxy de balanceamento de carga e clique em Seguinte.
  5. Para Público ou interno, selecione Interno e clique em Seguinte.
  6. Para a Implementação em várias regiões ou numa única região, selecione Melhor para cargas de trabalho em várias regiões e clique em Seguinte.
  7. Clique em Configurar.

Configuração básica

  1. Indique um nome para o balanceador de carga.
  2. Para Rede, selecione NETWORK.

Configure o front-end com duas regras de encaminhamento

  1. Clique em Configuração do front-end.
    1. Indique um nome para a regra de encaminhamento.
    2. Na lista Região da sub-rede, selecione REGION_A.

      Reserve uma sub-rede só de proxy

    3. Na lista Sub-rede, selecione SUBNET_A.
    4. Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
      • Indique um nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Permitir-me escolher.
      • No campo Endereço IP personalizado, introduza 10.1.2.99.
      • Selecione Reservar.
  2. Clique em Concluído.
  3. Para adicionar a segunda regra de encaminhamento, clique em Adicionar IP e porta de front-end.
    1. Indique um nome para a regra de encaminhamento.
    2. Na lista Região da sub-rede, selecione REGION_B.

      Reserve uma sub-rede só de proxy

    3. Na lista Sub-rede, selecione SUBNET_B.
    4. Na lista Endereço IP, clique em Criar endereço IP. É apresentada a página Reserve um endereço IP interno estático.
      • Indique um nome para o endereço IP estático.
      • Na lista Endereço IP estático, selecione Permitir-me escolher.
      • No campo Endereço IP personalizado, introduza 10.1.3.99.
      • Selecione Reservar.
  4. Clique em Concluído.
Configure o serviço de back-end
  1. Clique em Configuração de back-end.
  2. Na lista Criar ou selecionar serviços de back-end, clique em Criar um serviço de back-end.
  3. Indique um nome para o serviço de back-end.
  4. Em Protocolo, selecione TCP.
  5. Em Porta com nome, introduza http.
  6. Na lista Tipo de back-end, selecione Grupo de instâncias.
  7. Na lista Verificação de funcionamento, clique em Criar uma verificação de funcionamento e, de seguida, introduza as seguintes informações:
    • No campo Nome, introduza global-http-health-check.
    • Na lista Protocolo, selecione HTTP.
    • No campo Porta, introduza 80.
    • Clique em Criar.
  8. Na secção Novo back-end:
    1. Na lista Grupo de instâncias, selecione gl4-ilb-miga em REGION_A.
    2. Defina Transferir números como 80.
    3. Para o Modo equilibrado, selecione Connection.
    4. Clique em Concluído.
    5. Para adicionar outro back-end, clique em Adicionar back-end.
    6. Na lista Grupo de instâncias, selecione gl4-ilb-migb em REGION_B.
    7. Defina Transferir números como 80.
    8. Clique em Concluído.

Reveja a configuração

  1. Clique em Rever e finalizar.
  2. Reveja as definições de configuração do equilibrador de carga.
  3. Clique em Criar.

gcloud

  1. Defina a verificação de funcionamento TCP com o comando gcloud compute health-checks create tcp.

    gcloud compute health-checks create tcp global-health-check \
   --use-serving-port \
   --global

  2. Defina o serviço de back-end com o comando gcloud compute backend-services create.

    gcloud compute backend-services create gl4-gilb-backend-service \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=TCP \
  --enable-logging \
  --logging-sample-rate=1.0 \
  --health-checks=global-health-check \
  --global-health-checks \
  --global

  3. Adicione back-ends ao serviço de back-end com o comando gcloud compute backend-services add-backend.

    gcloud compute backend-services add-backend gl4-gilb-backend-service \
  --balancing-mode=CONNECTION \
  --max-connections=50 \
  --instance-group=gl4-ilb-miga \
  --instance-group-zone=ZONE_A \
  --global

    gcloud compute backend-services add-backend gl4-gilb-backend-service \
  --balancing-mode=CONNECTION \
  --max-connections=50 \
  --instance-group=gl4-ilb-migb \
  --instance-group-zone=ZONE_B \
  --global

  4. Crie o proxy de destino.

    Crie o proxy de destino com o comando gcloud compute target-tcp-proxies create.

    gcloud compute target-tcp-proxies create gilb-tcp-proxy \
  --backend-service=gl4-gilb-backend-service \
  --global

  5. Crie duas regras de encaminhamento, uma com um VIP (10.1.2.99) em REGION_B e outra com um VIP (10.1.3.99) em REGION_A. Para mais informações, consulte o artigo Reserve um endereço IPv4 interno estático.

    Para redes personalizadas, tem de fazer referência à sub-rede na regra de encaminhamento. Tenha em atenção que esta é a sub-rede da VM e não a sub-rede do proxy.

    Use o comando gcloud compute forwarding-rules create com as flags corretas.

    gcloud compute forwarding-rules create gil4forwarding-rule-a \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_A \
  --subnet-region=REGION_A \
  --address=10.1.2.99 \
  --ports=80 \
  --target-tcp-proxy=gilb-tcp-proxy \
  --global

    gcloud compute forwarding-rules create gil4forwarding-rule-b \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=NETWORK \
  --subnet=SUBNET_B \
  --subnet-region=REGION_B \
  --address=10.1.3.99 \
  --ports=80 \
  --target-tcp-proxy=gilb-tcp-proxy \
  --global

API

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

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

{
"name": "global-health-check",
"type": "TCP",
"httpHealthCheck": {
  "portSpecification": "USE_SERVING_PORT"
}
}

Crie o serviço de back-end global fazendo um pedido POST ao método backendServices.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
"name": "gl4-gilb-backend-service",
"backends": [
  {
    "group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl4-ilb-miga",
    "balancingMode": "CONNECTION"
  },
  {
    "group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl4-ilb-migb",
    "balancingMode": "CONNECTION"
  }
],
"healthChecks": [
  "projects/PROJECT_ID/regions/global/healthChecks/global-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}

Crie o proxy TCP de destino fazendo um pedido POST ao método targetTcpProxies.insert, substituindo PROJECT_ID pelo ID do seu projeto.

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

{
"name": "l4-ilb-proxy",
}

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

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

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-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": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

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

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

{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-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": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}

Teste o balanceador de carga

Crie uma instância de VM para testar a conetividade

  1. Crie uma VM de cliente nas regiões REGION_B e REGION_A:

    gcloud compute instances create l4-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 l4-ilb-client-b \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --network=NETWORK \
    --subnet=SUBNET_B \
    --zone=ZONE_B \
    --tags=allow-ssh

  2. Use o SSH para estabelecer ligação a cada instância do cliente.

    gcloud compute ssh l4-ilb-client-a --zone=ZONE_A

    gcloud compute ssh l4-ilb-client-b --zone=ZONE_B

  3. Verifique se o endereço IP está a publicar o respetivo nome do anfitrião

    • Confirme se a VM do cliente consegue alcançar ambos os endereços IP. O comando deve ser bem-sucedido e devolver o nome da VM de back-end que processou o pedido:

      curl 10.1.2.99

      curl 10.1.3.99

Teste de comutação por falha

  1. Valide a comutação por falha para back-ends na região REGION_A quando os back-ends na região REGION_B estão em mau estado ou inacessíveis. Para simular a comutação por falha, remova todos os back-ends de REGION_B:

    gcloud compute backend-services remove-backend gl4-gilb-backend-service \
  --instance-group=gl4-ilb-migb \
  --instance-group-zone=ZONE_B \
  --global

  2. Ligue-se através de SSH a uma VM cliente em REGION_B.

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

  3. Envie pedidos para o endereço IP com balanceamento de carga na região REGION_B. O resultado do comando mostra as respostas das VMs de back-end em REGION_A:

    {
RESULTS=
for i in {1..100}
do
  RESULTS="$RESULTS:$(curl 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
}

Opções de configuração adicionais

Esta secção expande o exemplo de configuração para oferecer opções de configuração alternativas e adicionais. Todas as tarefas são opcionais. Pode realizá-las por qualquer ordem.

Protocolo PROXY para reter informações de ligação do cliente

O Network Load Balancer do proxy interno termina as ligações TCP do cliente e cria novas ligações às instâncias de VM. Por predefinição, as informações de porta e IP do cliente original não são preservadas.

Para preservar e enviar as informações de ligação originais para as suas instâncias, ative o protocolo PROXY (versão 1). Este protocolo envia um cabeçalho adicional que contém o endereço IP de origem, o endereço IP de destino e os números das portas para a instância como parte do pedido.

Certifique-se de que as instâncias de back-end do balanceador de carga de rede do proxy interno estão a executar servidores HTTP ou HTTPS que suportam cabeçalhos do protocolo PROXY. Se os servidores HTTP ou HTTPS não estiverem configurados para suportar cabeçalhos do protocolo PROXY, as instâncias de back-end devolvem respostas vazias. Por exemplo, o protocolo PROXY não funciona com o software do servidor HTTP Apache. Pode usar software de servidor Web diferente, como o Nginx.

Se definir o protocolo PROXY para o tráfego de utilizadores, também o tem de definir para as verificações de funcionamento. Se estiver a verificar o estado de funcionamento e a publicar conteúdo na mesma porta, defina o --proxy-header da verificação de funcionamento de modo a corresponder à definição do balanceador de carga.

Normalmente, o cabeçalho do protocolo PROXY é uma única linha de texto legível pelo utilizador no seguinte formato:

PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n

Segue-se um exemplo do protocolo PROXY:

PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n

No exemplo anterior, o IP do cliente é 192.0.2.1, o IP de equilíbrio de carga é 198.51.100.1, a porta do cliente é 15221 e a porta de destino é 110.

Nos casos em que o IP do cliente não é conhecido, o balanceador de carga gera um cabeçalho do protocolo PROXY no seguinte formato:

PROXY UNKNOWN\r\n

Atualize o cabeçalho do protocolo PROXY para o proxy TCP de destino

A configuração de exemplo do balanceador de carga nesta página mostra como ativar o cabeçalho do protocolo PROXY ao criar o balanceador de carga de rede do proxy interno. Use estes passos para alterar o cabeçalho do protocolo PROXY para um proxy TCP de destino existente.

Consola

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

    Aceda a Balanceamento de carga

  2. Clique em Editar para o equilibrador de carga.

  3. Clique em Configuração do front-end.

  4. Altere o valor do campo Protocolo proxy para Ativado.

  5. Clique em Atualizar para guardar as alterações.

gcloud

No comando seguinte, edite o campo --proxy-header e defina-o como NONE ou PROXY_V1, consoante o seu requisito.

gcloud compute target-ssl-proxies update int-tcp-target-proxy \
    --proxy-header=[NONE | PROXY_V1]

Use o mesmo endereço IP entre várias regras de encaminhamento interno

Para que várias regras de encaminhamento interno partilhem o mesmo endereço IP interno, tem de reservar o endereço IP e definir a respetiva flag --purpose como SHARED_LOADBALANCER_VIP.

gcloud 

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

Ative a afinidade de sessão

A configuração de exemplo cria um serviço de back-end sem afinidade de sessão.

Estes procedimentos mostram como atualizar um serviço de back-end para um exemplo de equilibrador de carga, de modo que o serviço de back-end use a afinidade de IP do cliente ou a afinidade de cookies gerados.

Quando a afinidade de IP do cliente está ativada, o balanceador de carga direciona os pedidos de um cliente específico para a mesma VM de back-end com base num hash criado a partir do endereço IP do cliente e do endereço IP do balanceador de carga (o endereço IP interno de uma regra de encaminhamento interno).

Consola

Para ativar a afinidade de sessão de IP do cliente:

  1. Na Google Cloud consola, aceda à página Equilíbrio de carga.
    Aceda a Balanceamento de carga
  2. Clique em Back-ends.
  3. Clique no nome do serviço de back-end que criou para este exemplo e clique em Editar.
  4. Na página Detalhes do serviço de back-end, clique em Configuração avançada.
  5. Em Afinidade de sessão, selecione IP do cliente no menu.
  6. Clique em Atualizar.

gcloud

Use o seguinte comando gcloud para atualizar o serviço de back-end, especificando a afinidade da sessão do IP do cliente:BACKEND_SERVICE

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --session-affinity=CLIENT_IP

Ative a drenagem de ligações

Pode ativar a drenagem de ligações nos serviços de back-end para garantir uma interrupção mínima para os seus utilizadores quando uma instância que está a servir tráfego é terminada, removida manualmente ou removida por um escalador automático. Para saber mais sobre a drenagem de ligações, leia a documentação Ativar a drenagem de ligações.

O que se segue?