Exercício – identificar e resolver a conectividade de rede de entrada
Em nosso cenário, foi feita uma alteração na configuração de rede. Você está recebendo alertas informando que as máquinas virtuais no pool de back-end não estão respondendo a investigações de integridade. Agora você precisa diagnosticar a causa dessas falhas e corrigi-las.
Neste exercício, você usa um script para reconfigurar o ambiente e causar falhas na investigação de integridade. Você usa as habilidades aprendidas neste módulo para fazer com que o serviço HTTP com balanceamento de carga volte a funcionar plenamente.
Reconfigurar o balanceador de carga e testar novamente
No Azure Cloud Shell, defina o nome do grupo de recursos.
export RESOURCEGROUP=learn-ts-loadbalancer-rg
Vá para a pasta src/scripts.
cd ~/load-balancer/src/scripts
Execute o comando a seguir para reconfigurar o balanceador de carga, a rede e as máquinas virtuais. Esse script apresenta alguns problemas que você diagnosticará e corrigirá.
bash reconfigure.sh
Execute os comandos a seguir para mover para a pasta src/stresstest.
cd ~/load-balancer/src/stresstest
Execute o teste de estresse novamente, em que você substitui <ip address> pelo endereço IP do balanceador de carga. Se você não consegue se lembrar desse endereço, execute o script src/scripts/findip.sh novamente.
dotnet run <ip address>
Desta vez, o aplicativo não gerará nenhuma saída e, eventualmente, poderá passar do tempo com a mensagem "Erro ao enviar solicitação para Load Balancer: a operação foi cancelada". Pressione Enter para interromper o aplicativo.
No portal do Azure, selecione Painel>dashboard-learn-ts-loadbalancer.
Examine o painel que mostra o status da investigação de integridade e a disponibilidade do caminho de dados. Talvez seja necessário alterar o intervalo de tempo para os últimos 30 minutos. Ele deve ser semelhante ao seguinte gráfico, com ambas as métricas reduzidas a zero.
Este gráfico mostra que as máquinas virtuais não estão respondendo às solicitações de investigação de integridade do balanceador de carga. Assim, elas foram marcadas como não íntegras. Não há nenhum caminho de dados disponível entre um cliente e o aplicativo em execução nessas máquinas virtuais.
Diagnosticar e corrigir problemas
A primeira etapa é verificar se as máquinas virtuais estão em execução. Vamos resolver problemas de uma máquina virtual por vez. Vamos examinar appretailvm1 primeiro. Você examinará appretailvm2 mais tarde.
Testar a máquina virtual appretailvm1
Você não pode executar o ping em máquinas virtuais appretailvm1 ou appretailvm2 diretamente porque elas têm endereços privados que só estão disponíveis para outras máquinas virtuais na mesma sub-rede. Primeiro, você se conecta à jump box, que tem um endereço IP público e está na mesma sub-rede. Em seguida, você poderá executar o ping nas máquinas virtuais daí.
Retorne ao Cloud Shell.
Execute os comandos a seguir para obter o endereço IP da máquina virtual da jump box.
bash ~/load-balancer/src/scripts/jumpboxip.sh
Execute o comando a seguir para obter a senha que você criou ao executar o script de instalação inicial. Copie essa senha para a próxima etapa.
cd ~/load-balancer/src/scripts cat passwd.txt
Faça login na jumpbox com o endereço IP e a senha das saídas de comando anteriores. Substitua azureuser se você tiver usado um nome de usuário diferente.
ssh azureuser@<jump box ip address>
Na jump box, execute o seguinte comando para testar se a máquina virtual retailappvm1 está em execução.
ping retailappvm1 -c 10
A máquina virtual retailappvm1 deve responder, indicando que está em execução. A próxima etapa é estabelecer se o aplicativo Web está em execução nessa máquina virtual.
Execute o seguinte comando para enviar uma solicitação HTTP GET para a máquina virtual retailappvm1.
curl -v http://retailappvm1
Novamente, esse comando deve ser bem-sucedido.
Verificar as regras de roteamento e investigações de integridade
A máquina virtual retailappvm1 está ativa e o aplicativo está em execução nessa máquina virtual. Deve haver um problema entre o balanceador de carga e as máquinas virtuais no pool de back-end.
No portal do Azure, pesquise Monitor.
Na página Monitor – Visão Geral, selecione Integridade do Serviço.
Selecione Resource Health.
Na caixa Tipo de recurso, selecione Balanceador de carga. Na lista de recursos, selecione retailapplb.
Aguarde alguns minutos até que a integridade do balanceador de carga seja avaliada.
Em Histórico de integridade, expanda o evento de nível mais alto e examine as etapas recomendadas. Estas etapas sugerem a verificação dos pontos de extremidade VIP (regra de roteamento) e DIP (investigação de integridade) no balanceador de carga.
Vá para o grupo de recursos saiba-ts-balancer-rg e selecione retailapplb.
Selecione Regras de balanceamento de carga>retailapprule. Essa regra recebe o tráfego TCP na porta 80 do endereço IP de front-end e o envia para a porta 80 na máquina virtual selecionada no pool de back-end. Essa configuração parece estar correta, embora a porta usada pela investigação de integridade pareça suspeita. Ela está definida atualmente como a porta 85.
Feche a página retailapprule.
Selecione Investigações de integridade>retailapphealthprobe.
Altere a Porta de 85 de volta para 80 e, em seguida, selecione Salvar.
Aguarde alguns minutos.
Selecione Painel no menu à esquerda do portal do Azure.
No painel, selecione o gráfico mostrando o Status da Investigação de Integridade e as métricas de Disponibilidade do Caminho de Dados. A métrica Disponibilidade do Caminho de Dados deve subir para 100, mas a métrica Status da Investigação de Integridade ficará em torno de 50. Agora há um caminho disponível do balanceador de carga para pelo menos uma máquina virtual, mas somente 50% das máquinas virtuais são mostrados como íntegras.
Selecione o gráfico para acessar a página de métricas do Load Balancer. Essa página permite que você atualize o gráfico e amplie-o em um período de tempo específico.
No Cloud Shell, execute o comando a seguir para sair da jump box.
exit
Execute o aplicativo de teste de estresse novamente usando o endereço IP do balanceador de carga.
cd ~/load-balancer/src/stresstest dotnet run <ip address>
Como antes, o teste ainda falha. Agora há um caminho do balanceador de carga até pelo menos uma máquina virtual, mas esse caminho não funciona em um cliente em execução fora da rede virtual. Pressione Enter para interromper o aplicativo de teste de estresse.
Verificar as regras do NSG para a sub-rede
O problema pode ser causado por uma regra de segurança de rede bloqueando o tráfego externo.
No portal do Azure, vá para o grupo de recursos learn-ts-loadbalancer-rg.
Selecione o grupo de segurança de rede retailappnsg. Esse grupo de segurança determina qual tráfego é permitido por meio da rede virtual.
Selecione Regras de segurança de entrada. Embora haja uma regra que permita o tráfego de entrada do balanceador de carga em execução na rede virtual, não há nenhuma regra que permita o tráfego originado de fora da rede virtual pela porta 80.
Selecione Adicionar. O painel Adicionar regra de segurança de entrada é exibido.
Insira as seguintes configurações e, em seguida, selecione Adicionar.
Propriedade Valor Fonte Qualquer Intervalos de portas de origem * Destino Qualquer Serviço Personalizado Intervalos de portas de destino 80 Protocolo TCP Ação Permitir Prioridade 100 Nome Port_80 Descrição Porta HTTP No Cloud Shell, execute o aplicativo de teste de estresse novamente usando o endereço IP do balanceador de carga.
cd ~/load-balancer/src/stresstest dotnet run <ip address>
Agora o aplicativo é executado, mas você só recebe uma resposta da máquina virtual retailappvm1. Permita que o aplicativo seja executado por dois ou três minutos. Pressione Enter para interrompê-lo.
No portal do Azure, acesse o painel.
Selecione o gráfico para a métrica de Contagem de Pacotes média. Observe o valor de pico para a última execução do aplicativo de teste de estresse. Esse valor deve ser pelo menos o dobro do valor registrado anteriormente quando ambas as máquinas virtuais estavam disponíveis. Embora agora você tenha um sistema em funcionamento, você está em perigo de sobrecarregar a máquina virtual em operação.
Testar a máquina virtual appretailvm2
Parece que a máquina virtual appretailvm2 pode não estar manipulando solicitações corretamente. Você precisa verificar se essa máquina virtual está ativa e se o Load Balancer pode se conectar a ela.
No Cloud Shell, faça login na jumpbox com o endereço IP e a senha das saídas de comando anteriores
ssh azureuser@<jump box ip address>
Tente executar ping na máquina virtual appretailvm2.
ping retailappvm2 -c 10
A máquina virtual não responderá, e o comando ping relatará 100% de perda de pacotes. A máquina virtual retailappvm2 não está em execução ou há um problema de rede.
No portal do Azure, acesse o grupo de recursos learn-ts-loadbalancer-rg.
Selecione a máquina virtual retailappvm2.
A página Visão geral mostra que a máquina virtual foi interrompida. Selecione Iniciar e aguarde até que o computador comece a ser executado.
Volte para o Cloud Shell conectado à jump box e repita o comando ping.
ping retailappvm2 -c 10
Desta vez, as operações de ping devem ter sucesso.
Teste se o aplicativo em execução na máquina virtual retailappvm2 responde.
wget retailappvm2
Esse comando atinge o tempo limite. O aplicativo não está em execução ou pode haver um problema de rede. Selecione Ctrl+C para interromper o comando.
Na jump box, entre na máquina virtual retailappvm2. Quando solicitado, insira a mesma senha especificada antes.
ssh azureuser@retailappvm2
Execute o seguinte comando para testar o aplicativo nessa máquina virtual.
wget retailappvm2
O comando deve ser bem-sucedido e criar o arquivo index.html, que contém a resposta.
Examine este arquivo index.html.
cat index.html
O arquivo deve conter a mensagem retailappvm2 e mostrar que essa máquina virtual respondeu conforme o esperado.
Feche a conexão com a máquina virtual retailappvm2.
exit
Feche a conexão com a jump box.
exit
A máquina virtual retailappvm2 está funcionando e o aplicativo está em execução, mas você não pode se conectar ao aplicativo de fora da máquina virtual. Esse problema sugere um problema de rede.
No portal do Azure, vá para o grupo de recursos learn-ts-loadbalancer-rg.
Selecione o grupo de segurança de rede retailappnicvm2nsg.
Selecione Regras de segurança de entrada.
O grupo de segurança de rede tem uma regra de entrada que bloqueia todo o tráfego externo usando o protocolo TCP. Essa regra tem um número de prioridade inferior à regra (que abre a porta 80), portanto, tem precedência.
Selecione a regra retailappvnetnsgrulevm2denyall, altere a prioridade para 300 e, em seguida, selecione Salvar.
Aguarde dois minutos e acesse o Painel.
Selecione o gráfico que mostra a métrica Status da Investigação de Integridade. O valor dessa métrica deve subir para 100. Talvez seja necessário atualizar o gráfico algumas vezes.
Alterne para o Cloud Shell e execute o aplicativo stresstest novamente usando o endereço IP do balanceador de carga.
cd ~/load-balancer/src/stresstest dotnet run <ip address>
Agora você deve ver mensagens de retailappvm1 e retailappvm2. Você restaurou a conectividade completa com o sistema.
Pressione Enter para interromper o aplicativo.
Resumo
No início deste exercício, você viu que as máquinas virtuais não estavam respondendo às solicitações de investigação de integridade do balanceador de carga. Você descobriu e resolveu uma combinação de problemas de investigação e caminho de dados:
- Na regra retailapprule do balanceador de carga, a porta usada pela investigação de integridade foi configurada incorretamente para usar 85, em vez de 80. Você atualizou a regra para usar a porta 80.
- O grupo de segurança de rede retailappnsg não tinha uma regra de segurança de entrada que permitia tráfego na porta 80. Portanto, o grupo de segurança de rede bloqueou a investigação de integridade. Você adicionou uma regra de segurança de entrada para permitir o tráfego na porta 80.
- Você verificou a VM retailappvm2 e viu que ela parou. Você reiniciou a VM.
- Depois de iniciar a VM retailappvm2 e perceber que o aplicativo estava em execução, você não conseguiu se conectar ao aplicativo. O grupo de segurança de rede tinha uma regra de entrada que bloqueava todo o tráfego de rede para o protocolo TCP. Essa regra "negar tudo" tem precedência sobre a regra de segurança de entrada que permitia o tráfego para a porta 80. Você alterou a prioridade da regra "negar tudo" para que ela fosse maior que a regra da porta 80. Essa alteração permitiu o tráfego de rede de entrada na porta 80 para TCP.
Você retornou o serviço HTTP com balanceamento de carga de volta para a operação completa.