Многорегионный BCDR для виртуального рабочего стола Azure

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

Руководство основывается на двух связанных ресурсах:

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

• Рекомендации по bc для рабочих нагрузок Виртуального рабочего стола Azure, которые предоставляют принципы проектирования и рекомендации на уровне компонентов на основе Azure Well-Architected Framework.

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

Цели и области

В этом руководстве приведены следующие цели:

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

• Свести к минимуму время восстановления.

Эти цели также называются целевой точкой восстановления (RPO) и целевой целью времени восстановления (RTO).

Достижимые RPO и RTO зависят от выбранной модели BCDR и типа пула узлов. В следующей таблице приведены приблизительные оценки для каждой модели.

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

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

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

• На уровне хранилища по возможности используйте устойчивость зоны.

• На сетевом уровне развертывайте устойчивые к зонам шлюзы Azure ExpressRoute и vpn-шлюзы.

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

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

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

Ограничения области

В этой статье описываются последствия затрат, но основное внимание уделяется эффективному развертыванию геокатастерного восстановления, которое сводит к минимуму потери данных. Он не охватывает OneDrive. Дополнительные сведения см. в статье о устойчивости данных SharePoint и OneDrive в Microsoft 365.

Дополнительные сведения о BCDR см. в следующих статьях:

• Рекомендации по обеспечению непрерывности бизнеса для рабочих нагрузок Azure Virtual Desktop
• Рекомендации по BCDR для виртуального рабочего стола Azure
• Аварийное восстановление виртуального рабочего стола Azure

Необходимые условия

Перед реализацией многорегионального BCDR разверните базовую инфраструктуру зоны посадки как в первичном, так и во вторичном регионах Azure. Руководство по топологии сети, удостоверениям и структуре подписки см. в руководстве по проектированию зоны приземления Azure Virtual Desktop и топологии сети и подключению для Azure Virtual Desktop.

Для BCDR выполните следующие предварительные требования к сети:

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

• Убедитесь, что каждый концентратор обеспечивает гибридное подключение к локальным ресурсам, службам брандмауэра, ресурсам удостоверений, таким как контроллеры домена Active Directory и ресурсам управления, таким как Log Analytics.

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

Плоскость управления Azure Виртуальным Рабочим Столом BCDR

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

Географические пулы хостов и региональные пулы хостов

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

• Географические пулы узлов (классическая модель): Эта модель хранит метаданные пула узлов в географической базе данных, которая обслуживает несколько регионов Azure в одном географическом регионе Azure. База данных реплицируется в парный регион для восстановления между регионами. Проблема с базой данных или инфраструктурой в регионе, на котором размещена географическая база данных, влияет на пулы узлов во всех регионах этого региона, даже если эти регионы в противном случае работоспособны.

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

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

Для BCDR развертываний региональные узловые пулы предоставляют следующие преимущества:

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

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

• Независимая операция: Во время регионального сбоя пул узлов вторичного региона продолжает работать с собственной инфраструктурой управляющей плоскости и не зависит от пострадавшего региона.

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

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

Следующие типы пулов узлов виртуального рабочего стола Azure поддерживают различные решения для восстановления:

• Личные: В этом типе пула узлов пользователи имеют постоянно назначенный узел сеанса, и это назначение остается фиксированным. Так как у каждого пользователя есть выделенная виртуальная машина, виртуальная машина может хранить пользовательские данные. Используйте методы репликации и резервного копирования для сохранения и защиты этого состояния.

• Объединенный: В этом типе пула узлов система выполняет временное назначение пользователей на доступные сеансовые хосты виртуальных машин из пула, либо через группу рабочих столов (DAG), либо с помощью удаленных приложений. Виртуальные машины являются бессерверными, а система хранит данные и профили пользователей во внешнем хранилище или OneDrive.

Активный-активный и активный-пассивный

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

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

Характеристики активно-активной модели

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

