Репликация hyper v что это
Технология Hyper-V Replica в Windows Server 2012 (часть 1)
В Windows Server 2012 появилось интересное решение, предназначенное для обеспечения высокой доступности и аварийного восстановления виртуальных машин. Это решение называется Hyper-V Replica и с его помощью можно осуществлять репликацию виртуальных машин между хостами или кластерами Hyper-V.
Hyper-V Replica может использоваться в различных сценариях, например для репликации виртуальных машин между головным офисом компании и ее филиалами, или между офисом клиента и датацентром провайдера. Для Hyper-V Replica абсолютно не важно местоположение серверов. Репликация возможна как между серверами Hyper-V в одной локальной сети, так и между датацентрами, расположенными в разных странах. При этом Hyper-V Replica фактически не зависит от хранилища и предъявляет минимальные требования к пропускной способности сети.
Архитектура
Архитектурно Hyper-V Replica состоит из следующих компонентов:
Replication Engine — как следует из названия, это основной «движок» технологии. Он управляет конфигурацией HVR и обрабатывает операции репликации: первоначальную репликацию (Initial Replication), разностную репликацию (Delta Replication) и отработку отказа (Failover). Также Replication Engine отслеживает события, связаные с перемещением виртуальных машин и дисковых хранилищ, и предпринимает необходимые действия (приостанавливает процесс репликации во время миграции и возобновляет его по окончании);
Change Tracking Module — модуль, отслеживающий на основном узле операции записи, производимые на уровне виртуальной машины. Работа модуля не зависит от типа хранилища, в котором хранятся диски виртуальной машины, он может работать с любыми хранилищами (локальные диски, Direct Attached Storage (DAS), SAN LUN, Cluster Shared Volume (CSV) или файловая шара SMB);
Network Module — компонент, обеспечивающий безопасный и эффективный (по умолчанию осуществляется сжатие данных) канал связи между узлами. Соединение создается с использованием HTTP/HTTPS, поддерживается аутентификация с помощью цифровых сертификатов и шифрование трафика репликации (опционально).
Hyper-V Replica Broker — роль, обеспечивающая корректную работу репликации в случае размещения виртуальной машины на узле кластера. Работает совместно с сетевым модулем и службой Failover Clustering. Брокер запрашивает в базе данных кластера, какой узел отвечает за обработку данных репликации и перенаправляет необходимые данные на нужный узел. Это обеспечивает репликацию в случае миграции ВМ на другой узел кластера.
Management Experience — инструменты для управления репликацией. Сюда входят следующие компоненты:
• Hyper-V Manager UI — интерфейс Hyper-V Manager;
• Failover Cluster Manager UI — интерфейс Failover Cluster;
• Scripting — модуль Hyper-V для управления репликацией с помощью PowerShell;
• Hyper-V Replica APIs — программный интерфейс, может использоваться сторонними управляющими приложениями;
• Remote Management — средства удаленного управления (RSAT).
Безопасность
Одним из плюсов технологии Hyper-V Replica является то, что нахождение основного сервера и сервера-реплики в одном домене/рабочей группе не является обязательным. Если вы используете репликацию между некластерными узлами, то членство в домене совсем не обязательно (для кластеров, естественно, домен необходим). В связи с этим стоит затронуть некоторые вопросы безопасности:
• Используется новая упрощенная модель авторизации. При установке на сервер роли Hyper-V создается локальная группа Hyper-V Administrators, которая может использоваться для управления репликацией наряду с локальными администраторами сервера;
• Серверы-реплики можно настроить на принятие входящих соединений только от определенных серверов. Ограничения могут быть как по FQDN, так и по доменному суффиксу (напр. *.contoso.com);
• Можно настроить правила брандмауэра серверов-реплик на принятие входящих соединений только по определенному порту;
• В доменной среде взаимная аутентификация осуществляется на основе встроенной проверки подлинности (Kerberos) между доверенными доменами. Во внедоменной инфраструктуре должны использоваться сертификаты.
Примечание. По умолчанию трафик репликации не шифруется. Хотя в Kerberos и есть механизм шифрования, HVR его не задействует. Поэтому, если требуется шифрование, необходимо использовать аутентификацию на основе сертификатов.
Принцип работы
Сначала между основным сервером и репликой устанавливается соединение и производится первоначальная репликация (Initial Replication), в ходе которой на резервной площадке создается реплика виртуальной машины. Реплика находится в выключеном состоянии и по умолчанию не подключена к виртуальной сети.
Затем в дело вступает механизм Delta Replication. На основном узле все изменения, происходящие с VHD-дисками соответствующей ВМ отслеживаются и записываются в лог репликации (Hyper-V Replica Log file, HRL). Это файл с расширением .hrl, находящийся в той же директории, что и VHD. Каждому VHD ставится в соответствие свой HRL-файл, каждая операция записи в виртуальной машине соответствует записи на VHD и записи в HRL.
Примечание. Реплицируются лишь дисковые изменения, состояние памяти ВМ не затрагивается.
Раз в 5 минут изменения передаются на сервер-реплику. Для этого текущий HRL останавливается и отправляется на резервный сервер, создается новый HRL и все изменения пишутся уже в него. Переданные изменения применяются к VHD-диску реплики, после чего на основной сервер приходит уведомление об успешной операции и процесс передачи начинается по новой. При таком подходе каждый раз передаются только последние изменения. Передаваемые данные разбиваются на части размером 2 MB и сжимаются, а если используется HTTPS, то еще и шифруются.
Периодичность передачи данных составляет 5 минут, изменить ее нельзя. Таким образом, в нормальном состоянии копия машины отстаёт от оригинала не более чем на пять минут. Если же в течение 5 минут не удалось передать изменения, то в состоянии репликации появится предупреждение. Попытки передать изменения будут продолжаться еще 25 минут, а затем репликация остановится и перейдет в аварийное состояние. После этого для восстановления работы репликации потребуется вмешательство администратора.
Вот так в общих чертах выглядит технология Hyper-V Replica в Windows Server 2012. Более подробно о настройке репликации я расскажу во второй части статьи.
Использование Microsoft Azure в качестве резервного ЦОД-а
Высокую доступность виртуальных машин (ВМ) Hyper-V можно обеспечить разными способами. Один из таких способов, Hyper-V Replica, позволяет реплицировать критические для бизнеса компании ВМ в другое физическое расположение, например, в резервный ЦОД. В этом случае мы реализуем катастрофоустойчивое решение, и даже потеря всего ЦОД-а не приведет к потере ВМ. Но много ли компаний могут позволить себе иметь резервный ЦОД? А если его нет, но устойчивость к сбоям на уровне площадки все же необходима? Сервис Azure Site Recovery недавно был обновлен таким образом, что теперь вы можете настроить реплику ваших ВМ прямо в облако Microsoft, используя Microsoft Azure в качестве «резервного ЦОД-а». Здесь можно посмотреть, как это выглядит. Мы дальше рассмотрим возможные сценарии и реализацию одного из них.
Hyper-V Replica и катастрофоустойчивость?
Hyper-V Replica, впервые появившаяся в Windows Server 2012, представляет собой механизм асинхронной репликации ВМ. В минимальной конфигурации для работы Hyper-V Replica необходимы два хоста с поднятой ролью Hyper-V, связанные каким-либо каналом передачи данных. После настройки репликации для выбранной ВМ на целевом хосте создается копия этой ВМ (в выключенном состоянии), и далее с исходного хоста с определенным интервалом передаются изменения, происходящие в оригинальной ВМ. В Windows Server 2012 интервал репликации составляет 5 мин., в Windows Server 2012 R2 – может быть выбран из трех допустимых значений: 30 сек., 5 мин., 15 мин.
В случае недоступности оригинальной ВМ вследствие падения хоста или любых других проблем, администратор инициирует переключение на реплику. На целевом хосте при этом запускается реплицированная ВМ, после чего остается переключить клиентов на эту ВМ, у которой может быть другой IP, другие настройки VLAN и пр. При подобном незапланированном сбое (unplanned failover) в силу асинхронной репликации возможны потери данных (с момента последней репликации до момента сбоя). Мы также можем использовать запланированное переключение на реплику (planned failover), например, для выполнения каких-либо задач сервисного обслуживания на исходном сервере или в основном сайте. В этом случае Hyper-V Replica гарантирует передачу всех изменений с момента последней репликации, прежде чем остановит оригинальную ВМ и запустит реплицированную.
Azure Site Recovery (ASR)
Набор облачных служб Azure Site Recovery (ранее Azure Hyper-V Recovery Manager) изначально как раз и задумывался как такой оркестратор процессов репликации и переключения в случае запланированных или незапланированных простоев.
Обратите внимание, что каналы связи с Azure используются для настройки, мониторинга и управления при переключении между площадками. Трафик же репликации передается не через облако, а по тем каналам между ЦОД-ами, которые у вас используются.
Благодаря ASR, у нас есть третья точка наблюдения/оркестрации, высокую доступность которой обеспечивает Microsoft. Более того, вам не нужно сначала настраивать репликацию на хостах. После того как настроен канал связи Azure – ЦОД, прямо на портале управления Azure вы сможете увидеть информацию о ваших частных облаках, хостах и ВМ и отсюда же настроить репликацию. Канал Azure – ЦОД защищается с помощью сертификатов, поддерживается настройка подключения через proxy-серверы, причем применительно к вашей инфраструктуре эти подключения являются исходящими. Наконец, план восстановления позволяет описывать логику failover, включая запуск скриптов, которые могут выполнять самый широкий спектр задач – от открытия портов до изменения параметров виртуальной машины. Все составляющие плана восстановления, в том числе скрипты, также хранятся в Azure, чем обеспечивается их высокая доступность. Выражаясь образно, настроив Azure Site Recovery, мы получили «аварийную кнопку», нажать которую и тем самым запустить процесс восстановления можно из любой точки, где есть Интернет.
Описанная выше архитектура подразумевает наличие у организации минимум двух ЦОД-ов. Коль скоро речь идет об использовании Hyper-V Replica, предполагается, что средой виртуализации управляет System Center Virtual Machine Manager (VMM). Так вот в самой первой реализации Azure Site Recovery связь между Azure и ЦОД представляла собой связь между Azure и VMM, для чего на VMM устанавливался специальный провайдер. С помощью провайдера VMM сообщает Azure о конфигурации физической и виртуальной среды и получает от Azure запросы мониторинга и команды управления, например, с заданными администратором параметрами репликации, которые VMM применяет к необходимым хостам Hyper-V и ВМ.
Несколько площадок и обязательное использование VMM, очевидно, ограничивало сферу применения Azure Site Recovery. Недавние обновления этого сервиса позволяют теперь реализовать новые сценарии. Давайте посмотрим на них.
Сценарии использования Azure Site Recovery
Репликация ВМ между сайтом VMM и Microsoft Azure
Я не буду описывать процесс настройки репликации. Если инфраструктура VMM развернута, частные облака созданы, ВМ запущены, вы можете воспользоваться очень неплохим пошаговым руководством здесь. Отмечу лишь несколько важных моментов.
Во-первых, поддерживается только последняя версия VMM – System Center 2012 R2 Virtual Machine Manager, при этом на хостах, которыми он управляет, может использоваться как Windows Server 2012, так и Windows Server 2012 R2. Много полезной информации по миграции с более старых версий моно найти вот в этой подборке материалов.
Во-вторых, репликацию в Azure можно настроить только для ВМ первого поколения (Generation 1), причем не важно, используют они в качестве виртуальных жестких дисков файлы VHD или VHDX.
Настройка репликации начинается с создания на портале управления Azure так называемого recovery vault – хранилища, которое будет содержать все настройки Azure Site Recovery, включая планы восстановления, но не реплики ВМ. Последние, как и любые другие ВМ в Azure, создаются в учетных записях хранения (storage accounts). Для учетной записи хранения, которая будет использоваться под реплику, должна быть включена опция гео-репликации, и располагаться эта учетная запись должна в том же регионе (location), что и recovery vault.
После установки провайдера на VMM и агентов на хосты Hyper-V, на портале Azure вы увидите информацию обо всех созданных в VMM облаках. Защиту необходимо сначала включить для облака,
а затем для необходимых ВМ в этом облаке.
Иными словами, ВМ, которые вы хотите реплицировать в Azure, должны быть ассоциированы с облаками VMM.
При настройке репликации конкретной ВМ мастер предложит шаблон ВМ в Azure (target size), наиболее подходящий для защищаемой машины. Хотя этот параметр вы можете изменить по своему усмотрению. В моем примере для двухъядерной машины с 4 ГБ ОЗУ был предложен шаблон D2. Замечу, защищаемая ВМ использует динамическую память, 4 ГБ – это максимальный объем в настройках динамической памяти. Именно на него ориентируется Azure при выборе шаблона.
В нижней части рисунка вы видите еще одну принципиальную настройку – network mapping. С помощью этого механизма вы фактически указываете, к какой виртуальной сети Azure подключит реплицированную ВМ, когда произойдет плановый или внеплановый failover. В параметрах этой виртуальной сети как минимум задается адресное пространство, в данном примере 10.2.1.0/24. Но кроме этого, можно настроить VPN-туннель между данной виртуальной сетью и вашей инфраструктурой. Тогда после failover ВМ в Azure сможет взаимодействовать через туннель с другими машинами вашей сети. Конечно за исключением ситуации, когда туннель связывал Azure с тем самым датацентром, который мы потеряли после сбоя.
Хотелось бы еще раз подчеркнуть, что после установки провайдера и агентов, все действия по настройке осуществляются на портале Azure. После того, как вы настроили репликацию, можно проверить, что на всех хостах Hyper-V защищаемого облака действительно включилась Hyper-V Replica (по умолчанию она выключена), и изменения регулярно реплицируются в Azure. Проверить это можно как на портале Azure по журналам в разделе JOBS, вот один из примеров:
Так и непосредственно в консоли Hyper-V на хосте, где запущена защищаемая ВМ:
Последний важный момент – это план восстановления. В моем самом простом демонстрационном сценарии это план выглядит вот так:
Наконец, реальные ситуации могут быть сколь угодно сложные, и полностью автоматизировать процесс переключение на резервные ВМ не удастся. Какие-то шаги потребуют вмешательства ИТ-персонала. В план восстановления можно добавить такие «ручные» действия.
Тогда выполнение плана восстановления будет приостановлено на данном шаге до тех пор, пока администратор не выполнит необходимые действия и не нажмет кнопку, подтвердив завершение этого шага. После чего выполнение плана будет продолжено.
Предположим, план восстановления полностью готов, что дальше? Дальше крайне рекомендуется выполнить тестирование отработки сбоя. Большим плюсом Hyper-V Replica является то, что такое тестирование вы можете выполнить, не нарушая уже настроенный процесс репликации. Операция Test Failover фактически создает снимок реплицированной ВМ и на его основе создает и запускает копию реплицированной ВМ с именем Имя_ВМ-Test. Эту ВМ имеет смысл подключить к изолированному сегменту сети и проверить, как себя ведет приложение внутри, как к нему смогут подключиться тестовые клиенты и пр. При этом собственно репликация между оригинальной и реплицированной ВМ продолжается. Ровно такую же возможность предоставляет Azure Site Recovery при репликации ВМ в облако Microsoft. Мы можем создать в Azure некоторую тестовую виртуальную сеть, затем выбрать план восстановления, нажать внизу кнопку TEST FAILOVER и выбрать сеть, к которой будет подключена копия реплицированной ВМ.
Когда создание ВМ завершится, мы сможем выполнить все необходимые проверки и тесты. О завершении тестирования мы должны оповестить Azure, нажав The test failover is complete, после чего тестовая ВМ будет автоматически удалена.
Теперь, когда все готово, проверки выполнены, мы и получили ту самую «аварийную кнопку», которую можно использовать для планового или внепланового переключения.
И я всячески желаю, чтобы для последнего варианта нажимать на нее вам так и не потребовалось бы.
Будни администратора
Наступил тот момент, когда мне пришлось поднимать репликацию на 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 нет) к себе на рабочую машину отсюда:
Забираем makecert.exe и копируем его на хосты w2012a и w2012b в Windows\System32. Теперь работаем на основном хосте виртуализации w2012a:
Создаем самоподписанный сертификат корневого ЦС, коим будет являться сам хост:
Файл сертификата MainSiteRootCA.cer создается в каталоге C:\Windows\sysWOW64
Копируем его, для отправки на сервер-реплику w2012b
Создаем верификационный сертификат хоста виртуализации, подписанный самоподписанным сертификатом корневого ЦС со свойствами клиентской и серверной аутентификации (это обязательные атрибуты для сертификата авторизации при репликации)
Файл сертификата MainSiteCert.cer создается в каталоге C:\Windows\sysWOW64
Его тоже копируем себе, для отправки на w2012b.
Теперь работаем на хосте-реплике w2012b (действия те же самые, корневой сертификат, сертификат сервера, копируем файлы сертификатов для передачи на w2012a):
Теперь на оба хоста копируем перекрестно файлы сертификатов самоподписанных корневых ЦС в произвольное место, допустим в каталоги C:\Temp
Импортируем сертификаты. На w2012a импортируем сертификат реплики
На w2012a импортируем сертификат основного хоста
Так как самоподписанные сертификаты не поддерживают списки отзывов, нам необходимо выключить проверку 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 работают виртуальные машины, требующие репликации. Настраиваем репликацию.
Далее в свойствах виртуальных машины на 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.
Обратил внимание, что после такой процедуры, виртуальная машина отключается от сети. После всех манипуляций подключаем ее к нужному виртуальному свичу, благо это можно сделать «на лету».
А в случае, когда машины автоматически стартуют, работаем через процедуру Resume replication и ресинхронизацию и контролируем split-brain. Замечу что данный вариант не работает с виртуальными машинами без компонент интеграции. Для таких машин можно работать только по первому варианту.
В случае, когда восстановление основного хоста невозможно, а вместо него вводится в строй новый хост с новым гипервизором, необходимо повторить процедуру обмена сертификатами, разорвать репликацию на сервере реплики, (путем выбора Remove Replication в контекстном меню виртуальной машины), создать репликацию заново и отработать последовательность Planned Failover/Failover.