Como configurar o balanceamento de carga TCP/UDP interno

Neste guia, usamos um exemplo para ensinar os princípios básicos do balanceamento de carga TCP/UDP interno do Google Cloud Platform. Antes de seguir as instruções deste guia, familiarize-se com os itens abaixo:

Permissões

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

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

Configuração

Neste guia, mostramos como configurar e testar um balanceador de carga TCP/UDP interno. Nas etapas desta seção, veja como configurar o seguinte:

  1. um exemplo de rede VPC com sub-redes personalizadas
  2. regras de firewall que permitem conexões de entrada para VMs de back-end
  3. quatro VMs de back-end:
    • duas VMs em um grupo de instâncias não gerenciadas na zona us-west1-a
    • duas VMs em um grupo de instâncias não gerenciadas na zona us-west1-c
  4. uma VM cliente para testar conexões
  5. os seguintes componentes do balanceador de carga TCP/UDP interno:
    • uma verificação de integridade do serviço de back-end
    • um serviço de back-end interno na região us-west1 para gerenciar a distribuição de conexões para os dois grupos de instâncias zonais
    • uma regra de encaminhamento interna e um endereço IP interno para o front-end do balanceador de carga

A arquitetura deste exemplo é assim:

Configuração de exemplo de balanceamento de carga TCP/UDP interno (clique para ampliar)
Configuração de exemplo de balanceamento de carga TCP/UDP interno (clique para ampliar)

Como configurar rede, região e sub-rede

Você precisa de uma rede VPC com pelo menos uma sub-rede. Um balanceador de carga TCP/UDP interno é regional. O tráfego na rede VPC será roteado para o balanceador de carga se for originário de uma sub-rede na mesma região do balanceador de carga.

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

  • Rede: uma rede VPC de modo personalizado denominada lb-network.

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

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

Para criar o exemplo de rede e sub-rede, siga estas etapas.

Console

  1. Acesse a página "Redes VPC" no Console do Google Cloud Platform.
    Acessar a página "Redes VPC"
  2. Clique em Criar rede VPC.
  3. Informe um Nome de lb-network.
  4. Na seção Sub-redes:
    • Defina o Modo de criação de sub-rede como Personalizado.
    • Na seção Nova sub-rede, insira as informações a seguir:
      • 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, 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 uma solicitação POST ao método networks.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks
{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

Faça uma solicitação POST ao método subnetworks.insert.

POST https://www.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
}

Como configurar regras de firewall

Neste exemplo, usamos as seguintes regras de firewall:

  • fw-allow-lb-subnet: uma regra de entrada, aplicável a todos os destinos na rede VPC, permitindo tráfego de origens no intervalo 10.1.2.0/24. Essa regra permite tráfego de entrada de qualquer origem em lb-subnet para as instâncias (VMs) submetidas a balanceamento de carga.

  • fw-allow-ssh: uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite a conectividade SSH de entrada na porta TCP 22 proveniente de qualquer endereço. É possível escolher um intervalo de IP de origem mais restritivo para essa regra, por exemplo, especificando apenas os intervalos de IP do sistema que iniciará as sessões SSH. Neste exemplo, usamos a tag allow-ssh de destino para identificar as VMs a que isso se aplicará.

  • fw-allow-health-check: uma regra de entrada, aplicável às instâncias submetidas a balanceamento de carga, que permite tráfego dos sistemas de verificação de integridade do GCP (130.211.0.0/22 e 35.191.0.0/16). Neste exemplo, usamos a tag de destino allow-health-check para identificar as instâncias a que isso se aplicará.

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

Console

  1. Acesse a página "Regras de firewall" no Console do Google Cloud Platform.
    Acessar a página "Regras de firewall"
  2. Clique em Criar regra de firewall e insira 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 quando há correspondência: permitir
    • Destinos: todas as instâncias na rede
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 10.1.2.0/24
    • Protocolos e portas: permitir todos
  3. Clique em Criar.
  4. Clique em Criar regra de firewall novamente para criar a regra que permite conexões SSH de entrada:
    • Nome: fw-allow-ssh
    • Rede: lb-network
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação quando há correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de destino: allow-ssh
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 0.0.0.0/0
    • Protocolos e portas: escolha Protocolos e portas especificados e digite: tcp:22
  5. Clique em Criar.
  6. Clique em Criar regra de firewall pela terceira vez para criar a regra que permite verificações de integridade do GCP:
    • Nome: fw-allow-health-check
    • Rede: lb-network
    • Prioridade: 1000
    • Direção do tráfego: entrada
    • Ação quando há correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de destino: allow-health-check
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolos e portas: permitir todos
  7. Clique em Criar.

gcloud

  1. Crie a regra de firewall fw-allow-lb-subnet para permitir a comunicação a partir da 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 que permita a conectividade SSH para VMs com a tag de rede allow-ssh. Quando você omite source-ranges, o GCP interpreta a regra como sendo 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 verificações de integridade do GCP.

    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 uma solicitação POST ao método firewalls.insert.

POST https://www.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 uma solicitação POST ao método firewalls.insert.

POST https://www.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 uma solicitação POST ao método firewalls.insert.

POST https://www.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
}

Como criar VMs de back-end e grupos de instâncias

Neste exemplo, usamos dois grupos de instâncias não gerenciadas, cada um com duas VMs de back-end (servidor). Para demonstrar a natureza regional do balanceamento de carga TCP/UDP interno, os dois grupos de instâncias são colocados em zonas separadas, us-west1-a e us-west1-c.

  • O grupo de instâncias ig-a contém estas duas VMs:
    • vm-a1
    • vm-a2
  • O grupo de instâncias ig-c contém estas duas VMs:
    • vm-c1
    • vm-c2

O tráfego para as quatro VMs de back-end é submetido a balanceamento de carga. Cada uma delas executa um servidor da Web Apache nas portas TCP 80 e 443. Cada uma recebe um endereço IP interno na lb-subnet e um endereço IP externo (público) temporário. É possível remover os endereços IP externos posteriormente.

Embora não sejam obrigatórios, os endereços IP externos das VMs de back-end são úteis neste exemplo por permitirem que elas façam o download do Apache da internet, além de facilitarem a conexão por SSH.

Por padrão, o Apache é configurado para ser vinculado a qualquer endereço IP. Os balanceadores de carga TCP/UDP internos preservam o IP de destino para entregar pacotes. Verifique se o software servidor executado nas suas VMs de back-end está escutando no endereço IP da regra de firewall interna do balanceador de carga. Se você configurar várias regras de encaminhamento internas, verifique se o software escuta o endereço IP interno associado a cada uma delas. O endereço IP interno da regra de encaminhamento é o endereço IP de destino de um pacote entregue a uma VM de back-end por um balanceador de carga TCP/UDP interno.

Para simplificar a instrução, essas VMs de back-end executam o Debian GNU/Linux 9.

Console

Criar VMs de back-end

  1. Acesse a página "Instâncias de VMs" no Console do Google Cloud Platform.
    Acessar a página "Instâncias de VMs"
  2. Repita as etapas a seguir para criar quatro VMs usando estas combinações de nome e zona.
    • 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 como indicado na etapa 2.
  5. Em Região, escolha us-west1 e escolha uma Zona, como indicado na etapa 2.
  6. Na seção Disco de inicialização, verifique se a imagem selecionada é Debian GNU/Linux 9 (extensão). Clique em Escolher para alterar a imagem, se necessário.
  7. Clique em Gerenciamento, segurança, discos, rede, locatário individual e faça as alterações a seguir:

    • Clique em Rede e adicione as seguintes tags de rede: allow-ssh e allow-health-check.
    • Clique no botão de editar em Interfaces de rede e faça as alterações a seguir. Depois, clique em Concluído:
      • Rede: lb-network
      • Sub-rede: lb-subnet
      • IP interno primário: temporário (automático)
      • IP externo: temporário
    • Clique em Gerenciamento. No campo Script de inicialização, copie e cole o conteúdo do script a seguir, que é o mesmo para 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://169.254.169.254/computeMetadata/v1/instance/name)"
      echo "Page served from: $vm_hostname" | \
      tee /var/www/html/index.html
      systemctl restart apache2
      
  8. Clique em Criar.

Criar grupos de instâncias

  1. Acesse a página "Grupos de instâncias" no Console do Google Cloud Platform.
    Acessar a página "Grupos de instâncias"
  2. Repita as etapas a seguir, usando estas combinações, para criar dois grupos de instâncias não gerenciadas com duas VMs cada.
    • 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. Defina o Nome como indicado na etapa 2.
  5. Na seção Local, selecione Única zona, defina us-west1 como Região e escolha uma Zona, como indicado na etapa 2.
  6. Na seção Tipo de grupo, selecione Grupo de instâncias não gerenciadas.
  7. Em Rede, insira lb-network.
  8. Em Sub-rede, insira lb-subnet.
  9. Na seção Instâncias de VMs, adicione as VMs como indicado na etapa 2.
  10. Clique em Criar.

gcloud

  1. Execute o seguinte comando quatro vezes para criar as quatro VMs, usando estas quatro combinações para [VM-NAME] e [ZONE]. O conteúdo de script é o mesmo para 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-9 \
        --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://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 os dois grupos de instâncias não gerenciadas 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 apropriados:

    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

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

  • [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

Crie quatro VMs de back-end fazendo quatro solicitações POST ao método instances.insert:

POST https://www.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/n1-standard-1",
  "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-9-stretch-v20190618",
        "diskType": "projects/[PROJECT_ID]/zones/us-west1-a/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://169.254.169.254/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 uma solicitação POST ao método instanceGroups.insert.

POST https://www.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://www.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 uma solicitação POST para o método instanceGroups.addInstances.

POST https://www.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://www.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"
    }
  ]
}

Como criar uma VM cliente

Neste exemplo, criamos uma VM cliente (vm-client) na mesma região das VMs de back-end (servidor). O cliente é usado para validar a configuração do balanceador de carga e demonstrar o comportamento esperado, conforme descrito na seção de teste.

Console

  1. Acesse a página "Instâncias de VMs" no Console do Google Cloud Platform.
    Acessar a página "Instâncias de VMs"
  2. Clique em Criar instância.
  3. Defina o Nome como vm-client.
  4. Defina a Zona como us-west1-a.
  5. Clique em Gerenciamento, segurança, discos, rede, locatário individual e faça as alterações a seguir:
    • Clique em Rede e adicione allow-ssh a Tags de rede.
    • Clique no botão de editar em Interfaces de rede e faça as alterações a seguir. Depois, clique em Concluído:
      • Rede: lb-network
      • Sub-rede: lb-subnet
      • IP interno primário: temporário (automático)
      • IP externo: temporário
  6. Clique em Criar.

gcloud

A VM cliente pode estar em qualquer zona na mesma região que o balanceador de carga, podendo usar qualquer sub-rede nessa região. Neste exemplo, o cliente está na zona us-west1-a e usa a mesma sub-rede das VMs de back-end.

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

api

Faça uma solicitação POST ao método instances.insert.

POST https://www.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/n1-standard-1",
  "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-9-stretch-v20190618",
        "diskType": "projects/[PROJECT_ID]/zones/us-west1-a/diskTypes/pd-standard",
        "diskSizeGb": "10"
      }
    }
  ]
  "scheduling": {
    "preemptible": false
  },
  "deletionProtection": false
}

Como configurar componentes do balanceador de carga

Estas etapas configuram todos os componentes do balanceador de carga TCP/UDP interno, começando com verificação de integridade e serviço de back-end e, em seguida, componentes de front-end:

  • Verificação de integridade: neste exemplo, usamos uma verificação de integridade HTTP que apenas verifica se há uma resposta HTTP 200 (OK). Para mais informações, consulte a seção sobre verificações de integridade da visão geral do balanceamento de carga TCP/UDP interno.

  • Serviço de back-end: devido à necessidade de passar tráfego HTTP através do balanceador de carga interno, precisamos usar TCP em vez de UDP.

  • Regra de encaminhamento: neste exemplo, criamos uma única regra de encaminhamento interna.

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

Console

Criar o balanceador de carga e configurar um serviço de back-end

  1. Acesse a página "Balanceamento de carga" no Console do Google Cloud Platform.
    Acessar a página "Balanceamento de carga"
  2. Clique em Criar balanceador de carga.
  3. Em Balanceamento de carga TCP, clique em Iniciar configuração.
  4. Em Somente voltado para a Internet ou interno, selecione Apenas entre minhas VMs.
  5. Clique em Continuar.
  6. Defina o Nome como be-ilb.
  7. Clique em Configuração de back-end e faça as alterações a seguir:
    1. Região: us-west1
    2. Rede: lb-network
    3. Em Back-ends, na seção Novo item, selecione o grupo de instâncias ig-a e clique em Concluído.
    4. Clique em Adicionar back-end. Na seção Novo item exibida, selecione o grupo de instâncias ig-c e clique em Concluído novamente.
    5. Em Verificação de integridade, escolha Criar outra verificação de integridade, insira as informações a seguir e clique em Salvar e continuar:
      • Nome: hc-http-80
      • Protocolo: HTTP
      • Porta: 80
      • Protocolo de proxy: NONE
      • Solicitar caminho: /
    6. Verifique se há uma marca de seleção azul ao lado de Configuração de back-end antes de continuar. Revise esta etapa, se não houver a marca.
  8. Clique em Configuração de front-end. Na seção Novo IP de front-end e porta, faça as seguintes alterações:
    1. Nome: fr-ilb
    2. Sub-rede: ilb-subnet
    3. Em IP interno, escolha Reservar um endereço IP interno estático, insira as informações a seguir e clique em Reservar:
      • Nome: ip-ilb
      • Endereço IP estático: Quero escolher
      • Endereço IP personalizado: 10.1.2.99
    4. Portas: escolha Individual e insira 80 no Número da porta.
    5. Verifique se há uma marca de seleção azul ao lado da Configuração de front-end antes de continuar. Revise esta etapa, se não houver a marca.
  9. Clique em Revisar e finalizar. Verifique suas configurações.
  10. Clique em Criar.

gcloud

  1. Crie uma nova verificação de integridade HTTP para testar a conectividade TCP com as VMs na porta 80.

    gcloud compute health-checks create http hc-http-80 \
        --port=80
    
  2. Crie o serviço de back-end do tráfego HTTP:

    gcloud compute backend-services create be-ilb \
        --load-balancing-scheme=internal \
        --protocol=tcp \
        --region=us-west1 \
        --health-checks=hc-http-80
    
  3. Adicione os dois grupos de instâncias 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
    gcloud compute backend-services add-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-c \
        --instance-group-zone=us-west1-c
    
  4. Crie uma regra de encaminhamento do serviço de back-end. Ao fazer isso, especifique 10.1.2.99 como 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 integridade fazendo uma solicitação POST ao método healthChecks.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks
{
  "name": "hc-http-80",
  "type": "HTTP",
  "httpHealthCheck": {
    "port": 80
  }
}

Crie um serviço de back-end regional fazendo uma solicitação POST ao método regionBackendServices.insert.

POST https://www.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"
    }
  ],
  "healthChecks": [
    "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/hc-http-80"
  ],
  "loadBalancingScheme": "INTERNAL",
  "connectionDraining": {
    "drainingTimeoutSec": 0
  }
}

Crie a regra de firewall fazendo uma solicitação POST ao método forwardingRules.insert.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/forwardingRules
{
  "name": "fr-ilb",
  "IPAddress": "10.1.2.99",
  "IPProtocol": "TCP",
  "ports": [
    "80"
  ],
  "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"
}

Teste

Nos testes a seguir, veja como validar a configuração do balanceador de carga e conheça o comportamento esperado dele.

Como testar o balanceamento de carga

Neste teste, o balanceador de carga é contatado por uma VM cliente separada, e não por uma VM de back-end do balanceador de carga. O comportamento esperado é que o tráfego seja distribuído entre as quatro VMs de back-end porque nenhuma afinidade de sessão foi configurada.

  1. Conecte-se à instância da VM cliente.

    gcloud compute ssh vm-client --zone=us-west1-a
    
  2. Faça uma solicitação da Web para o balanceador de carga usando curl para contatar o endereço IP dele. Repita a solicitação para ver que as respostas provêm de diferentes VMs de back-end. O nome da VM que gera a resposta é exibido no texto na resposta HTML, em virtude do conteúdo de /var/www/html/index.html em cada VM de back-end. As respostas esperadas são assim: Page served from: vm-a1, Page served from: vm-a2 e assim por diante.

    curl http://10.1.2.99
    
    • Se você adicionar um rótulo de serviço à regra de encaminhamento interno, poderá usar DNS interno para contatar o balanceador de carga usando o nome de serviço.

      curl http://web-test.fr-ilb.il4.us-west1.lb.[PROJECT_ID].internal
      

Como dar um ping no endereço IP do balanceador de carga

