Задача получения статистики к сожалению еще актуальна в сетях доступа. При типичных скоростях абонентского доступа до 100 Мбит/с и суммарном канале с полосой примерно 1 Гбит/с для снятия статистики сетевых пакетов часто используется mirror с порта L2 или L3 коммутатора. Это объясняется тем, что в ядре такой сети ставят не очень дорогие коммутаторы, которые поддерживают максимум sflow-протокол, который даё1т лишь примерную оценку.

 

В качестве коллектора netflow обычно используется пакет nfsen, имеющий удобный web-интерфейс и подобные решения. А вот тема выбора софтового сенсора на *NIX-платформе раскрыта слабо. Если при потоке со скоростью  порядка нескольких десятков мегабит/с по большому счету не важно, чем считать, то при скорости около 1Гбит/с ресурсов даже современного процессора может не хватить.

 

В интернете есть статьи о чудовищном превосходстве линуксовой ядерной приблуды к iptables ipt_NETFLOW, которая якобы на порядок снижает загрузку сервера, по сравнению с решениями user-level, например softflowd. Покажем, что в настоящей системе тоже есть альтернативы юзер-левелу. Для этого проведем сравнение четырех наиболее популярных netflow-сенсоров:

1. ipcad;

2. fprobe;

3. softflowd;

4. ng_netflow.

 

Отметим, что первые три сенсора это как-раз приложения user-level и используют библиотеку libpcap. Не вдаваясь в теории сразу перейдем к делу. Тестовый стенд – сервер с FreeBSD 8.2 RELEASE, процессор Intel Duo Core E5300 @ 2.60GHz. Рабочий сетевой интерфейс Intel PRO/1000 PL Network Adaptor (82573L). Для управления и мониторинга я поставил еще и вторую сетевую -  realtek 8139. Тестовый трафик – поток, генерируемый с помощью iperf между двумя хостами с гигабитными интерфейсами:

 

Это соответствует примерно 80kpps, которые mirror-ом направляются на порт, к которому подключена интеловская сетевая тестового сервера.

 Запускаем iperf сначала с «чистым» сервером, т.е. никакой дополнительной обработки пакетов в ядре нет, сетевой адаптер принудительно переведен в режим promiscous  и все пакеты поступают в ядро.

 Далее запускаем ipcad практически с дефолтным конфигом

 

Потом запускаем fprobe

 

Потом softflowd

 

И, наконец, настраиваем ng_netflow уровня ядра, непосредственно на интерфейсе, согласно мануалу через ноду netflow

 

В качестве оценки загрузки процессора используем графики, построенные по rrd-базам, которые создает collectd (дискретность 10 секунд).

 

Теперь можно делать эмпирические выводы. Вычтем из  суммарной загрузки двух ядер статическую загрузку, полученную при отсутствии сенсоров и построим диаграмму.

 

Как и следовало ожидать, ng_netflow уровня ядра наиболее экономично использует ресурсы процессора. Разница между ng_netflow и softflowd составляет 100%, а между ng_netflow и ipcad  – 200%. Сама обработка ng_netflow примерно на 30% увеличивает загрузку процессора. Теоретически на базе Duo Core E5300 можно построить сенсор с производительностью 2 Гбит/с (правда при условии использования драйверов em от Yandex или сетевых карт c контроллером intel 82576). Учитывая, мягко говоря, ничтожную производительность моего тестового процессора по сравнению с современными топовыми i7 (12 логических ядер), можно предположить, что софтовый сенсор с производительность 10Gbit/s технически не проблема, естественно при использовании ядерной обработки пакетов.