The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Статистика на сервере для 500Мбит канала."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Учет трафика, статистика / Linux)
Изначальное сообщение [ Отслеживать ]

"Статистика на сервере для 500Мбит канала."  +/
Сообщение от maxxch (ok) on 11-Апр-11, 15:06 
Помогите найти решение для статистики клиентов.
Есть сервер на дебиане(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 месяцев) и все. но по этим данным графики не сильно построишь.
У кого будут какие советы по данной теме?
Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от vvvua (ok) on 11-Апр-11, 15:31 
Если свитчи умные, снимать с портов на клиента по SNMP


Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от maxxch (ok) on 11-Апр-11, 15:38 
> Если свитчи умные, снимать с портов на клиента по SNMP

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от vvvua (ok) on 11-Апр-11, 16:51 
Ну с таким бюджетом rrd сервак отдельный поставь.
1-2 кЕвров - и какойнить топовый i7 + винта 4 в софтрейде страйп режиме. Можно ещё 1 винт на бекап рейда.
Снимай статистику со старого, а обрабатывай в новом.
Я так понимаю, что тормозили не 5к правил файрвола, а сам rrd?


Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от maxxch (ok) on 11-Апр-11, 16:58 
> Ну с таким бюджетом rrd сервак отдельный поставь.
> 1-2 кЕвров - и какойнить топовый i7 + винта 4 в софтрейде
> страйп режиме. Можно ещё 1 винт на бекап рейда.
> Снимай статистику со старого, а обрабатывай в новом.
> Я так понимаю, что тормозили не 5к правил файрвола, а сам rrd?

если бы, как раз тормозили правила файрвола. ррд не проблема перекинуть в другое место.


Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

11. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от LSTemp (ok) on 14-Апр-11, 17:20 
> Если свитчи умные, снимать с портов на клиента по SNMP

статиску по snmp можно снимать не только с портов умного свича, но и с интерфейса того же софтогого роутера например. были бы клиенты по интерфейсам разделены (VPN, PPoE, VLAN). при реализации PPP-соединения так там вообще проще с радиуса всю информацию снимать и прочие штуки наворачивать.

PS
по iptables трафик считать  - это бррр... хотя если клиенты терпят...

PSS
и это же на КАЖДОГО клиента надо правило!!! убиться ап стену...

PSSS
не выдержал:

- поднимаешь pptpd
- поднимаешь RADIUS
- поднимаешь MySQL (например)
ВСЕ: никаких умных свичей, никаких IPTABLES, никаких демонов для кривой реализации цисковской идеи потоков и последущей мороки с разбором данных из них.


Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

15. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от maxxch (ok) on 14-Апр-11, 22:15 
>[оверквотинг удален]
> по iptables трафик считать  - это бррр... хотя если клиенты терпят...
> PSS
> и это же на КАЖДОГО клиента надо правило!!! убиться ап стену...
> PSSS
> не выдержал:
> - поднимаешь pptpd
> - поднимаешь RADIUS
> - поднимаешь MySQL (например)
> ВСЕ: никаких умных свичей, никаких IPTABLES, никаких демонов для кривой реализации цисковской
> идеи потоков и последущей мороки с разбором данных из них.

интересная реакция
вы, молодой человек, наверное не много сетей в своей жизни повидали.
существует готовая сеть со сформированной годами инфраструктурой, которую обслуживали за все время разные люди.
а вы вспомните конец 90-х, и начало провайдерства, тогда никто не слышал ни о pptp ни о радиусе.
а сеть строилась и на данный момент только в ней 5000 конечных пользователей на АБСОЛЮТНО разном оборудовании. я тут повстречал еще airlan который потом циска выкупила и начала свое оборудование делать.
так что перевести такое колличество на vpn будет нереально, да и не нужно.
Ваша идея очень хороша но для начала построения сети или для перевода сотни-другой абонентов.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

5. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от sm00th1980 (ok) on 11-Апр-11, 18:29 
могу помочь в разработке подобного решения. Есть большой опыт разработки биллинговых систем.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от maxxch (ok) on 11-Апр-11, 18:38 
> могу помочь в разработке подобного решения. Есть большой опыт разработки биллинговых систем.

рад слышать :)
что посоветуешь?


Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от sm00th1980 (ok) on 11-Апр-11, 19:05 
подробного ТЗ не видел, поэтому первое приближение выглядит так:

1) съём трафика через зеркалирование с порта свитча.
2)Направляем откопированный трафик на отдельную машину собирающую данные с интерфейса приёма.
3) трафик приходящий на интерфейс конвертируется в netflow(которое уже хранится сколько нужно)
4) netflow забирается скриптом парсящим его и агрегирующем трафик в нужном для дальнейшего анализа разрезе и складывающем его в БД
5) настраиваем web-морду для просмотра статистики из БД

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

пример одной из моих работ(написано на ExtJS и Django):
http://www.youtube.com/watch?v=0ma0Z_8Gp_Q

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от axe (??) on 11-Апр-11, 20:41 
>[оверквотинг удален]
> нужно)
> 4) netflow забирается скриптом парсящим его и агрегирующем трафик в нужном для
> дальнейшего анализа разрезе и складывающем его в БД
> 5) настраиваем web-морду для просмотра статистики из БД
> Всё это хозяйство как правило самописное и подобного не найдёшь под себя.
> А если и найдёшь то придётся сильно допиливать. Проще с нуля
> сделать с заточкой под конкретные нужды, конкретный трафик, конкретную аналитику, требованиям
> к хранению и скорости доступа и т.д. и т.п.
> пример одной из моих работ(написано на ExtJS и Django):
> http://www.youtube.com/watch?v=0ma0Z_8Gp_Q

Не надо велосипедить.
По пункту 3 используется softflowd, далее, инструментов для работы с netflow вагон с маленькой тележкой.
Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка будет на него.


Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от rusadmin (ok) on 12-Апр-11, 07:15 
>[оверквотинг удален]
>> А если и найдёшь то придётся сильно допиливать. Проще с нуля
>> сделать с заточкой под конкретные нужды, конкретный трафик, конкретную аналитику, требованиям
>> к хранению и скорости доступа и т.д. и т.п.
>> пример одной из моих работ(написано на ExtJS и Django):
>> http://www.youtube.com/watch?v=0ma0Z_8Gp_Q
> Не надо велосипедить.
> По пункту 3 используется softflowd, далее, инструментов для работы с netflow вагон
> с маленькой тележкой.
> Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка
> будет на него.

Да, тем более если мониторить один порт - то вообще NetFlow Analyzer будет даже бесплатным =)

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от maxxch (ok) on 12-Апр-11, 11:17 
>[оверквотинг удален]
>>> к хранению и скорости доступа и т.д. и т.п.
>>> пример одной из моих работ(написано на ExtJS и Django):
>>> http://www.youtube.com/watch?v=0ma0Z_8Gp_Q
>> Не надо велосипедить.
>> По пункту 3 используется softflowd, далее, инструментов для работы с netflow вагон
>> с маленькой тележкой.
>> Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка
>> будет на него.
> Да, тем более если мониторить один порт - то вообще NetFlow Analyzer
> будет даже бесплатным =)

спасибо за советы, сервак на i7 с рейдом заказали так что скоро буду тестить.
а как на счет готовых решений возможно платных по типу ManageEngine?
подойдут ли они под мою задачу?
свое конечно можно потихоньку собрать, но зачем изобретать велосипед
я когда то пробовал ManageEngine netflow analyzer так мне в нем что то очень не понравилось, уже что не вспомню, возможно то что нужно было все 5000 ip как клиентов вручную вводить.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

12. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от LSTemp (ok) on 14-Апр-11, 17:30 
> Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка
> будет на него.

Меня например больше смущает, что эта софтина раз от разу (от версии к версии), считала по разному. Правда я ее давно не смотрел. Видимо если говоришь, что можно пользовать - наверное так и есть.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от maxxch (ok) on 14-Апр-11, 20:12 
>> Меня только смущает зеркалирование полгигабита в коре, не слишком ли большая нагрузка
>> будет на него.
> Меня например больше смущает, что эта софтина раз от разу (от версии
> к версии), считала по разному. Правда я ее давно не смотрел.
> Видимо если говоришь, что можно пользовать - наверное так и есть.

