Аварийное восстановление для виртуальных машин Azure Stack Hub

В этой статье описываются рекомендации по архитектуре и проектированию решения, которое обеспечивает оптимизированный подход к аварийному восстановлению рабочих нагрузок, работающих на виртуальных машинах, размещенных в Azure Stack Hub.

Архитектура

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

Рабочий процесс

К облачным компонентам предлагаемого решения относятся следующие службы:

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

• Клиент Идентификатора Microsoft Entra, связанный с подпиской Azure, которая обеспечивает проверку подлинности субъектов безопасности Microsoft Entra для авторизации доступа к ресурсам Azure.

• Хранилище служб восстановления Azure в регионе Azure, который ближе всего к локальному центру обработки данных, в котором размещено развертывание Azure Stack Hub.

  Примечание.

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

• Канал Azure ExpressRoute , который подключает локальные центры обработки данных к региону Azure, в котором размещено хранилище служб восстановления Azure, настроено с частным пирингом и пирингом Майкрософт. Первый гарантирует, что требования к задержке выполняются после отработки отказа. Цель последнего — свести к минимуму время репликации изменений между локальными рабочими нагрузками и сайтом отработки отказа в Azure.

• Учетная запись служба хранилища Azure с большими двоичными объектами, содержащими VHD-файлы, созданные репликацией операционной системы и томов данных защищенных виртуальных машин Azure Stack Hub. Эти VHD-файлы служат источником для управляемых дисков виртуальных машин Azure, которые автоматически подготавливаются после отработки отказа.

• Виртуальная сеть Azure, в которой размещена среда аварийного восстановления. Она настроена таким образом, чтобы зеркально отображала среду виртуальной сети в Azure Stack Hub, в которой размещаются рабочие нагрузки, включая компоненты, такие как подсистемы балансировки нагрузки и группы безопасности сети. Эта виртуальная сеть обычно подключена к виртуальной сети Azure Stack Hub через подключение ExpressRoute для упрощения восстановления на уровне рабочей нагрузки.

  Примечание.

  Иногда VPN-подключение типа "сеть — сеть" достаточно в сценариях, когда требования к целевой точке восстановления (RPO) менее строги.

• Изолированная виртуальная сеть Azure, предназначенная для тестовой отработки отказа, настроенная таким образом, чтобы зеркально отображалась среда виртуальной сети в Azure Stack Hub, в которой размещаются рабочие нагрузки, включая компоненты, такие как подсистемы балансировки нагрузки и группы безопасности сети.

Локальные компоненты предлагаемого решения включают следующие службы:

• Интегрированная система Azure Stack Hub в подключенной модели развертывания. Система запускает текущее обновление (2002 с 9/20) и находится в локальном центре обработки данных клиента.

• Подписка Azure Stack Hub и виртуальная сеть или несколько одноранговых виртуальных сетей, на котором размещаются все локальные виртуальные машины для этого решения.

• Конфигурации и обработки серверов Azure Site Recovery, работающих на виртуальных машинах Azure Hub Stack windows Server 2016 или 2012 R2. Серверы управляют взаимодействием с хранилищем служб восстановления Azure, а также маршрутизацией, оптимизацией и шифрованием трафика репликации.

  Примечание.

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

• Виртуальные машины Azure Stack Hub, которые должны быть защищены. Они выполняют поддерживаемые версии операционных систем Windows Server, CentOS и Ubuntu.

• Служба Site Recovery (также называется агентом мобильности), работающим на защищенных виртуальных машинах. Он отслеживает изменения локальных дисков, записывает изменения в журналах репликации и реплицирует журналы на сервер обработки. Сервер обработки направляет их в целевую учетную запись хранения Azure. Журналы используются для создания точек восстановления для управляемых дисков, которые реализуются с помощью больших двоичных объектов, хранящихся в указанной учетной записи хранения Azure.

Компоненты

• Microsoft Entra ID
• Виртуальная сеть Azure
• Службы восстановления Azure
• Azure ExpressRoute
• Хранилище BLOB-объектов Azure
• Azure Stack Hub

Альтернативные варианты

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

• Отработка отказа на другую метку Azure Stack Hub. Пользователи, которые должны защититься от сбоя центра обработки данных или сайта, могут использовать другое развертывание Azure Stack Hub для реализации положений аварийного восстановления. При использовании основных и вторичных расположений пользователи могут развертывать приложения в активной или пассивной конфигурации в двух средах. Для менее критически важных рабочих нагрузок можно использовать неиспользуемую емкость в дополнительном расположении для восстановления приложений по запросу из резервного копирования. Вы также можете реализовать сайт восстановления в другом центре обработки данных, который, в свою очередь, использует Site Recovery для подготовки реплики сайта восстановления в Azure. Некоторые факторы определяют, является ли использование Site Recovery с Azure в качестве сайта отработки отказа жизнеспособным решением. К этим факторам относятся государственные правила, корпоративные политики и требования к задержкам.

  Примечание.

  По состоянию на июль 2020 года Site Recovery не поддерживает этот сценарий, что означает, что реализация должна использовать партнерское или внутридомовое решение.

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

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

  Примечание.

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

• Резервное копирование и восстановление виртуальных машин с помощью внешнего решения резервного копирования в одном центре обработки данных, а затем репликация резервных копий в другое расположение. Таким образом можно восстановить виртуальные машины Azure Stack Hub в одном экземпляре Azure Stack Hub или в другой или в Azure.

Подробности сценария

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

Традиционные решения для восстановления локальных рабочих нагрузок сложны для настройки, дорогого и трудоемкого использования для обслуживания, особенно при использовании другого локального расположения в качестве сайта отработки отказа. Корпорация Майкрософт рекомендует альтернативное решение, основанное на сочетании облачных и локальных компонентов для обеспечения устойчивости, производительности, высокоавтомативного и простого способа реализации, защиты и управления эффективной стратегией аварийного восстановления. Основным элементом этого решения является Site Recovery с сайтом отработки отказа, размещенным в Azure.

Потенциальные варианты использования

Site Recovery с Azure в качестве сайта отработки отказа устраняет все перечисленные выше недостатки. Вы можете использовать свои возможности для защиты физических и виртуальных серверов, в том числе работающих на платформах виртуализации Microsoft Hyper-V или VMware ESXi. Вы также можете использовать те же возможности для упрощения восстановления рабочих нагрузок, выполняемых на виртуальных машинах Azure Stack Hub.

Базовая функциональность

Site Recovery — это решение аварийного восстановления, которое упрощает защиту физических и виртуальных компьютеров, предоставляя два набора функций:

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

Site Recovery предлагает три типа отработки отказа:

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

Site Recovery поддерживает несколько сценариев, таких как отработка отказа и восстановление размещения между двумя локальными сайтами, отработка отказа и восстановление размещения между двумя регионами Azure и миграция из облаков сторонних поставщиков. Однако в контексте этой статьи основное внимание уделяется репликации локальных дисков виртуальных машин Azure Stack Hub в служба хранилища Azure, а также отработки отказа виртуальной машины и восстановления размещения между стеком Azure Stack Hub и регионом Azure.

Сведения об архитектуре Site Recovery и его компонентах зависят от ряда критериев, в том числе:

• Типы компьютеров для защиты (физические и виртуальные).
• Для виртуализированных сред тип гипервизора, на котором размещаются виртуальные машины для защиты (Hyper-V и VMware ESXi).
• Для сред Hyper-V для управления узлами Hyper-V используется system Center диспетчер виртуальных машин (SCVMM).

С помощью Azure Stack Hub архитектура соответствует той, которая применима к физическим компьютерам. Это не особенно удивительно, потому что в обоих случаях Site Recovery не может воспользоваться прямым доступом к гипервизору. Вместо этого механизм отслеживания и репликации изменений на локальные диски реализуется в защищенной операционной системе.

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

Сервер конфигурации координирует взаимодействие с хранилищем Site Recovery и управляет репликацией данных. Кроме того, сервер конфигурации размещает компонент, называемый сервером обработки, который выступает в качестве шлюза, получения данных репликации, оптимизации его путем кэширования и сжатия, шифрования и, наконец, пересылки его в служба хранилища Azure. Фактически сервер конфигурации работает в качестве точки интеграции между Site Recovery и защищенными виртуальными машинами, работающими в Azure Stack Hub. Вы реализуете эту интеграцию, развернув сервер конфигурации и зарегистрируя его в хранилище служб восстановления Azure.

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

• Пороговое значение RPO. Этот параметр представляет нужную целевую точку восстановления, которую требуется реализовать, и определяет частоту создания моментальных снимков точки восстановления, согласованной с site Recovery. Его значение не влияет на частоту репликации, так как репликация непрерывна. Site Recovery создаст оповещение и, при необходимости, уведомление по электронной почте, если текущее действующее RPO, предоставленное Site Recovery, превышает указанное пороговое значение. Site Recovery создает моментальные снимки точки восстановления с согласованной с аварийной производительностью каждые пять минут.

  Примечание.

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

• Хранение точки восстановления. Этот параметр представляет длительность (в часах) окна хранения для каждого моментального снимка точки восстановления. Защищенные виртуальные машины можно восстановить до любой точки восстановления в окне хранения. Site Recovery поддерживает до 24 часов хранения виртуальных машин, реплицированных в служба хранилища Azure учетных записей с уровнем производительности premium. При использовании учетных записей служба хранилища Azure с стандартным уровнем производительности существует ограничение на 72-часовое хранение.

• Периодичность создания моментальных снимков с согласованием приложений. Этот параметр определяет частоту (в часах), в которой Site Recovery создает моментальные снимки, согласованные с приложениями. Моментальный снимок, согласованный с приложением, представляет моментальный снимок приложений, работающих на защищенной виртуальной машине. Существует ограничение в 12 моментальных снимков, согласованных с приложениями. Для виртуальных машин под управлением Windows Server Site Recovery использует службу теневого копирования томов (VSS). Site Recovery также поддерживает моментальные снимки, согласованные с приложениями для Linux, но для этого требуется реализация пользовательских скриптов. Скрипты используются агентом мобильности при применении моментального снимка, согласованного с приложением.

  Примечание.

  Дополнительные сведения о реализации моментальных снимков, согласованных с приложениями, на виртуальных машинах Azure Stack Hub под управлением Linux, см. в статье "Общие вопросы о Site Recovery".

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

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

Вы можете управлять отработкой отказа путем создания планов восстановления, содержащих вручную и автоматические шаги. Для реализации последнего можно использовать модули Runbook служба автоматизации Azure, состоящие из пользовательских скриптов PowerShell, рабочих процессов PowerShell или скриптов Python 2.

После того как первичный сайт снова станет доступным, Site Recovery поддерживает возврат направления репликации, что позволяет выполнять восстановление размещения с минимальным временем простоя и без потери данных. Однако при использовании Azure Stack Hub такой подход недоступен. Вместо этого, чтобы выполнить отработку отказа, необходимо скачать файлы дисков виртуальной машины Azure, передать их в Azure Stack Hub и подключить их к существующим или новым виртуальным машинам.

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Надежность

Надежность гарантирует, что ваше приложение может выполнять обязательства, которые вы выполняете вашим клиентам. Дополнительные сведения см. в разделе "Обзор основы надежности".

Azure Stack Hub помогает повысить доступность рабочей нагрузки благодаря устойчивости, присущей своей инфраструктуре. Эта устойчивость обеспечивает высокий уровень доступности для виртуальных машин Azure Stack Hub, защищенных Site Recovery, и для основных компонентов локальной инфраструктуры Site Recovery, включая серверы конфигурации и обработки.

Аналогичным образом можно использовать устойчивость облачных компонентов инфраструктуры Site Recovery. По умолчанию службы восстановления Azure являются геоизбыточными, что означает, что ее конфигурация автоматически реплицируется в регион Azure, который является частью предварительно определенной пары регионов. Вы можете изменить параметры репликации на локально избыточное, если это достаточно для ваших потребностей в устойчивости. Обратите внимание, что этот параметр нельзя изменить, если хранилище содержит защищенные элементы. Тот же вариант устойчивости доступен для любых учетных записей служба хранилища Azure с уровнем производительности уровня "Стандартный", хотя его можно изменить в любой момент.

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

• Отработка отказа в Azure
• Восстановление размещения в Azure Stack Hub

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

Отработка отказа в Azure

Отработка отказа в Azure является основной частью соображений доступности в контексте защиты виртуальных машин Azure Stack Hub на основе Site Recovery. Чтобы максимально повысить доступность рабочей нагрузки, стратегия отработки отказа должна устранить необходимость свести к минимуму потенциальную потерю данных (RPO) и свести к минимуму время отработки отказа (RTO).

Чтобы свести к минимуму потенциальные потери данных, можно рассмотреть следующее:

• Максимизация пропускной способности и минимизация задержки трафика репликации путем выполнения рекомендаций по масштабируемости и производительности. Дополнительные сведения см. в следующем разделе этой статьи.
• Увеличение частоты точек восстановления, согласованных с приложениями для рабочих нагрузок базы данных (до максимальной точки восстановления в час). Точки восстановления с согласованностью на уровне приложений создаются на основе моментальных снимков с согласованностью на уровне приложений. Моментальные снимки, согласованные с приложениями, фиксируют данные приложения на диске и в памяти. Хотя этот подход сводит к минимуму потенциальную потерю данных, он имеет один из основных недостатков. Для локально установленных приложений моментальных снимков требуется использование службы теневого копирования томов в Windows или пользовательских скриптах в Linux. Процесс отслеживания может повредить производительность, особенно если загрузка ресурсов высока. Не рекомендуется использовать низкую частоту для моментальных снимков, согласованных с приложениями, для рабочих нагрузок, отличных от баз данных.

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

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

Чтобы свести к минимуму время отработки отказа, в рамках создания плана восстановления необходимо:

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

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

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

• Автоматизированный. Это действие основано на служба автоматизации Azure модулях Runbook, которые включают один из двух типов задач:
  • Подготовка и настройка ресурсов Azure, включая создание общедоступного IP-адреса и связывание его с сетевым интерфейсом, подключенным к виртуальной машине Azure.
  • Изменение конфигурации операционной системы и приложений, работающих на виртуальной машине Azure, подготовленной после отработки отказа.
• Вручную. Это действие не поддерживает автоматизацию и включается в план восстановления в основном в целях документации.

Восстановление размещения в Azure Stack Hub

В сценариях на основе Site Recovery восстановление размещения( при правильной реализации) не связано с потерей данных. Это означает, что основной целью стратегии отработки отказа является минимизация времени восстановления размещения (RTO). Однако, как упоминалось ранее, при отработке отказа в Azure Stack Hub вы не можете полагаться на планы восстановления. Вместо этого восстановление размещения включает в себя следующую последовательность шагов:

