Отделяем трафик Hyper-V Shared Nothing Live Migration

После перевода серверов виртуализации на Windows Server 2012 возникло желание использовать новый функционал Hyper-V  - Shared Nothing Live Migration для хостов, не являющихся членами кластеров. Здесь я опишу практический пример действий, которые были выполнены для того, чтобы отделить трафик миграции от основного трафика управления хостом виртуализации. В рассматриваемом примере имеется два сервера виртуализации HP ProLiant DL380 G5 с дополнительно установленным двух-портовым гигабитным сетевым адаптером HP NC360T. Таким образом каждый сервер имеет по четыре гигабитных сетевых интерфейса, которые мы будем использовать в следующем порядке:

• Port 1 NC373I (On-Board NIC1) – Под трафик резервного копирования DPM
• Port 2 NC373I (On-Board NIC2) – Под трафик Live Migration (LM)
• Port 3 NC360T (PCI-E NIC Port1) – Под трафик управления хостом
• Port 4 NC360T (PCI-E NIC Port2) – Под трафик виртуальных машин

Настраиваем отдельный сетевой интерфейс для Live Migration

Соответственно первое что мы должны сделать, это выделить отдельную IP подсеть и назначить каждому серверу IP адрес из этой подсети. В нашем примере под задачи миграции выделена подсеть 10.160.35.0/24 и адрес из этой подсети указан на интерфейсе Port 2 на каждом из серверов. Указываем только IP адрес и маску подсети. Шлюз по умолчанию оставляем пустым (он указан только на интерфейсе управления хостом - Port 3).

По кнопке Advanced открываем расширенные настройки IPv4 и отключаем регистрацию в DNS

На закладке Networking оставляем включенным только минимально необходимое количество модулей:

• Client for Microsoft Networks
• QoS Packet Scheduler
• File and Printer Sharing for Microsoft Network
• Internet Protocol Version 4 (TCP/IPv4)

Также не забываем выставить приоритет использования сетевых интерфейсов таким образом, чтобы интерфейс управления (в нашем случае Port 3) был самым первым.
Control PanelNetwork and InternetNetwork Connections > Меню Advanced

После того как на обоих наших серверах виртуализации настроены сетевые интерфейсы для миграции, проверим их взаимную доступность выполнив Ping IP адресов сегмента 10.160.35.0/24  с одного сервера на другой. В нашем примере оба сервера виртуализации подключены к одному физическому сегменту сети и поэтому проблем с их взаимной доступностью не возникает.

Включаем и настраиваем опции Live Migration

Далее на каждом из серверов откроем оснастку Hyper-V Manager и в меню Action > Hyper-V Settings на вкладке Live Migration включим нужный нам функционал, если он не был включён ранее, например на этапе установки роли Hyper-V.

В качестве протокола аутентификации выберем Kerberos, так как этот вариант позволит нам использовать для запуска миграции средства удалённого управления, такие как консоль SCVMM или удалённо запущенную оснастку Hyper-V Manager. Также укажем IP подсеть, которая должна будет использоваться для LM. Можно указать например всю  подсеть типа 10.160.35.0/24 или же отдельный адрес локального интерфейса в виде 10.160.35.60/32

На всех интерфейсах относящихся к перечисленным подсетям будет создан TCP прослушиватель порта 6600 для входящих подключений LM. Если по какой-то причине после сохранения настроек указанный порт не начал прослушиваться, то можно попробовать перезапустить службу Hyper-V Virtual Machine Management (vmms).

Через PowerShell локально на сервере виртуализации можно получить информацию об активных прослушивателях LM с помощью команды:

gwmi -n rootvirtualizationv2 Msvm_VirtualSystemMigrationService | select MigrationServiceListenerIPAddressList

или для удалённого компьютера:

gwmi -computer <RemoteServer> -n rootvirtualizationv2 Msvm_VirtualSystemMigrationService

Настраиваем делегирование в Active Directory

Чтобы выбранный нами тип взаимной аутентификации между хостами виртуализации в процессе миграции успешно работал, нам необходимо выполнить делегирование служб cisf и Microsoft Virtual System Migration Service в свойствах учетных записей обоих серверов виртуализации на соответствующей закладке

Если хостов виртуализации для которых нужно настроить делегирование более 2-3, то добавление каждого нового хоста может стать трудоёмким процессом. Вот пример простенького скрипта который позволит ускорить процесс добавления нового хоста виртуализации в делегирование всем существующим: 

Import-Module ActiveDirectory

 

$HostName = "KOM-AD01-VM01"

$HostFQDN = "KOM-AD01-VM01.holding.com"

$Services = @("cifs","Microsoft Virtual System Migration Service")

$OU =  "OU=HOSTS,DC=holding,DC=com"

$Filter = "(&(objectClass=computer)(cn=KOM-AD01-VM)(!description=cluster*)(!userAccountControl:1.2.840.113556.1.4.803:=2))"

 

 

Get-ADComputer -SearchBase $OU -ResultSetSize $null -LDAPFilter $Filter -Properties DistinguishedName | ForEach-Object {

 

    Write-Host "Изменяем учетную запись:" $_.DistinguishedName

 

 

    ForEach ($Service in $Services)

    {

        Set-ADObject $_.DistinguishedName -Add @{"msDS-AllowedToDelegateTo"="$Service/$HostFQDN","$Service/$HostName"}

    }  

}

Определяемся с разрешением имён

