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

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

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

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

image

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

image

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

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

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

image

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

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

image

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

image

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

image

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

image

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

image

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

Ограничиваем сервер 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

image

Параметр 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:

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

image

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

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

TechNet Library - Using a Backup Network Address

WindowsITPro - How-To: Configure a Backup Network for Microsoft’s DPM 2010

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

  1. Александр /

    Алексей, спасибо за ваш блог. Чрезвычайно большпя польза. Задаю вам вопрос в комментарии, потому что иначе не получилось почему то.
    Скажите, по вашему опыту работы, какой размер трафика генерируют процессы инвентаризации (харда и софта) применительно к одной станции (конечно, числа будут очень приблизительными, но я нигде вообще не нашел количественных оценок этих процессов)
    Спасибо

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

      Насколько я понимаю вопрос не имеет отношения к теме записи. Если у вас есть ко мне какие-то вопросы то попробую вам помочь если получится. Мой адрес электронной почты указан на странице About в "шапке" блога.

  2. Vladimir Prokhorov /

    Возможно ли для выделенной сети резервного копирования создать/указать отдельный DNS, который прописать в свойствах выделенных интерфейсов?

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

      Не могу сказать, так как не представляю как себя в таком случае поведёт DNS-клиент. Решение с правкой фала hosts, по крайней мере под описанную задачу, - работает.

  3. Михаил /

    Большое спасибо! Всё успешно получилось, руководствуясь Вашей заметкой!

  4. Михаил /

    Алексей, подскажите пожалуйста!
    На сервере DPM и сервере агента DPM, сетевые интерфейсы для бэкапа имеют скорость 1Гб.
    Но в процессе бэкапа задействуется меньше половины пропускной способности... Во время бэкапа на сервере DPM, в диспетчере задач отображалось использование сети данного интерфейса 10-15%, иногда подпрыгивая до 20%. Скорость была порядка 160-200Мбит. Я включил и проверил jumbo packet на обоих серверах. Но остальные рекомендации не делал TCP Chimney, Bios... Это особенность бэкапа (бэкапились несколько БД) или последствия того что не сделал все рекомендации (на продуктивном сервере проблематично найти время дедлайна)? Пробовал просто копировать файл 70гб с сервера агента на сервер дпм по выделенному каналу, в итоге использование сети 99% но скорость максимум 85Мб.

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

      Попробуйте включить и настроить на сервере DPM throttling для этого агента, то есть задать явно пропускную способность.
      https://technet.microsoft.com/ru-ru/library/Ff399035.aspx

  5. Обратная ссылка: Обновляем System Center 2012 SP1 Data Protection Manager до уровня System Center 2012 R2 и перебираемся на Windows Server 2012 R2 и SQL Server 2012 SP1 | Блог IT-KB /

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