J3qx

information archive

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

Posted by j3qx на Январь 11, 2016

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

Сегодня Алексей Максимов расскажет нам про отделение трафика Hyper-V Shared Nothing Live Migration от других типов трафика хоста.

После перевода серверов виртуализации на Windows Server 2012 возникло желание использовать новый функционал Hyper-VShared 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).

image

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

image

На закладке 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

image

image

После того как на обоих наших серверах виртуализации настроены сетевые интерфейсы для миграции, проверим их взаимную доступность выполнив 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

image

На всех интерфейсах относящихся к перечисленным подсетям будет создан 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 в свойствах учетных записей обоих серверов виртуализации на соответствующей закладке

image

Если хостов виртуализации для которых нужно настроить делегирование более 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:

image

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

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

image

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

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

image

 

Если вы хотите включить на интерфейсе 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

image

После того как на хостах настроено использование больших пакетов нам необходимо удостовериться в том что такие пакеты действительно могут ходить между серверами в сегменте сети 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

image

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


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

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

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

image

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

image

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

image

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

 

(C) http://vmind.ru/2013/05/30/hyper-v-shared-nothing-live-migration-network-on-separate-nic/

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: