Аварийное восстановление виртуального рабочего стола Azure

  • Статья

Для обеспечения безопасности данных организации вам потребуется принять и внедрить стратегию непрерывности бизнес-процессов и аварийного восстановления (BCDR). Продуманная стратегия BCDR обеспечивает работу приложений и рабочих нагрузок во время планового и незапланированного обслуживания или простоев службы Azure. Эти планы должны охватывать виртуальные машины узлов сеансов, управляемые клиентами, в отличие от службы Виртуального рабочего стола Azure, которая управляется корпорацией Майкрософт. Дополнительные сведения об областях управления см. в описании основных понятий аварийного восстановления Виртуального рабочего стола Azure.

Служба Виртуального рабочего стола Azure разработана с учетом потребностей в высоком уровне доступности. Виртуальный рабочий стол Azure — это глобальная служба, управляемая корпорацией Майкрософт, в рамках которой несколько экземпляров независимых компонентов распределены по нескольким регионам Azure. Если в каком-либо из компонентов возникнет непредвиденный сбой, трафик будет перенаправлен на один из оставшихся экземпляров или корпорация Майкрософт инициирует полную отработку отказа в инфраструктуру избыточности в другом регионе Azure.

Чтобы гарантировать, что пользователи сохраняют возможность подключения во время сбоя в регионе на виртуальных машинах узлов сеансов, ваша инфраструктура должна учитывать потребности в высоком уровне доступности и аварийном восстановлении. Типичный план аварийного восстановления предусматривает репликацию виртуальных машин в другое расположение. Во время простоя первичный сайт выполняет отработку отказа на реплицируемые виртуальные машины в дополнительном расположении. Пользователи могут и дальше обращаться к приложениям из дополнительного расположения без перерывов. В дополнение к репликации виртуальных машин потребуется обеспечить доступ к удостоверениям пользователей в дополнительном расположении. Если вы используете контейнеры профилей, их также нужно реплицировать. Наконец, убедитесь, что бизнес-приложения, использующие данные в основном расположении, могут выполнить отработку отказа с остальными данными.

Подытожим, что для обеспечения подключения пользователей во время сбоя потребуется выполнить указанные ниже действия.

  • Реплицируйте виртуальные машины в дополнительное расположение.
  • Если вы используете контейнеры профилей, настройте репликацию данных в дополнительном расположении.
  • Убедитесь, что удостоверения пользователей, настроенные в основном расположении, доступны в дополнительном расположении. Чтобы гарантировать доступность, убедитесь, что контроллеры доменов Active Directory доступны в дополнительном расположении или из него.
  • Убедитесь, что для всех бизнес-приложений, использующих данные в основном расположении, выполняется отработка отказа в дополнительное расположение.

Планы аварийного восстановления "активный — пассивный" и "активный — активный"

Существует два разных типа инфраструктуры аварийного восстановления: режимы "активный — пассивный" и "активный — активный". Каждый тип инфраструктуры работает по-своему, поэтому давайте рассмотрим их различия.

Планы "активный — пассивный" включают один активный регион с одним набором ресурсов и один отключенный до момента, пока он не понадобится (т. е. пассивный). Если активный регион отключается из-за сбоя или аварии, организация может перейти на пассивный регион, включив его и направив туда всех пользователей.

Другой вариант — это развертывание типа "активный — активный", где одновременно используются оба набора инфраструктуры. Хотя сбои могут повлиять на некоторых пользователей, к их числу будут относиться только пользователи в отключившемся регионе. Пользователи в другом регионе, который по-прежнему находится в сети, не будут затронуты, и восстановление ограничено пользователями в затронутом регионе, повторно подключающимся к работающему активному региону. Развертывания "активный-активный" могут принимать множество форм, в том числе:

  • Предоставление избыточной инфраструктуры в каждом регионе для размещения затронутых пользователей в случае выхода из строя одного из регионов. Потенциальный недостаток этого метода заключается в повышении затрат на обслуживание дополнительных ресурсов.
  • У вас могут быть дополнительные узлы сеансов в обоих активных регионах, которые вы будете высвобождать, когда они оказываются не нужны, что позволяет сократить затраты.
  • Подготавливайте новую инфраструктуру только во время аварийного восстановления и разрешайте затронутым пользователям подключаться к недавно подготовленным узлам сеансов. Этот метод требует регулярного тестирования с помощью инструментов «инфраструктура как код», чтобы вы могли как можно быстрее развернуть новую инфраструктуру во время аварии.

Дополнительные сведения о типах имеющихся планов аварийного восстановления см. в описании основных понятий аварийного восстановления Виртуального рабочего стола Azure.

Работу следует начинать с выбора метода, который лучше всего подходит для вашей организации. После первоначального планирования можно приступать к разработке плана восстановления.

Репликация виртуальной машины

Сначала нужно реплицировать виртуальные машины в дополнительное расположение. Параметры для этого зависят от настройки виртуальных машин:

  • Вы можете настроить репликацию всех своих виртуальных машин как для общих, так и для личных пулов узлов с использованием Azure Site Recovery. Дополнительные сведения о том, как этот процесс работает, см. в статье Репликация виртуальных машин Azure в другой регион Azure. Однако если у вас есть пулы узлов, созданные на основе одного образа, и нет хранящихся локально персональных данных пользователей, их можно не реплицировать. Вместо этого можно заранее создавать виртуальные машины и держать их в отключенном состоянии. Вы также можете выполнять подготовку новых виртуальных машин только в дополнительном регионе во время аварии. Если вы выберете эти методы, вам потребуется настроить только один пул узлов и соответствующие группы приложений и рабочие области.
  • Вы можете создать пул узлов в регионе отработки отказа, оставив все ресурсы в расположении отработки отказа отключенными. Для этого метода необходимо настроить новые группы приложений и рабочие области в регионе отработки отказа. Затем можно использовать план Azure Site Recovery для включения пулов узлов.
  • Вы можете создать пул узлов, который заполняется виртуальными машинами, созданными как в основном регионе, так и в регионе отработки отказа, оставив виртуальные машины в регионе отработки отказа отключенными. В этом случае необходимо настроить только один пул узлов и связанные с ней группы приложений и рабочие области. В рамках этого метода вы можете использовать план Azure Site Recovery, чтобы включить пулы узлов.

