Laboratório de Troubleshooting: Map requirements to features and capabilities of Azure Load Balancer
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações recebe alertas de que uma aplicação web em produção está com latência elevada e erros intermitentes. O ambiente usa um Azure Load Balancer Standard público com três VMs no backend pool. O engenheiro de plantão verifica o painel do Azure e coleta as seguintes informações:
Load Balancer: lb-prod-web (Standard, Public)
Frontend IP: 20.120.45.10
Backend Pool:
VM-prod-01: Running, NIC associada, respondendo ping interno
VM-prod-02: Running, NIC associada, respondendo ping interno
VM-prod-03: Running, NIC associada, respondendo ping interno
Health Probe:
Protocol: HTTP
Port: 8080
Path: /healthz
Interval: 15s
Unhealthy threshold: 2
NSG associado à sub-rede das VMs:
Inbound Rule 100: Allow TCP 443 from Any
Inbound Rule 200: Allow TCP 8080 from 10.0.0.0/8
Inbound Rule 4096: Deny All Inbound
O engenheiro confirma que as três VMs estão ligadas, a aplicação na porta 443 responde quando testada diretamente pelo IP privado de cada VM, e não houve deploy recente. O tráfego de usuários chega pela porta 443.
Qual é a causa raiz dos erros intermitentes?
A. O health probe está usando HTTP em vez de HTTPS, o que é incompatível com o SKU Standard e gera falsos negativos
B. O NSG bloqueia as sondas do health probe porque o intervalo de origem das sondas não está coberto pela regra que libera a porta 8080
C. O Idle Timeout padrão de 4 minutos está encerrando conexões longas antes que a aplicação conclua o processamento
D. O Load Balancer não consegue distribuir tráfego porque nenhuma regra libera explicitamente o IP do frontend no NSG da sub-rede
Cenário 2 — Causa Raiz
Um Load Balancer Standard interno foi implantado para balancear requisições entre instâncias de um serviço de processamento de dados. As VMs no backend pool precisam consultar uma API externa na internet durante o processamento. Após a migração do ambiente de Basic para Standard, os jobs passaram a falhar com erros de timeout na chamada à API externa. A equipe verifica:
Load Balancer: lb-internal-proc (Standard, Internal)
Frontend IP: 10.1.2.100 (privado)
Backend Pool:
VM-proc-01: sem IP público atribuído na NIC
VM-proc-02: sem IP público atribuído na NIC
VM-proc-03: sem IP público atribuído na NIC
Rota efetiva nas VMs:
0.0.0.0/0 -> Next hop: Internet
NSG da sub-rede:
Outbound Rule 100: Allow TCP 443 to Internet
Outbound Rule 4096: Deny All Outbound
O NSG permite saída na porta 443, as rotas apontam para a internet, e não há Azure Firewall ou NVA no caminho. O ambiente era funcional quando usava Load Balancer Basic.
Qual é a causa raiz da falha de conectividade de saída?
A. O NSG está bloqueando a saída porque a regra Allow TCP 443 não cobre o endereço IP da API externa especificamente
B. O SKU Standard não fornece conectividade de saída padrão para VMs sem IP público, ao contrário do Basic, e nenhuma solução de saída foi configurada
C. A rota padrão 0.0.0.0/0 com next hop Internet está sendo ignorada porque o Load Balancer interno intercepta todo o tráfego de saída
D. As VMs precisam de um IP público individual na NIC para ter conectividade de saída, independentemente do SKU do Load Balancer
Cenário 3 — Decisão de Ação
A causa foi identificada: um Load Balancer Standard público em produção está com todas as VMs do backend pool marcadas como unhealthy pelo health probe HTTP na porta 80. A investigação confirmou que o aplicativo foi atualizado ontem e a nova versão expõe o endpoint de health check na porta 8080, não mais na porta 80. A porta 80 não responde mais em nenhuma das VMs.
O ambiente tem as seguintes restrições:
- Janela de manutenção permitida: sábados das 22h às 02h. Hoje é terça-feira, 14h.
- O Load Balancer está com Session Persistence: Client IP configurado.
- O tráfego de usuários está chegando e sendo descartado porque não há VMs saudáveis.
- Um segundo Load Balancer de standby está disponível, pré-configurado com probe na porta 8080, mas nunca foi testado em produção.
- A equipe tem permissão para alterar configurações do Load Balancer existente fora da janela de manutenção em caso de incidente ativo.
Qual é a ação correta neste momento?
A. Aguardar a janela de manutenção de sábado para alterar a porta do health probe no Load Balancer existente, evitando risco fora da janela
B. Promover imediatamente o Load Balancer de standby como produção, redirecionando o DNS para o novo IP de frontend
C. Alterar a porta do health probe no Load Balancer existente de 80 para 8080, aproveitando a permissão de alteração em incidente ativo
D. Reverter o deploy da aplicação para a versão anterior, restaurando a resposta na porta 80 até a próxima janela de manutenção
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "Após adicionarmos uma nova VM ao backend pool do Load Balancer, alguns usuários começaram a reportar que suas sessões são reiniciadas aleatoriamente."
O engenheiro tem os seguintes passos de investigação disponíveis:
- Verificar se a configuração de Session Persistence na regra de balanceamento é diferente de None
- Confirmar se a nova VM passou a receber tráfego com base nos dados de métricas do Load Balancer
- Verificar se o health probe está marcando a nova VM como healthy
- Comparar as configurações de aplicação e versão de software entre a nova VM e as VMs existentes no pool
- Verificar se o Idle Timeout da regra de balanceamento foi alterado junto com a adição da VM
Qual sequência de diagnóstico é a mais lógica e eficiente para este cenário?
A. 3 -> 2 -> 1 -> 4 -> 5
B. 1 -> 3 -> 2 -> 4 -> 5
C. 5 -> 1 -> 3 -> 2 -> 4
D. 3 -> 1 -> 5 -> 2 -> 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O health probe do tipo HTTP na porta 8080 parte de um endereço IP especial de plataforma do Azure: 168.63.129.16. Esse IP não pertence ao bloco 10.0.0.0/8 e não é coberto pela regra 200 do NSG, que libera a porta 8080 apenas para origens internas. A regra 4096 bloqueia todo o resto. Portanto, as sondas são descartadas, as VMs são marcadas como unhealthy de forma intermitente, e o tráfego deixa de ser enviado para elas em rodízio, causando os erros.
A pista no enunciado é a combinação da origem restrita na regra do NSG (10.0.0.0/8) com o fato de que o probe usa a porta 8080, que não está aberta para todas as origens.
A informação irrelevante é o fato de as VMs responderem ao ping interno e de a porta 443 funcionar no acesso direto. Esses dados confirmam que a aplicação está sã, mas não têm relação com o caminho do health probe.
Os distratores induzem ao erro de focar no protocolo do probe (A), no timeout (C) ou na ausência de uma regra explícita para o frontend (D). O erro mais perigoso seria o C: aumentar o Idle Timeout não resolveria nada e atrasaria a identificação da causa real por horas.
Gabarito — Cenário 2
Resposta: B
O SKU Basic do Load Balancer fornece default outbound access de forma implícita para VMs no backend pool. O SKU Standard elimina esse comportamento por design, exigindo conectividade de saída explicitamente configurada via Outbound Rules, NAT Gateway ou IP público na NIC. Como nenhuma dessas alternativas foi configurada durante a migração, as VMs perderam a capacidade de iniciar conexões para a internet.
A pista no enunciado é direta: o ambiente "era funcional quando usava Load Balancer Basic" e não houve nenhuma outra mudança.
A informação irrelevante é a rota 0.0.0.0/0 com next hop Internet. Ela está correta e não é o problema; o bloqueio ocorre antes da camada de roteamento, na ausência de um mecanismo de SNAT válido.
O distrator D é o mais perigoso: ele afirma que VMs sempre precisam de IP público individual, o que é tecnicamente falso. Outbound Rules e NAT Gateway são soluções válidas sem IP público nas NICs. Agir com base nessa crença levaria a uma arquitetura incorreta e mais cara.
Gabarito — Cenário 3
Resposta: C
A causa está identificada e o impacto é imediato: 100% do tráfego está sendo descartado. O ambiente tem uma permissão explícita para alterações fora da janela em incidentes ativos. Alterar a porta do health probe de 80 para 8080 no Load Balancer existente é a ação cirúrgica, segura e reversível que resolve o problema sem introduzir risco adicional.
A alternativa A ignora a permissão de incidente e prolonga a indisponibilidade até sábado, o que é inaceitável. A alternativa B introduz risco desnecessário ao colocar em produção um recurso nunca testado, potencialmente trocando um problema por outro. A alternativa D reverte um deploy de aplicação, que é uma operação com impacto próprio e que não seria justificada quando a correção correta no Load Balancer é disponível e de baixo risco.
O ponto central é que as restrições de janela de manutenção existem para mudanças planejadas, não para bloquear a resposta a incidentes ativos quando há permissão explícita.
Gabarito — Cenário 4
Resposta: A
A sequência correta é: 3 -> 2 -> 1 -> 4 -> 5.
O raciocínio progressivo começa pela validação de que a nova VM está de fato participando do pool de forma saudável (passo 3). Sem confirmar isso, qualquer hipótese sobre sessões é prematura. Em seguida, confirmar pelo métricas que ela está recebendo tráfego (passo 2) estabelece que o problema não é de exclusão do pool. Com isso confirmado, verificar se a Session Persistence está configurada (passo 1) é o próximo passo lógico, pois a adição de uma nova VM com hash de 5 tuplas pode redistribuir sessões existentes se a persistência não estiver ativa. A comparação de versão de software (passo 4) identifica problemas de compatibilidade na camada de aplicação. O Idle Timeout (passo 5) é o menos provável de ter sido alterado junto com a adição de uma VM e deve ser verificado por último.
A alternativa B começa pela Session Persistence antes de confirmar se a VM está saudável e recebendo tráfego, o que inverte a ordem de eliminação de hipóteses. As alternativas C e D colocam o Idle Timeout em posições centrais do diagnóstico, o que não é justificado pelo sintoma relatado.
Árvore de Troubleshooting: Map requirements to features and capabilities of Azure Load Balancer
Legenda:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão verificável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado. A cada nó azul, responda a pergunta com base no que é observável no portal do Azure, nos logs ou nas métricas. Siga o caminho correspondente à sua resposta até alcançar um nó vermelho (causa identificada) e então execute a ação no nó verde associado. Se a ação não resolver o sintoma, retorne ao nó de verificação laranja mais próximo e reavalie as hipóteses antes de avançar para outro ramo.