Microsoft AZ-140: Operações, Escalonamento e Otimização de Host de Sessão — Guia de estudos

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

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

As operações de host de sessão no Azure Virtual Desktop (AVD) se concentram em três disciplinas principais: dimensionamento correto e engenharia de performance, escalabilidade inteligente e gerenciamento de energia, e operações de dia 2 confiáveis. O objetivo é fornecer uma experiência de usuário consistente durante a demanda de pico, minimizando os gastos fora do horário de expediente, tudo sem comprometer a manutenibilidade ou a recuperabilidade. Esta seção explica como projetar e operar o autoscale do AVD com planos de escalonamento, configuração de agendamento e capacidade, estados operacionais como o modo de dreno, e solução de problemas de integridade e registro. Em seguida, ela conecta as diretrizes de dimensionamento (incluindo cargas de trabalho habilitadas para GPU) e a automação com alavancas de otimização de custos, como reservas, planos de economia e o Azure Hybrid Benefit.

Projeto do Autoscale: Planos de Escalonamento, Agendamentos e Direcionamento de Pool de Hosts

• Planos de escalonamento e direcionamento

  • Um plano de escalonamento define quando e como um pool de hosts em pool inicia, drena, para e desaloca hosts de sessão. Um plano de escalonamento pode ser direcionado a múltiplos pools de hosts, mesmo entre regiões.
  • Cada pool de hosts direcionado executa o plano de escalonamento de forma independente em seu próprio contexto de fuso horário. Use a configuração de fuso horário do plano de escalonamento por agendamento para alinhar com o horário comercial local.
  • Tag de exclusão: defina um par de chave/valor de tag para que o autoscale ignore VMs específicas (por exemplo, canaries operacionais ou pilotos de manutenção).
  • O modo de balanceamento de carga é importante: o modo breadth-first distribui as sessões entre os hosts (melhora a performance instantânea, retarda o scale-in); o modo depth-first empilha as sessões em menos hosts (maximiza a consolidação e a economia de custos). Para um autoscale focado em custos, use o modo depth-first com limiares de capacidade apropriados.

• Agendamentos: ramp-up (aceleração), pico, ramp-down (desaceleração), fora do pico

  • Ramp-up: inicia e “aquece” a frota mínima antes da demanda, depois faz o scale-out quando os limiares de capacidade são ultrapassados.
  • Pico: mantém mais capacidade online para minimizar a latência e o enfileiramento; o scale-out continua se os limiares forem excedidos.
  • Ramp-down: coloca os hosts selecionados em modo de dreno, consolida as sessões e, após um período de carência, desliga os hosts ociosos.
  • Fora do pico: mantém uma pequena linha de base para acesso fora do horário de expediente; os hosts ociosos restantes são desalocados para minimizar os gastos.

• Limiares de capacidade, disponibilidade mínima de hosts e comportamento do autoscale

  • O limiar de capacidade (%) é medido em relação à capacidade total de sessões dos hosts online. Quando a utilização média excede o limiar, o autoscale inicia VMs adicionais. A utilização é determinada pelo máximo de sessões por host e pela contagem de sessões atuais. Ajuste por carga de trabalho; comece com 60–70% para depth-first, 70–80% para breadth-first.
  • A disponibilidade mínima de hosts pode ser definida como um número ou percentual de hosts a serem mantidos em execução em cada fase do agendamento. Sempre mantenha pelo menos um “reserva” para absorver picos repentinos.
  • Segurança no scale-in: o autoscale usa o modo de dreno e verificações de “nenhuma sessão ativa” para evitar a desconexão de usuários. Apenas hosts ociosos são parados/desalocados.

• Gerenciamento de energia e desalocação consciente dos custos

  • Parar (desalocar) libera as cobranças de computação; os discos de SO e de dados continuam a incorrer em cobranças de armazenamento. O Autoscale desaloca hosts ociosos durante o ramp-down e fora do pico.
  • A função Start VM on connect pode complementar a postura fora do pico, inicializando VMs desalocadas quando um usuário tenta se conectar. Garanta que a identidade gerenciada ou a entidade de serviço do pool de hosts tenha permissões para Iniciar VM no grupo de recursos do host de sessão.
  • Evite o desligamento dentro do sistema operacional convidado sem desalocação; isso deixa a VM alocada e faturável.

Estado Operacional, Manutenção e Integridade: Modo de Dreno, Notificações e Registro

• Modo de dreno e janelas de manutenção

  • O modo de dreno (AllowNewSession=false) impede novos logons, permitindo que as sessões existentes sejam concluídas. Use-o para aplicar patches, atualizar agentes, substituir imagens ou para o scale-in.
  • Abordagem de manutenção: coloque o(s) host(s) em modo de dreno, aguarde a ociosidade, faça o logoff normal das sessões remanescentes após notificação, aplique as atualizações e reinicie. Valide a integridade/heartbeat e reabilite novas sessões.

• Estratégia de notificação ao usuário

  • Notificações do plano de escalonamento: configure a mensagem de logoff e o período de carência durante o ramp-down. Use uma linguagem clara e com prazo definido.
  • Notificações suplementares: use o Azure Automation (Send-AzVMRunCommand, notificações do tipo ’toast’ via PowerShell) ou o Endpoint Manager para exibir mensagens na sessão antes da manutenção.

• Status do host de sessão, heartbeat e integridade do agente

  • Status típicos: Available, Unavailable (NoHeartbeat), NeedsAssistance, Unhealthy, Shutdown, NotJoinedToDomain, Upgrading.
  • Pré-requisitos de heartbeat/agente: tráfego de saída na porta 443 para os endpoints de serviço do AVD (use a service tag AzureVirtualDesktop), resolução de DNS estável, sincronização de tempo e ingresso bem-sucedido no domínio, se aplicável.
  • Serviços do agente: Remote Desktop Agent Loader e Remote Desktop Agent devem estar em execução. O agente do AVD e a pilha side-by-side são atualizados automaticamente se o acesso de saída for permitido.

• Registro e solução de problemas

  • Para ingressar VMs existentes em um pool de hosts, crie um token de registro (válido por tempo limitado) e instale/registre o agente do AVD com esse token.
  • Passos comuns para isolamento de falhas:
    • Verifique se o host aparece como Registered e Available no pool de hosts; caso contrário, registre-o novamente com um token novo.
    • Inspecione o Visualizador de Eventos: verifique os logs Microsoft-RDInfra-RDAgent, Microsoft-RDInfra-RDAgentBootLoader e RDS/TerminalServices em busca de erros de conectividade ou autenticação.
    • Valide o DNS: a resolução de domínio e a resolução de endpoint de serviço devem ser bem-sucedidas; se estiver usando o Azure AD DS, garanta que o DNS da VNet aponte para os controladores de domínio gerenciados.
    • Confirme se o Firewall do Windows ou as regras de segurança de rede permitem a saída na porta 443 e que nenhuma interceptação de TLS quebre a confiança do serviço.

• Exemplos úteis de automação

# Put a session host in drain mode (no new sessions)
Update-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-finance `
  -Name host1.contoso.com -AllowNewSession:$false

# Gracefully logoff idle users after notice (example)
Invoke-AzVMRunCommand -ResourceGroupName rg-avd -Name host1 `
  -CommandId RunPowerShellScript -ScriptPath .\Notify-And-Logoff.ps1

Dimensionamento, Utilização e Cargas de Trabalho com GPU

• Seleção do tamanho da VM e dimensionamento orientado pela carga de trabalho

  • Comece pela caracterização da carga de trabalho: escritório/produtividade, trabalhador do conhecimento com otimização para Microsoft 365 Apps e Teams, desenvolvedor/engenharia ou gráficos/3D.
  • CPU: mantenha a CPU sustentada abaixo de 70–75% com picos curtos abaixo de 85%. Monitore Processor(_Total)\% Processor Time e System\Processor Queue Length.
  • Memória: almeje <80% de memória alocada (committed) com Memory\Available MBytes acima de 500 MB por host; fique atento à paginação (paging). O cache do FSLogix pode aumentar o conjunto de trabalho (working set) — dimensione adequadamente.
  • Armazenamento: a experiência do usuário depende do IOPS e da latência do perfil FSLogix. Use Premium SSD v2, Ultra Disk para cenários intensivos em temp/cache, e Azure Files Premium ou Azure NetApp Files para perfis com alto IOPS. Para ambientes muito grandes ou perfis de latência ultrabaixa, o Azure NetApp Files oferece a melhor consistência.
  • Linhas de base iniciais (multissessão):
    • Produtividade leve: 4–8 vCPUs, 16–32 GB de RAM; breadth-first para responsividade.
    • Trabalhador do conhecimento médio: 8–16 vCPUs, 32–64 GB de RAM; depth-first para eficiência de custos.
    • Desenvolvimento/compilação/dados pesados: 16–32 vCPUs, 64–128 GB de RAM; considere pools dedicados.

