Помогите найти решение для статистики клиентов.
Есть сервер на дебиане(Intel(R) Xeon(R) CPU 3065 @ 2.33GHz) с двумя гигабитными картами через него идет поток(на данный момент 500мбит в пике) и клиенты(то есть ip) около 5000.
Нужно какимто(чудесным) образом рисовать графики по запросу на клиентов.
То есть нужно например узнать как работал ip например 10.1.1.44 в определенное время.
Все было хорошо пока поток был до 100мбит, сервер еще справлялся, собирал данные из iptable s(соответственно на каждый ip одно правило) и скармливал все rrdtool.
Но сейчас при таком потоке уже не справляется.
То есть точного количества мегабайтов скачанных не требуется а вот график показать клиенту "мол вот у вас загрузка в 10:30 была 3мбит" нужно.
В данный момент с него идет только сбор статистики первых соединений через fprobe для силовых структур(по закону хранить нужно 6 месяцев) и все. но по этим данным графики не сильно построишь.
У кого будут какие советы по данной теме?
Если свитчи умные, снимать с портов на клиента по SNMP
> Если свитчи умные, снимать с портов на клиента по SNMPэто сразу не подходит, свичи есть и умные и не очень, безпроводки много на разном оборудовании, некоторое еще 10 лет назад ставилось.
есть только одно место где трафик сходится и там нужно собрать статистику.
если кто знает железку которую докупить нужно специально для этой цели то это не проблема до 4000-5000 евро будет нормально.
Ну с таким бюджетом rrd сервак отдельный поставь.
1-2 кЕвров - и какойнить топовый i7 + винта 4 в софтрейде страйп режиме. Можно ещё 1 винт на бекап рейда.
Снимай статистику со старого, а обрабатывай в новом.
Я так понимаю, что тормозили не 5к правил файрвола, а сам rrd?
> Ну с таким бюджетом rrd сервак отдельный поставь.
> 1-2 кЕвров - и какойнить топовый i7 + винта 4 в софтрейде
> страйп режиме. Можно ещё 1 винт на бекап рейда.
> Снимай статистику со старого, а обрабатывай в новом.
> Я так понимаю, что тормозили не 5к правил файрвола, а сам rrd?если бы, как раз тормозили правила файрвола. ррд не проблема перекинуть в другое место.
> Если свитчи умные, снимать с портов на клиента по SNMPстатиску по snmp можно снимать не только с портов умного свича, но и с интерфейса того же софтогого роутера например. были бы клиенты по интерфейсам разделены (VPN, PPoE, VLAN). при реализации PPP-соединения так там вообще проще с радиуса всю информацию снимать и прочие штуки наворачивать.
PS
по iptables трафик считать - это бррр... хотя если клиенты терпят...PSS
и это же на КАЖДОГО клиента надо правило!!! убиться ап стену...PSSS
не выдержал:- поднимаешь pptpd
- поднимаешь RADIUS
- поднимаешь MySQL (например)
ВСЕ: никаких умных свичей, никаких IPTABLES, никаких демонов для кривой реализации цисковской идеи потоков и последущей мороки с разбором данных из них.
>[оверквотинг удален]
> по iptables трафик считать - это бррр... хотя если клиенты терпят...
> PSS
> и это же на КАЖДОГО клиента надо правило!!! убиться ап стену...
> PSSS
> не выдержал:
> - поднимаешь pptpd
> - поднимаешь RADIUS
> - поднимаешь MySQL (например)
> ВСЕ: никаких умных свичей, никаких IPTABLES, никаких демонов для кривой реализации цисковской
> идеи потоков и последущей мороки с разбором данных из них.интересная реакция
вы, молодой человек, наверное не много сетей в своей жизни повидали.
существует готовая сеть со сформированной годами инфраструктурой, которую обслуживали за все время разные люди.
а вы вспомните конец 90-х, и начало провайдерства, тогда никто не слышал ни о pptp ни о радиусе.
а сеть строилась и на данный момент только в ней 5000 конечных пользователей на АБСОЛЮТНО разном оборудовании. я тут повстречал еще airlan который потом циска выкупила и начала свое оборудование делать.
так что перевести такое колличество на vpn будет нереально, да и не нужно.
Ваша идея очень хороша но для начала построения сети или для перевода сотни-другой абонентов.
могу помочь в разработке подобного решения. Есть большой опыт разработки биллинговых систем.
> могу помочь в разработке подобного решения. Есть большой опыт разработки биллинговых систем.рад слышать :)
что посоветуешь?
подробного ТЗ не видел, поэтому первое приближение выглядит так:1) съём трафика через зеркалирование с порта свитча.
2)Направляем откопированный трафик на отдельную машину собирающую данные с интерфейса приёма.
3) трафик приходящий на интерфейс конвертируется в netflow(которое уже хранится сколько нужно)
4) netflow забирается скриптом парсящим его и агрегирующем трафик в нужном для дальнейшего анализа разрезе и складывающем его в БД
5) настраиваем web-морду для просмотра статистики из БДВсё это хозяйство как правило самописное и подобного не найдёшь под себя. А если и найдёшь то придётся сильно допиливать. Проще с нуля сделать с заточкой под конкретные нужды, конкретный трафик, конкретную аналитику, требованиям к хранению и скорости доступа и т.д. и т.п.
пример одной из моих работ(написано на ExtJS и Django):
http://www.youtube.com/watch?v=0ma0Z_8Gp_Q
>[оверквотинг удален]
> нужно)
> 4) netflow забирается скриптом парсящим его и агрегирующем трафик в нужном для
> дальнейшего анализа разрезе и складывающем его в БД
> 5) настраиваем web-морду для просмотра статистики из БД
> Всё это хозяйство как правило самописное и подобного не найдёшь под себя.
> А если и найдёшь то придётся сильно допиливать. Проще с нуля
> сделать с заточкой под конкретные нужды, конкретный трафик, конкретную аналитику, требованиям
> к хранению и скорости доступа и т.д. и т.п.
> пример одной из моих работ(написано на ExtJS и Django):
> http://www.youtube.com/watch?v=0ma0Z_8Gp_QНе надо велосипедить.
По пункту 3 используется softflowd, далее, инструментов для работы с netflow вагон с маленькой тележкой.
Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка будет на него.
>[оверквотинг удален]
>> А если и найдёшь то придётся сильно допиливать. Проще с нуля
>> сделать с заточкой под конкретные нужды, конкретный трафик, конкретную аналитику, требованиям
>> к хранению и скорости доступа и т.д. и т.п.
>> пример одной из моих работ(написано на ExtJS и Django):
>> http://www.youtube.com/watch?v=0ma0Z_8Gp_Q
> Не надо велосипедить.
> По пункту 3 используется softflowd, далее, инструментов для работы с netflow вагон
> с маленькой тележкой.
> Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка
> будет на него.Да, тем более если мониторить один порт - то вообще NetFlow Analyzer будет даже бесплатным =)
>[оверквотинг удален]
>>> к хранению и скорости доступа и т.д. и т.п.
>>> пример одной из моих работ(написано на ExtJS и Django):
>>> http://www.youtube.com/watch?v=0ma0Z_8Gp_Q
>> Не надо велосипедить.
>> По пункту 3 используется softflowd, далее, инструментов для работы с netflow вагон
>> с маленькой тележкой.
>> Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка
>> будет на него.
> Да, тем более если мониторить один порт - то вообще NetFlow Analyzer
> будет даже бесплатным =)спасибо за советы, сервак на i7 с рейдом заказали так что скоро буду тестить.
а как на счет готовых решений возможно платных по типу ManageEngine?
подойдут ли они под мою задачу?
свое конечно можно потихоньку собрать, но зачем изобретать велосипед
я когда то пробовал ManageEngine netflow analyzer так мне в нем что то очень не понравилось, уже что не вспомню, возможно то что нужно было все 5000 ip как клиентов вручную вводить.
> Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка
> будет на него.Меня например больше смущает, что эта софтина раз от разу (от версии к версии), считала по разному. Правда я ее давно не смотрел. Видимо если говоришь, что можно пользовать - наверное так и есть.
>> Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка
>> будет на него.
> Меня например больше смущает, что эта софтина раз от разу (от версии
> к версии), считала по разному. Правда я ее давно не смотрел.
> Видимо если говоришь, что можно пользовать - наверное так и есть.Поставил 9у версию ManageEngine netflow analyzera. ну что сказать, тула красивая, но так и не нашел рисования графиков для ip.
да и еще вот что, у меня свич поддерживает только sflow а netflow как я понял потихоньку уходит. как я уже писал что собираю в базу хедеры первых пакетов каждого соединения, так вот только их в сжатом виде в день у меня порядка 1гига то есть 6 месяцев это выходит порядка 180 гиг. так что netflow тут никак не получится, слишком уж большие потоки для него.
может кто сталкивался, возможно ли по данным sflow рисовать графики(хитрый больно алгоритм у него)?заодно прикрутил sflow сенсор на самом серваке, и направил тоже в manageengine, интересный факт, за день свич es4626-sfp отсылает примерно 40000 пакетов серверу, а линукс 12000000(поток трафика тот же). выходит точность уже сильно должна страдать под данным со свича или я чегото не понимаю?
netflow получится если написать нормальный парсер и загрузчик в БД со структурой учитывающей такие объёмы(это и называется велосипед по вашим словам...)
а по моему мнению - решение учитывающее бизнес-особенности
> netflow получится если написать нормальный парсер и загрузчик в БД со структурой
> учитывающей такие объёмы(это и называется велосипед по вашим словам...)
> а по моему мнению - решение учитывающее бизнес-особенностино нетфлова то нету на свиче как понятия. а брать его с linuxa так загнется он. это сейчас полгигабита а через год будет гигабит.
netflow со свитча то и не предполагалось собирать.Было предложено зеркалировать трафик на машину которая будет переводить его в netflow-поток(её уже можно сделать довольно мощной) более того можно зеркалировать не весь трафик - а разбить его по виланам(ряд свичтей это умеют - т.е. например 100 виланов пустить на один коллектор а другие 100 на другой - если они не выдержат - хотя это надо ещё проверять).
Теперь по поводу что netflow не переварит. Ещё как переварит - вы просто не знаете как оно работает.
Там происходит агрегация по сессиям и в итоге из 500Мбит трафика выйдет не так уж и много данных. Т.к. происходит агрегация по ip-адресам(люди в телекомах вот с гигабитов собирают и ничего - потому как требует государство хранить подробные данные для СОРМа какое-то время).
Далее уже с netflow уже может отдельный сервер парсить и делать срезы по данным как нужно.
Т.е. задачу при таком трафике можно и нужно параллелить и разносить на разные машины.
ps ради интереса - я могу чуть попозже привести данные сколько будет в трафике. Снять с реальной сети(правда не такой большой - но позволю себе экстраполировать чтобы оценить масштаб).
>[оверквотинг удален]
> не так уж и много данных. Т.к. происходит агрегация по ip-адресам(люди
> в телекомах вот с гигабитов собирают и ничего - потому как
> требует государство хранить подробные данные для СОРМа какое-то время).
> Далее уже с netflow уже может отдельный сервер парсить и делать срезы
> по данным как нужно.
> Т.е. задачу при таком трафике можно и нужно параллелить и разносить на
> разные машины.
> ps ради интереса - я могу чуть попозже привести данные сколько будет
> в трафике. Снять с реальной сети(правда не такой большой - но
> позволю себе экстраполировать чтобы оценить масштаб).отпиши в личку свой email будь добр
мои координаты:
email: sm00th1980@mail.ru
skype: sm00th1980