Заметки о Windows и других программных продуктах Microsoft...

Технология Hyper-V Replica в Windows Server 2012 (часть 1)

Технология Hyper-V Replica в Windows Server 2012 (часть 1)

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

Суть Hyper-V Replica (HVR) состоит в наличии регулярно обновляемой копии (реплики) виртуальной машины. Технически это выглядит как две площадки с серверами Hyper-V — основная (primary site) и резервная (replica site). При возникновении проблем с основной площадкой (потоп, пожар, отключение электричества или ядерная война) реплику можно активировать, что дает возможность оперативно восстановить работоспособность виртуальной машины в случае аварии.

Hyper-V Replica

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

Архитектура

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

Replication Engine — как следует из названия, это основной «движок» технологии. Он управляет конфигурацией HVR и обрабатывает операции репликации: первоначальную репликацию (Initial Replication), разностную репликацию (Delta Replication) и отработку отказа (Failover). Также Replication Engine отслеживает события, связаные с перемещением виртуальных машин и дисковых хранилищ, и предпринимает необходимые действия (приостанавливает процесс репликации во время миграции и возобновляет его по окончании);
Change Tracking Module — модуль, отслеживающий на основном узле операции записи, производимые на уровне виртуальной машины. Работа модуля не зависит от типа хранилища, в котором хранятся диски виртуальной машины, он может работать с любыми хранилищами (локальные диски, Direct Attached Storage (DAS), SAN LUN, Cluster Shared Volume (CSV) или файловая шара SMB);
Network Module — компонент, обеспечивающий безопасный и эффективный (по умолчанию осуществляется сжатие данных) канал связи между узлами. Соединение создается с использованием HTTP/HTTPS, поддерживается аутентификация с помощью цифровых сертификатов и шифрование трафика репликации (опционально).
Hyper-V Replica Broker — роль, обеспечивающая корректную работу репликации в случае размещения виртуальной машины на узле кластера. Работает совместно с сетевым модулем и службой Failover Clustering. Брокер запрашивает в базе данных кластера, какой узел отвечает за обработку данных репликации и перенаправляет необходимые данные на нужный узел. Это обеспечивает репликацию в случае миграции ВМ на другой узел кластера.
Management Experience — инструменты для управления репликацией. Сюда входят следующие компоненты:

• Hyper-V Manager UI — интерфейс Hyper-V Manager;
• Failover Cluster Manager UI — интерфейс Failover Cluster;
• Scripting — модуль Hyper-V для управления репликацией с помощью PowerShell;
• Hyper-V Replica APIs — программный интерфейс, может использоваться сторонними управляющими приложениями;
• Remote Management — средства удаленного управления (RSAT).

архитектура Hyper-V Replica

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

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

• Используется новая упрощенная модель авторизации. При установке на сервер роли Hyper-V создается локальная группа Hyper-V Administrators, которая может использоваться для управления репликацией наряду с локальными администраторами сервера;
• Серверы-реплики можно настроить на принятие входящих соединений только от определенных серверов. Ограничения могут быть как по FQDN, так и по доменному суффиксу (напр. *.contoso.com);
• Можно настроить правила брандмауэра серверов-реплик на принятие входящих соединений только по определенному порту;
• В доменной среде взаимная аутентификация осуществляется на основе встроенной проверки подлинности (Kerberos) между доверенными доменами. Во внедоменной инфраструктуре должны использоваться сертификаты.

Примечание. По умолчанию трафик репликации не шифруется. Хотя в Kerberos и есть механизм шифрования, HVR его не задействует. Поэтому, если требуется шифрование, необходимо использовать аутентификацию на основе сертификатов.

Принцип работы

Сначала между основным сервером и репликой устанавливается соединение и производится первоначальная репликация (Initial Replication), в ходе которой на резервной площадке создается реплика виртуальной машины. Реплика находится в выключеном состоянии и по умолчанию не подключена к виртуальной сети.

Затем в дело вступает механизм Delta Replication.  На основном узле все изменения, происходящие с VHD-дисками соответствующей ВМ отслеживаются и записываются в лог репликации (Hyper-V Replica Log file, HRL). Это файл с расширением .hrl, находящийся в той же директории, что и VHD. Каждому VHD ставится в соответствие свой HRL-файл, каждая операция записи в виртуальной машине соответствует записи на VHD и записи в HRL.

Примечание. Реплицируются лишь дисковые изменения, состояние памяти ВМ не затрагивается.

Раз в 5 минут изменения передаются на сервер-реплику. Для этого текущий HRL останавливается и отправляется на резервный сервер, создается новый HRL и все изменения пишутся уже в него. Переданные изменения применяются к VHD-диску реплики, после чего на основной сервер приходит уведомление об успешной операции и процесс передачи начинается по новой. При таком подходе каждый раз передаются только последние изменения. Передаваемые данные разбиваются на части размером 2 MB и сжимаются, а если используется HTTPS, то еще и шифруются.

Периодичность передачи данных составляет 5 минут, изменить ее нельзя. Таким образом, в нормальном состоянии копия машины отстаёт от оригинала не более чем на пять минут. Если же в течение 5 минут не удалось передать изменения, то в состоянии репликации появится предупреждение. Попытки передать изменения будут продолжаться еще 25 минут, а затем репликация остановится и перейдет в аварийное состояние. После этого для восстановления работы репликации потребуется вмешательство администратора.

Вот так в общих чертах выглядит технология Hyper-V Replica в Windows Server 2012. Более подробно о настройке репликации я расскажу во второй части статьи.

 
 
Комментарии
Eugene Leitan

Добрый вечер, Кирилл!
Большое спасибо за статью!!!

Но появилось несколько вопросов. Возможно вы с ними сталкивались.
1) Можно ли настроить хранение VHD(-vhdx) данных на разных дисках?
2) Любое приложение с данными (SQL, Exchange, Sharepoint) можно в технологии репликации?

Как вариант — вручную скопировать виртуальную машину, которую планируется реплицировать, разместив ее на нужном диске. Затем при настройке репликации указать использовать существующую виртуальную машину в качестве первоначальной копии.
По поводу приложений — в принципе можно, для этого надо использовать репликацию с помощью VSS.

Eugene Leitan

Кирилл, дообрый день!
Назрел еще один вопрос по репликации 🙂

Как вы решили вопрос разделения трафика репликации?

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

Eugene Leitan

нашел вот такую статью
http://wshandpowershell.blogspot.ru/2013/08/hyper-v-2012-replica-using-dedicated.html

только не пойму как трафик реплики «понимает» по какому адресу ему идти…

Вариант с использованием DNS можно использовать, но по мне это не очень удобное решение. А так все просто — в Hyper-V указываем имя сервера-реплики, а в DNS (или в hosts) прописываем соответствие этого имени нужному IP-адресу. Имя сервера-реплики разрешается в этот IP и трафик репликации идет на этот IP через нужный интерфейс.

It uses the good network link thanks to the host file. i am not sure you can use DNS to create another A record to the replication IP NIC, because kerberos authentication would probably not like it.

Eugene Leitan

Автоматический режим перехода рассматривали?
пока нашел только вот это
http://blogs.technet.com/b/keithmayer/archive/2012/10/05/automate-disaster-recovery-plan-with-windows-server-2012-hyper-v-replica-and-powershell-3-0.aspx

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

Eugene Leitan

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

Ну можно например организовать iSCSI хранилище на базе Windows Server 2012. А вообще все зависит от конкретной ситуации. Если действительно нужна высокая доступность ВМ, то придется раскошелится на СХД. Если же нет, то достаточно нормального мониторинга и ручного переключения. Вопрос как всегда упирается в финансы 🙂

Eugene Leitan

«Вопрос как всегда упирается в финансы»
с этим я соглашусь 🙂

А конфигрурация проста: два сервера с локальными ресурсами, связанные между собой двумя коммутаторами.

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

Игорь

Правильней сказать, что Hyper-V Replica является механизмом катастрофоустойчивости и оперативного резервного копирования и восстановления, поскольку никакой высокой доступности (failover) не предполагается, поскольку реплика не запустится автоматом, если ляжет основная ВМ.

Сергей

Подскажите, пожалуйста, как изменить настройки реплики, если я расширил диски на источнике реплики.

А зачем менять настройки? По идее отработает и так.

Антон

Здравствуйте. Подскажите пожалуйста, есть у данного механизма механизм проверки доступности основного узла и отказ от операции реплики в случае если основная ВМ подвисла, не буде ли тупо производиться реплицирование испорченной ВМ?

Если оригинал недоступен, то репликация просто встанет. Если же исходная машина в принципе работает, но с ошибками, то есть шанс среплицировать эти ошибки.

Leave a Reply to Kirill