Запускаем core на одном сервере, запускаем коллектор на другом.
Смотрим tcpdump и видим что пакеты идут
а) по udp
б) только в одну сторону.
Т.е. коллектор плюет информацию по трафику на заданный порт при этом совершенно не заботясь принимает ли ее кто-то.
Проверяем предположение, тушим core и видим что пакеты продолжают идти не смортя на port unreacheble в ответ.
Зашибись...
А теперь представим что нужно сделать какое-нибудь действие из списка:
а) Обновить биллинг
б) Почисить/оптимизировать/забэкапить базу mysql
в) почистить/проапгрейдить или, наконец, просто заменить сервер на котором хранится статистика...
Что будет в этом случае? Потеря трафика? В UTM4 не было сервера с базой, некому было пускать тсейвы, как следстие трафик просто накапливался и ждал своего часа в коллекторе.
Поделитесь, кто как решает проблему?
Что будет с трафиком если остановить core?
Что будет с трафиком если остановить core?
sys. admin ISP Yauza Telecom http://www.yauza.ru
Re: Что будет с трафиком если остановить core?
Использую flow-tools.
Re: Что будет с трафиком если остановить core?
Ясно. Раскажите по-подробнее пожалуйста.Zur писал(а):Использую flow-tools.
Вот у Вас предположим get_flow берет поток с ipcad'а (к примеру), запоминает его и перенаправляет в core. Что Вы делаете если нужно потушить core на время?
sys. admin ISP Yauza Telecom http://www.yauza.ru
Как ipcad узнает о невозможности отдать статистику?Blackmore писал(а):ну допустим IPCAD складывает, при невозможности отдать стастику наружу, в файл ipcad.dump - потом ее можно забрать и обработать,
ипкад последний - ipcad-3.6.6 - так что вроде проблем нет никаких
И как потом ipcad.dump отправить в UTM5?
В UTM4 я ручками формировал traffic.tmp и запускал main (если быть честным то так сбор трафика у меня и работал, никаким tsave'ом я вообще не пользовался).
А вот есть ли такая возможностьи (импорта трафика) в UTM5?
sys. admin ISP Yauza Telecom http://www.yauza.ru
А зачем вообще ipcad'у экспортить стату куда-то? Связка ipcad+get_xyz+utm5_core. ipcad собирает стату и хранит ее у себя. get_xyz ходит, забирает стату и скидывает ее ядру. Если остановить ядро и get_xyz то никаких потерь не происходит, стата просто лежит в дампе ipcad'а, пока за ней не придет get_xyz.hmepas писал(а):Как ipcad узнает о невозможности отдать статистику?Blackmore писал(а):ну допустим IPCAD складывает, при невозможности отдать стастику наружу, в файл ipcad.dump - потом ее можно забрать и обработать,
ипкад последний - ipcad-3.6.6 - так что вроде проблем нет никаких
И как потом ipcad.dump отправить в UTM5?
В UTM4 я ручками формировал traffic.tmp и запускал main (если быть честным то так сбор трафика у меня и работал, никаким tsave'ом я вообще не пользовался).
А вот есть ли такая возможностьи (импорта трафика) в UTM5?
Понятно, получаем вариант как с tsave'ом...со всеми минусами.Digi писал(а): А зачем вообще ipcad'у экспортить стату куда-то? Связка ipcad+get_xyz+utm5_core. ipcad собирает стату и хранит ее у себя. get_xyz ходит, забирает стату и скидывает ее ядру. Если остановить ядро и get_xyz то никаких потерь не происходит, стата просто лежит в дампе ipcad'а, пока за ней не придет get_xyz.
sys. admin ISP Yauza Telecom http://www.yauza.ru
Вообще-то по Netflow ipcad отдает куда как более интересную и подробную информацию. В случае предлагаемой связки даже порты у соединений не сохраняются.Digi писал(а):например? меня данный вариант вполне устраивает, в силу того, что вероятность потери трафика минимальна даже при полном падении сервера биллинга.hmepas писал(а): Понятно, получаем вариант как с tsave'ом...со всеми минусами.
Потери трафика при данном варианте нет вообще, это да. Но мы теряем вкусности которые могли обрести с переходом на UTM5 с UTM4. Например отключение интернета при минимально отклонении от нуля (а не в момент когда полчаса уж прошло и человек успел накачать больше своей абон. платы за несколько месяцев вперед), плюс в отчете по трафику этот трафик появляется моментально. Довольно вкусные вещи чтобы прям так сразу от них отказываться.Digi писал(а):например? меня данный вариант вполне устраивает, в силу того, что вероятность потери трафика минимальна даже при полном падении сервера биллинга.
sys. admin ISP Yauza Telecom http://www.yauza.ru
Даже статья в FAQ на эту тему есть, только пустая...
http://old.netup.ru/fom-serve/cache/35.html
Т.е. Netup сами признают что проблема есть, но как ее решить еще не знают.
Я так понимаю проблема в том, что в протокол Netflow не заложена обратная связь сервер->коллектор.
Поэтому, мне видится что нужно выделить еще одну сущность -- прокси который с одной стороны будет принимать netflow от любого количества коллекторов, а с другой стороны будет по ВНУТРЕННЕМУ (не netflow) протоколу передавать все это в core и внутренний протокол уже нужно разрабатывать отказоустойчивым. Т.е. если core падает, то flow-прокси перестает посылать трафик. Тогда, если прокси поставить на одном из маршуризаторов, то независимо от того поднят ли core трафик терятся не будет если поднят маршрутизатор (при условии конечно что прокси не упадет...)
http://old.netup.ru/fom-serve/cache/35.html
Т.е. Netup сами признают что проблема есть, но как ее решить еще не знают.
Я так понимаю проблема в том, что в протокол Netflow не заложена обратная связь сервер->коллектор.
Поэтому, мне видится что нужно выделить еще одну сущность -- прокси который с одной стороны будет принимать netflow от любого количества коллекторов, а с другой стороны будет по ВНУТРЕННЕМУ (не netflow) протоколу передавать все это в core и внутренний протокол уже нужно разрабатывать отказоустойчивым. Т.е. если core падает, то flow-прокси перестает посылать трафик. Тогда, если прокси поставить на одном из маршуризаторов, то независимо от того поднят ли core трафик терятся не будет если поднят маршрутизатор (при условии конечно что прокси не упадет...)
sys. admin ISP Yauza Telecom http://www.yauza.ru
Если стоит задача забекапить netflow поток в момент недоступности core
обычно рядом с коллектором ставят отдельный сервер
и льют 2 потока, один в core другой на местный сервер.
На сервере это все скапливается.
В случае если была недоступность ядра, то трафик впоследствии можно выцепить с этого сервера, и влить в ядро.
геморно, но за функционал приходится платить...
netflow это не только инфа по портам
это еще и real time
Да и маршрутизатор (если это Cisco) меньше нагружает.
обычно рядом с коллектором ставят отдельный сервер
и льют 2 потока, один в core другой на местный сервер.
На сервере это все скапливается.
В случае если была недоступность ядра, то трафик впоследствии можно выцепить с этого сервера, и влить в ядро.
геморно, но за функционал приходится платить...
netflow это не только инфа по портам
это еще и real time
Да и маршрутизатор (если это Cisco) меньше нагружает.
Можно еще проще, поднимаем на сервере с коллектором flowtools, и льем в него, а сам flowtools уже перенаправляет в core на другом сервере, беда только в том что схема получается уж больно геморойная, придется потом по логам/отчетам выяснять когда именно чего отвалилось и делать соответствующую выборку по трафику а потом этот трафик заного перенаправлять в core. Довольно мудрено получается, не находите?DiBrain писал(а):Если стоит задача забекапить netflow поток в момент недоступности core
обычно рядом с коллектором ставят отдельный сервер
и льют 2 потока, один в core другой на местный сервер.
На сервере это все скапливается.
В случае если была недоступность ядра, то трафик впоследствии можно выцепить с этого сервера, и влить в ядро.
геморно, но за функционал приходится платить...
netflow это не только инфа по портам
это еще и real time
Да и маршрутизатор (если это Cisco) меньше нагружает.
sys. admin ISP Yauza Telecom http://www.yauza.ru