Laboratório de Troubleshooting: Create and Configure an Azure Load Balancer
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações recebe alertas de que o tráfego de entrada parou de ser distribuído para as VMs de um backend pool. O ambiente usa um Azure Load Balancer Standard público. As VMs estão em execução, o agente de monitoramento instalado nelas reporta CPU e memória normais, e o time de rede confirma que a VNet e as subnets não sofreram alterações recentes.
O engenheiro responsável coleta as seguintes informações:
Load Balancer SKU: Standard
Frontend IP: 20.10.5.100 (público, estático)
Backend pool: VM1, VM2, VM3 (mesma VNet, subnet: 10.0.2.0/24)
Health probe: HTTP / porta 8080 / path: /healthz / intervalo: 15s / limiar: 2
Load balancing rule: TCP / porta 80 -> porta 80
Resultado das probes (portal Azure):
VM1: Unhealthy
VM2: Unhealthy
VM3: Unhealthy
Teste direto via Bastion Host para VM1:
curl http://10.0.2.4:8080/healthz
HTTP 200 OK
Alterações recentes registradas no Activity Log:
- Resize de VM1 (ontem às 23h14)
- Atualização de tag no Resource Group (hoje às 08h02)
Qual é a causa raiz do problema observado?
A. O resize da VM1 desassociou a interface de rede do backend pool, removendo todas as VMs do pool automaticamente
B. A health probe está configurada com protocolo HTTP e o Load Balancer Standard não suporta probes HTTP, apenas TCP
C. Um NSG na subnet das VMs está bloqueando o IP de origem das health probes, impedindo que o Load Balancer valide a disponibilidade das instâncias
D. A regra de balanceamento usa protocolo TCP na porta 80, mas a probe monitora a porta 8080; como a aplicação não responde na porta 80, o tráfego é descartado
Cenário 2 — Decisão de Ação
A equipe de plataforma identificou que o Load Balancer Standard público de um ambiente de produção não possui nenhuma outbound rule configurada e nenhum NAT Gateway associado à subnet do backend pool. As VMs do pool precisam acessar um serviço externo de licenciamento na internet para validar tokens a cada hora. Nos últimos 30 minutos, o serviço de licenciamento começou a retornar timeout nas VMs, e os logs da aplicação mostram falhas de conexão de saída.
A causa foi confirmada: as VMs perderam conectividade de saída para a internet porque o SNAT implícito não está mais disponível no SKU Standard sem outbound rule.
Restrições do ambiente:
- Janela de manutenção: apenas aos sábados entre 00h e 04h (hoje é terça-feira)
- As VMs não podem ser reiniciadas durante o horário comercial
- O time de rede tem permissão para modificar configurações do Load Balancer e criar recursos novos sem aprovação adicional
- A aplicação tolera até 5 minutos de indisponibilidade no serviço de licenciamento antes de entrar em modo degradado
Qual é a ação correta a tomar neste momento?
A. Aguardar a janela de manutenção do sábado para configurar uma outbound rule no Load Balancer, pois alterações de rede em produção fora da janela não são permitidas
B. Associar um NAT Gateway à subnet do backend pool imediatamente, pois essa operação não requer reinicialização das VMs e restaura a conectividade de saída sem impacto no tráfego de entrada
C. Atribuir um IP público individual a cada VM do backend pool para restaurar o SNAT por instância, reiniciando cada VM após a atribuição para aplicar a configuração
D. Criar uma outbound rule no Load Balancer apontando para um novo IP público de frontend dedicado à saída, mas aguardar a aprovação do time de segurança antes de aplicar
Cenário 3 — Causa Raiz
Um Load Balancer Standard interno foi configurado para expor um serviço de API na porta 443 dentro de uma VNet. O frontend IP é 172.16.1.10. Clientes na mesma VNet relatam que conseguem estabelecer conexão TCP com 172.16.1.10:443, mas recebem reset imediato após o handshake TLS.
O engenheiro analisa o ambiente:
Frontend IP: 172.16.1.10 (interno, estático)
Backend pool: API-VM1, API-VM2
Health probe: TCP / porta 443 / intervalo: 5s / limiar: 2
Status das probes:
API-VM1: Healthy
API-VM2: Healthy
Configuração da load balancing rule:
Protocolo: TCP
Porta frontend: 443
Porta backend: 443
Floating IP: Habilitado
Session persistence: None
Certificado TLS instalado nas VMs: válido, emitido para CN=api.internal.corp
Teste direto na VM (sem Load Balancer):
openssl s_client -connect 172.16.1.10:443 (via IP da VM): handshake OK
Informação adicional: o time de segurança atualizou a política de certificados há duas semanas, mas os certificados nas VMs foram renovados e validados manualmente ontem.
Qual é a causa raiz do problema observado?
A. O certificado TLS foi emitido para o nome api.internal.corp e não para o IP 172.16.1.10, causando falha de validação no cliente
B. Com o Floating IP habilitado, os pacotes chegam às VMs com o IP de destino 172.16.1.10; como as VMs não têm esse IP configurado em nenhuma interface, o stack TCP da VM encerra a conexão após o handshake
C. O Load Balancer Standard interno não suporta tráfego TLS na porta 443 sem um Application Gateway na frente
D. A health probe TCP está marcando as VMs como Healthy mesmo com o serviço TLS falhando, pois TCP e TLS operam em camadas diferentes
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "O Load Balancer público parou de responder na porta 80 após uma atualização de configuração feita há 20 minutos. Clientes externos recebem timeout."
Os seguintes passos de investigação estão disponíveis, mas fora de ordem:
- Verificar se a load balancing rule na porta 80 existe e está associada ao frontend IP correto
- Confirmar se as VMs do backend pool estão com status Healthy nas health probes
- Validar se o NSG associado à subnet ou à NIC das VMs permite tráfego de entrada na porta 80 e da origem
168.63.129.16 - Testar conectividade direta com o IP de uma das VMs do backend pool na porta 80, sem passar pelo Load Balancer
- Verificar se o frontend IP público do Load Balancer está ativo e com o endereço correto
Qual é a sequência de diagnóstico correta, partindo do ponto de falha mais externo em direção à causa mais interna?
A. 2 -> 1 -> 5 -> 3 -> 4
B. 5 -> 1 -> 2 -> 3 -> 4
C. 1 -> 5 -> 3 -> 2 -> 4
D. 3 -> 5 -> 1 -> 2 -> 4
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista definitiva está na contradição entre os dois dados coletados: as probes marcam todas as VMs como Unhealthy, mas um teste direto via Bastion na porta 8080 do endpoint /healthz retorna HTTP 200. Isso significa que a aplicação está funcionando corretamente e respondendo na porta e path configurados na probe. O que está falhando é o caminho entre o Load Balancer e as VMs, não a aplicação em si.
O Load Balancer Standard envia health probes a partir do endereço especial 168.63.129.16. Se um NSG na subnet ou na NIC das VMs não tiver uma regra explícita permitindo tráfego de entrada desse IP (ou da tag de serviço AzureLoadBalancer), as probes são descartadas silenciosamente. O Load Balancer interpreta a ausência de resposta como falha e marca as instâncias como Unhealthy, parando o roteamento.
A informação sobre o resize da VM1 é irrelevante: resize não remove VMs de backend pools nem afeta outras VMs do pool. A alternativa B é falsa: HTTP é um protocolo válido para probes no SKU Standard. A alternativa D representa um equívoco clássico de confundir a porta da probe com a porta da regra de balanceamento; essas duas configurações são independentes e o tráfego de dados ser na porta 80 não interfere na probe que monitora a porta 8080.
O distrator mais perigoso é o A: em um cenário real de pressão, o resize recente é a mudança mais visível no Activity Log e pode induzir o engenheiro a investigar a VM1 individualmente, atrasando o diagnóstico correto.
Gabarito — Cenário 2
Resposta: B
A causa está confirmada no enunciado; o desafio é escolher a ação correta dentro das restrições. A restrição crítica é que as VMs não podem ser reiniciadas durante o horário comercial. Isso elimina a alternativa C imediatamente, pois atribuir IPs públicos individuais a VMs em execução pode não exigir reinicialização em todos os casos, mas o enunciado explicita essa restrição como impeditivo.
Associar um NAT Gateway a uma subnet é uma operação de plano de controle que não afeta as VMs em execução e não exige reinicialização. A conectividade de saída é restaurada em segundos após a associação. Essa é a ação menos invasiva e mais rápida dentro das restrições.
A alternativa A ignora o impacto ativo em produção: o serviço de licenciamento já está falhando há 30 minutos e a aplicação entrará em modo degradado em menos de 5 minutos. Aguardar o sábado não é viável. A alternativa D inventa uma restrição de aprovação do time de segurança que não existe no enunciado para outbound rules, e também ignora o tempo de resposta necessário. A restrição de aprovação mencionada no enunciado é apenas para outros tipos de alteração, não para configurações do Load Balancer.
Gabarito — Cenário 3
Resposta: B
O comportamento descrito, conexão TCP estabelecida seguida de reset imediato após o handshake TLS, é o comportamento exato que ocorre quando uma VM recebe um pacote destinado a um IP que não está configurado em nenhuma de suas interfaces. Com o Floating IP habilitado, o Load Balancer entrega o pacote com o IP de destino preservado como 172.16.1.10. Se a VM não tiver esse IP configurado em sua interface de rede ou loopback, o stack de rede do sistema operacional aceita o pacote TCP (porque a porta está aberta), mas o processo TLS que faz o bind no IP próprio da VM não reconhece a conexão como sua e emite um reset.
A pista está no teste direto: openssl s_client -connect <IP da VM>:443 funciona porque nesse caso o destino é o IP real da VM, que ela reconhece. O mesmo teste via 172.16.1.10 falharia.
A informação sobre a atualização de política de certificados há duas semanas é irrelevante: os certificados foram renovados e validados ontem, e o handshake TCP é estabelecido antes de qualquer validação de certificado pelo cliente. A alternativa A confunde falha de validação de certificado pelo cliente com falha de conexão TCP; uma falha de certificado ocorre dentro do TLS, não redefine a conexão em nível TCP. A alternativa C é falsa: Load Balancers Standard internos suportam qualquer porta TCP, incluindo 443. A alternativa D descreve um fato correto (TCP e TLS são camadas diferentes), mas não é a causa do problema observado.
Gabarito — Cenário 4
Resposta: B
A sequência correta de diagnóstico para um Load Balancer que parou de responder externamente segue a lógica de validação de fora para dentro, do plano de controle para o plano de dados:
5 -> 1 -> 2 -> 3 -> 4
Primeiro, confirma-se que o frontend IP está ativo e correto (passo 5): sem isso, nenhuma outra investigação faz sentido, pois o problema pode ser simplesmente que o IP mudou ou foi desassociado. Em seguida, valida-se a load balancing rule (passo 1) para garantir que a porta 80 está mapeada para o frontend correto. O próximo passo é verificar o status das health probes (passo 2), pois se as VMs estão Unhealthy, o Load Balancer não roteia tráfego independentemente de qualquer outra configuração. Depois, investiga-se o NSG (passo 3) para identificar bloqueios de rede que possam estar impedindo tanto as probes quanto o tráfego de dados. Por último, testa-se a conectividade direta com a VM (passo 4) para isolar se o problema está no Load Balancer ou na aplicação.
A alternativa A começa pelo status das probes antes de validar se o frontend e a regra existem, o que pode levar o engenheiro a investigar as VMs antes de confirmar que o próprio Load Balancer está corretamente configurado. A alternativa C começa pela regra, ignorando que o frontend pode ter sido o elemento alterado na atualização recente. A alternativa D começa pelo NSG, que é uma causa possível mas não a mais externa a verificar.
Árvore de Troubleshooting: Create and Configure an Azure Load Balancer
Legenda de cores:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial ou ponto de entrada |
| Azul medio | Pergunta diagnostica ou ponto de decisao |
| Laranja | Verificacao ou validacao intermediaria |
| Verde | Acao recomendada ou resolucao |
| Vermelho | Causa identificada que exige investigacao aprofundada |
Para usar esta árvore diante de um problema real, comece pelo nó raiz que representa o sintoma observado e responda cada pergunta de diagnóstico com base no que for verificável no portal, nos logs ou via teste direto. Cada ramificação elimina uma hipótese e direciona para a próxima verificação, evitando que ações corretivas sejam tomadas antes de o diagnóstico estar completo. O objetivo é chegar a um nó verde de ação recomendada somente após percorrer o caminho correto de validação.