Налаштовуємо окремі мережеві інтерфейси для трафіку 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)
Тепер поговоримо про налаштування окремого інтерфейсу на серверах з встановленим агентом DPM. Якщо це звичайний фізичний сервер то мережевий інтерфейс налаштовується таким же чином як і на сервері DPM, якщо ж говорити про хостах віртуалізації то тут можна піти по кілька іншим сценарієм. Справа в тому, що на хості віртуалізації трафік DPM може проходити не тільки при бекапе віртуальних машин, а й при бекапе з агентів DPM встановлених всередині цих віртуальних машин. Якщо перший тип трафіку на хості ми можемо відвести на окремий фізичний інтерфейс, то другий тип трафіку у нас навіть при наявності окремого мережевого інтерфейсу DPM буде потрапляти в інтерфейс віртуального світча Hyper-V. Щоб "убити відразу двох зайців" і по-чесному відокремити трафік DPM можна створити на окремому мережевому інтерфейсі хоста додатковий віртуальний світч, зробити його доступним керуючої операційній системі і вже з'явився віртуальний адаптер використовувати для підключення до сегменту мережі DPM як з самого хоста так і зсередини віртуальних машин (через підключення додаткового віртуального мережевого адаптера до віртуального свитчу зробленому для DPM).
Відповідно на сервері віртуалізації з встановленим агентом DPM в оснащенні Hyper-V Manager створимо додатковий віртуальний світч на виділеному мережевому інтерфейсі і включимо опцію доступності віртуального світча керуючої операційній системі хоста - Allow management operating system to share this network adapter
Ви зберегли на хості віртуалізації з'явиться відповідний віртуальний мережевий адаптер
За кнопці Advanced відкриваємо додаткові параметри IPv4 і відключаємо реєстрацію в DNS, а також у властивостях віртуального адаптера включаємо підтримку Jumbo Packet
І так як ми налаштовували на мережеві інтерфейси використання великих пакетів Jumbo Packet нам необхідно упевнитися в тому що такі пакети дійсно можуть ходити між серверами в сегменті мережі DPM. Зробити це можна наприклад за допомогою команди Ping виставивши прапор заборони фрагментації пакетів і задати свідомо більшу величину пакета:
Якщо Ping не піде і ми отримаємо повідомлення про те що потрібна фрагментація пакета, значить на нашому мережевому обладнанні до якого підключені хости встановлено обмеження за розміром пакета і на цьому обладнанні також необхідно включати підтримку Jumbo Packet. Як зробити це наприклад на комутаторі Cisco я писав в минулій замітці.
Продуктивність мережевого інтерфейсу DPM
Крім того що для мережевих інтерфейсів виділених під трафік DPM ми задіяли підтримку Jumbo Packet. є ще пару моментів, на які можна звернути увагу з точки зору підвищення продуктивності.
У деяких джерелах можна зустріти рекомендацію про відключення технології TCP Chimney. Дізнатися поточний стан цієї функціональності можна командою:
netsh int tcp show global
Відключити TCP Chimney можна командою:
netsh int tcp set global chimney = disabled
Крім цього можна зустріти рекомендацію від відключенні апаратних функцій енергозбереження і змусити працювати сервер в режимі High Performance. Зокрема відключити в BIOS для процесорів використання С-State. що (в деяких випадках) може позитивно вплинути на продуктивність мережевих інтерфейсів
Визначаємося з дозволом імен
На сервері 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. - попередньо потрібно виконати завантаження відповідного модуля:
Параметр 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 через виділений мережевий сегмент.
Додаткові джерела інформації: