Репликация Hyper-V

Репликация Hyper-V

Дата: 20.03.2023

Комментариев: 0

В этой статье мы кратко расскажем о механизме репликации 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.

 

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.

Последние новости

Открыть чат
1
Отсканируйте код
Здравствуйте 👋
Чем Вам помочь?
Это не чат-бот! Тут отвечают люди, по этому не всегда мгновенно 😳