Microsoft AZ-140: Операции с узлами сеансов, масштабирование и оптимизация — Руководство по подготовке

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

Часть Microsoft Azure Virtual Desktop Specialty AZ-140 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Операции с узлами сеансов в Azure Virtual Desktop (AVD) сосредоточены на трех основных дисциплинах: подбор оптимального размера и инжиниринг производительности, интеллектуальное масштабирование и управление питанием, а также надежные операции второго дня (day-2 operations). Цель — обеспечить стабильное качество работы пользователей во время пикового спроса, минимизируя при этом расходы в нерабочее время, и все это без ущерба для удобства обслуживания и возможности восстановления. В этом разделе объясняется, как проектировать и использовать автомасштабирование AVD с помощью планов масштабирования, конфигурации расписания и емкости, операционных состояний, таких как режим стока, а также как устранять неполадки с работоспособностью и регистрацией. Затем в нем увязываются рекомендации по подбору размера (включая рабочие нагрузки с поддержкой GPU) и автоматизация с рычагами оптимизации затрат, такими как резервирования, планы экономии и Azure Hybrid Benefit.

Проектирование автомасштабирования: планы масштабирования, расписания и назначение пулам узлов

• Планы масштабирования и назначение

  • План масштабирования определяет, когда и как пул узлов (pooled host pool) запускает, переводит в режим стока, останавливает и освобождает узлы сеансов. Один план масштабирования может быть назначен нескольким пулам узлов, даже в разных регионах.
  • Каждый пул узлов, которому назначен план, выполняет его независимо в контексте своего часового пояса. Используйте настройку часового пояса в расписании плана масштабирования для согласования с местными рабочими часами.
  • Тег исключения: определите пару ключ/значение тега, чтобы автомасштабирование игнорировало определенные ВМ (например, для операционных тестов-«канареек» или пилотных ВМ для обслуживания).
  • Режим балансировки нагрузки имеет значение: breadth-first (в ширину) распределяет сеансы по всем узлам (улучшает мгновенную производительность, замедляет обратное масштабирование); depth-first (в глубину) концентрирует сеансы на меньшем количестве узлов (максимизирует консолидацию и экономию средств). Для автомасштабирования, ориентированного на затраты, используйте режим depth-first с соответствующими порогами емкости.

• Расписания: ramp-up (наращивание), peak (пик), ramp-down (сокращение), off-peak (внепиковый период)

  • Ramp-up: запускает и «прогревает» минимальный парк ВМ до начала спроса, затем выполняет горизонтальное масштабирование при превышении порогов емкости.
  • Peak: поддерживает больше мощностей в сети для минимизации задержек и очередей; горизонтальное масштабирование продолжается, если пороги превышены.
  • Ramp-down: переводит выбранные узлы в режим стока, консолидирует сеансы и по истечении льготного периода выключает простаивающие узлы.
  • Off-peak: поддерживает небольшую базовую группу для доступа в нерабочее время; остальные простаивающие узлы освобождаются (deallocated) для минимизации расходов.

• Пороги емкости, минимальная доступность узлов и поведение автомасштабирования

  • Порог емкости (%) измеряется относительно общей емкости сеансов на онлайн-узлах. Когда средняя утилизация превышает порог, автомасштабирование запускает дополнительные ВМ. Утилизация зависит от максимального количества сеансов на узел и текущего числа сеансов. Настраивайте для каждой рабочей нагрузки; начните с 60–70% для режима depth-first и 70–80% для breadth-first.
  • Минимальная доступность узлов может быть определена как количество или процент узлов, которые должны оставаться запущенными в каждой фазе расписания. Всегда поддерживайте хотя бы один «запасной» узел для поглощения внезапных всплесков нагрузки.
  • Безопасность обратного масштабирования: автомасштабирование использует режим стока и проверки на отсутствие активных сеансов, чтобы не прерывать работу пользователей. Останавливаются/освобождаются только простаивающие узлы.

• Управление питанием и освобождение ресурсов с учетом затрат

  • Остановка (освобождение) прекращает начисление платы за вычисления; плата за хранение дисков ОС и данных продолжает взиматься. Автомасштабирование освобождает простаивающие узлы во время фаз ramp-down и off-peak.
  • Функция «Запуск ВМ при подключении» может дополнить конфигурацию для внепикового периода, запуская освобожденные ВМ при попытке подключения пользователя. Убедитесь, что управляемое удостоверение или субъект-служба пула узлов имеет разрешения на запуск ВМ (VM Start) в группе ресурсов узлов сеансов.
  • Избегайте выключения из гостевой ОС без освобождения ресурсов; это оставляет ВМ в состоянии «выделено» (allocated), и за нее продолжает взиматься плата.

