Сервер для l7 задач с потоком от 1г до 10гигабитов

[shafiev]

Добрый день/вечер коллеги.

Встала задача подборки железа для осуществления задач L7(HTTP разбор, различные виды кеширования и тд и тп) .В общем хочется следующего :

 

0. Вытягивало хотя бы 400 kpps

1. Более-меннее быстрый I/O для задач по типу кеширования youtube

2. Разбор трафика ( snort и иже с ним задачи)

 

Также посоветуйте 10 гигабитные карточки( понимаю что скорее всего будет продукцию intel ).

[s.lobanov]

нормального бесплатного/свободного софта под эти задачи нет. у вас хоть на 100M есть рабочее решение?

[snark]

Встала задача подборки железа для осуществления задач L7(HTTP разбор, различные виды кеширования и тд и тп)

Cisco SCE + PeerApp ;)

[ThreeDHead]

Cisco SCE + PeerApp ;)

Ты знал, ты знал! :)

[Hawk128]

Если есть очень много желания, то netmap.

Одна контора в России на нем написала фильтр от атак на полной 10G скорости...

[Ivan_83]

L2-L7 как то долго реализовывать заново.

[shafiev]

Если есть очень много желания, то netmap.

 

 

Именно желания много-то .

Кстати на 100 мбит в принципе любой однопоточная прога все пережевывает.

[shafiev]

L2-L7 как то долго реализовывать заново.

 

Да там сюда по всему не надо - http://info.iet.unipi.it/~luigi/netmap/#d9cd

Вы мне примерный железо для сервера подскажите.

[Ivan_83]

По ссылке выше написаны адаптеры дрова которых уже умеют нетмап.

нетмап возвращает/отправляет эзернет пакеты, это L2, он не разбирает что там внутрях,

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

[shafiev]

По ссылке выше написаны адаптеры дрова которых уже умеют нетмап.

нетмап возвращает/отправляет эзернет пакеты, это L2, он не разбирает что там внутрях,

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

 

Я тоже так думал, однако походу все написали за нас( ну по крайней мере базисные операции pcap) .

вот http://info.iet.unipi.it/~luigi/doc/20120813-netmap.tgz файл в examples pcap.c

Для удобства сам файл положил сюды http://pastie.org/5853783 .

[snark]

железо для сервера подскажите

Для нормального пропуска 10Гбит я уже указал, какое Вам надо железо.

Если хотите, чтобы Ваши 10Гбит превратились в 10Мбит и, при этом, терялось 146% трафика, а все 3 ядра Вашего гипотетического сервера были нагружены на 100% - пытайтесь собирать софтовый DPI.

 

Один из вариантов: человек, присутствующий в этом треде, уже написал под фряху фильтр торрентов - осталось договорится с ним в цене на Ваши хотелки ;)

[Ivan_83]

Я тоже так думал, однако походу все написали за нас( ну по крайней мере базисные операции pcap) . вот http://info.iet.unip...0813-netmap.tgz файл в examples pcap.c Для удобства сам файл положил сюды http://pastie.org/5853783 .

Оно разгребает пакеты (до состояния читабельности L2-L4 данных), но не выстраивает сессии и про то что внутри не знает ничего.

Самый простой вариант с HTTP - доплатить команде Сысоева чтобы они сделали transparent proxy режим.

[Ivan_83]

Один из вариантов: человек, присутствующий в этом треде, уже написал под фряху фильтр торрентов - осталось договорится с ним в цене на Ваши хотелки ;)

Не стесняйся, тыкай пальцем прямо в меня :)

Я уже писал в других топиках, и тут: разгребать L2 - L7, а тем более что там HTTP, да ещё и кеширование - то ещё занятие. HTTP не самый приятный протокол, особенно когда ты посредине.

Тут ещё вот какой нюанс: нужно собирать IP пакеты одного соединения, потом анализировать данные внутри, и на их основании принимать решение что дальше делать с пакетами...

Короче, писать и отлаживать - трудно. Под большие нагрузки - тоже трудно.

[sexst]

Я бы еще осмелился заметить что протоколы на месте не стоят и придется постоянно держать людей для отслеживания изменений и правки сигнатур. И большой вопрос что в итоге будет дороже - готовое решение или свое.

[ThreeDHead]

А какой смысл в этом вообще? Хороший серв, стоит чуть меньше б/у SCE, которую "настроил и забыл", успевай только обновлять.

[snark]

Не стесняйся, тыкай пальцем прямо в меня :)

В следующий раз (чувствую это будет уже скоро) - сразу перейду на личности и пошлю к кому надо ;)

 

 

какой смысл в этом вообще?

Тебя то тут как раз и не хватало ;) Может у тебя получится донести до ТС мысль о том, что аналог связки SCE+ PeerApp может и получится сделать, но цена, скорее всего, будет выше железок?

 

 

Хороший серв, стоит чуть меньше б/у SCE

Сервак, который через себя просто пропустит 10Гбит/с стоит меньше SCE, но ...

задача подборки железа для осуществления задач L7(HTTP разбор, различные виды кеширования и тд и тп)

Но сервак, который через себя пропустит те же 10Гбит/с с анализом, кешированием "и т.д. и т.п."(с) да еще и с хорошей производительностью ... "нет, сынок, это фантастика"(с) IMHO

 

 

P.S. Как культурно написать "природу не на***ь", чтобы это не потерли?

[ThreeDHead]

snark поддерживаю.

 

От себя добавлю - на днях развернули 8 гигабит на нетфлоу-коллектор. Там 2xE5620, интеловские многоочередные карты, Ubuntu, пересобранное ядро для прозрачного ipt_NETFLOW.

Так вот, 7 гиг еще прожевывал, а вот на 8-ми уже уперся всеми ядрами в 100% и начал терять сознание.

