Миграция VM с Hyper-V на Hyper-V кластер
В этой статье рассмотрим Live миграцию виртуальных машин с Hyper-V сервера на Hyper-V кластер.
Имеем Hyper-V сервер — Hyper-V-1 с IP 192.168.100.190.
Один из серверов кластера Hyper-V это SRV-1 с IP 192.168.100.81.
Сервер Hyper-V и кластер Hyper-V находятся в домене.
Идем на сервер Hyper-V и включаем в настройках Hyper-V поддержку Live Migration. Добавляем IP-адреса обеих серверов. На сервере кластера Live Migration уже была включена при настройке кластера, осталось только добавить IP-адрес Hyper-V сервера с которого будем мигрировать.
На обеих серверах включаем поддержку Live Migration и добавляем IP-адреса участников. 
Далее идем на сервер DC, заходим в оснастку ADUC. Находим SRV-1, заходим в Properties, выбираем вкладку Delegation.
Выбираем опции: Trust this computer for delegation to specified services only и Use Kerberos only и нажмите на кнопку Add.
В следующем окне нажимаем кнопку Users and Computers и указываем имя сервера Hyper-V-1. В списке доступных служб выбираем Microsoft Virtual System Migration Service и cifs.
Те же действия выполняем и для Hyper-V-1.
Возвращаемся на сервер Hyper-V-1, выбираем VM для миграции.
Начинаем миграцию VM. В качестве типа миграции выбираем Move the virtual machine.
Выбираем сервер на который будет мигрировать машина.
Далее выбираем папку для миграции. Так как у нас машина мигрирует на кластер, то обязательно выбираем
C:\ClusterStorage\Volume1\ и добавляем нужную подпапку.
Если появилась такая ошибка:
То необходимо выключить VM и включить для нее режим совместимости CPU:
Запускаем VM. Снова запускаем миграцию. Ожидаем окончания миграции.
Переходим на сервер кластера SRV-1. Заходим в оснастку Failover Cluster Manager. Здесь нам необходимо смигрированную виртуальную машину на сервер SRV-1 перенести на кластер.
Выбираем Roles->Configure Roles.
Выбираем Virtual Machine.
И указываем машину.
Теперь наша смигрированная VM находится в кластере. Можем протестировать Live Migration уже в кластере, что бы убедится, что все выполнено правильно. Не забываем указать:
В параметрах машины Automatic Start Action — Automatically Start и задержку старта, что бы избежать перегрузки системы.
В свойствах виртуальной машины (Properties) — предпочтительные узлы, в порядке убывания и настраиваем Failover (обработку отказов и восстановление размещения).
Добавление серверов Windows в качестве узлов или кластеров Hyper-V в структуре вычислений VMM
Поддержка этой версии Virtual Machine Manager (VMM) прекращена. Рекомендуем перейти на VMM 2019.
Из этой статьи вы узнаете, как добавлять существующий сервер Windows в качестве кластера или сервера узла Hyper-V в структуру System Center Virtual Machine Manager (VMM), а также как настраивать свойства узлов и кластеров.
Приведенное здесь описание подходит для добавления серверных компьютеров Windows как с ролью Hyper-V, так и без нее. При добавлении сервера Windows без установленной роли Hyper-V компонент VMM установит ее при условии, что сервер отвечает предварительным требованиям.
Перед началом работы
Предварительные требования для добавления существующего сервера узла или кластера Hyper-V зависят от того, установлен ли Hyper-V и где расположен сервер.
| Расположение узла | Необходимое условие |
|---|---|
| Сервер без Hyper-V | Если вы хотите добавить сервер без установленного Hyper-V, он должен соответствовать предварительным требованиям для установки Hyper-V. Сервер должен работать под управлением поддерживаемых версий Windows Server. Если нужно добавить сервер управления VMM в качестве управляемого узла Hyper-V, сначала потребуется установить на сервере роль Hyper-V. В качестве управляемого кластера узлов Hyper-V нельзя добавить высокодоступный сервер управления VMM. В этой статье предполагается, что на добавляемом сервере уже запущена операционная система. Если требуется добавить компьютер без операционной системы в качестве узла или кластера Hyper-V, ознакомьтесь с этой статьей. |
| Тот же домен, что и для сервера VMM, либо двусторонний доверенный домен | Необходимо указать учетные данные учетной записи с правами администратора на добавляемых компьютерах. Можно ввести имя пользователя и пароль или указать учетную запись запуска от имени. Если для настройки параметров удаленного управления Windows (WinRM) используется групповая политика, ознакомьтесь со следующими параметрами: Параметры службы WinRM должны быть настроены с использованием групповой политики и могут применяться только к узлам, которые находятся в доверенном домене Active Directory. В частности, VMM поддерживает настройку параметров групповой политики «Разрешить автоматическую настройку прослушивателей», «Включить HTTP-прослушиватель совместимости» и «Включить HTTPS-прослушиватель совместимости». VMM не поддерживает настройку параметров политики службы WinRM. С помощью групповой политики невозможно настроить параметры клиента WinRM. Эти параметры политики могут переопределить свойства клиента, которые требуются VMM для правильной работы агента VMM. Если включены неподдерживаемые параметры групповой политики удаленного управления Windows, может произойти сбой установки агента VMM. |
| Недоверенный домен | VMM не поддерживает настройку параметров групповой политики удаленного управления Windows (WinRM) (службы или клиента) на узлах, которые находятся в недоверенном домене Active Directory. Если параметры групповой политики WinRM включены, установка агента VMM, необходимого на узлах, может завершиться ошибкой. В недоверенном домене VMM также создает сертификат во время установки агента на серверах или в кластерах. Сертификат используется для защиты связи с узлом. Когда VMM добавляет узел или кластер, сертификат автоматически импортируется в хранилище доверенных сертификатов сервера управления VMM. |
| Несвязанное пространство имен (DNS-суффикс не соответствует домену, членом которого является) | Служба System Center Virtual Machine Manager должна выполняться от имени учетной записи Local System или учетной записи домена, имеющей разрешения на регистрацию имен субъектов-служб (SPN) в Active Directory. Если кластер узлов находится в несвязанном пространстве имен, а сервер управления VMM — нет, добавьте DNS-суффикс для кластера узлов в параметрах TCP/IP-подключения на сервере управления VMM. Если для настройки параметров удаленного управления Windows (WinRM) используется групповая политика, ознакомьтесь со следующими необходимыми условиями: Параметры службы WinRM должны быть настроены с использованием групповой политики и могут применяться только к узлам, которые находятся в доверенном домене Active Directory. В частности, VMM поддерживает настройку параметров групповой политики «Разрешить автоматическую настройку прослушивателей», «Включить HTTP-прослушиватель совместимости» и «Включить HTTPS-прослушиватель совместимости». VMM не поддерживает настройку параметров политики службы WinRM. С помощью групповой политики невозможно настроить параметры клиента WinRM. Эти параметры политики могут переопределить свойства клиента, которые требуются VMM для правильной работы агента VMM. Если включены неподдерживаемые параметры групповой политики удаленного управления Windows, может произойти сбой установки агента VMM. |
| Сеть периметра или рабочая группа | Потребуется установить агент локально на целевом узле. Для этого запустите программу установки VMM с правами администратора и выберите Дополнительные установки > Локальный агент. В разделе Папка с файлом безопасности выберите Этот узел входит в сеть периметра и введите ключ шифрования. В разделе Сетевое имя узла укажите, как сервер VMM может связаться с сервером узла, а также запомните IP-адрес или имя компьютера. Завершите мастер. Убедитесь, что файл SecurityFile.txt находится на сервере VMM. По умолчанию он находится в папке C:\Program Files\Версия Microsoft System Center\Virtual Machine Manager. |
После установки агента VMM на узле учетная запись локального компьютера автоматически добавляется в локальную группу администраторов. Это не обязательное требование для агента VMM. При необходимости вы можете вручную удалить учетную запись локального компьютера из группы администраторов на узле.
Добавление серверов
В консоли VMM откройте область Структура > Серверы.
Щелкните Добавить группу > Добавить ресурсы > Узлы и кластеры Hyper-V.
В разделе Мастер добавления ресурсов > Расположение ресурса укажите, где расположен добавляемый сервер.
В разделе Учетные данные введите учетные данные для учетной записи домена, которая имеет права администратора на всех добавляемых узлах. (Для компьютеров в домене без доверия необходимо использовать учетную запись запуска от имени.)
Указанные выше учетные данные или учетная запись запуска от имени должны быть локальными администраторами на хост-компьютерах. Если указана учетная запись запуска от имени, она будет использоваться при добавлении узла, а также для предоставления в будущем доступа к узлу за время его существования. Если учетные данные указаны вручную, они будут использоваться только при добавлении узла. После успешного добавления узла учетная запись службы VMM будет добавлена в качестве локального администратора на узле и использована для предоставления доступа к нему в будущем.
В разделе Область обнаружения укажите:
В разделе Целевые ресурсы укажите компьютеры, которые требуется добавить. Повторите процедуру для всех узлов. В случае успешного обнаружения узел появится в разделе Имя компьютера. Добавьте следующее:
В списке Параметры узла > Группа узлов выберите группу узлов, которой нужно назначить узел или кластер узлов. Если узел уже связан с другим сервером управления VMM, выберите Связать этот узел с данной средой VMM. Если узел был связан с другим сервером управления VMM, он перестанет работать на этом сервере.
На странице Сводка проверьте параметры и нажмите кнопку Готово. Откроется диалоговое окно Задания с отображением состояния задания. Дождитесь перехода задания в состояние «Завершено». Убедитесь, что узел или кластер были добавлены для имени узла или кластера в группе узлов. Состояние должно иметь значение ОК.
Настройка свойств для узлов Hyper-V
После добавления узлов и серверов Hyper-V в структуру VMM можно настроить отдельные узлы и кластеры с помощью ряда свойств.
| Вкладка | Параметры |
|---|---|
| Общие | Просмотр сведений об удостоверении и системе для узла. Эти сведения включают данные о процессоре, общем и доступном объеме памяти и хранилища, операционной системе, типе низкоуровневой оболочки, версии агента VMM. Ввод описание узла. Настройка доступности узла для размещения. Настройка порта удаленного подключения. По умолчанию для этого параметра установлено значение 2179. |
| Оборудование | Просмотр и изменение параметров для ЦП, памяти, графических процессоров (GPU), хранилища (включая доступность хранилища для размещения), сетевых адаптеров, дисков DVD//CD-ROM и параметров контроллера управления основной платой (BMC). |
| Состояние | Содержит сведения о состоянии работоспособности для узла. Включает такие направления, как общая работоспособность, работоспособность роли Hyper-V и работоспособность агента VMM. В области Состояние можно выполнять следующие действия: Просматривать сведения об ошибках. Обновлять состояние работоспособности. Использовать кнопку Восстановить все. VMM попытается автоматически исправить все ошибки. |
| Пути к виртуальной машине/Виртуальные машины | Отображает виртуальные машины, находящиеся на узле, а также сведения о состоянии. Также позволяет зарегистрировать виртуальные машины на узле. |
| Резервы | Позволяет переопределять параметры резерва узла из группы родительского узла и настраивать резервные ресурсы для узла. К настраиваемым ресурсам относятся ЦП, память, дисковое пространство, дисковые операции ввода-вывода, пропускная способность сети. |
| Хранилище | Отображает объем хранения, выделенный для узла, и позволяет добавлять и удалять логические устройства хранения и общие папки. |
| Виртуальные коммутаторы | Позволяет настраивать виртуальные коммутаторы. |
| Пути размещения/Размещение | Позволяет настраивать пути к виртуальным машинам по умолчанию, а также пути к родительским дискам по умолчанию, которые будут использоваться во время размещения виртуальной машины на узле. |
| Периоды обслуживания | Позволяет выбирать периоды обслуживания. |
| Настраиваемые свойства | Позволяет назначать настраиваемые свойства и управлять ими. |
Свойства кластеров Hyper-V
| Вкладка | Параметры |
|---|---|
| Общие | Просмотр имени, группы узлов и описания. Также можно настроить параметр Резерв кластера (узлы) и просматривать состояние резерва кластера. |
Параметр Резерв кластера (узлы) указывает число отказов узлов, которое должен выдерживать кластер, продолжая поддерживать все виртуальные машины, развернутые в кластере узлов. Если кластер не может выдержать указанное число отказов узлов, не прерывая работы всех виртуальных машин, кластеру назначается «перегруженное» состояние. Узлы перегруженного кластера получают нулевую оценку во время размещения виртуальных машин. Администратор может переопределить оценку и поместить виртуальную машину высокой доступности в перегруженный кластер вручную.
Выполняется и успешно завершается проверка кластера. Включает ссылку на последний ответ о проверке (если есть). Обратите внимание, что для получения доступа к отчету необходимы права администратора на узле кластера, где размещается отчет. Можно выполнить проверку кластера по запросу с помощью VMM. Для этого в рабочей области Структура найдите и щелкните узел кластера. Затем на вкладке Кластер узлов нажмите кнопку Проверить кластер. Проверка кластера начнется немедленно.
Онлайн-элементы в кластере: основные ресурсы кластера, диск-свидетель в кворуме и служба кластера на каждом узле.
Можно выполнить следующие действия:
удалять и добавлять логические единицы хранения, управляемые VMM;
Создание кластера Hyper-V 2016 на двух хостах
В этой небольшой инструкции мы покажем пошагово как создать простой отказоустойчивый кластер Hyper-V Cluster из двух серверов с Windows Server 2016. Такой кластер позволяет без особых проблем организовать отказоустойчивость для виртуальных машин Hyper-V при аппаратных проблемах с одним из серверов.
Предварительные требования к отказоустойчивому кластеру Hyper-V
Настройки сети Hyper V
В нашем примере мы настроим следующую IP адресацию для компонентов кластера:
Общее имя кластера: HVCLUSTER2016 (IP адрес 10.0.0.10)
Первый сервер: имя HOST01, с двумя интерфейсами
10.0.0.11 – интерфейс управления, и трафика виртуальных машин
10.0.1.11 – интерфейс для трафика Cluster Shared Volume и Heartbeat
Второй сервер: имя HOST02, с двумя интерфейсами
10.0.0.12 — интерфейс управления, и трафика виртуальных машин
10.0.1.12 – интерфейс для трафика Cluster Shared Volume и Heartbeat
Установка кластера Hyper-V
Итак, на любом из серверов запускаем оснастку Failover Cluster Manager и запускаем мастер создания кластера (Create Cluster).
На странице выбора серверов кластера добавляем обе наших ноды.
На странице Validation Warning соглашаемся с запуском встроенных тестов валидации кластерной конфигурации.
Выберите, что нужно прогнать все тесты.
Нужно дождаться окончания валидации. Если будут найдены ошибки – их нужно исправить. После этого нажать на Finish.
Далее на странице настройки Access Point for Administering the Cluster нужно указать имя кластера и его IP адрес и подсеть.
Осталось нажать 2 раза кнопку Next и мастер создаст новый кластер.
Настройка кластера Hyper-V
Задайте содержательные имена дискам. В нашем примере один кластерный диск будет использоваться как том Cluster Shared Volumes (CSV) для хранения файлов ВМ, а второй использоваться для кворума (диск небольшого размера).
Далее нужно настроить кластерный кворум. Для этого щелкните ПКМ по имени кластера и выберите пункт меню More Actions-> Configure Cluster Quorum Settings.
Выберите вариант настройки кворума для кластера Select the quorum witness.
В качестве типа кворума выберите Quorum Witness Select Disk Witness (кворум с использованием диска свидетеля).
Выберите кластерный диск, который вы хотите использовать в качестве диска-свидетеля.
Теперь в настройках Hyper-V на каждой из нод нужно указать кластерный том CSV в качестве диска по-умолчанию для хранения виртуальных машин.
Затем с помощью обычного мастера Hyper-V нужно создать новую виртуальную машину. С помощью Live Migration в дальнейшем можно убедится, что ВМ на легко перемещается между узлами кластера Hyper-V.
Кластер Hyper-v из двух нод, без внешнего хранилища или гиперконвергенция на коленке
Давным-давно, в далекой-далекой галактике…, стояла передо мной задача организовать подключение нового филиала к центральному офису. В филиале доступно было два сервера, и я думал, как было бы неплохо организовать из двух серверов отказоустойчивый кластер hyper-v. Однако времена были давние, еще до выхода 2012 сервера. Для организации кластера требуется внешнее хранилище и сделать отказоустойчивость из двух серверов было в принципе невозможно.
Однако недавно я наткнулся на статью Romain Serre в которой эта проблема как раз решалась с помощью Windows Server 2016 и новой функции которая присутствует в нем — Storage Spaces Direct (S2D). Картинку я как раз позаимствовал из этой статьи, поскольку она показалась очень уместной.
Технология Storage Spaces Direct уже неоднократно рассматривалась на Хабре. Но как-то прошла мимо меня, и я не думал, что можно её применять в «народном хозяйстве». Однако это именно та технология, которая позволяет собрать кластер из двух нод, создав при этом единое общее хранилище между серверами. Некий единый рейд из дисков, которые находятся на разных серверах. Причем выход одного из дисков или целого сервера не должны привести к потере данных.
Звучит заманчиво и мне было интересно узнать, как это работает. Однако двух серверов для тестов у меня нет, поэтому я решил сделать кластер в виртуальной среде. Благо и вложенная виртуализация в hyper-v недавно появилась.
Для своих экспериментов я создал 3 виртуальные машины. На первой виртуальной машине я установил Server 2016 с GUI, на котором я поднял контроллер AD и установил средства удаленного администрирования сервера RSAT. На виртуальные машины для нод кластера я установил Server 2016 в режиме ядра. В этом месяце загадочный Project Honolulu, превратился в релиз Windows Admin Center и мне также было интересно посмотреть насколько удобно будет администрировать сервера в режиме ядра. Четвертная виртуальная машина должна будет работать внутри кластера hyper-v на втором уровне виртуализации.
Для работы кластера и службы Storage Spaces Direct необходим Windows Server Datacenter 2016. Отдельно стоит обратить внимание на аппаратные требования для Storage Spaces Direct. Сетевые адаптеры между узлами кластера должны быть >10ГБ с поддержкой удаленного прямого доступа к памяти (RDMA). Количество дисков для объединения в пул – минимум 4 (без учета дисков под операционную систему). Поддерживаются NVMe, SATA, SAS. Работа с дисками через RAID контроллеры не поддерживается. Более подробно о требованиях docs.microsoft.com
Если вы, как и я, никогда не работали со вложенной виртуализацией hyper-v, то в ней есть несколько нюансов. Во-первых, по умолчанию на новых виртуальных машинах она отключена. Если вы захотите в виртуальной машине включить роль hyper-v, то получите ошибку, о том, что оборудование не поддерживает данную роль. Во-вторых, у вложенной виртуальной машины (на втором уровне виртуализации) не будет доступа к сети. Для организации доступа необходимо либо настраивать nat, либо включать спуфинг для сетевого адаптера. Третий нюанс, для создания нод кластера, нельзя использовать динамическую память. Подробнее по ссылке.
Поэтому я создал две виртуальные машины – node1, node2 и сразу отключил динамическую память. Затем необходимо включить поддержку вложенной виртуализации:
Включаем поддержку спуфинга на сетевых адаптерах ВМ:
HDD10 и HDD 20 я использовал как системные разделы на нодах. Остальные диски я добавил для общего хранилища и не размечал их.
Сетевой интерфейс Net1 у меня настроен на работу с внешней сетью и подключению к контроллеру домена. Интерфейс Net2 настроен на работу внутренней сети, только между нодами кластера.
Для сокращения изложения, я опущу действия необходимые для того, чтобы добавить ноды к домену и настройку сетевых интерфейсов. С помощью консольной утилиты sconfig это не составит большого труда. Уточню только, что установил Windows Admin Center с помощью скрипта:
По сети из расшаренной папки установка Admin Center не прошла. Поэтому пришлось включать службу File Server Role и копировать инсталлятор на каждый сервер, как в мс собственно и рекомендуют.
Когда подготовительная часть готова и перед тем, как приступать к созданию кластера, рекомендую обновить ноды, поскольку без апрельских обновлений Windows Admin Center не сможет управлять кластером.
Приступим к созданию кластера. Напомню, что все необходимые консоли у меня установлены на контролере домена. Поэтому я подключаюсь к домену и запускаю Powershell ISE под администратором. Затем устанавливаю на ноды необходимые роли для построения кластера с помощью скрипта:
И перегружаю сервера после установки.
Запускаем тест для проверки готовности нод:
Отчёт в фомате html сформировался в папке C:\Users\Administrator\AppData\Local\Temp. Путь к отчету утилита пишет, только если есть ошибки.
Ну и наконец создаем кластер с именем hpvcl и общим IP адресом 192.168.1.100
После чего получаем ошибку, что в нашем кластере нет общего хранилища для отказоустойчивости. Запустим Failover cluster manager и проверим что у нас получилось.
И получаем оповещение, что не найдены диски для кэша. Поскольку тестовая среда у меня на SSD, а не на HDD, не будем переживать по этому поводу.
Затем подключаемся к одной из нод с помощью консоли powershell и создаем новый том. Нужно обратить внимание, что из 4 дисков по 40GB, для создания зеркального тома доступно порядка 74GB.
На каждой из нод, у нас появился общий том C:\ClusterStorage\Volume1.
Кластер с общим диском готов. Теперь создадим виртуальную машину VM на одной из нод и разместим её на общее хранилище.
Для настроек сети виртуальной машины, необходимо будет подключиться консолью hyper-v manager и создать виртуальную сеть с внешним доступом на каждой из нод с одинаковым именем. Затем мне пришлось перезапустить службу кластера на одной из нод, чтобы избавиться от ошибки с сетевым интерфейсом в консоли failover cluster manager.
Пока на виртуальную машину устанавливается система, попробуем подключиться к Windows Admin Center. Добавляем в ней наш гиперконвергентный кластер и получаем грустный смайлик
Подключимся к одной из нод и выполним скрипт:
Проверяем Admin Center и на этот раз получаем красивые графики
После того, как установил ОС на виртуальную машину VM внутри кластера, первым делом я проверил Live migration, переместив её на вторую ноду. Во время миграции я пинговал машину, чтобы проверить насколько быстро происходит миграция. Связь у меня пропала только на 2 запроса, что можно считать весьма неплохим результатом.
И тут стоит добавить несколько ложек дёгтя в эту гиперконвергентную бочку мёда. В тестовой и виртуальной среде все работает неплохо, но как это будет работать на реальном железе вопрос интересный. Тут стоит вернуться к аппаратным требованиям. Сетевые адаптеры 10GB с RDMA стоят порядка 500$, что в сумме с лицензией на Windows Server Datacenter делает решение не таким уж и дешёвым. Безусловно это дешевле чем выделенное хранилище, но ограничение существенное.
В заключении хотел бы сказать несколько слов о своих впечатлениях. Знакомство с новыми технологиями это был для меня весьма интересный опыт. Назвать его полезным, пока не могу. Я не уверен, что смогу применить эти навыки на практике. Поэтому у меня вопросы к сообществу: готовы ли вы рассматривать переход на гиперконвергентные решения в будущем? как относитесь к размещению виртуальных контроллеров домена на самих нодах?