Проектирование пула узлов и отказоустойчивости

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

Рекомендации по хранению и профилям

Каждый пул узлов имеет собственные учетные записи хранения (по крайней мере один) для постоянных профилей пользователей.

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

Взаимодействие с пользователем и группы приложений

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

Задержка и региональное взаимодействие

Оцените задержку на основе физического расположения пользователя и доступного подключения. Для некоторых регионов Azure, таких как Западная Европа и Северная Европа, разница может быть незначительной при доступе к основным или вторичным регионам. Оцените задержку сети на основе физического расположения каждого пользователя и регионов, в которых размещаются как узлы сеансов, так и внутренние системы, включая бизнес-приложения, базы данных и общие папки. Тесная близость между пользователями, хостами сеансов и бэкэнд-системами, к которым они обращаются, имеет решающее значение для обеспечения быстрого отклика. Чтобы проверить задержку, можно развернуть тестовые виртуальные машины в нужном регионе и использовать такие средства PowerShell, как Test-NetConnection или PsPing для отправки тестового трафика в клиентские системы и из них.

В сценарии аварийного восстановления пользователи подключаются к хостам сеансов во вторичном регионе, который может находиться дальше как от пользователей, так и от ресурсов бэкэнда. Это расстояние увеличивает задержку кругового пути и может снизить скорость реагирования приложений, особенно для рабочих нагрузок с учетом задержки, таких как базы данных в режиме реального времени, голосовая связь через IP-адрес (VoIP) или интерактивные средства разработки. Для некоторых пар регионов Azure, таких как Западная Европа и Северная Европа, задержка между регионами достаточно низка, чтобы снижение производительности во время отработки отказа оказывало минимальное или нулевое воздействие. Для других пар регионов, разделенных большим расстоянием, влияние может быть значительным.

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

Характеристики модели активного-пассивного типа

В этом разделе описывается, как работает развертывание Azure Virtual Desktop в активно-пассивном режиме, включая планирование вычислительных ресурсов, поведение при отработке отказа и управление профилями.

Пул хостов и планирование вычислений

Как и модель active-active, вы развертываете второй пул узлов во вторичном регионе для каждого пула узлов в основном регионе.

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

Эта конфигурация обеспечивает более высокое значение RTO, чем подход "активный-активный", но она стоит меньше.

Механизм переключения на резервный модуль и доступ пользователей

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

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

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

Поведение группы приложений

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

Рекомендации по FSLogix

Если требуется хранилище для управления профилями FSLogix и контейнерами Office, используйте облачный кэш для обеспечения почти нулевого RPO.

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

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

Выборочное тестирование отработки переключения

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

Единый пул хостов в разных регионах

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

Режим слива можно использовать для временного отключения доступа к узлам сеансов, расположенным во вторичном регионе, но этот подход усложняет управление, увеличивает накладные расходы и ведет к неэффективному использованию ресурсов. Узлы сеансов можно поддерживать в офлайн-состоянии во вторичных регионах, но этот подход увеличивает сложность и накладные расходы на управление.

Сравнение моделей BCDR

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

Схемы архитектуры

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

Личный пул хостов

Скачайте файл Visio для этой архитектуры.

Объединенный пул узлов

Скачайте файл Visio для этой архитектуры.

Соображения и рекомендации

Рассмотрим следующие соображения и рекомендации.

Общие сведения

Чтобы развернуть настройку active-active или active-passive, которая использует несколько пулов узлов и механизм облачного кэша FSLogix, создайте пул узлов в той же рабочей области или другой рабочей области в зависимости от модели. Этот подход требует согласования и постоянных обновлений, чтобы обеспечить синхронизацию обоих пулов узлов и поддержания их на одном уровне конфигурации. При создании нового пула хостов для вторичного региона DR необходимо выполнить следующие задачи:

• Создайте группы приложений и связанные приложения для нового пула узлов.

