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

Виртуальный рабочий стол Azure — это комплексная служба виртуализации рабочих столов и приложений, запущенная в Microsoft Azure. Виртуальный рабочий стол помогает обеспечить безопасный интерфейс удаленного рабочего стола, который помогает организациям повысить устойчивость бизнеса. Она обеспечивает упрощенное управление, Windows 10 и 11 Корпоративная с несколькими сеансами и оптимизацию для Приложения Microsoft 365 для предприятий. С помощью виртуального рабочего стола вы можете развертывать и масштабировать рабочие столы и приложения Windows в Azure в минутах, предоставляя интегрированные функции безопасности и соответствия требованиям, чтобы обеспечить безопасность приложений и данных.

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

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

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

Целями этого руководства являются следующие задачи.

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

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

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

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

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

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

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

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

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

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

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

• Рекомендации по BCDR для виртуального рабочего стола
• Аварийное восстановление виртуального рабочего стола

Необходимые компоненты

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

• Традиционная топология сети Azure
• Виртуальная глобальная сеть топология сети (управляемая корпорацией Майкрософт)

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

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

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

Непрерывность бизнес-процессов и аварийное восстановление плоскости управления

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

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

Active-Active и Active-Passive

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

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

• Активный — активный

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

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

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

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

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

  • Пользователи назначаются разным группам приложений, таким как группа классических приложений (DAG) и группа приложений RemoteApp (RAG) в первичных и вторичных пулах узлов. В этом случае они видят повторяющиеся записи в веб-канале клиента Виртуального рабочего стола. Чтобы избежать путаницы, используйте отдельные рабочие области Виртуального рабочего стола с четкими именами и метками, которые отражают назначение каждого ресурса. Сообщите пользователям об использовании этих ресурсов.

    

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

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

• Активный-пассивный
  • Как и active-active, для каждого пула узлов в основном регионе развертывается второй пул узлов в дополнительном регионе.
  • Объем вычислительных ресурсов, активных в дополнительном регионе, уменьшается по сравнению с основным регионом в зависимости от доступного бюджета. Вы можете использовать автоматическое масштабирование для обеспечения большего объема вычислительных ресурсов, но требуется больше времени, а емкость Azure не гарантируется.
  • Эта конфигурация обеспечивает более высокий уровень RTO по сравнению с активным и активным подходом, но это менее дорого.
  • Чтобы выполнить процедуру отработки отказа, вам потребуется вмешательство администратора, если произошел сбой Azure. Вторичный пул узлов обычно не предоставляет пользователю доступ к ресурсам виртуального рабочего стола.
  • Каждый пул узлов имеет собственные учетные записи хранения для профилей постоянных пользователей.
  • Пользователи, использующие службы Виртуального рабочего стола с оптимальной задержкой и производительностью, влияют только в случае сбоя Azure. Этот сценарий следует проверить с помощью средства оценки возможностей виртуального рабочего стола Azure. Производительность должна быть приемлемой, даже если она ухудшается, для вторичной среды аварийного восстановления.
  • Пользователям назначается только один набор групп приложений, таких как классические и удаленные приложения. Во время обычных операций эти приложения находятся в основном пуле узлов. Во время сбоя и после отработки отказа пользователи назначаются группам приложений в дополнительном пуле узлов. Повторяющиеся записи не отображаются в клиентском канале виртуального рабочего стола пользователя, они могут использовать ту же рабочую область, и все это прозрачно для них.
  • Если требуется хранилище для управления профилями FSLogix и контейнерами Office, используйте облачный кэш для обеспечения почти нуля RPO.
    • Чтобы избежать конфликтов профилей, не разрешайте пользователям одновременно получать доступ к обоим пулам узлов. Так как этот сценарий является активным-пассивным, администраторы могут применить это поведение на уровне группы приложений. Только после процедуры отработки отказа пользователь может получить доступ к каждой группе приложений в дополнительном пуле узлов. Доступ отменяется в группе приложений основного пула узлов и переназначен группе приложений в дополнительном пуле узлов.
    • Выполните отработку отказа для всех групп приложений, в противном случае пользователи, использующие разные группы приложений в разных пулах узлов, могут вызвать конфликты профилей, если они не управляются.
  • Можно разрешить определенному подмножество пользователей выборочно выполнить отработку отказа в дополнительный пул узлов и обеспечить ограниченное активное поведение и возможность отработки отказа. Кроме того, можно выполнить отработку отказа определенных групп приложений, но вы должны обучить пользователей не использовать ресурсы из разных пулов узлов одновременно.

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

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

Рекомендации и рекомендации

Общие

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

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

Просмотрите параметры непрерывности бизнес-процессов и аварийного восстановления для FSLogix.

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

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

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

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

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

Службы вычислений

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

• Золотой образ, используемый для развертывания пула узлов в дополнительном регионе аварийного восстановления, должен совпадать с основным. Образы следует хранить в коллекции вычислений Azure и настраивать несколько реплик изображений как в основном, так и в дополнительных расположениях. Каждая реплика образа может поддерживать параллельное развертывание максимального количества виртуальных машин, и вам может потребоваться несколько виртуальных машин на основе требуемого размера пакета развертывания. Дополнительные сведения см. в разделе "Магазин и общий доступ к изображениям" в коллекции вычислений Azure.

  

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

  Создание определения образа и версии образа

  az sig image-version create

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

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

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

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

Хранилище

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

• Вы можете использовать Файлы Azure общий ресурс и Azure NetApp Files в качестве альтернативных вариантов хранения. Сведения о сравнении параметров см. в параметрах хранилища контейнеров FSLogix.
• Файлы Azure общий ресурс может обеспечить устойчивость зоны с помощью параметра устойчивости, избыточного между зонами (ZRS), если он доступен в регионе.
• Вы не можете использовать функцию геоизбыточного хранилища в следующих ситуациях:
  • Вам требуется регион, у который нет пары. Пары регионов для геоизбыточного хранилища исправлены и не могут быть изменены.
  • Вы используете уровень "Премиум".
• RPO и RTO выше по сравнению с механизмом облачного кэша FSLogix.
• Это не просто проверить отработку отказа и восстановление размещения в рабочей среде.
• Azure NetApp Files требует дополнительных рекомендаций.
  • Избыточность зоны пока недоступна. Если требования к устойчивости важнее производительности, используйте Файлы Azure общий доступ.
  • Azure NetApp Files может быть зональным, то есть клиенты могут решить, в какой (отдельной) зоне доступности Azure следует выделить.
  • Репликация между зонами можно установить на уровне тома для обеспечения устойчивости зоны, но репликация выполняется асинхронной и требует отработки отказа вручную. Для этого процесса требуется цель точки восстановления (RPO) и цель времени восстановления (RTO), которая больше нуля. Прежде чем использовать эту функцию, ознакомьтесь с требованиями и рекомендациями по репликации между зонами.
  • Azure NetApp Files можно использовать с vpn-шлюзами, избыточными между зонами, и шлюзами ExpressRoute, если используется стандартная сетевая функция, которую можно использовать для обеспечения устойчивости сети. Дополнительные сведения см. в статье "Поддерживаемые топологии сети".
  • Azure Виртуальная глобальная сеть поддерживается при использовании со стандартными сетями Azure NetApp Files. Дополнительные сведения см. в статье "Поддерживаемые топологии сети".
• Azure NetApp Files имеет механизм репликации между регионами. Ниже приведены рекомендации.
  • Он недоступен во всех регионах.
  • Репликация между регионами пар томов Azure NetApp Files может отличаться от пар служба хранилища Azure регионов.
  • Его нельзя использовать одновременно с репликацией между зонами
  • Отработка отказа не является прозрачной, и для восстановления размещения требуется перенастройка хранилища.
• Ограничения
  • Существуют ограничения на размер, операции ввода-вывода в секунду (ОПЕРАЦИЙ ввода-вывода), пропускная способность MBps как для Файлы Azure общего ресурса, так и для учетных записей хранения Azure NetApp Files и томов. При необходимости можно использовать несколько пулов узлов в виртуальном рабочем столе с помощью параметров для каждой группы в FSLogix. Однако для этой конфигурации требуется больше планирования и настройки.

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

