Продолжаем исследовать технологию Hyper-V Replica в Windows Server 2012. В первой, теоретической части статьи мы рассмотрели архитектуру и принцип работы технологии, сегодня перейдем к практике и рассмотрим настройку репликации.
Перед настройкой Hyper-V Replica необходимо соблюсти некоторые требования. Требования, надо сказать, довольно скромные — 2 площадки с серверами Windows Server 2012 с установленной ролью Hyper-V и канал связи между ними. При использовании HTTPS дополнительно потребуется цифровой сертификат. Если требования соблюдены, можно приступать к настройке.
Примечание. Для репликации стоит выбирать сервера с одинаковой архитектурой процессора. Для самого процесса репликации это не важно, но при различии в архитектуре реплика ВМ может не запуститься.
Настройка сервера
Для работы репликации необходимо активировать функционал Hyper-V Replica и настроить взаимодействие между серверами. Для этого открываем Hyper-V Manager и переходим в раздел «Hyper-V Settings».
Нас интересует раздел «Replication Configuration», в котором находятся настройки репликации на уровне сервера. В нем мы указываем использовать компьютер как сервер реплики, отметив соответствующий чекбокс.
Затем выбираем тип аутентификации, который будет использоваться при репликации. Если сервера являются членами одного домена или находятся в разных, доверяющих друг другу доменах, то можно выбрать Kerberos. Во внедоменной среде (а также при необходимости шифрования) есть возможность использовать аутентификацию на основе цифровых сертификатов.
Для повышения безопасности можно изменить порт для входящей репликации. По умолчанию репликация производится по стандартным портам 80 (HTTP) или 443 (HTTPS). При необходимости это можно изменить и задать любой доступный порт.
Затем разрешаем входящую репликацию и указываем директорию для хранения реплик. Здесь возможны два варианта:
• Alow replication from any authentificated server — принимать входящую репликацию от любых аутентифицированных серверов и все реплики хранить в одном месте;
• Alow replication from specific servers — список серверов заполняется вручную, для каждого сервера можно указать свою директорию хранения. Сервера можно объединять в группы (trust group), что позволяет хранить на одном сервере реплики разных владельцев.
Сохранив необходимые параметры, закрываем окно настроек. Повторяем процедуру настройки на всех серверах, участвующих в репликации.
Не забудьте открыть нужный порт для входящей репликации. Для этого надо в настройках брандмауэра Windows активировать входящее правило «Hyper-V Replica HTTP Listener (TCP-In)» для HTTP или «Hyper-V Replica HTTPS Listener (TCP-In)» для HTTPS. Эти правила предопределены и не настраиваются, поэтому при использовании нестандартных портов придется создавать настраиваемое правило.
Настройка репликации
Настроив сервера, можно приступать к репликации виртуальной машины. Для примера будем настраивать репликацию виртуальной машины TestVM с основного сервера Gateway-01 на резервный сервер Gateway-02. Заходим на основной сервер, выделяем нужную ВМ, кликаем на ней правой клавишей и в открывшемся меню выбираем пункт «Enable Replication».
Запускается мастер настройки репликации. Все как обычно, первое окно пропускаем 🙂
В следующем выбираем сервер, на котором будет находится реплика выбраной машины. Если в качестве резервной площадки выступает кластер, то надо указывать сервер с установленной ролью Replica Broker.
Затем выбираем тип аутентификации между серверами. Поскольку в настройках сервера мы указали HTTP, то здесь можем только подтвердить этот выбор. Также внизу есть неприметная галочка, отвечающая за сжатие передаваемых данных, по умолчанию она включена.
В следующем окне отображаются все VHD-диски выбраной виртуальной машины. Если среди них есть не нуждающиеся в репликации, то можно исключить их из процесса, сняв выделение.
Затем идет окно, в котором выбирается количество точек восстановления (recovery points), хранящихся на сервере реплики. Есть два варианта:
• Хранить только одну, последнюю точку восстановления;
• Хранить дополнительные точки восстановления (снапшоты). Снапшоты будут создаваться каждый час. Этот вариант дает возможность восстановить реплику на заданное время, но требует дополнительного дискового пространства для хранения снапшотов.
Если выбраны дополнительные точки восстановления, то можно выбрать репликацию с помощью теневых копий (Volume Shadow Copy Service, VSS). В этом случае мы получаем не просто копию диска на определенное время, а его точный снимок (включая открытые файлы). Для некоторых приложений (например базы данных) это может быть критично, поэтому этот тип репликации назван application-consistent. Частоту создания теневых копий можно регулировать с интервалом от 1 до 12 часов.
Примечание. Важно понимать, что частота создания дополнительных точек восстановления не зависит от частоты репликации. Изменения передаются каждые 5 минут, а вот применяются уже в зависимости от выбора — либо к основному диску, если выбрано хранить одну точку восстановления, либо к наиболее свежему снапшоту в случае дополнительных точек восстановления.
Идем дальше и выбираем способ первоначальной репликации (Initial Replication):
• Передать копию виртуальной машины по сети. Этот выбор сразу запускает копирование ВМ по сети;
• Переправить копию машины на съемном носителе. В этом случае выбраная машина копируется на указаный носитель (напр. съемный жесткий диск или флешку) и переносится на сервер реплики вручную;
• Использовать существующую виртуальную машину в качестве первоначальной копии. Здесь мы указываем копию ВМ, перенесенную на съемном носителе или любым другим способом.
Репликацию можно начать немедленно или запланировать на определенное время.
И вот наконец окно с суммарной информацией. Проверяем, все ли правильно, и жмем Finish, запуская первоначальную репликацию. В зависимости от ширины канала это займет некоторое время.
По умолчанию реплика ВМ не подключена к виртуальной сети, поэтому сразу после окончания первоначальной репликации нам будет предложено настроить ее сетевые параметры. В принципе настройку можно произвести и позже, но мы не будем откладывать это дело. Жмем на кнопку «Settings… »
и переходим в настройки сети TestVM на резервном сервере. Сначала производим основные настройки — подключаем реплику к виртуальному коммутатору, при необходимости указываем VLAN и выставляем ограничения по трафику.
Затем открываем дополнительные настройки сети и переходим на вкладку «Failover TCP/IP». Здесь задаются альтернативные настройки сетевого подключения (IP-адрес, маска подсети, шлюз и DNS сервера), с которыми реплика будет запущена при отработке отказа. При файловере альтернативные настройки статически прописываются внутри виртуалки, заменяя введенные ранее. Так как репликация возможна в обе стороны, эти настройки необходимо производить как на основном, так и на резервном сервере.
Примечание. Альтернативные настройки нужны только в случае, если используется статическая адресация. При использовании DHCP заполнять их не надо.
И еще одна вкладка — «Test Failover». В ней мы можем указать виртуальный коммутатор, к которому будет подключена реплика при тестовом файловере. Поскольку при тестировании основная машина продолжает работу, то реплику лучше подключить к отдельной изолированой сети, дабы избежать конфликта.
На этом настройку репликации можно считать законченой. На основном сервере TestVM продолжает работать, как и раньше. Состояние репликации показано внизу, на вкладке «Replication». В ней указано, что это основной (Primary) экземпляр виртуальной машины.
На резервном сервере TestVM находится в выключеном состоянии, а на вкладке «Replication» указано, что это реплика. Дополнительные точки восстановления, если они были выбраны при настройке, будут отображаться в виде снапшотов.
Хотя реплика и выглядит как обыкновенная виртуалка, взять и просто включить ее не получится. Для активации реплики необходимо запускать процесс Failover. О вариантах файловера и пойдет речь в третьей частьи статьи.
А как сделать сертификат для hyper v? Чтобы работало через hhtps.