Поставил 9у версию ManageEngine netflow analyzera. ну что сказать, тула красивая, но так и не нашел рисования графиков для ip.
да и еще вот что, у меня свич поддерживает только sflow а netflow как я понял потихоньку уходит. как я уже писал что собираю в базу хедеры первых пакетов каждого соединения, так вот только их в сжатом виде в день у меня порядка 1гига то есть 6 месяцев это выходит порядка 180 гиг. так что netflow тут никак не получится, слишком уж большие потоки для него.
может кто сталкивался, возможно ли по данным sflow рисовать графики(хитрый больно алгоритм у него)?

заодно прикрутил sflow сенсор на самом серваке, и направил тоже в manageengine, интересный факт, за день свич es4626-sfp отсылает примерно 40000 пакетов серверу, а линукс 12000000(поток трафика тот же). выходит точность уже сильно должна страдать под данным со свича или я чегото не понимаю?

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от sm00th1980 (ok) on 14-Апр-11, 21:01 
netflow получится если написать нормальный парсер и загрузчик в БД со структурой учитывающей такие объёмы(это и называется велосипед по вашим словам...)
а по моему мнению - решение учитывающее бизнес-особенности
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

16. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от maxxch (ok) on 15-Апр-11, 10:31 
> netflow получится если написать нормальный парсер и загрузчик в БД со структурой
> учитывающей такие объёмы(это и называется велосипед по вашим словам...)
> а по моему мнению - решение учитывающее бизнес-особенности

но нетфлова то нету на свиче как понятия. а брать его с linuxa так загнется он. это сейчас полгигабита а через год будет гигабит.


Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от sm00th1980 (ok) on 15-Апр-11, 13:12 
netflow со свитча то и не предполагалось собирать.

Было предложено зеркалировать трафик на машину которая будет переводить его в netflow-поток(её уже можно сделать довольно мощной) более того можно зеркалировать не весь трафик - а разбить его по виланам(ряд свичтей это умеют - т.е. например 100 виланов пустить на один коллектор а другие 100 на другой - если они не выдержат - хотя это надо ещё проверять).

Теперь по поводу что netflow не переварит. Ещё как переварит - вы просто не знаете как оно работает.

Там происходит агрегация по сессиям и в итоге из 500Мбит трафика выйдет не так уж и много данных. Т.к. происходит агрегация по ip-адресам(люди в телекомах вот с гигабитов собирают и ничего - потому как требует государство хранить подробные данные для СОРМа какое-то время).

Далее уже с netflow уже может отдельный сервер парсить и делать срезы по данным как нужно.

Т.е. задачу при таком трафике можно и нужно параллелить и разносить на разные машины.

ps ради интереса - я могу чуть попозже привести данные сколько будет в трафике. Снять с реальной сети(правда не такой большой - но позволю себе экстраполировать чтобы оценить масштаб).

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от maxxch (ok) on 15-Апр-11, 14:39 
>[оверквотинг удален]
> не так уж и много данных. Т.к. происходит агрегация по ip-адресам(люди
> в телекомах вот с гигабитов собирают и ничего - потому как
> требует государство хранить подробные данные для СОРМа какое-то время).
> Далее уже с netflow уже может отдельный сервер парсить и делать срезы
> по данным как нужно.
> Т.е. задачу при таком трафике можно и нужно параллелить и разносить на
> разные машины.
> ps ради интереса - я могу чуть попозже привести данные сколько будет
> в трафике. Снять с реальной сети(правда не такой большой - но
> позволю себе экстраполировать чтобы оценить масштаб).

отпиши в личку свой email будь добр

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Статистика на сервере для 500Мбит канала."  +/
Сообщение от sm00th1980 (ok) on 15-Апр-11, 15:20 
мои координаты:
email: sm00th1980@mail.ru
skype: sm00th1980
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру