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

Эффективный план непрерывности бизнес-процессов и аварийного восстановления (BCDR) фокусируется на процессах и ресурсах, необходимых для работы организации, если катастрофа или другой значительный сбой. Перемещаемые профили пользователей обычно не рассматриваются как критически важный для бизнеса компонент в стратегии BCDR. В среде виртуального рабочего стола пользователь не знает, что у него есть перемещаемый профиль. Профиль перемещается для предоставления пользователям согласованного интерфейса независимо от виртуальной машины. Корпоративные или критически важные данные не должны храниться в профиле пользователя, если это возможно. Использование решений, таких как OneDrive и SharePoint, — это эффективный способ защиты данных во время инцидента BCDR без зависимости от данных, перемещаемых вместе с пользователем в его профиле. Этот процесс лучше всего описан в целевом объекте времени восстановления (RTO) и целевой точке восстановления (RPO), где преимущества затрат и анализ рисков можно взвесить на основе организационных и бизнес-целей.

Вариант 1. Восстановление профиля отсутствует

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

^{Рис. 1: Отсутствие восстановления профиля | Стандартные контейнеры FSLogix (VHDLocations)}

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

Вариант 2. Облачный кэш (основной / резервный)

Проектирование отказоустойчивости — это распространённая стратегия обеспечения надежности и доступности инфраструктуры в случае аварии или сбоя. Облачный кэш позволяет использовать FSLogix с помощью этой схемы резервного копирования. С помощью облачного кэша можно настроить устройства для использования двух поставщиков хранилища (2), которые хранят данные профиля в разных расположениях. Облачный кэш синхронизирует данные профиля с каждым из двух поставщиков хранилища асинхронно, поэтому у вас всегда есть последняя версия данных. Часть ваших устройств находится в основном расположении, а другие устройства находятся в резервном расположении. Облачный кэш приоритизирует первого поставщика хранилища (ближайшего к вашему устройству) и использует другого поставщика хранилища в качестве резервного. Например, если ваше основное устройство находится в западной части США, а устройство для отказоустойчивости расположено в восточной части США, можно настроить облачный кэш следующим образом:

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

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

^{Рис. 2: Облачный кэш (основной / резервный) | FSLogix Cloud Cache (CCDLocations)}

На схеме у нас есть пул узлов с несколькими регионами, использующий виртуальный рабочий стол Azure. Основной и резервный регионы являются частью этой настройки. У каждого из них есть выделенный общий ресурс Azure Files с хранилищем с избыточностью между зонами (ZRS), что обеспечивает высокий уровень доступности в регионе. Резервный регион содержит узлы сеансов, которые либо остановлены, либо дезактивированы. В случае аварии резервный регион становится основным регионом. Пользователи будут входить в эти сеансовые хосты и загружать реплицированный профиль из резервного региона.

Однако важно рассмотреть следующее:

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

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

Вариант 3: Облачный кэш (активный / активный)

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

^{Рис. 3. Облачный кэш (активный или активный) | FSLogix Cloud Cache (CCDLocations)}

На схеме представлены два (2) пулы узлов AVD и узлы сеансов, размещенные в определенных регионах Azure. Пользователи, назначенные региону "Западная часть США", получают доступ к этим виртуальным машинам. Пользователи в регионе "Восточная часть США" получают доступ только к этим виртуальным машинам. Во время аварии в выживаемом регионе должно быть достаточно ресурсов для поддержки всех пользователей. Кроме того, пользователям из неудавшегося региона требуется доступ к виртуальным машинам в остающемся регионе.

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