Эта статья была первоначально опубликована в моем личном блоге toonk.io
Часто в моей, сейчас 20 лет, в сетевой карьере, мне приходилось делать какую -то форму тестирования производительности сети. В отличие от использования, от устранения неисправностей проблемы клиента до тестирования нового сетевого оборудования, и в настоящее время все больше и больше виртуальных сетевых функций и программных «ударов в проводе».
Мне всегда нравилось играть с аппаратными генераторами трафика. Мой первый опыт работы с аппаратным тестированием ixia восходит к я думаю, что в 2003 году в Амстердамский интернет -обмен где мы тестировали совершенно новые карты Foundry 10G. Эти аппаратные тестеры были очень мощными и отличным инструментом для проверки нового снаряжения, такой как карты линейки маршрутизатора, брандмауэры и снаряжение IPSec. Тем не менее, у нас не всегда есть доступ к этим аппаратным генераторам трафика, поскольку они, как правило, довольно дороги или доступны только в лаборатории. В этом блоге мы рассмотрим программный генератор трафика, который любой может использовать — на основе DPDK. Когда вы проходите через это, помните, что сценарии и дополнительную информацию можно найти на моя страница GitHub здесь Анкет
DPDK, комплект разработки плоскости данных, является программным проектом с открытым исходным кодом, созданным Intel и теперь управляется Foundation Linux. Он предоставляет набор библиотек плоскости данных и драйверов контроллера сетевого интерфейса, которые работают в пользовательском пространстве. Хорошо, давайте подумаем об этом для секунды, что это значит? Пользовательская сеть — это то, что вы, вероятно, все чаще слышите и читаете. Основной драйвер, лежащий в основе сети пользовательских пространств (он же обход ядра), связанный с тем, как Linux создал свой сетевой стек; Он построен как часть общей многоцелевой многопользовательской ОС. Сеть в Linux является мощным и богатым функциями, но это лишь одна из многих особенностей Linux, и так; В результате сетевый стек должен играть справедливо и поделиться своими ресурсами с остальными программами ядра и пользователя. Конечным результатом является то, что получение нескольких (от 1 до 3) миллионов пакетов в секунду через сетевой стек Linux — это то, что вы можете сделать в стандартной системе. Этого недостаточно, чтобы заполнить ссылку 10G в размере 64 байт -пакетов, что эквивалентно 14 -метровым пакетам в секунду (PPS). Это тот момент, когда традиционный способ, управляемый прерыванием (IRQS) сети в Linux, начинает ограничивать то, что необходимо, и именно здесь появляется DPDK. С помощью программ DPDK и пользовательских сетевых взаимодействий мы убираем NIC из ядра и передаем его программе DPDK пользователя. Драйвер DPDK представляет собой драйвер режима вытягивания (PMD), что означает, что, как правило, одно ядро на NIC всегда использует 100% процессор, он находится в оживленном цикле, который всегда тянет к пакетам. Это означает, что вы увидите, что ядро работает на 100%, независимо от того, сколько пакетов прибывает или отправляется на этот NIC. Это, очевидно, немного отходы, но в настоящее время, с множеством сердечников и необходимостью в системах высокой пропускной способности, это часто является отличным компромиссом, и, что самое приятное, это позволяет нам добраться до 14-метрового числа PPS на Linux.
Хорошо, высокая производительность, мы все должны переехать в DPDK, верно?! Что ж, есть только одна проблема … поскольку мы сейчас обходим ядро, мы не можем извлечь выгоду из богатых функций Linux, таких как NetFilter, и даже не некоторые из того, что мы сейчас считаем основными функциями, такими как стек TCP/IP. Это означает, что вы не можете просто запустить свои приложения Nginx, MySQL, Bind и т. Д., На основе сокетов с DPDK, так как все они полагаются на API сокета Linux и ядро. Таким образом, хотя DPDK дает нам большую скорость и производительность, обходив ядро, вы также теряете много функциональности.
В настоящее время в настоящее время существует довольно много приложений на основе DKDK, варьирующихся от сетевых переходных, таких как программные маршрутизаторы и коммутаторы, а также стеки TCP/IP, такие как F-Stack. В этом блоге мы рассмотрим DPDK-PKTGEN, генератор трафика на основе DPDK, поддерживаемый командой DPDK. Я собираюсь пройти через установку DPDK, настраивать SR-IOV и запустить PKTGEN; Все приведенное ниже было протестировано на сервере Packet.com типа x1.small.x86 который имеет единый intel x710 10g NIC и 4 -основной процессор E3–1578L Xeon. Я использую Ubuntu 18.04.4 LTS.
Во -первых, нам нужно установить библиотеки, инструменты и драйверы DPKD. Существуют различные способы установки DPDK и PKTGEN; Я решил собрать код из источника. Есть несколько вещей, которые вам нужно сделать; Чтобы облегчить это, вы можете скачать тот же сценарий Bash, который я использовал, чтобы помочь вам с установкой.
Одна из проблем с DPDK заключается в том, что он будет полностью контролировать NIC. Чтобы использовать DPDK, вам нужно будет выпустить NIC из ядра и дать его DPDK. Учитывая, что у нас есть только один NIC, как только мы отдаем его DKDK, я бы потерял весь доступ (помните, что нет простого способа продолжать использовать SSH и т. Д., Поскольку он полагается на ядро Linux). Как правило, люди решают это, имея NIC Management NIC (для Linux) и один или несколько NIC для DPDK. Но у меня есть только один NIC, поэтому мы должны быть креативными: мы собираемся использовать SR-IOV для достижения того же самого. SR-IOV позволяет нам создавать один сетевой вид как несколько слотов PCI, поэтому мы виртуализируем NIC. Чтобы использовать SR-IOV, нам нужно включить iOmmu в ядро (сделано в скрипте установки DPDK). После этого мы можем установить количество виртуальных функций (количество новых PCI NIC)
echo 1 > /sys/class/net/eno1/device/sriov_numvfs ip link set eno1 vf 0 spoofchk off ip link set eno1 vf 0 trust on
dmesg -t покажет что -то вроде этого:
[Tue Mar 17 19:44:37 2020] i40e 0000:02:00.0: Allocating 1 VFs. [Tue Mar 17 19:44:37 2020] iommu: Adding device 0000:03:02.0 to group 1 [Tue Mar 17 19:44:38 2020] iavf 0000:03:02.0: Multiqueue Enabled: Queue pair count = 4 [Tue Mar 17 19:44:38 2020] iavf 0000:03:02.0: MAC address: 1a:b5:ea:3e:28:92 [Tue Mar 17 19:44:38 2020] iavf 0000:03:02.0: GRO is enabled [Tue Mar 17 19:44:39 2020] iavf 0000:03:02.0 em1_0: renamed from eth0
Теперь мы можем увидеть новое устройство PCI и NIC Name:
root@ewr1-x1:~# lshw -businfo -class network | grep 000:03:02.0 pci@0000:03:02.0 em1_0 network Illegal Vendor ID
Далее мы рассмотрим эту секунду из ядра и отдам его DPDK для управления:
/opt/dpdk-20.02/usertools/dpdk-devbind.py -b igb_uio 0000:03:02.0
Мы можем подтвердить это, как это (примечание EM2 не подключено и не используется):
/opt/dpdk-20.02/usertools/dpdk-devbind.py -s Network devices using DPDK-compatible driver ============================================ 0000:03:02.0 'Ethernet Virtual Function 700 Series 154c' drv=igb_uio unused=iavf,vfio-pci,uio_pci_generic Network devices using kernel driver =================================== 0000:02:00.0 'Ethernet Controller X710 for 10GbE backplane 1581' if=eno1 drv=i40e unused=igb_uio,vfio-pci,uio_pci_generic 0000:02:00.1 'Ethernet Controller X710 for 10GbE backplane 1581' if=em2 drv=i40e unused=igb_uio,vfio-pci,uio_pci_generic
Теперь, когда мы готовы начать тестирование, я должен объяснить нашу простую настройку тестов. Я использую два сервера x1-mmall; Один из них-отправитель (работающий DPDK-PKTGEN), другой-ванильная машина Ubuntu. То, что мы собираемся проверить, — это возможность ядра приемника, иногда называемого тестовым устройством (DUT), забрать пакеты из NIC. Это все; Мы ничего не обрабатываем, IP -адрес, на который отправляются пакеты, даже не настроен на DUT, поэтому ядро отбросит пакеты как можно скорее после того, как выберет его из NIC.
ОК ОК ОК, время, чтобы начать тестирование! Давайте запустим PKTGEN и генерируем несколько пакетов! Мой первый эксперимент — выяснить, сколько я могу отправить в один поток на целевую машину, прежде чем он начнет сбрасывать пакеты.
Обратите внимание, что вы можете найти точную конфигурацию в GitHub Repo для этого блога Анкет Файл pktgen.pkt Содержит команды для настройки настройки теста. Вещи, которые я настроил, были Mac и IP -адресами, портами и протоколами, а также скоростью отправки. Обратите внимание, что я тестирую с 10.99.204.3 до 10.99.204.8. Это включенные сети, поэтому я устанавливаю MAC -адрес назначения на адрес шлюза по умолчанию. С конфигурацией, как определено в pktgen.pkt, я отправляю те же пакеты 64 байта (5 корпуса, UDP 10.99.204.3:1234> 10.99.204.8:81) снова и снова.
Я использую следующее, чтобы запустить PKTGEN.
/opt/pktgen-20.02.0/app/x86_64-native-linuxapp-gcc/pktgen — -T -P -m "2.[0]" -f pktgen.pkt
После настройки свойств скорости отправки на отправителе и мониторинга с помощью ./monitorpkts.sh На приемнике мы обнаруживаем, что один поток (один очередь, с одним ядром) будет чистым на этом приемном машине вплоть до примерно 120 тыс. PPS. Если мы поднимаем скорость отправки выше, чем эта, я начинаю наблюдать за сброшенными пакетами на приемнике. Это немного ниже, чем ожидалось, и, хотя это один поток, я вижу процессор, который служит этой очереди, имеющей достаточное количество простоя осталось. Должно быть что -то еще …
Ответ связан с кольцом буфера приема на сетевой карте приемника. Это было слишком мало для более высоких ставок пакетов. После того, как я увеличил его с 512 до 4096. Теперь я могу получить до 1,4 МПП, прежде чем увидеть капли, неплохой для одного потока!
ethtool -G eno1 rx 4096
PKTGEN также поставляется с возможностью настроить его для диапазонов. Примеры диапазонов включают IP -адреса источника и назначения, а также порты исходного и назначения. Вы можете найти пример в файле pktgen-range.pkt. Для большинства сред, это более типичный сценарий, поскольку ваш сервер, вероятно, будет служить множеству различных потоков из разных IP -адресов. Фактически, система Linux опирается на существование многих потоков, чтобы иметь возможность справиться с этими большими объемами трафика. Хэши и баланс ядра Linux Эти различные потоки в доступные очереди приема на NIC. Затем каждая очередь обслуживается отдельным потоком прерывания, позволяя ядру параллелизировать работу и использовать несколько ядер в системе.
Ниже вы найдете скриншот с тех пор, как я проводил тест со многими потоками. Терминалы приемника можно увидеть слева, отправитель справа. Главное, что нужно заметить здесь, это то, что в приемном узле используются все доступные процессоры, обратите внимание на процессы ksoftirqd/x. Поскольку мы используем широкий спектр портов исходного и назначения, мы получаем надлежащую балансировку нагрузки по всем ядрам. При этом я теперь могу достичь 0% потерянных пакетов до 6 Мпп. Чтобы добраться до 14 мин в 10 г, скорость линейки 10 г @64bytes, мне понадобится больше процессоров.
Наконец, мы запустим базовый тест IMIX, используя функцию DPDK-PKTGEN PCAP. Интернет -микс или IMIX относится к типичному интернет -трафику. При измерении производительности оборудования с использованием IMIX пакетов предполагается, что производительность напоминает то, что можно увидеть в условиях «реального мира».
imix pcap file Содержит 100 пакетов с размерами и соотношением в соответствии с Imix Spects Анкет
tshark -r imix.pcap -V | grep 'Frame Length'| sort | uniq -c|sort -n 9 Frame Length: 1514 bytes (12112 bits) 33 Frame Length: 590 bytes (4720 bits) 58 Frame Length: 60 bytes (480 bits)
Мне нужно переписать исходные и назначенные IP -адреса и MAC -адреса, чтобы они соответствовали моей текущей настройке, это можно сделать так:
tcprewrite \ — enet-dmac=44:ec:ce:c1:a8:20 \ — enet-smac=00:52:44:11:22:33 \ — pnat=16.0.0.0/8:10.10.0.0/16,48.0.0.0/8:10.99.204.8/32 \ — infile=imix.pcap \ — outfile=output.pcap
Более подробную информацию также см. Мои заметки здесь:> https://github.com/atoonk/dpdk_pktgen/blob/master/dpdkpktgen.md
Затем мы запускаем приложение PacketGen и даем ему PCAP
/opt/pktgen-20.02.0/app/x86_64-native-linuxapp-gcc/pktgen — -T -P -m "2.[0]" -s 0:output.pcap
Теперь я вижу, что отправляю и получаю пакеты со скоростью 3,2 млн. ПП на уровне 10 Гб, намного ниже максимума, который мы видели ранее. Это означает, что тестовое устройство (DUT) способно принимать пакеты на 10 ГБ, используя шаблон трафика IMIX.
Результат теста IMIX с PCAP в качестве источника. Получатель (DUT) Слева, окно отправителя справа.
В этой статье мы посмотрели на то, чтобы получить DPDK и запустить, немного рассказали о том, что такое DPDK, и использовали свое приложение PKTGen Traffic Generator. Типичная задача при использовании DPDK заключается в том, что вы теряете сетевой интерфейс, что означает, что ядро больше не может его использовать. В этом блоге мы решили это с помощью SR-IOV, что позволило нам создать второй логический интерфейс для DPDK. Используя этот интерфейс, я смог генерировать 14 МПП без проблем.
На принимающей стороне этого тестового трафика у нас была еще одна машина Linux (без DPDK), и мы проверили его способность получать трафик от NIC (после чего ядро сразу же бросило его). Мы увидели, как пакеты в секунду ограничены RX-буфером, а также возможностью для ядер CPU собирать пакеты (мягкие прерывания). Мы увидели, что одно ядро было в состоянии сделать около 1,4 МПП. Как только мы начали использовать больше ядер, создавая больше потоков, мы начали видеть выпущенные пакеты примерно на 6 м. PPS. Если бы у нас было бы больше процессоров, мы, скорее всего, смогут сделать больше, чем это.
Также обратите внимание, что на протяжении всего этого блога я говорил в основном из пакетов в секунду и не так много с точки зрения битов в секунду. Причина этого в том, что каждый новый пакет на приемнике Linux (DUT) создает прерывание. В результате количество прерываний, с которыми может обработать систему, является наиболее критическим индикатором того, сколько бит в секунду может обрабатывать систему Linux.
В целом, PKTGEN и DPDK требуют небольшой работы для настройки, и, несомненно, есть немного кривой обучения. Я надеюсь, что сценарии и примеры в репо Github помогут с вашим тестированием и запомнят: с большой силой приходит большая ответственность.
Оригинал: «https://dev.to/atoonk/building-a-high-performance-linux-based-traffic-generator-with-dpdk-27na»