Laboratório de Troubleshooting: Choose an Azure Load Balancer SKU and tier
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que, após uma janela de manutenção na última sexta-feira, as conexões para um conjunto de VMs de backend pararam de ser estabelecidas. O Load Balancer foi recentemente recriado. O engenheiro responsável confirma que as regras de balanceamento, o health probe e o backend pool estão configurados corretamente e que as VMs estão respondendo localmente.
A saída do comando de verificação de conectividade retorna o seguinte:
$ Test-NetConnection -ComputerName 20.x.x.x -Port 443
ComputerName : 20.x.x.x
RemoteAddress : 20.x.x.x
RemotePort : 443
InterfaceAlias : Ethernet
SourceAddress : 10.0.1.5
TcpTestSucceeded : False
Informações adicionais coletadas pelo engenheiro:
- O Load Balancer recriado é do SKU Standard
- O IP público associado é do tipo Standard
- As VMs estão na sub-rede
subnet-backend(10.0.1.0/24) - O Availability Set das VMs não foi alterado durante a manutenção
- Nenhum Network Security Group foi associado à sub-rede ou às NICs após a recriação do Load Balancer
Qual é a causa raiz da falha de conectividade?
A) O IP público Standard não está corretamente associado à regra de balanceamento.
B) O SKU Standard bloqueia todo o tráfego de entrada por padrão e nenhum NSG foi configurado para permitir o fluxo.
C) O Availability Set foi desconfigurado durante a recriação, removendo as VMs do backend pool.
D) O health probe HTTP está falhando silenciosamente, impedindo que as VMs sejam marcadas como saudáveis.
Cenário 2 — Decisão de Ação
A causa foi identificada: o Load Balancer existente é do SKU Basic e a equipe precisa migrar para o SKU Standard para atender a um novo requisito de SLA contratual. O ambiente está em produção com tráfego ativo. A migração foi aprovada para execução imediata.
Restrições conhecidas:
- O IP público associado ao Load Balancer atual é do tipo Basic
- As VMs do backend pool estão em uma sub-rede sem NSG associado
- Não há janela de manutenção programada; qualquer interrupção deve ser minimizada
- A equipe de segurança ainda não revisou as regras de tráfego necessárias
Qual é a ação correta a tomar neste momento?
A) Recriar o Load Balancer como Standard imediatamente, pois a migração de SKU é a prioridade aprovada.
B) Suspender a migração até que o NSG seja criado e revisado pela equipe de segurança, e até que o IP público seja atualizado para Standard, para evitar bloqueio total de tráfego após a mudança.
C) Migrar apenas o IP público para Standard primeiro e depois recriar o Load Balancer, ignorando o NSG por enquanto.
D) Criar um segundo Load Balancer Standard em paralelo e alterar o DNS para o novo IP, sem encerrar o Load Balancer Basic.
Cenário 3 — Causa Raiz
Um arquiteto reporta que um Load Balancer Standard configurado com tier Global não está distribuindo o tráfego entre os backends regionais como esperado. O tráfego proveniente de clientes na Europa está chegando exclusivamente à região East US, ignorando a região West Europe, que possui backends saudáveis e com menor latência.
Logs do portal mostram:
Backend Pool (Global LB):
- Regional LB East US — Status: Healthy
- Regional LB West Europe — Status: Healthy
Incoming Requests (last 1h):
- Routed to East US: 100%
- Routed to West Europe: 0%
Informações adicionais:
- Ambos os Load Balancers regionais são do SKU Standard
- O Load Balancer da região West Europe foi adicionado ao backend pool há 20 minutos
- O IP público do Load Balancer Global é do tipo Standard
- O time zone do servidor de monitoramento está configurado como UTC+0
- As regras de balanceamento do Load Balancer Global apontam para a porta correta
Qual é a causa raiz mais provável para o comportamento observado?
A) O IP público do Load Balancer Global deveria ser do tipo Basic para suportar roteamento geográfico.
B) O Load Balancer regional West Europe foi adicionado ao backend pool recentemente e o tráfego ainda não convergiu para refletir sua disponibilidade no roteamento global.
C) As regras de balanceamento do Load Balancer Global estão configuradas para afinidade de sessão, fixando clientes existentes ao endpoint East US.
D) O Load Balancer regional West Europe é do SKU errado; apenas Load Balancers Basic podem ser usados como backends de um Load Balancer Global.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "O Load Balancer parou de responder após uma mudança de configuração. Não sabemos o que foi alterado."
Os seguintes passos de investigação estão disponíveis, mas fora de ordem:
- Verificar se há um NSG associado à sub-rede ou NIC que esteja bloqueando o tráfego
- Consultar o Activity Log do Load Balancer para identificar qual operação foi executada e por quem
- Confirmar se o health probe está marcando as VMs do backend como Healthy
- Validar se as regras de balanceamento estão associadas ao frontend IP correto
- Verificar se o SKU do Load Balancer é compatível com o SKU do IP público associado
Qual é a sequência correta de diagnóstico para este cenário?
A) 3 → 1 → 4 → 2 → 5
B) 2 → 5 → 1 → 3 → 4
C) 1 → 3 → 2 → 5 → 4
D) 5 → 4 → 3 → 1 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O SKU Standard do Azure Load Balancer adota uma postura de segurança fechada por padrão. Todo o tráfego de entrada é bloqueado até que um Network Security Group seja explicitamente associado à sub-rede ou à NIC das instâncias de backend. O enunciado confirma que nenhum NSG foi configurado após a recriação do Load Balancer, o que é a pista determinante.
A informação sobre o Availability Set é irrelevante: ele não foi alterado e não interfere no comportamento de segurança do SKU Standard. O health probe pode estar falhando como consequência do bloqueio de NSG, mas não é a causa raiz; tratar o health probe como causa seria confundir sintoma secundário com origem do problema. A associação do IP público Standard está correta segundo o enunciado, tornando A incorreta. O distrator mais perigoso é D, pois um operador poderia perder tempo ajustando o health probe sem jamais resolver o bloqueio real.
Gabarito — Cenário 2
Resposta: B
A restrição crítica neste cenário é dupla: a ausência de NSG e o IP público Basic. Ao migrar para o SKU Standard sem NSG, o tráfego seria imediatamente bloqueado pelo comportamento de segurança padrão do Standard. Além disso, um Load Balancer Standard não pode ser associado a um IP público Basic. Executar a migração sem resolver ambas as dependências resultaria em interrupção total do serviço em produção.
A alternativa A ignora as duas restrições críticas. A alternativa C resolve apenas uma delas (o IP), mas deixa o ambiente exposto ao bloqueio de tráfego pós-migração. A alternativa D poderia ser uma estratégia válida em um contexto de migração planejada, mas não endereça o problema do NSG e do IP antes da virada, além de não ser a ação correta para o momento descrito. A sequência correta é preparar o NSG e o IP antes de executar qualquer mudança no Load Balancer.
Gabarito — Cenário 3
Resposta: B
O tier Global do Azure Load Balancer utiliza roteamento baseado em anycast e propagação de rotas BGP. Quando um novo backend regional é adicionado ao pool, há um período de convergência durante o qual o tráfego pode não ser distribuído imediatamente para o novo endpoint. O fato de o Load Balancer West Europe ter sido adicionado há apenas 20 minutos é a pista central do enunciado.
A informação sobre o time zone do servidor de monitoramento é irrelevante e foi incluída deliberadamente para testar a capacidade de filtro. O IP público Standard é o requisito correto para o tier Global, tornando A incorreta. A alternativa D inverte a realidade: apenas Load Balancers Standard (não Basic) podem ser backends de um Load Balancer Global. A alternativa C descreveria um problema real em outros contextos, mas nenhuma configuração de afinidade de sessão foi mencionada no enunciado.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: 2 → 5 → 1 → 3 → 4.
O ponto de partida correto é o Activity Log (passo 2), pois o enunciado explicita que houve uma mudança de configuração desconhecida. Identificar o que foi alterado é o primeiro passo para direcionar todo o diagnóstico subsequente. Em seguida, verificar a compatibilidade de SKU entre o Load Balancer e o IP público (passo 5) é uma causa estrutural que pode impedir qualquer funcionamento. Depois, investigar bloqueios de NSG (passo 1) e o estado do health probe (passo 3) permite eliminar causas de camada de rede e disponibilidade de backend. Por último, validar as regras de balanceamento e o frontend IP (passo 4) é o refinamento final.
As demais sequências cometem o erro de iniciar pela investigação de sintomas secundários sem antes entender o contexto da mudança, o que leva a diagnósticos circulares e consumo desnecessário de tempo em ambientes de produção.
Árvore de Troubleshooting: Choose an Azure Load Balancer SKU and tier
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro (navy) | Sintoma inicial — ponto de entrada da investigação |
| Azul (blue) | Pergunta diagnóstica — verificação objetiva e observável |
| Vermelho | Causa identificada — origem confirmada do problema |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação intermediária — estado aguardando confirmação |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga as ramificações respondendo cada pergunta diagnóstica com base no que você consegue verificar diretamente no portal ou via comando. Cada resposta elimina um ramo inteiro de hipóteses. O objetivo é chegar a um nó vermelho (causa) ou verde (ação) pelo caminho mais curto possível, sem pular etapas que poderiam revelar causas estruturais anteriores, como incompatibilidade de SKU ou ausência de NSG.