1. Introdução
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.
O que você vai aprender
- Entenda os benefícios dos serviços de back-end regionais
- crie 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
- Executar o pool de destino para a migração do serviço de back-end
- Realizar a validação dos 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 controle do comportamento do balanceador de carga para os clientes, adicionamos recentemente o suporte a serviços de back-end no balanceamento de carga de rede. Isso proporciona aos nossos clientes maior escala, velocidade, desempenho e resiliência na implantação, tudo de uma forma 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
A escolha de um serviço de back-end regional como balanceador de carga traz uma série de 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 é possível aproveitar ao máximo os recursos de verificação de integridade de balanceamento de carga, libertando-se das restrições das verificações de integridade HTTP legadas. Por motivos de conformidade, as verificações de integridade TCP com suporte para strings de solicitação e resposta personalizadas ou HTTPS eram uma solicitação comum para clientes de balanceamento de carga de rede.
- Melhor resiliência com grupos de failover: com os grupos de failover, é possível designar um grupo de instâncias como primário e outro como secundário e fazer o 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 as 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 tradicional baseado em pool de destino 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 tiver mais do que o número máximo de instâncias, você precisará 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 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á preciso 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 sinalização –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. Isso exige que você crie 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 antigo balanceador de carga baseado em pool de destino para o novo.
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 avaliação 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 cloudshell e defina seu projectid
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 (link em inglês)
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"
No Cloud Shell, crie a instância 3
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"
No Cloud Shell, crie a instância 4
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"
Criar 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
Crie 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 suas 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. 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 a partir de 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
Criar 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
Configure seu serviço de back-end e adicione 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 aos serviços de back-end
Anote o nome da regra de encaminhamento "www-rule" e o endereço IP associado da seguinte forma:
Selecione "Balanceador de carga → Front-ends"
Além disso, notamos que os quatro pools de destino
Selecione "Balanceador de carga" → "www-pool"
Rotear 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
Verificar 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".
A regra de encaminhamento de validação de front-end agora está associada ao balanceador de carga "my-backend-service"
Selecione "Balanceador de carga → Front-ends"
Anote o nome da regra "www-rule" O endereço IP é mantido e o balanceador de carga "my-backend-service" já 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
- Entenda os benefícios dos serviços de back-end regionais
- crie 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
- Executar o pool de destino para a migração do serviço de back-end
- Realizar a validação dos serviços de back-end