• Одна учетная запись хранения с поддержкой геоизбыточного хранилища в основном регионе
  • Дополнительный регион исправлен. Этот параметр не подходит для локального доступа при отработке отказа учетной записи хранения.
• Две отдельные учетные записи хранения, один в основном регионе и один в дополнительном регионе (рекомендуется)
  • Используйте хранилище, избыточное по зонам, по крайней мере для основного региона.
  • Каждый пул узлов в каждом регионе имеет локальный доступ к пакетам MSIX с низкой задержкой.
  • Скопируйте пакеты MSIX дважды в обоих расположениях и дважды зарегистрируйте пакеты в обоих пулах узлов. Назначьте пользователей группам приложений дважды.

FSLogix

Корпорация Майкрософт рекомендует использовать следующую конфигурацию и функции FSLogix:

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

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

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

  

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

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

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

  Совет

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

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

Основной регион = Северная Европа

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

  • Путь к разделу реестра = HKEY_LOCAL_MACHINE профили FSLogix > SOFTWARE > >
  • Значение CCDLocations = type=smb,connectionString=\northeustg1\profiles; type=smb,connectionString=\westeustg1\profiles

  Примечание.

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

  

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

  • Путь к разделу реестра = HKEY_LOCAL_MACHINE > ПОЛИТИКА > ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ >FSLogix > ODFC

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

    

Вторичный регион = Западная Европа

• URI учетной записи хранения профиля контейнера = \westeustg1\profile
  • Путь к разделу реестра = HKEY_LOCAL_MACHINE профили FSLogix > SOFTWARE > >
  • Значение CCDLocations = type=smb,connectionString=\westeustg1\profiles; type=smb,connectionString=\northeustg1\profiles
• URI учетной записи хранения контейнеров Office = \westeustg2\odcf
  • Путь к разделу реестра = HKEY_LOCAL_MACHINE > ПОЛИТИКА > ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ >FSLogix > ODFC
  • Значение CCDLocations = type=smb,connectionString=\westeustg2\odfc; type=smb,connectionString=\northeustg2\odfc

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

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

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

Поток данных

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

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

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

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

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

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

   

Идентификация

Одним из наиболее важных зависимостей для виртуального рабочего стола является доступность удостоверения пользователя. Чтобы получить доступ к полным виртуальным рабочим столам и удаленным приложениям с узлов сеансов, пользователи должны иметь возможность пройти проверку подлинности. Идентификатор Microsoft Entra — это централизованная облачная служба удостоверений Майкрософт, которая обеспечивает эту возможность. Идентификатор Microsoft Entra всегда используется для проверки подлинности пользователей для виртуального рабочего стола. Узлы сеансов можно присоединить к одному клиенту Microsoft Entra или домену Active Directory с помощью служб домен Active Directory (AD DS) или доменных служб Microsoft Entra, предоставляя вам варианты гибкой конфигурации.

• Microsoft Entra ID

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

• Доменные службы Active Directory

  • Чтобы службы домен Active Directory были устойчивыми и высокодоступными, даже если в регионе произошла катастрофа, необходимо развернуть по крайней мере два контроллера домена (DCs) в основном регионе Azure. Эти контроллеры домена должны находиться в разных зонах доступности, если это возможно, и необходимо обеспечить правильную репликацию с инфраструктурой в дополнительном регионе и в конечном итоге локально. Необходимо создать хотя бы один контроллер домена в дополнительном регионе с глобальным каталогом и ролями DNS. Дополнительные сведения см. в статье "Развертывание служб домен Active Directory (AD DS) в виртуальной сети Azure.

• Microsoft Entra Connect

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

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

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

    

• Доменные службы Microsoft Entra

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

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

Личный пул узлов

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

Пул узлов в пуле

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

Отработка отказа и восстановление размещения

Сценарий личного пула узлов

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

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

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

