Como configurar balanceamento de carga interno

O balanceamento de carga interno permite executar e dimensionar os serviços por meio de um endereço IP privado de balanceamento de carga, acessível somente por instâncias internas da nuvem privada virtual (VPC, na sigla em inglês).

Para ver uma introdução rápida ao balanceamento de carga interno, consulte esta página.

Visão geral

O Google Cloud Platform (GCP) oferece balanceamento de carga interno para tráfego baseado em TCP/UDP. Com ele, é possível executar e dimensionar os serviços por meio de um endereço IP privado de balanceamento de carga, acessível apenas por instâncias internas de máquina virtual.

Use o balanceamento de carga interno a fim de configurar um endereço IP de balanceamento de carga interno que atue como front-end para as instâncias de back-end privadas. Não é necessário um IP público para o serviço de balanceamento de carga. As solicitações de cliente internas permanecerão internas na região e na rede VPC, possivelmente resultando em menos latência, já que todo o tráfego com carga balanceada continuará dentro da rede do Google. De modo geral, a configuração ficará mais simples.

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

O restante deste guia do usuário mostra os recursos e a configuração do balanceamento de carga interno para TCP/UDP.

Sobre balanceamento de carga interno

O balanceamento de carga interno é compatível com casos de uso, como os tradicionais serviços da Web de três camadas, em que a camada da Web usa balanceamento de carga HTTP(S) externo ou TCP/UDP externo, e também a instâncias em que a camada de aplicativo ou os bancos de dados do back-end são implantados com o balanceamento de carga interno.

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

Com o balanceamento de carga interno, é possível realizar os seguintes procedimentos:

  • Balancear a carga de tráfego TCP/UDP usando um IP de front-end privado.
    • Você pode configurar o IP do balanceamento de carga interno dentro da rede VPC.
  • Balancear a carga entre instâncias em uma região.
    • É possível 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.
  • Aproveite todos os benefícios de um serviço de balanceamento de carga totalmente gerenciado que pode ser expandido ou reduzido para administrar o tráfego do cliente de acordo com a necessidade.
    • O balanceador de carga altamente disponível não é um ponto de estrangulamento.

Arquitetura

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

No modelo de proxy tradicional do balanceamento de carga interno, como mostrado abaixo à esquerda, você configura um IP interno em instâncias ou em um dispositivo de balanceamento de carga e a instância de cliente se conecta a esse IP. O tráfego que chega ao IP é encerrado no balanceador de carga, que seleciona um back-end e estabelece uma nova conexão com ele. 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 solicitações de instâncias de clientes aos back-ends usando uma abordagem diferente, como mostrado à direita. Ele usa um balanceamento de carga leve criado com base na pilha de virtualização de rede Andromeda para fornecer balanceamento de carga definido por software que distribui o tráfego diretamente da instância cliente para uma instância de back-end.

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

Como implantar balanceamento de carga interno com clientes do GCP

Quando os clientes estão na rede VPC, o balanceamento de carga interno distribui o tráfego interno do cliente em back-ends que executam serviços privados. As instâncias de clientes, o endereço IP de balanceamento de carga interno e as instâncias de back-end estão configurados na rede VPC.

Balanceamento de carga interno quando os clientes estão em uma rede VPC (clique para ampliar)
Balanceamento de carga interno quando os clientes estão em uma rede VPC (clique para ampliar)

Na ilustração, a instância de cliente na sub-rede 1 se conecta ao endereço IP de balanceamento de carga interno (10.240.0.200). É feito o balanceamento de carga do tráfego dessa instância para uma instância de back-end (10.240.0.2) na sub-rede 2.

Como implantar balanceamento de carga interno com clientes por VPN ou interconexão

Quando os clientes se conectam por VPN ou interconexão, eles podem estar localizados na rede local, na rede de outro provedor de nuvem ou em outra rede do GCP. O tráfego proveniente dos clientes chega ao balanceador de carga interno na rede VPC por meio do Cloud VPN. Em seguida, é feito o balanceamento de carga desse tráfego internamente para uma instância de back-end íntegra, pertencente ao serviço de back-end apontado pela regra de encaminhamento.

