Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP

-Ключевые новые возможности системы Windows Server 2012 Hyper-V.

-Новый тип миграции.

-После настройки хост-серверов миграция – дело техники.

В большинстве вопросов, связанных с вычислениями, основной задачей является консолидация общих ресурсов и функций в едином модуле. В такой консолидации и состоит основное назначение технологии виртуализации. Аналогичные приоритеты имел и гипервизор Windows Server 2008 R2 Hyper-V, в котором появилась возможность совместного использования томов NTFS на основе хранилища SAN всеми узлами в кластере. При таком подходе ко всем томам предоставлялся одновременный доступ с помощью технологии Cluster Shared Volumes (CSV). В версии Server 2008 R2 появился механизм миграции live migration, позволяющий перемещать виртуальные машины между узлами в кластере без простоя. «Живая» миграция выполнялась посредством копирования содержимого оперативной памяти и состояния виртуальной машины в процессе работы. .

Новые возможности

В гипервизоре Server 2012 Hyper-V реализовано несколько новых возможностей, часть которых относится к работе отказоустойчивых кластеров. Выделим два важных изменения в механизме миграции live migration в отказоустойчивом кластере.

-В системе Server 2012 механизм live migration поддерживает выполнение нескольких одновременных процессов миграции между парой хост-серверов. В предыдущей версии поддерживался только один процесс.

-Механизм отказоустойчивых серверов поддерживает использование до 64 узлов и 4000 виртуальных машин в одном отказоустойчивом кластере Server 2012 – показатели выросли на 400 % по сравнению с отказоустойчивыми кластерами Server 2008 R2 (хотя речь в данной статье пойдет не об этом).

В системе Server 2012 появился новый тип live migration: миграция без общего хранилища. Да, я не оговорился. Нет общего хранилища, нет общего кластера – все, что нужно, это лишь соединение Gigabit Ethernet между хостами Server 2012 Hyper-V. Через это соединение вы можете переносить виртуальные машины между хост-серверами Hyper-V, перемещая при этом виртуальные диски виртуальных машин VHD, содержимое памяти, состояние процессора и системы без простоя в работе виртуальной машины. Если рассматривать самый экстремальный сценарий, то виртуальная машина, запущенная на ноутбуке, с дисками VHD, размещенными на локальном общем диске, может быть перемещена на другой ноутбук, подсоединенный через единственный сетевой кабель Gigabit Ethernet.

Небольшое предостережение: не думайте, что использование live migration без общего хранилища означает, что отказоустойчивые кластеры больше не нужны. Отказоустойчивый кластер – это решение с высоким уровнем доступности, в то время как горячая миграция без общего хранилища является мобильным решением, дающим дополнительную гибкость при запланированном перемещении виртуальных машин между хостами Hyper-V в вашем окружении. Кроме того, горячая миграция может служить дополнением к отказоустойчивому кластеру. Представьте возможность перемещения виртуальных машин без простоя в работе внутрь кластера, из кластера наружу, между кластерами и между отдельными хост-системами. При live migration без общего хранилища вы перестаете зависеть от хранилищ.

Требования для использования live migration без общего хранилища

Требования для активации механизма live migration достаточно просты.

-Вам необходимы два (как минимум) экземпляра системы Server 2012 с установленной ролью Hyper-V или бесплатной версией Microsoft Hyper-V Server 2012.

-Каждый сервер должен иметь доступ к собственному хранилищу для хранения виртуальных машин. Эту роль может играть локальное хранилище, выделенное хранилище SAN или общий ресурс Server Message Block (SMB) 3.0.

-Серверы должны иметь процессоры одного типа или семейства (то есть Intel или AMD), если вы используете функцию Processor Compatibility для виртуальных машин.

-Серверы должны быть членами одного домена Active Directory (AD).

-Между серверами должно быть установлено соединение скоростью не менее 1 Гбит/с (под трафик live migration рекомендуется организовать отдельный выделенный сегмент сети, однако такая конфигурация не является обязательной), через которое два сервера смогут обмениваться данными. Для сетевого адаптера, который вы используете, необходимо активировать службы Client for Microsoft Networks и File and Printer Sharing for Microsoft Networks, так как они используются для всех видов миграции между хранилищами.

-На каждом сервере Hyper-V одним и тем же виртуальным коммутаторам следует присвоить одинаковые имена, чтобы избежать ошибок и выполнения операций вручную в процессе миграции. Если на целевом сервере Hyper-V не определен виртуальный коммутатор с тем же именем, что и коммутатор, используемый в настройках переносимой виртуальной машины, появится сообщение об ошибке, и администратор, выполняющий миграцию, будет вынужден выбирать, к какому коммутатору на целевом сервере необходимо подключить адаптер виртуальной машины.

-Виртуальные машины, для которых планируется выполнять миграцию, не должны использовать транзитные хранилища.

Когда ваше окружение будет отвечать перечисленным требованиям, можно перейти к следующему шагу – разрешить исходящие и входящие миграции для хостов Hyper-V.

Разрешения на уровне хостов

Чтобы разрешить live migration на серверах Hyper-V, необходимо установить флаг Enable incoming and outgoing live migrations в настройках гипервизора Hyper-V. Эти настройки доступны в мастере Hyper-V Manager. На экране 1 показаны основные настройки, необходимые для разрешения миграции за границы кластера.

 

Настройки live migration на сервере Hyper-V
Экран 1. Настройки live migration на сервере Hyper-V

В простейших средах выбор параметра Enable incoming and outgoing live migrations, согласие с настройкой по умолчанию Use Credential Security Support Provider (CredSSP) для аутентификации и использование любой доступной сети для live migration должны обеспечить выполнение миграции без общего хранилища. Неочевидный момент: встроенное исключение Hyper-V (MIG-TCP-In) создает разрешающее правило брандмауэра для TCP-порта 6600. Если вы используете на серверах альтернативный локальный сетевой экран или если для фильтрации трафика между серверами применяются межсетевые экраны, вам придется открывать этот порт вручную.

Имейте в виду, что на экране настроек Hyper-V Settings вы также можете задать максимальное количество одновременно выполняющихся процессов миграции. Система Server 2012 снимает ограничение в один процесс живой миграции между любыми двумя хостами в одно и то же время, вместо этого теперь количество одновременных миграций определяется пропускающей способностью сети. Однако если вы хотите ограничить количество одновременных миграций определенным числом, задайте этот предел в поле Simultaneous live migrations. Вы можете настроить это значение и с помощью параметра MaximumVirtualMachineMigrations команды Set-VMHost в оболочке Windows PowerShell.

Хотя настройки по умолчанию могут работать в простых средах или при базовом тестировании, в большинстве окружений появится необходимость переключиться на аутентификацию Kerberos и задействовать выделенную сеть для трафика живой миграции, который будет включать в себя копии памяти виртуальной машины и ее устройств хранения. Применение механизма Kerberos позволяет администраторам инициировать процессы миграции удаленно. Использование выделенной сети помогает управлять сетевым трафиком и обеспечивать наличие достаточной пропускающей способности сети для выполнения миграции. Давайте рассмотрим процесс аутентификации и разберемся, почему он становится источником проблем при живой миграции в некластерных средах.

Аутентификация при живой миграции

В кластерных средах, в которых хост-серверы Hyper-V являются частями отказоустойчивого кластера, все хосты совместно используют общую кластерную учетную запись. Эта учетная запись служит для обмена сообщениями между хостами в процессе аутентификации, упрощая (с точки зрения аутентификации) такие операции как миграция внутри кластера. За границами кластера каждый сервер Hyper-V имеет собственную учетную запись компьютера – общие учетные данные отсутствуют. При выполнении операций обычно применяется учетная запись того пользователя, который инициирует действие.

При живой миграции операции выполняются на сервере-источнике, на целевом сервере (и на файловых серверах, если виртуальная машина хранится в общей папке SMB), и в каждом случае необходима аутентификация. Если администратор, выполняющий миграцию, подключается к серверу-источнику или целевому серверу и запускает процесс живой миграции без общего хранилища через локальную оснастку Hyper-V Manager, тогда учетные данные администратора используются как для локальных операций, так и для выполнения команд на целевом сервере Hyper-V. В таком сценарии протокол CredSSP работает корректно, позволяя использовать учетные данные администратора, заданные на стороне клиента, на удаленном сервере – как правило, на расстоянии одного шага аутентификации между локальной машиной, с которой выполняется операция, и удаленным сервером.

Однако общая идеология системы Server 2012 (и общего подхода к управлению) предполагает удаленное управление и автоматизацию. Необходимость постоянно авторизоваться на исходном и целевом серверах Hyper-V каждый раз, когда требуется выполнить миграцию вне кластера, является громадным недостатком при удаленном управлении. Если пользователь авторизовался на локальном компьютере с запущенной оснасткой Hyper-V Manager и пытается выполнить миграцию между хостами Hyper-V A и B, эта попытка будет неудачной. Учетные данные пользователя будут применяться на хосте A (который находится в одном шаге аутентификации от клиентской системы), однако хост A не сможет использовать эти учетные данные на хосте B для завершения миграции. Проблема в том, что протокол CredSSP не позволяет передавать учетные данные в систему, которая находится более чем в одном шаге. В такой ситуации полноценное удаленное управление обеспечит использование протокола Kerberos: Kerberos поддерживает ограниченное делегирование аутентификации. Таким образом, когда пользователь выполняет операцию на удаленном сервере, этот удаленный сервер может задействовать учетные данные пользователя для аутентификации на втором удаленном сервере.

Не означает ли это, что сервер, к которому я подключаюсь удаленно, может просто взять мои учетные данные и использовать их на другом сервере без моего ведома? Здесь и вступает в игру ограничивающая часть делегирования, несмотря на то, что вам необходимо будет выполнить определенную настройку, прежде чем вы сможете использовать протокол Kerberos как протокол аутентификации при миграции. Вам необходимо настроить делегирование для каждой учетной записи компьютера, которой будет разрешено выполнять операции на другом сервере от имени пользователя. Для настройки делегирования используйте средство управления Active Directory Users and Computer и окно свойств учетной записи компьютера для сервера, которому будет дано право на делегирование. Как показано на экране 2, вкладка Delegation содержит настройки разрешенного уровня делегирования. Для большинства компьютеров схема разрешений, изображенная на этом экране, разрешает делегирование только для определенных служб и только для протокола Kerberos, и это оптимальный вариант.

 

Настройки делегирования для выполнения удаленного запуска live migration
Экран 2. Настройки делегирования для выполнения удаленного запуска live migration

Единственная служба, которой требуется делегирование — Microsoft Virtual System Migration Service – должна быть активирована на целевом сервером Hyper-V. Необходимо выбрать только один режим аутентификации — Use Kerberos. У меня есть два сервера SERVERA и SERVERB; на экране видно, что я меняю настройки делегирования для сервера SERVERA и настраиваю делегирование Kerberos на другом моем сервере SERVERB для службы Microsoft Virtual System Migration Service. Я повторю процесс настройки для учетной записи компьютера SERVERB, позволяя делегировать ее на сервер SERVERA. Также имейте в виду, что я настроил делегирование для службы Common Internet File System (CIFS), которая потребуется позже, когда виртуальные машины, размещенные в общих папках SMB, будут перемещаться между хостами. После настройки делегирования Kerberos живая миграция между надежными серверами может быть запущена из любого удаленного экземпляра оснастки Hyper-V Manager.

Помните, что все хосты, участвующие в миграции, должны иметь одинаковые настройки аутентификации. На рисунках 1 и 2 показаны основные отличия между протоколами CredSSP и Kerberos и настройки, необходимые для использования каждого из протоколов. На рисунке 1 отражено использование протокола CredSSP; для его работы требуется, чтобы горячая миграция запускалась с одного из серверов Hyper-V. Рисунок 2 иллюстрирует использование аутентификации Kerberos и удаленный запуск процесса, для которого требуется дополнительное ограниченное делегирование Kerberos. Хотя использование аутентификации Kerberos требует более трудоемкой настройки, полученная дополнительная гибкость оправдывает эти усилия и переводит данную настройку в разряд рекомендованных. Для настройки типа аутентификации из оболочки PowerShell введите команду Set-VMHost и установите переменную VirtualMachineMigrationAuthenticationType в значение CredSSP или Kerberos.

 

Миграция с помощью протокола CredSSP
Рисунок 1. Миграция с помощью протокола CredSSP

 

Миграция с помощью протокола Kerberos
Рисунок 2. Миграция с помощью протокола Kerberos

Настройки сети

Аутентификация была тяжелым этапом. Теперь вы должны настроить сеть для использования при входящих миграциях (то есть сеть, в которой хост будет ожидать и принимать живые миграции). По умолчанию живая миграция допускается из любой сети. Однако я рекомендую, если это возможно, использовать закрытую, выделенную под процессы миграции сеть, чтобы обеспечить гарантированную пропускную способность и отделить миграции от остального трафика сети. Вы можете добавлять несколько сетей и устанавливать порядок их использования: просто введите адрес соответствующей подсети в нотации сетевых префиков, также известной как нотация Classless Inter-Domain Routing (CIDR). Например, чтобы указать сетевой адаптер с IP-адресом 10.1.2.1 и маской подсети 255.255.255.0, я использовал нотацию 10.1.2.0/24. Альтернативный вариант – указать полный IP-адрес с маской 32 (например, 10.1.2.2/32), но в этом случае необходимо будет менять настройки каждый раз при смене IP-адреса. Убедитесь, что исходный и целевой серверы могут обмениваться данными друг с другом, используя IP-адреса, которые вы указали для применения в процессе live migration, в противном случае миграция не может быть выполнена. Для изменения данных настроек с помощью оболочки PowerShell используйте команды Add-VMMigrationNetwork и Set-VMMigrationNetwork.

Применение миграции без общего хранилища

После настройки хост-серверов Hyper-V выполнить саму миграцию просто. Для виртуальной машины выберите действие Move, после чего в качестве типа перемещения укажите вариант Move the virtual machine. Введите имя целевого сервера Hyper-V, на который хотите переместить виртуальную машину, и в довершение укажите, каким образом элементы виртуальной машины, такие как VHD, будут перемещаться к месту назначения. На экране 3 показаны конечные настройки перемещения. Так как нас интересует сценарий без общего хранилища, в котором отсутствует общее хранилище и не используются общие файловые папки SMB, необходимо выбрать одну из двух возможностей: Move the virtual machine's data to a single location или Move the virtual machine's data by selecting where to move the items. Первый вариант позволяет указать единое место на целевом хранилище, в котором будет содержаться конфигурация виртуальной машины, жесткие диски и моментальные снимки. Второй вариант позволяет помимо выбора перемещаемых элементов указать место хранения для каждого элемента виртуальной машины.

 

Выбор варианта операции перемещения
Экран 3. Выбор варианта операции перемещения

После того, как вы сделаете выбор, укажите папку на целевом сервере. Операция перемещения будет запущена. Время выполнения зависит от размеров дисков VHD, объема перемещаемой памяти и частоты изменений. Однако операция будет выполнена без простоев в работе и потери соединения с виртуальной машиной. Вы также можете инициировать перемещение с помощью команды PowerShell Move-VM.

Устранение ошибок миграции