• Отмените назначения пользователей в основном пуле узлов и вручную переназначьте их новому пулу узлов при переключении на резервный узел.

• Просмотрите параметры BCDR для FSLogix.

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

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

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

• Используйте отдельную рабочую область Log Analytics для каждого региона и укажите компоненты виртуального рабочего стола Azure для отправки журналов в локальную рабочую область.

• Протестируйте и просмотрите возможности репликации рабочей области Log Analytics и отработки отказа.

Compute

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

Доступность и устойчивость узлов сеансов

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

Согласованность эталонного образа системы в разных регионах

Эталонный образ, используемый для развертывания пула хостов в дополнительном регионе аварийного восстановления, должен соответствовать эталонному образу, используемому для основного региона. Храните образы в галерее и настраивайте несколько реплик образов как в основном, так и во вторичном расположении. Каждая реплика образа поддерживает максимальное количество виртуальных машин, которые могут развертываться параллельно, и может потребоваться несколько реплик в зависимости от размера пакета развертывания. Дополнительные сведения см. в разделе "Хранение и предоставление общего доступа к изображениям в Галерее вычислений".

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

Галерея вычислений — это региональный ресурс. Создайте хотя бы одну вторичную коллекцию в дополнительном регионе. В основном регионе создайте коллекцию, определение образа виртуальной машины и версию образа виртуальной машины. Затем создайте те же объекты в дополнительном регионе. При создании версии образа виртуальной машины в дополнительном регионе можно скопировать версию образа из основного региона, указав исходную коллекцию, определение образа виртуальной машины и версию образа виртуальной машины. Azure копирует образ и создает локальную версию образа виртуальной машины. Эту операцию можно выполнить с помощью портала Azure или команды Azure CLI.

Принципы оформления золотого изображения, включая ZRS и планирование реплики, см. в статье "Золотые изображения" в рекомендациях BC.

Автомасштабирование и оптимизация затрат

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

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

Рекомендации по емкости во время аварий

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

Размер диска кэша облака

Для вариантов использования облачного кэша рекомендуется использовать уровень "Премиум" для управляемых дисков. В облачном кэше используется локальный диск кэша на каждом хосте сеанса для предварительного сохранения данных профиля перед репликацией с удаленными поставщиками хранилищ. Размер этого диска локального кэша должен быть по крайней мере таким, как максимальный ожидаемый VHD-файл профиля пользователя или расширенный виртуальный жесткий диск (VHDX). Недостаточный кэш-диск приводит к сбоям при входе. В качестве отправной точки выделите по крайней мере 30 ГБ для каждого параллельного пользователя и отслеживайте фактические размеры профилей для настройки. Дополнительные сведения см. в документации по облачному кэшу.

Хранение

В этом руководстве используется по крайней мере две отдельные учетные записи хранения для каждого пула узлов Виртуального рабочего стола Azure. Одна учетная запись относится к контейнеру профиля FSLogix, а одна учетная запись — для данных контейнера Office. Для пакетов MSIX также нужна еще одна учетная запись для хранения.

Параметры хранилища и устойчивость

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

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

• Для этого требуется регион, который не имеет пары регионов. Пары регионов для GRS зафиксированы и не могут быть изменены.

• Вы используете уровень "Премиум".

  Предупреждение

  Уровень "Премиум" службы "Файлы Azure" не поддерживает GRS. Если требуется производительность уровня "Премиум" для хранилища профилей FSLogix, следует использовать облачный кэш FSLogix для репликации между регионами, а не встроенную георепликацию хранилища.

• RPO и RTO выше по сравнению с облачным кэшем.

• Тестирование переключения на резервный канал и возврата на основной канал в рабочей среде не является простым.

Рекомендации по Azure NetApp Files

Azure NetApp Files поддерживает эластичные зоны с избыточными томами, которые распределяют данные между зонами доступности для обеспечения отказоустойчивости на уровне зоны. Определите, соответствуют ли эластичные зоны-избыточные тома вашим требованиям к устойчивости. Azure NetApp Files может быть зональным, что означает, что вы выбираете одну зону доступности Azure, в которой выделен том.

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

Вы можете использовать Azure NetApp Files с зонально-избыточными VPN-шлюзами и шлюзами ExpressRoute, если вы используете функцию стандартного сетевого подключения, которая поддерживает устойчивость сети. Дополнительные сведения см. в статье "Поддерживаемые топологии сети". Виртуальная глобальная сеть Azure поддерживается при использовании ее с стандартными сетями Azure NetApp Files.

Репликация Azure NetApp Files между регионами

Azure NetApp Files имеет механизм репликации между регионами. Этот механизм недоступен во всех регионах, а репликация между регионами пар томов Azure NetApp Files может отличаться от пар регионов хранилища. Репликацию между регионами нельзя использовать, если репликация между зонами активна.

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

Ограничения хранилища и масштабирование

Общие ресурсы Azure Files и учетные записи хранения и тома Azure NetApp Files имеют ограничения по размеру, операциям ввода-вывода в секунду (IOPS) и пропускной способности в МБ/с.

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

Параметры учетной записи хранения MSIX

Учетная запись хранения, используемая для пакетов приложений MSIX, должна отличаться от других учетных записей для контейнеров Profile и Office. Доступны следующие варианты геоаварийного восстановления:

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

• Рекомендуемый вариант использует одну учетную запись хранения в основном регионе и одну учетную запись хранения в дополнительном регионе. Используйте ZRS по крайней мере для основного региона. Убедитесь, что каждый пул узлов в каждом регионе имеет локальный доступ с низкой задержкой к пакетам MSIX. Скопируйте каждый пакет MSIX в оба региона и зарегистрируйте пакеты в обоих пулах узлов. Назначьте пользователей группам приложений в обоих пулах узлов.

FSLogix

Рекомендуется использовать следующую конфигурацию и компоненты FSLogix.

Если содержимое контейнера профиля требует отдельного управления BCDR с различными требованиями, чем контейнеры Office, разделите контейнеры профилей и контейнеры Office на отдельные учетные записи хранения. Контейнеры Office хранят только кэшированное содержимое, которое можно перестроить или восстановить из источника в случае аварии. Так как контейнеры Office содержат только кэшированные данные, вам может не потребоваться хранить резервные копии, что может снизить затраты. При использовании разных учетных записей хранения настройте резервные копии только в контейнере профиля. Или у вас должны быть различные параметры, такие как период хранения, используемое хранилище, частота и RTO или RPO.

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

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

Облачный кэш совместим с параметрами разделения профилей и параметров для каждой группы . Для настроек для каждой группы требуется внимательное проектирование и планирование групп Active Directory и членства. Убедитесь, что каждому пользователю назначена ровно одна группа, и она используется для предоставления доступа к пулам узлов.

Во вторичном регионе аварийного восстановления измените порядок поставщиков CCDLocations так, чтобы учетная запись для локального (вторичного) хранения была первой. Облачный кэш записывает в первый доступный поставщик в качестве активного целевого объекта записи и асинхронно реплицируется в последующие записи. Когда вы располагаете учетную запись локального хранилища первой в каждом регионе, вы убеждаетесь, что записи отправляются в локальное хранилище во время обычных операций и что репликация выполняется между регионами. Дополнительные сведения см. в разделе "Настройка контейнеров профилей с облачным кэшем".

Пример конфигурации облачного кэша

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

Конфигурация основного региона

Следующие параметры применяются в основном регионе:

• Универсальный идентификатор ресурса учетной записи хранения контейнера профилей (URI) = \\primarystgprofiles\profiles

  • Путь к разделу реестра = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles

  • Значение CCDLocations =type=smb,connectionString=\\primarystgprofiles\profiles;type=smb,connectionString=\\secondarystgprofiles\profiles

  Замечание

  При скачивании шаблонов FSLogix можно достичь одинаковых конфигураций с помощью консоли управления групповыми политиками Active Directory (GPMC). Дополнительные сведения о настройке объекта групповой политики для FSLogix см. в разделе "Использование файлов шаблонов групповой политики FSLogix".

  

• URI учетной записи хранения контейнеров Office = \\primarystgodfc\odfc

  • Путь к разделу реестра = HKEY_LOCAL_MACHINE > SOFTWARE > Policy > FSLogix > ODFC

  • Значение CCDLocations =type=smb,connectionString=\\primarystgodfc\odfc;type=smb,connectionString=\\secondarystgodfc\odfc

    

Конфигурация дополнительного региона

Следующие параметры применяются в дополнительном регионе:

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

• URI учетной записи контейнера хранения профиля = \\secondarystgprofiles\profiles

  • Путь к разделу реестра = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles

  • Значение CCDLocations =type=smb,connectionString=\\secondarystgprofiles\profiles;type=smb,connectionString=\\primarystgprofiles\profiles

• URI учетной записи хранения контейнеров Office = \\secondarystgodfc\odfc

  • Путь к разделу реестра = HKEY_LOCAL_MACHINE > SOFTWARE > Policy > FSLogix > ODFC

  • Значение CCDLocations =type=smb,connectionString=\\secondarystgodfc\odfc;type=smb,connectionString=\\primarystgodfc\odfc

Репликация облачного кэша

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

Скачайте файл Visio для этой архитектуры.

Поток данных

1. Пользователь Виртуального рабочего стола Azure запускает клиент Виртуального рабочего стола Azure и открывает опубликованный рабочий стол или приложение RemoteApp, назначенное пулу узлов основного региона.

2. FSLogix извлекает контейнеры профиля и Office пользователя, а затем подключает виртуальный жесткий диск (VHD или VHDX) из учетной записи хранения, расположенной в основном регионе.

3. Облачный кэш одновременно инициализирует репликацию между файлами в основном регионе и файлами в дополнительном регионе. В ходе этого процесса облачный кэш в основном регионе устанавливает монопольную блокировку на чтение и запись этих файлов.

4. Тот же пользователь Azure Virtual Desktop хочет запустить другое опубликованное приложение, назначенное пулу узлов вторичного региона.

5. Компонент FSLogix на узле сеанса виртуального рабочего стола Azure в дополнительном регионе пытается подключить файлы VHD или VHDX профиля пользователя из локальной учетной записи хранения. Монтирование завершается ошибкой, так как компонент облачного кэша на узле сеанса виртуального рабочего стола Azure в основном регионе блокирует эти файлы.

6. В конфигурации FSLogix и облачного кэша по умолчанию пользователь не может войти, FSLogix записывает ошибку ERROR_LOCK_VIOLATION 33 (0x21) в журналах диагностики.

   

Идентичность

Удостоверение пользователя имеет решающее значение для виртуального рабочего стола Azure. Чтобы получить доступ к полным виртуальным рабочим столам и удаленным приложениям с узлов сеансов, пользователи должны иметь возможность пройти проверку подлинности. Microsoft Entra ID предоставляет эту централизованную облачную службу идентификации. Виртуальный рабочий стол Azure использует идентификатор Microsoft Entra для проверки подлинности пользователей. Узлы сеансов могут присоединяться к одному клиенту Microsoft Entra или домену Active Directory с помощью AD DS или доменных служб. Эта гибкость обеспечивает широкий спектр параметров конфигурации.

Устойчивость идентификатора Microsoft Entra

Идентификатор Microsoft Entra — это глобальная многорегионная и устойчивая служба с высоким уровнем доступности. Никаких других действий в этом контексте в рамках плана BCDR виртуального рабочего стола Azure не требуется.

