Solucionar problemas de integridade de recursos e disponibilidade de entrada

Artigo
02/13/2024

Este artigo é um guia para investigar problemas que afetam a disponibilidade do IP de front-end e dos recursos de back-end do balanceador de carga.

A Verificação de Integridade de Recursos (RHC) para o Load Balancer é usada para determinar a integridade do seu balanceador de carga. Ele analisa a métrica Data Path Availability em um intervalo de 2 minutos para determinar se os pontos de extremidade de balanceamento de carga, as combinações de IP de frontend e portas de frontend com regras de balanceamento de carga estão disponíveis.

Nota: RHC não é suportado para Basic SKU Load Balancer

A tabela abaixo descreve a lógica RHC usada para determinar o estado de integridade do seu balanceador de carga.

Estado de funcionamento dos recursos	Descrição
Disponível	Seu recurso de balanceador de carga padrão está íntegro e disponível.
Degradado	Seu balanceador de carga padrão tem eventos iniciados pela plataforma ou pelo usuário que afetam o desempenho. A métrica Disponibilidade do Datapath relatou como menos de 90%, mas maior que 25% de integridade por pelo menos dois minutos. Você experimenta degradação de desempenho moderada a grave.
Indisponível	Seu recurso de balanceador de carga padrão não está íntegro. A métrica Datapath Availability relatou menos de 25% de integridade por pelo menos dois minutos. Você enfrenta uma degradação significativa do desempenho ou uma falta de disponibilidade para conectividade de entrada. Pode haver eventos de usuário ou plataforma causando indisponibilidade.
Desconhecido	O estado de funcionamento do recurso do seu recurso de balanceador de carga padrão não foi atualizado nem recebeu informações de disponibilidade do Caminho de Dados nos últimos 10 minutos. Esse estado é transitório e refletirá o status correto assim que os dados forem recebidos.

Sobre as métricas que usamos

As duas métricas a serem usadas são a disponibilidade do caminho de dados e o status da sonda de integridade, e é importante entender seu significado para obter insights corretos.

Disponibilidade do caminho dos dados

A métrica de disponibilidade do caminho de dados é gerada por um ping TCP a cada 25 segundos em todas as portas front-end que têm regras NAT de entrada e balanceamento de carga configuradas. Esse ping TCP é roteado para qualquer uma das instâncias de back-end íntegras (investigadas). Se o serviço receber uma resposta ao ping, é uma resposta bem-sucedida e a soma da métrica é iterada uma vez. Se não houver resposta, nenhuma iteração acontecerá. A contagem desta métrica é 1/100 do total de pings TCP por período de amostragem. Assim, queremos considerar a média, que é a média da soma/contagem para o período de tempo. Os dados mostram a métrica de disponibilidade de caminho agregada pela média, o que nos dá uma taxa de sucesso percentual para pings TCP em seu frontend IP:port para cada uma das suas regras NAT de entrada e balanceamento de carga.

Estado da sonda de estado de funcionamento

A métrica de status da sonda de integridade é gerada por um ping do protocolo definido na sonda de integridade. Esse ping é enviado para cada instância no pool de back-end e na porta definida no teste de integridade. Para testes HTTP e HTTPS, um ping bem-sucedido requer uma resposta HTTP 200 OK, enquanto que com testes TCP qualquer resposta é considerada bem-sucedida. Os sucessos ou falhas consecutivos de cada teste determinam a integridade da instância de back-end e se o pool de back-end atribuído é capaz de receber tráfego. Semelhante à disponibilidade do caminho de dados, usamos a agregação média, que nos informa a média de pings bem-sucedidos/totais durante o intervalo de amostragem. Esse valor de status da sonda de integridade indica a integridade do back-end isoladamente do seu balanceador de carga, examinando suas instâncias de back-end sem enviar tráfego pelo frontend.

Importante

O estado da sonda de saúde é amostrado numa base de um minuto. Isso pode levar a pequenas flutuações em um valor de outra forma estável. Por exemplo, se houver duas instâncias de back-end, uma sondada para cima e outra para baixo, o serviço de teste de integridade poderá capturar 7 amostras para a instância íntegra e 6 para a instância não íntegra. Isso levará a um valor anteriormente estável de 50 mostrando como 46,15 por um intervalo de um minuto.

Diagnosticar balanceadores de carga degradados e indisponíveis

