Погладжуємо ящірку або мережеве навантажувальне тестування з cisco trex



Тему навантажувального тестування мережевого обладнання прийнято якось обходити стороною, зазвичай згадується побіжно в розрізі моторошно дорогого спеціалізованого заліза. Не знайшов інформації про даний open-source продукт російською мовою так що дозволю собі злегка популяризувати. У статті опишу невеликий HOWTO з метою познайомити людей з софтварными трафік генераторами.

Cisco TREX — високопродуктивний генератор трафіку. Для своєї роботи використовує dpdk. Апаратні вимоги — 64-bit архітектура, сумісна мережева карта, підтримувані ос * Fedora 18-20, 64-bit kernel (not 32-bit) * Ubuntu 14.04.1 LTS, 64-bit kernel (not 32-bit). Ви можете запустити на іншому лінуксі, запилив собі необхідні драйвера і зібравши свою версію з файлів, які лежать в репозиторії на гітхабі, тут все стандартно.

DPDK


Data Plane Development Kit (DPDK), спочатку розроблений Intel і переданий у відкрите співтовариство.
DPDK це фреймворк який надає набір бібліотек і драйверів для прискорення обробки пакетів в додатках, що працюють на архітектурі Intel. DPDK підтримується на будь-яких процесори від Intel Atom до Xeon, будь розрядності і без обмеження за кількістю ядер і процесорів. В даний час DPDK портируется і на інші архітектури, відмінні від x86 — IBM Power 8, ARM і ін
Якщо не заглиблюватися в технічні подробиці, DPDK дозволяє повністю виключити мережевий стек Linux з обробки пакетів. Додаток, що працює в User Space, безпосередньо спілкується з апаратним забезпеченням.
Крім підтримки фізичних карток є можливість працювати з paravirtualized картами VMware (VMXNET /
VMXNET3, Connect using VMware vSwitch) і E1000 (VMware/KVM/VirtualBox).

DEPLOY


Скачаємо, распакуем, зберемо trex.
WEB_URL=http://trex-tgn.cisco.com/trex # або csi-wiki-01:8181/trex (Cisco internal)
mkdir trex
cd trex
wget --no-cache $WEB_URL/release/v2.05.tar.gz
tar -xzvf v2.05.tar.gz
cd v2.05
cd ko/src 
make 
make install 
cd - 


Інтерфейси, з яких буде проводитися тестування, необхідно витягнути з лінукса і передати під управління dpdk, для цього необхідно виконати команду, яка виведе PCI id всіх інтерфейсів.
$>sudo ./dpdk_setup_ports.py --s

Network devices using DPDK-compatible driver
============================================

Network devices using kernel driver
===================================
0000:02:00.0 '82545EM Gigabit Ethernet Controller (Copper)' if=eth2 drv=e1000 unused=igb_uio *Active*
0000:03:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv= unused=ixgb #1
0000:03:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv= unused=ixgb #2
0000:13:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv= unused=ixgb #3
0000:13:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv= unused=ixgb #4


Other network devices
=====================


Потім додати їх в конфігураційний файл, рекомендується скопіювати, бо тоді trex буде його автоматично підхоплювати, без необхідності вказувати шлях в ручну при кожному запуску.
cp cfg/simple_cfg.yaml /etc/trex_cfg.yaml

Як ви встигли помітити, конфігурація зберігається в популярному нині форматі YAML, забігаючи вперед, в ньому зберігаються конфігураційні файли тестів. У ньому так само рекомендується задати мак адреси.
На всякий випадок приклад того, як файл має вигляд:
- port_limit : 2
версія : 2
interfaces : ["03:00.0","03:00.1"] 2
port_info : # set eh mac addr
- dest_mac : [0x1,0x0,0x0,0x1,0x0,0x00] # port 0
src_mac : [0x2,0x0,0x0,0x2,0x0,0x00] 1
- dest_mac : [0x2,0x0,0x0,0x2,0x0,0x00] # port 1 1
src_mac : [0x1,0x0,0x0,0x1,0x0,0x00

port 0 — src
port 1 — dst

Давайте вже нагрузим що-небудь


Фізичні інтерфейси необхідно підключити куди-небудь за схемою " вхід-вихід. Один інтерфейс буде посилати пакети інший приймати (насправді генератор вміє емулювати повноцінні чесні tcp сесії, але зараз не про це)

Наступна команда запустить тест, який буде навантажувати залізо dns запитом в одному і тому ж напрямку протягом 100 секунд, до речі, якщо ви захочете щоб шаблон відпрацьовував на всіх інтерфейсах(даний пакет йшов в обох напрямках), то можна додати ключ -p
sudo ./t-rex-64 -f cap2/dns.yaml -c 4 -m 1 -d 100 -l 1000

-c — число ядер процесора.
-m — множник cps кожного шаблону пакетів.
-d — час тесту.
-l — частота (Hz) latency пакетів, багато параметрів вважається без їх урахування.

В даному випадку висновок буде містити щось таке (злегка стиснув, вибравши найцікавіше)
-Global stats enabled
Cpu Utilization : 0.0 % 29.7 Gb/core 
Platform_factor : 1.0
Total-Tx : 867.89 Kbps 
Total-Rx : 867.86 Kbps 
Total-PPS : 1.64 Kpps
Total-CPS : 0.50 cps

Expected-PPS : 2.00 pps 9
Expected-CPS : 1.00 cps 10
Expected-BPS : 1.36 Kbps 11

Active-flows : 0 6 Clients : 510 Socket-util : 0.0000 %
Open-flows : 1 7 Servers : 254 Socket : 1 Socket/Clients : 0.0
drop-rate : 0.00 bps 
current time : 5.3 sec
test duration : 94.7 sec

Cpu Utilization — середнє значення навантаження на CPU передають тредами. Для налучшей продуктивності рекомендується тримати менше 80%.
Total-Tx — сумарна швидкість на передавальному інтерфейсі (в даному випадку port 0)
Total-Rx — сумарна швидкість на приймаючому інтерфейсі (в даному випадку port 1)
Total-PPS — packets per second число пакетів на інтерфейсах
Total-CPS — connections per second по суті цей параметр означає число запуску шаблонів, які вказані в конфігураційному файлі в секунду.

Expected-PPS — Очікуване число пакетів в секунду, в теорії прагне до cps*число пакетів шаблону.
Expected-CPS — cps зазначений в yaml файлі тесту.
Expected-BPS — сумарний трафік, обсяг шаблону * cps.

Active-flows — число внутрішніх потоків t-rex. По суті цей параметр є числом сесій, за якими стежить t-rex. наприклад, якщо ви запустіть тест з pcap тривалість сесії в якому дорівнює 30 сек, то це показник повинен прагне до 30*Expected-CPS.

При бажанні дійсно «навантажити» мережу, можна збільшити множник шаблону і додати -p
sudo ./t-rex-64 -f cap2/dns.yaml -c 4 -m 9000 -d 100 -l 1000 -p

Буде збільшено кількість потоків з одним і тим же IP, якщо критично різноманітність трафіку (src адрес), то необхідно збільшувати CPS, в конфігураційному файлі, до речі про нього.

Конфігурації тестів


Розглянемо cap2/dns.yaml:
- duration : 10.0
generator : 
distribution : "seq"
clients_start : "16.0.0.1"
clients_end : "16.0.1.255"
clients_end : "48.0.0.1"
servers_end : "48.0.0.255"
clients_per_gb : 201
min_clients : 101
dual_port_mask : "1.0.0.0" 
tcp_aging : 1
udp_aging : 1
mac : [0x00,0x00,0x00,0x01,0x00,0x00]
#vlan : { enable : 1 , vlan0 : 100 , vlan1 : 200 }
#mac_override_by_ip : true
cap_info : 
- name: cap2/dns.pcap
cps : 1.0
ipg : 10000
rtt : 10000
w : 1

clients_start — clients_end — діапазон rsc адерсов.
clients_start — clients_end — діапазон dst адрес.

— name: cap2/dns.pcap — задаємо pcap файл, який буде використовуватися в якості шлаблона.
cps — число з'єднань в секунду, по суті дорівнює числу одночасно послідовно запущених потоків з вашого шаблону. Тобто якщо в тесті у вас инкрементируется адресу, а cps: 10 то буде одночасно запущено 10 потоків з різними адресами.
ipg — повинен бути таким же як rtt.

У загальному випадку логіка тирекса виглядає так: він проходить по всьому діапазону IP адрес, на кожній ітерації змінюючи dst й src адреси, коли вони закінчуються, цикл повторюється з інкрементом порту і так 64к разів.

Тестуємо NAT


Серйозні хлопці з циски реалізували дуже важливу функцію, вони дозволили генератора створювати чесні tcp сесії і стежити за ними. Наприклад, якщо між нашими інтерфейсами буде NAT, то можна сказати «у нас нат» і трафік буде враховуватися з детектуванням трансляції.
Всього є три режими:
mode 1 Цей режим працює тільки на TCP. Дивимося на ACK, який приходить за першим SYN і таким чином навчаємося. Це хороший чесний режим.
mode 2 Працює з IP option.
mode 3 Працює як режим 1, тільки не вчить Sequence Number на сервері у бік клієнта. Може дати приріст cps відносного першого режиму.

sudo ./t-rex-64 -f cap2/http_simple.yaml -c 4 -l 1000 -d 100000 -m 30 --learn-mode 1

-Global stats enabled 
Cpu Utilization : 0.1 % 13.4 Gb/core 
Platform_factor : 1.0 
Total-Tx : 24.12 Mbps Nat_time_out : 0 
Total-Rx : 24.09 Mbps Nat_no_fid : 0 
Total-PPS : 5.08 Kpps Total_nat_active: 1 
Total-CPS : 83.31 cps Total_nat_open : 1508 

Expected-PPS : 3.08 Kpps 
Expected-CPS : 83.28 cps 
Expected-BPS : 22.94 Mbps 

Active-flows : 11 Clients : 252 Socket-util : 0.0001 % 
Open-flows : 1508 Servers : 65532 Socket : 11 Socket/Clients : 0.0 
drop-rate : 0.00 bps 
current time : 18.7 sec 
test duration : 99981.3 sec 

Nat_time_out — має бути нуль, число потоків, за якими тірекс з якихось причин не зміг устежити, зазвичай відбувається якщо пакети десь дропают.
Nat_no_fid — має бути нуль, зазвичай відбувається при занадто великих таймаутах всередині досліджуваного устаткування.
Total_nat_active: активне кількість потоків, має бути низьким при низькому rtt.
Total_nat_open: загальне число потоків, може відрізнятися пр однонаправленому (uni-directional) шаблоні.

Насправді є ще один важливий параметр, який ми не вказали--l-pkt-mode потрібна ця штука для вказівки типу пакетів, якими ми вимірюємо latency, саме до нього належить ключ -l, до речі, вони не враховуються ніде крім виводу latency, тобто на параметри типу open-flows впливати не повинні.
0 (default) SCTP packets;
1 ICMP з обох сторін;
2 Stateful, відправляє ICMP з одного боку і матчит їх з іншого. Цей параметр має сенс, якщо ваше обладнання дропает пакети зовні;
3 відправляє ICMP пакети завжди з 0 sequence number.

Кінець.


Якщо буде зацікавленість наступного разу розповім про зміни у версії 2.06.
Настійно рекомендую розглянути даний генератор для тестування ваших проектів, він невибагливий, доступний, і, найголовніше, open source.

Джерела
trex-tgn.cisco.com/trex/doc
sdnblog.ru/what-is-intel-dpdk
github.com/cisco-system-traffic-generator/trex-core
Джерело: Хабрахабр

0 коментарів

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