• Hosts de sessão com GPU habilitada

  • Para CAD/GIS/3D/edição de vídeo e visualizações complexas, use NVads A10 v5 para perfis de vGPU granulares e uma ótima relação preço/desempenho; considere as famílias NV v4/v5 quando apropriado.
  • Implante a NVIDIA GPU Driver Extension para Windows em VMs da série N. Valide a codificação por hardware: habilite o AVC/H.264 e configure “Usar codificação por hardware para a Área de Trabalho Remota” via política quando for benéfico.
  • Monitore a GPU com os Performance Counters (utilização do motor da GPU, memória da GPU) e métricas do Azure Monitor. Garanta uma folga de CPU suficiente; aplicativos com uso intensivo de gráficos ainda são sensíveis à falta de CPU (CPU starvation).

• Telemetria e ajuste iterativo

  • Habilite o Azure Monitor para insights do AVD e o Log Analytics. Acompanhe CPU, memória, latência do perfil FSLogix, duração do logon, desconexões e tempos de intermediação (brokering).
  • Ajuste o MaxSessionLimit do pool de hosts e o modo de balanceamento de carga com base na contenção observada e, em seguida, reajuste os limites do autoscale para corresponder.

Otimização de Custos: Energia, Autoscale, Reservas, Savings Plans e AHB

• Alinhe o escalonamento com o horário comercial

  • Use o modo de balanceamento de carga depth-first (em profundidade) com limites de capacidade conservadores para consolidar sessões e acelerar o scale-in (redução de escala). Combine com a desalocação fora do horário de pico e a funcionalidade Start VM on connect para acessos tardios ou raros.
  • Defina uma contagem mínima de hosts pequena, mas diferente de zero, para evitar picos de inicialização a frio (cold-start storms).

• Reservas e planos de economia

  • Reservas: As reservas de VM de 1 ou 3 anos bloqueiam SKUs específicos em regiões específicas para obter os maiores descontos; ideal para a capacidade de base que funciona a maior parte do tempo (por exemplo, a frota do pico diurno).
  • Compute Savings Plans: oferecem descontos flexíveis entre famílias de VMs e regiões; úteis ao misturar tamanhos ou para ambientes dinâmicos onde a previsibilidade exata do SKU é menor.
  • Reservas de armazenamento: A capacidade reservada do Azure Files pode reduzir os custos de armazenamento do FSLogix em escala.

• Azure Hybrid Benefit (AHB) e licenciamento

  • Aplique o AHB a cargas de trabalho do Windows Server e de clientes Windows elegíveis para reduzir os custos de licenciamento do SO de computação. Garanta a elegibilidade e a conformidade da licença.
  • Para implantações do Microsoft 365, confirme se o licenciamento cobre o Windows Enterprise multi-session e os Microsoft 365 Apps, quando aplicável.

• Scripts operacionais e runbooks

  • Use o Azure Automation ou o GitHub Actions para:
    • Sequências de drenagem/habilitação (drain/enable) da frota antes e depois da manutenção.
    • Scripts de aquecimento (warm-up) pré-escalonamento às segundas-feiras ou após feriados.
    • Remediação de integridade (reiniciar serviços do agente, registrar novamente o host se o heartbeat for perdido).
  • A orquestração orientada por tags simplifica as operações seletivas (por exemplo, tag Environment=Pilot para excluir da operação de scale-in).

# Start or stop idle hosts by tag (supplemental to native autoscale)
$hosts = Get-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-ops
foreach ($h in $hosts) {
  if ($h.Session -eq 0 -and $h.Tags["KeepOnline"] -ne "true") {
    Stop-AzVM -ResourceGroupName rg-avd -Name ($h.Name.Split("/")[1]) -Force -StayProvisioned:$false
  }
}

Cenário de Problema Prático

A IKEA enfrenta picos durante a semana de planejadores 3D, engenheiros de produto e equipe de call center que usam aplicativos remotos. À noite e nos fins de semana, a demanda é baixa. As sessões com suporte de GPU devem permanecer responsivas, minimizando o custo geral de computação.

1. Segmente os host pools por carga de trabalho

   • Crie três host pools compartilhados: GPU-CAD (NVads A10 v5), KnowledgeWorker (séries D/E) e ContactCenter (série D).
   • Por quê: Alinha o tamanho e a densidade da VM com perfis de desempenho distintos; permite janelas de autoscale e manutenção independentes.

2. Anexe um único plano de escalonamento com agendamentos por horário comercial

   • Defina o ramp-up (aceleração) às 07:00, pico das 09:00 às 17:00, ramp-down (desaceleração) das 17:00 às 19:00, e fora de pico nos demais horários; defina o fuso horário para a região de cada pool.
   • Por quê: Garante que a capacidade esteja pronta antes da chegada dos usuários, consolida e desliga os recursos de forma gradual após o expediente e respeita os horários regionais.

3. Ajuste os limites de capacidade e a disponibilidade mínima de hosts por pool

   • GPU-CAD: breadth-first (em largura), limite de capacidade de 70%, mínimo de 30% de hosts online; KnowledgeWorker: depth-first (em profundidade), limite de 65%, mínimo de 10%; ContactCenter: depth-first, limite de 70%, mínimo de 15%.
   • Por quê: Cargas de trabalho de GPU preferem uma distribuição mais ampla para maior responsividade; cargas de trabalho de escritório se beneficiam da consolidação para reduzir custos; o call center requer uma reserva estável para trocas de turno.

4. Habilite o Start VM on connect para os pools KnowledgeWorker e ContactCenter

   • Conceda à identidade gerenciada do host pool as permissões para iniciar VMs (VM Start); mantenha o mínimo fora do pico baixo.
   • Por quê: Reduz os custos de tempo de execução ocioso, preservando o acesso just-in-time para logons inesperados fora do horário de expediente.

5. Implemente um fluxo de trabalho de manutenção e notificação

   • Antes da Patch Tuesday: coloque 20% de cada pool em modo de drenagem (drain mode) por meio de uma tag; notifique os usuários com 30 minutos de antecedência; após ficarem ociosos, aplique os patches, reinicie, valide o agente/sinal de vida (heartbeat) e, em seguida, rotacione para o próximo lote.
   • Por quê: A drenagem contínua (rolling drain) evita logoffs em massa, preserva a continuidade do serviço e reduz os picos no helpdesk.

6. Monitore e itere com o Azure Monitor for AVD

   • Acompanhe a utilização de CPU, memória, GPU, a duração do logon e a latência do FSLogix; ajuste o MaxSessionLimit e os limites do autoscale mensalmente.
   • Por quê: O ajuste orientado por dados mantém o SLA e controla os gastos à medida que os padrões de uso evoluem.

7. Aplique alavancas de custo

   • Reserve capacidade de 3 anos para o pico de base durante a semana nos pools KnowledgeWorker e ContactCenter; use um Compute Savings Plan para a demanda variável de GPU; aplique o Azure Hybrid Benefit onde for elegível.
   • Por quê: As reservas garantem as maiores economias para a carga de base previsível; os planos de economia se flexionam com os picos de GPU menos previsíveis; o AHB reduz os custos de licenciamento do SO.

8. Fortaleça o registro e a saúde dos hosts

   • Mantenha um runbook permanente para registrar novamente qualquer host que apresente NoHeartbeat (sem sinal de vida) e valide o DNS/horário. Mantenha tags de exclusão para hosts de diagnóstico.
   • Por quê: A remediação rápida e automatizada limita o impacto no usuário e preserva a capacidade durante problemas inesperados do agente.

Com este design, a IKEA atinge os objetivos de desempenho diurnos — incluindo a responsividade da GPU — enquanto desaloca agressivamente a capacidade fora do horário de pico e automatiza a manutenção, resultando em uma experiência de usuário estável e uma redução de custos mensurável.

← FSLogix · Todos os domínios · Aplicações e Experiência do Usuário Final →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Microsoft →