O túnel de VPN e o balanceador de carga interno precisam estar na mesma região.

Balanceamento de carga interno quando os clientes se conectam por VPN (clique para ampliar)
Balanceamento de carga interno quando os clientes se conectam por VPN (clique para ampliar)

A implementação acima inclui instâncias nas sub-redes 2 e 3 que veiculam conteúdo para um aplicativo de carrinho de compras. Essas instâncias fazem parte de uma rede do GCP chamada shopnet.

Na ilustração, a instância de cliente com o endereço IP 192.168.1.1 reside na rede local e se conecta ao endereço IP de balanceamento de carga interno (10.240.0.200) no GCP usando VPN. Em seguida, é feito o balanceamento de carga do tráfego proveniente do cliente para uma instância de back-end (10.240.0.2) na sub-rede 2.

Vários túneis de VPN ou interconexões

Quando você configura vários túneis de VPN entre redes que são ou não do GCP, os clientes que não são do GCP acessam o balanceamento de carga interno por esses túneis, conforme mostrado abaixo.

Balanceamento de carga interno com vários túneis de VPN (clique para ampliar)
Balanceamento de carga interno com vários túneis de VPN (clique para ampliar)

Na ilustração, a instância de cliente com o endereço IP 192.168.1.1 reside na rede local e se conecta ao endereço IP de balanceamento de carga interno (10.240.0.200) no GCP por VPN. O balanceamento de carga desse tráfego pode ser feito por vários túneis, assim como a geração de hash ECMP.

Enquanto o número de túneis não mudar, o balanceador de carga enviará todo o tráfego para uma determinada sessão no mesmo back-end. Para enviar todo o tráfego de um determinado cliente para o mesmo back-end, use a afinidade da sessão.

Se o número de túneis mudar, a rede local poderá escolher um túnel diferente para uma sessão. O balanceador de carga tentará mapear para o mesmo back-end, mas talvez uma pequena porcentagem de conexões seja redefinida.

Como implantar balanceamento de carga interno

No balanceamento de carga interno, você define um endereço RFC1918 privado como IP de balanceamento de carga e configura grupos de instâncias de back-end para processar as solicitações que chegam a esse IP de balanceamento de carga provenientes de instâncias de clientes.

Os grupos de instâncias de back-end podem ser classificados por zona ou região, o que permite a configuração deles de acordo com os requisitos de disponibilidade.

As instâncias de clientes que geram o tráfego para o IP do balanceamento de carga interno precisam pertencer à mesma rede e à mesma região de VPC, mas podem estar em sub-redes diferentes, como o IP de balanceamento de carga e os back-ends.

Veja a seguir um exemplo de implantação de balanceamento de carga interno:

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

No exemplo acima, há uma rede 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 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 privado.

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 proveniente da região a que 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 VPC geral. Se você estiver configurando o balanceamento de carga interno em uma rede legada, poderá usar qualquer IP não utilizado na rede.

    Você precisa determinar manualmente quais IPs já estão em uso. Para isso, liste todos os endereços IP de instâncias existentes e outros endereços IP de regra de encaminhamento referentes à rede/sub-rede VPC.

    Você pode selecionar um IP de balanceamento de carga interno especificando um IP interno temporário ou pode reservar um endereço IP interno estático que permaneça reservado para o projeto até você removê-lo.

    Depois que o endereço IP interno da regra de encaminhamento for selecionado e especificado, ele permanecerá alocado enquanto essa regra existir. Quando a regra de encaminhamento for excluída, o endereço IP retornará ao pool de endereços IP disponíveis para a rede VPC e poderá ser alocado a uma instância ou a outra regra de encaminhamento. Se ele for um endereço IP interno estático, também poderá retornar ao projeto, ficando disponível para ser atribuído a outro recurso.

  • O 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 VPC à qual está associado. O endereço IP permanecerá alocado enquanto essa regra existir.

Algoritmo de seleção do balanceamento de carga interno

A instância de back-end de um cliente é selecionada com o uso de um algoritmo de hash que leva em consideração 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 gerar o hash:

  • endereço IP de origem do cliente
  • porta do cliente
  • endereço IP de destino (o endereço IP do 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)

Encontre mais detalhes sobre essas opções na seção Afinidade da sessão.

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âncias de back-end, usando um hash de cinco tuplas. Esse hash usa o IP de origem do cliente, a porta do 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 permitir que todo o tráfego de um cliente siga uma determinada instância de back-end ao ativar o recurso de afinidade.

É possível ativar os seguintes tipos de afinidade:

  • 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 responder às sondagens um determinado número de vezes seguidas, ela será marcada como HEALTHY novamente e poderá receber novas conexões.

O balanceamento de carga interno é compatível com 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 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

O balanceamento de carga interno é um serviço do Google Cloud Platform totalmente gerenciado, por isso não precisa de nenhuma configuração para garantir a alta disponibilidade. É um serviço totalmente distribuído e que se expande 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. Como os grupos de instâncias são classificados por zona no escopo, é possível 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 são tratadas como um pool 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)

Você pode pensar na implantação como composta logicamente por um grande pool que abrange uma ou mais zonas na região em que o balanceamento de carga interno foi implantado.

No diagrama acima, supondo que todas as instâncias sejam íntegras, foi feito o balanceamento de carga das instâncias de clientes para um pool composto pelas instâncias 1, 2, 3 e 4.

Como configurar 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 à mesma região de 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 de clientes não precisam estar na mesma sub-rede das instâncias com carga balanceada.

Neste exemplo, mostramos a configuração de 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 para manter as instâncias
  3. os seguintes componentes de back-end:
    • 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

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

Configurar uma rede e uma sub-rede VPC

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

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. Insira um Nome, como my-custom-network.
  4. Em sub-redes, insira 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 VPC personalizada

gcloud compute networks create my-custom-network --subnet-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 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 VPC que você criar, na qual será criada uma sub-rede personalizada.
  • 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 VPC existente, convém escolher um intervalo diferente.

Configurar regras de firewall

As instâncias nessa rede 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. Insira um Nome, como allow-all-10-128-0-0-20.
  4. Defina Rede 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. Defina Rede 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 usa grupos de instâncias gerenciadas com base nos modelos de instância. No entanto, a configuração aqui apresentada é 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 de VMs" no Console do Google Cloud Platform.
    Acessar a página "Instâncias de VMs"
  2. Clique em Criar instância.
  3. Defina Nome como ig-us-central1-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, clique em Rede e preencha o campo Tags com int-lb.
  7. Em Rede, edite a interface de rede em Interfaces de rede.
  8. Em Rede, defina Rede como my-custom-network e Sub-rede como my-custom-subnet.
  9. Deixe os valores padrão no restante dos campos.
  10. Clique em Gerenciamento e 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
  11. Crie ig-us-central1-2 com as mesmas configurações, exceto pelo 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 pela Zona definida como us-central1-c e pelo 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 pela Zona definida como us-central1-c e pelo 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 Tipo de grupo, selecione Grupo de instâncias não gerenciadas.
  6. Defina Rede 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. Não altere as outras configurações.
  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 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. Defina Rede 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 outra 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 de front-end.
  2. Em Sub-rede, selecione my-custom-subnet.
  3. Em IP interno, selecione Ephemeral (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âncias 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, seja qual for a 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 este comando não especifica um endereço IP para o balanceador de carga, é atribuído um automaticamente. Caso você queira especificar um balanceador, selecione qualquer endereço que não seja usado na região e na rede 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. Defina Rede 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. Defina Rede 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 IP 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 de cliente autônoma

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

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 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 Rede, preencha o campo de Tags de rede com standalone.
  7. Em Rede, edite a interface de rede. Defina Rede 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

Excluir os endereços IP externos das instâncias

Quando você criou as instâncias para os grupos de instâncias, elas precisavam de IPs externos para que fosse possível fazer o download e a instalação do Apache. Agora que o Apache está instalado e essas instâncias atendem a um balanceador de carga interno, elas não precisam mais de acesso à Internet. Sendo assim, você pode remover os endereços IP externos das instâncias.

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 ig-us-central1-1 para buscar o console dessa instância.
  3. Clique em Editar.
  4. Expanda "Interfaces de rede". 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 de 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 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 regras de encaminhamento, serviços de back-end e recursos de verificação de integridade iguais aos do balanceamento de carga HTTP(S), mas com alguns parâmetros de comando novos. Nesta seção, você verá apenas esses novos parâmetros. Os parâmetros existentes são explicados na referência da ferramenta de linha de comando gcloud.

Regra de encaminhamento

No balanceamento de carga interno, a regra de encaminhamento aponta diretamente para um serviço de back-end na mesma região que essa regra. Nesta seção, você encontra a descrição dos 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 para 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: no balanceamento de carga interno, este parâmetro precisa ser especificado como internal. Inicialmente, ele só é compatível com balanceamento de carga interno.
  • --address: o endereço IP de destino do balanceador de carga interno. Quando o esquema do balanceamento de carga é internal, 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 em que a regra de encaminhamento é criada. Regras de encaminhamento global não são compatíveis com balanceamento de carga interno.
  • --protocol (padrão: tcp): o protocolo tcp ou udp processado pelo balanceador de carga interno.
  • --ports: um parâmetro que permite especificar 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 a que essa regra de encaminhamento se aplica. Quando configurado para balanceamento de carga interno, o IP interno da regra de encaminhamento é atribuído com base nessa sub-rede. Se a rede estiver em modo de sub-rede automático, a sub-rede será opcional porque poderá ser determinada com base na região. No entanto, se a rede estiver em modo de sub-rede personalizado, será necessário especificar uma sub-rede. 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 a que esta regra de encaminhamento se aplica. Quando configurado para balanceamento de carga interno, o IP interno da regra de encaminhamento é atribuído com base nessa rede. Se esse campo não for especificado, será usada a rede padrão. Na ausência dela, é necessário especificar esse campo.

Definir o destino de uma regra de encaminhamento

O comando forwarding-rules set-target permite alterar o serviço de back-end ao qual é direcionada a regra de encaminhamento. No 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 comando gcloud dos serviços de back-end 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 (obrigatório): especifica se o balanceador de carga está fazendo balanceamento de carga interno ou externo. Esta versão só é compatível com balanceamento de carga interno. É necessário um valor internal.
  • --region (obrigatório): a região em que reside o serviço de back-end. No balanceamento de carga interno, as instâncias, os grupos de instâncias, o serviço de back-end, o serviço de balanceador de carga e as instâncias cliente precisam estar na mesma região da rede, mas não precisam estar na mesma zona ou sub-rede.
  • --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á. Este parâmetro precisa corresponder ao parâmetro --protocol especificado para a regra de encaminhamento. O protocolo é obrigatório para serviços de back-end com 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 especificada, novas conexões para o balanceador de carga da mesma instância serão distribuídas uniformemente 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 ver 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 é compatível com balanceamento de carga interno. Faz o balanceamento 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, seja qual for a 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 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. Esta é 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.
  • Estes 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: os comandos 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 na sondagem de verificação de integridade para que uma instância íntegra seja marcada como UNHEALTHY.

Regras de firewall e endereços IP de origem da verificação de integridade

No balanceamento de carga interno, as sondagens de verificação de integridade para as instâncias com carga balanceada são provenientes de endereços nos intervalos 130.211.0.0/22 e 35.191.0.0/16. Esses são os intervalos de endereços IP que o balanceador de carga usa para se conectar a instâncias de back-end. É 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.

Se for necessário determinar endereços IP externos em determinado momento, use as instruções nas Perguntas frequentes do Google Compute Engine.

Balanceamento de carga interno com grupos de instâncias regionais

É possível usar o balanceamento de carga interno com grupos de instâncias regionais. Os comandos gcloud estão listados a seguir.

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

Monitoring

O balanceamento de carga interno exporta dados de monitoramento para o Stackdriver. As métricas de monitoramento podem ser usadas para avaliar a configuração, o uso e o desempenho do balanceador de carga interno, solucionar problemas e melhorar a utilização dos recursos e a experiência do usuário. Além dos painéis predefinidos no Stackdriver, você pode criar painéis personalizados, configurar alertas e consultar as métricas por meio da Stackdriver Monitoring API.

Como visualizar os painéis de monitoramento do Stackdriver

  1. Acesse o Stackdriver no Console do Google Cloud Platform.
    Ir para o Stackdriver
  2. Selecione Recursos > Balanceadores de carga do Google Cloud.
  3. Clique no nome de seu balanceador de carga.

No painel esquerdo, há vários detalhes do balanceador de carga interno. No painel direito, há gráficos de séries temporais. Clique no link Detalhamentos para ver os detalhes específicos. O painel esquerdo apresenta dados atualmente configurados, enquanto o painel direito mostra dados veiculados por configurações históricas, não refletidas no painel esquerdo.

Como definir alertas do Stackdriver

Você pode definir alertas do Stackdriver em várias métricas do balanceamento de carga interno:

  1. Acesse o Stackdriver no console do Google Cloud Platform.
    Ir para o Stackdriver
  2. Selecione Alertas > Criar uma política.
  3. Clique em Adicionar condição e selecione o tipo de condição.
  4. Selecione as métricas e os filtros. Para métricas, o tipo de recurso é Balanceador de carga TCP interno ou Balanceador de carga UDP interno.
  5. Clique em Salvar condição.
  6. Digite o nome da política e clique em Salvar política.

Como definir os painéis personalizados do Stackdriver

Você pode criar painéis personalizados do Stackdriver com as métricas de balanceamento de carga interno:

  1. Acesse o Stackdriver no console do Google Cloud Platform.
    Ir para o Stackdriver
  2. Selecione Painéis > Criar Painel.
  3. Clique em Adicionar gráfico.
  4. Dê um título ao gráfico.
  5. Selecione as métricas e os filtros. Para métrica, o tipo de recurso é Regra do balanceador de carga TCP do Google Cloud (interno) (internal_tcp_lb_rule) ou Regra do balanceador de carga UDP do Google Cloud (interno) (internal_udp_lb_rule).
  6. Clique em Salvar.

Métricas para balanceadores de carga internos

No Stackdriver, as seguintes métricas para balanceadores de carga internos são geradas:

Métrica Descrição
Taxa de transferência de entrada O número de bytes enviados para as regras de encaminhamento do balanceador de carga interno, conforme recebidas pelos back-ends.
Pacotes de entrada O número de pacotes enviados para as regras de encaminhamento do balanceador de carga interno, conforme recebidas pelos back-ends.
Taxa de transferência de saída O número de bytes enviados por back-ends internos da carga balanceada em conexões vinculadas a IPs de regra de encaminhamento.
Pacotes de saída O número de pacotes enviados por back-ends internos da carga balanceada em conexões vinculadas a IPs de regra de encaminhamento.
Latência(*) Uma distribuição por pacotes do RTT medido para grupos de pacotes sobre cada conexão interna de carga balanceada. Normalmente, reduzida para o 95º percentil nas visualizações do Stackdriver.

(*) Disponível apenas para tráfego TCP.

Como filtrar dimensões das métricas do balanceador de carga interno

As métricas são agregadas para cada balanceador de carga interno. Elas podem ser detalhadas nas seguintes dimensões:

Propriedade Descrição
GRUPO DE INSTÂNCIAS O nome do grupo de instâncias que recebeu a conexão.
ESCOPO DO BACK-END O escopo (região ou zona) do grupo de instâncias que recebeu a conexão.
ZONA DO BACK-END A zona do grupo de instâncias que veiculou a conexão, em caso de grupo classificado por zona.
REDE DE CLIENTES A rede a partir da qual a instância conectada ao balanceamento de carga interno envia tráfego.
SUB-REDE DO CLIENTE A sub-rede a partir da qual a instância conectada ao balanceamento de carga interno envia tráfego.
ZONA DO CLIENTE A zona do Google Cloud Platform da instância que se conectou à regra de encaminhamento do balanceamento de carga interno.
REGRA DE ENCAMINHAMENTO O nome da regra de encaminhamento usada pela instância para se conectar ao balanceador de carga interno.

Frequência e retenção de relatórios de métricas

As métricas dos balanceadores de carga internos são exportadas para o Stackdriver em lotes com granularidade de um minuto. Os dados de monitoramento são retidos por seis semanas. O painel fornece análise de dados em intervalos padrão de uma hora, seis horas, um dia, uma semana e seis semanas. Você pode solicitar análises manualmente em qualquer intervalo de seis semanas a um minuto.

Como solucionar problemas de acesso do balanceamento de carga interno por VPN e interconexão

O acesso do balanceamento de carga interno por VPN e interconexão combina dois produtos do GCP. Para isolar qualquer problema, recomendamos que você primeiro tente acessar o balanceador de carga interno de uma instância de VM cliente do GCP na mesma rede e na mesma região que o túnel de VPN.

Se você conseguir acessar o balanceador de carga interno da instância de VM cliente, verifique no restante desta seção alguns problemas comuns que você pode encontrar.

Problemas de VPN

Se você encontrar algum problema de VPN quando acessar o balanceamento de carga interno por VPN, leia o Guia de solução de problemas do Cloud VPN.

Problema de roteamento global

O balanceamento de carga interno é um produto regional. Todas as instâncias de VM cliente e de back-end, assim como túneis de VPN, precisam estar na mesma região.

Por esse motivo, há perda do acesso do balanceamento de carga interno quando o roteamento global usa um túnel fora da região de balanceamento de carga interno.

Isso ocorre porque o roteamento global pode ser configurado com túneis locais que estão dentro ou fora da região de balanceamento de carga interno. Se o túnel local for configurado com uma prioridade mais alta ou nenhuma prioridade for especificada, o túnel local terá preferência, o que permite o acesso do balanceamento de carga interno. No entanto, se o túnel local falhar, todo o tráfego será roteado para o túnel remoto e o acesso do balanceamento de carga interno será perdido.

UDP e MTU

Se grandes pacotes UDP forem descartados ao acessar o balanceamento de carga interno por VPN, significa que o Path MTU Discovery (PMTUD) não é compatível com o UDP.

Para corrigir este problema, verifique se o MTU da interface está configurado de modo a levar em consideração a sobrecarga de IPSec da conta e o MTU de 1.460 da instância de VM do GCP.

O peering VPC não é compatível

Se os clientes locais não conseguirem acessar um balanceador de carga interno com peering, significa que o peering VPC não é compatível com acesso à VPN. Você não poderá usar esses recursos juntos.

Restrições

  • O IP do balanceador de carga interno não pode ser o IP do próximo salto 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.
  • Os clientes em uma região não podem acessar um balanceador de carga interno em outra região. Todas as instâncias na configuração do balanceamento de carga interno precisam pertencer à mesma rede e à mesma região de VPC, mas podem estar em sub-redes diferentes.

Limites

  • São permitidas, no máximo, 50 regras de encaminhamento do balanceador de carga interno por rede.

  • São permitidos, no máximo, 250 back-ends 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 tráfego TCP e UDP.

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

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

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

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Compute Engine