Сегодня Алексей Максимов расскажет нам про отделение трафика 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 Panel\Network and Internet\Network 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-nroot\virtualization\v2Msvm_VirtualSystemMigrationService | selectMigrationServiceListenerIPAddressList
или для удалённого компьютера:
gwmi-computer <RemoteServer> -nroot\virtualization\v2Msvm_VirtualSystemMigrationService
Настраиваем делегирование в Active Directory
Чтобы выбранный нами тип взаимной аутентификации между хостами виртуализации в процессе миграции успешно работал, нам необходимо выполнить делегирование служб cisf и Microsoft Virtual System Migration Service в свойствах учетных записей обоих серверов виртуализации на соответствующей закладке
Если хостов виртуализации для которых нужно настроить делегирование более 2-3, то добавление каждого нового хоста может стать трудоёмким процессом. Вот пример простенького скрипта который позволит ускорить процесс добавления нового хоста виртуализации в делегирование всем существующим:
Import-ModuleActiveDirectory
$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-PropertiesDistinguishedName | ForEach-Object {
Write-Host“Изменяемучетнуюзапись:”$_.DistinguishedName
ForEach ($Servicein$Services)
{
Set-ADObject$_.DistinguishedName -Add @{“msDS-AllowedToDelegateTo”=“$Service/$HostFQDN”,“$Service/$HostName”}
}
}
Определяемся с разрешением имён
Далее нам необходимо решить вопрос с разрешением имён, то есть чтобы хосты виртуализации “видели” друг друга по IP адресам относящимся к выделенной нами подсети 10.160.35.0/24. Сделать это можно двумя путями – через DNS или через редактирование локальных файлов hosts (C:\Windows\System32\drivers\etc) на хостах виртуализации.
Вариант использования 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
Windows IT Pro – Shared-Nothing VM Live Migration with Windows Server 2012 Hyper-V