Отделяем трафик резервного копирования System Center 2012 DPM

В прошлой заметке мы рассмотрели пример создания отдельного сетевого сегмента для отделения трафика миграции Hyper-V Shared Nothing Live Migration. В этой заметке на примере тех же двух серверов виртуализации рассмотрим пример создания отдельного сетевого сегмента для отделения трафика резервного копирования System Center 2012 DPM. Дополнительно в этом примере появляется физический сервер резервного копирования на платформе HP ProLiant DL380 G5 выполняющий роль сервера DPM. Два выше обозначенных сервера виртуализации в нашем случае имеют установленный агент DPM.

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

Начнём с настройки отдельного сетевого интерфейса на сервере DPM. Первым делом настроим приоритет использования сетевых интерфейсов таким образом, чтобы интерфейс управления был самым первым.
Control PanelNetwork and InternetNetwork Connections > Меню Advanced

В свойствах сетевого интерфейса назначенного в сегмент сети DPM включим поддержку Jumbo Packet на максимально возможно значение

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

• Client for Microsoft Networks
• QoS Packet Scheduler
• Internet Protocol Version 4 (TCP/IPv4)

В свойствах IPv4 указываем только IP адрес и маску подсети. В нашем случае под сегмент DPM выделена сеть 10.160.34.0/24. Шлюз по умолчанию оставляем пустым (он указан только на интерфейсе управления хостом).

Теперь поговорим о настройке отдельного интерфейса на серверах с установленным агентом DPM. Если это обычный физический сервер то сетевой интерфейс настраивается таким же образом как и на сервере DPM, если же говорить о хостах виртуализации то здесь можно пойти по несколько другому сценарию. Дело в том, что на хосте виртуализации трафик DPM может проходить не только при бэкапе виртуальных машин, но и при бэкапе из агентов DPM установленных внутри этих виртуальных машин. Если первый тип трафика на хосте мы можем отвести на отдельный физический интерфейс, то второй тип трафика у нас даже при наличии отдельного сетевого интерфейса DPM будет попадать в интерфейс виртуального свитча Hyper-V. Чтобы "убить сразу двух зайцев" и по-честному отделить трафик DPM можно создать на отдельном сетевом интерфейсе хоста дополнительный виртуальный свитч, сделать его доступным управляющей операционной системе и уже появившийся виртуальный адаптер использовать для подключения к сегменту сети DPM как с самого хоста так и изнутри виртуальных машин (посредствам подключения дополнительного виртуального сетевого адаптера к виртуальному свитчу сделанному для DPM).

Соответственно на сервере виртуализации с установленным агентом DPM в оснастке Hyper-V Manager создадим дополнительный виртуальный свитч на выделенном сетевом интерфейсе и включим опцию доступности виртуального свитча управляющей операционной системе хоста – Allow management operating system to share this network adapter

После сохранения настроек на хосте виртуализации появится соответствующий виртуальный сетевой адаптер

В свойствах этого адаптера произведем настройку IP адреса который мы выделяем хосту в подсети DPM

По кнопке Advanced открываем расширенные настройки IPv4 и отключаем регистрацию в DNS, а также в свойствах виртуального адаптера включаем поддержку Jumbo Packet

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

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

PING 10.160.34.60 -f -l 8000

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

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

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

В некоторых источниках можно встретить рекомендацию об отключении технологии TCP Chimney. Узнать текущее состояние этой функциональности можно командой:

netsh int tcp show global

Отключить TCP Chimney можно командой:

netsh int tcp set global chimney=disabled

Отключение надо делать как на стороне сервера так и на стороне агентов DPM. В Windows Server 2012 эта функциональность по умолчанию выключена.

Помимо этого можно встретить рекомендацию от отключении аппаратных функций энергосбережения и заставить работать сервер в режиме High Performance. В частности отключить в BIOS для процессоров использование С-State, что (в некоторых случаях) может положительно повлиять на производительность сетевых интерфейсов

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

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

Вариант использования DNS предполагает создание для каждого сервера дополнительной A-записи с IP адресом из подсети DPM. С точки зрения трудозатрат это самый простой вариант, однако он имеет существенный недостаток – при разрешении имени сервера может возвращаться как IP адрес из подсети DPM так и IP адрес из подсети управления, а это сводит на нет саму идею разграничения трафика. Поэтому мы останавливаемся на варианте с настройкой файлов hosts.

На серверах с установленным агентом DPM в файл hosts добавляем запись только об IP адресе сервера DPM. Если серверов DPM несколько (например используется сценарий DPM Disaster Recovery) то с соответственно и записей может потребоваться сделать несколько.

На сервере DPM в файл hosts добавляем записи о всех серверах с установленным агентом DPM:

Ограничиваем сервер DPM выделенной подсетью

Для того чтобы заставить сервер DPM работать с агентами только в определённой подсети воспользуемся командлетами PowerShell для DPM (в графическом интерфейсе консоли DPM Administrator Console выполнить такую настройку возможности нет). В консоли DPM Management Shell выполняем:

Add-DPMBackupNetworkAddress -DpmServername KOM-SCDP01 -Address 10.160.34.0/24 -SequenceNumber 1

Если хотим выполнять командлеты DPM например в консоли Windows PowerShell ISE, – предварительно нужно выполнить загрузку соответствующего модуля:

Import-Module DataProtectionManager

Параметр SequenceNumber определяет приоритет использования подсетей.  То есть в качестве основной подсети можно задать подсеть выделенную строго под задачи DPM и дополнительной командой при желании добавить другую подсеть (например сеть управления хостами):

Add-DPMBackupNetworkAddress -DpmServername KOM-SCDP01 -Address 10.160.100.0/24 -SequenceNumber 2

Проверить текущие настройки ограничения подсетей можно так:

Get-DPMBackupNetworkAddress -DpmServername KOM-SCDP01 | ft –AutoSize

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

После того как все настройки произведены и на сервере и на агентах DPM желательно перезапустить службу агента DPM (DPMRA) на всех этих системах.

net stop dpmra & net start dpmra

Теперь можно выполнить запуск задания резервного копирования на сервере DPM и проверить наличие сетевой активности на выделенных сетевых интерфейсах:

На отправляющей стороне, то есть на защищаемом сервере с установленным агентом DPM:

И на стороне сервера DPM…

В конечном итоге мы имеем успешно выполняемые задания резервного копирования с прохождением всего трафика DPM через выделенный сетевой сегмент.