Операционное состояние, обслуживание и работоспособность: режим стока, уведомления и регистрация

• Режим стока и окна обслуживания

  • Режим стока (AllowNewSession=false) предотвращает новые входы в систему, позволяя завершить существующие сеансы. Используйте его для установки исправлений, обновления агентов, замены образов или для обратного масштабирования.
  • Подход к обслуживанию: переведите узел(ы) в режим стока, дождитесь простоя, корректно завершите оставшиеся сеансы после уведомления, затем примените обновления и перезагрузите. Проверьте работоспособность/сигнал активности и снова разрешите новые сеансы.

• Стратегия уведомления пользователей

  • Уведомления плана масштабирования: настройте сообщение о выходе из системы и льготный период во время фазы ramp-down. Используйте четкие, ограниченные по времени формулировки.
  • Дополнительные уведомления: используйте Azure Automation (Send-AzVMRunCommand, всплывающие уведомления через PowerShell) или Endpoint Manager для отображения сообщений в сеансе перед началом обслуживания.

• Статус узла сеансов, сигнал активности и работоспособность агента

  • Типичные статусы: Available (Доступен), Unavailable (Недоступен, NoHeartbeat), NeedsAssistance (Требуется помощь), Unhealthy (Неработоспособен), Shutdown (Выключен), NotJoinedToDomain (Не присоединен к домену), Upgrading (Обновляется).
  • Предварительные условия для сигнала активности/агента: исходящий трафик по порту 443 к конечным точкам службы AVD (используйте тег службы AzureVirtualDesktop), стабильное разрешение DNS, синхронизация времени и успешное присоединение к домену, если применимо.
  • Службы агента: службы Remote Desktop Agent Loader и Remote Desktop Agent должны быть запущены. Агент AVD и стек side-by-side обновляются автоматически, если разрешен исходящий доступ.

• Регистрация и устранение неполадок

  • Чтобы присоединить существующие ВМ к пулу узлов, создайте токен регистрации (действителен в течение ограниченного времени) и установите/зарегистрируйте агент AVD с этим токеном.
  • Общие шаги по изоляции неисправностей:
    • Проверьте, что узел отображается как Registered (Зарегистрирован) и Available (Доступен) в пуле узлов; если нет, повторно зарегистрируйте его с новым токеном.
    • Изучите журналы в Event Viewer: Microsoft-RDInfra-RDAgent, Microsoft-RDInfra-RDAgentBootLoader и RDS/TerminalServices на предмет ошибок подключения или аутентификации.
    • Проверьте DNS: разрешение доменных имен и конечных точек службы должно работать успешно; при использовании Azure AD DS убедитесь, что DNS виртуальной сети указывает на управляемые контроллеры домена.
    • Убедитесь, что правила брандмауэра Windows или групп безопасности сети разрешают исходящий трафик по порту 443 и что никакое перехватывание TLS не нарушает доверие к службе.

• Полезные примеры автоматизации

# 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

Определение размеров, утилизация и рабочие нагрузки с поддержкой GPU

• Выбор размера ВМ и определение размеров в зависимости от рабочей нагрузки

  • Начните с определения характеристик рабочей нагрузки: офисная/продуктивная работа, работник умственного труда с оптимизацией для Microsoft 365 Apps и Teams, разработчик/инженер или работа с графикой/3D.
  • ЦП: поддерживайте постоянную загрузку ЦП на уровне ниже 70–75% с короткими пиками до 85%. Отслеживайте Processor(_Total)\% Processor Time и System\Processor Queue Length.
  • Память: стремитесь к использованию выделенной памяти <80%, при этом Memory\Available MBytes должен быть выше 500 МБ на хост; следите за подкачкой. Кэш FSLogix может увеличить рабочий набор — определите размер соответствующим образом.
  • Хранилище: пользовательский опыт зависит от IOPS и задержки профиля FSLogix. Premium SSD v2, Ultra Disk для сценариев с интенсивным использованием временных файлов/кэша, а также Azure Files Premium или Azure NetApp Files для профилей с высоким IOPS. Для очень крупных развертываний или профилей с наименьшей задержкой Azure NetApp Files обеспечивает наилучшую стабильность.
  • Начальные базовые показатели (многосеансовые):
    • Легкая продуктивная работа: 4–8 vCPU, 16–32 ГБ ОЗУ; распределение в ширину (breadth-first) для лучшей отзывчивости.
    • Средняя нагрузка работника умственного труда: 8–16 vCPU, 32–64 ГБ ОЗУ; распределение в глубину (depth-first) для экономической эффективности.
    • Тяжелая нагрузка (разработка/компиляция/данные): 16–32 vCPU, 64–128 ГБ ОЗУ; рассмотрите возможность использования выделенных пулов.

• Сеансовые хосты с поддержкой GPU

  • Для CAD/GIS/3D/редактирования видео и сложных визуализаций используйте NVads A10 v5 для гранулярных профилей vGPU и хорошего соотношения цена/производительность; при необходимости рассмотрите семейства NV v4/v5.
  • Разверните расширение NVIDIA GPU Driver Extension для Windows на ВМ N-серии. Проверьте аппаратное кодирование: включите AVC/H.264 и настройте через политику «Использовать аппаратное кодирование для удаленного рабочего стола» (Use hardware encoding for Remote Desktop), когда это целесообразно.
  • Отслеживайте GPU с помощью счетчиков производительности (Performance Counters) (утилизация движка GPU, память GPU) и метрик Azure Monitor. Обеспечьте достаточный запас производительности ЦП; приложения с интенсивным использованием графики по-прежнему чувствительны к нехватке ресурсов ЦП.

• Телеметрия и итеративная настройка

  • Включите Azure Monitor для аналитики AVD и Log Analytics. Отслеживайте ЦП, память, задержку профиля FSLogix, продолжительность входа в систему, отключения и время брокериджа.
  • Скорректируйте MaxSessionLimit пула хостов и режим балансировки нагрузки на основе наблюдаемой конкуренции за ресурсы, затем перенастройте пороги автомасштабирования для соответствия.

Оптимизация затрат: управление питанием, автомасштабирование, резервирования, планы экономии и AHB

• Согласование масштабирования с рабочими часами

  • Используйте масштабирование в глубину (depth-first) с консервативными порогами емкости, чтобы консолидировать сеансы и ускорить обратное масштабирование (scale-in). Сочетайте это с высвобождением ресурсов в непиковые часы и функцией «Запуск ВМ при подключении» для редкого доступа или доступа в нерабочее время.
  • Установите небольшое, но ненулевое минимальное количество узлов, чтобы избежать «лавины» холодных запусков.

• Резервирования и планы экономии

  • Резервирования (Reservations): резервирование ВМ на 1 или 3 года фиксирует определенные SKU в конкретных регионах для получения максимальных скидок; идеально подходит для базовой емкости, которая работает большую часть времени (например, парк ВМ для дневных пиковых нагрузок).
  • Планы экономии для вычислений (Compute Savings Plans): предлагают гибкие скидки для разных семейств ВМ и регионов; полезны при смешивании размеров ВМ или для динамичных сред, где предсказуемость точных SKU ниже.
  • Резервирования хранилища: зарезервированная емкость Azure Files может сократить затраты на хранилище FSLogix в больших масштабах.

• Преимущество гибридного использования Azure (AHB) и лицензирование

  • Применяйте AHB к рабочим нагрузкам Windows Server и соответствующим клиентским версиям Windows, чтобы сократить расходы на лицензирование ОС. Убедитесь в соответствии требованиям лицензирования и их соблюдении.
  • Для развертываний Microsoft 365 убедитесь, что лицензирование покрывает Windows Enterprise с поддержкой нескольких сеансов и приложения Microsoft 365, где это применимо.

• Операционные скрипты и модули runbook

  • Используйте Azure Automation или GitHub Actions для:
    • Последовательностей перевода парка ВМ в режим стока (drain) и обратно до и после обслуживания.
    • Скриптов для «прогрева» перед масштабированием по понедельникам или после государственных праздников.
    • Восстановления работоспособности (перезапуск служб агента, повторная регистрация узла при потере сигнала пульса (heartbeat)).
  • Оркестрация на основе тегов упрощает выборочные операции (например, тег Environment=Pilot для исключения из обратного масштабирования).

# 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
  }
}

Практический сценарий

Компания IKEA сталкивается со всплесками нагрузки в будние дни со стороны специалистов по 3D-планированию, инженеров-разработчиков и сотрудников колл-центра, использующих удаленные приложения. Вечером и в выходные дни спрос низкий. Сеансы с поддержкой GPU должны оставаться отзывчивыми при минимизации общих затрат на вычисления.

1. Сегментировать пулы узлов по типу рабочей нагрузки

   • Создать три объединенных (pooled) пула узлов: GPU-CAD (NVads A10 v5), KnowledgeWorker (серии D/E) и ContactCenter (серия D).
   • Зачем: Это позволяет согласовать размер и плотность ВМ с различными профилями производительности, а также обеспечивает независимое автомасштабирование и окна обслуживания.

2. Привязать единый план масштабирования с расписаниями по рабочим часам

   • Определить наращивание мощности в 07:00, пик с 09:00 до 17:00, сокращение с 17:00 до 19:00, и непиковый период в остальное время; установить часовой пояс для региона каждого пула.
   • Зачем: Это гарантирует готовность емкости до прихода пользователей, консолидирует и корректно отключает ресурсы после окончания рабочего дня, а также учитывает региональное время.

3. Настроить пороги емкости и минимальную доступность узлов для каждого пула

   • GPU-CAD: масштабирование в ширину (breadth-first), порог емкости 70%, минимум 30% узлов онлайн; KnowledgeWorker: масштабирование в глубину (depth-first), порог 65%, минимум 10%; ContactCenter: масштабирование в глубину, порог 70%, минимум 15%.
   • Зачем: Нагрузки GPU предпочитают распределение в ширину для лучшей отзывчивости; офисные нагрузки выигрывают от консолидации для снижения затрат; колл-центру требуется стабильный резерв для смены смен.

4. Включить функцию «Запуск ВМ при подключении» (Start VM on connect) для пулов KnowledgeWorker и ContactCenter

   • Предоставить управляемому удостоверению пула узлов разрешения на запуск ВМ; поддерживать низкое минимальное количество узлов в непиковые часы.
   • Зачем: Это сокращает расходы на простаивающие ресурсы, сохраняя при этом доступ «точно в срок» для непредвиденных входов в систему в нерабочее время.

5. Реализовать рабочий процесс обслуживания и уведомлений

   • Перед «Вторником обновлений» (Patch Tuesday): перевести 20% каждого пула в режим стока (drain mode) с помощью тега; уведомить пользователей за 30 минут; после освобождения от сеансов установить обновления, перезагрузить, проверить агент/сигнал пульса, затем перейти к следующей партии.
   • Зачем: Поочередный перевод в режим стока позволяет избежать массовых выходов пользователей, сохраняет непрерывность сервиса и снижает количество обращений в службу поддержки.

6. Мониторить и итерировать с помощью Azure Monitor for AVD

   • Отслеживать утилизацию CPU, памяти, GPU, длительность входа в систему, задержку FSLogix; ежемесячно корректировать MaxSessionLimit и пороги автомасштабирования.
   • Зачем: Настройка на основе данных поддерживает SLA и контролирует расходы по мере изменения моделей использования.

7. Применить рычаги экономии

   • Зарезервировать емкость на 3 года для базовой пиковой нагрузки в будни в пулах KnowledgeWorker и ContactCenter; использовать Compute Savings Plan для переменного спроса на GPU; применить Преимущество гибридного использования Azure (Azure Hybrid Benefit), где это возможно.
   • Зачем: Резервирования обеспечивают наибольшую экономию для предсказуемой базовой нагрузки; планы экономии гибки для менее предсказуемых пиков GPU; AHB снижает затраты на лицензирование ОС.

8. Усилить процессы регистрации и проверки работоспособности

   • Поддерживать постоянно действующий runbook для повторной регистрации любого узла со статусом NoHeartbeat и проверки DNS/времени. Использовать теги-исключения для диагностических узлов.
   • Зачем: Быстрое автоматизированное исправление ограничивает влияние на пользователей и сохраняет емкость во время непредвиденных проблем с агентом.

С такой архитектурой IKEA достигает целевых показателей производительности в дневное время, включая отзывчивость GPU, при этом агрессивно высвобождая ресурсы в нерабочее время и автоматизируя обслуживание, что приводит к стабильному пользовательскому опыту и измеримому сокращению затрат.

← FSLogix · Все домены · Приложения и пользовательский опыт →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →