1. Introdução
Neste guia, você vai encontrar instruções para fazer a transição de um balanceador de carga de rede atual de um back-end de pool de destino para um serviço de back-end regional.
O que você vai aprender
- Entenda os benefícios dos serviços de back-end regionais
- Criar um balanceador de carga de rede com pools de destino
- Realizar a validação do pool de destino
- Criar um serviço de back-end regional usando grupos de instâncias não gerenciadas
- Realizar a migração do pool de destino para o serviço de back-end
- Executar a validação de serviços de back-end
O que é necessário
- Experiência com balanceadores de carga
2. Visão geral dos serviços de back-end regionais para balanceamento de carga de rede
Com o balanceamento de carga de rede, os clientes do Google Cloud têm uma ferramenta poderosa para distribuir tráfego externo entre máquinas virtuais em uma região do Google Cloud. Para facilitar o gerenciamento do tráfego de entrada e o comportamento do balanceador de carga, adicionamos recentemente o suporte a serviços de back-end ao balanceamento de carga de rede. Isso melhora a escala, a velocidade, o desempenho e a resiliência para os clientes na implantação, tudo de maneira fácil de gerenciar.
Agora oferecemos suporte a serviços de back-end com o balanceamento de carga de rede, uma melhoria significativa em relação à abordagem anterior, os pools de destino. Um serviço de back-end define como nossos balanceadores de carga distribuem o tráfego de entrada para os back-ends anexados e fornece controle refinado sobre o comportamento do balanceador de carga.
3. Benefícios dos serviços de back-end regionais
Escolher um serviço de back-end regional como balanceador de carga traz várias vantagens para seu ambiente.
Os serviços de back-end regionais oferecem:
- Verificação de integridade de alta fidelidade com verificação de integridade unificada: com os serviços de back-end regionais, agora você pode aproveitar ao máximo os recursos de verificação de integridade do balanceamento de carga, sem as restrições das verificações de integridade HTTP legadas. Por motivos de conformidade, as verificações de integridade do TCP com suporte a strings de solicitação e resposta personalizadas ou HTTPS eram uma solicitação comum para clientes do balanceamento de carga de rede.
- Melhor resiliência com grupos de failover: com eles, é possível designar um grupo de instâncias como principal e outro como secundário e fazer failover do tráfego quando a integridade das instâncias no grupo ativo fica abaixo de um determinado limite. Para ter mais controle sobre o mecanismo de failover, é possível usar um agente como keepaculture ou pacemaker e expor uma verificação de integridade íntegra ou com falha com base nas alterações de estado da instância de back-end.
- Escalonabilidade e alta disponibilidade com grupos de instâncias gerenciadas: os serviços de back-end regionais dão suporte aos grupos gerenciados de instâncias como back-ends. Agora é possível especificar um modelo para suas instâncias de máquina virtual de back-end e aproveitar o escalonamento automático com base na utilização da CPU ou em outras métricas de monitoramento.
Além disso, você poderá aproveitar a drenagem de conexão para protocolo orientado à conexão (TCP) e tempo de programação mais rápido para grandes implantações.
Topologia de rede do codelab
Este guia fornece instruções para a transição de um balanceador de carga de rede existente de um back-end de pool de destino para um serviço de back-end regional.
Ao migrar para um serviço de back-end regional, você aproveita recursos como verificações de integridade não legadas (para TCP, SSL, HTTP, HTTPS e HTTP/2), grupos gerenciados de instâncias, diminuição de conexão e política de failover.
Neste guia, explicamos como fazer a transição do seguinte exemplo de balanceador de carga de rede baseado em pool de destino para usar um serviço de back-end regional
Antes: balanceamento de carga de rede com um pool de destino
A implantação resultante do balanceador de carga de rede baseado em serviço de back-end será semelhante a esta.
Depois:balanceamento de carga de rede com um serviço de back-end regional
Neste exemplo, presumimos que você tenha um balanceador de carga de rede baseado em pool de destino tradicional com duas instâncias na zona us-central-1a e duas instâncias na zona us-central-1c.
As etapas gerais necessárias para essa transição são:
- Agrupe as instâncias do pool de destino em grupos de instâncias. Os serviços de back-end funcionam somente com grupos de instâncias gerenciadas ou não gerenciadas. Embora não haja limite para o número de instâncias que podem ser colocadas em um único pool de destino, os grupos de instâncias têm um tamanho máximo. Se o pool de destino tem mais do que o número máximo de instâncias, você precisa dividir os back-ends em vários grupos de instâncias. Se a implantação atual incluir um pool de destino de backup, crie um grupo de instâncias separado para essas instâncias. Este grupo de instâncias será configurado como um grupo de failover.
- Criar um serviço de back-end regional Se a implantação incluir um pool de destino de backup, será necessário especificar uma proporção de failover ao criar o serviço de back-end. Ela precisa corresponder à proporção de failover configurada anteriormente para a implantação do pool de destino.
- Adicione grupos de instâncias (criados anteriormente) ao serviço de back-end. Se a implantação incluir um pool de destino de backup, marque o grupo de instâncias de failover correspondente com uma flag –failover ao adicioná-lo ao serviço de back-end.
- Configure uma regra de encaminhamento que aponte para o novo serviço de back-end. Você tem duas opções:
- (Recomendado) Atualize a regra de encaminhamento atual para apontar para o serviço de back-end. OU
- Crie um novo encaminhamento que aponte para o serviço de back-end. Para isso, você precisa criar um novo endereço IP para o front-end do balanceador de carga. Em seguida, modifique as configurações de DNS para fazer a transição do endereço IP do balanceador de carga baseado em pool de destino para o novo endereço IP.
Configuração de ambiente autoguiada
- Faça login no console do Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.
Lembre-se do código do projeto, um nome exclusivo em todos os projetos do Google Cloud. O nome acima já foi escolhido e não servirá para você. Faremos referência a ele mais adiante neste codelab como PROJECT_ID.
- Em seguida, será necessário ativar o faturamento no Console do Cloud para usar os recursos do Google Cloud.
A execução deste codelab não será muito cara, se for o caso. Siga todas as instruções na seção "Limpeza", que orienta você sobre como encerrar recursos para não incorrer em cobranças além deste tutorial. Novos usuários do Google Cloud estão qualificados para o programa de US$300 de teste sem custo financeiro.
Inicie o Cloud Shell
Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.
No Console do GCP, clique no ícone do Cloud Shell na barra de ferramentas localizada no canto superior direito:
O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:
Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Todo o trabalho neste laboratório pode ser feito apenas com um navegador.
Faça login no Cloud Shell e defina o ID do projeto
gcloud config list project gcloud config set project [YOUR-PROJECT-ID] Perform setting your projectID: projectid=YOUR-PROJECT-ID echo $projectid
4. Criar rede VPC
Rede VPC
No Cloud Shell
gcloud compute networks create network-lb --subnet-mode custom
Criar sub-rede
No Cloud Shell
gcloud compute networks subnets create network-lb-subnet \
--network network-lb --range 10.0.0.0/24 --region us-central1
Criar regras de firewall
No Cloud Shell
gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag
Criar instâncias não gerenciadas
Crie duas instâncias por zona, us-central1-a e us-central1-c
No Cloud Shell, crie a instância 1
gcloud compute instances create www1 \ --subnet network-lb-subnet \ --image-family debian-9 \ --image-project debian-cloud \ --zone us-central1-a \ --tags network-lb-tag \ --metadata startup-script="#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo service apache2 restart echo '<!doctype html><html><body><h1>www1</h1></body></html>' | tee /var/www/html/index.html"
No Cloud Shell, crie a instância 2
gcloud compute instances create www2 \ --subnet network-lb-subnet \ --image-family debian-9 \ --image-project debian-cloud \ --zone us-central1-a \ --tags network-lb-tag \ --metadata startup-script="#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo service apache2 restart echo '<!doctype html><html><body><h1>www2</h1></body></html>' | tee /var/www/html/index.html"
Crie a instância 3 no Cloud Shell
gcloud compute instances create www3 \ --subnet network-lb-subnet \ --image-family debian-9 \ --image-project debian-cloud \ --zone us-central1-c \ --tags network-lb-tag \ --metadata startup-script="#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo service apache2 restart echo '<!doctype html><html><body><h1>www3</h1></body></html>' | tee /var/www/html/index.html"
Crie a instância 4 no Cloud Shell
gcloud compute instances create www4 \ --subnet network-lb-subnet \ --image-family debian-9 \ --image-project debian-cloud \ --zone us-central1-c \ --tags network-lb-tag \ --metadata startup-script="#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo service apache2 restart echo '<!doctype html><html><body><h1>www4</h1></body></html>' | tee /var/www/html/index.html"
Crie uma regra de firewall para permitir o tráfego externo para essas instâncias de VM
No Cloud Shell
gcloud compute --project=$projectid firewall-rules create www-firewall-network-lb --direction=INGRESS --priority=1000 --network=network-lb --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 --target-tags=network-lb-tag
Criar um endereço IP externo estático para o balanceador de carga
No Cloud Shell
gcloud compute addresses create network-lb-ip-1 \
--region us-central1
Adicionar um recurso legado de verificação de integridade HTTP
No Cloud Shell
gcloud compute http-health-checks create basic-check
5. Criar regra de encaminhamento e pool de destino
Criar um pool de destino
gcloud compute target-pools create www-pool \
--region us-central1 --http-health-check basic-check
Adicione as instâncias ao pool de destino, us-central1-a
gcloud compute target-pools add-instances www-pool \ --instances www1,www2 \ --instances-zone us-central1-a
Adicione suas instâncias ao pool de destino, us-central1-c
gcloud compute target-pools add-instances www-pool \ --instances www3,www4 \ --instances-zone us-central1-c
Adicionar uma regra de encaminhamento
gcloud compute forwarding-rules create www-rule \ --region us-central1 \ --ports 80 \ --address network-lb-ip-1 \ --target-pool www-pool
Validar a funcionalidade do pool de destino
Identifique o endereço IP do front-end selecionando "Balanceadores de carga" → "Front-ends" (www-rule).
Use o comando curl no terminal da estação de trabalho para acessar o endereço IP externo e observar o balanceamento de carga nas quatro instâncias de destino. Feche o terminal após a validação.
while true; do curl -m1 IP_ADDRESS; done
6. Fazer a transição do balanceador de carga de rede do pool de destino para o serviço de back-end
Criar verificações de integridade unificadas para seu serviço de back-end
gcloud compute health-checks create tcp my-tcp-health-check --port 80 --region us-central1
Criar grupos de instâncias com base em instâncias atuais do pool de destino
gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1a --zone=us-central1-a gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1a --zone=us-central1-a --instances=www1,www2
Crie grupos de instâncias a partir de instâncias atuais do pool de destino
gcloud compute --project=$projectid instance-groups unmanaged create www-instance-group-central1c --zone=us-central1-c gcloud compute --project=$projectid instance-groups unmanaged add-instances www-instance-group-central1c --zone=us-central1-c --instances=www3,www4
Criar um serviço de back-end e associá-lo às verificações de integridade recém-criadas
gcloud compute backend-services create my-backend-service --region us-central1 --health-checks my-tcp-health-check --health-checks-region us-central1 --load-balancing-scheme external
Configurar o serviço de back-end e adicionar os grupos de instâncias
gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1a --instance-group-zone us-central1-a --region us-central1 gcloud compute backend-services add-backend my-backend-service --instance-group www-instance-group-central1c --instance-group-zone us-central1-c --region us-central1
Atualizar a regra de encaminhamento atual para oferecer suporte a serviços de back-end
Anote o nome da regra de encaminhamento "www-rule" e o endereço IP associado fazendo o seguinte:
Selecione "Balanceador de carga → Front-ends"
Além disso, observei os quatro pools de destino
Selecione "Balanceador de carga" → "www-pool"
Roteie o tráfego para serviços de back-end atualizando a regra de encaminhamento atual
gcloud compute forwarding-rules set-target www-rule --region=us-central1 --backend-service my-backend-service --region us-central1
Verifique se o balanceador de carga "www-pool" não está mais configurado com o front-end "www-rule" (confira a captura de tela abaixo)
Selecione "Balanceador de carga" → "www-pool"
Validar que a regra de encaminhamento do front-end agora está associada ao balanceador de carga "my-backend-service"
Selecione "Balanceador de carga" → "Front-ends"
O endereço IP do nome da regra "www-rule" é mantido, e o balanceador de carga "my-backend-service" está em uso
Use o comando curl no terminal da estação de trabalho para acessar o endereço IP externo e observar o balanceamento de carga no serviço de back-end recém-associado. Feche o terminal após a validação.
while true; do curl -m1 IP_ADDRESS; done
7. Etapas de limpeza
gcloud compute forwarding-rules delete www-rule --region=us-central1 --quiet gcloud compute backend-services delete my-backend-service --region us-central1 --quiet gcloud compute target-pools delete www-pool --region us-central1 --quiet gcloud compute addresses delete network-lb-ip-1 --region us-central1 --quiet gcloud compute firewall-rules delete www-firewall-network-lb --quiet gcloud compute instances delete www4 --zone us-central1-c --quiet gcloud compute instances delete www3 --zone us-central1-c --quiet gcloud compute instances delete www2 --zone us-central1-a --quiet gcloud compute instances delete www1 --zone us-central1-a --quiet gcloud compute networks subnets delete network-lb-subnet --region us-central1 --quiet gcloud compute networks delete network-lb --quiet gcloud compute instance-groups unmanaged delete www-instance-group-central1a --zone us-central1-a --quiet gcloud compute instance-groups unmanaged delete www-instance-group-central1c --zone us-central1-c --quiet
8. Parabéns!
Parabéns por concluir o codelab.
O que vimos
- Entender os benefícios dos serviços de back-end regionais
- Criar um balanceador de carga de rede com pools de destino
- Realizar a validação do pool de destino
- Criar um serviço de back-end regional usando grupos de instâncias não gerenciadas
- Realizar a migração do pool de destino para o serviço de back-end
- Realizar a validação de serviços de back-end