В 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 МБ, расшифровываются, сравниваются с имеющимися данными, серверы на основной площадке уведомляются о завершении передачи очередной дельты. Таким образом копия машины отстаёт от оригинальной не более чем на пять минут. Важно понимать, реплицируются лишь дисковые изменения, память машины не затрагивается. Копия машины в резервной площадке находится в выключенном состоянии.