Непрерывность бизнес-процессов и аварийное восстановление (BCDR) для сценария корпоративного уровня виртуальных рабочих столов Windows

Виртуальный рабочий стол Windows — это управляемая служба, которая предоставляет Microsoft a Control плоскость для среды виртуализации настольных систем. Служба не взимается, а корпорация Майкрософт не предлагает соглашение об уровнеобслуживания с финансовыми обязательствами. Несмотря на отсутствие соглашения об уровне обслуживания, мы пытаемся обеспечить доступность по крайней мере 99,9% для URL-адресов службы виртуальных рабочих столов Windows.

Примечание

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

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

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

Хорошая стратегия BCDR обеспечивает работу критически важных приложений и рабочих нагрузок во время плановых и незапланированных служб или простоев Azure.

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

Рекомендации по проектированию

Стратегия вычислений пула узлов

  • Для пула узлов виртуальных рабочих столов Windows как " активный — активный ", так и " активный — пассивный " могут быть хорошими BCDR подходами в зависимости от требований.

    • В режиме "активный — активный" один пул узлов может содержать виртуальные машины из нескольких регионов. В этом сценарии использование облачного кэша требуется для активной репликации профиля фслогикс пользователя и контейнеров Office между регионами. Для виртуальных машин в каждом регионе запись реестра облачного кэша, задающая расположения, должна быть инвертирована, чтобы присвоить приоритет локальному.

      • Такая конфигурация является сложной. " активный — активный " обеспечивает защиту от простоев хранилища, не требуя от пользователя повторного входа. Затем он обеспечивает непрерывное тестирование расположения аварийного восстановления. Такая конфигурация не рассматривается как оптимизация производительности или стоимости.
      • Балансировка нагрузки входящего подключения пользователей не может принять учетные записи. все узлы будут равны, и пользователи могут быть направлены на удаленный (неоптимальный) виртуальный компьютер пула узлов Windows.
      • Эта конфигурация ограничена типом пула узлов в составе пула (общий). Для личного (выделенного) типа, когда рабочий стол назначается пользователю на определенной виртуальной машине узла сеансов, он фиксируется и не изменяется, даже если он недоступен.
    • В режиме "активный — пассивный", Azure Site Recoveryили в дополнительном пуле узлов (горячая замена) можно использовать параметры региона аварийного восстановления.

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

    • Параметр устойчивости по умолчанию для развертывания пула узлов виртуальных рабочих столов Windows — Группа доступности. Этот параметр обеспечивает устойчивость пула узлов только на одном уровне центра обработки данных Azure, при этом соглашение об уровне обслуживанияс высоким уровнем доступности 99,95%.

      Примечание

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

    • С помощью зоны доступностивиртуальные машины в пуле узлов распределяются по разным центрам обработки данных. Виртуальные машины по-прежнему находятся в одном регионе и имеют более высокий уровень устойчивости и более 99,99% соглашения об уровне обслуживанияс высоким уровнем доступности. При планировании емкости необходимо учитывать достаточно лишнюю мощность вычислений, чтобы гарантировать, что виртуальная система Windows продолжит работать даже при утере одной зоны.

      Примечание

      Для указания зон необходимо использовать шаблон Azure Resource Manager (ARM). Этот параметр пока недоступен в портал Azure.

  • Критические приложения и пулы узлов

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

Оптимальное хранилище для контейнеров профиля и Office

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

  • В BCDR ситуации можно сократить время, затрачиваемое на резервное копирование, восстановление и репликацию данных, разделяя профиль пользователя и диски контейнеров Office. Фслогикс предлагает возможность поместить их в отдельные места хранения. При нормальном использовании диск Office может потреблять гораздо больше гигабайтов, чем профиль. Резервное копирование, репликация и восстановление диска профиля происходит быстрее без включения данных кэша. Диск Office не обязан быть устойчивым, так как он просто кэширует данные и может быть скачан повторно. Содержащиеся в нем данные уже полностью находятся в Microsoft 365 веб-службы.

    Примечание

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

  • OneDrive можно использовать для перенаправления хорошо известных папок ( Desktop ,,, Documents Pictures Screenshots и Camera Roll ) при их наличии. Такое перенаправление обеспечивает устойчивость этих специальных папок. Папки могут обрабатываться OneDrive, а не требовать особой необходимости в сценарии BCDR.

  • Azure предлагает несколько решений для хранения данных, которые можно использовать для хранения профиля Фслогикс и контейнера Office. Параметры хранилища для контейнеров профилей фслогикс в Windows Virtual Desktop сравнивает различные решения для управляемых хранилищ Azure для контейнера профиля пользователя Windows Virtual Desktop фслогикс. Локальные дисковые пространства также поддерживается с виртуальным рабочим столом Фслогикс и Windows. Это решение для самостоятельного управления хранилищем, которое выходит за рамки этой статьи. Клиенты могут получить наибольшее значение из файлов Azure или Azure NetApp Files, одновременно упрощая управление виртуальными рабочими столами Windows. Это Рекомендуемые решения для хранения данных рабочей нагрузки.

  • Агент Фслогикс может поддерживать несколько расположений профилей для обеспечения высокой отказоустойчивости при настройке VHDLocations записи реестра. В этом случае необходимо использовать правильный механизм репликации в зависимости от используемого типа хранилища. Вместо этого можно использовать облачный кэш.

Репликация и устойчивость хранилища пользовательских данных

В виртуальных рабочих столах Windows для пользовательских данных в контейнерах фслогикс можно использовать несколько механизмов и стратегий репликации:

  • #1 шаблона профиля: Собственные механизмы репликации хранилища Azure. Например, геоизбыточное хранилище (GRS) для стандартных файловых ресурсов — репликация Azure NetApp Files или Синхронизация файлов Azure для файловых серверов на основе виртуальных машин.

  • #2 шаблона профиля: Облачный кэш фслогикс имеет встроенный автоматический механизм для репликации контейнеров между четырьмя разными учетными записями хранения.

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

Доступность эталонного образа

Если вы используете пользовательские образы для развертывания виртуальных машин пула узлов виртуальных рабочих столов Windows, важно обеспечить доступность этих артефактов во всех регионах, если возникает серьезная авария. Используйте службу " Коллекция общих образов Azure " для репликации образов во всех регионах, где пул узлов развертывается с избыточным хранилищем и несколькими копиями.

Резервное копирование

Важно предотвратить потери данных для критически важных пользовательских данных.

  • Оцените, какие данные необходимо сохранить и защитить. Если вы используете OneDrive или другое внешнее хранилище, сохранение профиля пользователя или данных контейнера Office может быть необязательным.

  • Рассмотрите механизм обеспечения защиты важных пользовательских данных.

    • Вы можете использовать службу Azure Backup для защиты данных профиля и контейнера Office при хранении на уровне "Стандартный" или "Премиум" файлов Azure.
    • Вы можете использовать Azure NetApp Files моментальные снимки и политики для Azure NetApp Files на всех уровнях.
    • Для защиты виртуальных машин пула узлов можно использовать Azure Backup. Эта практика поддерживается, даже если виртуальные машины пула узлов не имеют состояний.

Зависимости инфраструктуры и приложений

  • Если пользователям инфраструктуры виртуальных рабочих столов Windows требуется доступ к локальным ресурсам, важно учитывать высокий уровень доступности инфраструктуры сети, необходимой для подключения.
  • Оцените и оцените устойчивость инфраструктуры проверки подлинности.
  • Рассмотрим BCDR аспекты для зависимых приложений и других ресурсов. Эти аспекты гарантируют доступность во вторичном расположении аварийного восстановления.

