В этой статье мы кратко расскажем о механизме репликации 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% получите целостные транзакции внутри БД.
В зависимости от настроек параметров репликации Hyper-V вы можете настроить частоту передачи реплики (не согласованной) каждые 30 секунд, 5 минут, 15 минут. Хотя если поковыряться в недрах Windows, можно задать и другие параметры, мы не рекомендуем это делать. А вот согласованные (VSS) точки отката вы можете получить только если у вас ваша гостевая OS Windows, и в ней есть и работает служба VSS и вы включите в параметрах репликации как часто надо делать «согласованную» точку отката. По умолчанию компания Microsoft предлагает это делать раз в 4 часа и каждый час делать не согласованную точку. Все эти параметры так же можно модифицировать в недрах Windows, но тут уже настоятельно не рекомендуем этого делать. Максимум можно поменять частоту создания согласованных копий на каждые 3, 2 или 1 час. Но следует помнить, что при создании согласованной точки, все приложения в гостевой OS практически полностью перестают отвечать на вызовы и сильно замедляются в работе.
Требования для настойки:
- Ваши гипервизоры должны быть членами домена. Помните, что если Domain Controllers у вас являются сами VM, то у вас их должно быть минимум два и на разных гипервизорах. Т. к. в момент загрузки гипервизора он не обнаружит доступный Domain Controller и если из-за какого то сбоя среды виртуализации или самой VM с DomainController, вы не получите доступ уже и к гипервизору. На гипервизорах мы рекомендуем установить AD никак не связанную с основным доменом предприятия. В ней создать учётные записи только администраторов среды виртуализации. Выделить сегмент сети гипервизора в отдельный VLAN (как минимум), а лучше выделить отдельные коммутаторы минимум на 10Gbe. Ограничить в этот сегмент сети доступ таким образом, чтобы администраторы среды виртуализации не могли с любой точки как локального сегмента и тем более сети Internet подключиться к гипервизорам.
- Дисковая подсистема вашего гипервизора должна быть достаточно высокопроизводительной т. к. механизм репликации использует практически в 2 раза больше операций с дисковой подсистемой на основном гипервизоре.
- На гипервизорах в параметрах локального Firewall надо включить разрешение на подключение по TCP/80 и/или TCP/443 для передачи реплик (об этом вам ещё напомнит Microsoft при настройке).
Порядок действий для настройки репликации:
Выделяем в списке VM в списке и в правой части диспетчера управления Hyper-V жмём «Включить репликацию». На первом экране укажите имя сервера партнёра по репликации (на этом партнёре уже должно быть всё настроено включая открытый TCP/80 или TCP/443) и нажмите «Далее»:
Выберите режим передачи данных с шифрованием или без него. Настоятельно не рекомендуем включать шифрование, если у вас данные передаются в закрытом сегменте. Но если у вас есть необходимость настроить шифрование вы должны понимать что такое ассиметричное шифрование, корректно настроить центр сертификации в домене и получить корректные сертификаты на обоих серверах. Также вам надо учесть фактор избыточной нагрузки на CPU на обоих серверах.
Тут вы можете настроить какие виртуальные диски необходимо реплицировать. Например, если у вас на сервере партнёре не очень много свободного места и вы не хотите, например, реплицировать кэш WSUS службы, то тут можно диск с WSUS исключить из репликации. Учтите, что добавить «на лету» его не получится в дальнейшем и надо будет пересоздать параметры репликации. Пересоздать можно двумя способами:
- Удалить VM на сервере реплике.
- Удалить параметры репликации и создать их заново и начальную реплику передать в ранее отреплицированную VM. При таком восстановлении начальная репликация будет передана не полностью, но диск который ранее был не реплицирован приедет на сервер-реплику с именем виртуального диска не как вы задали на основном сервере, а в виде длинного GUID.
На этом экране вы можете выбрать как часто надо отправлять реплику на сервер-реплику. Учтите, что слишком частая отправка даст избыточную нагрузку как на отправляющий сервер, так и на принимающий. Слишком редкая отправка реплики может привести к проблемам объединения полученных изменений на стороне реплики.
При настройке дополнительных точек, учтите что на сервере-реплике необходимо иметь свободное пространство равное объёму изменений за выбранное количество часов (первый параметр). Также помните, что служба VSS имеется только в операционных системах Windows и корректно работает в паре с Hyper-V и гостевой OS Windows версии не ниже 9-й. Ещё немаловажный фактор, это ощутимое снижение производительности гостевой OS в момент создания точки VSS. Если гостевая система высоко нагружена и делать такую точку каждый час, тогда вы получите эффект снижения производительности каждый час.
Если с передачей начальной реплики по сети всё ясно, то вот с передачей на носителе и «Использовать существующую….» есть нюансы, о которых надо знать.
- Чтобы передать начальную реплику на носителе, надо эти данные выгрузить на этот носитель. И это возможно сделать выполнив просто экспорт 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.