Рекомендации по непрерывности бизнес-процессов и аварийному восстановлению для виртуального рабочего стола Azure

  • Статья

Виртуальный рабочий стол Azure — это управляемая корпорацией Майкрософт служба, которая предоставляет уровень управления для среды виртуализации рабочего стола. Затраты на службу включены в состав соответствующих лицензий, см. в разделе "Цены на виртуальный рабочий стол Azure". Корпорация Майкрософт не предлагает финансово поддерживаемое соглашение об уровне обслуживания (SLA) для служб. Несмотря на отсутствие соглашение об уровне обслуживания, мы стараемся достичь по крайней мере 99,9 процента доступности для URL-адресов службы виртуального рабочего стола Azure.

Примечание.

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

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

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

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

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

При разработке инфраструктуры виртуального рабочего стола Azure учитывайте эти факторы проектирования.

Сравнение подходов активный — активный и активный — пассивный для пула узлов

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

Пул узлов Active-Active

  • Последствия сбоев хранилища сглаживаются без необходимости прохождения пользователем повторной проверки подлинности.
  • Включено непрерывное тестирование расположения аварийного восстановления.
  • Один пул узлов может содержать виртуальные машины из нескольких регионов. В этом сценарии необходимо использовать облачный кэш для активного реплика te профиля FSLogix пользователя и контейнеров Office между регионами.
  • Для виртуальных машин (виртуальных машин) в каждом регионе переверните запись реестра облачных кэшей, указывающую расположения, чтобы обеспечить приоритет для локального реестра кэша.
  • Балансировка нагрузки входящих подключений пользователей не может учитываться. Все узлы равны, и пользователи могут направляться на удаленную (не оптимальную) виртуальную машину пула узлов виртуального рабочего стола Azure.
  • Эта конфигурация ограничена общим типом пула узлов. Для личного (выделенного) типа, если пользователю назначен рабочий стол на определенной виртуальной машине узла сеансов, рабочий стол не изменяется, даже если виртуальная машина недоступна.
  • Облачный кэш не улучшает вход пользователей и выходить из системы при использовании плохого хранилища. Обычно средам, использующим облачный кэш, немного медленнее вход и время выхода, относительно использования традиционных VHDLocations с использованием одного и того же хранилища. Ознакомьтесь с документацией по FSLogix Cloud Cache, чтобы ознакомиться с рекомендациями по локальному хранилищу кэша.
  • Конфигурация пула узлов active-active часто сложна. Это не считается оптимизацией производительности или оптимизацией затрат.

Пул узлов active-пассивный

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

Устойчивость пула узлов

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

  • При создании пула узлов виртуального рабочего стола Azure можно выбрать различные варианты доступности.

  • При создании виртуальной машины важно выбрать подходящий вариант для ваших требований. Вы не можете изменить параметры доступности виртуальной машины позже.

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

    • SSD уровня "Премиум", "Ультра" или SSD уровня "Премиум" версии 2 — 99,9%
    • Стандартная Управляемые диски SSD — 99,5%
    • Стандартные Управляемые диски HDD — 95 %

  • Параметр устойчивости по умолчанию для развертывания пула узлов виртуального рабочего стола Azure — использовать зоны доступности.

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

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

    Примечание.

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

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

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

Расположение хранилища, используемое для контейнеров FSLogix, имеет решающее значение для обеспечения минимальной задержки от виртуальной машины пула узлов. При настройке VHDLocations записи реестра агент FSLogix может поддерживать несколько расположений профилей для повышения устойчивости. Вы можете использовать облачный кэш или убедиться, что на основе типа используемого хранилища используется правильный механизм реплика tion.

Azure предлагает несколько решений для хранения профиля FSLogix и контейнеров Office.

  • служба хранилища варианты контейнеров профилей FSLogix в Виртуальном рабочем столе Azure сравнивают доступные решения управляемого хранилища.
  • Файлы Azure или Azure NetApp Files для предприятий предлагают наибольшее значение для клиентов. Службы Azure упрощают управление виртуальным рабочим столом Azure и являются предпочтительными решениями для хранения для этой рабочей нагрузки.
  • Локальные дисковые пространства также поддерживается для FSLogix и виртуального рабочего стола Azure. Это решение для самостоятельного управления хранилищем, которое не рассматривается в этой статье.

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

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

  • Отдельные диски профилей пользователей и контейнеров Office. FSLogix предлагает возможность размещения дисков в разных местах хранения.

  • Не делайте диск Office устойчивым. В обычном использовании диск Office может использовать гораздо больше гигабайт, чем диск профиля. Это кэш данных, которые можно скачать еще раз из Microsoft 365 веб-службы.

  • Используйте OneDrive для перенаправления стандартных папок, таких как Desktop, Documents, Pictures, Сохраненные рисунки и Камера Roll. Перенаправление обеспечивает устойчивость этих данных без особого учета в сценарии BCDR.

  • Не включайте данные кэша для диска профиля, чтобы можно было быстрее создать резервную копию, реплика te и восстановить диск.

    Примечание.

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

Можно использовать несколько механизмов реплика и стратегий для пользовательских данных в контейнерах FSLogix.

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

  • Шаблон профиля #2. Кэш облака FSLogix имеет встроенный автоматический механизм для реплика te контейнеров между четырьмя различными учетными записями хранения.

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

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

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

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

Важно предотвратить потерю данных в критически важных пользовательских данных. Для защиты резервных копий рассмотрим следующие факторы:

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

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

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

Расположения данных для виртуального рабочего стола Azure

Виртуальный рабочий стол Azure хранит различные сведения об объектах обслуживания: имена пулов узлов, групп приложений, рабочих областей, субъектов-пользователей и т. д. Данные классифицируются по разным типам, таким как входные данные клиента, данные клиента, диагностические данные и данные, созданные службой. Дополнительные сведения см. в статье Расположения данных для Виртуального рабочего стола Azure.

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

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

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

Рекомендуется внедрить эти рекомендации в структуру инфраструктуры:

  • Чтобы BCDR для модели развертывания пула узлов Виртуального рабочего стола Azure используйте подход активный — пассивный, если он удовлетворяет вашим требованиям к целевой точке восстановления (RPO) и целевому времени восстановления (RTO).
  • Мы рекомендуем Azure Site Recovery для персональных (выделенных) пулов узлов. Целевой регион должен соответствовать аварийному восстановлению внутреннего сервера хранилища, который использует FSLogix.
  • Azure Site Recovery также поддерживается для общих пулов узлов. Этот вариант можно оценить и сравнить с развертыванием другого пула узлов в дополнительном регионе аварийного восстановления.
  • Если максимальная устойчивость пула узлов требуется в одном регионе, используйте зоны доступности. Убедитесь, что функция зон доступности доступна в определенном регионе. Убедитесь, что определенный номер SKU виртуальной машины доступен во всех зонах доступности.

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

  • Разделение профилей пользователей и контейнеров Office.

  • В этом порядке рекомендуется использовать следующие параметры для типов хранилища контейнеров:

    1. Файлы Azure категории "Премиум"
    2. Уровень "Стандартный" для Azure NetApp Files
    3. Уровень "Премиум" для Azure NetApp Files

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

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

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

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

    Примечание.

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

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

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

  • Рекомендуется следовать этим рекомендациям, если используется облачный кэш:

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

  • Используйте коллекцию вычислений Azure для реплика te золотых образов в разных регионах.

    • Золотые образы не участвуют в предоставлении пользователям возможности подключения к виртуальной машине узла сеанса. Однако они играют важную роль в том, как быстро вы сможете запустить процесс подготовки новых виртуальных машин в пуле узлов, поэтому их необходимо создать и создать резервную копию.
    • Используйте ZRS для создания образа. Сохраняйте по крайней мере две копии изображения в каждом регионе.

  • Используйте Azure Backup для защиты критически важных данных пользователей от потери данных или логического повреждения при использовании уровня Файлы Azure уровня "Стандартный" или "Премиум".

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

  • Внимательно изучите планы устойчивости и BCDR для зависимых ресурсов. К этим ресурсам относятся сеть, проверка подлинности, приложения и другие внутренние службы в Azure или в локальной среде.

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

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

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

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

  • Сведения о безопасности, управлении и соответствия требованиям для сценария корпоративного масштабирования Виртуального рабочего стола Azure.

    Безопасность, управление и соответствие требованиям