Мы рекомендуем использовать Azure Site Recovery для управления репликацией виртуальных машин в другие расположения Azure, как указано в статье Архитектура аварийного восстановления из Azure в Azure. Особенно рекомендуется использовать Azure Site Recovery для пулов личных узлов, поскольку такие пулы, как следует из их названия, обычно так или иначе связаны с персональными данными пользователей. Azure Site Recovery поддерживает номера SKU на основе сервера и клиента.

Если вы используете Azure Site Recovery, вам не понадобится регистрировать эти виртуальные машины вручную. Агент Виртуального рабочего стола Azure на вторичной виртуальной машине автоматически будет использовать последний маркер безопасности для подключения к ближайшему к нему экземпляру службы. Виртуальная машина (узел сеансов) в дополнительном расположении автоматически станет частью пула узлов. Конечному пользователю потребуется повторить подключение во время этой процедуры, однако другие выполняемые вручную операции отсутствуют.

Если во время сбоя существуют пользовательские соединения, прежде чем администратор сможет запустить отработку отказа в дополнительный регион, вам нужно завершить соединения пользователей в текущем регионе.

Чтобы отключить пользователей в Виртуальном рабочем столе Azure (классическая версия), выполните следующий командлет:

Invoke-RdsUserSessionLogoff

Чтобы отключить пользователей в Виртуальном рабочем столе Azure, выполните следующий командлет:

Remove-AzWvdUserSession

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

Виртуальная сеть

Далее рассмотрите возможности сетевого подключения во время сбоя. Вам потребуется убедиться, что в дополнительном регионе настроена виртуальная сеть. Если пользователям нужно обращаться к локальным ресурсам, потребуется настроить эту виртуальную сеть для такого доступа. Вы можете устанавливать локальные подключения с помощью VPN, ExpressRoute или виртуальной глобальной сети.

Мы рекомендуем использовать службу Azure Site Recovery, чтобы настроить виртуальную сеть в регионе отработки отказа, так как она сохраняет параметры основной сети и не требует пиринга.

Удостоверения пользователей

Затем убедитесь, что контроллер домена доступен в дополнительном расположении.

Существует три способа сохранения доступа к контроллеру домена:

  • Использование одного или нескольких контроллеров доменов Active Directory в дополнительном расположении
  • Использование локального контроллера домена Active Directory
  • Репликация контроллера домена Active Directory с помощью Azure Site Recovery

Профили пользователей

Рекомендуется использовать FSLogix для управления профилями пользователей. Дополнительные сведения см. в разделе "Непрерывность бизнес-процессов" и варианты аварийного восстановления для FSLogix.

Резервное копирование данных

Вы также можете создать резервную копию данных. Вы можете выбрать один из перечисленных ниже способов резервного копирования данных Виртуального рабочего стола Azure.

  • Для данных вычислений рекомендуется выполнять резервное копирование только пулов личных узлов с помощью Azure Backup.
  • Для служба хранилища данных решение резервного копирования, которое рекомендуется, зависит от внутреннего хранилища, используемого для хранения профилей пользователей:

Зависимости приложений

Наконец, убедитесь, что все бизнес-приложения, которые используют данные, расположенные в основном регионе, могут выполнить отработку отказа в дополнительное расположение. Кроме того, обязательно настройте параметры, необходимые приложениям для работы в новом расположении. Например, если одно из приложений зависит от серверной части SQL, обязательно выполните репликацию SQL в дополнительном расположении. Необходимо настроить приложение для использования дополнительного расположения в качестве части процесса отработки отказа или в качестве конфигурации по умолчанию. Вы можете моделировать зависимости приложений в планах Azure Site Recovery. Дополнительные сведения см. в статье Сведения о планах восстановления.

Тестирование аварийного восстановления

После завершения настройки аварийного восстановления необходимо протестировать план, чтобы убедиться, что он работает.

Ниже приведены некоторые рекомендации по тестированию плана.

  • Если тестовые виртуальные машины имеют доступ к Интернету, они будут использовать любой существующий узел сеансов для новых подключений, но все существующие подключения к исходному узлу сеансов останутся активными. Убедитесь, что администратор, проводящий тестирование, выполнил выход для всех активных пользователей перед тестированием плана.
  • Полные тесты аварийного восстановления следует выполнять только в период обслуживания, чтобы не нарушать работу пользователей.
  • Убедитесь, что тест охватывает все критически важные для бизнеса приложения и данные.
  • За один раз рекомендуется выполнять отработку отказа до 100 виртуальных машин. Если виртуальных машин больше, рекомендуется выполнить их отработку партиями с интервалом в 10 минут.

Следующие шаги

Если у вас есть вопросы по обеспечению безопасности данных, выходящие за рамки планирования процедур на случай сбоев и простоев, ознакомьтесь с нашим руководством по безопасности.