Live migration, или динамическая миграция в Hyper-V дает возможность переносить работающую виртуальную машину с одного хоста на другой без ее остановки. Изначально динамическая миграция была возможна только в кластерной конфигурации, и только с использованием общего кластерного ресурса (Cluster Shared Volumes, CSV). Но с выходом Windows Server 2012 ситуация изменилась.
Теперь общее хранилище (shared storage) больше не является необходимым условием для работы Live Migration, а переносить виртуальные машины можно не только между узлами кластера. Для переноса виртуальной машины с одного хоста Hyper-V на другой достаточно того, чтобы они были связаны сетью Ethernet. Подобный тип миграции получил название Shared-nothing live migration, или Динамическая миграция в режиме ″ничего общего″.
Для возможности включения Shared-Nothing Live Migration необходимо соблюсти следующие требования:
• Два или больше сервера Windows Server 2012 c установленной ролью Hyper-V. Также можно использовать бесплатную редакцию Hyper-V Server 2012;
• Каждый сервер должен иметь доступ к собственному хранилищу виртуальных машин. В качестве хранилища можно использовать локальные диски, сети хранения (SAN) или сетевые шары SMB 3.0;
• Виртуальные машины, которые планируется мигрировать, не должны использовать подключенные напрямую (pass-through) жесткие диски;
• Для обеспечения совместимости серверы должны иметь процессоры с одинаковой архитектурой. В идеале лучше использовать идентичные серверы от одного производителя;
• Серверы должны быть членами одного домена Active Directory;
• Серверы должны быть связаны как минимум одним гигабитным сетевым соединением. Выделенная сеть для трафика миграции рекомендуется, но не обязательна;
• На сетевых адаптерах, используемых для миграции, должны быть включены Client for Microsoft Networks и File and Print Sharing for Microsoft Networks;
• Каждый Hyper-V хост должен иметь виртуальные коммутаторы с одним и тем же именем. Это нужно для того, чтобы избежать ошибок и ручных операций при выполнении миграции.
Если все эти требования соблюдены, то следующим шагом является включение миграции в настройках Hyper-V на всех серверах, участвующих в миграции. Для этого открываем Hyper-V Manager и идем в раздел «Hyper-V Settings».
Здесь нас интересует пункт «Live Migration», в котором сосредоточены настройки динамической миграции. В первую очередь ее необходимо включить, отметив соответствующий чекбокс. Затем выбираем тип аутентификации — Kerberos или CredSSP. При использовании CredSSP удаленное или автоматическое выполнение миграции невозможно, т.к. необходимо залогинится на сервере. Аутентификация Kerberos лишена этого недостатка и более безопасна, поэтому лучше использовать ее.
Дальше задаем количество одновременно перемещаемых виртуальных машин. Виртуальные машины можно мигрировать параллельно, причем количество одновременных миграций ограничено только возможностями оборудования и вашим здравым смыслом :). Чтобы избежать перегрузки, по умолчанию стоит ограничение на две одновременные миграции.
Для принимающей стороны можно указать, с каких IP принимать входящую миграцию. В качестве фильтра можно указать как отдельные IP-адреса, так и целые подсети. По умолчанию входящая миграция принимается с любых адресов.
Отдельно на вкладке «Storage Migrations» можно указать количество одновременных миграций хранилища виртуальных машин. По дефолту здесь также стоит ограничение в 2 миграции.
Закончив, жмем клавишу Apply, сохраняя сделаные настройки. Напомню, что динамическую миграцию возможно включить только на серверах, являющихся членами одного домена. В противном случае Hyper-V не даст сохранить настройки и выдаст вот такую ошибку.
Сохранив настройки, возвращаемся в основное окно и выбираем виртуальную машину, которую предстоит смигрировать. Кликаем на ней правой клавишей и выбираем пункт «Move».
Запускается мастер переноса. В стартовом окне нет ничего интересного, поэтому жмем Next.
Дальше нам предлагается выбрать, что именно нужно перенести — виртуальную машину целиком или только хранилище виртуальных дисков. Наша задача — полностью перенести ВМ на другой сервер, поэтому выбираем первый вариант и идем дальше.
В следующем окне выбираем сервер назначения, на который переедет наша виртуальная машина.
Теперь надо выбрать, как именно переносить машину, целиком или по частям. Можно поместить все компоненты в одно место, а можно выбрать для каждого из них свое размещение — отдельно виртуальные жесткие диски, отдельно снапшоты, отдельно файлы конфигурации и файл смарт-пейджинга. Третий вариант — смигрировать только саму ВМ, оставив диски на месте, возможен только при наличии общего хранилища (shared storage).
Далее указываем папку (или папки) на сервере назначения, в которую будет перенесена виртуальная машина и жмем Next.
Смотрим результирующую информацию. Если все устраивает, то жмем кнопку Finish, запуская процесс миграции.
Обратите внимание, что если имена виртуальных коммутаторов на исходном сервере и сервере назначения не совпадают, то процесс не сможет быть запущен. Данную проблему легко исправить, указав к какому коммутатору подключить виртуальную машину, но для этого потребуется вмешательство пользователя. Если вы планируете запускать миграцию в автоматическом режиме, например с помощью скриптов, то конфигурации должны быть полностью идентичны.
Теперь остается наблюдать за процессом переноса. Его продолжительность зависит от нескольких факторов:
• Пропускная способность канала между серверами;
• Текущая нагрузка на сервера;
• Объем оперативной памяти, выделенный для виртуальной машины.
У меня миграция виртуальной машины c установленной Windows Server 2012 заняла чуть больше 8 минут.
При этом для пользователя перенос проходит практически незаметно. В качестве эксперимента на время миграции я запустил утилиту ping для проверки доступности машины. Как видите, при миграции потеряно всего 6 пакетов. Хотя проверял я на ненагруженых машинах и при большой нагрузке простой может быть больше.
В заключение скажу, что Shared-nothing live migration не обеспечивает отказоустойчивость виртуальных машин и не является заменой кластерам. Тем не менее, эта технология дает возможность свободно перемещать виртуальные машины между серверами. При этом нет необходимости в дорогостоящих системах хранения данных. В общем, рекомендуется к использованию однозначно 🙂