Вичавлюємо гигабиты: або недокументированная можливість ViPNet Client/Coordinator

Всім привіт. Цей пост про те, як спонтанний експеримент і кілька годин, проведених в серверній, допомогли отримати цікаві результати по продуктивності рішення ViPNet Custom 4.3 у версії для Windows.



Вам вже цікаво? Тоді загляньте під кат.

1. Вступна

Спочатку дане тестування було просто внутрішнім власним експериментом. Але так як, на наш погляд результати вийшли досить цікавими, ми вирішили опублікувати, отримані дані.

Що таке ПО ViPNet Custom? Якщо коротко, то це комплекс міжмережевого екранування і шифрування, розроблений компанією «Інфотекс» у відповідності з вимогами ФСБ і ФСТЕК Росії.

На момент тестування рішення були відсутні які-небудь дані про виміри продуктивності програмного варіанти ViPNet Custom на різних конфігураціях. Цікаво було порівняти результати програмної реалізації ViPNet Custom з апаратною реалізацією ViPNet Coordinator HW1000/HW2000, продуктивність яких відома та задокументована вендором.

2. Опис початкового стенду

Згідно з даними з сайту infotecs.ru ВАТ «Інфотекс» найбільш потужні конфігурації платформ HW мають наступні характеристики:

Тип Платформа Процесор Пропускна здатність
HW1000 Q2 AquaServer T40 S44 Intel Core i5-750 До 280 Mb/s
HW2000 Q3 AquaServer T50 D14 Intel Xeon E5-2620 v2 До 2.7 Gb/s


На жаль, якихось додаткових відомостей про умови тестування надано не було.

Спочатку ми отримали доступ до обладнання з наступними характеристиками:
1) IBM system x3550 M4 2 x E5-2960v2 10 core 64 GB RAM;
2) Fujitsu TX140 S1 E3-1230v2 4 core 16GB RAM.

Використання сервера Fujitsu в експерименті було поставлено під сумнів… Бажання відразу штурмувати 10GbE завадила відсутність мережі на обладнанні, тому ми вирішили залишити його, як початкову відправну точку.

На IBM ми організували 2 віртуальних сервера з віртуальним 10-гігабітним світчем на базі платформи ESX 6.0u1b і після оцінили загальну продуктивність двох віртуальних машин.

Опис стенду:

1. Сервер IBM system x3550 M4 2 x E5-2960v2 10 core 64 GB RAM, ESXi 6.0u1.
Для кожної віртуальної машини (VM) виділений один фізичний процесор з 10 ядрами.

VM1: Windows 2012 R2 (VipNet Coordinator 4.3_(1.33043) ):
• 1 CPU 10 core;
• 8GB RAM.
VM2: Windows 8.1 (ViPNet Client 4.3_(1.33043) ):
• 1 CPU 10 core;
• 8GB RAM.

VM підключені до віртуального комутатора 10Gbps, встановлений MTU 9000.

2. Сервер Fujitsu TX140 S1 E3-1230v2 4 core 16Gb RAM, Windows 2012 R2, ViPNet Client 4.3_(1.33043).

Фізичні сервери IBM і Fujitsu з'єднані гігабітної мережі MTU 9000. Hyper Threading відключений на обох серверах. В якості навантажувального ЗА використовувався Iperf3.

Схема стенду представлена на малюнку 1.



Малюнок 1 — Схема організації стенду тестування

3. Перший етап тестування

На жаль, підготовка цієї статті почалася вже після проведення всіх тестів, тому для даного розділу скріншоти результатів, крім фінального, не збереглися.

3.1. Тест №1

Спочатку оцінимо, чи зможемо ми забезпечити пропускну здатність мережі 1 Gb/s. Для цього нагрузим віртуальний координатор VM1 Windows 2012 R2 (ViPNet Coordinator 4.3) і фізичний сервер Fujitsu TX140 S1.

На стороні VM1 Iperf3 запущений в режимі сервера.
На стороні сервера Fujitsu Iperf3 запущений з параметрами

Iperf.exe –c ІР_сервера –P4 –t 100,

де параметр –P4 вказує кількість потоків на сервері, рівне кількості ядер.

Тест проводився три рази. Результати наведені в таблиці 1.

Таблиця 1. Результат тесту №1

Хост Завантаження CPU Досягнута навантаження Канал
VM1 Windows 2012 R2 (ViPNet Coordinator 4.3) <25% 972 Mbps 1Gbps
Fujitsu TX140 S1 100% 972 Mbps 1Gbps


За результатами зроблені наступні висновки:
1) процесор E3-1230v2 в задачі шифрування може забезпечити пропускну здатність мережі 1Gb/s;
2) віртуальний координатор завантажений менш ніж на 25%;
3) при аналогічному процесорі, офіційна продуктивність ViPNet Coordinator HW1000 перевищена майже в 4 рази.

Якщо виходити з отриманих даних видно, що сервер Fujitsu TX140 S1 досяг своєї максимальної продуктивності. Тому подальше тестування будемо проводити тільки з віртуальними машинами.

3.2. Тест №2

Ось і настав час великих швидкостей. Протестуємо віртуальний координатор VM1 Windows 2012 R2 (ViPNet Coordinator 4.3) і VM2 Windows 8.1 (ViPNet Client 4.3).

На стороні VM1 Iperf3 запущений в режимі сервера.
На стороні сервера VM2 Iperf3 запущений з параметрами

Iperf.exe –c ІР_сервера –P10 –t 100,

де параметр –P10 вказує кількість потоків на сервері, рівне кількості ядер.

Тест проводився три рази. Результати наведені в таблиці 2

Таблиця 2. Результат тесту №2

Хост Завантаження CPU Досягнута навантаження Канал
VM1 Windows 2012 R2 (ViPNet Coordinator 4.3) 25-30% 1.12 Gbps 10 Gbps
VM2 Windows 8.1 (ViPNet Client 4.3) 25-30% 1.12 Gbps 10 Gbps


Як видно, результати не сильно відрізняються від попередніх. Тест був виконаний ще кілька разів з наступними змінами:
• серверна частина iperf перенесена на VM2;
• замінена гостьова ОС на VM2 на Windows Server 2012 R2 ViPNet Coordinator 4.3;

В усіх протестованих комбінаціях результати залишалися однаковими в межах похибки.
З'явилося розуміння, що, найімовірніше, є вбудоване обмеження в самому ПО ViPNet.

Після декількох варіантів тестування, з'ясувалося, що при запуску Iperf3 з параметрами
Iperf.exe –c ІР_сервера –P4 –t 100
пропускна здатність стала практично аналогічною, досягнутої раніше, на сервері Fujitsu.

При цьому максимально завантаженими стали 4 ядра процесора – рівно 25% від його потужності.

Отримані результати остаточно переконали в тому, що обмеження присутній. Результати спрямовані виробнику із запитом варіантів вирішення проблеми.

4. Продовження експерименту

Незабаром було отримано відповідь від виробника:
«Кількістю процесорів можна керувати значенням ключа HKLM\System\CurrentControlSet\Control\Infotecs\Iplir, в ньому значення ThreadCount. Якщо значення -1 або не задано, то кількість потоків вибирається рівним кількості процесорів, але не більше 4. Якщо встановлено якесь значення, то вибирається кількість потоків дорівнює цьому значенню».

Що ж, здогадка була вірна. Налаштуємо стенд на максимальну продуктивність, встановивши значення параметра ThreadCount дорівнює 10 на обох віртуальних машинах.

4.1. Тест №3

Після внесення всіх необхідних змін знову запускаємо Iperf.

На стороні VM1 Iperf3 запущений в режимі сервера. На стороні сервера VM2 Iperf3 запущений з параметрами
Iperf.exe –c ІР_сервера –P10 –t 100,

де параметр –P10 вказує кількість потоків на сервері, рівне кількості ядер.

Тест проводився три рази. Результати наведені в таблиці 3 і малюнках 2-3

Таблиця 3. Результат тесту №3

Хост Завантаження CPU Досягнута навантаження Канал
VM1 Windows 2012 R2 (ViPNet Coordinator 4.3) 100% 2,47 Gbps 10 Gbps
VM2 Windows 8.1 (ViPNet Client 4.3) 100% 2,47 Gbps 10 Gbps




Малюнок 2 — Висновок iPerf3 на VM1 Windows 2012 R2 (ViPNet Coordinator 4.3)



Малюнок 3 — Висновок iPerf3 на VM2 Windows 8.1 (ViPNet Client 4.3)

За результатами зроблені наступні висновки:
1) внесені зміни дозволили досягти максимальної продуктивності шифрування при повній утилізації процесора;
2) сумарну продуктивність при використанні двох Xeon E5-2960v2 можна вважати рівною 5 Gbps;
3) при врахуванні загальної продуктивності двох процесорів отримана продуктивність шифрування у 2 рази перекриває офіційні результати ViPNet Coordinator HW2000.

Отримані результати тільки підігрівали інтерес, що можна отримати ще більше. На щастя, вийшло отримати доступ до більш потужного обладнання.

Так само варто відзначити, що в ході тестування не було виявлено різниці в пропускній спроможності між ViPNet Client і ViPNet Coordinator.

5. Другий етап тестування

Для подальших розвідок у питанні продуктивності програмної частини ПО ViPNet, ми отримали доступ до двом окремим блейд-серверів з наступними характеристиками:
• CPU 2 x E5-2690v2 10 core;
• ESXi 6.0u1.

Кожна віртуальна машина розташована на своєму окремому «лезі».

VM1: Windows 2012 R2 (ViPNet Client 4.3_(1.33043) ):
• 2 CPU 20 core;
• 32 GB RAM.

VM2: Windows 2012 R2 (ViPNet Client 4.3_(1.33043) ):
• 2 CPU 20 core;
• 32 GB RAM.

Мережеве з'єднання між віртуальними машинами здійснюється через интреконнект блейд-сервера з пропускною здатністю 10 Gbps з MTU 9000. Hyper Threading відключений на обох серверах.

Для імітації навантаження використовувалося програмне забезпечення iPerf3 і, додатково, Ntttcp з наступними основними параметрами:

1) на приймаючій стороні:

Iperf.exe –s;

на передавальній стороні:

Iperf.exe –cserver_ip –P20 –t100;

2) на приймаючій стороні:

NTttcp.exe -r -wu 5 -cd 5 -m 20,*,self_ip -l 64k -t 60 -sb 128k -rb 128k;

на передавальній стороні:

NTttcp.exe -s -wu 5 -cd 5 -m 20,*,server_ip -l 64k -t 60 -sb 128k -rb 128k.

Схема організації стенду представлена на малюнку 4.



Малюнок 4 — Схема організації стенду тестування

5.1. Тест №4

Для початку проведемо перевірку пропускної здатності мережі без шифрування. ЗА ViPNet не встановлено.

Тест проводився три рази. Результати наведені в таблиці 4 і малюнках 5-6.

Таблиця 4. Результат тесту №4

Хост Завантаження CPU Досягнута навантаження Канал
Ntttcp 2,5% 8,5 Gbps 10 Gbps
Iperf 4% 9,3 Gbps 10 Gbps




Рисунок 5 — Результат тестування Ntttcp без шифрування



Малюнок 6 — Результат тестування Iperf без шифрування

За результатами були зроблені наступні висновки:
1) була досягнута пропускна здатність мережі в 10 Gbps;
2) є різниця в результатах ПО для тестування. Далі для достовірності результати будуть публікуватися як для Iperf, так і для Ntttcp.

5.2. Тест №5

Встановимо значення параметра ThreadCount рівне 20 на обох віртуальних машинах і заміримо результати.

Тест проводився три рази. Результати наведені в таблиці 5 і малюнках 7-8.

Таблиця 5 – Результат тесту №5

Хост Завантаження CPU Досягнута навантаження Канал
Ntttcp 74-76% 3,24 Gbps 10 Gbps
Iperf 68-71% 3,36 Gbps 10 Gbps




Малюнок 7 — Результат тестування Ntttcp з шифруванням



Малюнок 8 — Результат тестування Iperf з шифруванням

За результатами були зроблені наступні висновки:

1) на одиничному сервері була перевищена теоретична продуктивність ViPNet Coordinator HW2000;
2) не була досягнута теоретична продуктивність в 5 Gbps;
3) завантаження CPU не досягла 100%;
4) зберігається різниця в результатах ПО для тестування, але, на даний момент, вона мінімальна.

Виходячи з того, що процесори не серверах не були повністю утилізовані, звернемо увагу на обмеження з боку драйвера ViPNet на одночасне кількість потоків шифрування.

Для перевірки обмеження подивимося завантаження одного ядра процесора при операції шифрування.

Тест №6

У даному тесті будемо використовувати тільки Iperf, так як, за результатами попередніх тестів, він дає більше навантаження на процесор, з параметрами

Iperf.exe –cIP_server –P1 –t100.

На кожному сервері через реєстр обмежимо ViPNet на використання одного ядра при операції шифрування.

Тест проводився три рази. Результати наведені на малюнках 9-10.



Малюнок 9 — Утилізація одного ядра при операції шифрування



Малюнок 10 — Результат тестування Iperf з шифруванням при завантаженні одного ядра

За результатами були зроблені наступні висновки:

1) одиничне ядро було завантажене на 100%;
2) виходячи із завантаження одного ядра, 20 ядер повинні давати теоретичну продуктивність в 5.25 Gbps;
3) виходячи з завантаження одного ядра, ЗА ViPNet має обмеження у 14 ядер.

Для перевірки обмежень на ядра проведемо ще один тест з задіяними 14 ядрами на процесорі.

Тест №7

Тестування з шифруванням з 14 ядрами.

У даному тесті будемо використовувати тільки Iperf з параметрами

Iperf.exe –cIP_server –P12 –t100.

На кожному сервері через реєстр обмежимо ViPNet на використання не більше 14 ядер при операції шифрування.



Малюнок 11 — Утилізація 14 ядер при операції шифрування



Малюнок 12 — Результат тестування Iperf з шифруванням при завантаженні 14 ядер

За результатом зроблені висновки:

1) були завантажені всі 14 ядер;
2) продуктивність аналогічна варіанту з 20 ядрами;
3) є ліміт 14 ядер при многопоточной операції шифрування.

Результати тестів були спрямовані виробнику із запитом варіантів вирішення проблеми.

6. Висновок

Через деякий час було отримано відповідь виробника:

«Використання більше чотирьох ядер на координаторові Windows є недокументованій можливістю, і її правильна робота не перевіряється і не гарантується».

Думаю, на цьому тестування можна закінчити.

Чому ж програмний варіант досить сильно вирвався вперед в результатах тестування?

Швидше за все причин кілька:
1) Старі результати тестування. На нових прошивках, за неофіційними даними, продуктивність HW сильно підросла;
2) Недокументовані умови тестування.
3) Не варто забувати, що для отримання максимального результату використовувалася недокументированная можливість.

Залишилися питання? Задавайте їх у коментарях.

Андрій Куртасанов, Softline
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.