Como configurar o balanceamento de carga interno

O balanceamento de carga interno permite executar e dimensionar os serviços atrás de um endereço IP de balanceamento de carga particular, acessível somente a instâncias internas da Virtual Private Cloud (VPC).

Para uma introdução rápida ao balanceamento de carga interno, consulte Balanceamento de carga interno em cinco minutos.

Visão geral

No Google Cloud Platform (GCP, na sigla em inglês), você conta com balanceamento de carga interno para tráfego baseado em TCP/UDP. Com esse balanceamento, execute e expanda seus serviços atrás de um endereço IP de balanceamento de carga particular, acessível apenas a instâncias internas de máquina virtual.

Antes da disponibilidade do balanceamento de carga interno, havia estas opções:

  • Opção 1: configurar um endereço IP externo e restringir o acesso à instância da máquina virtual para que apenas suas instâncias pudessem alcançá-lo. Isso deixou a configuração mais complexa.
  • Opção 2: configurar uma instância de proxy com IP interno para intermediar solicitações com back-ends. Isso era complexo de configurar e gerenciar. Além disso, a capacidade era limitada pela largura de banda e pela capacidade da instância de proxy. Essa solução alternativa não tinha todas as vantagens de um serviço de balanceamento de carga gerenciado.

Com o balanceamento de carga interno, você pode configurar um IP de balanceamento de carga interno para funcionar como o front-end das instâncias de back-end particulares. Você não precisa mais de um IP público para o serviço de balanceamento de carga. As solicitações de cliente interno permanecem internas à rede e à região da VPC, possivelmente resultando em menos latência, uma vez que todo o tráfego com carga balanceada continuará dentro da rede do Google. De maneira geral, a configuração fica mais simples.

O balanceamento de carga interno funciona com redes de VPC em modo automático, redes de VPC em modo personalizado e redes legadas. O balanceamento de carga interno também pode ser implementado com grupos de instâncias gerenciadas regionais. Isso permite fazer o escalonamento automático em uma região, tornando o serviço imune a falhas zonais.

O restante deste guia do usuário orienta você em meio aos recursos e à configuração do balanceamento de carga interno para TCP/UDP.

Sobre balanceamento de carga interno

O balanceamento de carga interno permite dar suporte a casos de uso, como os tradicionais serviços Web de três camadas, em que a camada Web usa balanceamento de carga HTTP(S) externo ou TCP/UDP externo, e a instâncias em que a camada de aplicativo ou os bancos de dados do back-end estejam implantados atrás do balanceamento de carga interno.

App da Web de três camadas com balanceamento de carga de HTTP(S) e balanceamento de carga interno (clique para ampliar)
App da Web de três camadas com balanceamento de carga de HTTP(S) e balanceamento de carga interno (clique para ampliar)

Com o balanceamento de carga interno, é possível:

  • balancear a carga de tráfego TCP/UDP usando um IP de front-end particular.
    • você pode configurar o IP do balanceamento de carga interno dentro da rede da VPC.
  • balancear a carga entre instâncias em uma região.
    • criar instâncias em várias zonas de disponibilidade dentro da mesma região.
  • configurar a verificação de integridade dos seus back-ends.
    • a integridade das instâncias de back-end é verificada pelos sistemas de verificação de integridade do GCP.
    • configurar uma verificação de integridade de TCP, SSL(TLS), HTTP ou HTTPS.
  • receber todos os benefícios de um serviço de balanceamento de carga totalmente gerenciado expansível para o tráfego do cliente.
    • dispensa a preocupação com a disponibilidade do balanceador de carga ou com o balanceador de carga como ponto de estrangulamento.

Arquitetura

O balanceamento de carga interno pode ser implementado de várias formas, como um proxy.

No modelo de proxy tradicional de balanceamento de carga interno, como mostrado abaixo à esquerda, você configura um IP interno em um dispositivo de balanceamento de carga ou instância, e as conexões de instância cliente se conectam a esse IP. O tráfego que chega a esse IP, então, é encerrado no balanceador de carga. O balanceador de carga seleciona um back-end e estabelece uma nova conexão. Há duas conexões em vigor: Cliente<->Balanceador de carga e Balanceador de carga<->Back-end.

Balanceamento de carga interno para arquitetura TCP/UDP (clique para ampliar)
Balanceamento de carga interno para arquitetura TCP/UDP (clique para ampliar)

O balanceamento de carga interno do GCP distribui as solicitações de instância cliente entre os back-ends, usando uma abordagem diferente, como mostrado à direita. É usado um balanceamento de carga leve criado sobre a pilha de virtualização de rede Andromeda para balanceamento de carga definido por software, que entrega o tráfego diretamente da instância do cliente a uma instância de back-end.

O balanceamento de carga interno não é um dispositivo nem uma solução baseada em instância, mas um balanceamento de carga totalmente distribuído, definido por software.

Implantar balanceamento de carga interno

No balanceamento de carga interno, você configura um endereço RFC1918 particular como seu IP de balanceamento de carga e configura grupos de instâncias de back-end para administrar solicitações que chegam a esse IP de balanceamento de carga a partir de instâncias cliente.

Os grupos de instâncias de back-end são classificados por zonas no escopo. Dessa forma, você pode configurá-los em várias zonas, de acordo com os requisitos de disponibilidade. Todas as instâncias precisam pertencer à mesma rede e região da VPC, mas podem estar em sub-redes diferentes. As instâncias de cliente que geram o tráfego para o IP do balanceamento de carga interno precisam pertencer à mesma rede e região da VPC, mas podem estar em sub-redes diferentes, como o IP de balanceamento de carga e os back-ends.

Um exemplo de implantação do balanceamento de carga interno é mostrado abaixo:

Implantação do balanceamento de carga interno (clique para ampliar)
Implantação do balanceamento de carga interno (clique para ampliar)

No exemplo acima, você tem uma rede da VPC chamada my-internal-app, formada por uma única sub-rede A (10.10.0.0/16) na região central dos Estados Unidos. Há dois grupos de instâncias de back-end para fornecer disponibilidade entre duas zonas. O IP de balanceamento de carga (ou seja, o IP da regra de encaminhamento) 10.10.10.1 é selecionado na mesma rede da VPC. Uma instância, 10.10.100.2, na rede my-internal-app envia uma solicitação para o IP de balanceamento de carga 10.10.10.1. Essa solicitação tem a carga balanceada para uma instância em um dos grupos de instâncias IG1 e IG2.

