Laboratório de Troubleshooting: Identify appropriate use cases for Azure Load Balancer
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que uma aplicação web hospedada em três VMs atrás de um Azure Load Balancer Standard público passou a apresentar falhas intermitentes. Alguns usuários conseguem acessar normalmente, outros recebem timeout. A aplicação está em produção há seis meses sem alterações na configuração do Load Balancer.
Na última semana, a equipe de segurança aplicou uma nova política de NSG nas sub-redes das VMs para restringir tráfego lateral entre elas. Também foi habilitado o diagnóstico de métricas no Load Balancer via Azure Monitor.
A equipe verifica o seguinte no portal:
Health Probe Status:
VM-01: Healthy
VM-02: Degraded
VM-03: Degraded
NSG aplicado à subnet:
Inbound rules:
Priority 100 | Source: VirtualNetwork | Port: 443 | Allow
Priority 200 | Source: Internet | Port: 443 | Allow
Priority 4096| Default Deny All
Probe configurada:
Protocol: HTTP
Port: 80
Path: /health
Usuários que conseguem acessar estão sendo roteados exclusivamente para VM-01. As demais VMs estão em execução e respondem localmente quando testadas via SSH com curl localhost:80/health.
Qual é a causa raiz das falhas intermitentes?
A) O Load Balancer Standard não suporta health probes HTTP na porta 80 quando a regra de balanceamento usa a porta 443
B) A nova regra de NSG bloqueia o tráfego originado pelo endereço de probe do Azure (168.63.129.16) na porta 80, fazendo com que VM-02 e VM-03 sejam marcadas como degradadas
C) O diagnóstico habilitado via Azure Monitor está consumindo recursos das VMs e causando lentidão nas respostas de health probe
D) A regra de NSG com prioridade 100 restringe o tráfego de entrada apenas à porta 443, impedindo que os usuários acessem a aplicação nas VMs degradadas
Cenário 2 — Decisão de Ação
A equipe de redes identificou que um Azure Load Balancer interno está configurado incorretamente: a regra de balanceamento aponta para o backend pool correto, mas o Floating IP (também chamado de Direct Server Return) foi habilitado inadvertidamente. A aplicação de destino não foi desenvolvida para operar com Floating IP e não está configurada para responder pelo IP do frontend do Load Balancer.
O ambiente está em produção. Há uma janela de manutenção programada para daqui a 72 horas. A alteração da configuração de Floating IP em uma regra existente não causa indisponibilidade imediata, apenas requer que a regra seja salva novamente. O time de desenvolvimento confirmou que nenhuma das instâncias de backend precisa de reconfiguração adicional após a correção da regra.
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção de 72 horas para desabilitar o Floating IP, pois toda alteração em regras de Load Balancer em produção deve seguir o processo formal de mudança
B) Desabilitar o Floating IP na regra de balanceamento imediatamente, pois a correção não causa indisponibilidade e o ambiente está operando com falha de roteamento ativa
C) Recriar o Load Balancer do zero sem Floating IP, aproveitando a janela de manutenção para garantir uma configuração limpa
D) Adicionar uma rota estática nas VMs do backend apontando o IP do frontend do Load Balancer para o loopback, como solução temporária até a janela de manutenção
Cenário 3 — Causa Raiz
Uma empresa migrou recentemente um sistema legado de monitoramento industrial para o Azure. O sistema usa o protocolo Modbus TCP na porta 502 para comunicação entre um servidor central e 12 dispositivos de campo representados por VMs. A equipe configurou um Azure Load Balancer interno Standard para distribuir requisições do servidor central para as VMs.
Após a migração, o servidor central consegue estabelecer conexão TCP na porta 502, mas os dispositivos de campo relatam receber requisições duplicadas de forma irregular. A equipe suspeita de um problema de configuração no backend pool.
Informações coletadas:
Load Balancer SKU: Standard (Internal)
Frontend IP: 10.10.1.100
Backend pool: 12 VMs
Load balancing rule:
Protocol: TCP
Frontend port: 502
Backend port: 502
Session Persistence: None
Idle Timeout: 4 minutos
Floating IP: Disabled
Logs de conexao no servidor central:
[10:01:22] Connected to 10.10.1.100:502
[10:01:22] Request sent: READ_HOLDING_REGISTERS
[10:01:23] Response received from 10.10.1.101
[10:01:45] New connection established to 10.10.1.100:502
[10:01:45] Request sent: READ_HOLDING_REGISTERS
[10:01:46] Response received from 10.10.1.107
O servidor central não reabre conexões intencionalmente. As VMs estão saudáveis e a aplicação Modbus está respondendo normalmente em testes isolados. O Idle Timeout de 4 minutos foi configurado pela equipe para reduzir consumo de recursos.
Qual é a causa raiz das requisições duplicadas?
A) O backend pool com 12 VMs excede o limite de instâncias suportadas pelo Azure Load Balancer Standard interno, causando rebalanceamento inesperado
B) A ausência de Session Persistence faz com que cada nova conexão TCP seja roteada para uma VM diferente, e o protocolo Modbus, sendo stateful por sessão, interpreta a troca de backend como duplicação de requisição
C) O Idle Timeout de 4 minutos está encerrando conexões TCP ativas antes que o servidor central conclua o ciclo de polling, forçando reconexões que o Load Balancer roteia para backends diferentes
D) O protocolo Modbus TCP não é suportado pelo Azure Load Balancer porque opera em uma porta abaixo de 1024, exigindo configuração especial de portas privilegiadas
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "VMs do backend pool não estão recebendo tráfego do Load Balancer. O frontend IP responde a ping, mas a aplicação nas VMs não é alcançada."
O engenheiro tem acesso ao portal do Azure e às VMs via Bastion. Os seguintes passos de investigação estão disponíveis, mas fora de ordem:
Passo P: Verificar se as VMs estao no estado "Running" e se o agente de SO esta responsivo
Passo Q: Verificar o status das health probes no portal do Azure (Healthy/Degraded)
Passo R: Confirmar que a regra de balanceamento esta associada ao frontend IP e ao backend pool corretos
Passo S: Testar manualmente se a aplicacao responde na porta configurada fazendo curl direto no IP da VM via Bastion
Passo T: Verificar se o NSG da subnet ou da NIC permite o trafego da probe (168.63.129.16) na porta configurada
Qual sequência representa o raciocínio diagnóstico mais eficiente, do geral para o específico?
A) P -> Q -> R -> T -> S
B) R -> Q -> T -> S -> P
C) Q -> R -> P -> S -> T
D) S -> T -> Q -> R -> P
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na combinação de dois fatos: a nova política de NSG foi aplicada recentemente, e as health probes das VMs degradadas usam HTTP na porta 80, enquanto as regras do NSG permitem entrada apenas nas portas 443 e pelo endereço de origem "VirtualNetwork" ou "Internet". O endereço de origem das health probes do Azure Load Balancer é 168.63.129.16, que não se enquadra nas tags de serviço permitidas pelas regras existentes, e a porta 80 não está liberada em nenhuma regra. Como resultado, as probes não chegam às VM-02 e VM-03, que são marcadas como degradadas.
A informação irrelevante no enunciado é a habilitação do Azure Monitor para diagnóstico. Ela é plausível como distrator porque coincidiu temporalmente com o problema, mas monitoramento passivo não interfere na responsividade das VMs.
O distrator mais perigoso é a alternativa A, que sugere uma limitação técnica inexistente entre protocolo de probe e porta de regra. Essa crença levaria o engenheiro a alterar a configuração da probe sem resolver o bloqueio real no NSG, mantendo o ambiente degradado.
Gabarito — Cenário 2
Resposta: B
O enunciado declara explicitamente que a alteração não causa indisponibilidade e que o backend não requer reconfiguração adicional. Diante dessas condições, aguardar 72 horas (alternativa A) significa manter deliberadamente um ambiente com falha de roteamento ativa, o que não é justificável. A correção é de baixo risco e deve ser aplicada imediatamente.
A alternativa C é tecnicamente válida como abordagem de limpeza, mas reconstruir o Load Balancer inteiro para corrigir uma única propriedade de uma regra representa risco operacional desnecessário e viola o princípio de menor impacto em produção.
A alternativa D é uma solução de contorno (workaround) para o cenário em que o Floating IP é intencional e o backend precisa responder pelo IP do frontend. Ela seria aplicável se a causa fosse diferente da descrita, mas neste caso introduz complexidade sem resolver o problema de origem.
O erro de raciocínio dos distratores é tratar restrições de processo (janela de manutenção) como absolutas mesmo quando o risco da correção é nulo e o impacto da inação é concreto.
Gabarito — Cenário 3
Resposta: C
O protocolo Modbus TCP é orientado a sessão: o servidor central abre uma conexão TCP e realiza múltiplos ciclos de polling dentro dela. O Idle Timeout configurado como 4 minutos é inferior ao intervalo entre alguns ciclos de polling do sistema legado, fazendo com que o Load Balancer encerre conexões TCP consideradas ociosas. Quando o servidor central tenta reutilizar a conexão encerrada, o sistema operacional estabelece uma nova conexão TCP, que o Load Balancer roteia para um backend diferente (pois sem Session Persistence cada nova conexão é tratada independentemente). O dispositivo de campo que recebe a nova requisição não tinha contexto da sessão anterior, e o servidor central interpreta a resposta de uma VM diferente como uma duplicação ou inconsistência.
A informação irrelevante é o número de VMs no backend pool (12). Ela sugere a alternativa A como causa plausível, mas o Azure Load Balancer Standard não possui limite prático nesse patamar.
A alternativa B descreve corretamente o comportamento esperado do Load Balancer sem Session Persistence, mas não é a causa das duplicações neste cenário específico: o servidor central não reabre conexões intencionalmente, portanto a ausência de Session Persistence sozinha não explicaria o problema se o Idle Timeout fosse adequado.
O distrator mais perigoso é B, pois levaria a equipe a habilitar Session Persistence sem aumentar o Idle Timeout, o que resolveria parcialmente mas não eliminaria as reconexões forçadas pelo timeout.
Gabarito — Cenário 4
Resposta: B
A sequência correta é R -> Q -> T -> S -> P.
O raciocínio diagnóstico eficiente parte da configuração lógica (a regra está corretamente associada ao frontend e ao backend?), avança para o estado reportado pelo serviço (as probes indicam backends saudáveis?), investiga o bloqueio de rede (o NSG permite o tráfego de probe?), valida a aplicação diretamente (o serviço responde na porta correta?), e só então verifica o estado da VM como último recurso.
A sequência A (P -> Q -> R -> T -> S) começa pelo estado da VM, que é o fator mais improvável de ser a causa em um ambiente onde as VMs foram descritas como em execução. Iniciar por aí desperdiça tempo de diagnóstico.
A sequência D (S -> T -> Q -> R -> P) começa pelo teste direto na VM, que requer acesso via Bastion e é o passo mais operacionalmente custoso. Aplicar esse passo antes de verificar a configuração lógica e o estado das probes inverte a ordem de custo e probabilidade.
A disciplina de diagnóstico progressivo exige que perguntas de alto impacto e baixo custo operacional venham antes de testes diretos que exigem acesso às instâncias.
Árvore de Troubleshooting: Identify appropriate use cases for Azure Load Balancer
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| 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 | Validação ou verificação intermediária |
Ao enfrentar um problema real com o Azure Load Balancer, inicie pelo nó raiz e responda cada pergunta com base no que é observável no ambiente: portal do Azure, métricas do Monitor ou acesso direto às VMs. Cada resposta direciona para o próximo nível de investigação. Nunca pule para um nó de ação sem percorrer o caminho completo desde o sintoma, pois causas diferentes produzem sintomas idênticos e a ação incorreta pode mascarar o problema real sem resolvê-lo.