Diagnosticar problemas ao rever configurações e métricas
Monitorizar o desempenho do Balanceador de Carga do Azure pode fornecer um aviso antecipado de possíveis falhas. O Azure Monitor fornece muitas métricas importantes que utiliza para examinar tendências no desempenho do Balanceador de Carga. Também pode acionar alertas se uma ou mais máquinas virtuais (VMs) falharem pedidos da sonda de estado de funcionamento.
No cenário de exemplo, tem de monitorizar o desempenho do sistema de balanceamento de carga para garantir que o desempenho cumpre os requisitos. Se o desempenho for interrompido e as conexões com VMs começarem a falhar, solucione problemas no sistema para determinar a causa e corrigir o problema. Ao final desta unidade, você é capaz de:
- Descrever as métricas disponíveis para medir o débito e desempenho de um sistema de balanceamento de carga.
- Utilizar a página de estado de funcionamento do recurso no portal do Azure para monitorizar o estado de funcionamento do seu sistema.
- Explicar como resolver problemas comuns num sistema de balanceamento de carga.
Utilizar o Azure Monitor para resolver problemas do Balanceador de Carga
Com o Azure Monitor, pode capturar e examinar registos de diagnósticos e dados de desempenho do Balanceador de Carga.
Monitorizar a conectividade
Você pode visualizar métricas para o Balanceador de Carga usando o painel Métricas no portal do Azure. A partir da perspetiva de resolução de problemas de conectividade, as métricas mais importantes são Disponibilidade do Caminho de Dados e Estado da Sonda de Estado de Funcionamento.
O Balanceador de Carga testa continuamente a disponibilidade do caminho para o endereço IP de front-end através das regras de balanceamento de carga e do conjunto de back-end para as aplicações em execução nas suas VMs. Estas informações são registadas como a métrica Disponibilidade do Caminho de Dados. Aplicar a métrica Avg mostra a disponibilidade média de um determinado intervalo de tempo. Esta agregação é um valor entre 0 (sem disponibilidade) e 100, em que existe pelo menos um caminho de sucesso disponível do endereço IP de front-end para uma VM no conjunto de back-end.
A métrica Estado da Sonda de Estado de Funcionamento é semelhante, mas só se aplica à sonda de estado de funcionamento para as VMs, em vez do caminho completo através do Balanceador de Carga. Novamente, a agregação Avg para essa métrica fornece um valor entre 0 (todas as VMs não estão íntegras e não respondem) e 100, onde todas as VMs estão respondendo à sonda de integridade.
A captura de tela a seguir mostra o gráfico para a disponibilidade média do caminho de dados e o status médio da sonda de integridade para um balanceador de carga com duas VMs no pool de back-end. Uma das máquinas não está a responder à sonda de estado de funcionamento. O estado médio da sonda de saúde está oscilando em torno da marca de 50%.
Outra forma de examinar estas métricas é através da agregação Contagem. Essa abordagem pode fornecer outras informações sobre possíveis problemas com sua configuração. O exemplo que se segue mostra os grafos da contagem das métricas Estado da Sonda de Estado de Funcionamento e Disponibilidade do Caminho de Dados. O grafo mostra quantas sondas bem-sucedidas foram efetuadas ao longo do tempo.
Um ponto interessante neste gráfico é que o número de testes de Disponibilidade de Caminho de Dados bem-sucedidos permaneceu dentro de um intervalo consistente. No entanto, o número de verificações bem-sucedidas do Estado da Sonda de Estado de Funcionamento aumentou momentaneamente e depois baixou para cerca de metade do valor antes da ocorrência do pico.
Na configuração utilizada para gerar este gráfico, o conjunto de back-end inclui apenas duas VMs. Uma destas máquinas foi interrompida para simular uma falha. A métrica Disponibilidade do Caminho de Dados mostra que ainda é possível que uma aplicação cliente se ligue à aplicação em execução na VM que está a funcionar. No entanto, o Estado da Sonda de Estado de Funcionamento indica que o estado de funcionamento global do conjunto de back-end é apenas metade do que era anteriormente.
Ver estado de funcionamento do serviço
A página Estado de funcionamento do serviço do Balanceador de Carga do Azure comunica o estado geral do seu sistema. Pode aceder a esta página no portal do Azure Monitor. Selecione Estado de Funcionamento do Serviço, Estado de Funcionamento do Recurso e, em seguida, selecione Balanceador de Carga como o tipo de recurso.
Selecione o seu balanceador de carga. Você verá um relatório que detalha o histórico de saúde do seu serviço. Pode expandir qualquer item no relatório para ver os detalhes. A imagem que se segue mostra o resumo gerado quando uma das VMs no conjunto de back-end fica offline.
Monitorizar a carga de trabalho por VM
As outras métricas disponíveis para o Balanceador de Carga permitem-lhe monitorizar o número de bytes e pacotes de rede que passam pelo Balanceador de Carga por front-end. Um front-end é definido como uma combinação do endereço IP do Balanceador de Carga, o protocolo utilizado para aceitar pedidos recebidos e o número de porta utilizado pela regra de balanceamento de carga para ligar às VMs. Estas métricas podem fornecer uma medida de débito do seu sistema por VM ativa.
O grafo que se segue mostra a contagem de pacotes média que percorre o Balanceador de Carga enquanto executa uma carga de trabalho de teste de 500 utilizadores simultâneos durante dois minutos. A carga de trabalho foi executada duas vezes. Na primeira vez, o conjunto de back-end incluía duas instâncias de VM. Na segunda vez, uma das VMs foi encerrada (para simular uma falha).
Neste gráfico, a contagem de pacotes média por front-end duplicou quando uma VM foi encerrada. Este volume de trabalho pode sobrecarregar a VM restante, o que poderá levar a tempos de resposta prolongados e possíveis limites de tempo.
Investigar e remediar problemas comuns no Balanceador de Carga
Esta secção abrange alguns cenários de falha comuns que poderá encontrar no Balanceador de Carga. Cada cenário resume os sintomas de uma falha e como pode resolver o problema.
As VMs no Balanceador de Carga não estão a responder ao tráfego na porta da sonda
Este problema pode ser o resultado dos seguintes problemas:
As VMs no conjunto de back-end não estão a escutar a porta da sonda correta.
Verifique se a sonda de estado de funcionamento está definida corretamente no Balanceador de Carga. Certifique-se de que o código da aplicação em execução em cada VM está a responder adequadamente aos pedidos de sonda. Estes devem devolver uma mensagem de resposta HTTP 200 (OK).
O NSG para a sub-rede da rede virtual que aloja as VMs está a bloquear a porta da sonda.
Verifique a configuração do NSG para a sub-rede da rede virtual que contém as VMs. Certifique-se de que o NSG permite que o tráfego do Balanceador de Carga passe pela porta da sonda de estado de funcionamento.
Está a tentar aceder ao Balanceador de Carga a partir da mesma VM e cartão de rede virtual. Este problema não está relacionado com a pesquisa, mas é um cenário de caminho de dados não suportado.
Está a tentar aceder ao front-end do Balanceador de Carga a partir de uma VM no conjunto de back-end.
Ambos os itens são problemas de criação de aplicações. Evite enviar pedidos para a mesma instância do Balanceador de Carga a partir da VM no conjunto de back-end.
Uma VM no conjunto de back-end está em mau estado de funcionamento
Neste caso, a maioria das VMs está a responder normalmente, mas uma ou duas não. Como algumas VMs aceitam tráfego, é provável que a sonda de estado de funcionamento esteja corretamente configurada. O NSG para a sub-rede não está a bloquear a porta que a sonda de estado de funcionamento utiliza. O problema está, provavelmente, nas VMs em mau estado de funcionamento. Este problema pode estar a acontecer porque as VMs estão inacessíveis ou em baixo ou existe um problema de aplicação nestas máquinas.
Utilize os seguintes passos para determinar a causa do problema de uma VM em mau estado de funcionamento:
- Inicie sessão numa VM em mau estado de funcionamento para verificar o que está a acontecer. Verifique se a VM consegue responder a verificações básicas como pedidos de ping, rdp ou ssh de outra VM no conjunto de back-end.
- Se a VM estiver em funcionamento e acessível, verifique se a aplicação está em execução.
- Execute o
netstat -ancomando e verifique se as portas usadas pela investigação de integridade e pelo aplicativo estão listadas como LISTENING.
Configurações erradas no Balanceador de Carga
O Balanceador de Carga requer que configure corretamente as regras de encaminhamento que direcionam o tráfego que chega do front-end para o conjunto de back-end. Se uma regra de roteamento estiver ausente ou não estiver configurada corretamente, o tráfego que chega ao front-end será descartado. Depois que o tráfego é descartado, o aplicativo é relatado aos clientes como inacessível.
Valide a rota através do Balanceador de Carga do front-end para o conjunto de back-end. Você pode usar ferramentas como Ping, TCPing e netsh, que estão disponíveis para Windows e Linux. Você também pode usar psping no Windows. As seções a seguir descrevem como usar essas ferramentas.
Usar ping
O comando ping testa a conectividade de ping através de um ponto de extremidade usando o protocolo ICMP. Para verificar se uma rota está disponível do seu cliente para uma VM através do Balanceador de Carga, execute o seguinte comando. Substitua <o endereço> ip pelo endereço IP da instância do Load Balancer.
ping -n 10 <ip address>
| Switch | Descrição |
|---|---|
| -n | Essa opção especifica o número de solicitações de ping a serem enviadas. |
O resultado normal tem o seguinte aspeto:
ping -n 10 nn.nn.nn.nn
Pinging nn.nn.nn.nn with 32 bytes of data:
Reply from nn.nn.nn.nn: bytes=32 time=34ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Ping statistics for nn.nn.nn.nn:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 34ms, Average = 30ms
Utilizar o comando PsPing
O comando PsPing testa a conectividade de ping através de um ponto final. Este comando também mede a disponibilidade de latência e largura de banda para um serviço. Para verificar se uma rota está disponível do seu cliente para uma VM através do Balanceador de Carga, execute o seguinte comando. Substitua <ip address (endereço IP)> e <port (porta)> pelo endereço IP e pela porta de front-end da instância do Balanceador de Carga.
psping -n 100 -i 0 -q -h <ip address>:<port>
| Sinalizador | Descrição |
|---|---|
| -n | Especifica a quantidade de pings a efetuar. |
| -i | Indica o intervalo em segundos entre iterações. |
| -q | Suprime a saída entre os pings. Só é mostrado um resumo no final. |
| -h | Imprime um histograma que mostra a latência dos pedidos. |
O resultado normal tem o seguinte aspeto:
TCP connect to nn.nn.nn.nn:nn:
101 iterations (warmup 1) ping test: 100%
TCP connect statistics for nn.nn.nn.nn:nn:
Sent = 100, Received = 100, Lost = 0 (0% loss),
Minimum = 7.48ms, Maximum = 9.08ms, Average = 8.30ms
Latency Count
7.48 3
7.56 2
7.65 2
7.73 2
7.82 7
7.90 4
7.98 4
8.07 6
8.15 9
8.24 9
8.32 11
8.40 7
8.49 11
8.57 12
8.66 3
8.74 2
8.82 2
8.91 1
8.99 2
9.08 1
Utilizar o utilitário tcping
O utilitário tcping é semelhante ao ping , exceto que ele opera através de uma conexão TCP em vez de ICMP. Utilize o tcping da seguinte forma:
tcping <ip address> <port>
O resultado normal tem o seguinte aspeto:
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.042ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.810ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.266ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.181ms
Ping statistics for nn.nn.nn.nn:nn
4 probes sent.
4 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 9.042ms, Maximum = 9.810ms, Average = 9.325ms
Utilizar o utilitário netsh
O utilitário netsh é uma ferramenta de configuração de rede para fins gerais. Utilize o comando rastreio em netsh para capturar o tráfego. Em seguida, analise-o usando uma ferramenta como o Wireshark. Utilize rastreio netsh para examinar os pacotes de rede enviados e recebidos por psping quando testar a conectividade através do Balanceador de Carga da seguinte forma:
Inicie um rastreio de rede a partir de um pedido de comando executado como Administrador. O seguinte exemplo rastreia o tráfego do cliente de Internet (pedidos HTTP) de e para o endereço IP especificado. Substitua o <endereço IP> pelo endereço da instância do Balanceador de Carga. Os dados de rastreamento são gravados em um arquivo chamado trace.etl.
netsh trace start ipv4.address=<ip address> capture=yes scenario=internetclient tracefile=trace.etlExecute psping para testar a conectividade através do Balanceador de Carga.
psping -n 100 -i 0 -q <ip address>:<port>Pare o rastreio.
netsh trace stopEste comando demora alguns minutos a ser concluído porque correlaciona e intercala a informação enquanto cria simultaneamente o ficheiro de saída de rastreio.
Inicie o Wireshark e abra o arquivo de rastreamento.
Adicione o seguinte filtro ao rastreio. Substitua <nn> pelo número da porta de front-end do Balanceador de Carga.
TCP.Port==80 or TCP.Port==<nn>Adicione a origem e destino do pedido HTTP como campos à saída de rastreio.
Examine as mensagens de rastreio:
- Caso não existam pacotes de entrada para o Balanceador de Carga, é provável que exista um problema de segurança de rede ou um problema de encaminhamento definido pelo utilizador.
- Se nenhum dos pacotes de saída for devolvido ao cliente, é provável que exista um problema de configuração de aplicação ou um problema de encaminhamento definido pelo utilizador.
Firewall da VM ou NSG a bloquear a porta
Se a rede e o Balanceador de Carga estiverem configurados corretamente, a VM estiver ativada e o aplicativo estiver em execução, a configuração de firewall ou NSG para as VMs poderá estar bloqueando a porta usada pela sonda de integridade ou pelo aplicativo. Use as seguintes etapas para determinar se esse é o caso:
Caso exista uma firewall na VM, pode estar a bloquear pedidos nas portas utilizadas pela sonda de estado de funcionamento e aplicação. Valide a configuração da firewall no anfitrião para garantir que permite o tráfego nas portas utilizadas pela sonda de estado de funcionamento e a aplicação.
Verifique se qualquer NSG para o NIC das VMs permite a entrada e saída nas portas necessárias. Verifique a existência de uma regra Negar todas no NSG no NIC das VM's que tenha uma prioridade superior do que a regra predefinida.
Importante
Pode associar um NSG a uma sub-rede e os NICs individuais das VMs na sub-rede. Pode ter configurado o NSG para uma sub-rede para permitir que o tráfego passe por uma porta. No entanto, se o NSG de uma VM fechar essa mesma porta, os pedidos não irão chegar a essa VM.
Limitações do Balanceador de Carga
O Balanceador de Carga funciona na camada 4 na pilha de rede ISO e não examina nem manipula de qualquer outra forma o conteúdo dos pacotes de rede. Não é possível utilizá-lo para implementar o encaminhamento baseado em conteúdo.
Todos os pedidos de clientes são encerrados por uma VM no conjunto de back-end. O Balanceador de Carga é invisível para os clientes. Se nenhuma VM estiver disponível, a solicitação do cliente falhará. As aplicações cliente não podem comunicar com ou interrogar o estado do Balanceador de Carga ou qualquer um dos seus componentes.
Se precisar de implementar o balanceamento de carga com base no conteúdo das mensagens, considere utilizar o Gateway de Aplicação do Azure. Ou então, pode configurar um servidor Web proxy para processar pedidos de cliente recebidos e direcioná-los para VMs específicas.