Далее нам необходимо решить вопрос с разрешением имён, то есть чтобы хосты виртуализации "видели" друг друга по IP адресам относящимся к выделенной нами подсети 10.160.35.0/24. Сделать это можно двумя путями – через DNS или через редактирование локальных файлов hosts (C:WindowsSystem32driversetc) на хостах виртуализации.

Вариант использования DNS предполагает создание для каждого сервера дополнительной A-записи с IP адресом из подсети LM. С точки зрения трудозатрат это самый простой вариант, однако он имеет существенный недостаток – при разрешении имени сервера виртуализации может возвращаться как IP адрес из подсети миграции так и IP адрес из подсети управления, а это сводит на нет саму идею разграничения трафика. Дополнительно это может вызвать проблемы с доступностью хостов из инфраструктурных систем типа SCVMM или SCOM.

Нам нужно выполнить такую настройку, при которой только сервера виртуализации между собой будут общаться исключительно через выделенную подсеть 10.160.35.0/24, а для всех остальных внешних систем эти самые сервера по прежнему будут доступны через IP адрес интерфейса управления (в нашем случае Port 3). Сделать это можно как раз с помощью редактирования файл hosts на всех серверах виртуализации которые у нас должны участвовать в процессе миграции. Итак, добавляем на каждом хосте записи о других хостах, указав IP адреса из подсети LM:

Такой вариант настройки разрешения имён будет более хлопотным, но на мой взгляд позволит более правильно реализовать поставленную задачу.

Если же всё таки вы решите остановиться на варианте с DNS, то как я уже сказал, вам придётся создать дополнительную A-запись (PTR не нужна) с указанием IP адреса из подсети LM

После создания записи, DNS сервер начнёт возвращать разные адреса для одного и того же имени и если IP Forwarding не настроен на интерфейсе сети Live Migration, то могут возникнуть проблемы с доступностью сервера из разных систем. Это можно легко проверить выполнив ping интерфейса LM из другой подсети. По умолчанию в Windows Server 2012 IP Forwarding выключен на всех сетевых интерфейсах. Убедиться в этом можно через PowerShell:

Get-NetIPInterface "Port 2 On-Board (Live Migration)" | fl

Если вы хотите включить на интерфейсе Forwarding , выполните команду:

Get-NetIPInterface "Port 2 On-Board (Live Migration)" | Set-NetIPInterface -Forwarding Enabled

В своём конкретном примере я остановился на варианте с файлом hosts, при котором сервера доступны друг другу в подсети 10.160.35.0/24 и включать форвардинг нет никакой необходимости.

Производительность сетевого интерфейса Live Migration

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

1) Отключить на хосте виртуализации аппаратные функции энергосбережения и заставить работать сервер в режиме High Performance. В частности отключить в BIOS для процессоров использование С-State. В некоторых источниках в интернете можно встретить громогласные заявления о том что отключение С-State приводит чуть ли не к 30% увеличению производительности сетевых адаптеров. Често говоря я такого эффекта на платформе HP ProLiant DL 380 G5 не заметил, хотя всё равно оставил включённым режим повышенной производительности.

2) Включить использование Jumbo Packet на сетевых интерфейсах используемых для LM. В моём случае на встроенном котроллере HP NC373i это означало выбор максимально возможного значения Jumbo Packet - 9014

После того как на хостах настроено использование больших пакетов нам необходимо удостовериться в том что такие пакеты действительно могут ходить между серверами в сегменте сети LM. Сделать это можно например с помощью команды Ping выставив флаг запрета фрагментации пакетов и задать заведомо большую величину пакета:

PING 10.160.35.60 -f -l 8000

Если Ping не пойдёт и мы получим сообщение о том что требуется фрагментация пакета, значит на нашем сетевом оборудовании к которому подключены хосты установлено ограничение по размеру пакета и на этом оборудовании также необходимо включать поддержку Jumbo Packet.

В моём примере оба хоста виртуализации подключены к коммутатору Cisco Catalyst C3560G-24TS. Для того чтобы посмотреть настройки MTU на уровне коммутатора в консоли управления коммутатором выполним:

show system mtu

Чтобы посмотреть MTU на уровне порта:

show interfaces GigabitEthernet0/1

Чтобы сконфигурировать размер MTU для использования Jumbo:

configure terminal
system mtu jumbo ?
system mtu jumbo 9000
exit
write
reload

В моём примере включение Jumbo на уровне коммутатора требует его перезагрузки (reload), то есть планировать такое мероприятие разумеется лучше на нерабочее время.

Проверяем результат

После того как все настройки завершены и мы убедились в том что пакеты большого размера успешно ходят между хостами можно выполнить запуск процедуры Shared Nothing Live Migration. В процессе переноса виртуальной машины обращаем внимание на сетевую активность на выделенных сетевых интерфейсах:

На отправляющей стороне, то есть на хосте виртуализации с которого выполняется перенос VM:

И на принимающем сервере…

В конечном итоге мы успешно выполнили перенос работающей виртуальной машины между серверами виртуализации не имеющими общего дискового хранилища и при этом весь трафик миграции прошёл через выделенный сетевой сегмент.

В процессе миграции выполнялся ping переносимой виртуальной машины и осуществлялся доступ по RDP. 2 потерянных пакета не повлияли на качество терминальной сессии. И это не может не радовать.

Дополнительные источники информации:

• TechNet Library - Hyper-V: Live Migration Network Configuration Guide
• Ask Premier Field Engineering (PFE) Platforms - Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form)