Compartilhar via

Solucionar problemas de integridade do recurso e de disponibilidade de entrada

  • Artigo

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

O Resource Health Check (RHC) para o Azure Load Balancer é usado para determinar a integridade do seu balanceador de carga. Ele analisa a métrica Disponibilidade do Caminho de Dados para determinar se os pontos de extremidade de balanceamento de carga, as combinações de IP de front-end e portas de front-end com regras de balanceamento de carga estão disponíveis.

Observação: o RHC não tem suporte para o balanceador de carga de SKU Básico

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

Status de integridade de recurso Descrição
Disponível Seu recurso do balanceador de carga está íntegro e disponível.
Degradado Seu balanceador de carga tem eventos iniciados pela plataforma ou pelo usuário que afetam o desempenho. A métrica de disponibilidade do caminho de dados relatou integridade inferior a 90%, mas superior a 25% por pelo menos dois minutos. Você pode estar enfrentando degradação de desempenho moderada a grave.
Indisponível Seu recurso do balanceador de carga não está íntegro. A métrica Disponibilidade do Caminho de Dados relatou menos de 25% de integridade por pelo menos dois minutos. Você pode estar enfrentando 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 status de integridade do recurso do balanceador de carga não foi atualizado ou não recebeu informações de disponibilidade do caminho de dados nos últimos 10 minutos. Esse estado pode ser temporário ou seu balanceador de carga pode não suportar o RHC.

Monitorando a disponibilidade do seu balanceador de carga

As duas métricas a serem usadas são Disponibilidade do caminho de dados e Status da sonda de integridade e é importante entender seus significados para obter insights corretos.

Disponibilidade do Caminho de Dados

A métrica Disponibilidade do Caminho de Dados é gerada por um ping TCP a cada 25 segundos em todas as portas de front-end que têm regras de balanceamento de carga configuradas. Esse ping TCP é roteado para qualquer uma das instâncias de back-end íntegras (investigadas). A métrica é uma taxa de sucesso percentual agregada de pings TCP em cada combinação de IP:porta de frontend para cada uma de suas regras de balanceamento de carga, em um período de tempo de amostra.

Status da Investigação de Integridade

A métrica 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 na investigação de integridade. Para investigações HTTP e HTTPS, um ping bem-sucedido requer uma resposta HTTP 200 OK, ao passo que, com investigações TCP, qualquer resposta é considerada bem-sucedida. A integridade de cada instância de backend é determinada quando a sonda atinge o número de sucessos ou falhas consecutivos necessários, com base na sua configuração da propriedade de limite da sonda. O status de integridade de cada instância de backend determina se a instância de backend tem ou não permissão para receber tráfego. Semelhante à métrica Disponibilidade do caminho de dados, a métrica Status da sonda de integridade agrega a média de pings bem-sucedidos/totais durante o intervalo de amostragem. O valor Status da Sonda de Saúde indica a saúde do backend isoladamente do seu balanceador de carga, sondando suas instâncias de backend sem enviar tráfego pelo frontend.

Importante

O status da sonda de saúde é coletado a cada minuto. Isso pode levar a flutuações secundárias em um valor outrora constante. Por exemplo, em cenários Ativo/Passivo onde há duas instâncias de backend, uma sondada para cima e outra para baixo, o serviço de sondagem de integridade pode capturar 7 amostras para a instância saudável e 6 para a instância não saudável. Isso levará a um valor anteriormente estável de 50 mostrado como 46,15 para um intervalo de um minuto.

Diagnosticar balanceadores de carga degradados e indisponíveis

Conforme descrito no artigo sobre recursos de integridade, 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 em um período de dois minutos. As mesmas etapas podem ser seguidas para investigar a falha que você vê em qualquer alerta de Status do Health Probe ou Disponibilidade do Caminho de Dados que você configurou. Exploramos o caso em que verificamos a integridade dos nossos recursos e descobrimos que nosso balanceador de carga estava indisponível com uma Disponibilidade do Caminho de Dados de 0% - nosso serviço está inativo.

Primeiro, vamos para a exibição das métricas detalhadas da página de insights do balanceador de carga no Portal do Azure. Acesse a exibição na página de recursos do balanceador de carga ou no link da mensagem de integridade do recurso. Em seguida, navegamos até a guia disponibilidade de front-end e back-end e revisamos uma janela de trinta minutos do período em que o estado degradado ou indisponível ocorreu. Se observarmos que a disponibilidade do nosso caminho de dados é 0%, sabemos que há um problema impedindo o tráfego para todas as nossas regras de balanceamento de carga e podemos ver quanto tempo esse problema durou.

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

Diagnosticar falhas de investigação de integridade

Se a métrica Status da Sonda de Saúde estiver refletindo que suas instâncias de backend não estão íntegras, recomendamos seguir a lista de verificação abaixo para descartar erros comuns de configuração:

  • Verifique a utilização da CPU para seus recursos para determinar se eles estão sob uma alta carga.
  • Se estiver usando uma verificação de investigação HTTP ou HTTPS, verifique se o aplicativo está íntegro e respondendo.
    • Valide se seu aplicativo está 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 backend.
  • Examine os grupos de segurança de rede aplicados aos nossos recursos de back-end. Verifique se não há regras de prioridade mais alta do que AllowAzureLoadBalancerInBound que bloqueia a investigação da integridade.
    • Você pode fazer isso acessando as configurações de Rede do Azure das suas VMs de back-end ou Conjuntos de Dimensionamento de Máquinas Virtuais.
    • Se você descobrir que esse problema de NSG está ocorrendo, transfira a regra de permissão existente ou crie uma nova regra de alta prioridade para permitir o tráfego do AzureLoadBalancer.
  • Verifique seu sistema operacional. Verifique se suas VMs estão escutando na porta de investigação e examine as regras de firewall do respectivo sistema operacional para garantir que não estão bloqueando o tráfego de investigação proveniente do endereço IP 168.63.129.16.
    • Você pode verificar as portas de escuta executando netstat -a no prompt de comando do Windows ou netstat -l em um terminal do Linux.
  • Verifique se você está usando o protocolo correto. Por exemplo, uma investigação usando HTTP para investigar uma porta escutando um aplicativo não HTTP irá falhar.
  • O Firewall do Azure não deve ser colocado no pool de back-end dos balanceadores de carga. Consulte Integrar o Firewall do Azure ao Balanceador de Carga Padrão do Azure para integrar corretamente o Firewall do Azure ao balanceador de carga.

Próximas etapas