Требования к высокой доступности AD DS

Чтобы обеспечить устойчивость и высокую доступность AD DS, даже если происходит авария на уровне региона, разверните по крайней мере два контроллера домена в основном регионе Azure. По возможности поместите эти контроллеры домена в разные зоны доступности и обеспечьте правильную репликацию между инфраструктурой в дополнительном регионе и, в конце концов, на локальной площадке. Создайте хотя бы один контроллер домена в дополнительном регионе с глобальным каталогом и ролями DNS. Дополнительные сведения см. в статье "Развертывание AD DS в виртуальной сети Azure".

Конфигурация устойчивости Microsoft Entra Connect

Если вы используете идентификатор Microsoft Entra вместе с AD DS, а затем Microsoft Entra Connect для синхронизации данных удостоверений пользователей между AD DS и Идентификатором Microsoft Entra, рассмотрите устойчивость и восстановление этой службы для защиты от постоянной аварии.

Установите второй экземпляр службы во вторичном регионе и настройте промежуточный режим для обеспечения высокой доступности и восстановления после сбоев.

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

Рекомендации по доменным службам

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

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

Отказоустойчивость и восстановление после сбоя

Рассмотрим следующие сценарии пула хостов.

Сценарий личного пула хостов

Отказоустойчивость и восстановление после сбоя для личного пула узлов работают по отличающимся принципам, так как вы не используете облачный кэш или внешнее хранилище для контейнеров профилей или Office. FSLogix по-прежнему можно использовать для хранения данных в контейнере на узле сеанса. В регионе аварийного восстановления (DR) нет вторичного пула узлов, поэтому вам не нужно создавать дополнительные рабочие области или ресурсы Azure Virtual Desktop для репликации или синхронизации. С помощью Site Recovery можно реплицировать виртуальные машины узла сеансов.

Site Recovery можно использовать в нескольких различных сценариях. Для виртуального рабочего стола Azure используйте архитектуру DR Azure to Azure в Site Recovery.

Операционные соображения Site Recovery

Администраторы должны вручную инициировать переключение на резервный сайт Site Recovery с помощью портала Azure, API или PowerShell. Вы можете выполнять скрипты и автоматизировать всю конфигурацию и операции Site Recovery с помощью PowerShell. Соглашение об уровне обслуживания Site Recovery объявляет время восстановления (RTO), и Site Recovery обычно выполняет переключение на резервный узел виртуальных машин в течение нескольких минут. Вы можете совместно использовать Site Recovery и резервное копирование. Дополнительные сведения см. в статье "Поддержка Site Recovery с помощью резервного копирования". Необходимо настроить Site Recovery на уровне виртуальной машины, так как в виртуальном рабочем столе Azure нет прямой интеграции. Кроме того, необходимо инициировать отказоустойчивость и возврат на уровне каждой виртуальной машины.

Site Recovery не поддерживает расширения виртуальной машины во время репликации. Если вы используете пользовательские расширения для виртуальных машин узла сеансов Виртуального рабочего стола Azure, необходимо настроить расширения после отказа или восстановления. Встроенные расширения joindomain виртуального рабочего стола Azure и Microsoft.PowerShell.DSC применяются только при создании виртуальной машины узла сеанса. Вы можете безопасно игнорировать их после первой отработки отказа. Просмотрите матрицу поддержки аварийного восстановления виртуальной машины Azure между регионами Azure. Проверьте требования, ограничения и матрицу совместимости для сценария аварийного восстановления Azure Site Recovery в Azure, особенно поддерживаемые версии операционной системы.

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

Сценарий объединенного пула узлов

Используйте модель аварийного восстановления active-active, если требуется восстановление службы без вмешательства администратора во время сбоя. Используйте процедуры отработки отказа только для активно-пассивной архитектуры. В активно-пассивной модели вторичный DR регион остается бездействующим и сохраняет минимальные готовые ресурсы. Сохраните вторичную конфигурацию в соответствии с основной конфигурацией. Во время переключения на резервный сервер переназначьте всех пользователей группам приложений для рабочего стола и удаленных приложений во вторичном пуле узлов аварийного восстановления.

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

