[schnm]

Есть узел, через который проходит порядка 500Гб трафика в сутки. Из них порядка 300 тарифицируется. Роутер на базе линукса, подсчет идет с помощью ipcad через libipq. Роутер на базе серверной платы с p4-3Ghz. При росте трафика начались проблемы - загрузка процессора 80-100 процентов (грузит ipcad), в часы пик возможны потери пакетов из-за используемого способа подсчета, но только он гарантирует, что посчитается весь трафик. Переход на ulog или pcap не рассматривается. Попытались заменить машинку на двухпроцессорную (2x2.4Xeon), но результат только ухудшился - Ipcad грузит только один проц.

 

Мое виденье: т.к. все на изернете с достаточно широкими каналами, которые планируется расширять дальше, то либо начинать размножение серверов для подсчета трафика, либо брать catalyst 45xx с нефлоу модулем и забыть а проблеме.

 

Теперь вопрос - кто сталкивался с подобными ситуациями и как боролся? :) Может чего не так делаю?

[rus-p]

С Вашими объемами не сталкивался, могу только предположить, как можно решить проблему без покупки каталиста.

 

В FreeBSD есть модуль ng_netfow, поковыряйте его, у меня работал неплохо.

 

Тут уже не раз писалось что потеря 5-10% трафика при гигабитных скоростях не должна напрягать. Но если Вы считаете трафик в куче (локальный+инет) и боитесь потерять инет (как раз эти 10%). То как выход: разделите подсчет сетевыми средствами на два нетфлоу потока и два ипикада.

 

Чтоб был толк от двухпроцессорной машинки, поставьте две сетевые, выставите smp_affinity как нужно, и повесте по ипикаду на каждую сетевую, будут задействованы оба проца.

 

Если поток меньше гигабита, поставьте ipcad на отдельный комп и с помощью цискиного SPAN перенаправьте трафик. На 3750 можно поднять 2 SPAN-а, тоесть в пике посчитать 2 гигабита.

Изменено 7 ноября, 2006 пользователем rus-p

[Egor]

все-таки, лучше сменить ipcad на что-нибудь ядерное. Для FreeBSD это ng_netflow для Linux не знаю((

 

а каталист не факт, что поможет, поищите, тут где-то про это было.

[schnm]

Проблема как раз в том, что это весь интернетный трафик. И потери очень сильно недопустимы, а на данный момент эта линуксовая машина вносит как потери так и задержку.

 

С BSD незнаком, не хочется заниматься глубоким изучением, но видимо все к этому идет т.к. под линукс как раз проблема в том, что ничего аналогичного не обнаружено.

 

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

Изменено 7 ноября, 2006 пользователем schnm

[edwin]

> С каталистом проблем точно не возникнет,

 

Возникнут, причем серьезные.

на сетии 4xxx у них значительные проблемы с точностью netflow... тут это уже обсуждалось.

Ситуация в 65xx получше будет, но и там свои жуки есть...

[SergeiK]

Можно попробовать sflow с HP Procurve железяк, довольно не дорого, но там тоже все не однозначно.

Сыроваты они для операторства, на мой вкус.

[SergeiK]

Хм...

А вот посчитал, что 500гигабайт в сутки - это не много...

500*1024*1024/(24*3600*400) - 15,2kpps в среднем- это не нагрузка даже для средних маршрутизаторов Cisco. Ну, даже если пиковая нагрузка будет в 10 раз больше - всего 150kpps.

Например, 2801 90 kpps, а 2851 220 kpps. Цена - по любому меньше 4500 с Netflow.

И потенциал, как роутера - больше. Правда как быстрый свич никак не получится.

Изменено 7 ноября, 2006 пользователем SergeiK

[edwin]

> 500*1024*1024/(24*3600*400)

 

а при чем тут 400 ?

средний траффик выходит ~ 45 Мбит/с

Согласен, трафик в среднем небольшой и на вскидку 7500+RSP4 вполне разрулит да и на запас хватит,netflow там точный, но вот какие пики ...

2schnm:

сколько траффика в пике ?

[SergeiK]

400 - это среднее число байт в пакете в современных условиях.

Цифра итоговая - килопакеты/сек.

Изменено 7 ноября, 2006 пользователем SergeiK

[edwin]

> Цифра итоговая - килопакеты/сек.

 

Ну я думаю Вы согласитесь, что на сегодняшний день больше всего упирается в Mbs , а не pps, хотя разумеетмя принимать во внимание необходимо оба фактора(особенно если применяется VoIP с его вагоном маленьких пакетов).

Изменено 7 ноября, 2006 пользователем edwin

[schnm]

На данный момент - 45 мегабит канал забитый практически под завяку. расширение планируется в ближайшем времени до 100-ки.

[carrie]

К сожалению не могу понять почему бы автору не купить под такие объемы что-нибудь вроде 7206. Но раз надо linux - значит надо.

Почему имено libipq? Единственное отличие ipq от ulog - это возможность в юзерспейс (ipcad) управлять политикой, отсылая на каждый пакет ядру вердикт: "можно", "нельзя". Эта возможность libipq и дает ему относительно более худшую производительность, чем ту, которая может быть достигнута ulog'ом: нельзя буферизовать пакеты в ядре в больших объемах, отправляя в юзерспейс их "пачкой". Поэтому ваш роутер бльшую часть cpu съедает на system: переключение контекста из kernel в user space. Если в ipcad хорошо реализовано хэширование, то это время будет не просто большим, а бОльшим.

Здесь всё же придется отказаться от libipq и вынести фильтрацию пакетов, если она есть, в отдельное ПО (модуль, скрипт etc), которое будет управлять правилами iptables. (Здесь возможны варианты: посмотреть nf-hipac, если netfilter будет медленным, модули ipset для iptables, написать свой небольшой модуль ядра, заточенный под под ваши нужды).

Если решитесь попробовать ulog, то сам по себе он не быстрый, если не сделать тюнинг. В связке с ним можно попробовать fprobe-ulog (возможно ipcad тоже хорош - не пользовал его), для которого тоже нужно тщательно подбирать параметры и даже собрать может быть с другой хэш-ф-цией. Для ulog очень желательно ядро 2.6.18...Нагружаться должен будет и второй процессор, как только первый будет загружен полностью. Можно, конечно, повесить два fprobe-ulog, и половину клиентов считать на одном, половину - на другом.

pcap всерьез рассматривать, конечно, не стоит, если только не накладывать на него патчи из проекта nprobe (не пробовал).

Если еще сильней отойти в сторону, то можно посмотреть на проект nProbe. Или на новый способ учета на основе ip_conntrack, который обещает быть _очень_ производительным, но пока еще находится в beta-стадии (Harald Welte, где-то на netfilter.org, gnumonks.org).

Пару лет назад для учета больших объемов мы писали свой модуль ядра.

На машине dual operon 246 с картами e1000 intel server adapter, таблицей маршрутизации в ~180k (bgp full view), загруженным ip_conntrack получалось легко выжать 220 000 пакетов в секунду (или ~100Мбит/сек на маленьких UDP пакетах и ~4000000 уникальных flow/15мин): нагрузка была ~40%. Треть этой нагрузки приходилась на маршрутизацию (тогда в 2.6.8 не было LC-TRIE), треть на ip_conntrack.

Если учет трафика не "кушает" 100%, то можно посоветовать оптимизировать другие настройки сервера: IP-стек, правила iptables, не использовать вообще ip_conntrack (или использовать, но с -j NOTRACK), использовать ipset, nf-hipac, только сетевые карты e1000 и именно те, которые server adapter (чипов e1000 разных много и у них разные возможности). Для модуля e1000 есть куча весьма полезных настроек. Раскидать учёт по N серверам тоже не так уж и плохо: будет резервирование. И не дорого :)

 

В общем проблема решаема. Вопрос в том, хотите ли вы ей настолько серьезно заняться.

[jab]

И чего только линузятники не навыдумывают, лишь бы нормальную операционку не ставить...

[carrie]

И чего только линузятники не навыдумывают, лишь бы нормальную операционку не ставить...

Если собирать такое на PC/сервер, к сожалению, альтернатив linux для таких объемов нет. И то приходится извращаться, потому как ну несерьезно здесь использовать PC, никто таким не занимается.

А ng_netflow на FreeBSD в текущей его реализации подвержен DoS, т.к. не умеет работать с большим "разнообразием" трафика: алгоритм хэширования там очень неоптимальный и пока не может обеспечить сравнимой производительности (в тестах 40kpps - предел). Вроде бы glebus (создатель ng_netflow) уже имеет патчи на этот счет, но в 6-ку они пока еще не попали. Если они помогут - конечно, имеет смысл не извращаться, а попробовать ng_netflow. Потому что не важно какая ОС: "вам шашечки или ехать?"(с)

[schnm]

К сожалению не могу понять почему бы автору не купить под такие объемы что-нибудь вроде 7206.

Автор не покупает оборудование, автор только рекомендует, но понимания зачем тратить 10 штук баксов, если можно поставить PC менее чем за 1000 пока не было.

 

За рекомендованные варианты - спасибо. Буду пробовать растащить на первом этапе аккаунтинг и все остальное по разным машинкам, так же попробую NProbe (http://www.ntop.org/nProbe.html). Судя по тому что пишут - это просто наступившее светлое будущее в сфере учета трафика.

[jab]

И чего только линузятники не навыдумывают, лишь бы нормальную операционку не ставить...

Если собирать такое на PC/сервер, к сожалению, альтернатив linux для таких объемов нет. И то приходится извращаться, потому как ну несерьезно здесь использовать PC, никто таким не занимается.

У меня даже тот же ipcad на FreeBSD обрабатывает значительно большие объемы на более слабой тачке.

[carrie]

У меня даже тот же ipcad на FreeBSD обрабатывает значительно большие объемы на более слабой тачке.

Вполне может быть. Всё зависит от кол-ва пакетов в секунду и "разнообразия" трафика.

Не могли бы вы привести цифры интереса ради: какое у вас кол-во flow за 15 минут? pps?

А тут просто человек libipq в ipcad использовал, что и дало более низкую производительность.

 

Посмотрел исходники ipcad-3.7. В нём тоже похоже есть вероятность недосчитаться больших объемов, если я сгенеряю на него, к примеру, вот такой трафик и "просажу" тем самым сервер:

udp 213.180.204.11:80 -> 194.87.0.50:80

udp 213.180.204.11:81 -> 194.87.0.51:80

udp 213.180.204.11:82 -> 194.87.0.52:80

udp 213.180.204.11:83 -> 194.87.0.53:80

udp 213.180.204.11:84 -> 194.87.0.54:80

...

или

udp 213.180.204.11:80 -> 194.87.0.50:80

udp 213.180.204.11:81 -> 194.87.0.50:81

udp 213.180.204.11:82 -> 194.87.0.50:82

udp 213.180.204.11:83 -> 194.87.0.50:83

udp 213.180.204.11:84 -> 194.87.0.50:84

 

т.к. хэш ф-ция выглядит так:

static int

_flow_hash_value(flow_t *flow) {

int h;

 

h =

flow->src.s_addr

^ flow->dst.s_addr

^ (int)flow->ifSource

^ flow->ifInIndex

^ flow->ifOutIndex

^ flow->src_port

^ flow->dst_port

^ flow->src_mask

^ flow->dst_mask

;

 

return (h & 0x7fffffff);

}

 

Вот что говорит автор fprobe о hash-ф-циях:

fprobe-ulog use hashing to speedup flows cache searching. This option

specifies the hash type. `xor8' is very frugal with memory - it uses

only 1KB (on 32-bit systems) for hash structure while `xor16' and

`crc16' - 256KB. But, on the other hand, bigger hash gives better

performance.

Hash functions xor8 and xor16 faster then crc16, but they are vulnerable

to a DoS attack, as described in "Denial of Service via Algorithmic

Complexity Attacks" by Scott A Crosby and Dan S Wallach:

http://www.cs.rice.edu/~scrosby/hash

[jab]

У меня даже тот же ipcad на FreeBSD обрабатывает значительно большие объемы на более слабой тачке.

Вполне может быть. Всё зависит от кол-ва пакетов в секунду и "разнообразия" трафика.

Не могли бы вы привести цифры интереса ради: какое у вас кол-во flow за 15 минут? pps?

Ну вот навскидку. 500k flows, 45kpps, 140Mbps. Celeron 2.4, 80% idle.

[DemYaN]

Ну вот навскидку. 500k flows, 45kpps, 140Mbps. Celeron 2.4, 80% idle.

А можно поподробней какой чипсет,сетевые интерфейсы?

Изменено 10 ноября, 2006 пользователем DemYaN

[carrie]

Ну вот навскидку. 500k flows, 45kpps, 140Mbps. Celeron 2.4, 80% idle.

Ну что-то если честно не верится.

Попробуем, возожно, собрать тестовую платформу, проверить результаты.

[carrie]

Ну вот навскидку. 500k flows, 45kpps, 140Mbps. Celeron 2.4, 80% idle.

А можно поподробней какой чипсет,сетевые интерфейсы?

Поддержу вопрос. Хотелось бы уточнить версию ОС, включен ли polling, какой проводился тюнинг?

[jab]

:-) Ну начинается... Чипсет какой-то старый интеловский, сетевые интерфейсы старые интеловские, операционка FreeBSD 6.1, поллинг, немного тюнинга и пара волшебных слов.

[kuru]

Ну коль за язык уже потянули, расскажи про тюнинг и пару волшебных слов ;)

 

thanks

Изменено 10 ноября, 2006 пользователем kuru

[Sultan]

Хочу попробовать написать модуль Target для iptables для подсчета трафика подобно тому, как это реализовано в ng_ipacct для freebsd.

Т.е. данные собираются модулем в необходимом формате (например - timestamp, src ip, src port, src ip, dst ip, dst port, packets, bytes, in iface, out iface), и по запросу из юзерспейса формируют таблицу checkpoint и передачу данных в юзерспейс. Всвязи с вышеозначенным прошу, имевших подобный опыт, указать путь к документации и поделиться опытом. В частности, а данный момент интересует ограничение на размер выделяемой памяти для подобного модуля, механизм передачи данных по запросу в юзерспейс и какой тип хэшей оптимально использовать для этой задачи. Результатами труда поделюсь.

[vop]

механизм передачи данных по запросу в юзерспейс

procfs надо делать обязательно.