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

imageПосле перевода серверов виртуализации на 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).

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 PanelNetwork and InternetNetwork 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 -n rootvirtualizationv2 Msvm_VirtualSystemMigrationService | select MigrationServiceListenerIPAddressList

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

gwmi -computer <RemoteServer> -n rootvirtualizationv2 Msvm_VirtualSystemMigrationService

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

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

image

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

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 потерянных пакета не повлияли на качество терминальной сессии. И это не может не радовать.

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

TechNet Library — Hyper-V: Live Migration Network Configuration Guide

Windows IT Pro — Shared-Nothing VM Live Migration with Windows Server 2012 Hyper-V

Ask Premier Field Engineering (PFE) Platforms — Windows Server 2012 Hyper-V Best Practices (In Easy Checklist Form)

Всего комментариев: 8 Комментировать

  1. Евгений /

    Спасибо Алексей за статью!
    Но для отказоустойчивости Microsoft рекомендует делать NIC teaming и разделять трафик VLAN с приоритезацией.
    Кстати, вопрос не по самой теме Live Migration:
    1) Что предполагается под трафиком управления хостом ?
    2) Можно ли его объединить с трафиком виртуальных машин (т.к. оба коннекта соединяются с внешнеми физическими серверами)?

    1. Алексей Максимов /

      По поводу тиминга наверно можно ещё подумать во всех ли случаях его применение будет также эффективно как обычное разделение на физическом уровне. Есть неплохая статья по поводу режимов работы тиминга WS2012 http://habrahabr.ru/company/microsoft/blog/162509/
      Из неё я делаю вывод что самым интересным режимом тиминга в моём случае будет Switch Independent + Address Hash. Однако учитывая фразу описания такого режима:

      Входящий трафик поступает только на один интерфейс (основной адаптер группы). В случае сбоя в работе основного адаптера группы, его функции передаются другому сетевому адаптеру, и весь входящий трафик направляется к нему

      Из этого я делаю вывод что тим из 4-х гигабитных адаптеров в конечном итоге даст пропускную способность не больше возможного для отдельно взятого интерфейса.

      А если трафик таков что поджимает в потолку 1 гигабита, например одновременная миграция 1-2 VM, бэкап 3-ей VM и другие активности, то выгода от такого тиминга становится весьма сомнительной.

      1. Павел /

        Алексей, почему Address Hash? При установке роли Hyper-V, Management OS становится виртуальной машиной для гипервизора и тут применим метод Hyper-V Port.

  2. Евгений /

    Нашел ответы на свои вопрос…
    http://blogs.technet.com/b/gavinmcshera/archive/2011/03/27/3416313.aspx

  3. Обратная ссылка: Отделяем трафик резервного копирования System Center 2012 DPM | Блог IT-KB /

  4. Обратная ссылка: Отделяем трафик Hyper-V Shared Nothing Live Migration | vMind.ru /

  5. Eugene Leitan /

    Алексей,
    как можно отделить трафик реплики между двумя хостами одной сети?

    1. Алексей Максимов / Автор записи

      Говорят можно. http://social.technet.microsoft.com/Forums/fr-FR/24fce42a-d486-4789-af4d-0b216b821f45/hyperv-replica-over-dedicated-network. Но я сам такой сценарий не пробовал, так как нет задачи — заниматься репликацией VM.

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