Neste teste, demonstramos um comportamento esperado: não é possível dar um ping no endereço IP do balanceador de carga. Isso ocorre porque os balanceadores de carga TCP/UDP internos são implementados na programação de rede virtual, eles não são dispositivos separados.

  1. Conecte-se à instância da VM cliente.

    gcloud compute ssh vm-client --zone=us-west1-a
    
  2. Tente fazer o ping do endereço IP do balanceador de carga. Observe que você não recebe uma resposta e o comando ping expira após 10 segundos neste exemplo.

    timeout 10 ping 10.1.2.99
    

Como enviar solicitações a partir de VMs submetidas a balanceamento de carga

Neste teste, demonstramos que as solicitações ao balanceador de carga originadas de qualquer VM de back-end (as VMs de servidor submetidas a balanceamento de carga) são sempre respondidas pela mesma VM que faz a solicitação.

O balanceamento de carga TCP/UDP interno é implementado por meio de programação de rede virtual e configuração de VM no SO convidado. Em VMs do Linux, o ambiente de convidado Linux realiza a configuração local instalando uma rota na tabela de roteamento do SO convidado. Por causa dessa rota local, o tráfego para o endereço IP do balanceador de carga permanece na VM submetida a balanceamento de carga. Esta rota local é diferente das rotas na rede VPC.

  1. Conecte-se a uma VM de back-end, como vm-a1:

    gcloud compute ssh vm-a1 --zone=us-west1-a
    
  2. Faça uma solicitação da Web para o balanceador de carga (por endereço IP ou nome de serviço) usando curl. Repita a solicitação e observe que a resposta é enviada pela VM de back-end que faz a solicitação. A resposta esperada quando se faz o teste a partir de vm-a1 é sempre: Page served from: vm-a1.

    curl http://10.1.2.99
    
  3. Inspecione a tabela de roteamento local, procurando um destino que corresponda ao endereço IP do próprio balanceador de carga, 10.1.2.99. Essa rota é uma parte necessária do balanceamento de carga TCP/UDP interno, mas também demonstra porque uma solicitação de uma VM por trás do balanceador de carga sempre é respondida pela mesma VM.

    ip route show table local | grep 10.1.2.99
    

Outras opções de configuração

Nesta seção, expandimos o exemplo de configuração fornecendo opções de configuração alternativas. Todas as tarefas são opcionais. É possível realizá-las em qualquer ordem.

Como configurar grupos de instâncias gerenciadas

Com a configuração de exemplo, foram criados dois grupos de instâncias não gerenciadas. Porém, é possível usar grupos de instâncias gerenciadas, incluindo grupos de instâncias gerenciadas zonais e regionais, como back-ends para balanceamento de carga TCP/UDP interno.

Os grupos de instâncias gerenciadas exigem que você crie um modelo de instância. Neste procedimento, demonstramos como substituir os dois grupos de instâncias não gerenciadas zonais do exemplo por um único grupo de instâncias gerenciadas regionais. Um grupo de instâncias gerenciadas regionais cria automaticamente VMs em várias zonas da região, simplificando a distribuição do tráfego de produção entre as zonas.

Os grupos de instâncias gerenciadas também são compatíveis com autoescalonamento e recuperação automática. Se você usar autoescalonamento com balanceamento de carga TCP/UDP interno, não poderá escalonar de acordo com o balanceamento de carga.

Neste procedimento, mostramos como modificar o serviço de back-end do balanceador de carga TCP/UDP interno de exemplo para que ele use um grupo de instâncias gerenciadas regionais.

Console

Modelo de instância

  1. Acesse a página "Modelos de instância" de VM no Console do Google Cloud Platform.
    Acessar a página "Modelos de instância" de VM
  2. Clique em Criar modelo de instância.
  3. Defina o Nome como template-vm-ilb.
  4. Escolha um tipo de máquina.
  5. Em Disco de inicialização, clique em Alterar, escolha Debian GNU/Linux 9 (extensão) e clique em Selecionar.
  6. Clique em Gerenciamento, segurança, discos, rede, locatário único.
    • Clique em Rede e faça as seguintes alterações:
      • Rede: lb-network
      • Sub-rede: lb-subnet
      • Tags de rede: allow-ssh e allow-health-check
    • Clique em Gerenciamento. No campo Script de inicialização, copie e cole o conteúdo do script a seguir:
      #! /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.