• Отработка отказа Site Recovery не является автоматической— администратор должен активировать его с помощью портал Azure или Powershell/API.
• Вы можете выполнять скрипты и автоматизировать всю конфигурацию и операции Site Recovery с помощью PowerShell.
• Site Recovery имеет объявленный RTO в рамках соглашения об уровне обслуживания (SLA). Большую часть времени Site Recovery может выполнять отработку отказа виртуальных машин в течение нескольких минут.
• Вы можете использовать Site Recovery с Azure Backup. Дополнительные сведения см. в статье "Поддержка использования Site Recovery с Azure Backup".
• Необходимо включить Site Recovery на уровне виртуальной машины, так как на портале виртуального рабочего стола нет прямой интеграции. Кроме того, необходимо активировать отработку отказа и восстановление размещения на уровне одной виртуальной машины.
• Site Recovery предоставляет тестовую возможность отработки отказа в отдельной подсети для общих виртуальных машин Azure. Не используйте эту функцию для виртуальных машин виртуального рабочего стола, так как в одно и то же время вы будете иметь два одинаковых узла сеанса виртуального рабочего стола, вызывающих плоскость управления службой.
• Site Recovery не поддерживает расширения виртуальной машины во время репликации. Если вы включите какие-либо пользовательские расширения для виртуальных машин узла сеансов виртуального рабочего стола, необходимо повторно создать расширения после отработки отказа или восстановления размещения. Встроенные расширения виртуального рабочего стола, присоединенные к домену присоединения и Microsoft.PowerShell.DSC , используются только при создании виртуальной машины узла сеанса. Это безопасно потерять их после первой отработки отказа.
• Обязательно просмотрите матрицу поддержки аварийного восстановления виртуальных машин Azure между регионами Azure и проверьте требования, ограничения и матрицу совместимости для сценария аварийного восстановления Azure в Azure в Azure, особенно поддерживаемые версии ОС.
• При отработке отказа виртуальной машины из одного региона в другой виртуальная машина запускается в целевом регионе аварийного восстановления в незащищенном состоянии. Восстановление размещения возможно, но пользователь должен повторно защитить виртуальные машины в дополнительном регионе, а затем включить репликацию обратно в основной регион.
• Выполните периодическое тестирование процедур отработки отказа и восстановления размещения. Затем задокументируйте точный список шагов и действий восстановления на основе конкретной среды виртуального рабочего стола.

Сценарий пула узлов в пуле

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

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

Можно использовать модель "активный— активный" и частичной отработки отказа. Если пул узлов используется только для предоставления групп рабочих столов и приложений, вы можете секционировать пользователей в нескольких группах 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 из хранилища дополнительного региона.

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

• Создайте несколько новых учетных записей пользователей в Active Directory для рабочей среды.
• Создайте новую группу Active Directory с именем GRP-TEST и назначьте пользователей.
• Назначьте доступ к DAG1, APPG2 и APPG3 с помощью группы GRP-TEST.
• Предоставьте пользователям инструкции в группе GRP-TEST для тестирования приложений.
• Проверьте процедуру отработки отказа с помощью группы GRP-TEST, чтобы удалить доступ из основного пула узлов и предоставить доступ к вторичному пулу аварийного восстановления.

Важные рекомендации:

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

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

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

• Для контейнера ODFC, если содержимое представляет только кэшированные данные, которые можно перестроить из локального хранилища данных, например Microsoft 365, не обязательно создавать резервные копии данных.

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

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

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

  Примечание.

  Резервное копирование OneDrive не рассматривается в этой статье и сценарии.

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

• Для общего доступа Файлы Azure используйте Azure Backup.

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

• Azure NetApp Files предоставляет собственное встроенное решение для резервного копирования.

  • Убедитесь, что вы проверяете доступность компонентов региона вместе с требованиями и ограничениями.

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

• Бен Мартин Баур | Архитектор облачных решений
• Игорь Паляй | Главный инженер FastTrack для Azure (FTA)

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

• Нельсон Дель Виллар | Архитектор облачных решений, инфраструктура Azure Core
• Джейсон Мартинес | Технический писатель

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

• План аварийного восстановления виртуального рабочего стола
• BCDR для виртуального рабочего стола — Cloud Adoption Framework
• Облачный кэш для создания устойчивости и доступности

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

• Проектирование надежных приложений Azure
• Доступ к файлам Azure, доступ к локальным и защищенным AD DS
• Виртуальный рабочий стол для предприятия
• Корпоративные общие папки с функцией аварийного восстановления
• Примеры конфигурации FSLogix