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) направлено на поддержание производительности пользователей во время региональных сбоев, защиту данных (профилей, образов, приложений), оркестрацию отработки отказа зависимых компонентов и обеспечение предсказуемого перехода от устаревших служб Remote Desktop Services (RDS). Эффективные архитектуры отделяют плоскость управления AVD без сохранения состояния от плоскостей данных с сохранением состояния, используют повторяемую автоматизацию для перестроения, определяют четкие целевые показатели восстановления для каждого компонента и проверяют реальную производительность с помощью анализа и моделирования емкости.

Региональная архитектура, доступ пользователей и отработка отказа

• Плоскости управления и данных: Брокер, веб-доступ, службы диагностики и управления AVD отказоустойчивы на глобальном уровне. Узлы сеансов, пулы узлов, образы и хранилища привязаны к региону и должны быть спроектированы с учетом отработки отказа.
• Стратегия на случай регионального сбоя:
  • Создайте пул узлов в дополнительном регионе для каждой группы пользователей с тем же семейством размеров ВМ и той же родословной образов. Реплицируйте образы в дополнительный регион с помощью Azure Compute Gallery.
  • Опубликуйте идентичные группы приложений (RemoteApp и/или Desktop) в обоих регионах и назначьте их пользователям, установив основной пул по умолчанию, а дополнительный — в качестве цели для аварийного восстановления (DR).
  • Держите узлы для DR в холодном или теплом резерве. Для объединенных в пул узлов выполните масштабирование до нуля или выключите их, а затем используйте планы масштабирования и функцию Start VM on Connect для минимизации постоянных затрат.
• Доступ пользователей во время сбоев:
  • Служба AVD направляет запросы на подключение к работоспособным узлам сеансов. Когда вы переводите основной пул узлов в режим стока (drain mode) или он становится недоступен, новые подключения направляются в дополнительный пул, если у пользователей есть там назначения.
  • Проинформируйте пользователей, что открытые сеансы в отказавшем регионе будут разорваны; повторное подключение произойдет к доступному региону.
• Паритет образов и подключенных приложений MSIX:
  • Используйте Azure Image Builder и Azure Compute Gallery (SIG) с региональной репликацией для образов.
  • Храните пакеты подключенных приложений MSIX в отказоустойчивых хранилищах, доступных из обоих регионов, и реплицируйте содержимое в дополнительный регион (например, с помощью межрегиональной репликации ANF или репликации учетной записи хранения).
• Сетевые зависимости и зависимости удостоверений:
  • Убедитесь, что DNS и службы удостоверений (Active Directory или Azure AD DS) доступны из обоих регионов. Для Azure AD DS настройте параметры DNS в VNet на IP-адреса управляемого домена в каждой региональной VNet, которой требуется присоединение к домену и разрешение имен.
  • Проверьте поведение RDP Shortpath между регионами; при возникновении препятствий для UDP произойдет возврат к обратному подключению (reverse connect).

Пример репликации версии образа в два региона:

az sig image-version create \
  --resource-group rg-avd-images \
  --gallery-name sig-avd \
  --gallery-image-definition win11-ms \
  --gallery-image-version 1.0.3 \
  --target-regions eastus=1 westus=1

Целевые показатели восстановления и роли защиты данных

Определите отдельные RTO/RPO для каждого компонента:

• Пулы узлов и узлы сеансов:
  • Объединенные в пул: Рассматривайте узлы сеансов как эфемерные. RTO — минуты (автоматизированное повторное развертывание), RPO — не применимо (нет состояния узла). Не полагайтесь на резервные копии ВМ для восстановления; выполняйте повторное развертывание из образа и автомасштабирование.
  • Персональные: Если состояние пользователя находится на диске ОС, защитите его с помощью Azure Backup или Azure Site Recovery (ASR). Предпочтительно выносить состояние пользователя в профили FSLogix для упрощения DR.
• Образы:
  • RPO близко к нулю для доступности образов благодаря репликации Compute Gallery; RTO — минуты для развертывания новых узлов. Поддерживайте конвейеры создания «золотых» образов версионированными и воспроизводимыми.
• Профили и кэши Office (FSLogix):
  • RPO: от минут до часов в зависимости от расписания репликации и резервного копирования; RTO: минуты на монтирование в дополнительном регионе при настроенном Cloud Cache, в противном случае — время на восстановление тома/общей папки и перенаправление сеансов.
• Приложения:
  • Для приложений внутри образа согласуйте с RTO/RPO образа. Для подключенных приложений MSIX согласуйте с временем репликации хранилища пакетов и их повторной регистрации.

Azure Backup и ASR:

