Концепция аварийного восстановления виртуального рабочего стола Azure
Виртуальный рабочий стол Azure значительно вырос в качестве решения для удаленной и гибридной работы в последние годы. Так как многие пользователи теперь работают удаленно, организации требуют решений с высокой скоростью развертывания и снижением затрат. Пользователи также должны иметь удаленную рабочую среду с гарантированной доступностью и устойчивостью, которая позволяет им обращаться к своим виртуальным машинам даже во время аварийных ситуаций. В этом документе описываются планы аварийного восстановления, которые рекомендуется поддерживать в организации.
Чтобы предотвратить сбои системы или простои, все системы и компоненты в развертывании Виртуального рабочего стола Azure должны быть отказоустойчивыми. Отказоустойчивость — это при наличии повторяющейся конфигурации или системы в другом регионе Azure, который берет на себя основную конфигурацию во время сбоя. Эта вторичная конфигурация или система снижает влияние локализованного сбоя. Существует множество способов настройки отказоустойчивости, но в этой статье рассматриваются методы, доступные в настоящее время в Azure.
Инфраструктура виртуальных рабочих столов
Чтобы выяснить, какие области нужно сделать отказоустойчивые, мы сначала должны знать, кто отвечает за обслуживание каждой области. Вы можете разделить ответственность за службу Виртуального рабочего стола Azure на две области: управляемую корпорацией Майкрософт и управляемую клиентом. Метаданные, такие как пулы узлов, группы приложений и рабочие области, управляются корпорацией Майкрософт. Метаданные всегда доступны и не требуют дополнительной настройки клиентом для репликации данных или конфигураций пула узлов. Мы разработали инфраструктуру шлюза, которая подключает людей к узлам сеансов, чтобы она была глобальной и устойчивой службой, управляемой корпорацией Майкрософт. Между тем управляемые клиентом области включают виртуальные машины, используемые в Виртуальном рабочем столе Azure, а также параметры и конфигурации, уникальные для развертывания клиента. В следующей таблице представлено более четкое представление о том, какие области управляются какой стороной.
| Управление корпорацией Майкрософт | Управляется клиентом |
|---|---|
| Подсистема балансировки нагрузки | Сеть |
| Посредник сеансов | Узлы сеансов |
| Шлюз | Хранилище |
| Диагностика | Данные профиля пользователя |
| Платформа облачной идентификации | Идентификация |
В этой статье мы сосредоточимся на компонентах, управляемых клиентом, так как это параметры, которые можно настроить самостоятельно.
Основы аварийного восстановления
В этом разделе мы обсудим действия и принципы проектирования, которые могут защитить данные и предотвратить огромные усилия по восстановлению данных после небольших сбоев или полных аварий. В случае небольших сбоев выполнение определенных небольших шагов может помочь предотвратить их превращение в более серьезные бедствия. Рассмотрим некоторые основные термины, которые помогут вам приступить к настройке плана аварийного восстановления.
При разработке плана аварийного восстановления следует учитывать следующие три аспекта:
- Высокая доступность: распределение инфраструктуры таким образом, чтобы более мелкие и локальные сбои не прерывали все развертывание. Проектирование с высоким уровнем доступности может свести к минимуму последствия сбоя и избежать необходимости полного аварийного восстановления.
- Непрерывность бизнес-процессов: как организация может работать во время простоя любого размера.
- Аварийное восстановление: процесс возврата к работе после полного сбоя.
В Azure есть множество встроенных бесплатных функций, которые могут обеспечить высокий уровень доступности на многих уровнях. Первая функция — это группы доступности, которые распределяют виртуальные машины между разными доменами сбоя и обновления в Azure. Далее находятся зоны доступности, которые физически изолированы и географически распределенные группы центров обработки данных, которые могут снизить последствия сбоя. Наконец, распределение узлов сеансов между несколькими регионами Azure обеспечивает еще больше географического распределения, что еще больше снижает влияние на сбой. Все три функции обеспечивают определенный уровень защиты в Виртуальном рабочем столе Azure, и их следует тщательно рассмотреть вместе с любыми затратами.
В основном стратегия аварийного восстановления, рекомендуемая для Виртуального рабочего стола Azure, заключается в развертывании ресурсов в нескольких зонах доступности в пределах региона. Если вам нужна дополнительная защита, можно также развернуть ресурсы в нескольких парных регионах Azure.
Развертывания "активный — пассивный" и "активный — активный"
Что-то еще следует помнить, это разница между планами "активный — пассивный" и "активный — активный". Планы "активный — пассивный" включают один активный регион с одним набором ресурсов и один отключенный до момента, пока он не понадобится (т. е. пассивный). Если активный регион находится в автономном режиме, организация может переключиться в пассивный регион, включив его и переместив всех пользователей.
Другой вариант — это развертывание типа "активный — активный", где одновременно используются оба набора инфраструктуры. Хотя сбои могут повлиять на некоторых пользователей, к их числу будут относиться только пользователи в отключившемся регионе. Пользователи в другом регионе, который по-прежнему находится в сети, не будут затронуты, и восстановление ограничено пользователями в затронутом регионе, повторно подключающимся к работающему активному региону. Развертывания "активный-активный" могут принимать множество форм, в том числе:
- Предоставление избыточной инфраструктуры в каждом регионе для размещения затронутых пользователей в случае выхода из строя одного из регионов. Потенциальный недостаток этого метода заключается в повышении затрат на обслуживание дополнительных ресурсов.
- У вас могут быть дополнительные узлы сеансов в обоих активных регионах, которые вы будете высвобождать, когда они оказываются не нужны, что позволяет сократить затраты.
- Подготавливайте новую инфраструктуру только во время аварийного восстановления и разрешайте затронутым пользователям подключаться к недавно подготовленным узлам сеансов. Этот метод требует регулярного тестирования с помощью инструментов «инфраструктура как код», чтобы вы могли как можно быстрее развернуть новую инфраструктуру во время аварии.
Рекомендуемые методы аварийного восстановления
Мы рекомендуем использовать следующие методы аварийного восстановления:
Настройте и разверните ресурсы Azure в нескольких зонах доступности.
Настройте и разверните ресурсы Azure в нескольких регионах в конфигурациях "активный — активный" или "активный — пассивный". Эти конфигурации обычно находятся в пулах общих узлов.
Для личных пулов узлов с выделенными виртуальными машинами реплицируйте виртуальные машины с помощью Azure Site Recovery в другой регион.
Настройте отдельный пул узлов аварийного восстановления в дополнительном регионе. Во время аварии можно переключить пользователей на дополнительный регион.
Мы рассмотрим более подробные сведения о двух основных методах, с помощью которых можно реализовать эти методы для общих и личных пулов узлов в следующих разделах.
Аварийное восстановление для пулов общих узлов
В этом разделе мы обсудим общие пулы узлов (или пулы) с помощью подхода "активный — пассивный". Подход "активный — пассивный" заключается в том, что существующие ресурсы делятся на основной и дополнительный регион. Как правило, ваша организация будет выполнять всю свою работу в основном (или активном) регионе, но во время аварии все, что необходимо для переключения на дополнительный (или пассивный) регион, — отключить ресурсы в основном регионе (если это можно сделать в зависимости от степени сбоя) и включить их в дополнительном регионе.
На следующей схеме показан пример развертывания с избыточной инфраструктурой в дополнительном регионе. "Избыточный" означает, что копия исходной инфраструктуры существует в этом другом регионе и является стандартной в развертываниях для обеспечения устойчивости для всех компонентов. Под одним идентификатором Microsoft Entra есть два региона: западная часть США и восточная часть США. В каждом регионе есть два узла сеанса с операционной системой с несколькими сеансами (ОС), сервер под управлением Microsoft Entra Подключение, контроллер домен Active Directory, общий ресурс Файлы Azure класса Premium для профилей FSLogix, учетная запись хранения и виртуальная сеть (виртуальная сеть). В основном регионе, западная часть США, включены все ресурсы. В дополнительном регионе восточная часть США узлы сеансов в пуле узлов либо отключены, либо в режиме очистки, а сервер Microsoft Entra Подключение находится в промежуточном режиме. Две виртуальные сети в обоих регионах связаны посредством пиринга.
В большинстве случаев, если компонент завершается сбоем или основной регион недоступен, единственное действие, необходимое клиенту, — включить узлы или удалить режим стока в дополнительном регионе для включения подключений конечных пользователей. В этом сценарии основное внимание уделяется сокращению времени простоя. Однако план аварийного восстановления на основе избыточности может стоить больше из-за необходимости поддерживать эти дополнительные компоненты в дополнительном регионе.
Возможные преимущества этого плана:
- Меньше времени, затрачиваемого на восстановление после аварий. Например, вы будете тратить меньше времени на подготовку, настройку, интеграцию и проверку вновь развернутых ресурсов.
- Нет необходимости использовать сложные процедуры.
- Легко протестировать отработку отказа за пределами аварий.
Возможные недостатки:
- Больше затрат из-за наличия дополнительной инфраструктуры для обслуживания, таких как учетные записи хранения, узлы и т. д.
- Вам потребуется потратить больше времени на настройку развертывания для реализации этого плана.
- Вам нужно поддерживать дополнительную инфраструктуру, которую вы настроили, даже если она не нужна.
Важные сведения о восстановлении общего пула узлов
При использовании этой стратегии аварийного восстановления важно учитывать следующее:
Наличие нескольких узлов сеансов в сети во многих регионах может повлиять на взаимодействие с пользователем. Управляемая сетевая подсистема балансировки нагрузки не учитывает географическое расположение, вместо этого обрабатывая все узлы в пуле узлов одинаково.
Во время аварии пользователи будут создавать новые профили в дополнительном регионе. В OneDrive (с использованием перенаправления известных папок) или SharePoint следует хранить критически важные данные для бизнеса или критически важных для бизнеса. Хранение данных здесь даст пользователям быстрый доступ к приложениям с незначительным нарушением взаимодействия с пользователем.
Убедитесь, что виртуальные машины настроены точно так же, как в пуле узлов. Кроме того, убедитесь, что все виртуальные машины в пуле узлов имеют одинаковый размер. Если виртуальные машины не совпадают, подсистема балансировки нагрузки управляемой сети равномерно распределяет пользовательские подключения по всем доступным виртуальным машинам. Меньшие виртуальные машины могут стать ограниченными ресурсами раньше, чем ожидалось, по сравнению с большими виртуальными машинами, что приводит к негативному пользовательскому опыту.
Доступность региона влияет на мониторинг данных или рабочей области. Если регион недоступен, служба может потерять все исторические данные мониторинга во время аварии. Рекомендуется использовать пользовательский экспорт или дамп исторических данных мониторинга.
Рекомендуется обновлять узлы сеансов по крайней мере один раз в месяц. Эта рекомендация применяется к узлам сеансов, которые вы отключали в течение длительного периода времени.
Тестируйте развертывание, запуская управляемую отработку отказа по крайней мере раз в шесть месяцев. Часть управляемой отработки отказа может означать, что ваше дополнительное расположение становится основным до следующей управляемой отработки отказа. Изменение дополнительного расположения на основное позволяет пользователям иметь почти идентичные профили во время реальной аварии.
В следующей таблице перечислены рекомендации по развертыванию для стратегий аварийного восстановления пула узлов:
| Технология | Рекомендации |
|---|---|
| Сеть | Создайте и разверните вторичную виртуальную сеть в другом регионе и настройте пиринг Azure с основной виртуальной сетью. |
| Узлы сеансов | Создайте и разверните общий пул узлов Виртуального рабочего стола Azure с ОС SKU с несколькими сеансами и включите виртуальные машины из других зон доступности и другого региона. |
| Хранилище | Создание учетных записей хранения в нескольких регионах с помощью учетных записей уровня "Премиум". |
| Данные профиля пользователя | Создайте расположения хранилища S МБ в нескольких регионах. |
| Идентификация | Контроллеры домена Active Directory из того же каталога. |
Аварийное восстановление для личных пулов узлов
Для личных пулов узлов стратегия аварийного восстановления должна включать репликацию ресурсов в дополнительный регион с помощью Azure Site Recovery Services Vault. Если основной регион исчез во время аварии, Azure Site Recovery может выполнить отработку отказа и включить ресурсы в дополнительном регионе.
Например, предположим, что у нас есть развертывание с основным регионом в западной части США и дополнительным регионом в восточной части США. Основной регион имеет личный пул узлов с двумя узлами сеансов. Каждый узел сеанса имеет собственный локальный диск, содержащий данные профиля пользователя и собственную виртуальную сеть, которая не связана ни с чем. В случае аварии можно использовать Azure Site Recovery для отработки отказа в дополнительный регион в восточной части США (или в другую зону доступности в том же регионе). В отличие от основного региона, дополнительный регион не имеет локальных компьютеров или дисков. Во время отработки отказа Azure Site Recovery принимает дублированные копии данные из хранилища Azure Site Recovery и использует их для создания двух новых виртуальных машин, которые являются копиями исходных узлов сеансов, включая данные локального диска и профиля пользователя. Дополнительный регион имеет собственную независимую виртуальную сеть, поэтому виртуальная сеть в основном регионе не будет влиять на функциональные возможности.
На следующей схеме показан пример развертывания, который мы только что описали.
Преимущества этого плана включают более низкую общую стоимость и не требуют обслуживания для исправления или обновления из-за подготовки ресурсов только при необходимости. Однако потенциальный недостаток заключается в том, что вы будете тратить больше времени на подготовку, интеграцию и проверку инфраструктуры отработки отказа, чем при настройке аварийного восстановления общего пула узлов.
Важные сведения о восстановлении личного пула узлов
При использовании этой стратегии аварийного восстановления важно учитывать следующее:
Могут потребоваться требования, необходимые виртуальным машинам пула узлов на вторичном сайте, таким как виртуальные сети, подсети, безопасность сети или vpn-сети для доступа к каталогу, например локальная служба Active Directory.
Примечание.
Использование виртуальной машины , присоединенной к Microsoft Entra, автоматически выполняет некоторые из этих требований.
Вы можете столкнуться с проблемами интеграции, производительности или ресурсов, если крупномасштабная авария влияет на нескольких клиентов или клиентов.
Личные пулы узлов используют виртуальные машины, выделенные одному пользователю. Это означает, что правила балансировки нагрузки сходства направляют все сеансы пользователей обратно к определенной виртуальной машине. Это сопоставление "один к одному" между пользователем и виртуальной машиной означает, что если виртуальная машина отключена, пользователь не сможет войти, пока виртуальная машина не вернется в режим "в сети" или после завершения аварийного восстановления виртуальная машина не будет восстановлена.
Виртуальные машины в личном пуле узлов хранят профиль пользователя на диске C, что означает, что FSLogix не требуется.
Доступность региона влияет на мониторинг данных или рабочей области. Если регион недоступен, служба может потерять все исторические данные мониторинга во время аварии. Рекомендуется использовать пользовательский экспорт или дамп исторических данных мониторинга.
Рекомендуется избегать использования FSLogix при использовании конфигурации личного пула узлов.
Подготовка виртуальных машин не гарантируется в регионе отработки отказа.
Выполняйте управляемые тесты отработки отказа и восстановления размещения по крайней мере раз в шесть месяцев.
В следующей таблице перечислены рекомендации по развертыванию для стратегий аварийного восстановления пула узлов:
| Технология | Рекомендации |
|---|---|
| Сеть | Создайте и разверните вторичную виртуальную сеть в другом регионе, чтобы следовать пользовательским соглашениям об именовании или требованиям к безопасности за пределами схемы именования Azure Site Recovery по умолчанию. |
| Узлы сеансов | Включение и настройка Azure Site Recovery для виртуальных машин. При необходимости можно предварительно подготовить образ вручную или использовать службу Конструктора образов Azure для текущей подготовки. |
| Хранилище | Создание учетной записи службы хранилища Azure необязательно для хранения профилей. |
| Данные профиля пользователя | Данные профиля пользователя хранятся локально на диске C. |
| Идентификация | Контроллеры домена Active Directory из одного каталога в нескольких регионах. |
Следующие шаги
Дополнительные сведения об аварийном восстановлении в Azure см. в следующих статьях: