Отделение трафика резервного копирования System Center 2012 DPM
http://blog.it-kb.ru/wp-content/uploads/2013/05/image_thumb17.pngВ прошлой заметке мы рассмотрели пример создания отдельного сетевого сегмента для отделения трафика миграции Hyper-V Shared Nothing Live Migration. В этой заметке на примере тех же двух серверов виртуализации рассмотрим пример создания отдельного сетевого сегмента для отделения трафика резервного копирования System Center 2012 DPM. Дополнительно в этом примере появляется физический сервер резервного копирования на платформе HP ProLiant DL380 G5 выполняющий роль сервера DPM. Два выше обозначенных сервера виртуализации в нашем случае имеют установленный агент DPM.
Настраиваем отдельные сетевые интерфейсы для трафика DPM
Начнём с настройки отдельного сетевого интерфейса на сервере DPM. Первым делом настроим приоритет использования сетевых интерфейсов таким образом, чтобы интерфейс управления был самым первым.
Control Panel\Network and Internet\Network Connections > Меню Advanced
http://blog.it-kb.ru/wp-content/uploads/2013/05/image_thumb18.png
В свойствах сетевого интерфейса назначенного в сегмент сети DPM включим поддержку Jumbo Packet на максимально возможно значение
http://blog.it-kb.ru/wp-content/uploads/2013/05/image19.png
На закладке Networking оставляем включенным только минимально необходимое количество модулей:
- Client for Microsoft Networks
- QoS Packet Scheduler
- Internet Protocol Version 4 (TCP/IPv4)
В свойствах IPv4 указываем только IP адрес и маску подсети. В нашем случае под сегмент DPM выделена сеть 10.160.34.0/24. Шлюз по умолчанию оставляем пустым (он указан только на интерфейсе управления хостом).
http://blog.it-kb.ru/wp-content/uploads/2013/05/image20.png
Теперь поговорим о настройке отдельного интерфейса на серверах с установленным агентом DPM. Если это обычный физический сервер то сетевой интерфейс настраивается таким же образом как и на сервере DPM, если же говорить о хостах виртуализации то здесь можно пойти по несколько другому сценарию. Дело в том, что на хосте виртуализации трафик DPM может проходить не только при бэкапе виртуальных машин, но и при бэкапе из агентов DPM установленных внутри этих виртуальных машин. Если первый тип трафика на хосте мы можем отвести на отдельный физический интерфейс, то второй тип трафика у нас даже при наличии отдельного сетевого интерфейса DPM будет попадать в интерфейс виртуального свитча Hyper-V. Чтобы "убить сразу двух зайцев" и по-честному отделить трафик DPM можно создать на отдельном сетевом интерфейсе хоста дополнительный виртуальный свитч, сделать его доступным управляющей операционной системе и уже появившийся виртуальный адаптер использовать для подключения к сегменту сети DPM как с самого хоста так и изнутри виртуальных машин (посредствам подключения дополнительного виртуального сетевого адаптера к виртуальному свитчу сделанному для DPM).
Соответственно на сервере виртуализации с установленным агентом DPM в оснастке Hyper-V Manager создадим дополнительный виртуальный свитч на выделенном сетевом интерфейсе и включим опцию доступности виртуального свитча управляющей операционной системе хоста – Allow management operating system to share this network adapter
http://blog.it-kb.ru/wp-content/uploads/2013/05/image21.png
После сохранения настроек на хосте виртуализации появится соответствующий виртуальный сетевой адаптер
http://blog.it-kb.ru/wp-content/uploads/2013/05/image22.png
В свойствах этого адаптера произведем настройку IP адреса который мы выделяем хосту в подсети DPM
http://blog.it-kb.ru/wp-content/uploads/2013/05/image23.png
По кнопке Advanced открываем расширенные настройки IPv4 и отключаем регистрацию в DNS, а также в свойствах виртуального адаптера включаем поддержку Jumbo Packet
http://blog.it-kb.ru/wp-content/uploads/2013/05/image24.png
После того как выделенные сетевые интерфейсы под сеть резервного копирования настроены и на сервере 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:\Windows\System32\drivers\etc) на сервере DPM и серверах с агентом DPM.
Вариант использования DNS предполагает создание для каждого сервера дополнительной A-записи с IP адресом из подсети DPM. С точки зрения трудозатрат это самый простой вариант, однако он имеет существенный недостаток – при разрешении имени сервера может возвращаться как IP адрес из подсети DPM так и IP адрес из подсети управления, а это сводит на нет саму идею разграничения трафика. Поэтому мы останавливаемся на варианте с настройкой файлов hosts.
На серверах с установленным агентом DPM в файл hosts добавляем запись только об IP адресе сервера DPM. Если серверов DPM несколько (например используется сценарий DPM Disaster Recovery) то с соответственно и записей может потребоваться сделать несколько.
http://blog.it-kb.ru/wp-content/uploads/2013/05/image25.png
На сервере DPM в файл hosts добавляем записи на всех серверах с установленным агентом DPM:
http://blog.it-kb.ru/wp-content/uploads/2013/05/image26.png
Ограничиваем сервер 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
http://blog.it-kb.ru/wp-content/uploads/2013/05/image27.png
Параметр 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:
http://blog.it-kb.ru/wp-content/uploads/2013/05/image28.png
И на стороне сервера DPM…
http://blog.it-kb.ru/wp-content/uploads/2013/05/image29.png
В конечном итоге мы имеем успешно выполняемые задания резервного копирования с прохождением всего трафика DPM через выделенный сетевой сегмент.
Дополнительные источники информации:
TechNet Library – Using a Backup Network Address
WindowsITPro – How-To: Configure a Backup Network for Microsoft’s DPM 2010
Оригинал статьи: Блог IT-KB - Отделяем трафик резервного копирования System Center 2012 DPM