Параметры непрерывности бизнес-процессов и аварийного восстановления для FSLogix
Примечание.
Все схемы являются примерами на основе виртуального рабочего стола Azure и применимы к другим платформам виртуальных рабочих столов.
Эффективный план непрерывности бизнес-процессов и аварийного восстановления (BCDR) фокусируется на процессах и ресурсах, необходимых для работы организации, если катастрофа или другой значительный сбой. Перемещаемые профили пользователей обычно не описываются как важный для бизнеса или критически важный компонент стратегии BCDR . В среде виртуального рабочего стола пользователь не знает, что у него есть перемещаемый профиль. Профиль перемещается для предоставления пользователям согласованного интерфейса независимо от виртуальной машины. Корпоративные или критически важные данные не должны храниться в профиле пользователя, если это возможно. Использование OneDrive, SharePoint или других решений — это эффективное средство для защиты данных во время события BCDR , а не полагаться на данные, перемещаемые с пользователем в рамках своего профиля. Этот процесс лучше всего описан в целевом объекте времени восстановления (RTO) и целевой точке восстановления (RPO), где преимущества затрат и анализ рисков можно взвесить на основе организационных и бизнес-целей.
Вариант 1. Восстановление профиля отсутствует
Хотя этот вариант не похож на дизайн BCDR , он ориентирован на обеспечение того, чтобы бизнес-и критически важные данные не были в профиле пользователя. Во время аварии пользователи создадут профили в новом расположении или в новом поставщике хранилища (оба могут быть истинными). Этот вариант является наиболее экономичным с точки зрения стоимости инфраструктуры, хотя имеет штраф из-за влияния, который он может иметь на пользовательском интерфейсе.
Рис. 1. Восстановление профилей | Стандартные контейнеры FSLogix (VHDLocations)
На схеме используется пул узлов с несколькими регионами с помощью виртуального рабочего стола Azure. Основной и отработка отказа регионов имеют выделенный Файлы Azure общий ресурс с использованием хранилища, избыточного между зонами (ZRS), который обеспечивает высокий уровень доступности в регионе. В регионе отработки отказа есть узлы сеансов, которые остановлены или освобождены. В случае аварии регион отработки отказа становится основным регионом, и пользователи будут входить в эти узлы сеансов и создавать новые профили в Файлы Azure общей папке в этом регионе.
Вариант 2. Облачный кэш (основной или отработка отказа)
Проект отработки отказа — это общая стратегия обеспечения доступности и надежности инфраструктуры в случае аварии или сбоя. Облачный кэш позволяет использовать FSLogix с помощью этого типа проектирования отработки отказа. С помощью облачного кэша можно настроить устройства для использования двух поставщиков хранилища (2), которые хранят данные профиля в разных расположениях. Облачный кэш синхронизирует данные профиля с каждым из двух поставщиков хранилища асинхронно, поэтому у вас всегда есть последняя версия данных. Некоторые устройства находятся в основном расположении, а другие устройства находятся в расположении отработки отказа. Облачный кэш определяет первый поставщик хранилища (ближайший к устройству) и использует другой поставщик хранилища в качестве резервной копии. Например, если основное устройство находится в западной части США, а устройство отработки отказа находится в восточной части США, можно настроить облачный кэш следующим образом:
- Основное устройство использует поставщик хранилища в западной части США в качестве первого варианта и поставщика хранилища в восточной части США в качестве второго варианта.
- Устройство отработки отказа использует поставщик хранилища в восточной части США в качестве первого варианта и поставщика хранилища в западной части США в качестве второго варианта.
- Если основное устройство или ближайший поставщик хранилища завершается ошибкой, вы можете переключиться на устройство отработки отказа или поставщик хранилища резервных копий и продолжить работу, не теряя данные профиля.
Однако существуют некоторые недостатки использования проектирования отработки отказа с облачным кэшем. Во-первых, необходимо заплатить за хранение данных профиля в двух (2) расположениях. Во-вторых, необходимо вручную инициировать процесс отработки отказа, который может потребовать одобрения заинтересованных лиц бизнеса. В-третьих, может возникнуть некоторая задержка или несоответствие в данных профиля из-за асинхронной синхронизации с двумя поставщиками хранилища.
Совет
- Прежде чем разрешить пользователям вернуться к профилям в основном расположении, убедитесь, что все пользователи успешно вышли из расположения отработки отказа, чтобы убедиться, что основное расположение имеет актуальное реплика данных профиля пользователя.
- Облачный кэш является интенсивной системой ввода-вывода и может легко вызвать узкие места сети и (или) хранилища в восстановленном расположении.
Рис. 2. Облачный кэш (основной или отработка отказа) | FSLogix Cloud Cache (CCDLocations)
На схеме у нас есть пул узлов с несколькими регионами, использующий виртуальный рабочий стол Azure. Основные и отказоустойчивые регионы являются частью этой установки. Каждый из них имеет выделенный Файлы Azure совместно использовать хранилище, избыточное между зонами (ZRS), обеспечивая высокий уровень доступности в регионе. Регион отработки отказа содержит узлы сеансов, которые либо остановлены, либо освобождены. В случае аварии регион отработки отказа становится основным регионом. Пользователи будут входить в эти узлы сеансов и загружать свой реплика загруженный профиль из региона отработки отказа.
Однако важно рассмотреть следующее:
- События BCDR (непрерывность бизнес-процессов и аварийное восстановление) редко являются грациозными. В зависимости от обстоятельств данные профиля пользователя могут не быть нетронутыми.
- Пользователи, выполнив вход в узлы сеансов в регионе отработки отказа, могут столкнуться с потерей данных или, в худших случаях, повреждением контейнера.
Учитывая эту ситуацию, важно использовать такие платформы хранения, как OneDrive или SharePoint для критически важных данных. Эти платформы обеспечивают дополнительную избыточность и защиту от потери данных. Помните, что планирование аварийного восстановления является важным, а правильная стратегия хранения может снизить риски и обеспечить непрерывность бизнес-процессов.
Вариант 3. Облачный кэш (активный или активный)
При обсуждении инфраструктуры часто используются активные и активные проекты, которые также можно применять к решению профиля FSLogix. С помощью этого параметра облачный кэш настраивается с двумя поставщиками хранилища, которые обновляются асинхронно, чтобы отразить все изменения, внесенные в локальный кэш. Поставщик хранилища, ближайший к активному расположению, указан первым, а самый быстрый поставщик указан вторым. В другом расположении порядок изменится. Этот параметр несет дополнительные затраты на хранение данных поставщика в двух расположениях и требует ручного принятия решения заинтересованными лицами бизнеса перед началом отработки отказа.
Совет
- В случае сбоя региона может потребоваться значительное время для полного реплика te данных профиля.
- Облачный кэш является интенсивной системой ввода-вывода и может легко вызвать узкие места сети и (или) хранилища в восстановленном расположении.
Рис. 3. Облачный кэш (активный или активный) | FSLogix Cloud Cache (CCDLocations)
На схеме представлены два (2) пулы узлов AVD и узлы сеансов, размещенные в определенных регионах Azure. Пользователи, назначенные региону "Западная часть США", получают доступ к этим виртуальным машинам. Пользователи в регионе "Восточная часть США" получают доступ только к этим виртуальным машинам. Во время аварии в выживаемом регионе должно быть достаточно ресурсов для поддержки всех пользователей. Кроме того, пользователям из неудавшегося региона требуется доступ к виртуальным машинам в остающемся регионе.
События BCDR никогда не являются грациозными и в зависимости от обстоятельств события данные профиля пользователя не гарантируются нетронутыми. Пользователи, которые входят в узлы сеансов в выживших регионах, могут столкнуться с потерей данных или повреждением контейнера. Эта ситуация усиливает необходимость использования платформ хранения, таких как OneDrive или SharePoint для критически важных пользовательских данных.