Рекомендации по проектированию

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

  • Для модели развертывания пула узлов виртуальных рабочих столов Windows BCDR используйте параметр активный-пассивный , если он удовлетворяет требованиям к цели точки восстановления (RPO) и целевому времени восстановления (RTO).

  • Azure Site Recovery рекомендуется использовать для личных (выделенных) пулов узлов. Целевой регион следует согласовать с аварийным восстановлением серверной части хранилища, используемой Фслогикс.

    • Azure Site Recovery также поддерживается для пулов узлов в составе пула (Общий). Этот параметр можно оценить и сравнить с развертыванием другого пула узлов в дополнительном регионе аварийного восстановления.
  • Если в одном регионе требуется максимальная устойчивость пула узлов, используйте зоны доступности.

    • Проверьте доступность функций зоны доступности в определенном регионе и доступность конкретного номера SKU виртуальной машины во всех зонах.
  • Для большинства сценариев мы рекомендуем хранить профиль пользователя Фслогикс и контейнеры Office в службе файлов Azure или Azure NetApp Files.

    • Мы рекомендуем разбить профиль пользователя и контейнеры Office.
    • Ниже приведены рекомендуемые параметры для типов хранилища контейнера (по порядку): уровень "Премиум" для файлов Azure Azure NetApp Files, уровень "Стандартный" и Azure NetApp Files уровня "Премиум". Рекомендуемый тип хранилища зависит от ресурсов и задержки, необходимой для конкретной рабочей нагрузки.
    • Для оптимальной производительности поместите контейнеры Фслогикс в хранилище ближе к виртуальной машине, в которой пользователь вошел в систему. Лучше хранить контейнеры в одном центре обработки данных.
  • Используйте встроенные механизмы репликации службы хранилища Azure для BCDR, если это возможно для менее важных сред.

    • Используйте хранилище, избыточное в зонах (ZRS) или GRS, для файлов Azure.
    • Используйте LRS с локальной устойчивостью только в том случае, если защита зоны или региона не требуется.

Примечание

GRS недоступен на уровне службы файлов Azure Premium или уровня "Стандартный" с включенной поддержкой больших файлов.

  • Использовать облачный кэш следует только в следующих случаях:

    • Доступность данных в профиле пользователя или контейнере Office требует высокой доступности, или соглашение об уровне обслуживания является критически важным и должно быть устойчивым к сбоям региона.
    • Выбранный параметр хранилища не может удовлетворять требованиям BCDR. Например, GRS недоступен на уровне службы файлов Azure Premium или уровня "Стандартный" с включенной поддержкой больших файлов.
    • Требуется репликация между разнородным хранилищем.
  • При использовании облачного кэша рекомендуется следовать приведенным ниже рекомендациям.

    • Используйте твердотельный накопитель (SSD) для управляемого диска виртуальных машин пула узлов виртуальных рабочих столов Windows.
    • Создайте решение резервного копирования для защиты профиля пользователя и контейнеров Office.
    • Убедитесь, что управляемый диск для локальной виртуальной машины достаточно велик, чтобы разместить локальный кэш профиля Фслогикс всех пользователей и контейнеров Office.
  • Используйте коллекцию общих образов Azure для репликации эталонных образов в разные регионы.

    • Хранилище, используемое для создания образа, должно быть хранилищем, избыточным в виде зоны (ZRS). Должна поддерживаться по крайней мере две копии на регион.
  • Используйте Azure Backup для защиты критически важных пользовательских данных от потери данных или логического повреждения при использовании уровня "Стандартный" или "Премиум" файлов Azure.

    • Используйте моментальные снимки и политики при использовании службы Azure NetApp Files.
    • Даже если поддерживается, использование Azure Backup для сохранения состояния виртуальной машины в пуле узлов не рекомендуется, так как оно должно быть без отслеживания состояния.
  • Внимательно изучите планы устойчивости и BCDR для зависимых ресурсов. Эти ресурсы включают в себя сетевые подключения, проверку подлинности, приложения и другие внутренние службы в Azure или в локальной среде.

    • Сетевая инфраструктура, как часть Центральной и периферийной (WAN) архитектуры, должна быть доступна в дополнительном регионе.
    • Гибридное подключение должно иметь высокий уровень доступности как в основном, так и в дополнительном регионах.
    • Проверка подлинности Active Directory должна быть доступна в регионе аварийного восстановления или должна быть гарантирована возможность подключения к локальному домену.