Условия и предположения конфигурации

Пулы узлов в основном регионе и вторичном регионе для аварийного восстановления используют однообразные конфигурации, включая облачное кеширование. В обоих пулах узлов DAG1, APPG2 и APPG3 доступны пользователям. В основном пуле узлов Active Directory группы GRP1, GRP2 и GRP3 назначают пользователям DAG1, APPG2 и APPG3. Членство в группах может перекрываться, но эта схема остается приемлемой, так как в этом сценарии используется активно-пассивная модель с полным переключением.

Процесс переключения при запланированном или незапланированном событии резервного копирования и восстановления описан ниже.

1. В основном пуле узлов удалите назначения пользователей группами GRP1, GRP2 и GRP3 для групп приложений DAG1, APPG2 и APPG3.

2. Подключенные пользователи принудительно отключены от основного пула узлов.

3. В дополнительном пуле узлов, где настроены те же группы приложений, необходимо предоставить пользователям доступ к DAG1, APPG2 и APPG3 с помощью групп GRP1, GRP2 и GRP3.

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

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

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

1. Создайте несколько тестовых учетных записей пользователей в Active Directory.

2. Создайте новую группу Active Directory с именем GRP-TEST и назначьте пользователей.

3. Назначьте доступ к DAG1, APPG2 и APPG3 с помощью группы GRP-TEST.

4. Указание пользователям в группе GRP-TEST тестировать приложения.

5. Проверьте процедуру отработки отказа с помощью группы GRP-TEST. Удалите доступ к основному пулу узлов и предоставьте доступ ко вторичному пулу аварийного восстановления.

Следуйте приведенным ниже рекомендациям.

• Автоматизируйте процесс отработки отказа с помощью PowerShell, Azure CLI или другого доступного API или средства.

• Периодически тестируйте полный процесс переключения на резерв и возврата к исходному состоянию.

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

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

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

Для контейнеров Office, если содержимое – это только кэшированные данные, которые можно перестроить из онлайн-хранилища данных, такие как Microsoft 365, вам не нужно создавать резервные копии данных. Если вам нужно создать резервную копию данных контейнера Office, можно использовать менее дорогое хранилище или выбрать другую частоту резервного копирования и период хранения. Для типа личного пула узлов выполните резервное копирование на уровне виртуальной машины узла сеанса. Этот метод применяется только при локальном хранении данных. Если вы используете OneDrive и перенаправление известных папок, возможно, больше не потребуется хранить данные в контейнере.

Рекомендации по хранению и регионам

Если у вас нет других требований, резервное копирование хранилища основного региона соответствует типичным потребностям резервного копирования. В большинстве случаев резервное копирование среды аварийного восстановления не требуется. Для общей папки Файлов Azure используйте Backup. Для типа устойчивости хранилища используйте ZRS, если не требуется хранилище резервных копий вне сайта или региона. Если вам нужны эти резервные копии, используйте GRS.

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

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

• Бен Мартин Баур | Технический архитектор — Центр инноваций Майкрософт

Другие участники:

• Джейсон Мартинес | Технический писатель
• Игорь Паляй | Главный инженер FastTrack для Azure (FTA)
• Нельсон Дель Виллар | Архитектор облачных решений — инфраструктура Azure Core

Дальнейшие действия

• План аварийного восстановления виртуального рабочего стола Azure
• BCDR для виртуального рабочего стола Azure
• Обзор облачного кэша
• Примеры конфигурации FSLogix
• Проектирование надежных приложений Azure

Связанные ресурсы

• Доступ к файлам Azure из локальной сети и их защита с помощью AD DS
• Корпоративные файловые ресурсы с ОР