Conforme descrito no artigo de integridade do recurso, um balanceador de carga degradado é aquele que mostra entre 25% e 90% de disponibilidade do caminho de dados. Um balanceador de carga indisponível é aquele com menos de 25% de disponibilidade do caminho de dados, durante um período de dois minutos. As mesmas etapas podem ser tomadas para investigar a falha que você vê em qualquer status de investigação de integridade ou alertas de disponibilidade de caminho de dados que você tenha configurado. Exploramos o caso em que verificamos a integridade de nossos recursos e descobrimos que nosso balanceador de carga não está disponível com uma disponibilidade de caminho de dados de 0% - nosso serviço está inativo.

Primeiro, vamos para a exibição detalhada de métricas de nossa página de insights do balanceador de carga no portal do Azure. Aceda à vista a partir da página de recursos do balanceador de carga ou da ligação na mensagem de estado de funcionamento do recurso. Em seguida, navegamos até a guia Disponibilidade de Frontend e Backend e revisamos uma janela de trinta minutos do período de tempo em que o estado degradado ou indisponível ocorreu. Se virmos que nossa disponibilidade de caminho de dados é de 0%, sabemos que há um problema que impede o tráfego de todas as nossas regras de NAT de entrada e balanceamento de carga, e podemos ver quanto tempo esse problema durou.

O próximo lugar que precisamos procurar é nossa métrica de status da sonda de integridade para determinar se nosso caminho de dados não está disponível é porque não temos instâncias de back-end saudáveis para atender ao tráfego. Se tivermos pelo menos uma instância de back-end saudável para todas as nossas regras de entrada e balanceamento de carga, sabemos que não é nossa configuração que está fazendo com que nossos caminhos de dados fiquem indisponíveis. Este cenário indica um problema na plataforma Azure. Embora os problemas da plataforma sejam raros, um alerta automatizado é enviado à nossa equipe para resolver rapidamente todos os problemas da plataforma.

Diagnosticar falhas na sonda de integridade

Digamos que verificamos nosso estado de investigação de saúde e descobrimos que todas as instâncias estão mostrando como insalubres. Essa descoberta explica por que nosso caminho de dados não está disponível, pois o tráfego não tem para onde ir. Em seguida, devemos passar pela seguinte lista de verificação para excluir erros de configuração comuns:

Verifique a utilização da CPU para seus recursos para determinar se eles estão sob alta carga.
- Você pode verificar isso visualizando a métrica Porcentagem de CPU do recurso na página Métricas. Saiba como Solucionar problemas de alta CPU para máquinas virtuais do Azure.
Se estiver usando uma sonda HTTP ou HTTPS, verifique se o aplicativo está íntegro e responsivo.
- Valide se o aplicativo é funcional acessando diretamente os aplicativos por meio do endereço IP privado ou do endereço IP público no nível da instância associado à sua instância de back-end.
Analise os Grupos de Segurança de Rede aplicados aos nossos recursos de back-end. Certifique-se de que não há regras de prioridade mais alta do que AllowAzureLoadBalancerInBound que bloqueia a investigação de integridade.
- Você pode fazer isso visitando as configurações de rede de suas VMs de back-end ou conjuntos de escala de máquina virtual.
- Se você achar que esse problema do NSG é o caso, mova a regra Allow existente ou crie uma nova regra de alta prioridade para permitir o tráfego do AzureLoadBalancer.
Verifique o seu SO. Certifique-se de que suas VMs estão escutando a porta de teste e revise suas regras de firewall do sistema operacional para garantir que elas não estejam bloqueando o tráfego de sonda originado do endereço 168.63.129.16IP.
- Você pode verificar as portas de escuta executando netstat -a a partir de um prompt de comando do Windows ou netstat -l de um terminal Linux.
Certifique-se de que está a utilizar o protocolo certo. Por exemplo, um teste usando HTTP para investigar uma escuta de porta para um aplicativo não-HTTP falha.
O Firewall do Azure não deve ser colocado no pool de back-end de balanceadores de carga. Consulte Integrar o Firewall do Azure com o Balanceador de Carga Padrão do Azure para integrar corretamente o Firewall do Azure com o balanceador de carga.

Se você passou por essa lista de verificação e ainda está encontrando falhas na sonda de integridade, pode haver problemas raros na plataforma que afetam o serviço de investigação para suas instâncias. Neste caso, o Azure tem as suas costas e um alerta automatizado é enviado para a nossa equipa para resolver rapidamente todos os problemas da plataforma.