Laboratório de Troubleshooting: Plan and configure subnet delegation
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de infraestrutura implantou com sucesso o Azure SQL Managed Instance em uma sub-rede chamada snet-sqlmi há três semanas. A sub-rede está configurada com o bloco 10.2.1.0/24, possui um NSG e uma UDR associados, e a delegação Microsoft.Sql/managedInstances foi aplicada corretamente.
Na última semana, a equipe tentou provisionar uma segunda instância gerenciada na mesma sub-rede para atender uma nova carga de trabalho. O provisionamento falhou com o seguinte erro:
Deployment failed. Subnet 'snet-sqlmi' does not have enough free IP addresses
to allocate resources for the new managed instance.
A equipe verifica o estado da sub-rede e obtém a seguinte saída:
Address space : 10.2.1.0/24
Total IPs : 256
Reserved (Azure): 5
In use : 238
Available : 13
O time de redes reporta que o NSG possui 47 regras de entrada e saída configuradas, e que a UDR contém 12 entradas de rota. Um engenheiro sugere que as regras do NSG estão consumindo endereços IP virtuais e propõe remover regras redundantes para liberar espaço.
Qual é a causa raiz do problema?
A) O NSG com 47 regras está consumindo endereços IP virtuais na sub-rede, reduzindo o espaço disponível para novas instâncias.
B) O bloco /24 foi dimensionado sem considerar que cada instância do SQL Managed Instance consome um número significativo de endereços IP além do endereço principal, e o espaço disponível é insuficiente para uma segunda instância.
C) A delegação Microsoft.Sql/managedInstances limita a sub-rede a uma única instância ativa, impedindo o provisionamento de uma segunda instância independentemente do espaço de endereçamento.
D) A UDR com 12 entradas de rota está fragmentando o espaço de endereçamento da sub-rede e impedindo a alocação de blocos contíguos necessários para o SQL Managed Instance.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: a sub-rede snet-webapp foi configurada com a delegação Microsoft.Web/serverFarms, mas a equipe também precisa implantar, na mesma sub-rede, um conjunto de máquinas virtuais para agentes de monitoramento interno. O ambiente é de produção, em operação contínua. O App Service integrado à sub-rede está em funcionamento e atendendo requisições de usuários finais.
A equipe possui as seguintes restrições documentadas:
- Não é permitido causar indisponibilidade do App Service durante o horário comercial
- A janela de manutenção disponível é das 02h às 04h no horário local
- A sub-rede
snet-webapppossui apenas 18 endereços IP disponíveis - Existe uma sub-rede
snet-monitoringvazia, com bloco10.3.5.0/26, sem delegação configurada, disponível na mesma VNet
Qual é a ação correta a tomar neste momento?
A) Remover a delegação da sub-rede snet-webapp imediatamente para permitir a implantação das VMs de monitoramento, e reconfigurar a delegação após a implantação.
B) Implantar as VMs de monitoramento diretamente na sub-rede snet-webapp, pois a delegação Microsoft.Web/serverFarms permite a coexistência de outros recursos em determinados contextos.
C) Implantar as VMs de monitoramento na sub-rede snet-monitoring, que não possui delegação e está disponível na mesma VNet, sem alterar a configuração da sub-rede de produção.
D) Aguardar a janela de manutenção, remover o App Service Plan, excluir a delegação, implantar as VMs e recriar o App Service Plan com nova integração de VNet.
Cenário 3 — Causa Raiz
Um arquiteto de nuvem recebe o seguinte relato de uma equipe de desenvolvimento:
"Configuramos a delegação corretamente, criamos o App Service Plan e tentamos fazer a integração de VNet, mas o portal continua dizendo que não há sub-redes disponíveis para seleção, mesmo com a sub-rede delegada visível na lista."
O arquiteto analisa a configuração e coleta as seguintes informações:
VNet: vnet-app-prod
Region: East US
Subnet: snet-appint
Address: 10.4.2.128/28
Delegation: Microsoft.Web/serverFarms
NSG: nsg-appint (associado)
UDR: nenhuma
App Service Plan:
Name: asp-prod-01
SKU: B1 (Basic)
Region: Brazil South
OS: Windows
O NSG associado à sub-rede possui as regras padrão do Azure e nenhuma regra customizada de bloqueio. A sub-rede possui 9 endereços IP disponíveis. A delegação foi aplicada há dois dias sem erros.
Qual é a causa raiz do problema?
A) O bloco /28 é insuficiente para a integração de VNet do App Service, que exige no mínimo um bloco /26.
B) O NSG sem regras customizadas está impedindo a integração porque as regras padrão bloqueiam o tráfego de gerenciamento do App Service.
C) O App Service Plan está em uma região diferente da VNet, e a integração de VNet regional exige que ambos estejam na mesma região.
D) A delegação Microsoft.Web/serverFarms requer que uma UDR esteja associada à sub-rede antes que a integração de VNet possa ser concluída.
Cenário 4 — Impacto Colateral
Uma equipe identifica que a sub-rede snet-aci está sem espaço de endereçamento disponível, impedindo novos provisionamentos de grupos de contêiner. Para resolver o problema, a equipe decide excluir a sub-rede e recriá-la com um bloco /23 maior, mantendo a mesma delegação Microsoft.ContainerInstance/containerGroups.
A ação é executada com sucesso: a sub-rede antiga é removida, a nova é criada, a delegação é reaplicada e os novos grupos de contêiner são provisionados sem erros.
Qual consequência secundária essa ação pode causar?
A) A delegação reaplicada em uma sub-rede recém-criada é tratada pelo Azure como uma configuração nova e pode ter um período de propagação de até 24 horas antes de aceitar implantações.
B) Todos os grupos de contêiner que estavam em execução na sub-rede original perdem sua conectividade de rede permanentemente, pois seus endereços IP privados eram vinculados à sub-rede excluída.
C) A nova sub-rede com bloco /23 passa a exigir automaticamente uma UDR associada, pois sub-redes maiores que /24 com delegação ativa requerem controle de rota explícito.
D) O Azure interpreta a nova sub-rede como uma sub-rede sem histórico de delegação e ignora a configuração de delegação reaplicada até que um recurso seja implantado manualmente.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A saída do comando mostra claramente que 238 dos 251 endereços utilizáveis já estão em uso, restando apenas 13. O Azure SQL Managed Instance é notoriamente intensivo em consumo de endereços IP: cada instância consome dezenas de endereços para nós de gerenciamento, listeners, réplicas internas e componentes de infraestrutura do serviço gerenciado. Uma segunda instância tipicamente requer entre 32 e mais de 100 endereços dependendo da configuração, tornando 13 endereços insuficientes.
A pista decisiva está na saída do comando: o espaço está genuinamente esgotado por uso real, não por qualquer disfunção técnica.
A informação sobre o NSG com 47 regras e a UDR com 12 entradas são informações irrelevantes propositalmente incluídas. Regras de NSG e entradas de UDR não consomem endereços IP de sub-rede; elas operam no plano de controle e de dados, respectivamente, sem afetar o espaço de endereçamento disponível.
O distrator mais perigoso é A, pois o engenheiro do enunciado já sugere essa ação incorreta. Agir com base nessa hipótese desperdiçaria tempo e não resolveria o problema real. A alternativa C é incorreta porque a delegação não impõe limite de instâncias por sub-rede; o limite é de capacidade de endereçamento. A alternativa D confunde fragmentação de rotas com esgotamento de IPs, dois problemas completamente diferentes.
Gabarito — Cenário 2
Resposta: C
O cenário apresenta uma causa já identificada (incompatibilidade entre delegação e tipo de recurso) e um conjunto de restrições claras. A sub-rede snet-monitoring está vazia, sem delegação, na mesma VNet, e foi projetada exatamente para cargas de trabalho de monitoramento. Implantar as VMs nessa sub-rede resolve o problema sem tocar na configuração de produção.
A alternativa A é a mais perigosa: remover a delegação de uma sub-rede com App Service em produção, fora da janela de manutenção, causaria indisponibilidade imediata do serviço. Isso viola diretamente a restrição documentada no enunciado.
A alternativa B parte de uma premissa incorreta. A delegação Microsoft.Web/serverFarms não permite coexistência com VMs na mesma sub-rede; a sub-rede delegada é exclusiva para interfaces de rede gerenciadas pelo App Service.
A alternativa D descreve uma sequência tecnicamente válida em outros contextos, mas viola a restrição de não causar indisponibilidade fora da janela de manutenção, além de ser desnecessariamente destrutiva quando uma solução sem impacto está disponível.
Gabarito — Cenário 3
Resposta: C
A pista determinante está na comparação das regiões: a VNet vnet-app-prod está em East US e o App Service Plan asp-prod-01 está em Brazil South. A integração de VNet regional do App Service exige que o App Service Plan e a VNet estejam na mesma região do Azure. Quando há divergência de região, o portal não lista a sub-rede como disponível para seleção, mesmo que a delegação esteja corretamente aplicada.
A delegação correta, o NSG sem bloqueios e a disponibilidade de IPs são todas confirmações de que a configuração da sub-rede em si está correta. O problema está na incompatibilidade de região entre o plano e a rede.
A alternativa A é um distrator plausível porque o bloco /28 fornece apenas 11 endereços utilizáveis, o que poderia ser insuficiente em alguns cenários. Porém, o portal do Azure não filtra sub-redes por tamanho de bloco durante a seleção de integração de VNet; o bloqueio observado ocorre antes dessa verificação, por razão de região. A alternativa B é incorreta porque as regras padrão do Azure permitem o tráfego de gerenciamento necessário para o App Service. A alternativa D é incorreta porque a delegação Microsoft.Web/serverFarms não exige UDR como pré-requisito.
Gabarito — Cenário 4
Resposta: B
Quando uma sub-rede é excluída, todos os recursos de rede vinculados a ela perdem sua conectividade imediatamente e de forma permanente. Grupos de contêiner do ACI que estavam em execução na sub-rede original tinham seus endereços IP privados alocados naquela sub-rede. Com a exclusão, esses recursos ficam em estado de falha de rede sem possibilidade de recuperação automática. A solução exigiria recriar os grupos de contêiner na nova sub-rede.
Este é o impacto colateral real e relevante: a ação resolve o problema de espaço de endereçamento, mas destrói a conectividade dos recursos existentes.
A alternativa A é incorreta porque delegações não possuem período de propagação após reaplicação; a delegação entra em vigor imediatamente. A alternativa C inventa uma restrição que não existe: o tamanho do bloco /23 não impõe requisito automático de UDR. A alternativa D é incorreta porque o Azure não trata delegações reaplicadas de forma diferente de delegações originais; a configuração é imediatamente válida.
Árvore de Troubleshooting: Plan and configure subnet delegation
Legenda de cores:
| Cor | Significado |
|---|---|
| Azul escuro | Sintoma inicial ou falha observada |
| Azul | Pergunta de diagnóstico |
| Vermelho | Causa identificada |
| Laranja | Ação de validação ou correção intermediária |
| Verde | Resolução confirmada |
Diante de uma falha real de provisionamento em sub-rede delegada, comece pelo nó raiz e responda cada pergunta de diagnóstico com base no que é observável diretamente: a delegação existe, o serviço é o correto, há IPs disponíveis, o recurso é compatível, as regiões coincidem, as regras de rede permitem o tráfego. Cada ramificação leva a uma causa específica com uma ação correspondente. O objetivo é eliminar hipóteses progressivamente até chegar ao nó verde de resolução pelo caminho mais curto possível.