Microsoft AZ-140: Arquitetura e Design de Serviço do Azure Virtual Desktop — Guia de estudos
Faz parte do Microsoft Azure Virtual Desktop Specialty AZ-140 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.
Visão Geral
O Azure Virtual Desktop (AVD) é um serviço de virtualização de desktops e aplicativos gerenciado pela Microsoft que separa o plano de controle do serviço do plano de dados específico do seu tenant. O serviço intermedia conexões seguras, enquanto você possui e opera as máquinas virtuais de host de sessão, identidade, armazenamento e redes. Projetar uma arquitetura eficaz significa mapear a experiência do usuário, identidade, entrega de aplicativos, capacidade, resiliência e controles de custo em um modelo de implantação coeso que pode ser validado e implementado em fases sem interrupção para o usuário.
Arquitetura do Serviço: Plano de Controle vs. Plano de Dados
Plano de controle (gerenciado pela Microsoft):
- Os serviços de Web Access, Gateway e Broker autenticam usuários, enumeram recursos e orquestram sessões de conexão reversa sobre TLS 443. Eles são distribuídos globalmente e atualizados pela Microsoft.
- Os serviços de Diagnostics e Insights coletam telemetria de conexão, status de integridade e do agente.
- APIs de gerenciamento baseadas em ARM definem host pools, grupos de aplicativos e workspaces, incluindo planos de escalonamento e a função “Start VM on Connect”.
Plano de dados (gerenciado pelo cliente):
- Hosts de sessão (Windows 10/11 Enterprise multi-session ou single-session) em suas assinaturas e VNets.
- Identidade e resolução de nomes via AD DS, Azure AD DS ou Entra ID com o modo de ingresso apropriado. Os hosts de sessão devem resolver os serviços de domínio; configure o DNS da VNet para os controladores de domínio ou IPs do Azure AD DS em vez de DNS público.
- Estado e cache do usuário (contêineres de perfil e do Office do FSLogix) no Azure Files Premium ou Azure NetApp Files (ANF), ou menos comumente em servidores de arquivos IaaS ou Storage Spaces Direct (S2D).
- Rede (VNets, peering, VPN/ExpressRoute, NSGs, UDRs, egresso), com QoS e direcionamento de caminho para minimizar a latência e o jitter em UDP/TCP 443.
- Gerenciamento de imagens com o Azure Compute Gallery e o Azure Image Builder, e controles operacionais como autoescalonamento e janelas de manutenção.
O tráfego do plano de controle é de saída dos hosts de sessão; nenhum endpoint público de entrada é necessário nas VMs de host. Isso reduz a exposição e simplifica as regras de firewall.
Construções Essenciais e Entrega de Aplicativos
Host pool: Um conjunto lógico de hosts de sessão com uma localização de recurso definida (região de metadados), política de balanceamento de carga e modo de atribuição (compartilhado ou pessoal). Um host pool contém um grupo de aplicativos de Desktop por padrão e pode ter múltiplos grupos de RemoteApp.
Grupo de aplicativos (app group):
- Desktop: Apresenta um desktop Windows completo do pool. Apenas um grupo de aplicativos de desktop é permitido por host pool.
- RemoteApp: Publica aplicativos individuais. Você pode criar múltiplos grupos de RemoteApp por pool.
- Um usuário não deve ser atribuído tanto ao grupo de Desktop quanto a um grupo de RemoteApp do mesmo host pool. Use pools separados para evitar conflitos de experiência de aplicativo/desktop.
- Um grupo de aplicativos está associado a exatamente um workspace. O workspace e o grupo de aplicativos devem compartilhar a mesma localização de recurso do AVD.
Workspace: O contêiner voltado para o usuário que agrega grupos de aplicativos de diferentes pools em feeds de recursos para os clientes AVD. O RBAC nos grupos de aplicativos controla quem vê quais aplicativos/desktops. Mantenha as localizações dos metadados alinhadas ao registrar grupos de aplicativos em workspaces.
Estratégia de imagem: Para pools compartilhados (multi-session), use imagens do marketplace do Windows 10/11 Enterprise multi-session ou uma imagem personalizada generalizada em um Azure Compute Gallery. Para pools pessoais, use imagens do Windows 10/11 Enterprise single-session. Sempre generalize as VMs de origem antes de capturar as imagens para remover o estado específico do usuário e da máquina.
Tipos de Host Pool, Atribuição, Atualizações e Gerenciamento de Energia
Host pools compartilhados vs. pessoais:
- Compartilhado (Pooled): Múltiplos usuários simultâneos por VM. Otimize para densidade e custo com balanceamento de carga Breadth-first (em largura) ou Depth-first (em profundidade). Use o FSLogix para perfis.
- Pessoal (Personal): Um usuário por VM com estado dedicado. Métodos de atribuição:
- Automática: A primeira conexão vincula permanentemente um usuário a uma VM não atribuída.
- Direta: O administrador mapeia usuários para hosts de sessão específicos.
Pools de validação vs. produção:
- A flag de pool de validação inscreve o pool em anéis de pré-lançamento do agente AVD. Use um pequeno pool de validação por imagem/região para testar atualizações do agente AVD, do SO e de aplicativos com usuários piloto.
- Modelo de implementação em fases (staged rollout):
- Valide a imagem e o agente em um pool de dev/test.
- Pilote em um pool de validação com um subconjunto de usuários.
- Expanda gradualmente para os pools de produção, região por região.
- Drene e aplique patches nos hosts de forma incremental para evitar tempo de inatividade.
Autoscale e Start VM on Connect:
- O Autoscale (planos de escalonamento) agenda a capacidade, impõe limites de sessão, drena hosts ociosos e desaloca VMs para minimizar o custo, preservando a experiência do usuário.
- O Start VM on Connect liga as VMs desalocadas quando um usuário tenta se conectar. Requisitos operacionais:
- Habilite uma identidade gerenciada atribuída pelo sistema no host pool e conceda a função de Desktop Virtualization Power On Off Contributor no grupo de recursos dos hosts de sessão ou nas VMs.
- As VMs devem ser desalocadas para economizar custos de computação; VMs “paradas” (stopped) mas ainda alocadas continuam a gerar cobranças e não oferecem o benefício de uma inicialização a frio (cold-start).
- Funciona com pools compartilhados e pessoais; a inicialização a frio (cold-start) adiciona minutos de atraso na conexão.
- Aplica-se apenas a conexões iniciadas pelo cliente através do AVD; o RDP direto não é suportado.
- Coordene com o autoscale para garantir que um número mínimo de hosts esteja pré-aquecido para os períodos de pico.
Balanceamento de Carga, Planejamento de Capacidade, Registro e Saúde
Algoritmos de balanceamento de carga:
- Breadth-first (primeiro em largura): Distribui as sessões uniformemente entre os hosts disponíveis. Ideal para desempenho consistente e folga de memória.
- Depth-first (primeiro em profundidade): Preenche um host até seu limite máximo de sessões (Max session limit) antes de usar o próximo. Maximiza as desalocações para economia de custos, mas arrisca efeitos de “vizinho barulhento” (noisy-neighbor) se os limites forem muito altos.
Limite máximo de sessões e densidade de usuários:
- Defina o limite máximo de sessões por VM para limitar as sessões simultâneas e proteger a experiência do usuário (UX), especialmente com o modo Depth-first.
- Estime a densidade fazendo benchmarking das cargas de trabalho alvo: a CPU geralmente limita a densidade em ambientes multissessão. Como regra geral:
- Produtividade leve: 6–10 sessões/vCPU em SKUs multissessão modernos quando devidamente ajustados.
- Produtividade média: 4–6 sessões/vCPU.
- Cargas de trabalho gráficas ou com uso intensivo de dados: 1–3 sessões/vCPU.
- Planejamento de capacidade:
- Hosts necessários = ceil((Usuários × simultaneidade) ÷ sessões por host).
- Adicione uma reserva N+1 ou uma porcentagem de folga para failover e janelas de patch.
- Rede: Estime 300–500 Kbps por sessão leve, 1–2 Mbps para média, 3–5+ Mbps para pesada. Apenas usuários no escritório fazem hairpin pela internet corporativa; usuários remotos se conectam diretamente ao AVD.
- QoS: Priorize UDP/TCP 443 para os gateways do AVD; uma alocação insuficiente causa respostas lentas e erros de conexão.
Seleção de armazenamento para o FSLogix:
- O Azure NetApp Files oferece o maior IOPS e a menor latência em escala empresarial (para dezenas de milhares de usuários) com sobrecarga mínima de gerenciamento.
- O Azure Files Premium oferece compartilhamentos SMB com backend de SSD com autenticação baseada em AD ou Kerberos do Entra, equilibrando desempenho e custo para a maioria das implantações.
- Alternativas IaaS (S2D SOFS) exigem pelo menos três VMs sem um Cloud Witness e impõem sobrecarga operacional; use apenas quando as opções de PaaS não forem viáveis.
Tokens de registro, registro do host da sessão e saúde do agente:
- Antes de adicionar VMs existentes a um pool de hosts, gere um token de registro. O agente e o boot loader do AVD registram a VM usando este token; depois disso, o host fica vinculado ao pool e o token pode expirar.
- Mantenha a saúde do agente “verde” monitorando o status do serviço, a versão da pilha SxS e o heartbeat via AVD Insights e Log Analytics. Coloque os hosts em modo de dreno (drain mode) durante a aplicação de patches para evitar novas sessões.
- Dica rápida de solução de problemas: Dentro de uma sessão de usuário, use os contadores RemoteFX Graphics do Monitor de Desempenho (Frames Ignorados/Segundo) para isolar problemas de renderização no servidor vs. rede vs. cliente.
Exemplo de PowerShell para registro e saúde:
# Generate a time-limited registration token
New-AzWvdRegistrationInfo `
-ResourceGroupName 'rg-avd' `
-HostPoolName 'hp-pooled' `
-ExpirationTime (Get-Date).AddHours(8)
# Review host state, drain mode, and session counts
Get-AzWvdSessionHost `
-ResourceGroupName 'rg-avd' `
-HostPoolName 'hp-pooled' |
Select-Object Name, Status, AllowNewSession, Sessions
Considerações sobre DNS e ingresso no domínio:
- Ao usar o Azure AD DS, defina os servidores DNS da VNet para os IPs do domínio gerenciado para que os hosts da sessão possam localizar os controladores de domínio para o registro do Windows e Kerberos/NTLM.
- Para AD DS via ambiente híbrido, configure cada VNet que hospeda hosts de sessão para usar os IPs dos DCs on-premises (pelo menos dois para resiliência). Garanta que encaminhadores condicionais (conditional forwarders) ou resolvedores suportem endpoints privados do Azure, se utilizados.
Design regional e o Experience Estimator:
- Escolha as regiões do pool de hosts com base na menor latência de ida e volta (round-trip) a partir das localizações dos usuários, medida com o Azure Virtual Desktop Experience Estimator. Execute testes a partir de sub-redes reais de usuários em horários de pico e fora de pico.
- Colocalize o armazenamento do FSLogix e os serviços de domínio com os hosts da sessão para minimizar os round-trips de SMB. Evite montagens de perfil entre regiões.
- Para implantações multirregionais, alinhe os locais de metadados entre o pool de hosts, os grupos de aplicativos e os workspaces; use pools separados por região para autonomia e failover em estágios.
Cenário de Problema Prático
A Siemens AG precisa entregar cargas de trabalho de CAD e produtividade para engenheiros em Munique, Chicago e Singapura, minimizando custos e garantindo alto desempenho.
- Mapear grupos de usuários, cargas de trabalho e regiões
- Identificar três grupos (cohorts): uso intenso de CAD (necessita de GPU), produtividade padrão e prestadores de serviço com necessidades apenas de aplicativos. Medir a latência de cada local com o AVD Experience Estimator.
- Por quê: Pools baseados em grupos de usuários evitam efeitos de “vizinho barulhento” e permitem famílias de VM com dimensionamento correto (right-sized) e comportamento de escalonamento por carga de trabalho. As medições de latência informam o posicionamento regional.
- Projetar pools de hosts regionais e entrega de aplicativos
- Criar três pools de hosts regionais por grupo de usuários na Europa Ocidental, Leste dos EUA e Sudeste Asiático. Usar:
- GPU NVadsA10 v5 para CAD (em pool, Breadth-first, limite máximo de sessões mais baixo).
- Séries D/E para produtividade (em pool, Depth-first para maximizar desalocações fora do pico).
- Pools apenas de RemoteApp para prestadores de serviço, publicando aplicativos específicos.
- Registrar grupos de aplicativos RemoteApp e Desktop em workspaces regionais que correspondam à localização de recursos de cada pool.
- Por quê: Segregar pools por carga de trabalho e região otimiza o desempenho e o custo, mantendo direitos de acesso a aplicativos bem definidos.
- Implementar identidade e DNS
- Para a UE e os EUA, ingressar no domínio AD DS on-prem sincronizado com o Entra ID. Configurar o DNS personalizado de cada VNet para dois DCs regionais para resiliência. Em Singapura, implantar o Azure AD DS e definir o DNS da VNet para os IPs do domínio gerenciado para evitar dependência da WAN.
- Por quê: Controladores de domínio locais e DNS de VNet correto garantem resolução Kerberos confiável e logons rápidos; o Azure AD DS reduz a sobrecarga operacional onde não há AD on-prem.
- Otimizar estado do usuário e armazenamento
- Usar o Azure NetApp Files para os grupos de CAD e de produtividade com alta concorrência; usar o Azure Files Premium para os prestadores de serviço. Colocar o armazenamento na mesma região dos pools de hosts e habilitar contêineres de perfil do FSLogix com Cloud Cache para usuários de CAD que se deslocam entre dois escritórios próximos.
- Por quê: O ANF oferece a menor latência e o maior IOPS para cargas de trabalho pesadas; o Azure Files Premium reduz o custo para usuários mais leves. A colocalização evita a latência de SMB entre regiões.
- Capacidade, autoescalonamento e Start VM on Connect
- Estabelecer metas de densidade a partir de testes piloto (ex: CAD 1–2 sessões/vCPU, produtividade 4–6 sessões/vCPU). Configurar planos de autoescalonamento com aumento gradual (ramp-up) durante o dia de trabalho e dreno e desalocação fora do horário comercial. Habilitar o Start VM on Connect com uma identidade atribuída pelo sistema em cada pool de hosts e conceder a função Desktop Virtualization Power On Off Contributor nos grupos de recursos dos hosts da sessão.
- Por quê: O autoescalonamento e o Start VM on Connect minimizam os gastos com computação, preservando a experiência do usuário; a identidade e a atribuição de função permitem que o serviço ligue as VMs de forma confiável.
- Implementação em estágios e validação
- Marcar um pequeno pool de hosts de validação por região para receber atualizações do agente antecipadamente. Cadência de patches: validar → piloto → produção. Usar o modo de dreno durante a aplicação de patches e impor limites máximos de sessões adequados para cada carga de trabalho e algoritmo.
- Por quê: Anéis de controle (controlled rings) evitam regressões em todo o serviço; o modo de dreno mantém as sessões durante a manutenção do host.
- Ajuste de rede e QoS
- Garantir que os roteadores de filial priorizem UDP/TCP 443 para os endpoints do AVD com alocações de largura de banda suficientes. Remover qualquer hairpin de VPN para usuários remotos para que os usuários em casa se conectem diretamente ao AVD.
- Por quê: Os fluxos de mídia do AVD dependem da porta 443; um QoS subprovisionado causa respostas lentas e quedas de conexão.
Ao alinhar os tipos de pool, grupos de aplicativos, identidade, armazenamento, escalonamento e posicionamento regional aos grupos e geografias da Siemens, o design alcança desempenho previsível, segurança operacional por meio de anéis de validação e eficiência de custos por meio de gerenciamento de energia inteligente e controles de densidade.
Todos os domínios · Identidade →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →