Share via

Windows Server 8 Hyper-V. Hyper-V Replica, часть первая

  • Article

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

В Windows Server 2008 R2 подобные задачи решались, как правило, с использованием продуктов сторонних вендоров. На Платформе 2011 Алексеем Кибкало был прочитан доклад о создании резервной площадки для виртуального ЦОД с использованием Citrix Essentials for Hyper-V, позднее в блоге был написан ряд статей по этому поводу. Летом того же 2011 года Citrix изъял из продажи этот продукт, негласно озвучив теорию о включении технологии в следующее поколение Windows Server и System Center. До выхода Windows Server 8 Developer Preview почти никакой информации о Site Recovery в открытом доступе не было. Выход Windows Server 8 сначала в статусе Developer Preview, а затем и в Beta, приоткрыл завесу тайны.

Теперь Windows Server имеет в своем составе решение, фактически не зависящее от хранилища, позволяющее осуществлять репликации виртуальных машин с различной степенью частоты и эффективности - периодически, асинхронно и с переходом по отказу.

Архитектурно Hyper-V Replica (HVR) состоит из следующих компонентов:

  •          Replication Engine. Как уже понятно из названия, это "ядро" технологии, управляющее конфигурацией репликации, обрабатывающее первоначальную и разностную репликации, отслеживающее события репликациии и при необходимости приостанавливающее и возобновляющее процесс переноса данных
  •          Change Tracking. Модуль, отслеживающий операции чтения на уровне виртуальной машины на первичном узле или кластере, вне зависимости от типа хранилища ВМ (DAS, SAN LUN, папка SMB на файловом сервере или CSV)
  •          Network Module. Компонент с говорящим названием призван обеспечить безопасный канал связи между первичным и принимающим узлами, строящий соединение с использованием HTTP/HTTPS с возможностью привлечения механизмов шифрования
  •          Hyper-V Replica Broker role. Роль, обеспечивающая прозрачную миграцию в случае размещения виртуальной машины на кластерных узлах совместно с сетевым модулем и компонентов Failover Clustering
  •          Management Experience. Включает в себя следующие компоненты для управления процессами репликации:
    •    Интерфейс Hyper-V Manager
    •    Интерфейс Failover Cluster
    •    Scripting - управление функциональностью реплик с помощью PowerShell
    •    Hyper-V Replica APIs - интерфейс может использоваться сторонними управляющими приложениями
    •    Remote Management - включает в себя средства удаленного управления (RSAT)

Несомненным плюсом технологии является и то, что нахождение основного сервера (кластера) и сервера-реплики (кластера) в одном домене или рабочей группе не является обязательным. В этом ключе стоит затронуть некоторые вопросы безопасности. Безопасность Hyper-V Replica реализована на следующих уровнях:

  •          Используется новая модель авторизации – при установке роли Hyper-V создается локальная группа Hyper-V Administrators, включающая в себя локальных администраторов сервера по умолчанию
  •          Администраторы могут настроить серверы-реплики на принятие входящих соединений только от определенных серверов
  •          Администраторы могут настроить на правила брандмауэра серверов-реплик на принятие входящих соединений по настраиваемому порту
  •          Взаимная аутентификация может осуществляться на основе встроенной проверки подлинности между доверенными доменами. Во внедоменной инфраструктуре могут (и должны) использоваться сертификаты.

 Существует несколько сценариев развертывания, в которорых используется HVR:

  •          Основной офис и филиал
  •          Датацентр компании
  •          Датацентр провайдера
  •          Офис клиента и датацентр провайдера

 Первая схема, на мой взгляд, будет наиболее востребована, поэтому остановимся на ней подробнее в этой и последующих заметках

Основной офис и филиал (резервный ЦОД)

Технически это выглядит как две площадки с узлами Hyper-V (как кластерными, так и не объединенными в кластер). Disaster Recovery план должен включать следующие шаги:

  •          Развертывание и конфигурация первичного и вторичного узлов (кластеров) в головном и резервном ЦОД соотвественно
  •          Создание и конфигурация репликационных отношений между площадками
  •          Тестирование планового перехода по отказу (инициированного администратором)

Что происходит в этот момент на узлах Hyper-V? Теоретически (практическая часть будет затронута в отдельной заметке), после установления транспортного канала между основным сервером и репликой происходит создание копии виртуальной машины на резервной площадке (по умолчанию без настроенной виртуальной сети). Далее в действие вступает механизм Delta Replication – каждые 5 минут на реплицируемый сервер передаются зашифрованные файлы, измененные за прошедшее время, частями по 2 МБ, расшифровываются, сравниваются с имеющимися данными, серверы на основной площадке уведомляются о завершении передачи очередной дельты. Таким образом копия машины отстаёт от оригинальной не более чем на пять минут. Важно понимать, реплицируются лишь дисковые изменения, память машины не затрагивается. Копия машины в резервной площадке находится в выключенном состоянии.

В следующей статье заострим внимание на практической части настройки Hyper-V Replica.

Comments

  • Anonymous
    January 01, 2003
    Да. По сути, для HRV не имеет значения, как подключено место хранения виртуальных машин. В ближайшее время будет опубликована заметка с практической частью развертывания Hyper-V Replica, там этот момент постараюсь затронуть.

  • Anonymous
    January 01, 2003
    Фича Windows Server Backup в Server 8 позволяет выполнять как раз поблочное инкрементальное резервной копирование виртуальных машин в ключени применения к Hyper-V. Более того, этот API является открытым и, возможно, будет использоваться в продуктах других вендоров. Думаю, что в будущих заметках эти возможности будут упомянуты вследствие такого интереса -) Кстати, Владимир, используйте LiveID при размещении комментариев, в таком случае они не требуют премодерации.

  • Anonymous
    January 01, 2003
    Илья, я попробую решить это на выходных. К сожалению, сейчас меняю работу и пару дней без доступа к архиву базы знаний.

  • Anonymous
    January 01, 2003
    Будет вторая часть, будет. К Техэду точно -) В принципе, если возникают какие-то сложности с самостоятельной настройкой - пишите сюда или в ветку по виртуализации на Технете, постараемся помочь по мере возможностей.

  • Anonymous
    January 01, 2003
    Добавлю про домены. Для Hyper-V Replica членство в домене вообще не обязательно, если вы используете репликацию между некластерными узлами (для кластеров, естественно, нужен домен). Непосредственно во время работы репликации коммуникаций с контроллером домена не производится.

  • Anonymous
    January 01, 2003
    Владимир, спасибо за фидбэк. Change Tracking отслеживает изменения жизненного цикла на уровне виртуальной машины (полагаю, не без участия компонента интеграции Data Exchange), расположенной на основном сервере с целью внесения в передаваемые данные в процессе Delta Replication. Предположу опять же, что API этого модуля включен в Hyper-V Replica APIs. В принципе, можно будет уточнить у разработчиков, если Вы озвучите, для какого сценария Вам это нужно.

  • Anonymous
    January 01, 2003
    Добрый день! Возникли трудности при настройке репликации ВМ. Тестовый стенд такой : два отказоустойчивых кластера Hyper-V на базе ОС WS 2012 DTC. На одном и другом кластере развёрнуты роли Replication Brokers со своими IP-адресами. На узлах второго кластера в настройках Hyper-V выставлен параметр: Enable this computer as a Replica Server. Профили сетевых соединений на каждом узле каждого кластера выключены. На первом кластере есть ВМ, которые я хочу задублировать с помощью реплики на втором кластер. Для этого:

  1. захожу в оснастку Failover Cluster Mgmt.
  2. В свойствах ВМ выбираю Replication -> Enable Replication.
  3. Прохожу по шагам Мастера репликации.
  4. На самом заключительном этапе нажимаю кнопку Finish и у меня появляется окно с ошибкой соджержащей следующий текст: Hyper-V failed to enable replication. Failed to perform this operation. The virtual machine is not in a valid state to perform this operation. Operation aborted: 0x8004004. Также иногда появляется сообщение: 0x800700AA The requested resource is in use. Куда копать?

  • Anonymous
    March 12, 2012
    Денис, спасибо за интересную статью! Подскажи пожалуйста, что это за компонент "Change Tracking Module" и есть ли открытый API для его использования? Спасибо!

  • Anonymous
    March 12, 2012
    Incremental/Differential Backup с испльзованием CBT-like технологии (получение списка изменений с момента последнего бэкапа). Спасибо!

  • Anonymous
    March 16, 2012
    А возможно осуществлять репликацию между двумя хостами, не имеющими подключения к NASSAN, а имеющие только DAS диски? Т.е. просто между двумя отдельными серверами возможно даже размещенными в одном месте?

  • Anonymous
    August 07, 2012
    а где же часть вторая?...ждем-с....

  • Anonymous
    January 26, 2014

На самом заключительном этапе нажимаю кнопку Finish и у меня появляется окно с ошибкой соджержащей следующий текст:>Hyper-V failed to enable replication.>Failed to perform this operation. The virtual machine is not in a valid state to perform this operation.>Operation aborted: 0x8004004.Это сообщение появляется если оба сервера настроены как Replica Server или на сервере-реплике уже есть виртуалка с идентификатором SID как у той для которой необходимо создать реплику.

  • Anonymous
    October 11, 2015
    Помогите настроить соединение между двумя серверами, иемющими статические ИП, и не входящие в одну сеть (не в домене). При попытке подключение по 80 порту получаю ошибку "Соединение было сброшено". Расскажите поэтапно как сгенерить сертификат для соединения по 443 порту. Спасибо
  • Anonymous
    October 13, 2015
    http://blogs.technet.com/b/virtualization/archive/2013/04/13/hyper-v-replica-certificate-based-authentication-makecert.aspx - достаточно подробное описание того, как это сделать с помощью утилиты makecert.