1. Остановите и раздали виртуальные машины Azure в среде аварийного восстановления.
2. Определите параметр URI каждого управляемого диска, подключенного к виртуальным машинам, которые планируется скачать.
3. Скачайте файлы виртуального жесткого диска (VHD), определяемые параметрами URI, указанными на предыдущем шаге, в локальную среду.
4. Отправьте VHD-файлы в Azure Stack Hub.
5. Подключите загруженные виртуальные жесткие диски к новым или существующим виртуальным машинам Azure Stack Hub.
6. Запустите виртуальные машины Azure Stack Hub.

Оптимальный подход к минимизации времени восстановления размещения — автоматизировать его.

Рекомендации, связанные с рабочей нагрузкой

Site Recovery интегрируется с приложениями и ролями на основе Windows Server, включая SharePoint, Exchange, SQL Server и службы домен Active Directory (AD DS). Это позволяет использовать следующие возможности для реализации защиты и восстановления на уровне приложений:

• Интеграция с технологиями репликации на уровне приложений, такими как группы доступности SQL Server AlwaysOn, группы доступности базы данных Exchange (DAG) и репликация AD DS
• Моментальные снимки, согласованные с приложением, для отдельных или нескольких уровней приложений
• Многофункциональная библиотека автоматизации, которая предоставляет готовые к работе сценарии для конкретных приложений, которые можно скачать и интегрировать с планами восстановления.

Кроме того, можно использовать механизмы репликации для конкретной рабочей нагрузки для обеспечения устойчивости на уровне сайта. Это часто используемый вариант при реализации аварийного восстановления для контроллеров домена AD DS, SQL Server или Exchange, все из которых изначально поддерживают репликацию. Хотя для этого требуется подготовка виртуальных машин Azure, размещающих эти рабочие нагрузки в среде аварийного восстановления, что повышает затраты, это дает следующие преимущества:

• Сокращает время, необходимое для отработки отказа и восстановления размещения
• Упрощение отработки отказа на уровне рабочей нагрузки, а также сценарии, в которых отработка отказа на уровне сайта не требуется

Безопасность

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

• Шифрование при передаче. Это включает обмен данными между защищенными виртуальными машинами Azure Stack Hub, локальными компонентами Site Recovery и облачными компонентами Site Recovery:

  • Агент мобильности, установленный на защищенных виртуальных машинах, всегда взаимодействует с сервером обработки через TLS 1.2.
  • Для обмена данными с сервера конфигурации с сервера конфигурации в Azure и с сервера обработки в Azure можно использовать TLS 1.1 или 1.0. Чтобы повысить уровень безопасности гибридного подключения, следует рассмотреть возможность применения ПРОТОКОЛА TLS 1.2.

  Примечание.

  Дополнительные сведения о настройке шифрования на основе TLS 1.2 см. в параметрах реестра протокола TLS и обновлении, чтобы включить протоколы TLS 1.1 и TLS 1.2 в Качестве безопасных протоколов по умолчанию в WinHTTP в Windows

• Шифрование при хранении Это включает служба хранилища Azure и виртуальные машины Azure на сайте аварийного восстановления.

  • служба хранилища Azure шифруется неактивно для всех учетных записей хранения с использованием 256-разрядного шифрования уровня "Стандартный" и соответствует стандарту Федеральной информационной обработки 140-2. Шифрование включено автоматически и не может быть отключено. По умолчанию шифрование использует ключи, управляемые корпорацией Майкрософт, но клиенты могут использовать собственные ключи, хранящиеся в хранилище ключей Azure.
  • Управляемые диски виртуальных машин Azure автоматически шифруются с помощью серверного шифрования управляемых дисков Azure, которые также применяются к их моментальным снимкам, используя ключи шифрования, управляемые платформой.

Кроме того, вы можете применить ограниченный доступ к учетным записям служба хранилища Azure, в котором размещено содержимое дисков, реплицируемых Site Recovery. Для этого включите управляемое удостоверение для хранилища служб восстановления и назначьте этому управляемому удостоверению следующие роли управления доступом на основе ролей Azure (Azure RBAC) на уровне учетной записи служба хранилища Azure:

• Учетные записи хранения на основе Resource Manager (стандартный уровень производительности):
  • Участник
  • Участник данных хранилища BLOB-объектов
• Учетные записи хранения на основе Resource Manager (уровень производительности premium):
  • Участник
  • Владелец данных BLOB-объектов хранилища

Хранилище служб восстановления Azure предлагает механизмы, которые дополнительно защищают его содержимое, включая следующие защиты:

• Azure RBAC; Это позволяет выполнять делегирование и разделение обязанностей в соответствии с принципом наименьшей привилегии. Существуют три встроенные роли, связанные с Site Recovery, которые ограничивают доступ к операциям Site Recovery:
  • Участник Site Recovery. Эта роль имеет все разрешения, необходимые для управления операциями Site Recovery в хранилище служб восстановления Azure. Однако пользователь с этой ролью не может создать или удалить хранилище или назначить права доступа другим пользователям. Эта роль лучше всего подходит для администраторов аварийного восстановления, которые могут включить аварийное восстановление и управлять ими для клиента Azure Stack Hub.
  • Оператор Site Recovery. Эта роль имеет разрешения для выполнения операций отработки отказа и восстановления размещения и управления ими. Пользователь с этой ролью не может включить или отключить репликацию, создать или удалить хранилище, зарегистрировать новую инфраструктуру или назначить права доступа другим пользователям. Эта роль лучше всего подходит для оператора аварийного восстановления, который может выполнить отработку отказа виртуальных машин Azure Stack Hub при указании владельцев приложений и ИТ-администраторов в фактическом или имитированном сценарии аварии.
  • Средство чтения Site Recovery. Эта роль имеет разрешения для отслеживания всех операций управления Site Recovery. Эта роль лучше всего подходит ит-специалистам, ответственным за мониторинг состояния защищенных виртуальных машин Azure Stack Hub и привлечения запросов в службу поддержки при необходимости.
• Блокировки ресурсов Azure. У вас есть возможность создавать и назначать блокировки только для чтения и удалять в хранилище Site Recovery, чтобы снизить риск случайного и вредоносного изменения или удаления хранилища.
• Обратимое удаление. Целью обратимого удаления является защита хранилища и его данных от случайного или вредоносного удаления. При обратимом удалении любое удаленное содержимое сохраняется в течение 14 дополнительных дней, что позволяет получить его в течение этого периода. Дополнительное 14-дневное хранение содержимого хранилища не несет никаких затрат. Обратимое удаление включено по умолчанию.
• Защита операций с учетом безопасности. Хранилище служб восстановления Azure позволяет включить дополнительный уровень проверки подлинности всякий раз, когда выполняется операция с учетом безопасности, например отключение защиты. Эта дополнительная проверка помогает гарантировать, что авторизованные пользователи выполняют такие операции.
• Мониторинг и оповещения о подозрительных действиях. Службы восстановления Azure обеспечивают встроенный мониторинг и оповещение о событиях безопасности, связанных с операциями хранилища.

Оптимизация затрат

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

При рассмотрении стоимости решения аварийного восстановления на основе Site Recovery, описанного в этой статье, необходимо учитывать как локальные, так и облачные компоненты. Модель ценообразования Azure Stack Hub определяет цены на локальные компоненты. Как и в Azure, Azure Stack Hub предлагает соглашение с оплатой по мере использования, доступное с помощью корпоративных соглашений и программы поставщик облачных решений. Это соглашение включает ежемесячную цену для каждой виртуальной машины Windows Server. Если у вас есть возможность использовать существующие лицензии Windows Server, вы можете значительно сократить затраты на базовую виртуальную машину. Однако при использовании Site Recovery обычно требуется только одна виртуальная машина Azure Stack Hub для каждого клиента, которая необходима для реализации сервера конфигурации для конкретного клиента.

Плата, связанная с Azure, связана с использованием следующих ресурсов:

• Службы восстановления Azure. Цены определяются количеством защищенных экземпляров. Стоит отметить, что каждый защищенный экземпляр не взимает никаких расходов Site Recovery в течение первых 31 дней.

• служба хранилища Azure; Цены отражают сочетание следующих факторов:

  • Уровень производительности
  • Объем сохраненных данных
  • Объем исходящей передачи данных
  • Количество и типы выполненных операций (только для уровня производительности уровня "Стандартный")
  • Избыточность данных (только для уровня производительности уровня "Стандартный")

• Azure ExpressRoute. Цены основаны на одной из двух моделей:

  • Безлимитный тарифный план. Эта модель включает ежемесячную плату со всеми входящими и исходящими передачами данных.
  • Тарифный план с оплатой за трафик. Эта модель включает ежемесячную плату со всеми входящими передачами данных бесплатно и исходящими передачами данных, которые взимается за ГБ.

  Примечание.

  Эта оценка не включает затраты на физические подключения, предоставляемые сторонними поставщиками подключений.

• Виртуальные машины Azure. Цены на виртуальные машины Azure отражают сочетание двух компонентов:

  • Затраты на вычисления. Размер виртуальной машины, время простоя и модель лицензирования операционной системы определяют стоимость.
  • Затраты на управляемый диск. Размер диска и уровень производительности определяют стоимость.

  Примечание.

  Стоит отметить, что гидратация устраняет необходимость запуска виртуальных машин Azure во время регулярных бизнес-операций с рабочими нагрузками, работающими в Azure Stack Hub, что значительно снижает затраты на вычисления реализаций на основе Site Recovery, особенно в сравнении с традиционными решениями аварийного восстановления.

  Примечание.

  Цены на ресурсы зависят от регионов Azure.

  Примечание.

  Дополнительные сведения о ценах см. в ценах На Azure.

Эффективность работы

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

Основные рекомендации по управлению аварийного восстановления на основе Site Recovery виртуальных машин Azure Stack Hub:

• Реализация Site Recovery в Azure Stack Hub
• Процедуры отработки отказа и восстановления размещения
• Делегирование ролей и обязанностей
• DevOps

Реализация Site Recovery в Azure Stack Hub

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

Процедуры отработки отказа и восстановления размещения

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

Делегирование ролей и обязанностей

Планирование и реализация аварийного восстановления рабочих нагрузок на основе виртуальных машин Azure Stack Hub с помощью Site Recovery обычно включает взаимодействие заинтересованных лиц:

• Операторы Azure Stack Hub управляют инфраструктурой Azure Stack Hub, обеспечивая наличие достаточных вычислительных ресурсов, хранилищ и сетевых ресурсов, необходимых для реализации комплексного решения аварийного восстановления и обеспечения доступности этих ресурсов для клиентов. Они также сотрудничают с владельцами приложений и данных, чтобы помочь определить оптимальный подход к развертыванию рабочих нагрузок в Azure Stack Hub.
• Администраторы Azure управляют ресурсами Azure, необходимыми для реализации решений гибридного аварийного восстановления.
• Администраторы Microsoft Entra управляют ресурсами Microsoft Entra, включая объекты пользователей и групп, которые используются для подготовки, настройки и управления ресурсами Azure.
• ИТ-специалисты клиента Azure Stack Hub реализуют, реализуют и управляют Site Recovery, включая отработку отказа и восстановление размещения.
• Пользователям Azure Stack Hub необходимо предоставить требования RPO и RTO и отправить запросы на реализацию аварийного восстановления для рабочих нагрузок.

Убедитесь, что есть четкое представление о ролях и обязанностях, которые относятся к владельцам приложений и операторам в контексте защиты и восстановления. Пользователи отвечают за защиту своих виртуальных машин. Операторы отвечают за рабочее состояние инфраструктуры Azure Stack Hub.

DevOps

При настройке восстановления на уровне виртуальной машины с помощью Site Recovery в первую очередь отвечает ИТ-операциям, существуют некоторые рекомендации, связанные с DevOps, которые следует включить в комплексную стратегию аварийного восстановления. Azure Stack Hub упрощает реализацию инфраструктуры как кода (IaC), которая включает автоматическое развертывание различных рабочих нагрузок, включая приложения и службы на основе виртуальных машин. Эту возможность можно использовать для упрощения подготовки сценариев аварийного восстановления на основе Site Recovery, что упрощает начальную настройку в нескольких сценариях клиента.

Например, можно использовать одни и те же шаблоны Azure Resource Manager для подготовки всех сетевых ресурсов, необходимых для размещения рабочих нагрузок на основе виртуальных машин в метке Azure Stack Hub для приложения в одной согласованной операции. Вы можете использовать тот же шаблон для подготовки соответствующего набора ресурсов в Azure для подготовки сайта аварийного восстановления. Для учета различий между двумя средами можно просто указать разные значения параметров шаблона в каждом случае.

Оптимизация производительности

Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".

При планировании развертывания Site Recovery в Azure Stack Hub необходимо учитывать объем обработки, хранилища и сетевых ресурсов, выделенных серверам конфигурации и обработки. Возможно, потребуется настроить предполагаемое изменение размера виртуальной машины Azure Stack Hub, на котором размещены компоненты Site Recovery после развертывания, чтобы удовлетворить изменения в требованиях к обработке или хранилищу. У вас есть три основных варианта настройки размера:

• Реализуйте вертикальное масштабирование. Это включает изменение объема и типа процессора, памяти и дисков виртуальной машины Azure Stack Hub, на котором размещен сервер конфигурации, включая сервер обработки. Чтобы оценить требования к ресурсам, можно использовать сведения в следующей таблице:

  Таблица 1. Требования к размеру сервера конфигурации и обработки

  ЦП	Память	Диск кэша	Частота изменения данных	Защищенные компьютеры
  8 виртуальных ЦП 2 сокета * 4 ядра @ 2,5 ГГц	16 ГБ	300 ГБ	500 ГБ или менее	< 100 компьютеров
  12 виртуальных ЦП 2 сокета * 6 ядер @ 2,5 ГГц	18 ГБ	600 ГБ	500 ГБ — 1 ТБ	От 100 до 150 компьютеров
  16 виртуальных ЦП 2 сокета * 8 ядер @ 2,5 ГГц	32 Гб	1 TБ	1-2 TБ	150—200 компьютеров

• Реализуйте горизонтальное масштабирование. Это включает подготовку или отмену подготовки виртуальных машин Azure Stack Hub с сервером обработки, установленным для соответствия требованиям обработки защищенных виртуальных машин Azure Stack Hub. Как правило, если необходимо масштабировать развертывание до более чем 200 исходных компьютеров, или у вас есть общая скорость ежедневного увеличения объема более двух терабайтов (ТБ), вам потребуется дополнительные серверы обработки для обработки трафика репликации. Чтобы оценить количество и конфигурацию дополнительных серверов обработки, ознакомьтесь с рекомендациями по размеру сервера обработки.

• Изменение политики репликации. Это включает изменение параметров политики репликации с акцентом на моментальные снимки, согласованные с приложениями.

В сетевой точке существует несколько различных методов настройки пропускной способности, доступной для трафика репликации:

• Изменение размера виртуальной машины. Размер виртуальных машин Azure Stack Hub определяет максимальную пропускную способность сети. Однако важно отметить, что нет гарантий пропускной способности. Вместо этого виртуальные машины могут использовать объем доступной пропускной способности до предела, определенного их размером.

• Замените переключатели uplink. Системы Azure Stack Hub поддерживают ряд аппаратных коммутаторов, предлагая несколько вариантов скорости связи вверх. Каждый узел кластера Azure Stack Hub имеет две связи вверх поверх коммутаторов стойки для отказоустойчивости. Система выделяет половину емкости исходящей связи для критической инфраструктуры. Оставшаяся часть — это общая емкость для служб Azure Stack Hub и всего трафика пользователей. Системы, развернутые с более быстрыми скоростями, имеют большую пропускную способность для трафика репликации.

  Примечание.

  Хотя сетевой трафик можно разделить, подключив второй сетевой адаптер к серверу с виртуальными машинами Azure Stack Hub, все трафик виртуальной машины к Интернету использует одну и ту же связь вверх. Во-вторых, виртуальный сетевой адаптер не отделяет трафик на физическом уровне транспорта.

• Измените пропускную способность сетевого подключения к Azure. Для размещения больших объемов трафика репликации можно использовать Azure ExpressRoute с пирингом Майкрософт для подключений между виртуальными сетями Azure Stack Hub и служба хранилища Azure. Azure ExpressRoute расширяет локальные сети в облако Майкрософт через частное подключение, предоставленное поставщиком подключений. Вы можете купить каналы ExpressRoute для широкого диапазона пропускной способности, от 50 мегабит в секунду (Мбит/с) до 100 гигабит в секунду.

  Примечание.

  Дополнительные сведения о реализации Azure ExpressRoute в сценариях Azure Stack Hub см. в статье "Подключение Azure Stack Hub к Azure с помощью Azure ExpressRoute".

• Изменение регулирования трафика репликации на сервере обработки. Вы можете контролировать, сколько пропускной способности используется трафиком репликации на виртуальных машинах, на которых размещаются серверы обработки, из графического интерфейса агента служб восстановления Microsoft Azure. Поддерживаемые возможности включают настройку ограничений для рабочих и нерабочих часов, а значения пропускной способности — от 512 килобит в секунду до 1023 Мбит/с. Кроме того, можно применить ту же конфигурацию с помощью командлета Set-OBMachineSetting PowerShell.

• Измените пропускную способность сети, выделенную на защищенную виртуальную машину на сервере обработки. Для этого измените значение записи UploadThreadsPerVM в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure Backup\Replication . По умолчанию значение имеет значение 4, но его можно увеличить до 32, если доступно достаточно пропускной способности сети.

Развертывание этого сценария

Необходимые компоненты

Реализация рекомендуемого решения зависит от удовлетворения следующих предварительных требований:

• Доступ к подписке Azure с разрешениями, достаточными для подготовки и управления всеми облачными компонентами компонентов Site Recovery, в том числе:

  • Хранилище служб восстановления Azure в регионе Azure, указанном как сайт аварийного восстановления для рабочей среды Azure Stack Hub.
  • Учетная запись служба хранилища Azure размещения содержимого реплицированных дисков виртуальных машин Azure Stack Hub.
  • Виртуальная сеть Azure, представляющая среду аварийного восстановления, к которой будут подключены гидратированные виртуальные машины Azure после запланированного или не плановая отработка отказа.
  • Изолированная виртуальная сеть Azure, представляющая тестовую среду, к которой будут подключены гидратированные виртуальные машины Azure после тестовой отработки отказа.
  • Подключение на основе Azure ExpressRoute между локальной средой, виртуальными сетями Azure и учетной записью хранения Azure, используемой для размещения копий VHD-файлов с содержимым, реплицированным с дисков защищенных виртуальных машин Azure Stack Hub.

• Подписка пользователя Azure Stack Hub. Все виртуальные машины Azure Stack Hub, защищенные отдельным сервером конфигурации Site Recovery, должны принадлежать одной подписке пользователя Azure Stack Hub.

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

• Виртуальная машина Windows Server Azure Stack Hub, на которую будет размещаться сервер конфигурации и сервер обработки. Виртуальная машина должна принадлежать той же подписке и быть подключена к той же виртуальной сети, что и виртуальные машины Azure Stack Hub, которые должны быть защищены. Кроме того, виртуальная машина должна:

  • Соответствие требованиям к программному обеспечению и оборудованию сервера конфигурации Site Recovery
  • Соответствие документации по внешним требованиям к сети подключения.

  Примечание.

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

  • Отвечают требованиям к внутреннему подключению. В частности, виртуальные машины Azure Stack Hub, с которыми вы хотите защитить, должны иметь возможность взаимодействовать с:

    • Сервер конфигурации через TCP-порт 443 (HTTPS) для управления репликацией
    • Сервер обработки через TCP-порт 9443 для доставки данных репликации.

    Примечание.

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

• Для защиты виртуальных машин Azure Stack Hub, работающих под управлением любой из поддерживаемых операционных систем , для защиты виртуальных машин Azure Stack Hub под управлением операционных систем Windows Server, необходимо:

  • Создайте учетную запись Windows с правами администратора. Эту учетную запись можно указать при включении Site Recovery на этих виртуальных машинах. Сервер обработки использует эту учетную запись для установки служба Site Recovery. В рабочей среде обязательно отключите управление удаленным доступом пользователей в целевых операционных системах Windows Server, задав значение записи реестра LocalAccountTokenFilterPolierPolicy в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System key to 1.
  • Включение правил совместного использования файлов и принтеров и инструментов управления Windows в брандмауэре Microsoft Defender.

• Чтобы защитить виртуальные машины Azure Stack Hub под управлением операционных систем Linux, необходимо:

  • Создайте корневую учетную запись пользователя. Эту учетную запись можно указать при включении Site Recovery на этих виртуальных машинах. Сервер обработки использует эту учетную запись для установки служба Site Recovery.
  • Установите последнюю версию opensh, opensh-server и пакеты opensl.
  • Включите и запустите порт Secure Shell (SSH) 22.
  • Включите безопасную подсистему FTP и проверку подлинности паролей.

Этапы реализации высокого уровня

На высоком уровне реализация аварийного восстановления на основе Site Recovery в Azure Stack Hub состоит из следующих этапов:

1. Подготовка виртуальных машин Azure Stack Hub к защите с помощью Site Recovery. Убедитесь, что виртуальные машины удовлетворяют предварительным требованиям Site Recovery, перечисленным в предыдущем разделе.

2. Создайте и настройте хранилище служб восстановления Azure. Настройте хранилище служб восстановления Azure и укажите, что нужно реплицировать. Компоненты и действия Site Recovery настраиваются и управляются с помощью хранилища.

3. Настройка исходной среды репликации. Подготовьте сервер конфигурации Site Recovery и сервер обработки, установив двоичные файлы единой установки Site Recovery и зарегистрируйте его в хранилище.

   Примечание.

   Вы можете повторно запустить единую настройку Site Recovery для реализации дополнительных серверов обработки на виртуальных машинах Azure Stack Hub.

4. Настройка целевой среды репликации. Создайте или выберите существующую учетную запись хранения Azure и виртуальную сеть Azure в регионе Azure, где будет размещаться сайт аварийного восстановления. Во время репликации содержимое дисков для защищенных виртуальных машин Azure Stack Hub копируется в учетную запись служба хранилища Azure. Во время отработки отказа Site Recovery автоматически подготавливает виртуальные машины Azure в качестве реплик защищенных виртуальных машин Azure Stack Hub и подключает их к виртуальной сети Azure.

5. Включение репликации. Настройте параметр репликации и включите репликацию для виртуальных машин Azure Stack Hub. Служба мобильности устанавливается автоматически на каждой виртуальной машине Azure Stack Hub, для которой включена репликация. Site Recovery инициирует репликацию каждой виртуальной машины Azure Stack Hub в соответствии с заданными параметрами политики.

6. Выполните тестовую отработка отказа. После установки репликации убедитесь, что отработка отказа будет работать должным образом, выполнив тестовую отработку отказа.

7. Выполните запланированные или не плановая отработка отказа. После успешной отработки отказа можно выполнить плановую или плановая отработка отказа неуправляемую отработку отказа в Azure. У вас есть возможность указать, какие виртуальные машины Azure Stack Hub следует включить в отработку отказа.

8. Выполните восстановление размещения. Когда вы будете готовы к отработке отказа, остановите виртуальные машины Azure, соответствующие виртуальным машинам Azure Stack Hub, скачайте файлы дисков в локальное хранилище, отправьте их в Azure Stack Hub и подключите их к существующей или новой виртуальной машине.

Итоги

В заключение Azure Stack Hub — это уникальное предложение, которое отличается во многих аспектах от других платформ виртуализации. Таким образом, он гарантирует особые соображения в отношении стратегии непрерывности бизнес-процессов для своих рабочих нагрузок. С помощью служб Azure можно упростить проектирование и реализацию этой стратегии. В этой справочной статье об архитектуре мы изучили использование Microsoft Site Recovery для защиты рабочих нагрузок на основе виртуальных машин Azure Stack Hub в подключенной модели развертывания. Этот подход позволяет клиентам воспользоваться устойчивостью и управляемостью Azure Stack Hub и гипермасштабированием и глобальным присутствием облака Azure.

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

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

Документация по продукту:

• Сведения о Site Recovery
• Обзор Azure Stack Hub
• Что такое идентификатор Microsoft Entra?
• Что такое хранилище BLOB-объектов Azure?
• Что такое Azure ExpressRoute?
• Что такое виртуальная сеть Azure?

Модули Microsoft Learn.

• Azure Stack Hub
• Настройка идентификатора Microsoft Entra
• Настройка учетных записей хранения
• Настройка виртуальных сетей
• Проектирование и реализация Azure ExpressRoute
• Разработка решения для восстановления сайта в Azure

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

• Дизайн гибридной архитектуры
• Резервное копирование файлов и приложений в Azure Stack Hub
• Гибридные подключения
• Гибридная общая папка с функцией аварийного восстановления для удаленных и локальных рабочих ролей филиалов