A disponibilidade geral da Azure Extended Zone em Perth, anunciada após um período de preview, marca um movimento estratégico da Microsoft para atender workloads sensíveis a latência em localizações geograficamente isoladas. Para times de engenharia no Brasil, esse caso de uso em Perth serve como um blueprint valioso sobre como expandir a capacidade de processamento para a borda mantendo o controle centralizado.
O Desafio da Latência e a Escolha da Extended Zone
Perth, por sua localização isolada, impõe desafios severos para aplicações que dependem de alta performance gráfica (como modelagem de subsuperfície). A centralização em regiões tradicionais do Azure pode resultar em latency que degrada a experiência do usuário e a produtividade da engenharia. A Azure Extended Zone permite que os session hosts residam próximos aos usuários, enquanto o controle, governança e processamento de dados colaterais permanecem na região pai.
Arquitetura em Foco
- Host Pool Types: Opção por Personal Host Pools (persistentes), garantindo que cada engenheiro possua uma VM dedicada. Isso elimina a variabilidade de performance comum em cenários pooled.
- Session Hosts: Utilização de instâncias NVadsA10 v5 com aceleração GPU.
- Segmentação de Rede: Arquitetura hub-and-spoke com uso de AVD Private Link e Private Endpoints, eliminando a exposição de IPs públicos.
- Governança de Identidade: Integração híbrida via Entra ID, com autorizações baseadas em fluxos de governança (ex: Saviynt).
Por que abrir mão do FSLogix?
Este projeto tomou uma decisão técnica consciente ao não utilizar FSLogix. Em um modelo de personal host pool persistente, a sobrecarga de gerenciamento de contêineres de perfil muitas vezes supera os benefícios. Para o perfil de uso de softwares de engenharia Statefull, a alocação de storage via montagem de share externa mostrou-se mais eficiente e menos complexa.
Engenharia de Imagem: O Fluxo de Pipeline
A automação é o coração da estabilidade operacional. O fluxo robusto adotado utiliza Azure Image Builder (AIB) combinado com Azure Compute Gallery.
- Build: A imagem é construída na região pai (Australia East) seguindo as normas da organização.
- Repositório: A imagem é publicada na Azure Compute Gallery.
- Replicação: A imagem é replicada automaticamente para a Perth Extended Zone.
Automação de Replicação via API
Um ponto de atenção crítico: a replicação para Extended Zones exige uma configuração de Managed Identity atrelada à galeria, algo que, no momento, é dependente de chamadas via REST API e não da interface (portal).
# Configurar Identity para replicação
az identity create --name "mi-gallery-perth-replication" ...
Este é um requisito de infraestrutura que exige que o time de DevOps alinhe as permissões adequadamente entre a subscription e o provedor de recursos, garantindo que o ciclo de vida da imagem flua sem intervenção manual.
Controle de Custos (FinOps Prático)
Instâncias GPU não deallocadas representam um impacto financeiro agressivo. Como os usuários finais (engenheiros) não possuem acesso ao portal do Azure, a solução foi empoderar o usuário através de um atalho desktop ('Stop My VDI'). O script utiliza o IMDS (Instance Metadata Service) internamente para identificar o contexto da VM e disparar um webhook que aciona um Azure Automation Runbook para a deallocation, garantindo o desligamento correto SEM exposição de credenciais ou APIs sensíveis.
Considerações Finais
A adoção de Extended Zones exige que o time de engenharia domine não apenas a camada de virtualização (AVD), mas também a orquestração de rede, pipeline de image building e automação de custos. Este modelo de Perth demonstra que, com as ferramentas certas (AIB, Managed Identities, IMDS), é possível levar workloads de peso para a borda mantendo a eficiência operacional e a segurança exigidas em ambientes corporativos.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