• Azure Backup:
  • Создавайте резервные копии общих папок Azure Files, в которых размещаются контейнеры профилей FSLogix и ODFC. Используйте частые моментальные снимки для достижения целевых показателей RPO; восстанавливайте отдельные VHD/VHDX или всю общую папку.
  • Сообщите, что моментальные снимки являются согласованными на случай сбоя (crash-consistent), пока пользователи вошли в систему; для точного восстановления выполните внеполосное копирование/переименование контейнера пользователя и попросите его повторно войти в систему.
  • При необходимости создавайте резервные копии дисков ОС персональных рабочих столов. Объединенные в пул узлы обычно не требуют резервного копирования ВМ.
• Azure Site Recovery:
  • Используйте ASR для критически важных для AVD компонентов инфраструктуры с сохранением состояния (например, серверы управления, серверы лицензий, если применимо, серверы бизнес-приложений) и для пулов персональных узлов, когда требуется сохранить состояние ВМ.
  • Избегайте использования ASR для объединенных в пул узлов AVD; повторное развертывание из образа/планов масштабирования быстрее и дешевле.

Отказоустойчивость хранилища профилей, Cloud Cache, резервное копирование и восстановление

• Варианты хранилища для FSLogix:
  • Azure NetApp Files (ANF): Самые высокие показатели IOPS/самая низкая задержка в масштабе; поддерживает межрегиональную репликацию для DR. Идеально подходит для очень крупных сред или при высоких требованиях к параллелизму и вводу-выводу профилей.
  • Azure Files Premium: Общие файловые ресурсы PaaS на базе SSD с ZRS для внутрирегиональной отказоустойчивости; отличный баланс производительности и администрирования. Для межрегионального DR комбинируйте с Cloud Cache и резервным копированием/восстановлением на уровне общей папки или проектируйте двухрегиональные общие папки.
  • Storage Spaces Direct (S2D) на IaaS: Используйте только тогда, когда PaaS не является жизнеспособным вариантом. Требует минимум три ВМ без Cloud Witness для кворума. Эксплуатационные издержки выше, чем у альтернатив PaaS.
• Cloud Cache:
  • Настройте несколько провайдеров (например, две конечные точки Azure Files или ANF в разных зонах/регионах). Во время регионального сбоя FSLogix продолжает работать с оставшимися провайдерами, обеспечивая согласованность в конечном счете для кэшированных записей.
  • Пример конфигурации:

