Laboratório de Troubleshooting: Choose between public and internal load balancers
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
O time de operações recebe o seguinte alerta às 14h32: instâncias de uma camada de aplicação interna estão com o health probe do load balancer retornando falha, e o tráfego originado pelo frontend deixou de ser distribuído entre elas. O ambiente está descrito abaixo:
Load Balancer SKU: Standard (Internal)
Frontend IP: 10.1.2.10 (subnet: app-subnet, 10.1.2.0/24)
Backend pool: vm-app-01 (10.1.3.4), vm-app-02 (10.1.3.5)
Health Probe: HTTP, porta 8080, path /health
Probe interval: 5s, unhealthy threshold: 2
NSG na NIC das VMs: permite TCP 443 inbound de qualquer origem
Última alteração: deploy de nova versão da aplicação às 14h20
Métrica Azure Monitor: DipAvailability = 0 para ambas as VMs
O engenheiro verifica que as VMs estão ligadas, respondem a ping internamente e o sistema operacional está estável. O serviço de aplicação subiu sem erros aparentes no log do SO.
Qual é a causa raiz da falha observada?
A) O IP de frontend do Internal Load Balancer está em uma subnet diferente da subnet das VMs do backend pool, o que impede o roteamento correto do health probe.
B) O NSG associado às NICs das VMs bloqueia o tráfego do health probe, pois permite apenas TCP 443 e o probe está configurado na porta 8080.
C) O intervalo do health probe de 5 segundos é insuficiente para aplicações que demoram mais de 10 segundos para responder, gerando falsos negativos.
D) O health probe do Standard Load Balancer requer que o path /health retorne HTTP 200; como o deploy ocorreu minutos antes, a nova versão provavelmente alterou o comportamento desse endpoint.
Cenário 2 — Decisão de Ação
O time de rede identificou que um Public Load Balancer Standard SKU em produção não possui nenhuma Outbound Rule configurada, e as VMs no backend pool não têm IP público atribuído diretamente. A causa foi confirmada: as VMs não conseguem estabelecer conexões de saída com a internet.
O ambiente possui as seguintes restrições:
- O load balancer atende requisições de clientes externos 24 horas por dia, 7 dias por semana, sem janela de manutenção acordada
- Qualquer alteração no frontend IP ou nas regras de balanceamento exige aprovação de change management com 48 horas de antecedência
- O time tem permissão para adicionar e modificar recursos na subnet sem aprovação prévia
- Existe um NAT Gateway já provisionado na subscription, atualmente desassociado a qualquer subnet
Qual é a ação correta a tomar neste momento?
A) Criar uma Outbound Rule no Public Load Balancer, alocando um novo IP público para saída.
B) Associar o NAT Gateway já provisionado à subnet onde as VMs estão localizadas, resolvendo o problema de saída sem alterar o load balancer.
C) Atribuir um IP público diretamente à NIC de cada VM para que elas possam fazer saída independente do load balancer.
D) Aguardar a abertura de uma janela de manutenção aprovada antes de qualquer intervenção, pois qualquer alteração pode impactar o frontend.
Cenário 3 — Causa Raiz
Um desenvolvedor reporta que uma aplicação cliente, rodando em uma VM na vnet-prod (10.0.0.0/16), não consegue alcançar o endpoint interno de uma API balanceada por um Internal Load Balancer. O frontend IP do ILB é 10.0.5.100.
Resultado do teste da VM cliente:
$ curl -v http://10.0.5.100:80/api/test
* Trying 10.0.5.100:80...
* connect to 10.0.5.100 port 80 failed: Connection timed out
Configuração do ILB:
Frontend IP: 10.0.5.100 (subnet: ilb-frontend-subnet, 10.0.5.0/24)
Backend pool: vm-api-01 (10.0.6.4), vm-api-02 (10.0.6.5)
LB Rule: TCP 80 -> TCP 80
Health probe: TCP 80 — Status: Healthy (ambas as VMs)
Floating IP: Disabled
VM cliente: 10.0.1.15 (subnet: client-subnet, 10.0.1.0/24)
NSG na subnet do cliente: permite todo tráfego outbound
NSG na subnet ilb-frontend-subnet: permite inbound TCP 80 de 10.0.0.0/16
O engenheiro confirma que as duas VMs do backend respondem corretamente a requisições diretas na porta 80. O health probe está marcando ambas como saudáveis. A VNet não tem peering com outras redes.
Qual é a causa raiz do problema?
A) O NSG da subnet ilb-frontend-subnet está bloqueando o tráfego, pois a regra permite apenas o range 10.0.0.0/16 e a VM cliente está fora desse range.
B) O Internal Load Balancer não roteia tráfego de clientes que estão em subnets diferentes da subnet do frontend, exigindo que cliente e frontend estejam na mesma subnet.
C) O NSG associado à subnet das VMs do backend pool está bloqueando o tráfego encaminhado pelo load balancer, impedindo que as requisições cheguem às instâncias.
D) A VM cliente está tentando alcançar diretamente o IP do frontend do ILB, mas há um NSG na subnet client-subnet ou na NIC da VM cliente bloqueando o tráfego de saída para a porta 80 em direção ao range 10.0.5.0/24.
Cenário 4 — Impacto Colateral
Um engenheiro identificou que VMs em um Public Load Balancer Standard SKU estavam sem acesso de saída à internet. Para resolver, ele removeu as VMs do backend pool do Load Balancer Standard e associou um IP público diretamente à NIC de cada VM, restaurando a conectividade de saída imediatamente.
O problema de saída foi resolvido. O load balancer continua operando e as regras de balanceamento de entrada continuam ativas.
Qual consequência secundária essa ação pode causar?
A) As VMs passam a responder requisições de entrada diretamente pelo IP público da NIC, contornando o load balancer e expondo-as sem as proteções de regras do frontend.
B) O Load Balancer Standard perde a capacidade de fazer health probe nas VMs removidas do backend pool, tornando as métricas de disponibilidade imprecisas no Azure Monitor.
C) Ao associar um IP público à NIC de uma VM que ainda está no backend pool de um Load Balancer Standard, o tráfego de saída passa a usar o IP da NIC, mas o tráfego de entrada continua sendo roteado pelo load balancer, o que pode criar assimetria de rota para conexões estabelecidas.
D) O IP público associado à NIC da VM é automaticamente promovido para o frontend do load balancer, sobrescrevendo as regras existentes e causando falha nas conexões de entrada dos demais clientes.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na combinação de dois dados: o health probe está configurado na porta 8080 via HTTP, e o NSG nas NICs das VMs permite apenas TCP 443 inbound. O Standard Load Balancer envia health probes diretamente às NICs das VMs, e esse tráfego deve ser permitido explicitamente pelo NSG. Como a porta 8080 não está liberada, os probes falham, e o load balancer marca ambas as instâncias como não saudáveis, cessando a distribuição de tráfego.
A informação irrelevante neste cenário é o estado operacional das VMs: o fato de responderem a ping e o SO estar estável não tem relação com o comportamento do health probe HTTP na porta específica.
A alternativa A representa um equívoco comum: o frontend do ILB pode legalmente estar em uma subnet diferente da subnet dos backends. A C é plausível em tese, mas o intervalo de 5 segundos é padrão e não há evidência de lentidão na aplicação. A D descreve um problema real de deploy, mas o enunciado indica que o serviço subiu sem erros, e o probe falhou nas duas VMs simultaneamente logo após o deploy de uma versão que não alterou o endpoint, enquanto a porta bloqueada no NSG explica melhor o padrão observado.
O distrator mais perigoso é D, pois o timing do deploy cria uma correlação tentadora que pode desviar o diagnóstico da causa real.
Gabarito — Cenário 2
Resposta: B
A restrição crítica é que qualquer alteração no load balancer requer aprovação com 48 horas de antecedência, e criar uma Outbound Rule (alternativa A) é uma alteração diretamente no recurso do load balancer. Atribuir IPs públicos às NICs das VMs (alternativa C) também é uma solução válida tecnicamente, mas cria exposição pública desnecessária e não aproveita o NAT Gateway já disponível.
O enunciado informa explicitamente que o time tem permissão para modificar recursos na subnet sem aprovação prévia. Associar o NAT Gateway existente à subnet é exatamente esse tipo de operação: uma alteração na subnet, não no load balancer, que resolve o problema de saída sem tocar no frontend ou nas regras de balanceamento.
A alternativa D é o distrator mais perigoso em ambientes corporativos: a tendência de aguardar aprovação mesmo quando uma ação permitida está disponível pode prolongar desnecessariamente um incidente de produção.
Gabarito — Cenário 3
Resposta: D
O diagnóstico correto exige eliminar as causas aparentes e focar na camada que não foi verificada. O health probe está saudável, as VMs respondem diretamente, o NSG da subnet do frontend permite o range correto, e não há peering com redes externas. A VM cliente está em 10.0.1.15, que pertence a 10.0.0.0/16, portanto está dentro da faixa permitida pelo NSG do frontend.
O que não foi verificado no enunciado é o NSG na subnet client-subnet ou na NIC da VM cliente para saída em direção à subnet 10.0.5.0/24 na porta 80. O tráfego de saída permissivo descrito no NSG da subnet cliente refere-se ao nível da subnet, mas um NSG associado diretamente à NIC da VM pode ter regras mais restritivas que sobrepõem essa permissão.
A alternativa A é o distrator mais atrativo, mas falha na matemática: 10.0.1.15 está dentro de 10.0.0.0/16. A B descreve um comportamento que não existe: o ILB roteia tráfego de qualquer origem dentro da VNet (ou redes conectadas), não apenas da mesma subnet do frontend. A C é plausível, mas o enunciado afirma que os probes estão saudáveis, o que significa que o tráfego do load balancer chega às VMs.
Gabarito — Cenário 4
Resposta: C
Quando uma VM está em um backend pool de um Load Balancer Standard e também possui um IP público associado à sua NIC, a Azure aplica a seguinte regra de precedência: o tráfego de saída usa o IP público da NIC, enquanto o tráfego de entrada ainda é roteado pelo load balancer. Isso cria uma assimetria de rota para conexões TCP estabelecidas: o pacote de entrada chega via load balancer (IP do frontend), mas a resposta sai pelo IP público da NIC. Para conexões stateless, esse comportamento pode ser imperceptível, mas para conexões TCP de longa duração ou em cenários com inspeção de estado, a assimetria pode causar drops e comportamentos intermitentes.
A alternativa A descreve um risco real, mas incompleto: as VMs permanecem no backend pool, portanto o tráfego de entrada ainda passa pelo load balancer. A B é falsa: health probes não dependem da presença das VMs no backend pool para funcionar; elas continuam no pool. A D descreve um comportamento que não existe na plataforma Azure: IPs de NIC não sobrescrevem automaticamente frontends de load balancers.
Árvore de Troubleshooting: Choose between public and internal load balancers
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou estado observável) |
| 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 identificando se a falha é de tráfego de entrada ou de saída. Siga cada bifurcação respondendo objetivamente à pergunta do nó com base no que você pode observar ou medir no ambiente, como estado do health probe, regras de NSG, presença de Outbound Rules e tipo de load balancer. Cada caminho termina em uma causa nomeada ou em uma ação concreta, evitando que o diagnóstico derive para hipóteses não verificadas.