Laboratório de Troubleshooting: Choose between regional and cross-region load balancers
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de infraestrutura relata que um Cross-Region Load Balancer recém-criado não está distribuindo tráfego para nenhuma das regiões configuradas. O ambiente foi provisionado via Azure Portal e a equipe afirma que todos os recursos foram criados corretamente.
Ao investigar, você coleta as seguintes informações:
Cross-Region Load Balancer
SKU: Standard
IP Frontend: 20.10.55.100 (Global, público)
Status: Provisionado com sucesso
Backend Pool
Membro 1: lb-eastus-prod (East US) — IP: 20.20.10.5
Membro 2: lb-brazilsouth (Brazil South) — IP: 10.0.1.4
Health Probe
Protocolo: TCP
Porta: 443
Status East US: Healthy
Status Brazil South: Unhealthy (sem resposta)
Load Balancing Rules
Porta frontend: 443
Porta backend: 443
Session persistence: None
A equipe menciona que o certificado TLS do Load Balancer de Brazil South foi renovado há dois dias, mas que o serviço está respondendo normalmente quando acessado diretamente pelo IP público regional.
Qual é a causa raiz do problema observado?
A) O Cross-Region Load Balancer está com a regra de balanceamento mal configurada, pois a porta de frontend deve ser diferente da porta de backend para tráfego global
B) O membro lb-brazilsouth está configurado com um IP interno (10.0.1.4) no pool de backend do Cross-Region Load Balancer, o que não é suportado; apenas IPs de frontend públicos de Load Balancers regionais Standard são aceitos
C) A renovação do certificado TLS causou uma interrupção temporária que ainda não foi propagada para o health probe do Cross-Region Load Balancer
D) O Cross-Region Load Balancer exige que ambos os membros do backend estejam na mesma zona de disponibilidade para operar corretamente
Cenário 2 — Decisão de Ação
A equipe de operações identificou a causa raiz de um incidente em produção: um Load Balancer regional Standard que serve como backend de um Cross-Region Load Balancer foi acidentalmente migrado para SKU Basic durante uma janela de manutenção. Desde a migração, o Cross-Region Load Balancer parou de aceitar aquele membro no pool de backend e o tráfego global está sendo integralmente direcionado para a única região restante.
O contexto atual é:
- A migração de SKU Basic para Standard exige recriação do recurso, não é uma operação in-place
- A região afetada (West Europe) ainda possui as VMs de backend saudáveis e respondendo
- O Load Balancer Basic recriado ainda não foi adicionado ao Cross-Region Load Balancer
- Existe uma janela de manutenção aprovada em 4 horas
- A única região ativa (East US) está operando com 85% de capacidade e pode sustentar a carga total por até 6 horas sem degradação
Qual é a ação correta a tomar neste momento?
A) Recriar imediatamente o Load Balancer Standard em West Europe e adicioná-lo ao pool do Cross-Region Load Balancer, sem aguardar a janela de manutenção, pois o risco de sobrecarga em East US justifica a urgência
B) Aguardar a janela de manutenção aprovada em 4 horas, recriar o Load Balancer Standard em West Europe, validar as health probes e então adicioná-lo ao pool do Cross-Region Load Balancer
C) Alterar o SKU do Load Balancer Basic existente para Standard diretamente no portal, sem recriação, aproveitando que a janela de manutenção ainda não começou
D) Remover East US do pool do Cross-Region Load Balancer para forçar failover completo para West Europe enquanto o problema é resolvido
Cenário 3 — Causa Raiz
Uma empresa opera uma aplicação crítica com o seguinte desenho de rede:
[Usuários externos]
|
[Cross-Region Load Balancer] — IP Global: 52.100.200.1
|
+-----+-----+
| |
[LB Regional [LB Regional
East US] Southeast Asia]
| |
[VMs East US] [VMs Southeast Asia]
Os usuários de São Paulo relatam latência elevada e conexões ocasionalmente recusadas nas últimas 3 horas. Usuários de Londres não relatam problemas. A equipe de monitoramento compartilha os seguintes dados:
Métricas — Cross-Region Load Balancer (última hora)
Health probe status East US: Healthy
Health probe status Southeast Asia: Healthy
Bytes de saída East US: 12.4 GB
Bytes de saída Southeast Asia: 0.02 GB
Packet count East US: alto
Packet count Southeast Asia: mínimo
Evento registrado — 3 horas atrás:
"Frontend IP configuration updated — Southeast Asia regional LB"
Tipo: alteração de endereço IP de frontend
A equipe argumenta que o problema deve ser na camada de aplicação das VMs de Southeast Asia, pois os health probes estão retornando Healthy para ambas as regiões.
Qual é a causa raiz do problema observado?
A) As VMs de Southeast Asia estão com sobrecarga de CPU, o que explica o baixo volume de tráfego para a região e os health probes ainda passando por operarem em porta diferente da aplicação
B) O IP de frontend do Load Balancer regional de Southeast Asia foi alterado, tornando o endereço registrado no pool de backend do Cross-Region Load Balancer inválido; o tráfego está sendo enviado quase integralmente para East US, aumentando a latência para usuários de São Paulo
C) O Cross-Region Load Balancer está com o algoritmo de distribuição priorizando East US por proximidade geográfica dos servidores de anycast, comportamento esperado que não requer intervenção
D) Os health probes do Cross-Region Load Balancer estão configurados com protocolo incorreto e retornam falso positivo de Healthy para Southeast Asia, enquanto a aplicação está efetivamente inativa
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte relato: "O Cross-Region Load Balancer está aceitando conexões, mas parte dos usuários de uma região específica está recebendo respostas com latência muito acima do esperado. Não há alertas de health probe ativos."
Os passos de investigação disponíveis são:
- Verificar se o IP de frontend dos Load Balancers regionais no pool de backend do Cross-Region Load Balancer corresponde ao IP público atual de cada regional
- Analisar as métricas de distribuição de tráfego do Cross-Region Load Balancer por região de backend para identificar desequilíbrio
- Confirmar que os Load Balancers regionais adicionados ao pool possuem SKU Standard e IP público, não Basic ou interno
- Verificar a latência de rede entre os pontos de presença do anycast e os backends regionais usando Network Watcher
- Analisar métricas de CPU e throughput nas VMs de backend da região com latência elevada
Qual é a sequência correta de investigação?
A) 3 → 1 → 2 → 4 → 5
B) 2 → 1 → 3 → 5 → 4
C) 5 → 4 → 2 → 1 → 3
D) 1 → 3 → 4 → 5 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no endereço IP do segundo membro do pool de backend: 10.0.1.4 é um endereço IP privado (RFC 1918), não um IP público. O Cross-Region Load Balancer aceita exclusivamente IPs de frontend públicos de Load Balancers regionais Standard como membros do pool de backend. Um endereço IP interno invalida o membro e impede qualquer distribuição de tráfego para aquela entrada.
A informação sobre a renovação do certificado TLS é propositalmente irrelevante. O fato de o serviço responder diretamente pelo IP regional confirma que a aplicação está saudável, eliminando qualquer hipótese de falha relacionada ao certificado. Focar nessa informação é o erro de diagnóstico que o distrator C explora.
A alternativa D é uma restrição inexistente: o Cross-Region Load Balancer opera entre regiões distintas por design e não impõe requisitos de zona de disponibilidade entre os membros.
O distrator mais perigoso é C, porque leva o time a investigar renovação de certificado e propagação de configuração, desperdiçando tempo enquanto o problema real é estrutural e imediato.
Gabarito — Cenário 2
Resposta: B
O cenário apresenta todas as condições para aguardar a janela de manutenção: East US sustenta a carga total por até 6 horas sem degradação, a janela ocorre em 4 horas, e a recriação do Load Balancer Standard exige uma operação destrutiva que deve ser planejada. Agir antes da janela sem necessidade real expõe o ambiente a erros de configuração em produção sem o suporte completo previsto para a janela.
A alternativa A desconsidera a restrição crítica de que East US tem capacidade suficiente pelo tempo necessário; a urgência invocada não é real dado o contexto numérico fornecido. A alternativa C é factualmente incorreta: a migração de SKU Basic para Standard não é possível in-place e resultaria em falha de operação. A alternativa D causaria interrupção total do serviço, pois West Europe está sem Load Balancer Standard funcional no pool.
O raciocínio correto aqui é: validar se as restrições de tempo e capacidade permitem a abordagem controlada antes de assumir urgência.
Gabarito — Cenário 3
Resposta: B
A causa raiz está no evento registrado 3 horas atrás: o IP de frontend do Load Balancer regional de Southeast Asia foi alterado. O Cross-Region Load Balancer armazena uma referência ao IP de frontend do regional no momento em que ele foi adicionado ao pool. Quando esse IP muda, a referência fica inválida. O tráfego destinado a Southeast Asia falha silenciosamente ou é descartado, forçando o Cross-Region Load Balancer a concentrar praticamente todo o fluxo em East US.
Os health probes do Cross-Region Load Balancer verificam o endpoint do backend regional, mas se o probe ainda alcança algum IP válido na cadeia, pode retornar Healthy mesmo com a distribuição comprometida. Isso explica por que os probes passam enquanto o comportamento de roteamento está errado.
A afirmação da equipe de que o problema é na camada de aplicação das VMs é o distrator representado pela alternativa A, e é o erro de diagnóstico clássico de focar no componente mais próximo da falha visível em vez de investigar a cadeia de configuração.
A alternativa C descreve um comportamento como se fosse esperado, o que desorientaria o time e encerraria a investigação prematuramente.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 2 → 1 → 3 → 5 → 4.
O raciocínio parte do sintoma mais diretamente observável: analisar as métricas de distribuição de tráfego (passo 2) confirma imediatamente se há desequilíbrio entre regiões, localizando o problema antes de investigar causas. Em seguida, verificar se os IPs de frontend dos regionais no pool estão corretos (passo 1) identifica a causa mais comum de desequilíbrio silencioso. Confirmar SKU e tipo de IP (passo 3) valida a compatibilidade estrutural dos membros. Analisar métricas nas VMs de backend (passo 5) descarta sobrecarga na camada de computação. Por último, usar Network Watcher para latência de anycast (passo 4) é o passo mais granular e custoso, reservado para quando as causas mais comuns foram eliminadas.
A alternativa A começa pela validação de SKU, que é uma verificação estrutural válida mas menos eficiente como primeiro passo quando o sintoma já aponta para desequilíbrio de roteamento. A alternativa C começa nas VMs, invertendo a lógica de diagnóstico de fora para dentro. A alternativa D começa pela verificação de IP sem antes confirmar que existe desequilíbrio, o que pode levar o engenheiro a investigar a causa certa pelo motivo errado.
Árvore de Troubleshooting: Choose between regional and cross-region load balancers
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado. A cada nó de pergunta, responda com base no que você consegue verificar diretamente no portal ou via CLI, seguindo o caminho correspondente. Os nós vermelhos indicam onde parar para confirmar a causa antes de agir. Os nós verdes indicam a ação corretiva precisa para aquela causa. Os nós laranjas indicam que a ação foi tomada e que é necessário validar se o comportamento voltou ao normal antes de encerrar o diagnóstico.