Grupo de instâncias gerenciadas

  1. Acesse a página "Grupos de instâncias de VMs" no Console do Google Cloud Platform.
    Acessar a página "Grupos de instâncias" de VM
  2. Clique em Criar grupo de instâncias.
  3. Defina o Nome como ig-ilb.
  4. Em Local, escolha Várias zonas e defina a Região como us-west1.
  5. Defina o Modelo de instância como template-vm-ilb.
  6. (Opcional) Configure escalonamento automático. Não é possível fazer escalonamento automático no grupo de instâncias com base no uso do balanceamento de carga HTTP porque o grupo de instâncias é um back-end de balanceamento de carga TCP/UDP interno.
  7. Defina o Número mínimo de instâncias como 1 e o Número máximo de instâncias como 6.
  8. (Opcional) Configure a recuperação automática. Se você configurar a recuperação automática, use a mesma verificação de integridade usada pelo serviço de back-end para o balanceador de carga TCP/UDP interno. Neste exemplo, use hc-http-80.
  9. Clique em Criar.

gcloud

  1. Crie o modelo da instância. Opcionalmente, defina outros parâmetros, como tipo de máquina, para o modelo de imagem a usar.

    gcloud compute instance-templates create template-vm-ilb \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh,allow-health-check \
        --subnet=lb-subnet \
        --region=us-west1 \
        --network=lb-network \
        --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ânciasgerenciadas regionais usando o modelo:

    gcloud compute instance-groups managed create ig-ilb \
        --template=template-vm-ilb \
        --region=us-west1 \
        --size=6
    
  3. Adicione o grupo de instânciasgerenciadas regionais como back-end para o serviço de back-end que você já criou:

    gcloud compute backend-services add-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-ilb \
        --instance-group-region=us-west1
    
  4. Desconecte os dois grupos de instâncias não gerenciadas (zonais) do serviço de back-end:

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

Como remover endereços IP externos de VMs de back-end

Quando você criou as VMs de back-end, a cada uma foi atribuído um endereço IP externo temporário para possibilitar o download do Apache por meio de um script de inicialização. Como as VMs de back-end só são usadas por um balanceador de carga interno, é possível remover os endereços IP externos. A remoção de endereços IP externos impede que as VMs de back-end acessem a Internet diretamente.

Console

  1. Acesse a página "Instâncias de VMs" no Console do Google Cloud Platform.
    Acessar a página "Instâncias de VMs"
  2. Repita as etapas a seguir para cada VM de back-end.
  3. Clique no nome da VM de back-end (por exemplo, vm-a1) para visualizar a página Detalhes da instância de VM.
  4. Clique em Editar.
  5. Na seção Interfaces de rede, clique no botão Editar.
  6. No pop-up IP externo, escolha Nenhum e clique em Concluído.
  7. Clique em Salvar.

gcloud

  1. Para procurar a zona de uma instância, por exemplo, se estiver usando um grupo de instâncias gerenciadas regionais, execute o seguinte comando para cada instância determinar sua zona. Substitua [SERVER-VM] pelo nome da VM a ser pesquisada.

    gcloud compute instances list --filter="name=[SERVER-VM]"
    
  2. Repita a etapa a seguir para cada VM de back-end. Substitua [SERVER-VM] pelo nome da VM e [ZONE] pela zona da VM.

    gcloud compute instances delete-access-config [SERVER-VM] \
        --zone=[ZONE] \
        --access-config-name=external-nat
    

api

Faça uma solicitação POST ao método instances.deleteAccessConfig para cada VM de back-end, substituindo vm-a1 pelo nome da VM e us-west1-a pela zona da VM.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/v1-a1/deleteAccessConfig?accessConfig=external-nat&networkInterface=None

Como aceitar tráfego em várias portas

O componente que controla a porta do tráfego de entrada é a regra de encaminhamento interna. Neste procedimento, veja como substituir a regra de encaminhamento da porta 80 por uma que aceite tráfego nas portas 80 e 443. Quando você cria as VMs de back-end, o script de inicialização que instala e configura o Apache também o configura para veicular tráfego HTTPS na porta 443. É preciso substituir uma regra de encaminhamento porque o GCP não aceita a atualização de regras de encaminhamento.

gcloud

  1. Exclua a regra de encaminhamento atual, fr-ilb.

    gcloud compute forwarding-rules delete fr-ilb \
        --region=us-west1
    
  2. Crie uma regra de encaminhamento de substituição com o mesmo nome para as portas 80 e 443. Os outros parâmetros dessa regra, incluindo o endereço IP e o serviço de back-end, são os mesmos.

    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,443 \
        --backend-service=be-ilb \
        --backend-service-region=us-west1
    
  3. Conecte-se à instância de VM de cliente e teste as conexões HTTP e HTTPS.

    • Conecte-se à VM do cliente:

      gcloud compute ssh vm-client --zone=us-west1-a
      
    • Teste a conectividade HTTP:

      curl http://10.1.2.99
      
    • Teste a conectividade HTTPS. A sinalização --insecure é necessária porque a configuração do servidor Apache, na configuração de exemplo, usa certificados autoassinados.

      curl https://10.1.2.99 --insecure
      
    • Observe que as solicitações HTTP (na porta 80) e as solicitações HTTPS (na porta 443) são manipuladas por todas as VMs de back-end.

Como usar a afinidade de sessão

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

Neste procedimento, mostramos como atualizar o serviço de back-end para o balanceador de carga TCP/UDP interno de exemplo de modo que ele use a afinidade de sessão com base nos endereços IP de cliente.

O balanceador de carga direciona as solicitações de um cliente específico para a mesma VM de back-end com base em um 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 interna).

Console

  1. Acesse a página "Balanceamento de carga" no Console do Google Cloud Platform.
    Acessar a página "Balanceamento de carga"
  2. Clique em be-ilb (nome do serviço de back-end que você criou para este exemplo) e clique em Editar.
  3. Na página Editar balanceador de carga interno, clique em Configuração de back-end.
  4. Selecione IP do cliente no menu pop-up Sessão de afinidade.
  5. Clique em Atualizar.

gcloud

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

gcloud compute backend-services update be-ilb \
    --session-affinity CLIENT_IP

api

Faça uma solicitação PATCH ao método regionBackendServices/patch.

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/be-ilb
{
  "sessionAffinity": "CLIENT_IP"
}

Para mais informações sobre o uso da afinidade da sessão para influenciar a distribuição de tráfego e uma descrição de cada opção, consulte Distribuição de tráfego.

Como criar uma regra de encaminhamento em outra sub-rede

Neste procedimento, criamos um segundo endereço IP e regra de encaminhamento em outra sub-rede para demonstrar que é possível criar várias regras de encaminhamento para um balanceador de carga TCP/UDP interno. A região da regra de encaminhamento precisa corresponder à região do serviço de back-end.

Sujeito a regras de firewall, os clientes em qualquer sub-rede da região podem contatar o endereço IP do balanceador de carga TCP/UDP interno.

  1. Crie uma segunda sub-rede na rede lb-network, região us-west1:

    gcloud compute networks subnets create second-subnet \
        --network=lb-network \
        --range=10.5.6.0/24 \
        --region=us-west1
    
  2. Crie uma segunda regra de encaminhamento para as portas 80 e 443. Os outros parâmetros desta regra, incluindo endereço IP e serviço de back-end, são iguais aos da regra de encaminhamento principal, fr-ilb.

    gcloud compute forwarding-rules create fr-ilb-2 \
        --region=us-west1 \
        --load-balancing-scheme=internal \
        --network=lb-network \
        --subnet=second-subnet \
        --address=10.5.6.99 \
        --ip-protocol=TCP \
        --ports=80,443 \
        --backend-service=be-ilb \
        --backend-service-region=us-west1
    
  3. Conecte-se à instância de VM de cliente e teste as conexões HTTP e HTTPS com os endereços IP.

    • Conecte-se à VM do cliente:
    gcloud compute ssh vm-client --zone=us-west1-a
    
    • Teste a conectividade HTTP com os endereços IP:
    curl http://10.1.2.99
    curl http://10.5.6.99
    
    • Teste a conectividade HTTPS. O uso de --insecure é obrigatório porque a configuração do servidor Apache na configuração de exemplo usa certificados autoassinados.
    curl https://10.1.2.99 --insecure
    curl https://10.5.6.99 --insecure
    
    • Observe que as solicitações são manipuladas por todas as VMs de back-end, independentemente do protocolo (HTTP ou HTTPS) ou do endereço IP usado.

A seguir