Os detalhes de configuração da implantação são descritos abaixo.

Endereço IP de balanceamento de carga

Com o balanceamento de carga interno, o IP de balanceamento de carga é um endereço RFC1918 particular.

O endereço IP de um balanceador de carga interno, como o IP da regra de encaminhamento, pode ser atribuído de uma das seguintes maneiras:

  • Você seleciona o IP de balanceamento de carga interno

    Você pode especificar um endereço IP não alocado da região à qual a regra de encaminhamento está associada como o IP de balanceamento de carga. Esse endereço IP pode ser de qualquer sub-rede nessa região que faça parte da rede da VPC geral. Se estiver configurando o balanceamento de carga interno em uma rede legada, você poderá usar qualquer IP não utilizado na rede.

    Você precisa determinar manualmente quais IPs já estão em uso listando todos os endereços IP de instâncias existentes e outros endereços IP de regra de encaminhamento para a rede/sub-rede da VPC.

    Você pode selecionar um IP de balanceamento de carga interno especificando um IP interno efêmero ou reservar um endereço IP interno estático que continue reservado para o projeto até removê-lo.

    Depois que você selecionar e especificar o endereço IP interno da regra de encaminhamento, ele continuará alocado enquanto a regra de encaminhamento existir. Quando a regra de encaminhamento for excluída, o endereço IP retornará ao pool de IPs disponíveis para a rede da VPC e poderá ser alocado a uma instância ou a outra regra de encaminhamento. Ele também poderá retornar ao projeto, se for um endereço IP interno estático, disponível para você atribuir a outro recurso.

  • Balanceamento de carga aloca automaticamente o IP de front-end

    O IP pode ser alocado automaticamente pela criação de uma regra de encaminhamento sem especificar um endereço IP. Nesse caso, o GCP atribuirá um endereço IP interno não alocado à regra de encaminhamento da rede/sub-rede da VPC à qual está associado. O endereço IP continuará alocado enquanto existir a regra de encaminhamento.

Algoritmo de seleção de balanceamento de carga interno

A instância de back-end de um cliente é selecionada usando-se um algoritmo de hash que considera a integridade da instância.

Por padrão, o balanceador de carga direciona conexões de um cliente para uma instância de back-end usando um hash de cinco tuplas, que usa estes cinco parâmetros para hash:

  • IP de origem do cliente
  • porta do cliente
  • IP de destino (o IP de balanceamento de carga)
  • porta de destino
  • protocolo (TCP ou UDP)

Se você quiser que o balanceador de carga direcione todo o tráfego de um cliente para uma instância de back-end específica, use uma das seguintes opções para afinidade da sessão:

  • hash baseado em três tuplas (IP de cliente, IP de destino, protocolo)
  • hash baseado em duas tuplas (IP de cliente, IP de destino)

Na seção Afinidade da sessão, encontre mais detalhes sobre essas opções.

Afinidade da sessão

Conforme descrito na seção anterior em algoritmo de seleção, o comportamento padrão é que as conexões de um cliente tenham a carga balanceada em todas as instância de back-end, usando um hash de cinco tuplas. Esse hash usa o IP de origem do cliente, a porta cliente, o IP de destino (IP de balanceamento de carga), a porta de destino e o protocolo (TCP ou UDP).

No entanto, em muitas instâncias, como no caso de aplicativos da Web que armazenam estados localmente na instância e exigem que todo o tráfego de um cliente tenha a carga balanceada para a mesma instância de back-end, todo o tráfego da instância do cliente precisa ter a carga balanceada para a mesma instância de back-end. Sem esse recurso, o tráfego pode falhar ou ter um desempenho abaixo do ideal.

Com o balanceamento de carga interno, você pode ativar todo o tráfego de um cliente para seguir uma instância de back-end específica, permitindo o recurso de afinidade.

Os seguintes tipos de afinidade podem ser ativados:

  • hash baseado em três tuplas (client_ip_proto): IP de cliente, IP de destino e protocolo
    • Use essa afinidade para que todo o tráfego de um cliente seja direcionado para a mesma instância de back-end com base em um hash dos três parâmetros acima.
  • hash baseado em duas tuplas (client_ip): IP de cliente e IP de destino
    • Use essa afinidade para que todo o tráfego de um cliente, independentemente do protocolo, seja direcionado para a mesma instância de back-end, com base em um hash dos dois parâmetros acima.

De modo geral, se você ativa uma afinidade de duas ou três tuplas, o tráfego do cliente tem a carga balanceada para o mesmo back-end, mas é possível que o tráfego não seja distribuído tão uniforme quanto o hash de cinco tuplas padrão. Via de regra, uma conexão específica permanece na mesma instância de back-end, desde que esteja íntegra.

Verificação de integridade

As verificações de integridade determinam quais instâncias podem receber novas conexões. O verificador examina as instâncias em intervalos específicos. Instâncias que não respondem com sucesso à sondagem um número específico de vezes em uma linha são marcadas como UNHEALTHY, e não recebem novas conexões, mas ainda podem ser mantidas. O verificador de integridade continua sondando instâncias não íntegras. Se uma instância responde com sucesso às sondagens um número específico de vezes, ela é marcada como HEALTHY novamente e pode receber novas conexões.

O balanceamento de carga interno suporta quatro tipos de verificação de integridade:

  • verificações de integridade de TCP
  • verificações de integridade de SSL (TLS)
  • verificações de integridade de HTTP
  • verificações de integridade de HTTPS

Se o tráfego é HTTP(S), as verificações de integridade de HTTP(S) fornecem a mais alta verificação de fidelidade, porque analisam se o servidor Web está ativo e atendendo o tráfego, não apenas a integridade da instância. Configure a verificação de integridade do SSL se o seu tráfego não é HTTPS, mas é criptografado via SSL(TLS). Para todo o tráfego TCP diferente de HTTP(S) e de SSL(TLS), configure uma verificação de integridade de TCP.

Para que uma sondagem de verificação de integridade HTTP(S) seja considerada bem-sucedida, é necessário que a instância retorne uma resposta HTTP válida com o código 200 e feche a conexão dentro do período definido. Se isso ocorre um número específico de vezes em uma linha, a verificação de integridade retorna um status HEALTHY para essa instância. Por outro lado, se há uma falha na instância, ela é marcada como UNHEALTHY e nenhuma notificação é enviada. Instâncias UNHEALTHY não recebem novas conexões, mas ainda podem ser mantidas. Se uma instância é aprovada posteriormente em uma verificação de integridade, ou seja, se responde com sucesso a um número específico de sondagens de verificação, ela começa novamente a receber novas conexões, sem receber nenhuma notificação.

Quando você define a verificação de integridade como SSL, uma conexão SSL é aberta para cada uma das instâncias. Quando define como TCP, uma conexão TCP é aberta. Em ambos os casos, se o protocolo de handshake é bem-sucedido, a sondagem de verificação de integridade é considerada bem-sucedida. A verificação de integridade é aprovada quando um número específico de sondagens é bem-sucedido. Do contrário, é considerada com falha. Conexões existentes podem ser mantidas em instâncias que não passaram na verificação de integridade. Uma sondagem de verificação de integridade de TCP ou SSL pode usar uma das seguintes verificações:

  • verificação de integridade de handshake simples (padrão): o verificador tenta um handshake simples de TCP ou SSL. Se tem êxito, a instância passa na rodada de sondagem.
  • verificação de integridade da solicitação/resposta: forneça uma string de solicitação ao verificador de integridade para envio após a conclusão do handshake de TCP ou SSL. Se a instância retorna a string de resposta que você configurou, isso significa que ela passou pela rodada de sondagem. As strings de solicitação e resposta podem ter até 1.024 bytes.

Alta disponibilidade

Balanceamento de carga interno é um serviço do Google Cloud Platform totalmente gerenciado que não requer configuração para garantir a alta disponibilidade. É um serviço totalmente distribuído e expansível para administrar o tráfego do cliente, de acordo com a necessidade. Os limites são descritos na seção Limites.

Você pode configurar vários grupos de instâncias para proporcionar alta disponibilidade ao serviço. Os grupos de instâncias são classificados por zona em escopo. Dessa forma, você pode configurá-los em várias zonas a fim de protegê-los contra falhas de instância em uma única zona.

Quando você configura mais de um grupo de instâncias, as instâncias em todos esses grupos de instâncias são tratadas como um pool de instâncias, e o balanceamento de carga interno distribui as solicitações de usuário entre as instâncias íntegras desse grupo usando o algoritmo de hash descrito na seção Algoritmo de seleção do balanceamento de carga interno.

Grupos de instâncias em várias zonas para alta disponibilidade (clique para ampliar)
Grupos de instâncias em várias zonas para alta disponibilidade (clique para ampliar)

Assim, você pode pensar na implantação como composta logicamente de um grande pool que abrange uma ou mais zonas na região onde implantou o balanceamento de carga interno.

No diagrama acima, pressupondo-se que todas as instâncias estejam íntegras, as instâncias cliente têm carga balanceada em relação a um pool composto das instâncias um, dois, três e quatro.

Como configurar o balanceamento de carga interno

Como configurar o balanceamento de carga interno (clique para ampliar)
Como configurar o balanceamento de carga interno (clique para ampliar)

Uma configuração de balanceamento de carga interno consiste em vários componentes. Todos esses componentes precisam pertencer à mesma rede e região da VPC. As instâncias de cliente que geram o tráfego precisam pertencer à mesma rede e região da VPC do IP de encaminhamento de balanceamento de carga, dos serviços de back-end e dos grupos de instâncias. As instâncias cliente não precisam estar na mesma sub-rede das instâncias com balanceamento de carga.

Este exemplo configura um balanceador de carga interno para fins de teste.

Vamos configurar o seguinte:

  1. quatro instâncias distribuídas por duas zonas na mesma região;
  2. grupos de instância para manter as instâncias;
  3. componentes de back-end, que incluem o seguinte:
    • verificação de integridade: usada para monitorar a integridade da instância;
    • serviço de back-end: monitora grupos de instâncias e os impede de exceder o uso configurado;
    • back-ends: mantêm os grupos de instâncias.
  4. uma regra de encaminhamento, com um endereço IP interno, que envia tráfego do usuário para o proxy;
  5. uma regra de firewall que permite tráfego do intervalo de endereços IP do balanceador de carga;
  6. uma instância cliente autônoma que pode ser usada para testar o balanceador de carga.

Agora vamos testar nossa configuração.

Configurar um ambiente de teste

As seções a seguir orientam você em meio à criação dos componentes do ambiente de teste.

Configurar uma rede e sub-rede da VPC

O balanceamento de carga interno funciona com redes de VPC em modo automático, redes de VPC em modo personalizado e redes legadas. Neste exemplo, usaremos uma rede da VPC em modo personalizado.

Console


  1. Acesse a página "Redes da VPC" no Console do Google Cloud Platform.
    Acessar a página "Rede da VPC"
  2. Clique em Criar rede da VPC.
  3. Digite o Nome my-custom-network.
  4. Em sub-redes, digite o Nome my-custom-subnet.
  5. Defina Região como us-central1.
  6. Digite o Intervalo de endereços IP 10.128.0.0/20.
  7. Clique em Criar.

gcloud


Criar uma rede da VPC personalizada

gcloud compute networks create my-custom-network --mode custom

Created     [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/my-custom-network].
NAME               MODE    IPV4_RANGE  GATEWAY_IPV4
my-custom-network  custom

Criar uma nova sub-rede na rede da VPC personalizada

gcloud compute networks subnets create my-custom-subnet \
    --network my-custom-network \
    --range 10.128.0.0/20 \
    --region us-central1

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/subnetworks/my-custom-subnet].
NAME              REGION       NETWORK            RANGE
my-custom-subnet  us-central1  my-custom-network  10.128.0.0/20

  • my-custom-network - o nome da rede da VPC que você está criando.
  • my-custom-subnet - o nome da sub-rede que você está criando.
  • 10.128.0.0/20: quanto ao intervalo, pode ser qualquer RFC1918 válido que não se sobreponha a outro intervalo na mesma rede. Se você estiver criando a sub-rede em uma rede da VPC existente, convém escolher um intervalo diferente.

Configurar regras de firewall

As instâncias nessa rede da VPC não serão acessíveis até as regras de firewall serem criadas. Como exemplo, você pode permitir o tráfego interno entre as instâncias e o tráfego SSH, RDP e ICMP de todas as origens.

Console


Criar regra de firewall que permita tráfego na sub-rede

  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.
  3. Digite o Nome allow-all-10-128-0-0-20.
  4. Configure a Rede da VPC como my-custom-network.
  5. Defina Filtro de origem como IP ranges.
  6. Defina Intervalos de IP de origem como 10.128.0.0/20.
  7. Defina Protocolos e portas especificados como tcp;udp;icmp.
  8. Clique em Criar.

Criar regra de firewall que permita SSH, RDP e ICMP de qualquer lugar

  1. Crie uma segunda regra de firewall com o Nome allow-tcp22-tcp3389-icmp.
  2. Configure a Rede da VPC como my-custom-network.
  3. Defina Filtro de origem como IP ranges.
  4. Defina Intervalos de IP de origem como 0.0.0.0/0 (permitir qualquer origem).
  5. Defina Protocolos e portas especificados como tcp:22;tcp:3389;icmp.
  6. Clique em Criar.

gcloud


Criar regra de firewall que permita tráfego na sub-rede

gcloud compute firewall-rules create allow-all-10-128-0-0-20 \
    --network my-custom-network \
    --allow tcp,udp,icmp \
    --source-ranges 10.128.0.0/20

Criar regra de firewall que permita SSH, RDP e ICMP de qualquer lugar

gcloud compute firewall-rules create allow-tcp22-tcp3389-icmp \
    --network my-custom-network \
    --allow tcp:22,tcp:3389,icmp

Configurar instâncias e grupos de instâncias

Um sistema de produção normalmente usaria grupos de instâncias gerenciadas com base em modelos de instância, mas essa configuração é mais rápida para os testes iniciais.

Criar duas instâncias em cada zona

Para fins de teste, vamos instalar o Apache em cada instância. Essas instância estão sendo criadas com tag de int-lb. Essa tag é usada posteriormente pela regra de firewall.

As quatro instâncias são denominadas ig-us-central1-1 a ig-us-central1-4.

Console


Criar instâncias

  1. Acesse a página "Instâncias da VM" no Console do Google Cloud Platform.
    Acessar a página "Instâncias de VM"
  2. Clique em Criar instância.
  3. Defina Nome como ig-us-central1-1.
  4. Defina a Zona como us-central1-b.
  5. Clique em Gerenciamento, disco, redes, chaves SSH para mostrar as configurações avançadas.
  6. Em Gerenciamento, preencha o campo Tags com int-lb.
  7. Defina o Script de inicialização como
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-1</h1></body></html>' | sudo tee /var/www/html/index.html
  8. Em Rede, defina Rede da VPC como my-custom-network e sub-rede como my-custom-subnet.
  9. Deixe os valores padrão no restante dos campos.
  10. Clique em Criar.
  11. Crie ig-us-central1-2 com as mesmas configurações, exceto com Script de inicialização definido como
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-2</h1></body></html>' | sudo tee /var/www/html/index.html
  12. Crie ig-us-central1-3 com as mesmas configurações, exceto com Zona definida como us-central1-c e Script de inicialização definido como
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-3</h1></body></html>' | sudo tee /var/www/html/index.html
  13. Crie ig-us-central1-4 com as mesmas configurações, exceto com Zona definida como us-central1-c e Script de inicialização definido como
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo service apache2 restart
    echo '<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>' | sudo tee /var/www/html/index.html

gcloud


gcloud compute instances create ig-us-central1-1 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-b \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-1</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-1].
NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
ig-us-central1-1 us-central1-b n1-standard-1             10.128.0.3  23.251.150.133 RUNNING

gcloud compute instances create ig-us-central1-2 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-b \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-2</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/ig-us-central1-2].
NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
ig-us-central1-2 us-central1-b n1-standard-1             10.128.0.11 23.251.148.160 RUNNING

gcloud compute instances create ig-us-central1-3 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-c \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-3</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-c/instances/ig-us-central1-3].
NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
ig-us-central1-3 us-central1-c n1-standard-1             10.128.0.12 104.196.31.214 RUNNING

gcloud compute instances create ig-us-central1-4 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --tags int-lb \
    --zone us-central1-c \
    --subnet my-custom-subnet \
    --metadata startup-script="#! /bin/bash
      apt-get update
      apt-get install apache2 -y
      a2ensite default-ssl
      a2enmod ssl
      service apache2 restart
      echo '<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>' | tee /var/www/html/index.html
      EOF"

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-c/instances/ig-us-central1-4].
NAME             ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
ig-us-central1-4 us-central1-c n1-standard-1             10.128.0.13 104.196.25.101 RUNNING

Criar um grupo de instâncias para cada zona e adicionar instâncias

Console


  1. Acesse a página "Grupos de instâncias" no Console do Google Cloud Platform.
    Acessar a página "Grupos de instâncias"
  2. Clique em Criar grupo de instâncias.
  3. Defina Nome como us-ig1.
  4. Defina Zona como us-central1-b.
  5. Em Definição da instância, clique em Selecionar instâncias existentes.
  6. Configure a Rede da VPC como my-custom-network.
  7. Defina sub-rede como my-custom-subnet.
  8. Em Instâncias de VM, selecione ig-us-central1-1 e ig-us-central1-2.
  9. Mantenha as outras configurações inalteradas.
  10. Clique em Criar.
  11. Repita as etapas, mas faça as seguintes configurações:
    • Nome: us-ig2
    • Zona: us-central1-c
    • Instâncias: ig-us-central1-3 e ig-us-central1-4.
  12. Verifique se você tem dois grupos de instâncias, cada um com duas instâncias.

gcloud


  1. Crie o grupo de instâncias us-ig1.

    gcloud compute instance-groups unmanaged create us-ig1 \
        --zone us-central1-b
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].
    NAME   ZONE          NETWORK MANAGED INSTANCES
    us-ig1 us-central1-b                 0

  2. Adicione ig-us-central1-1 e ig-us-central1-2 a us-ig1

    gcloud compute instance-groups unmanaged add-instances us-ig1 \
        --instances ig-us-central1-1,ig-us-central1-2 --zone us-central1-b
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instanceGroups/us-ig1].

  3. Crie o grupo de instâncias us-ig2.

    gcloud compute instance-groups unmanaged create us-ig2 \
        --zone us-central1-c
    

    Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-c/instanceGroups/us-ig2].
    NAME   ZONE          NETWORK MANAGED INSTANCES
    us-ig2 us-central1-c                  0

  4. Adicione ig-us-central1-3 e ig-us-central1-4 a us-ig2

    gcloud compute instance-groups unmanaged add-instances us-ig2 \
        --instances ig-us-central1-3,ig-us-central1-4 \
        --zone us-central1-c
    

    Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/ig-us-central1-c/instanceGroups/us-ig2].

Configurar o balanceador de carga

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 de TCP, clique em Iniciar configuração.
  4. Em Somente voltado para a Internet ou interno, selecione Only between my VMs.
  5. Clique em Continuar.
  6. Defina Nome como my-int-lb.

Configurar serviços de back-end

  1. Clique em Configuração de back-end.
  2. O Nome do serviço de back-end é exibido como my-int-lb.
  3. Defina Região como us-central1.
  4. Configure a Rede da VPC como my-custom-network.
  5. Em Back-ends, selecione o grupo de instâncias us-ig1.
  6. Clique em Adicionar back-end.
  7. Selecione o grupo de instâncias us-ig2.
  8. Em Verificação de integridade, selecione Criar verificação de integridade.
    1. Defina o Nome da verificação de integridade como my-tcp-health-check.
    2. Defina Protocolo como TCP.
    3. Não altere as outras configurações.
    4. Clique em Salvar e continuar.
  9. Verifique se há uma marca de seleção azul ao lado de Configuração do back-end no Console do Google Cloud Platform. Se não houver, verifique se você concluiu todas as etapas acima.

Configurar serviços de front-end

  1. Clique em Configuração do front-end.
  2. Em sub-rede, selecione my-custom-subnet.
  3. Em Endereço IP, selecione Automatic.
  4. Defina Portas como 80.
  5. Verifique se há uma marca de seleção azul ao lado de Configuração do front-end no Console do Google Cloud Platform. Se não houver, verifique se você concluiu todas as etapas acima.

Revisar e finalizar

  1. Clique em Revisar e finalizar.
  2. Verifique suas configurações.
  3. Clique em Criar.

gcloud


Criar verificação de integridade

gcloud compute health-checks create tcp my-tcp-health-check \
    --port 80

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/my-tcp-health-check].
NAME                PROTOCOL
my-tcp-health-check TCP

Criar um serviço de back-end

gcloud compute backend-services create my-int-lb \
    --load-balancing-scheme internal \
    --region us-central1 \
    --health-checks my-tcp-health-check \
    --protocol tcp

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/backendServices/my-int-lb].
NAME               BACKENDS PROTOCOL
my-int-lb          TCP

Adicionar grupos de instância ao serviço de back-end

No balanceamento de carga interno, as conexões de entrada são distribuídas com base na configuração de afinidade da sessão. Se a afinidade da sessão não estiver definida, o balanceador de carga distribuirá todas as conexões entre todas as instâncias disponíveis, o mais uniformemente possível, independentemente da carga atual.

gcloud compute backend-services add-backend my-int-lb \
    --instance-group us-ig1 \
    --instance-group-zone us-central1-b \
    --region us-central1

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/backendServices/my-int-lb].

gcloud compute backend-services add-backend my-int-lb \
    --instance-group us-ig2 \
    --instance-group-zone us-central1-c \
    --region us-central1

Updated [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]//regions/us-central1/backendServices/my-int-lb].

Criar uma regra de encaminhamento

Crie uma regra de encaminhamento para direcionar o tráfego para o balanceador de carga interno. Como esse comando não especifica um endereço IP para o balanceador de carga, é atribuído um automaticamente. Se você quiser especificar um, selecione qualquer endereço que não seja usado na região e na rede da VPC e o especifique usando a sinalização --address.

gcloud compute forwarding-rules create my-int-lb-forwarding-rule \
    --load-balancing-scheme internal \
    --ports 80 \
    --network my-custom-network \
    --subnet my-custom-subnet \
    --region us-central1 \
    --backend-service my-int-lb

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/forwardingRules/my-int-lb-forwarding-rule].

IPAddress: 10.128.0.6 IPProtocol: TCP backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/backendServices/my-int-lb creationTimestamp: '2016-06-17T12:56:44.843-07:00' description: '' id: '6922319202683054867' kind: compute#forwardingRule loadBalancingScheme: INTERNAL name: my-int-lb-forwarding-rule network: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/my-custom-network ports: - '80' region: us-central1 selfLink: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/forwardingRules/my-int-lb-forwarding-rule subnetwork: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-central1/subnetworks/my-custom-subnet

Configurar uma regra de firewall para permitir balanceamento de carga interno

Configure uma regra de firewall para permitir o tráfego para o balanceador de carga e do balanceador para as instâncias. E configure outra para permitir sondagens de verificação de integridade do verificador de integridade.

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.
  3. Defina Nome como allow-internal-lb.
  4. Configure a Rede da VPC como my-custom-network.
  5. Defina Tags de destino como int-lb.
  6. Defina Filtro de origem como IP ranges.
  7. Defina Intervalos de IP de origem como 10.128.0.0/20.
  8. Defina Protocolos e portas especificados como tcp:80;tcp:443.
  9. Clique em Criar.
  10. Clique em Criar regra de firewall.
  11. Defina Nome como allow-health-check.
  12. Configure a Rede da VPC como my-custom-network.
  13. Defina Tags de destino como int-lb.
  14. Defina Filtro de origem como IP ranges.
  15. Defina Intervalos de IPs de origem como 130.211.0.0/22 e 35.191.0.0/16.
  16. Defina Protocolos e portas especificados como tcp.
  17. Clique em Criar.

gcloud


gcloud compute firewall-rules create allow-internal-lb \
    --network my-custom-network \
    --source-ranges 10.128.0.0/20 \
    --target-tags int-lb \
    --allow tcp:80,tcp:443

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-internal-lb].
NAME               NETWORK            SRC_RANGES     RULES           SRC_TAGS  TARGET_TAGS
allow-internal-lb  my-custom-network  10.128.0.0/20  tcp:80,tcp:443            int-lb

gcloud compute firewall-rules create allow-health-check \
    --network my-custom-network \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --target-tags int-lb \
    --allow tcp

NAME                NETWORK            SRC_RANGES                    RULES  SRC_TAGS  TARGET_TAGS
allow-health-check  my-custom-network  130.211.0.0/22,35.191.0.0/16  tcp              int-lb

Criar uma instância cliente autônoma

Para fins de teste, crie uma instância cliente autônoma na mesma região que o balanceador de carga.

Console


  1. Acesse a página "Instâncias da VM" no Console do Google Cloud Platform.
    Acessar a página "Instâncias de VM"
  2. Clique em Criar instância.
  3. Defina Nome como standalone-instance-1.
  4. Defina Zona como us-central1-b.
  5. Clique em Gerenciamento, disco, redes, chaves SSH para mostrar as configurações avançadas.
  6. Em Gerenciamento, preencha o campo Tags com standalone.
  7. Em Rede, defina Rede da VPC como my-custom-network e sub-rede como my-custom-subnet.
  8. Clique em Criar.

gcloud


gcloud compute instances create standalone-instance-1 \
    --image-family debian-9 \
    --image-project debian-cloud \
    --zone us-central1-b \
    --tags standalone \
    --subnet my-custom-subnet

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-central1-b/instances/standalone-instance-1].
NAME                  ZONE          MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP EXTERNAL_IP    STATUS
standalone-instance-1 us-central1-b n1-standard-1             10.128.0.8  23.251.150.133 RUNNING

Criar uma regra de firewall para permitir conexões SSH com a instância cliente autônoma

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.
  3. Digite um Nome de allow-ssh-to-standalone.
  4. Configure a Rede da VPC como my-custom-network.
  5. Defina Tags de destino como standalone.
  6. Defina Filtro de origem como IP ranges.
  7. Defina Intervalos de IP de origem como 0.0.0.0/0 (permitir qualquer origem).
  8. Defina Protocolos e portas especificados como tcp:22.
  9. Clique em Criar.

gcloud


gcloud compute firewall-rules create allow-ssh-to-standalone \
    --network my-custom-network \
    --target-tags standalone \
    --allow tcp:22

Created [https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls/allow-ssh-to-standalone].
NAME                     NETWORK            SRC_RANGES  RULES   SRC_TAGS  TARGET_TAGS
allow-ssh-to-standalone  my-custom-network  0.0.0.0/0   tcp:22            standalone

Excluir os IPs externos das suas instâncias

Quando você criou as instâncias para seus grupos de instâncias, elas precisavam de IPs externos para que fosse possível fazer o download e a instalação do Apache. Com o Apache instalado e como essas instâncias atendem um balanceador de carga interno, não é necessário acesso à Internet, portanto é possível remover os IPs externos das instâncias.

Console


  1. Acesse a página "Instâncias da VM" no Console do Google Cloud Platform.
    Acessar a página "Instâncias de VMs"
  2. Clique em ig-us-central1-1 para buscar o console dessa instância.
  3. Clique em Editar.
  4. Defina IP externo como None.
  5. Clique em Salvar.
  6. Repita para ig-us-central1-2.
  7. Repita para ig-us-central1-3.
  8. Repita para ig-us-central1-4.

gcloud


gcloud compute instances delete-access-config ig-us-central1-1 \
    --access-config-name external-nat --zone us-central1-b
gcloud compute instances delete-access-config ig-us-central1-2 \
    --access-config-name external-nat --zone us-central1-b
gcloud compute instances delete-access-config ig-us-central1-3 \
    --access-config-name external-nat --zone us-central1-c
gcloud compute instances delete-access-config ig-us-central1-4 \
    --access-config-name external-nat --zone us-central1-c

Testar o balanceador de carga

Em sua máquina local, conecte-se à instância cliente autônoma.

gcloud compute --project [PROJECT_ID] ssh --zone us-central1-b standalone-instance-1

Use curl para acessar o endereço IP interno do balanceador de carga. Repita algumas vezes a até ver a resposta de outras instâncias.

$ curl 10.128.0.6
<!doctype html><html><body><h1>ig-us-central1-2</h1></body></html>
$ curl 10.128.0.6
<!doctype html><html><body><h1>ig-us-central1-1</h1></body></html>
$ curl 10.128.0.6
<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>
$ curl 10.128.0.6
<!doctype html><html><body><h1>ig-us-central1-4</h1></body></html>

Novos parâmetros de comando do gcloud para balanceamento de carga interno

O balanceamento de carga interno usa a mesma regra de encaminhamento, serviço de back-end e recursos de verificação de integridade como balanceamento de carga HTTP(S), mas com alguns novos parâmetros de comando. Nesta seção, há informações apenas desses novos parâmetros. Os parâmetros existentes são explicados na referência da ferramenta de linha de comando do gcloud.

Regra de encaminhamento

Para balanceamento de carga interno, a regra de encaminhamento aponta diretamente para um serviço de back-end na mesma região que a regra de encaminhamento. Nesta seção, há informações sobre os novos parâmetros no contexto do comando create. Os comandos get, list, describe e delete permanecem inalterados. Consulte o comando forwarding-rules do gcloud para explicações sobre outros parâmetros.

Novos parâmetros de criação de regras de encaminhamento

gcloud compute forwarding-rules create NAME \
    --load-balancing-scheme internal \
    [--address] \
    --region \
    [--protocol]
    --ports PORT,[PORT,…] \
    --backend-service NAME \
    [--subnetwork] \
    [--network]
  • --load-balancing-scheme: para balanceamento de carga interno, esse parâmetro precisa ser especificado como internal. Inicialmente, ele só é suportado para balanceamento de carga interno.
  • --address: o endereço IP de destino do balanceador de carga interno. Quando o esquema do balanceamento de carga é internal, ele só pode ser um endereço IP RFC1918 pertencente à sub-rede configurada para a regra de encaminhamento. Nesse caso, um endereço externo não pode ser usado. Se esse parâmetro não for especificado e o esquema do balanceamento de carga for internal, o endereço IP da regra de encaminhamento será automaticamente alocado do intervalo de IPs interno da sub-rede ou da rede configurada para a regra de encaminhamento.
  • --region: a região onde a regra de encaminhamento é criada. Regras de encaminhamento global não são suportadas para balanceamento de carga interno.
  • --protocol (padrão: tcp): o protocolo, tcp ou udp, que o balanceador de carga interno processa.
  • --ports: um parâmetro que permite que você especifique de uma a cinco portas, em uma lista separada por vírgulas. Somente pacotes destinados a portas listadas são encaminhados.
  • --backend-service: o serviço de back-end que receberá todo o tráfego direcionado à regra de encaminhamento.
  • --subnetwork: a sub-rede à qual essa regra de encaminhamento se aplica. Quando configurado para balanceamento de carga interno, o IP interno da regra de encaminhamento é atribuído dessa sub-rede. Se a rede estiver em modo de sub-rede automático, a sub-rede será opcional, já que poderá ser determinada com base na região. No entanto, se a rede estiver em modo de sub-rede personalizado, uma sub-rede precisará ser especificada. As instâncias configuradas como back-ends para um balanceador de carga interno podem pertencer a sub-redes diferentes na mesma região.
  • --network: a rede à qual esta regra de encaminhamento se aplica. Quando configurado para balanceamento de carga interno, o IP interno da regra de encaminhamento é atribuído a partir dessa rede. Se esse campo não é especificado, é usada a rede padrão. Na ausência dela, é necessário especificar esse campo.

Definir o destino de uma regra de encaminhamento

Com o comando forwarding-rules set-target, altere o serviço de back-end para o qual é direcionada a regra de encaminhamento. Para balanceamento de carga interno, o destino da regra de encaminhamento precisa ser um serviço de back-end e os parâmetros --backend-service e --region são necessários.

Console


Use a ferramenta de linha de comando gcloud para esta etapa.

gcloud


gcloud compute forwarding-rules set-target \
    --region REGION \
    --backend-service NAME

Serviço de back-end

A regra de encaminhamento direciona a solicitação do cliente para o serviço de back-end. Por sua vez, o serviço de back-end direciona a solicitação do cliente para uma instância íntegra no back-end. Para ser considerada íntegra, é necessário que a instância passe na verificação de integridade.

Novos parâmetros de criação de serviços de back-end

Consulte o backend-services do gcloud para explicações de outros parâmetros.

gcloud compute backend-services create NAME \
    --load-balancing-scheme internal \
    --region \
    --health-checks \
    --protocol \
    [--session-affinity] \
    [--timeout]
  • --load-balancing-scheme internal (necessário): especifica se o balanceador de carga está fazendo o balanceamento de carga interno ou externo. Apenas balanceamento de carga interno é suportado nesta versão. Um valor internal é necessário.
  • --region (necessário): a região onde o serviço de back-end reside. Para balanceamento de carga interno, instâncias, grupos de instâncias, serviço de back-end, serviço de balanceador de carga e instâncias de cliente precisam estar na mesma região da rede. Eles não precisam estar na mesma zona ou sub-rede que todos.
  • --health-checks (obrigatório): o nome da verificação de integridade que o serviço de back-end usa para monitorar instâncias. O parâmetro --health-checks é necessário. Os parâmetros --http-health-checks e --https-health-checks não são compatíveis.
  • --protocol (padrão: http): o protocolo, tcp ou udp, que o balanceador de carga processará. Esse parâmetro precisa corresponder ao parâmetro --protocol especificado para a regra de encaminhamento. O protocolo é obrigatório para serviços de back-end como o valor padrão http, e somente tcp e udp são compatíveis com o balanceamento de carga interno.
  • --session-affinity: se não for especificado, novas conexões para o balanceador de carga da mesma instância serão distribuídas de maneira uniforme entre instâncias de back-end. Para que as conexões da mesma instância de cliente terminem na mesma instância de back-end, especifique uma afinidade de sessão de client_ip ou client_ip_proto. Consulte Afinidade da sessão para mais detalhes.
  • --timeout (padrão=30s): especifica quantos segundos aguardar uma resposta do grupo de instâncias de back-end antes de considerá-la uma solicitação com falha.

Novos parâmetros para o comando backend-services add-backend

Consulte o comando backend-services add-backend para explicações sobre outros parâmetros.

gcloud compute backend-services add-backend [INSTANCE_GROUP] \
    --balancing-mode connection \
    --instance-group-zone \
    --region
  • --balancing-mode: somente o modo de balanceamento CONNECTION é suportado para balanceamento de carga interno. Balanços com base no número total de conexões pendentes. Utilização da instância e conexões atuais em andamento com a instância não são levadas em conta. As conexões de entrada são distribuídas da maneira mais uniforme possível entre todas as instâncias disponíveis, independentemente da carga atual. As conexões estabelecidas permanecem na mesma instância, independentemente de novas conexões de entrada. Os parâmetros --max-rate e --max-rate-per-instance não são compatíveis com o balanceamento de carga interno.
  • --instance-group-zone: a zona do grupo de instâncias que você está associando ao back-end.
  • --region: especifique a região do back-end. Essa é a mesma região do restante dos componentes do balanceador de carga interno.
  • --instance-group-region: a região do grupo de instâncias regional que você está associando ao back-end.
  • Os seguintes parâmetros não são válidos para balanceamento de carga interno:
    • --capacity-scaler
    • --max-rate
    • --max-rate-per-instance
    • --max-utilization

OBSERVAÇÃO: comandos para get, list, describe, remove-backend e delete agora utilizam uma sinalização --regions adicional quando usados para serviços de back-end regionais correspondentes.

Diminuição da conexão para serviços de back-end

Você pode ativar a diminuição da conexão em serviços de back-end a fim de garantir uma interrupção mínima para os usuários quando uma instância é removida de um grupo de instâncias, manualmente ou por um autoescalador. A diminuição da conexão só está disponível para conexões TCP. A diminuição da conexão não é compatível com tráfego UDP. Para saber mais sobre a diminuição da conexão, leia a documentação Como ativar a diminuição da conexão.

Verificações de integridade

As verificações de integridade determinam quais instâncias podem receber novas conexões. O verificador examina as instâncias em intervalos específicos. Instâncias que não respondem com sucesso à sondagem um número específico de vezes em uma linha são marcadas como UNHEALTHY. Não são enviadas novas conexões para a instância, embora ainda sejam permitidas conexões existentes. As verificações de integridade precisam ser do tipo tcp, ssl, http ou https.

Configure uma verificação de integridade TCP, SSL, HTTP ou HTTPS para determinar a integridade das suas instâncias.

  • Se o serviço em execução nas instâncias de back-end for baseado em HTTP, use uma verificação de integridade de HTTP.
  • Se o serviço em execução nas instâncias de back-end for baseado em HTTPS, use uma verificação de integridade de HTTPS.
  • Se o serviço em execução nas instâncias de back-end usar SSL, use uma verificação de integridade de SSL.
  • A menos que você tenha uma razão explícita para utilizar um tipo diferente de verificação de integridade, use uma verificação de integridade de TCP.

Uma vez configuradas, as sondagens de verificação de integridade são enviadas regularmente na porta especificada para todos os grupos de instâncias configurados.

Consulte Verificação de integridade para informações mais detalhadas sobre como as verificações de integridade funcionam.

Parâmetros de criação de health-checks

gcloud compute health-checks create [tcp | ssl | http | https] my-health-check \
    ...options

Se você estiver criptografando tráfego entre o balanceador de carga e suas instâncias, use uma verificação de integridade de SSL ou HTTPS.

  • --check-interval (padrão=5s): com que frequência enviar uma sondagem de verificação de integridade a uma instância. Por exemplo, 10s enviam a sondagem a cada 10 segundos. Unidades válidas para essa sinalização são s para segundos e m para minutos.
  • --healthy-threshold (padrão=2): o número de sondagens consecutivas de verificação de integridade bem-sucedidas antes de uma instância não íntegra ser marcada como HEALTHY.
  • --port (padrão=80 para TCP e HTTP, 443 para SSL e HTTPS): o número da porta TCP monitorada pela verificação de integridade.
  • --request: válido apenas para verificações de integridade de TCP e SSL. Uma string opcional de até 1.024 caracteres enviada à instância pelo verificador de integridade. O verificador de integridade procura pela resposta na instância da string fornecida no campo --response. Se --response não está configurado, o verificador de integridade não aguarda a resposta e considera a sondagem como bem-sucedida quando há êxito no handshake TCP ou SSL.
  • --response: válido apenas para verificações de integridade de TCP e SSL. Uma string opcional de até 1.024 caracteres que o verificador de integridade espera receber da instância. Se a resposta exata não é recebida, a sondagem de verificação de integridade falha. Se --response está configurado, mas --request não está, o verificador de integridade espera uma resposta de qualquer maneira. A menos que seu sistema envie automaticamente uma mensagem em resposta a um handshake bem-sucedido, sempre configure --response para corresponder a uma --request explícita.
  • --timeout (padrão=5s): se o verificador de integridade não recebe resposta válida da instância nesse intervalo, a sondagem é considerada com falha. Por exemplo, 10s faz com que o verificador aguarde 10 segundos antes de considerar a sondagem como falha. Unidades válidas para essa sinalização são s para segundos e m para minutos.
  • --unhealthy-threshold (padrão=2): o número de falhas consecutivas de sondagem de verificação de integridade para que uma instância íntegra seja marcada como UNHEALTHY.

IPs de origem e regras de firewall da verificação de integridade

Para balanceamento de carga interno, as sondagens de verificação de integridade para suas instâncias de carga balanceada vêm de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. É necessário que as regras de firewall permitam essas conexões.

A seção Configurar uma regra de firewall para permitir balanceamento de carga interno abrange esta etapa.

Balanceamento de carga interno com grupos de instâncias regionais

Você pode usar o balanceamento de carga interno com grupos de instâncias regionais. Os comandos gcloud são os seguintes.

Este comando cria um grupo de instâncias regionais em us-central1, que pode sofrer escalonamento automático.

    gcloud compute instance-groups managed create us-central1-ig1 \
        --region us-central1

Este comando cria um serviço de back-end em us-central1. Em seguida, um back-end contendo o grupo de instâncias regionais pode ser adicionado.

    gcloud compute backend-services create my-int-lb \
        --load-balancing-scheme internal \
        --region us-central1 \
        --health-checks my-tcp-health-check

Este comando adiciona o grupo de instâncias regionais ao serviço de back-end.

    gcloud compute backend-services add-backend my-int-lb \
        --instance-group us-central1-ig1 \
        --instance-group-region us-central1 \
        --region us-central1

Em seguida, você pode anexar esse serviço de back-end a uma regra de encaminhamento com load-balancing-scheme definido como interno:

    gcloud compute forwarding-rules create internal-lb-forwarding-rule \
        --load-balancing-scheme internal \
        --ports 80 \
        --network my-custom-network \
        --subnet my-custom-subnet \
        --region us-central1 \
        --backend-service my-int-lb

Restrições

  • Instâncias de cliente e instâncias de back-end têm que estar no Google Cloud Platform. O envio de tráfego de clientes no local (fora do GCP) para o balanceador de carga interno no GCP não é suportado nesta versão. Esse recurso terá suporte em versões futuras.
  • O IP do balanceador de carga interno não pode ser o próximo IP de conexão de uma rota configurada manualmente. Se uma rota configurada tiver o IP do balanceador de carga interno como destino, o tráfego correspondente a essa rota será ignorado.
  • Não é possível enviar tráfego por meio de um túnel VPN para o IP do balanceador de carga.
  • Os clientes em uma região não podem acessar um balanceador de carga interno em uma região diferente. Todas as instâncias na configuração do balanceamento de carga interno precisam pertencer à mesma rede e região da VPC, mas podem estar em sub-redes diferentes.

Limites

  • Um número máximo de 50 regras de encaminhamento do balanceador de carga interno é permitido por rede.

  • Um máximo de 250 back-ends é permitido por regra de encaminhamento do balanceador de carga interno.

Preços

Os preços de balanceamento de carga normais são aplicáveis.

Perguntas frequentes

P: Quais protocolos são compatíveis com o balanceamento de carga interno?

  • O balanceamento de carga interno é compatível com os tráfegos TCP e UDP.

P: A descoberta de serviço é compatível com o balanceamento de carga interno?

  • O registro e a descoberta do nome de serviço não são compatíveis. As instâncias do cliente precisam ser configuradas para acessar o balanceamento de carga interno diretamente pelo IP de front-end do balanceamento de carga interno.

Q: Posso usar pools de destino com balanceamento de carga interno?

Enviar comentários sobre…

Compute Engine Documentation