Что нового в Windows 8 для облачных вычислений на базе Hyper-V (часть 11) — сценарии аварийного восстановления Hyper-V

Опубликовано: 20 Апреля, 2023

  • Эта статья является последней в серии из 11 частей, в которой представлен всесторонний обзор новых функций в Windows Server 2012 и Windows 8. клиент, поддерживающий виртуализацию и облачные вычисления.

    Сценарии аварийного восстановления реплики Hyper-V

    Реплика Hyper-V поддерживает четыре основных сценария аварийного восстановления для частных, хостинговых и распределенных сред. Сценарии частной среды состоят из настройки реплик между главным корпоративным офисом и филиалом, а также между корпоративными центрами обработки данных. Сценарий хостинга включает настройку реплик между центрами обработки данных хостинг-провайдера, которые поддерживают несколько клиентов. Наконец, кросс-локальный сценарий состоит из настройки реплик между корпоративным офисом и центром обработки данных хостинг-провайдера, который поддерживает несколько клиентов.

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

    Сценарий главного корпоративного офиса и филиала

    Организации с главным корпоративным офисом и несколькими географически разбросанными филиалами склонны к централизации некоторых важных приложений на главном сайте. Доступ к этим приложениям обычно осуществляется сайтами филиалов через канал WAN. Критически важные приложения могут включать экземпляры SQL Server, веб-сайты IIS, приложения System Center, бизнес-приложения (LOB) или многие другие основные приложения. Как правило, приложения централизованы на главном сайте из-за бюджетных ограничений или из-за ограниченности помещений и/или ИТ-персонала на сайтах филиалов. Без плана аварийного восстановления для смягчения проблемы, если основной сайт становится недоступным из-за проблемы с сетевым подключением, сбоя физического сервера или отказа физического объекта, местоположения филиалов могут серьезно повлиять на бизнес, поскольку они больше не могут получить доступ к критически важным ресурсам. приложения, необходимые им для выполнения повседневных операций. Однако использование Windows Server 2012 Hyper-V для развертывания критически важных приложений на виртуальных машинах на главном корпоративном сайте и репликация виртуальных машин с помощью Hyper-V Replica на основные сайты филиалов позволяет создать эффективный и экономичный план аварийного восстановления. возможно в рамках бюджета даже малых и средних компаний.

    Реализация этого типа сценария аварийного восстановления включает следующие основные этапы:

    1. Разверните Windows Server 2012 Hyper-V на основном корпоративном сайте и сайтах филиалов.
    2. Виртуализация критически важных приложений на главном корпоративном сайте на Windows Server 2012 Hyper-V (возможно, отказоустойчивый кластер для одновременной реализации высокой доступности)
    3. Определите, следует ли использовать аутентификацию Kerberos (требуется членство в домене AD или доверительные отношения) или аутентификацию на основе сертификатов (различная поддержка или отсутствие общей поддержки членства в домене AD или требование зашифрованной репликации) между первичным сервером и сервером-репликой.
    4. Настройте один или несколько серверов реплик Windows Server 2012 в выбранных филиалах.
    5. Включите репликацию между основными виртуальными машинами, работающими на главном корпоративном сайте, и выбранными серверами-репликами на сайтах филиалов.
    6. Выполните первоначальную репликацию основных виртуальных машин на выбранные серверы-реплики.
    7. Выполните тестовую отработку отказа каждой основной виртуальной машины, чтобы проверить возможность успешного переключения на сайты выбранных филиалов.
    8. Настройте реплику Hyper-V на главном корпоративном сайте, чтобы проверить путь обратной репликации для основных виртуальных машин.
    9. Выполните запланированную отработку отказа каждой основной виртуальной машины на выбранных серверах-репликах и проверьте путь обратной репликации для основных виртуальных машин.
    10. Выполните тестовую миграцию основных виртуальных машин в среде отказоустойчивого кластера, чтобы убедиться, что репликация продолжается после миграции сервера или хранилища (требуется конфигурация Hyper-V Replica Broker).

    Тестовый переход на другой ресурс не требует запланированного отключения, поскольку основная виртуальная машина продолжает выполняться и реплицироваться на виртуальную машину-реплику во время тестового события. Этот параметр предоставляется с репликой Hyper-V для создания новой дублирующей тестовой виртуальной машины с целью проверки того, что точка восстановления может успешно запуститься и что виртуальная машина с тестовой репликой работает правильно. Новая тестовая виртуальная машина создается с тем же именем, что и основная виртуальная машина, с добавлением Test в конец имени. Например, для основной виртуальной машины с именем VM1 новая тестовая виртуальная машина называется VM1-Test. Поскольку новая тестовая виртуальная машина создается на том же сервере Hyper-V, что и основная виртуальная машина, сетевая конфигурация новой тестовой виртуальной машины отключена, чтобы она не мешала работе основной виртуальной машины. Вам следует подключить новую тестовую виртуальную машину к изолированной сети, чтобы выполнить обратную репликацию или другие задачи проверки.

    Запланированная отработка отказа требует запланированного простоя, поскольку основная виртуальная машина должна быть отключена, чтобы гарантировать отсутствие потери данных. После выключения основной виртуальной машины последний журнал реплики Hyper-V отправляется на сервер реплики, и вы выполняете контролируемый переход на сервер реплики. Во время запланированного перехода на другой ресурс выполняется обратная проверка пути репликации, и виртуальная машина-реплика запускается и продолжает работать до тех пор, пока вы не выполните запланированный переход на другой ресурс обратно на основную виртуальную машину.

    Сценарий корпоративного центра обработки данных

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

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

    Сценарий центра обработки данных хостинг-провайдера

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

    Межучрежденческий сценарий

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

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

    Вывод

    В этой заключительной статье серии из 11 частей вы узнали о сценариях аварийного восстановления, включенных по умолчанию с помощью функции Windows Server 2012 Hyper-V Replica. Теперь должно быть очевидно, что реплика Hyper-V обеспечивает поддержку распространенных сценариев аварийного восстановления и обеспечения непрерывности бизнеса для различных предприятий в облачных средах или между ними и без затрат или интеграции сторонних решений.