Следующие шаги должны помочь вам разобраться с любыми препятствиями, которые могут возникнуть в процессе работы.

  1. Убедитесь, что ваша инфраструктура соответствует требованиям, описанным в начале этой статьи.
  2. Проверьте журнал Event Viewer (Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMW > Admin) на предмет сообщений, описывающих проблему.
  3. Убедитесь в корректности настроек IP-адресации между исходным и целевым серверами. У серверов должна быть возможность обмениваться сообщениями. Проверьте командой ping доступность целевого IP-адреса миграции с исходного сервера.
  4. Запустите следующую команду PowerShell из сессии с повышенными привилегиями, чтобы просмотреть IP-адреса, используемые для сервера:gwmi -n root\virtualization\v2 Msvm_VirtualSystemMigrationService | select MigrationServiceListenerIPAddressList
  5. Убедитесь, что на целевом сервере активировано исключение брандмауэра для служб Hyper-V (MIG-TCP-In).
  6. Имя целевого сервера должно быть разрешимым через службу DNS. Попробуйте запустить команду Nslookup на целевом сервере. Также запустите команду
ipconfig /registerdns

на целевом сервере и команду

ipconfig /flushdns

на исходном.

7. На целевом сервере используйте следующую команду для очистки кэша протокола Address Resolution Protocol (ARP):

command arp -d *

8. Для проверки возможности соединения попробуйте удаленно отправить запрос Windows Management Instrumentation (WMI) на целевой сервер (на нем должно быть активировано исключение брандмауэра WMI-In), например

gwmi -computer  -n root\virtualization\v2 Msvm_VirtualSystemMigrationService

9. Измените IP-адрес, используемый для живой миграции. Например, если вы задействовали подсеть 10.1.2.0/24, попробуйте заменить ее на конкретный IP-адрес 10.1.2.1/32. Кроме того, проверьте настройки шифрования IPSec или межсетевых экранов между исходным и целевым серверами. Выясните, не подключено ли несколько сетевых карт в одну подсеть – это может вызвать проблемы. Если вы столкнулись с такой ситуацией, попробуйте отключить один из адаптеров.

10. Настройте аутентификацию через протокол CredSSP и запустите процесс локально с сервера Hyper-V. Если после этого ошибка будет устранена, значит корень проблемы в делегировании Kerberos.

Наиболее распространенные неполадки среди тех, с которыми я сталкивался, связаны с ошибками настройки протокола Kerberos или IP-адресов. Невозможность разрешить имя целевого сервера через службу DNS также приведет к проблемам.

Подведение итогов и дальнейшие шаги

Живая миграция без общего хранилища – это наиболее радикальный тип миграции с нулевым временем простоя. Однако существуют и другие типы миграции без простоев, такие как хранение виртуальных машин в общей файловой папке SMB, к которой имеют доступ оба хоста Hyper-V. При таком подходе память и состояние устройства перемещаются по сети, а хранилище остается на прежнем месте. И еще существует живая миграция внутри отказоустойчивого кластера – процесс, который может использовать общие хранилища SAN посредством файловой системы CSV (CSVFS).

Если вы перемещаете виртуальную машину между отказоустойчивыми кластерами или между отказоустойчивым кластером и автономным хостом Hyper-V, вам придется удалить виртуальную машину из кластера перед миграцией. Очень удобно, что в системе Server 2012 можно добавлять и удалять виртуальные машины из отказоустойчивого кластера, не останавливая их – то есть без простоя в работе виртуальных машин, даже если миграция затрагивает отказоустойчивый кластер.

Конечно, даже в сценарии без общего хранилища существует необходимость в наличии общей физической сетевой инфраструктуры и зависимость от настроек IP-адреса виртуальной машины во время перемещения. Вот почему другая возможность системы Server 2012, Network Virtualization, открывает перед нами новый мир: теперь виртуальные машины можно перемещать между любыми хостами, не меняя настроек сети в их операционных системах.