Безопасная репликация между двумя standalone хостами Hyper-V 3.0

Наступил тот момент, когда мне пришлось поднимать репликацию на Hyper-V 3.0 в разнесенных датацентрах в условиях отсутствия домена на обычных standalone серверах. На виртуальных машинах крутятся задачи, которые не требуют мгновенного RTO (по требованиям не более часа в условиях удаленности датацентров), а ненулевой RPO для них не смертелен. При этом затраты на решение должны быть минимизированы. В таких случаях я дополнительно подключаю виртуальные машины и хосты виртуализации к своей системе мониторинга, и при их отказе в течении двух трех минут я получаю смс и почтовое уведомление о случившемся отказе. Ну а далее дело техники. Из предварительных требований нужно чтобы серверы резолвили друг друга по именам, для этого минимально достаточно подправить файлы hosts. Можно, прописать записи на отказоустойчивом DNS-сервере, если таковой имеется. В моем случае это два простых хоста с именами w2012a в качестве главного хоста виртуализации и w2012b в качестве хоста-реплики с соответствующими записями в hosts, которые друг друга по этим именам и пингуют.

Для начала, необходимо создать и обменяться сертификатами компьютеров, по которым сервера будут доверять друг другу. В этом нам поможет утилита makecert.exe из состава Windows SDK. Качаем и устанавливаем Windows Software Development Kit (SDK) for Windows 7 (в версии Windows 8 makecert нет) к себе на рабочую машину отсюда:

http://www.microsoft.com/en-us/download/confirmation.aspx?id=3138 - здесь нашелся

Забираем makecert.exe и копируем его на хосты w2012a и w2012b в Windows\System32. Теперь работаем на основном хосте виртуализации w2012a:

Создаем самоподписанный сертификат корневого ЦС, коим будет являться сам хост:

C:\Windows\System32\makecert -pe -n "CN=MainSiteRootCA" -ss root -sr LocalMachine -sky signature -r "MainSiteRootCA.cer"

Файл сертификата MainSiteRootCA.cer создается в каталоге C:\Windows\sysWOW64

Копируем его, для отправки на сервер-реплику w2012b

Создаем верификационный сертификат хоста виртуализации, подписанный самоподписанным сертификатом корневого ЦС со свойствами клиентской и серверной аутентификации (это обязательные атрибуты для сертификата авторизации при репликации)

C:\Windows\System32\makecert -pe -n "CN=w2012a" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "MainSiteRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 MainSiteCert.cer

Файл сертификата MainSiteCert.cer создается в каталоге C:\Windows\sysWOW64

Его тоже копируем себе, для отправки на w2012b.

Теперь работаем на хосте-реплике w2012b (действия те же самые, корневой сертификат, сертификат сервера, копируем файлы сертификатов для передачи на w2012a):

C:\Windows\System32\makecert -pe -n "CN=ReplicaSiteRootCA" -ss root -sr LocalMachine -sky signature -r "ReplicaSiteRootCA.cer"

C:\Windows\System32\makecert -pe -n "CN=w2012b" -ss my -sr LocalMachine -sky exchange -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 -in "ReplicaSiteRootCA" -is root -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 ReplicaSiteCert.cer

Теперь на оба хоста копируем перекрестно файлы сертификатов самоподписанных корневых ЦС в произвольное место, допустим в каталоги C:\Temp

Импортируем сертификаты. На w2012a импортируем сертификат реплики

certutil -addstore -f Root "C:\Temp\ReplicaSiteRootCA.cer"

На w2012a импортируем сертификат основного хоста

certutil -addstore -f Root "C:\Temp\ReplicaSiteRootCA.cer"

Так как самоподписанные сертификаты не поддерживают списки отзывов, нам необходимо выключить проверку CRL на обоих хостах, так как она включена по умолчанию. Для этого исправляем ключ в реестре HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication\DisableCertRevocationCheck с 0 на 1 и перегружаем хосты.

Ключ реестра можно можно поправить через командную строку:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\Replication" /v DisableCertRevocationCheck /d 1 /t REG_DWORD /f

На обоих хостах уже установлена роль Hyper-V и на w2012a работают виртуальные машины, требующие репликации. Настраиваем репликацию.

Для корректной отработки failover и failback, на обоих хостах настраиваем роль сервера-реплики для своего соседа, тоесть первый сервер это сервер-реплика для второго, а второй - сервер-реплика для первого. При настройке партнеров по репликации нужно выбрать аутентификацию с использованием сертификатов. И указать на каждом хосте свой собственный сертификат.

Если до этого с сертификатами все было сделано правильно, то при выборе сертификата будет единственный выбор - верификационный сертификат того хоста на котором настраиваем реплику, тоесть для первого сервера, сертификат первого сервера, а для второго - второго. Так как корневые и верификационные сертификаты обоих хостов находятся в доверенных хранилищах, то сервера будут доверять друг другу.

Далее в свойствах виртуальных машины на w2012a, включаем репликацию, вводим имя w2012b в качестве хоста-реплики, убеждаемся что выбран правильный тип авторизации, выбираем какие жесткие диски реплицировать. Тут важный момент, где можно сэкономить на репликации ненужной информации как то файлов гибернации, pagefile, временных директорий прочей, зачастую ненужной информации. Выносим все это дело внутри виртуальной машины на отдельный vhdx диск и исключаем его из репликации, единожды скопировав на w2012b данный диск. Тогда не придется гонять часто изменяющуюся временную информацию, сбрасывающуюся при перезагрузке сервера, по каналам связи.

Далее выбираем глубину сохранения реплик (максимально 15 реплик). Если виртуальная машина поддерживает VSS, можно настроить инкрементарную репликацию, но нужно помнить что VSS в некоторых сценариях создает дополнительную нагрузку на дисковую подсистему.

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

Обязательно в правилах брандмауэра обоих хостов включаем входящее правило Hyper-V Replica HTTPS Listener (TCP-In), так как по 443 порту и будет ходить вся репликационная информация.

Все, после этого процесс репликации начался.

Надо заметить, что для отработки failoverможно работать по двум сценариям. В одном случае в свойствах реплицируемых виртуальных машин automatic start action нужно выставить в none, чтобы при восстановлении упавшего сервера, сохранившего операционную систему и настройки Hyper-V оригинальные виртуальные машины не стартовали, а работали только репликами на w2012b.

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

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

Во втором случае можно оставить все как есть, тогда будет задействован процесс автоматической ресинхронизации. После запуска w2012a и виртуальных машин на нем, все внешние коннекты будут идти на них, а не на реплики. Что приводит к split-brain до момента, пока мы не выключим виртуальную машину на w2012b, произведем Resume Replication на w2012a и не выполним ресинхронизацию.

Теперь немного о процессе возврата виртуальной машины на w2012a в случае его падения и восстановления.

В случае, когда у нас виртуальные машины автоматически не стартуют на восстановленном хосте w2012a, удаляем в гипервизоре виртуальную машину которую надо будет восстанавливать, иначе следующий шаг будет возвращать ошибку. На w2012b в свойствах виртуальной машины в репликации выбираем Reverse replication. В этот момент изменения, которые были сделаны за время работы виртуальной машины на w2012b применяются на экземпляр виртуальной машины на w2012a.

Перед следующим шагом, выключаем виртуалную машину на w2012b и выбираем в ее контекстном меню опцию Planned Failover, ждем когда реплика и основа поменяются местами. И последний шаг - на w2012a в контекстном меню виртуальной машины выбираем Failover.

Обратил внимание, что после такой процедуры, виртуальная машина отключается от сети. После всех манипуляций подключаем ее к нужному виртуальному свичу, благо это можно сделать "на лету".

А в случае, когда машины автоматически стартуют, работаем через процедуру Resume replication и ресинхронизацию и контролируем split-brain. Замечу что данный вариант не работает с виртуальными машинами без компонент интеграции. Для таких машин можно работать только по первому варианту.

В случае, когда восстановление основного хоста невозможно, а вместо него вводится в строй новый хост с новым гипервизором, необходимо повторить процедуру обмена сертификатами, разорвать репликацию на сервере реплики, (путем выбора Remove Replication в контекстном меню виртуальной машины), создать репликацию заново и отработать последовательность Planned Failover/Failover.

В целом все...

Поделиться

Опубликовать в Facebook
Опубликовать в LiveJournal

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>