Exercício – Identificar e resolver a conectividade de rede de entrada
No nosso cenário, a configuração de rede foi alterada. Você está recebendo alertas de que as máquinas virtuais no pool de back-end não estão respondendo a testes de integridade. Agora, tem de diagnosticar a causa destas falhas e corrigi-las.
Neste exercício, você usa um script para reconfigurar o ambiente e causar falhas de teste de integridade. Você usa as habilidades aprendidas neste módulo para retornar o serviço HTTP com balanceamento de carga de volta à operação completa.
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
Aceda à pasta src/scripts.
cd ~/load-balancer/src/scripts
Execute o comando seguinte para reconfigurar o balanceador de carga, a rede e as máquinas virtuais. Este script apresenta alguns problemas que você diagnosticará e corrigirá.
bash reconfigure.sh
Execute os seguintes comandos para ir para a pasta src/stresstest.
cd ~/load-balancer/src/stresstest
Execute o teste de esforço novamente onde você substitui <o endereço> ip pelo endereço IP do balanceador de carga. Se não se lembrar deste endereço, execute novamente o script src/scripts/findip.sh.
dotnet run <ip address>
Desta vez, o aplicativo não gerará nenhuma saída e poderá eventualmente atingir o tempo limite com a mensagem "Erro ao enviar solicitação ao Balanceador de Carga: a operação foi cancelada". Pressione Enter para parar o aplicativo.
Na portal do Azure, selecione Dashboard>dashboard-learn-ts-loadbalancer.
Consulte o dashboard que mostra o estado da sonda de estado de funcionamento e a disponibilidade do caminho de dados. Poderá ter de alterar o intervalo de tempo para os últimos 30 minutos. Deverá ter um aspeto semelhante ao seguinte gráfico, com ambas as métricas a cair para zero.
Este gráfico mostra que as máquinas virtuais não estão a responder aos pedidos da sonda de estado de funcionamento do balanceador de carga. Por isso, foram marcados como estando em mau estado de funcionamento. Não existe um caminho de dados disponível entre um cliente e a aplicação em execução nestas máquinas virtuais.
Diagnosticar e resolver problemas
O primeiro passo é verificar se as máquinas virtuais estão a ser executadas. Vamos resolver os problemas das máquinas virtuais um de cada vez. Em primeiro lugar, vejamos a VM appretailvm1. Irá examinar a VM appretailvm2 mais tarde.
Testar a máquina virtual appretailvm1
Não pode enviar ping diretamente para a máquina virtual appretailvm1 ou appretailvm2, uma vez que estas têm endereços privados que só estão disponíveis para outras máquinas virtuais na mesma sub-rede. Primeiro, você se conecta à caixa de salto, que tem um endereço IP público e está na mesma sub-rede. Em seguida, você pode executar ping nas máquinas virtuais a partir daí.
Regresse ao Cloud Shell.
Execute os seguintes comandos para obter o endereço IP da máquina virtual do jump box.
bash ~/load-balancer/src/scripts/jumpboxip.sh
Execute o seguinte comando para obter a palavra-passe que criou quando executou o script de configuração inicial. Copie esta palavra-passe para o passo seguinte.
cd ~/load-balancer/src/scripts cat passwd.txt
Entre na caixa de salto com o endereço IP e a senha das saídas de comando anteriores. Substitua azureuser caso tenha utilizado um nome de utilizador diferente.
ssh azureuser@<jump box ip address>
No 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 deverá responder a indicar que está em execução. O passo seguinte é determinar se a aplicação Web está em execução nesta máquina virtual.
Execute o seguinte comando para enviar um pedido HTTP GET para a máquina virtual retailappvm1.
curl -v http://retailappvm1
Uma vez mais, este comando deverá ser bem-sucedido.
Verificar as sondas de estado de funcionamento e as regras de encaminhamento
A máquina virtual retailappvm1 está a funcionar e a aplicação está a ser executada nessa máquina virtual. Deve existir um problema entre o balanceador de carga e as máquinas virtuais no conjunto de back-end.
No portal do Azure, procure Monitorização.
Na página Monitorização – Descrição Geral, selecione Estado de Funcionamento do Serviço.
Selecione Estado de funcionamento do recurso.
Na caixa Tipo de recurso, selecione Balanceador de carga. Na lista de recursos, selecione retailapplb.
Aguarde uns minutos para que o estado de funcionamento do balanceador de carga seja avaliado.
Em Histórico do estado de funcionamento, expanda o evento que está mais acima e analise os passos recomendados. Estes passos sugerem que seja feita a verificação dos pontos finais VIP (regra de encaminhamento) e DIP (sonda de estado de funcionamento) no balanceador de carga.
Aceda ao grupo de recursos learn-ts-loadbalancer-rg e selecione retailapplb.
Selecione Regras de balanceamento de carga>retailapprule. Esta regra recebe tráfego de TCP na porta 80 do endereço IP de front-end e envia-o para a porta 80 da máquina virtual selecionada no conjunto de back-end. Esta configuração parece estar correta, embora a porta utilizada pela sonda de estado de funcionamento pareça suspeita. Atualmente, está definida como a porta 85.
Feche a página retailapprule.
Selecione Sondas de estado de funcionamento>retailapphealthprobe.
Altere a Porta de 85 para 80 e, em seguida, selecione Guardar.
Aguarde alguns minutos.
No menu à esquerda do portal do Azure, selecione Dashboard.
No dashboard, selecione o gráfico que mostra as métricas Estado da Sonda de Estado de Funcionamento e Disponibilidade do Caminho de Dados. A métrica Disponibilidade do Caminho de Dados deve aumentar para 100, mas a métrica Estado da Sonda de Estado de Funcionamento deverá ficar pelos 50. Agora, existe um caminho disponível desde o balanceador de carga até pelo menos uma máquina virtual. No entanto, apenas 50% das máquinas virtuais são apresentadas como estando em bom estado de funcionamento.
Selecione o gráfico para aceder à página de métricas do Balanceador de Carga. Esta página permite-lhe atualizar o gráfico e aplicar zoom num período específico.
No Cloud Shell, execute o seguinte comando para sair do jump box.
exit
Volte a executar a aplicação de teste de esforço através do endereço IP do balanceador de carga.
cd ~/load-balancer/src/stresstest dotnet run <ip address>
Tal como antes, o teste irá continuar a falhar. Agora, existe um caminho desde o balanceador de carga até pelo menos uma máquina virtual. No entanto, este caminho não funciona quando um cliente está fora da rede virtual. Prima Enter para parar a aplicação de teste de esforço.
Verificar as regras de NSG da sub-rede
O problema pode ser causado por uma regra de segurança de rede que bloqueia o tráfego externo.
No portal do Azure, aceda ao grupo de recursos learn-ts-loadbalancer-rg.
Selecione o grupo de segurança de rede retailappnsg. Este grupo de segurança determina que tráfego é permitido através 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 através da porta 80.
Selecione Adicionar. O painel Adicionar regra de segurança de entrada é exibido.
Introduza as seguintes definições e, em seguida, selecione Adicionar.
Property Value Source Qualquer Intervalo de portas de origem * Destino Qualquer Serviço Personalizado Intervalos de portas de destino 80 Protocolo TCP Ação Permitir Prioridade 100 Nome Porta_80 Description Porta HTTP No Cloud Shell, volte a executar a aplicação de teste de esforço através do endereço IP do balanceador de carga.
cd ~/load-balancer/src/stresstest dotnet run <ip address>
A aplicação será agora executada, mas só receberá uma resposta da máquina virtual retailappvm1. Permita que a aplicação seja executada durante dois ou três minutos. Pressione Enter para pará-lo.
No portal do Azure, aceda ao dashboard.
Selecione o gráfico da métrica de Contagem de Pacotes média. Observe o valor do pico da mais recente execução da aplicação de teste de esforço. Este valor deve ser pelo menos o dobro do valor registado anteriormente, quando ambas as máquinas virtuais estavam disponíveis. Apesar de agora ter um sistema funcional, corre o risco de sobrecarregar a máquina virtual em funcionamento.
Testar a máquina virtual appretailvm2
Parece que a máquina virtual appretailvm2 não está a processar os pedidos corretamente. Precisa de verificar se esta máquina virtual está operacional e se o Balanceador de Carga consegue ligar-se à mesma.
No Cloud Shell, entre na caixa de salto com o endereço IP e a senha das saídas de comando anteriores
ssh azureuser@<jump box ip address>
Tente enviar ping à máquina virtual appretailvm2.
ping retailappvm2 -c 10
A máquina virtual não consegue responder e o comando ping reporta uma perda de pacotes de 100%. A máquina virtual retailappvm2 não está em execução ou existe um problema de rede.
No portal do Azure, aceda ao grupo de recursos learn-ts-loadbalancer-rg.
Selecione a máquina virtual retailappvm2.
A página Descrição geral mostra que a máquina virtual parou. Selecione Iniciar e aguarde que a máquina seja executada.
Regresse ao Cloud Shell ligado ao jump box e repita o comando ping.
ping retailappvm2 -c 10
Desta vez, as operações ping devem ser bem-sucedidas.
Teste se a aplicação executada na máquina virtual retailappvm2 responde.
wget retailappvm2
Este comando expira. O aplicativo não está em execução ou pode haver um problema de rede. Prima Ctrl+C para parar o comando.
No jump box, inicie sessão na máquina virtual retailappvm2. Quando lhe for pedido, introduza a mesma palavra-passe que especificou anteriormente.
ssh azureuser@retailappvm2
Execute o seguinte comando para testar a aplicação nesta máquina virtual.
wget retailappvm2
O comando deverá ser executado com êxito e criar o ficheiro index.html que contém a resposta.
Examine este ficheiro index.html.
cat index.html
O ficheiro deve conter a mensagem retailappvm2 e mostrar que esta máquina virtual respondeu como esperado.
Feche a ligação à máquina virtual retailappvm2.
exit
Feche a ligação ao jump box.
exit
A máquina virtual retailappvm2 está operacional e a aplicação está em execução, mas não consegue ligar-se à aplicação fora da máquina virtual. Esta falha sugere um problema de rede.
No portal do Azure, aceda ao 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 através do protocolo TCP. Esta regra tem um número prioritário inferior à regra (que abre a porta 80), por isso prevalece.
Selecione a regra retailappvnetnsgrulevm2denyall, altere a prioridade para 300 e, de seguida, selecione Guardar.
Aguarde dois minutos e, em seguida, aceda ao Dashboard.
Selecione o gráfico que mostra a métrica Estado da Sonda de Estado de Funcionamento. O valor desta métrica deverá aumentar para 100. Pode precisar de atualizar o gráfico algumas vezes.
Mude para o Cloud Shell e execute a aplicação stresstest novamente através do endereço IP do balanceador de carga.
cd ~/load-balancer/src/stresstest dotnet run <ip address>
Agora, deverá ver mensagens das VMs retailappvm1 e retailappvm2. Recuperou totalmente a ligação ao sistema.
Prima Enter para parar a aplicação.
Resumo
No início deste exercício, viu que as máquinas virtuais não estavam a responder aos pedidos da sonda de estado de funcionamento do balanceador de carga. Detetou e resolveu um conjunto de problemas de sonda e caminho de dados:
- Na regra retailapprule do balanceador de carga, a porta utilizada pela sonda de estado de funcionamento foi configurada incorretamente para 85 em vez de 80. Atualizou a regra para utilizar a porta 80.
- O grupo de segurança de rede retailappnsg não tinha nenhuma regra de segurança de entrada que permitisse tráfego na porta 80. Por isso, o grupo de segurança de rede bloqueou a sonda de estado de funcionamento. Adicionou uma regra de segurança de entrada para permitir tráfego na porta 80.
- Verificou que a VM retailappvm2 parou. Reiniciou a VM.
- Depois iniciar a VM retailappvm2 e verificar que a aplicação estava em execução, não conseguiu ligar-se à aplicação. O grupo de segurança de rede tinha uma regra de entrada que bloqueava todo o tráfego de rede para o protocolo TCP. Esta regra "negar tudo" prevaleceu sobre a regra de segurança de entrada que permitiu tráfego na porta 80. Alterou a prioridade da regra "negar tudo", para que fosse superior à regra da porta 80. Esta alteração permitiu tráfego de rede de entrada na porta 80 para TCP.
Fez com que o serviço HTTP com balanceamento de carga voltasse a ficar totalmente operacional.