# PowerShell on session host
New-Item -Path HKLM:\SOFTWARE\FSLogix\Profiles -Force | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name Enabled -Type DWord -Value 1 | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name CCDLocations -Type String `
  -Value "type=smb,connectionString=\\files-pri.file.core.windows.net\profiles;type=smb,connectionString=\\files-dr.file.core.windows.net\profiles" | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name DeleteLocalProfileWhenVHDShouldApply -Type DWord -Value 1 | Out-Null

• Схемы резервного копирования и восстановления:
  • Внедрите создание ежечасных или каждые несколько часов моментальных снимков Azure Backup для общих папок с профилями. В случае повреждения профиля пользователя изолируйте текущий VHDX, восстановите предыдущий моментальный снимок в альтернативное место и скопируйте или повторно подключите контейнер пользователя.
  • Для ANF используйте моментальные снимки и межрегиональную репликацию; восстанавливайте на уровне тома или отдельный файл через каталог моментальных снимков.
• Тестирование:
  • Включайте в учения по DR проверку монтирования/подключения, симуляцию повреждений и откат на уровне пользователя.

Отказоустойчивость трафика, DNS и зависимостей

• Зависимости приложений:
  • Многие приложения AVD зависят от HTTP/S API, веб-интерфейсов или баз данных. Проектируйте их с использованием глобальной балансировки нагрузки и региональных развертываний, чтобы отказ зависимостей не приводил к зависанию пользовательских сессий, которые в остальном исправны.
• Azure Front Door и Traffic Manager:
  • Используйте Azure Front Door для глобальной балансировки нагрузки на уровне 7 (HTTP/S), WAF и маршрутизации на основе путей для зависимостей приложений, используемых пользователями AVD. Сочетайте его с зонально-избыточными бэкендами в каждом регионе.
  • Используйте Azure Traffic Manager для балансировки нагрузки на основе DNS для общедоступных конечных точек, не использующих HTTP, которые поддерживают проверки работоспособности (health probes).
• Частный DNS и разрешение имен:
  • Централизуйте условные перенаправители (conditional forwarders) с помощью Azure DNS Private Resolver для маршрутизации запросов между локальными средами, виртуальными сетями Azure и управляемыми доменами. Публикуйте записи с низким TTL для конечных точек, которым может потребоваться быстрое переключение при отказе.
  • Для конечных точек хранения, которые не могут обеспечить бесшовное встроенное переключение при отказе, рассмотрите возможность использования конечных точек с двойными именами, абстрагированных за внутренним DNS, для переключения между основными и аварийными (DR) общими ресурсами во время инцидента.
• Сетевое QoS и доступ:
  • Приоритизируйте трафик AVD в реальном времени (UDP/TCP) в сетях WAN; настройте QoS на маршрутизаторах филиалов, чтобы обеспечить классам трафика AVD достаточную пропускную способность для уменьшения ошибок подключения и задержек.
  • Проверяйте доступность Shortpath и точечные открытия в брандмауэрах (firewall pinholes); убедитесь, что планирование пропускной способности для исходящего трафика соответствует количеству одновременных подключений и сочетанию рабочих нагрузок.

Миграция с RDS, обнаружение, плотность и емкость

• Оценка RDS:
  • Проведите инвентаризацию Connection Brokers, RD Gateways, RD Web, RD Session Hosts, RD Licensing и файловых серверов/хранилищ профилей. Задокументируйте GPO, конфигурацию FSLogix и методы доставки приложений.
  • Сопоставьте роли с конструкциями AVD: пулы хостов, рабочие области, группы приложений, хранилище профилей и управляемое AVD посредничество (brokering); устраните необходимость в RD Gateway и Broker в Azure.
• Azure Migrate и обнаружение:
  • Используйте устройство Azure Migrate для обнаружения существующих виртуальных машин RDS, базовых показателей производительности и зависимостей. Определите связи между приложениями и серверами для размещения хостов сеансов AVD и учета “гравитации данных” (data gravity).
• Анализ плотности пользователей:
  • Создайте модели плотности для каждой рабочей нагрузки (пользователи, выполняющие простые задачи/интеллектуальные работники/продвинутые пользователи). Рассчитайте количество сеансов на ВМ, используя показатели готовности ЦП (CPU ready), нагрузки на память (memory pressure) и базовые показатели IO профилей. Проверьте результаты с помощью пилотных тестов на подходящих SKU виртуальных машин (например, Dv5/Esv5/Dasv5, с поддержкой GPU для графики).
  • Используйте Azure Virtual Desktop Experience Estimator для выбора регионов с наименьшей задержкой между пользователем и хостом.
• Моделирование емкости:
  • Преобразуйте плотность в количество хостов на пул с буфером N+1 и запасом на обслуживание. Определите пороги для горизонтального масштабирования, а также минимальное/максимальное количество хостов в планах масштабирования. Рассмотрите возможность резервирования емкости для предсказуемых затрат и гарантированных ядер в загруженных регионах.
  • Убедитесь, что квоты подписки и региональные квоты (vCPU, ядра на семейство, IP-адреса, сетевые адаптеры, диски) увеличены заранее; отправляйте запросы на увеличение квот заблаговременно.

Прямой переход, сосуществование, квоты и сценарии автоматизации

• Планирование прямого перехода:
  • Обеспечить параллельное сосуществование: поддерживать работоспособность RDS, пока пилотные группы переходят на AVD. Публиковать одни и те же приложения в обеих системах, но направлять пользователей по когортам.
  • Пилотные когорты: начать с ИТ-специалистов и ранних последователей, затем расширить на репрезентативные отделы и после этого провести широкое развертывание. Использовать обратную связь для тонкой настройки образов, параметров FSLogix и масштабирования.
  • Откат: поддерживать пути доступа к RDS до тех пор, пока не будут выполнены критерии приемки. Сохранять обратную совместимость профилей пользователей или предоставить путь сброса профиля для каждой когорты.
• Операционная готовность:
  • Ключи регистрации: при добавлении существующих ВМ в пулы хостов сгенерируйте ключ регистрации и присоедините их с помощью агента AVD; автоматизируйте этот процесс с помощью Azure Image Builder и скриптов пост-конфигурации.
  • Гигиена рабочих пространств и групп приложений: публиковать группы приложений с минимальными привилегиями; разделять Desktop и RemoteApp; оставлять группы приложений для аварийного восстановления назначенными, но при необходимости визуально менее заметными.
• Сценарии автоматизации и автоматизация:
  • Создать сценарии автоматизации для обеспечения непрерывности бизнеса и аварийного восстановления (BCDR), которые охватывают:
    • Объявление инцидента и перевод основных пулов в режим стока (drain mode).
    • Масштабирование пулов аварийного восстановления и проверка паритета образов.
    • Переключение хранилища профилей с помощью Cloud Cache или перенаправления DNS.
    • Проверка критически важных зависимостей приложений через Front Door/Traffic Manager.
    • Информирование пользователей и службы поддержки.
    • Откат после восстановления основного региона.
  • Реализовать сценарии автоматизации с помощью Azure Automation или Functions с управлением доступом на основе ролей и утверждением изменений.
• Затраты и резервирования:
  • Использовать Savings Plans и Capacity Reservations для стабильных базовых рабочих нагрузок; поддерживать пиковую мощность по модели оплаты по мере использования (pay-as-you-go) с автомасштабированием. Настроить расписание для выключения непроизводственных пулов в нерабочее время.

Практический сценарий проблемы

Компания Adobe должна обеспечить непрерывную работу творческих групп и групп поддержки во время регионального сбоя при миграции с локальной фермы RDS на Azure Virtual Desktop. Учитываются сотни терабайт перемещаемых профилей и требовательные к графике рабочие нагрузки.

1. Анализ и определение базовых показателей

• Использовать Azure Migrate для инвентаризации хостов RDS, общих папок с профилями и зависимостей бизнес-приложений (LOB), а также для сбора данных о шаблонах использования CPU/памяти/IO для когорт с графическими и поддерживающими нагрузками.
• Почему: Эмпирические базовые показатели позволяют точно определить целевую плотность пользователей и выбрать SKU виртуальных машин, минимизируя избыточное выделение ресурсов.

2. Проектирование региональной архитектуры

• Создать основные пулы хостов в регионе West US 2 с ВМ NVadsA v5 с поддержкой GPU для творческих групп и Dv5 для групп поддержки; развернуть вторичные пулы в Central US.
• Реплицировать образы через Azure Compute Gallery; хранить пакеты MSIX в ANF с межрегиональной репликацией.
• Почему: Это обеспечивает паритет вычислительных ресурсов и приложений между регионами с предсказуемой производительностью.

3. Усиление защиты удостоверений и DNS

• Настроить DNS в VNet на IP-адреса Azure AD DS, к которым будут присоединяться хосты сеансов; развернуть Azure DNS Private Resolver для пересылки запросов между локальной средой и Azure.
• Почему: Надежное разрешение имен между регионами обеспечивает вход в систему и доступ к приложениям во время отработки отказа.

4. Реализация отказоустойчивых профилей

• Использовать Azure NetApp Files для FSLogix со снимками и межрегиональной репликацией; включить FSLogix Cloud Cache, указывающий на основной и DR-тома ANF.
• Почему: ANF обеспечивает IOPS/задержку, необходимые творческим группам; Cloud Cache и CRR (межрегиональная репликация) обеспечивают непрерывность работы в случае сбоя региона.

5. Оркестрация отработки отказа зависимостей

• Разместить веб-API бизнес-приложений (LOB) за Azure Front Door и настроить регионально развернутые бэкенды; использовать Traffic Manager для любых публичных конечных точек, не использующих HTTP.
• Почему: Это сохраняет доступность конечных точек приложений из любого региона AVD без необходимости перенастройки.

6. Определение целевых показателей восстановления и защиты

• Установить RTO в минутах для хостов в пуле (пересоздание), в часах для персональных рабочих столов (если есть, защищенных с помощью Azure Backup/ASR) и RPO 15 минут для профилей с помощью снимков ANF; выполнять резервное копирование общих папок Azure Files для когорты поддержки, если они используются.
• Почему: Целевые показатели для каждого компонента позволяют соотнести затраты с влиянием на бизнес.

7. Пилотирование и сосуществование

• Перевести 100 пользователей поддержки и 50 сотрудников творческих групп на AVD; параллельно оставить опубликованным RDS. Проверить плотность, стабильность профилей и производительность приложений. Итеративно дорабатывать политики масштабирования и настройки FSLogix.
• Почему: Контролируемые пилотные проекты снижают риски, связанные с выбором образов, хранилища и настроек автомасштабирования.

8. Прямой переход и учения по аварийному восстановлению

• Сгенерировать ключи регистрации AVD для расширения пулов; назначить группы приложений для DR всем пользователям. Провести учения по аварийному восстановлению: перевести основной пул в режим стока, масштабировать DR-пул, проверить непрерывность работы Cloud Cache и выполнить отработку отказа зависимостей приложений через Front Door.
• Почему: Это доказывает работоспособность сквозной отработки отказа, включая профили и зависимости, до начала полной миграции.

9. Квоты, резервирования и автоматизация

• Заранее увеличить региональные квоты на vCPU и GPU; приобрести Capacity Reservations для базовой нагрузки на GPU и CPU; реализовать сценарии Azure Automation для перевода в режим стока, масштабирования, переключения хранилища и коммуникаций.
• Почему: Это гарантирует наличие мощностей во время инцидентов и устраняет ручные шаги в стрессовых ситуациях.

10. Полная миграция и план отката

• Мигрировать оставшиеся когорты волнами в течение двух недель; поддерживать доступ к RDS в качестве пути для отката с четкими критериями принятия решений для каждой волны.
• Почему: Постепенный прямой переход снижает риски и сохраняет возможность немедленного отката в случае возникновения непредвиденных проблем.

← Мониторинг · Все домены

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

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