Хотя тут речь даже не о пропускной способности, а вообще о том - чем-же L7 обрабатывать, открытого мало, а то что есть - жалкие поделки. И второе - зачем? Торренты резать?

Edited January 26, 2013 by ThreeDHead

[Ivan_83]

Резать то не сложно.

Даже в TCP влезть и нарыть торрент или нет там ходит, и дальше добавить в таблицу соединений (типа коннтрака) с пометкой: пропускать/блочить/ещё анализировать не оч сложно.

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

Касательно сигнатур, хотя бы торрентовских, то если вместо анализа пакетов анализировать исходники и документацию, то вероятность после очередного обновления клиента перестать узнавать трафик - минимальна. Авторы там не настолько упороты чтобы ломать совместимость со старыми клиентами, они просто играются с некоторыми константами в пределах существующего протокола и существующих ограничений обратной совместимости, но при анализе пакетов это понять не возможно.

 

PS: у вендоров закрытое оно ещё и потому что под капотом там своих ужасных тараканов хватает, и многие вендоры не брезгуют чужим кодом.

[telecom]

snark поддерживаю.

 

От себя добавлю - на днях развернули 8 гигабит на нетфлоу-коллектор. Там 2xE5620, интеловские многоочередные карты, Ubuntu, пересобранное ядро для прозрачного ipt_NETFLOW.

Так вот, 7 гиг еще прожевывал, а вот на 8-ми уже уперся всеми ядрами в 100% и начал терять сознание.

Хотя тут речь даже не о пропускной способности, а вообще о том - чем-же L7 обрабатывать, открытого мало, а то что есть - жалкие поделки. И второе - зачем? Торренты резать?

Думаю, один 5675 был бы гораздо лучше...

[ThreeDHead]

Даже в TCP влезть и нарыть торрент или нет там ходит, и дальше добавить в таблицу соединений (типа коннтрака) с пометкой: пропускать/блочить/ещё анализировать не оч сложно.

Я сомневаюсь что даже с тупо включенным _ядерным_ коннтраком, система вытянет 10 гигабит/с.

 

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

Модуль для iptables/ebtables. Не?

 

Думаю, один 5675 был бы гораздо лучше...

Я не могу сказать лучше было бы или хуже, надо собирать стенд и проводить тесты и замеры. У меня есть подозрение что мы просто уперлись в пропускную полосу транка, при этом пошли потери трафика, и совокупность этого - свернула мозг принимающей системе.

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

[Ivan_83]

Модуль для iptables/ebtables. Не?

Я не пишу под ядро линуха. Максимум мои юзер спейс программы под линухом работают чуть хуже, чем под фрёй.

 

Я сомневаюсь что даже с тупо включенным _ядерным_ коннтраком, система вытянет 10 гигабит/с.

Не знаю как там линуксовый коннтрак устроен, но тот конттрак который я реализовал у себя в ноде имеет ограничение связанное пакетрейтом для одной сессии, либо, если сильно не повезёт, то там всплывёт случай когда две разные тяжёлые сессии имеют один хэш. Пока не жаловались: размер хеша 16 байт, оч малое время блокировки и скорее всего не пропускают столько трафика чтобы под коллизию попадал.

[shafiev]

Даже в TCP влезть и нарыть торрент или нет там ходит, и дальше добавить в таблицу соединений (типа коннтрака) с пометкой: пропускать/блочить/ещё анализировать не оч сложно.

Я сомневаюсь что даже с тупо включенным _ядерным_ коннтраком, система вытянет 10 гигабит/с.

 

 

 

Коллеги, я собираюсь использовать фреймворк netmap или же pf_ring . C их слов , http://info.iet.unip.../dummynet/#8696 на далеко не топовом железе тут получили под 6 мегапакетов в секунду ( правда там тест сильно синтетический) ,

Прошу мне подсказать именно по железки .

Edited April 19, 2013 by shafiev

[Bigmazy]

Даже в TCP влезть и нарыть торрент или нет там ходит, и дальше добавить в таблицу соединений (типа коннтрака) с пометкой: пропускать/блочить/ещё анализировать не оч сложно.

Я сомневаюсь что даже с тупо включенным _ядерным_ коннтраком, система вытянет 10 гигабит/с.

 

 

 

Коллеги, я собераюсь использовать фреймворк netmap и или же pf_ring . C их слов , http://info.iet.unip.../dummynet/#8696 на далеко не топовом железе тут получили под 6 мегапакетов в секунду ( правда там тест сильно синтетический) ,

Прошу мне подсказать именно железки .

 

В правильном направлении идёте.

[photon]

Netmap/pf_ring - это реализации прямого доступа к памяти ядра для userland-программ. На маршрутизацию, классификацию трафика и NAT, которые и так реализованы в ядре, использование netmap не окажет никакого влияния. Может пригодиться разве что для каких-то netflow- или tcpdump-сенсоров, систем обнаружения вторжений и прокси-серверов. Впрочем, и сбор Netflow уже реализован на уровне ядра (ng_netflow/ipt_netflow), поэтому netmap провайдеру, не занимающемуся фильтрацией контента, вообще говоря не нужен.

Edited April 20, 2013 by photon

[shafiev]

Netmap/pf_ring - это реализации прямого доступа к памяти ядра для userland-программ. На маршрутизацию, классификацию трафика и NAT, которые и так реализованы в ядре, использование netmap не окажет никакого влияния. Может пригодиться разве что для каких-то netflow- или tcpdump-сенсоров, систем обнаружения вторжений и прокси-серверов. Впрочем, и сбор Netflow уже реализован на уровне ядра (ng_netflow/ipt_netflow), поэтому netmap провайдеру, не занимающемуся фильтрацией контента, вообще говоря не нужен.

 

Ok. Это все понятно.