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

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

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

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

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

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

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

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

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

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

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

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

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

Вне сферы действия

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

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

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

Предварительные требования

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

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

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

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

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

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

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

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

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

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

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

Active-Active и Active-Passive

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

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

• «Active-Active»

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

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

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

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

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

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

    

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

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

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

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

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

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

Общие

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

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

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

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

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

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

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

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

Вычисление

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

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

  

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

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

  az sig image-version create

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

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

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

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

Хранилище

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

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

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

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

FSLogix

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

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

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

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

  

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

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

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

  Совет

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

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

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

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

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

  Примечание.

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

  Снимок экрана, показывающий ключи реестра Cloud Cache.

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

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

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

    

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

• URI учетной записи хранения контейнера профилей = \westeustg1\profiles
  • Путь к разделу реестра = HKEY_LOCAL_MACHINE > SOFTWARE > FSLogix > Profiles
  • Значение 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. Пользователь Виртуального рабочего стола Azure запускает клиент виртуального рабочего стола, а затем открывает опубликованное приложение рабочего стола или удаленного приложения, назначенное пулу узлов основного региона.

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

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

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

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

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

   

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

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

• Идентификатор Microsoft Entra

  • Это глобальная мультирегионная и устойчивая служба с высоким уровнем доступности. В рамках плана 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 можно использовать в некоторых сценариях в качестве альтернативы службам Active Directory Domain Services.
  • Она предлагает соглашение об уровне обслуживания с высоким уровнем доступности.
  • Если восстановление после гео-катастроф входит в рамки вашего сценария, необходимо развернуть другую реплику в дополнительном регионе Azure с помощью набора реплик. Эту функцию можно также использовать для повышения высокого уровня доступности в основном регионе.

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

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

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

Область проектирования	Описание
А	Одним из наиболее важных зависимостей для виртуального рабочего стола Azure является доступность удостоверения пользователя. Чтобы получить доступ к полным виртуальным рабочим столам и удаленным приложениям с узлов сеансов, ваши пользователи должны иметь возможность авторизоваться. Просмотрите параметр «Идентификация».
Б	Если пользователям виртуального рабочего стола Azure требуется доступ к локальным ресурсам, важно учитывать высокий уровень доступности в сетевой инфраструктуре, необходимой для подключения к ресурсам. Оцените и оцените устойчивость инфраструктуры проверки подлинности и рассмотрите аспекты BCDR для зависимых приложений и других ресурсов. Эти рекомендации помогут обеспечить доступность в дополнительном расположении аварийного восстановления.
С	В зависимости от размера структуры развертывания и организации убедитесь, что все подписки имеют достаточную квоту для запуска рабочих нагрузок Виртуального рабочего стола Azure в разных регионах, и у вас есть правильные роли управления доступом на основе ролей Azure (Azure RBAC).
Д	Для развертывания обоих пулов узлов в первичном и вторичном регионах аварийного восстановления необходимо распределить флот виртуальных машин для хостинга сеансов по нескольким зонам доступности. Если зоны доступности недоступны в локальном регионе, можно использовать группу доступности, чтобы сделать решение более устойчивым, чем при развертывании по умолчанию.
Е	Золотой образ, который вы используете для развертывания гостевого пула в дополнительном регионе аварийного восстановления, должен быть таким же, как и в основном регионе. Следует хранить образы в Галерее образов Azure и настраивать несколько реплик образов как в основном, так и во вторичных расположениях.
Ф	Вы можете использовать Azure Site Recovery или дополнительный пул узлов (горячий режим ожидания) для поддержания среды резервного копирования.
Г	Вы можете создать новый пул узлов в резервном регионе и держать все ресурсы выключенными. Для этого метода настройте новые группы приложений в резервном регионе и распределите пользователей по группам. Затем можно использовать план восстановления в Site Recovery для активации пулов узлов и создания организованного процесса.

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

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

Область проектирования	Описание
А	Одним из наиболее важных зависимостей для виртуального рабочего стола Azure является доступность удостоверения пользователя. Чтобы получить доступ к полным виртуальным рабочим столам Azure и удаленным приложениям с узлов сеансов, пользователям потребуется пройти проверку подлинности. Просмотрите параметр «Идентификация».
Б	Если пользователям виртуального рабочего стола Azure требуется доступ к локальным ресурсам, важно учитывать высокий уровень доступности в сетевой инфраструктуре, необходимой для подключения к ресурсам. Оцените и оцените устойчивость инфраструктуры проверки подлинности и рассмотрите аспекты BCDR для зависимых приложений и других ресурсов. Эти рекомендации помогут обеспечить доступность в дополнительном расположении аварийного восстановления.
С	В зависимости от размера развертывания и структуры организации убедитесь, что все подписки имеют достаточную квоту для запуска рабочих нагрузок Виртуального рабочего стола Azure в разных регионах и у вас назначены корректные роли RBAC Azure.
Д	Через зоны доступности виртуальные машины в пуле узлов распределяются по разным центрам обработки данных. Виртуальные машины по-прежнему находятся в одном регионе, и они имеют более высокую устойчивость и более высокий уровень обслуживания на уровне 99,99 %. Планирование емкости должно включать достаточно дополнительных вычислительных ресурсов, чтобы обеспечить работу виртуального рабочего стола Azure, даже если одна зона доступности потеряна.
Е	Используйте FSLogix Cloud Cache для создания устойчивости профилей для пользователей. FSLogix Cloud Cache может повлиять на опыт входа в систему и выхода из неё, когда вы используете хранилище с низкой производительностью. Обычно средам, использующим облачный кэш, немного медленнее вход и время выхода, относительно использования традиционных VHDLocations с использованием одного и того же хранилища. Ознакомьтесь с документацией по FSLogix Cloud Cache, чтобы ознакомиться с рекомендациями по локальному хранилищу кэша.
Ф	Azure NetApp Files для предприятий предлагает наибольшее значение для клиентов. Службы Azure упрощают управление виртуальным рабочим столом Azure и являются предпочтительными решениями для хранения для этой рабочей нагрузки.
Г	Параметры хранилища для контейнеров профилей FSLogix в Виртуальном рабочем столе Azure сравнивают различные доступные решения управляемого хранилища.
Х	Отдельные диски профилей пользователей и контейнеров Office. FSLogix предлагает возможность размещения дисков в разных местах хранения.
Я	Для дисков AppAttach и при необходимости используйте встроенные механизмы репликации Azure Storage для BCDR (обеспечения непрерывности бизнеса и восстановления после аварий) для менее критичных сред. Используйте зоно-избыточное (ZRS) или географически избыточное (GRS) хранилище для файлов Azure.
J	Чтобы предотвратить потерю или логическое повреждение данных пользователей, используйте Azure Backup для защиты критически важных рабочих нагрузок.
К	Золотой образ, который вы используете для развертывания гостевого пула в дополнительном регионе аварийного восстановления, должен быть таким же, как и в основном регионе. Следует хранить образы в Галерее образов Azure и настраивать несколько реплик образов как в основном, так и во вторичных расположениях.

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

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

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

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

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

• Отработка отказа Site Recovery не является автоматической — администратор должен активировать её с помощью портала Azure или PowerShell/API.
• Вы можете выполнять скрипты и автоматизировать всю конфигурацию и операции Site Recovery с помощью PowerShell.
• Site Recovery имеет заявленный RTO в рамках соглашения об уровне обслуживания (Service-Level Agreement - SLA). В большинстве случаев Site Recovery может выполнять переключение на резервную копию виртуальных машин в течение нескольких минут.
• Вы можете использовать Site Recovery с Azure Backup. Дополнительные сведения см. в статье "Поддержка использования Site Recovery с Azure Backup".
• Необходимо включить Site Recovery на уровне виртуальной машины, так как на портале виртуального рабочего стола нет прямой интеграции. Кроме того, необходимо инициировать переключение на резерв и восстановление исходного состояния на уровне одной виртуальной машины.
• Site Recovery предоставляет возможность тестирования отказоустойчивости в отдельной подсети для стандартных виртуальных машин Azure. Не используйте эту функцию для виртуальных машин виртуального рабочего стола, так как в одно и то же время вы будете иметь два одинаковых узла сеанса виртуального рабочего стола, вызывающих плоскость управления службой.
• Site Recovery не поддерживает расширения виртуальной машины во время репликации. При включении пользовательских расширений для виртуальных машин узла сеансов виртуального рабочего стола необходимо повторно включить расширения после переключения на резервный узел или восстановления исходного состояния. Встроенные расширения Виртуального Рабочего Стола joindomain и Microsoft.PowerShell.DSC используются только при создании виртуальной машины хоста сеанса. Безопасно отключить их после первой аварийной переключения.
• Обязательно ознакомьтесь с матрицей поддержки для аварийного восстановления виртуальных машин 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. Просмотрите и настройте емкость хост-пула во вторичном регионе. Здесь может потребоваться использовать план автомасштабирования для автоматического включения питания на узлах сеансов. Вы также можете вручную запустить необходимые ресурсы.

Шаги и поток Failback схожи, и вы можете выполнить весь процесс несколько раз. Облачный кэш и настройка учетных записей хранения гарантирует, что данные профиля и контейнера 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 Files используйте Azure Backup.

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

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

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

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

Соавторы

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

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

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

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

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

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

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

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

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