Определение правильного сценария аварийного восстановления
Чтобы смягчить возможные последствия сбоев в центре обработки данных или в регионе, ваша организация должна правильно подготовиться к аварийному восстановлению. Создание правильной стратегии защиты зависит в основном от перечня сценариев сбоев, которые могут повлиять на функциональность используемой вами службы "Виртуальный рабочий стол Azure".
Цели и метрики
Восстановление работоспособности организации требует четкой координации всех процедур, нацеленных на восстановление полной производительности. У всех этих процедур есть нечто общее: общие, четко определенные целевые показатели уровня обслуживания. Службы аварийного восстановления (DR) должны включать следующие метрики:
- Целевая точка восстановления (RPO) — минимально допустимый объем данных, которые необходимо доставить клиентам в рамках услуги по восстановлению активов из резервных копий. И наоборот, этот объем данных можно считать максимально допустимым объемом потери данных, выраженным в виде процентов, вычтенных из значения 100 %.
- Целевое время восстановления (RTO) — это максимально разрешенная длительность процесса восстановления. Этот показатель также можно считать мерой времени допустимого простоя для организации.
- Период хранения — максимальное допустимое время хранения набора резервных копий до их обновления и замены.
Показатели RPO и RTO можно считать сбалансированными относительно друг друга, поэтому клиент может разрешить увеличить время восстановления, чтобы достичь более высоких значений точек восстановления. Если время восстановления критично для клиента из-за доступной пропускной способности или риска простоя, то, возможно, не удастся достичь высокого показателя RPO для этого клиента.
В оставшейся части урока мы рассмотрим три разных сценария сбоев и расскажем, как подготовить план обеспечения непрерывности бизнеса и послеаварийного восстановления (BCDR) для виртуального рабочего стола Azure.
- Сценарий 1. Локальное повреждение данных, метаданных или ресурсов
- Сценарий 2. Сбой в одном центре обработки данных в зоне доступности внутри региона Azure
- Сценарий 3. Сбой в регионе Azure
Примечание.
Подробные сведения о том, как защищать отдельные компоненты виртуального рабочего стола Azure, см. в подразделе "Подробнее" раздела "Краткое содержание" данного урока.
Сценарий 1. Локальное повреждение данных, метаданных или ресурсов
Предположим, что в вашей среде "Виртуальный рабочий стол Azure" возникли проблемы из-за сбоя узла сеанса или повреждения профиля FSLogix. В таких случаях наиболее распространенный метод — восстановление профилей из резервных копий или повторное создание узла сеанса. В данном модуле мы расскажем, как применить эти методы к каждому компоненту среды "Виртуальный рабочий стол Azure".
Служба "Виртуальный рабочий стол Azure"
Все функции виртуального рабочего стола Azure продолжают работать в полном объеме, и на них не влияют сбои этих типов. Корпорация Майкрософт отвечает за полное восстановление данных и работоспособности в рамках заключенного с клиентом соглашения об уровне обслуживания (SLA).
Доменные службы AD DS и Microsoft Entra
Контроллеры доменов Active Directory — критически важные компоненты службы "Виртуальный рабочий стол Azure", и они всегда должны быть доступны. Чтобы сбой не повлиял на их работоспособность, создайте несколько контроллеров домена. Если у вас есть контроллеры домена на виртуальных машинах Azure, убедитесь, что они настроены в одной группе доступности. Если ваши контроллеры домена работают на локальных компьютерах, следует обеспечить избыточность подключения локальной сети к виртуальной сети Azure. Управлять избыточными путями и подключениями можно с помощью Azure ExpressRoute. Сделайте резервную копию состояния системы Active Directory, чтобы при необходимости выполнять восстановление из нее. Если вы используете доменные службы Microsoft Entra, корпорация Майкрософт отвечает за обслуживание избыточных контроллеров домена и их защиту от незапланированных сбоев.
Пулы узлов
Пулы узлов могут стать недоступными при нормальной работе служб. Пулы узлов обеспечивают доступ к виртуальным рабочим столам и приложениям Azure для пользователей. Для их подготовки используется образ рабочего стола, поэтому если происходит сбой, но при этом образ рабочего стола доступен, их можно воссоздать. Кроме того, можно использовать отдельный пул узлов для приложений, потребляемых через службу "Виртуальный рабочий стол Azure". Также следует рассмотреть возможность использования аналогичного подхода аварийного восстановления для этого пула узлов.
Виртуальные сети
Виртуальные сети — это управляемые службы, на которые не влияют сбои такого типа. Виртуальная сеть Azure предоставляет блок частных IP-адресов, в котором можно развернуть все ваши ресурсы для частного подключения. Затем вы сможете защитить эти ресурсы границей. Таким образом, при локальном сбое ресурса в одном центре обработки данных виртуальная сеть никогда не выйдет из строя и в ней не возникнут сбои.
Профили FSLogix и подключение приложений MSIX
В зависимости от выбранной технологии хранения FSLogix вы можете настроить службу Azure Backup для общих ресурсов службы "Файлы Azure" и моментальных снимков Azure NetApp Files. Кроме того, защиту файлов и папок на виртуальных машинах серверов можно обеспечить с помощью службы резервного копирования.
изображения;
Зачастую при выполнении штатных процедур обслуживания среды "Виртуальный рабочий стол Azure" требуется вносить изменения в образы рабочих столов. Следует поддерживать резервные копии образов, чтобы их можно было быстро восстановить в случае повреждения.
Сценарий 2. Сбой в одном центре обработки данных в зоне доступности внутри региона Azure
Регион Azure — это набор центров обработки данных, развернутых в пределах периметра с заданными задержками и подключенных через выделенную региональную сеть с малыми задержками. В случае выхода из строя центра обработки данных или зоны в регионе Azure в вашем BCDR для службы "Виртуальный рабочий стол Azure" необходимо использовать рекомендации, изложенные в следующих разделах.
Служба "Виртуальный рабочий стол Azure"
Все функции виртуального рабочего стола Azure продолжают работать в полном объеме, и на них не влияют сбои этого типа. Корпорация Майкрософт отвечает за полное восстановление данных и работоспособности в рамках заключенного с клиентом соглашения об уровне обслуживания (SLA).
Доменные службы AD DS и Microsoft Entra
Чтобы избежать проблем, которые могут возникнуть при сбое в одном центре обработки данных, разверните по крайней мере два контроллера домена в зоне доступности. Если вы используете доменные службы Microsoft Entra, корпорация Майкрософт управляет двумя контроллерами домена для вашего клиента в отдельной зоне доступности, если они поддерживаются регионом.
Пулы узлов
Для обеспечения отказоустойчивости виртуальных машин пулов узлов можно развернуть пул узлов службы "Виртуальный рабочий стол Azure" с использованием зон доступности для виртуальных машин. Вы можете распределить виртуальные машины в пуле узлов в разных центрах обработки данных, находящихся в одном и том же регионе.
Виртуальная сеть
Виртуальные сети — это управляемые службы, и на них не влияют сбои этого типа. Необходимо сделать так, чтобы для важных ресурсов всегда были настроены соответствующие сетевые подключения. Например, сбои такого типа могут оказать влияние на базовые подсистемы балансировки нагрузки, так как для последних не поддерживается доступность зоны.
Профили FSLogix и подключение приложений MSIX
Чтобы обеспечить поддержку зон доступности, используйте службы "Файлы Azure" с избыточным хранилищем класса Premium. В этом сценарии при сбое в центре обработки данных профили FSLogix и виртуальные жесткие диски подключения приложений MSIX остаются доступными.
изображения;
Такой сбой не влияет на образы, так как они становятся доступными в другой зоне.
Сценарий 3. Сбой в регионе Azure
Сбой в полных регионах Azure крайне маловероятен и редко. Тем не менее вы должны быть готовы к ним. Изучите приведенные ниже рекомендации и рассмотрите возможность реализации BCDR для службы "Виртуальный рабочий стол Azure".
Служба "Виртуальный рабочий стол Azure"
Все функции виртуального рабочего стола Azure продолжают работать в полном объеме, и на них не влияет сбой такого типа. Корпорация Майкрософт отвечает за полное восстановление данных и работоспособности в рамках заключенного с клиентом соглашения об уровне обслуживания (SLA).
Доменные службы AD DS и Microsoft Entra
Чтобы подготовиться к такому типу сбоя, можно развернуть управляемый домен, чтобы в каждом клиенте Microsoft Entra было создано более одного набора реплик. Наборы реплик можно добавить в любую пиринговую виртуальную сеть в любом регионе Azure, поддерживающем доменные службы Microsoft Entra.
Если вы используете локальные контроллеры домена, необходимо настроить подключение к виртуальной сети в новом регионе с помощью VPN, ExpressRoute или виртуальной глобальной сети (виртуальной глобальной сети). Если вы используете доменные службы Microsoft Entra, можно создать дополнительный набор реплик в другом регионе. Виртуальная сеть в дополнительном регионе, где размещается новый набор реплик, должна иметь возможность взаимодействовать с сетью, в котором размещается основной набор доменных служб Microsoft Entra. Мы рекомендуем использовать пиринг между виртуальными сетями для репликации между наборами реплик внутри одного расположения.
Пулы узлов
Вы можете развернуть пул узлов Виртуального рабочего стола Azure в конфигурациях "активный— активный " и "активный - пассивный ".
При использовании конфигурации активный-активный в одном пуле узлов могут находиться виртуальные машины из нескольких регионов. Используя сочетание функций кэша облака, можно активно реплицировать профиль FSLogix пользователя в хранилище в нескольких регионах. Для присоединения приложения MSIX используйте другую копию в дополнительном файловом ресурсе в другом регионе. Виртуальные машины в каждом регионе должны содержать реестр кэша облака, чтобы указывать расположения. Кроме того, необходимо настроить групповые политики, чтобы обеспечить приоритет расположения локального хранилища. Такое развертывание службы "Виртуальный рабочий стол Azure" обеспечивает самую высокую эффективность с точки зрения пользователей. Это связано с тем, что в случае сбоя пользователи в оставшемся регионе смогут по-прежнему использовать службу, не выполняя повторный вход в нее. Тем не менее эта конфигурация более дорогостоящая, более сложная для развертывания и не оптимизирована для обеспечения высокой производительности.
В конфигурации активный-пассивный можно использовать службу Azure Site Recovery для репликации виртуальных машин в дополнительном регионе с вашими контроллерами доменов. Если вы используете службу Azure Site Recovery, вам не потребуется регистрировать виртуальные машины вручную. Вместо этого агент Виртуального рабочего стола Azure на вторичной виртуальной машине автоматически использует последний маркер безопасности для подключения к ближайшему к нему экземпляру службы. Это гарантирует, что узел сеанса автоматически присоединяется к пулу узлов, и пользователю необходимо повторно подключиться только для доступа к своим виртуальным машинам. Для этой конфигурации вы также можете создать второстепенный пул узлов (называемый сервером горячей замены) в регионе обработки отказа, в котором выключены все ресурсы. Затем, используя план восстановления в службе Azure Site Recovery, можно включить пулы узлов и создать скоординированный процесс. Вам также потребуется создать еще одну группу приложений в регионе отработки отказа и назначить пользователей этой группе.
Виртуальные сети
Сбои в регионе влияют на виртуальные сети, а также на службы, развернутые в этих сетях. Вам необходимо спланировать виртуальную сеть во второстепенном регионе. Вы можете создать виртуальную сеть вручную, а затем настроить ее с использованием пиринга с основной сетью. Вы также можете настроить виртуальную службу в регионе отработки отказа и сохранить параметры вашей основной сети с помощью службы Azure Site Recovery.
В службе "Виртуальный рабочий стол Azure", подключенной к сети в вашей локальной среде, следует настроить виртуальную сеть в дополнительном регионе с подключением к сети локальной среды.
Профили FSLogix и подключение приложений MSIX
Вы можете использовать службу Azure NetApp Files в качестве хранилища для профилей FSXlogix и подключения приложений MSIX, так как она поддерживает репликацию между регионами. Служба "Файлы Azure" со производительностью "Стандартная" также поддерживает репликацию между регионами. Вы можете настроить агент FSLogix таким образом, чтобы он поддерживал несколько расположений профилей. Благодаря этому можно обеспечить доступность в случае возникновения сбоя. Если основное расположение завершается сбоем, агент FSLogix реплицируется как часть виртуальной машины Azure Site Recovery. Агент автоматически пытается использовать путь к профилю, указывающий на дополнительный регион.
В сценарии "активный-активный" (если показатели RTO и RTA меньше одного дня) рекомендуется применять профили FSLogix для использования кэша облака. Кэш облака — это функция FSLogix, которую необходимо специально включить и настроить. Она позволяет использовать несколько удаленных расположений, которые постоянно обновляются во время сеанса пользователя.
изображения;
После каждого изменения образа основного рабочего стола следует реплицировать образы в дополнительном регионе. Вы можете использовать коллекцию вычислений Azure для совместного использования пользовательских образов между регионами. Во время сбоя в основном регионе можно использовать клонированные образы рабочих столов в качестве источников для создания пулов узлов.
Зависимости приложений
Приложениям, зависящим от ресурсов, доступных в основном регионе, требуются те же ресурсы в дополнительном расположении. Например, если некоторые из ваших приложений подключены к серверной части SQL, развернутой в одном регионе, обязательно реплицируйте SQL во второстепенном расположении. Для SQL Server на виртуальных машинах Azure можно использовать Azure Site Recovery. При использовании SQL по модели "платформа как услуга" (PaaS) можно применять активную георепликацию или группы автоматической отработки отказа. Следует включить эти ресурсы в общий план BCDR. Кроме того, следует включить план Azure Site Recovery, который может моделировать зависимости приложений в плане защиты.