Возможно, это странно, но в первые дни на работе после новогодних каникул, когда все упавшее за праздники уже успешно возвращено к жизни, у многих возникает желание как-то упорядочить информацию в своей голове, дабы привести её к систематизированному виду. Хорошим катализатором для этого процесса является осознание факта, что вроде и обладаешь багажом знаний, но бабушке с улицы или шестилетнему ребёнку в простых словах этот багаж ну никак не получится объяснить. Ибо, как гласит народная мудрость, не смог объяснить ребёнку – значит, сам не знаешь. Да и вообще, дефрагментация информации ещё никому не вредила.
Но у нас не курс прикладной психологии, поэтому сегодня я просто изложу в систематизированном виде набора пикселей максимальное количество полезной информации о функции репликации виртуальных машин в среде гипервизора Hyper-V на примере текущей версии Windows Server 2012 R2.
Итак, на что я хочу потратить примерно час вашего времени:
- Надо понять, зачем вообще нужна репликация в условиях современного мира
- Составить чек лист из очевидных и не очень пунктов, предшествующих настройке серверов
- Как правильно и быстро настроить репликацию встроенными средствами. Достаточно подробно, но без воды
- Несколько советов по оптимизации процесса репликации.
- Ни слова про продукты Veeam или других вендоров.
Акт первый. Обзорный.
Значение термина “репликация виртуальных машин” ничем не отличается от общепринятого в IT значения слова “репликация”: на стороннем хосте создаётся и поддерживается копия ВМ с основного хоста.
Давайте сразу договоримся: репликация — это не бекап! Как снапшоты не бекап, рейды не бекап, и вообще ничего не бекап кроме бекапа,
ибо если бы дедушка был бабушкой
…
Но лучше все же на всякий случай поясню, почему “не бекап”: в случае выхода из строя основной машины всегда можно без задержки включить реплику, но если выход из строя был спровоцирован не сиюминутной ошибкой, а комплексом накопленных проблем на уровне ОС или приложений, то все они будут успешно отражены на реплике, и ничего хорошего у вас не получится. Бесчисленно количество случаев, когда после включения реплицированной ВМ она работает несколько минут и умирает вслед за своим родителем с теми же симптомами.
Таким образом, репликация — это прекрасный инструмент для расширения вашего плана катастрофоустойчивости, позволяющий вернуть все ваши сервисы в боевое состояние с минимальной задержкой во времени, но нельзя на него перекладывать всю ответственность, т.к. ничто не совершенно и везде есть минусы.
Репликацию виртуальной машины Hyper-V как процесс возможно осуществить тремя путями:
- Встроенными средствами гипервизора.
- С помощью стороннего софта. Тут интересный факт заключен в игнорировании этой функции некоторыми вендорами без видимых причин.
- С помощью средств SAN. Несомненно, метод самый интересный, быстрый и прочая…, но крайне дорогой.
Как было оговорено в самом начале, мы будем рассматривать только первый пункт — а именно репликацию Hyper-V машин встроенными средствами Windows Server 2012 R2. Позволю себе заметить, что именно R2 т.к. между первым и вторым релизом лежит функциональная пропасть, и использовать не R2 версию гипервизора в продакшн среде практически моветон.
Итак, что же нам предлагает Microsoft из коробки:
- Репликация с помощью асинхронного копирования изменённых данных с родительской машины на реплицированную. Асинхронное – значит, данные передаются не немедленно после изменения оригинальных данных, а через некоторые промежутки времени, что позволяет не “перенапрягать” машину-источник и канал передачи. В данный момент минимальный период репликации равен 30 секундам.
- Для репликации Hyper-V машин не надо иметь каких-то специальных разделяемых хранилищ или соблюдать единообразие оборудования для хранения на источнике и приёмнике
- Всё, что может быть виртуализовано, можно реплицировать.
- Репликация происходит по обычным IP сетям и, в случае необходимости, трафик может быть зашифрован.
- В Hyper-V репликация возможна как между отдельными хостами, так и между кластерами. И даже смешанный вариант возможен без ограничений.
- Хосты, между которыми происходит репликация, могут находиться где угодно, в каких угодно сетях и принадлежать разным доменам.
Чек-лист, пока не стало поздно
- Пункт первый и очевидный, но часто упускаемый: удостоверьтесь, что сервер, на который пойдёт репликация, имеет Hyper-V-совместимое железо. Инженерам свойственно запускать всё, что угодно, на чём угодно, но поверьте, что это не тот случай. Абсолютно не тот. Аппаратная поддержка виртуализации строго должна быть в обязательном порядке.
- Второй очевидный пункт: рассчитайте, сколько вам понадобится места на принимающем хранилище, и проверьте скорость его работы. Снимая с далёкой полки хранилку эпохи динозавров, вы рискуете увидеть общую скорость передачи данных на уровне той же эпохи, несмотря на все ваши сетевые гигабиты.
- Следствие предыдущего пункта: на основании периода репликации усреднённой виртуальной машины прикиньте, сколько будет весить каждая точка репликации и сколько таких точек вы можете себе позволить. Максимальное количество, доступное на данный момент — это 24 точки отката.
- Если планируется реплицировать машины, являющиеся частью Hyper-V кластера, то надо установить и настроить роль Replica Broker в кластере. Если на принимающей стороне есть кластер – надо повторить.
- Проверьте настройки фаерволов и роутинг на всем маршруте между хостами. Если за сеть отвечаете не вы, то найдите вашего сетевика и пытайте его калёным железом, пока он не выстроит кратчайший и быстрейших маршрут между хостами. С фаерволами всё проще: нам нужен 80 порт для Kerberos over HTTP и 443 для certificate-based over HTTPS. Само собой, порты можно поменять в процессе настройки.
- Если вы планируете шифровать трафик между хостами, то вам понадобятся сертификаты, и нужно заранее разложить их по всем заинтересованным серверам. И не побрезгуйте проверить сертификаты на срок годности, а центры сертификации внести в доверенные, если используете самоподписные.
- Проинспектируйте все ваши виртуальные машины на предмет используемых VHD. Имеете все шансы обнаружить диски, которые совершенно не надо реплицировать, что сэкономит вам время и деньги.
- Составьте список приложений, для которых важна консистентность данных. Проверьте здоровье VSS системы как на хостах, так и внутри гостевых ОС. Если ваши приложения не используют VSS (например, не самые старые версии Oracle), им придётся уделить отдельное внимание.
- Продумайте время для первого прохода репликации. При первом прогоне через сеть будет передана вся машина, — и, естественно, хочется это сделать вне рабочего времени. Если принимающий хост находится за границами локальной сети, вы рискуете не успеть закончить передачу за ночь или выходные и утром получить сильно загруженный канал связи и очень загруженный хост. Как избежать такой ситуации, будет написано чуть ниже.
- Учтите, что репликация в Hyper-V возможна не только между двумя хостами, но и с использованием промежуточных серверов. Этакая многоходовая репликация.
- Проанализируйте ваш текущий план резервного копирования на предмет совместимости с планом репликации. Думаю, никому не понравится ситуация, когда во время бекапа запустится ещё и репликация. Ваш хост вполне может не простить вам такую нагрузку. Так же стоит ответить на вопрос, что будет если вы восстановите машину из бекапа: нужна ли вам реплика в виде машины до аварии, или надо скорее привести её к консистентному виду.
Считаю, что так же справедливо будет упомянуть инструмент от Microsoft, позволяющий с определённой долей погрешности подсчитать необходимые для репликации отдельно взятой виртуальной машины ресурсы. Называется он Capacity Planner for Hyper-V Replica Конечно, вы не получите точное количество IOPS, нагрузку на сеть и процессор, но как оценочный инструмент он весьма неплох и позволит проанализировать вашу инфраструктуру заранее.
При запуске вас попросят указать основной сервер, сервер для репликации, машины, которые предстоит обрабатывать и время проведения измерений. Рекомендую изменить установленные по умолчанию 30 минут в сторону увеличения до часа. И, конечно, оптимальное время для запуска — это самый разгар рабочего дня. Собранными данными можно очень здорово пугать начальство и просить денег на новые
игруш
…железки.
Акт второй. Настроечный.
И вот настал ответственный момент! Сертификаты есть, сеть настроена, везде работает Hyper-V роль, не забыты инструменты управления, и мы можем приступать.
Первым делом надо разрешить нашему хосту выступать в качестве сервера репликации и принимать машины на борт. Делается это через окно стандартных настроек Hyper-V:
Все настройки прозрачные, но я хочу немного заострить внимание на нижней секции Authorization and storage. Это не критично, но очень рекомендую разрешать репликацию только с определёнными хостами или группами хостов. Не часто, но бывают случаи, когда по ошибке или от незнания запускается ошибочная репликация — и хорошо, если это запасной хост, а может случиться забивание хранилища боевого со всеми последующими развлечениями. Разрешать всё подряд — удел лабораторий для тестировщиков и разработчиков. Ну или просто смелых людей =)
Зовём брокера
Поскольку в самом начале мы договорились, что инфраструктура у нас как у взрослых (т.е. настроен и успешно работает кластер), то нам необходимо включить роль брокера реплик Hyper-V. Если же кластера у вас нет, то можете смело пропускать этот параграф.
Процедура активации проста и включает в себя 5 кнопок Next и одну Finish. Объяснять тут нечего, поэтому просто идём в мастер управления кластером, выбираем Configure Role и проходим мастера, не забыв дать NETBIOS совместимое имя и указать IP.
Небольшой хинт для тех, кто сначала читает документацию, а потом делает, хотя настоящие инженеры так не поступают, — всё описанное в предыдущем параграфе можно сделать непосредственно из брокера лишь с той разницей, что настройки будут применены сразу на весь кластер и не придётся вручную разрешать репликацию на каждом сервере. Как видите, выглядит всё точно так же:
И небольшое пояснение о роли брокера в процессе репликации — при репликации машин, не участвующих в High Availability кластере, брокер никак не задействуется. Но когда речь заходит про кластеризованные машины, он полностью забирает на себя управление всеми процессами, связанными с репликацией и кластеризацией, не давая кластеру принять неверное решение о доступности машин. Поэтому золотое правило — с этого момента
все
действия вы должны делать только через консоль Failover Cluster Manager, иначе вы рискуете остаться без кластера. Даже если на боевой хост упадёт метеорит, худшее, что вы можете сделать в этой ситуации — это включить репличную машину через Hyper-V Manager.
Первый пошёл
Теперь наконец-то мы действительно готовы реплицировать нашу самую первую машину. Как и всё в Windows, делать это мы будем через правую кнопку мыши:
Дальше открывается довольно стандартный мастер настроек, где на первых шагах нас спрашивают имя сервера (куда будет реплицирована машина) и просят уточнить настройки подключения. Вернее, если хосты находятся в одном домене, то всё будет заполнено без нашего участия, а вот если сервера не знакомы, да ещё надо зашифровать трафик, то придётся все параметры указать вручную. Единственная галочка, заслуживающая внимания на этом шаге — “сжимать передаваемые данные”. Тут мы обращаемся к стадии планирования и смотрим, что нам важнее: сжимать информацию и скорее закончить передачу данных (что неизбежно вызовет дополнительную нагрузку на хосты), или нам не важен объём и длительность передачи, т.к. в приоритете производительность хоста. Два скучных скриншота:
На следующем шаге необходимо выбрать диски, которые будут участвовать в репликации. В конце статьи, когда пойдёт речь про общую оптимизацию, я приведу несколько советов, а пока стоит запомнить одну деталь – диск, не отмеченный для репликации, будет полностью отсутствовать на принимающей стороне, т.е. он исключается из конфигурации виртуальной машины. Если без этого диска машина не может функционировать, но на нём хранится нечто неважное (вроде временных файлов), то просто создайте заново этот диск на реплицированной машине.
Затем снова обращаемся к этапу планирования и выставляем выбранный период репликации. Если по недоразумению вы всё ещё используете Server 2012, то вас даже не спросят, а просто выставят значение в 5 минут. Со временем Microsoft пришли к выводу, что такое поведение не совсем правильное, и в Server 2012 R2 добавили возможность выбора из 30 секунд, 5 и 15 минут. Не фонтан, конечно, но лучше, чем ничего.
И будьте очень осторожны, выбирая 30-ти секундный интервал — вам понадобится действительно очень сильный хост, с очень быстрой сетью и очень быстрым хранилищем.
Следующий ответственный шаг – указываем, сколько точек восстановления мы будем хранить. Здесь же указываем, с какой периодичностью будут создаваться VSS снапшоты. В принципе, можно прекрасно обходиться и без них, но тогда никто не сможет вам гарантировать консистентность данных со всеми вытекающим последствиями, особенно если речь идёт о приложениях, для которых она критична.
Пример на скриншоте можно интерпретировать на русский таким образом — нам необходимо создавать точку восстановления каждый час, хранить её 24 часа (это максимальное значение) и раз в 4 часа создавать VSS снапшот. Соглашусь с тем, что не самая прозрачная и удобная для понимания конструкция, но, что есть — с тем и работаем.
Следом идёт очень полезный пункт для тех, у кого ну очень большие машины или просто нет возможности передавать большие объёмы данных по сети. Как мы помним, при первом запуске с хоста на хост должен быть передан весь объём реплицируемой машины, и нам на выбор предлагается аж три варианта, как мы можем это сделать:
- Непосредственно по сети с указанием времени старта процесса. Вариант по умолчанию, дополнительных комментариев не требующий.
- Самый интересный, на мой взгляд, вариант. Если его выбрать, в первый момент времени на передающем хосте будет создана и сохранена в отдельную папку машина-клон. Папка будет наименована по шаблону <VMname_GUID>. Эта же машина будет реплицирована в виде пустышки на принимающей стороне. Далее папку с фейковой машиной можно и нужно скопировать на внешний носитель и перенести ближе ко второму хосту. На втором хосте у машины-пустышки появится новый пункт в меню: Import Initial Replica, т.е. машина будет находиться в ожидании настоящих данных. Нас попросят указать путь к папке с данными, они будут скопированы на место постоянной службы, запустятся внутренние процессы согласования, и на этом проход первой реплики можно считать завершённым. Несомненно, чем дольше диск с данными будет путешествовать между хостами, тем больше будет разница между машинами, поэтому не стоит затягивать это путешествие.
- И третий вариант: когда на принимающей стороне уже есть копия виртуальной машины. Вы просто указываете эту машину, и дальше она будет использована как опорная. Как такое может быть? Например, она была восстановлена из бекапа. Или осталась от предыдущей репликации. Не важно, главное, что эта машина может быть использована как опорная, и по сети будут переданы только несовпадающие данные.
Затем нам предложат окинуть взглядом все введенные настройки и подтвердить своё желание кнопкой Finish. Нам скажут, что всё прошло хорошо, и предложат изменить сетевые настройки для реплик, т.к. по умолчанию они не подключены ни к одной сети (согласен, что это очень неожиданное место для такого предложения), но мне кажется, что лучше вопросы сети объяснить на практических примерах, которые будут дальше, а пока перейдём к расширенной репликации Hyper-V машин.
Расширяем широту наших глубин
Как и многие другие интересные функции, расширенная репликация виртуальных машин появилась только в Windows Server 2012 R2. Расширенная репликация позволяет настраивать репликацию не только по принципу «точка-точка», но и выстраивать целые цепочки, когда после прохода репликации с главного сервера (назовём это основной репликой), запускается процесс репликации реплики (масло масляное, но лучше не скажешь) на третий хост.
И, если многим не совсем ясно, зачем вообще нужна репликация, то наличие возможности создания цепочки репликации, вероятно, способно окончательно запутать даже самых стойких. Однако предлагаю на ваш суд вот такой, не выдуманный пример. Предположим, что у вас достаточно большая компания, с несколькими серверными в одном здании, и вы настраиваете реплицирование каждые 30 секунд, чтобы в случае прорыва канализации и затопления серверов иметь возможность быстро включить копии ваших виртуальных машин с минимальными потерями данных. Это отличная схема, но, к сожалению, она никак не защищает от полного обесточивания здания или трактора, перегрызающего оптические каналы, подходящие к зданию. На такой случай очень хочется иметь копии машин где-то на стороне, обновляемые, пусть и не каждые 30 секунд, но хотя бы раз в 15 минут, чтобы не позволить вам упасть в грязь лицом.
Здесь стоит обозначить правила для проведения расширенной репликации виртуальных машин:
- Частота расширенной репликации не может быть меньше основной т.е. если основная происходит раз в 5 минут, расширенная не может происходить каждые 30 секунд
- Частота создания VSS снепшотов не может быть изменена
- Нельзя поменять список дисков участвующих в репликации
- Однако можно изменить методы аутентификации и способ прохода первой реплики
Мастер настройки расширенной репликации вызывается традиционно правым кликом по реплицированной машине и выбором пункта Extend Replication. Дальнейшая настройка происходит точь-в-точь как в случае с обычной, поэтому рассматривать её отдельно смысла нет.
И вот мы всё успешно настроили, запустили и проверили, поэтому предлагаю перейти к рассмотрению поведения в случае аварии сделав небольшую остановку около сетей.
Немного о сетях
Доподлинно не известно, излишняя это паранойя или нет, но принято все реплики подключать к изолированной сети, которая никак не пересекается с производственной. А зачастую у администратора и вовсе нет выбора, т.к. в дата центре на принимающей стороне используются другие подсети, и у реплики должны быть абсолютно другие сетевые настройки.
И, как мы можем видеть на скриншоте ниже, Hyper-V предоставляет нам возможность указать точные настройки каждого сетевого адаптера на случай аварийного включения. Которое, кстати называется failover, и мы поговорим про него прямо сейчас.
Страшное слово Фейловер
Начну с объяснения термина Failover, т.к. адекватного перевода на язык Пушкина и Толстого ещё не придумали. Фейловером называется процесс правильного (читай управляемого) включения, оперирования и выключения реплицированной машины. Пример неправильного поведения: из панели управления хостом или кластером машина включается по кнопке Start. В этом случае мы получаем гарантированный крах репликации, с последующей настройкой заново, и весь набор весёлых проблем, свойственных наличию двух одинаковых машин в одной инфраструктуре.
Итак, фейловер бывает трёх видов:
- Запланированный
- Тестовый
- Аварийный (или просто фейловер, без приписок)
Плановый фелойвер
Использование запланированного фейловера, подразумевает, что заранее известно о
возможных
проблемах с основным хостом. Например, будут проводиться работы с сетями питания, на вас движется ураган, необходимо выключить хост для обслуживания или рабочие поутру решили поковыряться в земле в опасной близости от подводящих кабельных трасс.
В данном варианте присутствует небольшой простой сервисов, равный времени выключения основной машины и загрузке реплики, но то, что переключение производится планово, дает возможность подобрать наиболее удобное для всех время.
Важный момент — репликация может быть продолжена в обратном режиме, т.е. все изменения, сделанные на стороне реплики, при её выключении будут переданы на основную машину. Это позволяет полностью исключить потерю данных.
Итак, как происходит запланированный фейловер:
- Выключаем основную виртуальную машину. Сделать это можно только вручную, чтобы избежать ошибочного выключения. Пока машина не будет полностью выключена, мастер фейловера будет показывать соответствующую ошибку.
- Там же, на основном хосте, кликаем по выключенной машине и выбираем Planned Failover
-
- По умолчанию пункт Reverse the replication direction after failover, обеспечивающий обратную репликацию, не отмечен, и, если вам не хочется терять данные, накопленные за время работы машины в режиме фейловера, стоит отметить этот пункт. Важное замечание — на основном хосте должно быть установлено разрешение о принятии реплик, о чём говорилось в самом начале, иначе данные просто не будут приняты.
-
Запускаем процесс фейловера и проверяем сетевую доступность поднятой машины для пользователей. Здесь самые частые ошибки — это неверно указанный VLAN и отсутствие соответствующей DNS записи. Ни то, ни другое мастер фейловера не проверяет, оставляя это на откуп администратору.
Самое забавное в этой ситуации — это то, как происходит обратное переключение: нам надо повторить фейловер, но на этот раз со стороны второго хоста, т.е. надо выключить на нём реплику и произвести её плановый фейловер. Решение более чем странное, но что есть — то есть.
Тестовый фейловер
Именно тот случай, когда название соответствует функционалу. Реплики, как и бекапы, хочется проверять, чтобы спать чуть более спокойно. А лучший способ проверить реплику — это включить её. На первый взгляд может показаться, что это другое название запланированного фейловера, однако это не так.
При выполнении тестового фейловера на стороне реплики создаётся временная машина, на которой можно выполнять разнообразные тесты. Например, проверить телнетом набор портов, и в случае утвердительного ответа быть уверенным, что сервисы на этих портах запущены успешно. Один нюанс — по умолчанию виртуальная машина в тестовом фейловере запускается не подключенной к сети. Поэтому первым шагом указываем общие сетевые настройки на случай фейловера, пере-открываем мастер и видим новый пункт меню:
Или более интересный вариант: посмотреть, как поведёт себя критичное для бизнес процессов приложение после установки нового патча, не забыв вывести машину в специально подготовленную изолированную сеть.
Само собой, тестовый фейловер надо запускать на стороне реплики. Процесс полностью повторяет плановый фейловер, с той лишь разницей, что после выполнения всех необходимых процедур его необходимо остановить. Иначе машина так и будет работать, пока рано или поздно не разрастётся на весь диск.
Аварийный фейловер
Здесь есть только одно золотое правило — никогда не запускать этот фейловер, кроме тех случаев, когда это действительно необходимо, т.е. если нет аварийной ситуации — пользуйтесь исключительно тестовым и плановым вариантами. Если необходимо просто посмотреть, как это работает, написать документацию для инженеров и т.п., то проделайте все шаги исключительно в тестовой среде.
При выполнении фейловера единственная опция, которая будет вам доступна — это выбор необходимой точки восстановления. Дальше машина будет запущена несмотря ни на что. Если при выполнении планового фейловера мастер не даст вам выстрелить в ногу и включить две одинаковых машины (т.е. он будет ждать момента полного выключения основной машины), то в этом случае вы получите всего лишь очень чёткое, но ненавязчивое предупреждение.
В качестве последнего барьера перед точкой невозврата вам необходимо будет подтвердить завершение фейловера с помощью Complete-VMFailover командлета PowerShell. Все дополнительные точки восстановления будут удалены, а процесс фейловера логически завершён.
Best Practice
Прежде чем перейти к общим советам, я хочу затронуть тему частной оптимизации для конкретной инфраструктуры. Единственным источником информации, на основе которой можно будет делать далеко идущие выводы, само собой, служит всеобъемлющий мониторинг. Можно спорить, лучшим или нет является Operation Manager из пакета System Center. Но, поскольку в начале мы договорились не рассматривать сторонний софт, да ещё за немалые деньги, этот инструмент мы пропустим.
Итак, первое средство из коробки, которое встречает нас при каждой загрузке Windows Server, носит невзрачное название Best Practice Analyzer (оно находится в самом низу Server Manager консоли).
Запуская время от времени BPA, можно получить действительно ценные советы относительно настроек хоста, которые делаются на основе накопленных событий и мониторинга производительности различных подсистем вашего конкретного хоста и информации накопленной самой Microsoft.
По неизвестным мне причинам события для Hyper-V Replica не вынесены в отдельную подгруппу и, хотя и имеют свои уникальные номера, но идут под грифом Hyper-V. Правила, относящиеся к репликам, идут под номерами от 37 до 54 включительно.
Следующим по порядку идёт непосредственно консоль Hyper-V Manager. Стоит добавить в стандартное окно со списком машин дополнительную колонку Replication Health. Как нетрудно догадаться, в этой колонке будет отображено текущее состояние репликации.
И через меню Replication можно вызвать весьма подробную справку о состоянии машины:
А теперь перейдём к общим советам:
- Не бойтесь провести за планированием и тестами лишний день
- По возможности выносите файл подкачки виртуальной машины на отдельный VHDX и исключайте его из репликации. Нет абсолютно никакого резона для его передачи.
- Если вы решили провести апгрейд серверов до 2012 R2, то сначала нужно выполнить апгрейд реплики, а затем основного сервера — и никогда наоборот. Репликация не поддерживает обратную совместимость.
- Если вы изменили размер диска у машины источника (стало возможным в Server 2012 R2), необходимо так же изменить диск у реплики. Автоматически это не происходит.
- Используйте Network Throttling, если нет возможности использовать выделенную сеть для репликации, т.к. процесс репликации способен полностью захватить всю полосу пропускания канала связи. В таких случаях QoS наше всё. На мой взгляд, проще всего настроить ограничения для процесса vmms.exe или для указанных портов
Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку
Рассмотрим процесс настройки репликации между серверами на базе Windows Server 2019 без доменной среды.
Имеется вот такая схема работы серверов.
Задача настроить реплицию между Server1 и Server2. Таким образом VM_1, VM_2 у нас будет на Server2, а VM_3 на Server1.
Надеюсь, всё понятно… ? В общем, чтобы было вот так.
Будем производить настройку репликации с помощи само подписанных сертификатов через PowerShell.
Содержание
Требования
Есть вещи на которые стоит обратить внимание при настройке репликации.
- Нужная стабильная и широкая сетевая полоса, если виртуальные машины «толстые», то первоначальная версия будет передаваться долго и повесит весь сервер и сеть;
- Место на сервере-реплике должно быть не меньше, чем на исходном;
- У виртуальной машины, которую мы реплицируем не должно быть контрольных точек;
Настраиваем репликацию
Добавляем DNS-суффиксы
Открываем Панель управления системой. Переходим Изменить параметры/Изменить/Дополнительно/ и добавляем DNS-суффикс.
В моём примере будет «adel.local».
После чего перезагружаем сервер.
Аналогично делаем на сервере репликации.
Отключаем проверку на отзыв сертификата
Нам необходимо через реестр отключить проверку на отзыв сертификата. На обоих серверах.
Иначе высыпается ошибка о невозможности проверить сертификат на отзыв.
Открываем командную строчку от имени администратора и прописываем:
|
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication” /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f |
Изменяем файл hosts
Теперь нам необходимо изменить файл хостов чтобы Server1 и Server2 всегда видели друг друга по имени. Этот шаг опционален. Я его применяю для того, чтобы никакие проблемы связанные с DNS внутри нашей сети не помешала нашей репликации. Типа такой:
Поэтому открываем блокнот от имени администратора и переходим по пути C:\windows\system32\drivers\etc\hosts, добавляем две записи: ip-адрес исходного сервера и его имя с dns-суффиксом и ip-адрес сервера репликации с его имением и суффиксом.
Аналогично делаем на сервере-репликации.
Выпуск сертификатов для каждого сервера
На исходном сервере сделаем оба сертификата. Стандартная команда New-SelfSignedCertificate делает сертификат на год. Но нет желания каждый год обновлять эти сертификаты. Поэтому я нашел в интернете способ выпустить сертификат на 3 года.
И так. Сделаем сертификат для Server1. Открываем PowerShell и запускаем. (Копируем и вставляем по одной строчке);
Необходимо вместо Server1.med.local указать название сервера с dns-суффиксом, что мы задали раньше.
|
$todaydate = Get-Date $add3year = $todaydate.AddYears(3) New-SelfSignedCertificate -dnsname Server1.adel.local -notafter $add3year -CertStoreLocation cert:\LocalMachine\My -TestRoot |
И для нашего Server2.
|
$todaydate = Get-Date $add3year = $todaydate.AddYears(3) New-SelfSignedCertificate -dnsname Server2.adel.local -notafter $add3year -CertStoreLocation cert:\LocalMachine\My -TestRoot |
В итоге у нас должно получится вот такое при открытии certlm.msc (Сертификаты на локальном компьютере):
Тестовый Корневной сертификат
Для начала сделаю папку «Сертификаты для репликации» в документах, чтобы всё было в одном месте.
Наш тестовый сертификат находится вне Доверенных корненых центрах, поэтому все наши сертификаты будут считаться недействительными. Нам необходимо его экспортировать и добавить в корни. По умолчанию он находится в Промежуточные центры сертификации.
Открываем оснастку certlm.msc, находим нужный сертификат.
Нажимаем ПКМ, Экспорт и экспортируем сертификат ничего не меняя, в созданную папку и назовём его CA.
Далее его необходимо добавить в Доверенные корневые сертификаты и на Server1 и на Server2.
Должно вылезти предупреждение, с ним соглашаемся.
Экспорт сертификатов
Экспортируем наши сертификаты в папку. И копируем их на сервер-репликацию. Всё в той же оснастке certlm.msc в разделе Личные выбираем наш сертификат Server1, нажимаем ПКМ, экспорт и далее делаем по инструкции:
Вместе с закрытым ключом;
Устанавливаем нужные свойства;
Задаем ключ;
И сохраняем в нашей папке «Сертификаты для репликации».
Точно так же делаем для второго сертификата. После чего копируем всю папку на Server2 и производим импорт.
Импорт сертификатов
Не забываем, что необходимо сначала импортировать сертификат CA в корневые. Если Вы это не сделали раньше, то сделайте прямо сейчас.
С сертификатам для сервера всё просто. Кликаем два раза по нужному сертификату и импортируем его в Сертификаты на компьютеры в раздел личные с заданным ключом на моменте экспорта.
Настройка сервера-реплики
На нашем сервере репликации (в примере это Server2) открываем оснастку Hyper-V, переходим в Параметры Hyper-V, открываем Конфигурация репликации.
Указываем TCP-порт по которому будет работать репликация. Выбираем сертификат и указываем хранилище для репликации.
Открыть порт в брандмауэре
Не забываем, что нам необходимо открыть порт, который мы указываем в настройках сервера репликации. Если у Вас стоит сторонний FireWall или антивирус с этими функциями, то открываем там.
Включение репликации
Настал момент, когда можно запускать репликацию с Server1 на Server2. Открываем оснастку Hyper-V, выбираем нужную VM, кликаем включить репликацию.
Далее указываем наш сервер-репликации;
В настройках подключения выбираем сертификат;
Выбираем диски для синхронизации. Я всегда отключаю бекапные.
Выбираем частоту реплицирования;
Выбираем количество точек;
Указываем метод первоначальной передачи ВМ и время запуска синхронизации. Если у нас толстая виртуальная машина, то можно сделать экспорт на диск, перенести. Но это как-то запарно, я всегда использую сеть.
Получаем сводку;
Тыкаем готово и радумаеся. Пошло, поехало…
Маленькая особенность
По-умолчанию, если репликация сломается, то повторно она запускается в промежутке с 18:30 до 6:00, чтобы это исправить необходимо открыть свойства ВМ в Hyper-V, в разделе репликация указать Автоматический запуск. Проверенно опытом, что так стабильнее и лучше.
Важные подсказки
- При изменении конфигурации ВМ (добавили оперативной памяти, расширили диск) эти действия необходимо продублировать руками на виртуальной машине на сервере репликации;
- Чтобы спать спокойнее, необходимо настроить мониторинг репликации;
- Просмотр статуса репликации возможен прямо из оснастки Hyper-V, необходимо включить нужный столбец;
Просмотры: 2 945
Если мой материал был полезен, то можете угостить меня кофе ☕️
В этой статье мы кратко расскажем о механизме репликации Hyper-V встроенными средствами. К сожалению, данный механизм почему-то крайне редко кто-то использует и вместо этого воруют “покупают” такие продукты как Veeam Backup, но при этом используют его только для создания реплик VMs.
Репликация Hyper-V позволяет делать полную копию VM на другой гипервизор (сервер) и поддерживает эту копию в актуальном состоянии непрерывно. Таким образом, в случае тотального краха основного гипервизора, вы как администратор среды виртуализации, после принятия решения “Основной сервер восстановлению не подлежит и надо запускать VM на резервном гипервизоре” потратите буквально несколько минут, чтобы данную VM включить с объёмом потерянных данных не более чем 0,5 / 5 / 15 минут (в зависимости от настройки). Мало того, если гостевая OS, так же Windows (из поколения не ниже 9-ой версии), то за счёт использования службы VSS совместно с компонентами интеграции вы получите целостными даже базы СУБД, работавшими в момент создания копии данных для резервного гипервизора.
После настройки репликации основной гипервизор создаёт разностные файлы виртуальных дисков и передаёт их на сервер реплику (резервный сервер), а сервер-реплика получив его объединяет с основным виртуальным диском. В зависимости от настроек, можно получить ещё и согласованные реплики с приложениями (та самая служба VSS). Такие “согласованные” копии гарантируют, что в них все данные будут целостными и даже в MS SQL, MySQL, PostgreSQL и другие СУБД даже сильно нагруженные окажутся на сервере реплике с своими базами в целостном состоянии и в случае неожиданного краха основного сервера у вас будет возможность взять последнее состояние реплики (с минимальным объёмом потерянных данных, но с риском что БД находится в состоянии corrupted), либо откатиться на более раннюю точку, но согласованную с приложениями (VSS). И вы на 100% получите целостные транзакции внутри БД.
Выделяем в списке VM в списке и в правой части диспетчера управления Hyper-V жмём “Включить репликацию”. На первом экране укажите имя сервера партнёра по репликации (на этом партнёре уже должно быть всё настроено включая открытый TCP/80 или TCP/443) и нажмите “Далее”:
Выберите режим передачи данных с шифрованием или без него. Настоятельно не рекомендуем включать шифрование, если у вас данные передаются в закрытом сегменте. Но если у вас есть необходимость настроить шифрование вы должны понимать что такое ассиметричное шифрование, корректно настроить центр сертификации в домене и получить корректные сертификаты на обоих серверах. Также вам надо учесть фактор избыточной нагрузки на CPU на обоих серверах.
Тут вы можете настроить какие виртуальные диски необходимо реплицировать. Например, если у вас на сервере партнёре не очень много свободного места и вы не хотите, например, реплицировать кэш WSUS службы, то тут можно диск с WSUS исключить из репликации. Учтите, что добавить “на лету” его не получится в дальнейшем и надо будет пересоздать параметры репликации. Пересоздать можно двумя способами:
• Удалить VM на сервере реплике.
• Удалить параметры репликации и создать их заново и начальную реплику передать в ранее отреплицированную VM. При таком восстановлении начальная репликация будет передана не полностью, но диск который ранее был не реплицирован приедет на сервер-реплику с именем виртуального диска не как вы задали на основном сервере, а в виде длинного GUID.
5. Настройка частоты репликации
На этом экране вы можете выбрать как часто надо отправлять реплику на сервер-реплику. Учтите, что слишком частая отправка даст избыточную нагрузку как на отправляющий сервер, так и на принимающий. Слишком редкая отправка реплики может привести к проблемам объединения полученных изменений на стороне реплики.
6. Настройка дополнительных точек восстановления
При настройке дополнительных точек, учтите что на сервере-реплике необходимо иметь свободное пространство равное объёму изменений за выбранное количество часов (первый параметр). Также помните, что служба VSS имеется только в операционных системах Windows и корректно работает в паре с Hyper-V и гостевой OS Windows версии не ниже 9-й. Ещё немаловажный фактор, это ощутимое снижение производительности гостевой OS в момент создания точки VSS. Если гостевая система высоко нагружена и делать такую точку каждый час, тогда вы получите эффект снижения производительности каждый час.
7. Выбор метода начальной репликации
Если с передачей начальной реплики по сети всё ясно, то вот с передачей на носителе и “Использовать существующую….” есть нюансы, о которых надо знать.
• Чтобы передать начальную реплику на носителе, надо эти данные выгрузить на этот носитель. И это возможно сделать выполнив просто экспорт VM на носитель. Но тут есть “нюанс”, о котором будет сказано ниже.
• Если у вас уже есть реплика вашей VM на сервере-реплике, то вы можете для ускорения процесса запустить репликацию используя параметр “Использовать существующую VM….”. Учтите, что Hyper-V определяет какая VM является той же на реплике определяет не по имени в диспетчере, а по GUID (внутренний параметр VM). По этому как именно названа ваша VM на реплике, не важно. Если в момент начала такой репликации на сервере-реплике не было каких-то виртуальных дисков, то они загрузятся на сервер-реплику, но имя файла данного виртуального диска будет содержать не название как на исходном сервере, а GUID. Полезен данный механизм в тех случаях, когда вы добавили ещё один диск на исходную VM и надо добавить это диск в репликацию.
После настройки репликации от отправки начальной реплики на основном сервере автоматически удалится “снапшот” (Точка возврата) и начнёт исполняться автоматическая процедура передачи всех изменений на сервер-реплику.
Преимущества данного решения очевидно, но всё же отмечу их:
• Имеется в базовой конфигурации OS Windows Server.
• Крайне легко настраивается даже новичком.
• Гарантирует целостность данных внутри VM для гостевых OS Windows.
• В случае отказа основного сервера или самой VM вам потребуется 1-5 минут на проверку статуса точек восстановления на сервере-реплике и выполнить отработку отказа.
• Имеются точки возврата за 24 часа, то можно вернуться не к последнему состоянию (когда внутри VM уже данные были Corrupt), а выбрать время для точки восстановления.
• Возможность настройки “Расширенной репликации на 3-й сервер, что даёт уверенность вам в том, что при самых негативных обстоятельствах, у вас есть ещё одна копия целиком VM.
Но есть и негативные стороны данного решения:
• В случае отказа основного сервера, VM на сервере-реплике сама не включится (требуется вмешательство человека).
• Незначительно снижается производительность из-за избыточных затрат файловой подсистемы на создания файлов с данными которые надо передать в реплике.
• Репликация может самопроизвольно прекратить функционировать.
Если с первым пунктом вопросов особо ни у кого не будет, и всем ясно, что если надо ещё выше уровень отказоустойчивости, то надо использовать “Отказоустойчивый кластер” и со вторым тоже всё понятно и это особенность технологии и снижение производительности не значительное, то вот с третьим пунктом проблема. Не нанимать же специального человека, который будет каждые 15 минут заходить и проверять.
Для этого мы разработали сенсор для системы мониторинга PRTG и скоро опубликуем у нас на сайте и GitHub. Для Zabbix тоже будет готов, но чуть позже. Вы сможете взять данный сенсор и переписать его самостоятельно т. к. он написан на PowerShell.
Skip to content
Beginners’ Guide for Microsoft Hyper-V: How to Configure Hyper-V Replication: Part 67
Now that we have a general overview of Hyper-V Replication, let’s look at how to set up the solution with two Hyper-V servers in a lab environment. Replication using two standalone servers is the most straightforward approach to Hyper-V Replication that helps build knowledge of how the process works.
The Hyper-V Replication test configuration
To level set on the lab configuration, we have two Windows Server 2022 hosts in the lab environment configured as standalone Hyper-V servers with local storage, etc. Both servers are fresh installations with the latest Windows patches. The Hyper-V Role has been installed on both servers via the PowerShell cmdlet:
Protect Your Data with BDRSuite
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
Once you have Hyper-V installed on both of your Hyper-V hosts, you can set up Hyper-V Replication between them. You may wonder if you would use Hyper-V Replication between standalone hosts would never be used in production. However, there is a specific use case among others where this could be the case.
When would you use Hyper-V replication between two standalone servers?
Using Hyper-V Replication between two standalone servers is an excellent way to create a “poor man’s disaster recovery” solution if you don’t have the hardware or budget to create robust Hyper-V clusters at each location. In this way, businesses take a calculated risk to understand that if the primary host goes down, no other host can assume the workloads at the primary location.
However, you can assume this risk with replication, knowing you have a replica of your Hyper-V server at another location or even on the same site. The “same site” configuration is well-suited for losing your primary Hyper-V server but not for a site-level failure.
However, Hyper-V Replication can be used to configure multiple replicas to have multiple replica copies of your VMs to protect from inter-site failures and site-level.
Configuring Hyper-V Replication – Step-by-Step
To begin the configuration process for Hyper-V Replication, right-click on a virtual machine and select Enable Replication.
Enabling Hyper-V Replication on a virtual machine
It will launch the Enable Replication wizard for the Hyper-V virtual machine. Click Next.
Beginning the Enable Replication wizard for a Hyper-V virtual machine
Next, you will need to choose the target for the Hyper-V replica. You can type in the name of your Hyper-V server or use the Browse button to find the server in Active Directory.
Specifying the Replica Server in Hyper-V Replication
Before you can target a specific Hyper-V server for replication, you need to enable the server as a Replica Server. Under the properties of the Hyper-V host that will be the target of replication, you need to check the box, Enable this computer as a Replica server. Also, select either HTTP or HTTPS for the communication protocol.
You should never use HTTP for production environments. HTTPS requires the configuration of certificates to encrypt the communications between the two Hyper-V servers and ensures data is secure during transmission. You can also configure which servers are authorized to replicate machines to the target Hyper-V server.
Enabling a Hyper-V Server as a Replica Server and configuring authentication and authorization
Specify your connection parameters. It compresses data by default (configurable).
Specifying connection parameters
Choose the replication VHDs you want to replicate to the target server.
Choose the replication VHDs you want to replicate
Configure the replication frequency for the Hyper-V Replica. It essentially configures your RPO value for the replication process. Here, you can see the available replication intervals in the wizard – 30 seconds, 5 minutes, and 15 minutes.
Configuring the Replication Frequency
You can also choose to keep extra recovery points or maintain the latest recovery point. The additional recovery points will be kept as Hyper-V checkpoints on the Hyper-V replicas.
Choosing to configure additional recovery points
You can also choose your Initial Replication Method for your Hyper-V replicas. You can choose from the following:
- Send initial copy over the network
- Send initial copy using external media
- Use an existing virtual machine on the Replica server as the initial copy
- Schedule Initial replication
- Start replication immediately
- Start replication on
Choose the Initial Replication Method
Finally, we come to the Summary screen for the Hyper-V replication configuration. Verify your configuration is accurate. You can hit the Previous button if needed or click Finish if everything looks okay.
Summary screen for the Enable Replication wizard
You can check out the status of Hyper-V replication by clicking the VM in Hyper-V Manager and choosing Replication > View Replication health. Below, I have replicated the shell of a virtual machine without an operating system installed.
Viewing the replication health of a Hyper-V virtual machine
You can see all the Hyper-V Replication options by right-clicking the virtual machine and choosing Replication. You will see the following options:
- Planned Failover
- Pause Replication
- View Replication Health
- Remove Replication
Viewing replication options
Hyper-V Replication FAQs
What is Hyper-V Replication?
It is a capability built into Microsoft Hyper-V, enabling businesses to create and maintain exact replicas of production virtual machines in another Hyper-V environment. As a result, replication enables quick recovery from a disaster with little data loss. In addition, Hyper-V Replication offers extremely low replication intervals, including 30-second RPOs.
How does Hyper-V Replication work?
It replicates changes from the source virtual machine to the target virtual machine at the replication interval defined. In a Hyper-V cluster, this process is managed by the Hyper-V Replica Broker. However, in Hyper-V standalone environments, the Hyper-V servers manage this communication directly.
What are the benefits of using Hyper-V Replication?
Hyper-V Replication has many benefits, including disaster recovery protection, flexibility in protecting your data, low RPO and RTO values, the ability to test failover and failback, and cost-effectiveness.
Wrapping Up
Hyper-V replication is a great way to provide disaster recovery options for critical applications in the environment. It can protect organizations from critical downtime from server failures, ransomware, natural disasters, and other threats. Businesses can also use it to protect data between standalone Hyper-V environments where they don’t have the hardware or budget to build a proper Hyper-V cluster to protect workloads.
Read More:
Beginners’ Guide for Microsoft Hyper-V: What is Hyper-V Replication and How it works: Part 66
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
Try BDRSuite for Free!
Schedule a live demo with one of our product experts
Start your full-featured 30-day free trial
Explore detailed pricing, editions & features
Using virtual machine failover helps you avoid downtime if a disaster makes your primary environment unavailable. Failovers allow you to recover data and restore workloads quickly. To perform a failover, you need VM replicas created in advance. You can set up Hyper-V VM replication within the same host/cluster or to a different host/cluster.
This blog post covers setting up Hyper-V replication with native tools in Windows and with a third-party comprehensive data protection solution.
Requirements
To set up Hyper-V replication, you should have the following:
- 2 servers with Microsoft Hyper-V installed
- A reliable network connection between the Hyper-V servers
- Storage with high IOPS performance
Before Setting up Hyper-V Replication
You should plan how you will use Microsoft Hyper-V replication to protect data and recover workloads before proceeding with setting up Hyper V servers as this will impact your Hyper-V configuration. Here are some key factors that your plan should include:
- Define which virtual disks to replicate. If you are using a dedicated virtual disk for a swap file, you can exclude this virtual disk from replication. Data in a swap file is frequently changed (the changed data is considered the data to replicate), but this data is not required to restore a VM replica on the second server (that is, not required for failovers). So, you can reduce Hyper-V VM replication time when excluding unnecessary disks.
- Decide how often to synchronize data between VMs. Select the synchronization interval based on your RPOs, that is, recovery point objectives set for your workloads. Consider factors such as network bandwidth when selecting VM synchronization frequency. Lower network bandwidth would make it difficult to synchronize large amounts of data frequently.
- Define possible scenarios to recover data. How many recovery points should you save for a VM replica? Each recovery point is saved as a virtual disk snapshot (called a checkpoint in Hyper-V) for a VM replica. A snapshot is used to revert the needed VM state for the appropriate point in time.
- Decide whether you need to have application consistency for your Microsoft Hyper-V VM replicas. Some applications like Active Directory Domain Controller, Microsoft Exchange Server, Microsoft SQL Server, Oracle Database, and other database servers can write data during their regular operation. The process of writing data must be quiesced by using Volume Shadow Copy Service (on Windows VMs or using scripts for Linux VMs) before starting replication to preserve application consistency.
- Select the method of initial VM replication. If you have a high-speed network connection, you can start the initial Hyper-V replication over the network. If the network bandwidth is low (for example, when creating replicas over WAN or internet between offices or data centers), then you can copy a VM on a removable storage media (for example, a USB HDD) and then copy the VM to the replica server (known as replication seeding). This VM will be the initial replica and only data changes will be replicated over the network from then on.
Preparing Hyper-V Hosts
You need to prepare the Microsoft Hyper-V hosts and ensure that network traffic for VM replication is allowed and DNS names are resolved.
Network connection for Hyper-V replication
Network connection for Hyper-V replication can be established in two ways:
- HTTP (port 80, TCP). This connection type can be used if the two servers running Hyper-V are members of an Active Directory domain. Authentication is performed by using Kerberos in Active Directory to make it secure. Otherwise, it is not recommended that you use HTTP to transfer data over the internet via unencrypted network connections as HTTP is an unencrypted protocol. Configuring Hyper-V replication via HTTP is not difficult, you just need to join the servers in the domain.
- HTTPS (port 443, TCP). This connection type is encrypted and secure in itself. However, setting up Hyper-V replication via HTTPS is a complicated process. You need to create certificates and manually import them to all the servers with Hyper-V. A certificate is used for authentication between the Hyper-V hosts. If your Hyper-V servers are not in an Active Directory domain, you must use an HTTPS connection for Hyper-V VM replication.
If you use an HTTPS connection, you need to buy a certificate from a certificate provider (certificate authority or CA). This approach is the most secure one. The alternative is generating a self-signed certificate manually. You can create SSL certificates by using native tools in Windows Server 2019. However, using self-signed certificates is less secure than obtaining them from a CA. Certificates periodically expire, and then you need to reconfigure Hyper-V hosts to use new certificates.
Use a secure network connection if you use the internet for communication between the two Hyper-V hosts. You can use VPN or an IPSec tunnel. Note that if you use an encrypted VPN connection, traffic is encrypted, and you don’t need to encrypt with HTTPS for communication between the Hyper-V hosts for VM replication. If you use HTTPS in this case, you get overhead because encrypted data is bigger in size (there are larger traffic requirements – one reason is the fact that key-based encryption is asymmetrical). As a result, the performance of data transfers worsens. For this reason, avoid using double encryption.
In our example, we have two Windows Server 2019 machines with Hyper-V installed. Both machines are members of a domain (domain1.net). We don’t use an unsecured WAN connection. For this reason, in our walkthrough, we use Kerberos authentication and an HTTP connection for Hyper-V replication.
Resolving DNS names
Both servers running Hyper-V must resolve hostnames (DNS names) to IP addresses. If your servers are domain members, and a domain controller is set as the primary DNS server in the network configuration, this is not a problem. If your servers running Hyper-V are not in a domain (they are in a workgroup), you may need to add records to the hosts file manually. The hosts file is stored in:
C:\Windows\System32\drivers\etc\hosts
You can open PowerShell as administrator and open this file in Notepad with the ability to edit and save changes:
notepad.exe "$env:windir\system32\drivers\etc\hosts"
Add lines with the IP address and hostname to the hosts file like this:
192.168.101.2 server2
192.168.101.9 server9
Ping Hyper-V hosts to ensure that hostnames are resolved. ICMP traffic must be enabled in this case.
Configuring the Firewall
When you install Microsoft Hyper-V, some rules in the Windows firewall are created automatically. However, the rules needed for Hyper-V replication traffic are disabled by default, and Hyper-V replication traffic is blocked as a result. You need to enable the relevant Hyper-V replication rule for HTTP or HTTPS traffic, depending on your scenario. Enable the rules on both Hyper-V servers.
The rules are:
- Hyper-V Replica HTTP Listener (TCP-In) for HTTP traffic (port 80 for inbound connections)
- Hyper-V Replica HTTPS Listener (TCP-In) for HTTPS traffic (port 443 for inbound connections)
Note: We use default port numbers, and these rules are applicable. If you are using custom port numbers, you need to adjust the rules or create similar rules with the needed port numbers.
Using the command line interface
Do the following steps to configure Windows Firewall for Hyper-V replication in the command line:
- Open PowerShell as administrator.
- Check firewall rules:
netsh advfirewall firewall show rule name=all dir=in | find "Hyper-V"
- Enable the rule:
- For HTTP:
Enable-Netfirewallrule -displayname "Hyper-V Replica HTTP Listener (TCP-In)"
- For HTTPS:
Enable-Netfirewallrule -displayname "Hyper-V Replica HTTPS Listener (TCP-In)"
- Check whether the rule has been enabled:
- For HTTP:
Get-Netfirewallrule -DisplayName 'Hyper-V Replica HTTP Listener (TCP-In)'
- For HTTPS:
Get-Netfirewallrule -DisplayName 'Hyper-V Replica HTTPS Listener (TCP-In)'
Using the GUI
Using the graphical user interface (GUI) is a convenient way to configure Windows firewall for setting up Hyper V replication.
- In Server Manager, go to Tools > Windows Defender Firewall with Advanced Security.
As an alternative, you can run the following command to open the Windows Firewall window:
wf.msc
- Click Inbound rules in the left pane of the Windows Firewall window.
- Right-click the needed rule:
- Hyper-V Replica HTTP Listener (TCP-In)
- Hyper-V Replica HTTPS Listener (TCP-In)
- Click Enable Rule in the context menu that opens.
Setting up Hyper-V Replication with Native Tools
There are a few steps left to prepare both Hyper-V hosts before we can proceed to setting up Hyper-V replication.
- To open Hyper-V Manager, open Server Manager and go to Tools > Hyper-V Manager. We are setting up Hyper-V replication from the main (source) server, which is Server02.
- Right-click the server name in Hyper-V Manager, and in the context menu, hit Hyper-V settings.
- In the left pane of the Hyper-V Settings window, click Replication Configuration. In the right panel of the window, select the following settings:
- Enable this computer as a Replica server
- Use Kerberos (HTTP). Specify the port (we use port 80, which is the default value). If you use HTTPS and certificates, select the appropriate options.
- Allow replication from any authenticated server
Click OK to save the settings.
Repeat all the steps on the second Hyper-V host (that is, the destination host for Hyper-V replication).
Enabling VM replication
We have configured both Hyper-V hosts, and now we can set up Hyper-V replication for a virtual machine on the source host.
Right-click the VM in Hyper-V Manager on the primary server (Server02 and VM2 in our case), and in the context menu, click Enable Replication.
The replication wizard opens. Set up Hyper-V replication for the VM by following the steps in the wizard.
- Before you begin. You can skip this step because there is nothing to configure.
- Specify Replica Server
- Click Browse. In the window that opens, enter the server name (Server09 in our case).
- Click Check Names. When the server name is underlined, this means that the name is correct.
- Click OK to save settings and close the current window.
- Then you can click Next.
- Specify Connection parameters. The replica server has already been selected (Server09). Set the following parameters, which must match the ones you set previously in Hyper-V settings on both servers.
- Replica server port: 80
- Authentication type: Use Kerberos authentication (HTTP)
- Compress the data that is transmitted over the network
- Choose Replication VHDs. Select the virtual disks of the VM to replicate. The VM used in our example has one virtual disk.
- Configure Replication Frequency. Select one of the three available options depending on your RPO and other factors such as network bandwidth and storage performance:
- 30 seconds
- 5 minutes
- 15 minutes
- Configure additional recovery points. Select the number of recovery points to retain for a VM replica. There are two options:
- Maintain only the latest recovery point – only one recovery point is available in this case.
- Create additional hourly recovery points – you can set the number of additional recovery points to create and the frequency.
- Choose initial replication method
- Select one of the options:
- Send initial copy over the network (we use this option)
- Send initial copy using external media
- Use an existing virtual machine on the replica server as the initial copy
- Schedule initial replication. You can set when to start this Hyper-V VM replication.
Note: Avoid job overlaps (when scheduling replication for multiple VMs) to avoid overloading hardware and network, which will cause overall performance degradation of VM replication and running VMs.
- Summary. Check your Hyper-V configuration for VM replication and hit Finish.
After enabling VM replication, you should see a notification message that you need to connect virtual network adapters of a VM replica to the network manually by editing VM settings.
Running VM replication
Let’s open Hyper-V Manager on the replica server (Server09). We can see that a VM replica has already been created. The name of this VM is VM2, as on the source Hyper-V host.
Right-click the VM replica to see available options. You can check replication health, run a test failover, or run a real failover.
Our VM replication has been completed successfully.
For more convenience, you can add a column to see replication health in the main Hyper-V Manager window in the list of VMs.
- Go to View > Add/Remove Columns in the main Hyper-V Manager window.
- In the Available Columns list, select Replication Health and click Add ->
- Click OK to save settings and close the window.
You can see that replication health for our VM replica is Normal.
You can check files of the VM replica, such as virtual disks, snapshots, etc., in the appropriate folder on the destination (replica) server.
Let’s look at how we can perform Hyper-V VM replication with a dedicated data protection solution called NAKIVO Backup & Replication. Configuration of Hyper-V replication is easy even if your Hyper-V hosts are in a workgroup and there is no Active Directory Domain. You don’t need to follow the difficult workflow to configure certificates like you would do with the native replication method. There are convenient options for using an encrypted connection.
To perform Hyper-V replication, you first need to configure your Hyper-V hosts – both the production and disaster recovery (DR) environments. You have to add the hosts to the NAKIVO solution inventory and make sure firewall settings do not block connections, among other things. In the example below, we are replicating Hyper-V virtual machines from a production environment (HVProd) to a designated DR site (HVDR). It is worth noting that, as shown below, you can manage multiple hypervisors from the Inventory tab in the +NAKIVO Backup & Replication web interface.
Once you have the Hyper-V environments configured, you need to launch the Hyper-V replication wizard.
On the Jobs dashboard page, click Create > Replication > Microsoft Hyper-V replication job.
The New Replication Job Wizard for Microsoft Hyper-V opens.
- Source. Select the virtual machines you want to replicate to the other environment. Note that in the example below, we select an individual virtual machine within our production environment.
With the wizard, you can also choose to replicate virtual machines at the host level by ticking the checkbox next to the host/cluster. When you do so, you will see in the information pane: New items created on or moved to the source host will be automatically added to this job. This useful feature allows you to automatically have Hyper-V replication set up for any new virtual machines you add to your source environment.
Hit Next at each step to continue.
- Destination. Identify the target Hyper-V environment, including the destination path. The path selected in the example below (D:\NakivoReplicas) is the one we set in our Hyper-V settings to store our virtual machine replicas and configuration files.
- Networks. Additionally, you need to select the target network for the replicated virtual machine in the destination Hyper-V host/cluster. A VM replica will be connected to this network.
- Re-IP. You can set the custom IP address and other IP settings for the VM replica. Primary and secondary Hyper-V hosts can use different networks with different IP addresses, gateways, and DNS servers. You don’t have to edit VM settings for connecting a VM replica to the needed network manually in this case.
- Schedule. Set up the schedule based on which you want to perform replication of your Hyper-V virtual machine. Note the Add another schedule and Show calendar options.
A powerful feature of NAKIVO Backup & Replication is the ability to set up job chaining. Job chaining allows you to link one job to another one. For example, you may chain a replication job to a backup job. In the screenshot below, we have the Run after another job option selected and the corresponding backup job chosen. With these settings, after a successful backup job, the solution immediately kicks off the replication job for your Hyper-V virtual machine.
If you click the Show calendar link, you can see the Calendar dashboard, which is a great way to get a visual overview of all the jobs scheduled in NAKIVO Backup & Replication. You can also create and edit jobs, including Hyper-V replication jobs, right from this interface. The Calendar also helps you avoid any job overlaps.
With the NAKIVO solution, you can also set up multiple schedules for a Hyper-V replication job by clicking the Add another schedule link. This allows you to create different schedules for different days of the week, which is something that many businesses might appreciate if they experience variations in working hours and/or typical activity. For example, we can have a different schedule set up for weekdays versus the weekend.
- Retention. You can set the number of recovery points that will be retained. These equate to checkpoints in Hyper-V on the replicated virtual machine.
- Options. Finally, you are given many interesting options showcasing the power and versatility of NAKIVO Backup & Replication. On the Options screen, you can configure the following settings for your Hyper-V replication job:
- App-aware mode – This mode allows you to maintain data consistency on the Hyper-V replica. You might want to use this mode if you are replicating, for instance, a Microsoft SQL Server virtual machine.
- Change tracking – Hyper-V RCT was introduced with Windows Server 2016 and allows you to perform efficient changed block tracking, that is, recording only the changes that are made between each backup iteration without using a filter driver. You can also choose to use NAKIVO’s proprietary change tracking technology.
- Network acceleration – This option allows you to compress data and reduce traffic and, thus, increase data transfer speeds by up to 2 times.
- Encryption – You can control whether you want the transferred data to be encrypted in flight over the network.
- Replica disks – You can replicate the source VM settings here if you select Respect original VM disk type. You can also select to use dynamic disks, which is essentially thin provisioning the resulting Hyper-V replica virtual machine.
In addition to the options above, you can control the naming of your replica virtual machines, opt to receive job completion reports via email, truncate Microsoft SQL Server and Exchange Server transaction logs, and choose to execute local pre- and/or post-job scripts.
Click Finish & Run.
In your Hyper-V Manager of the source server (Server02 in our case), you can see a temporary Microsoft Hyper-V checkpoint of the source virtual machine that is being replicated.
Below, we have an example of the checkpoint existing on the Hyper-V replica virtual machine once it is created (the VM name is VM2-replica). The chain of checkpoints will grow to the value of Keep <N> last recovery points. If we set to keep 3 last recovery points, we will have maximum 3 checkpoints for the VM-replica on the destination Hyper-V host.
Conclusion
Microsoft Hyper-V replication allows you to place a VM replica (an exact copy of a VM) in a different location to protect against data loss in the event of a site-wide failure or disaster with the ability of fast VM failover, that is, recovery.
You can use a dedicated Hyper-V replication solution like NAKIVO Backup & Replication to simplify the process and access more flexible options.