Вынос обработки детальки на отдельный сервер
Вынос обработки детальки на отдельный сервер
Кто-нибудь выносил на отдельный сервер сбор и обработку детальной статистики? Если да, то как реализовывали? Думаю, не одни мы столкнулись с проблемами после 4гбит/с при обработке нетфлоу и необходимости при этом хранить детальную статистику 3 года.
Это понятно, что вторым dst на серверах доступа для нетфлоу указывать другой сервер. Собирать и обрабатывать дальше чем - вот в чём вопрос)) Мы вообще оставили для физиков с серверов доступа только аккаунтинг. Нетфлоу для 10к+ клиентов с >4гбитами утму просто крышу срывает.xxxupg писал(а):просто отсылать 2ую копию нетфлоу на другую машину с NAS'a =)
Сделайте программку, которая раскладывает по account_id файлики с деталькой и затем пакует их (весьма желательно xz -9, но годится и bzip2 -9). Прикрутите ее как /netup/utm5/bin/raw_fd_script.
Жмется такая деталька до 12% от исходного объема. У меня получается около 10 сжатых файлов в сутки (примерно гигабайт). Несжатой получается соответственно раз в семь-восемь побольше. Каналы - 45, 2 и 6 мегабит (53).
Такая раскладка сделает возможным быстрое получение отчетов по заданному account_id, что чаще всего и требуется. Я написал программку, которая умеет работать со сжатой деталькой (.utm.bz2) и формировать из нее отчеты. А вот raw_fd_script пока только сжимает детальку и отсылает в хранилище по scp.
Диски нужно ставить исходя из формулы 365*3*(суточный объем сжатой детальки). Это минимальное значение. Желательно побольше, потому что абоненты за эти три года увеличатся числом. Как вариант - распределенное хранилище, самое простое - исходя из account_id рассылать на две и более машины, по ftp, scp или еще как-то.
У меня под это дело выделен терабайтный жесткий диск. Идея записи на болванки оставлена давно. Это самоубийство.
Я буду делать раскладку по account_id сейчас. Потому что недавний детальный отчет за месяц очень уж медленно формировался. Два часа почти.
Если данный вариант вам интересен - можете стукнуть в аську, переговорим.
Жмется такая деталька до 12% от исходного объема. У меня получается около 10 сжатых файлов в сутки (примерно гигабайт). Несжатой получается соответственно раз в семь-восемь побольше. Каналы - 45, 2 и 6 мегабит (53).
Такая раскладка сделает возможным быстрое получение отчетов по заданному account_id, что чаще всего и требуется. Я написал программку, которая умеет работать со сжатой деталькой (.utm.bz2) и формировать из нее отчеты. А вот raw_fd_script пока только сжимает детальку и отсылает в хранилище по scp.
Диски нужно ставить исходя из формулы 365*3*(суточный объем сжатой детальки). Это минимальное значение. Желательно побольше, потому что абоненты за эти три года увеличатся числом. Как вариант - распределенное хранилище, самое простое - исходя из account_id рассылать на две и более машины, по ftp, scp или еще как-то.
У меня под это дело выделен терабайтный жесткий диск. Идея записи на болванки оставлена давно. Это самоубийство.
Я буду делать раскладку по account_id сейчас. Потому что недавний детальный отчет за месяц очень уж медленно формировался. Два часа почти.
Если данный вариант вам интересен - можете стукнуть в аську, переговорим.
Сейчас нетфлоу собирается ядром, деталька пишется на рамдрайв, перепаковывается и пишется на внешний диск. Хочется под обработку детальки выделить отдельный сервер, сняв задачу с ядра, поскольку ему всё равно кранты при текущей загрузке. Понятно, что экспортить нетфлоу дополнительно на другой хост, там его обрабатывать. Смотрим в сторону nfdump. Часть нетфлоу придётся оставить на ядре, но нагрузка существенно ниже будет. Как хранение детальки в ядре выключить тоже понятно. Вот и интересовали схемы, кто такое у себя уже реализовал. Вроде саксесс стори))JAO писал(а):Тогда просьба разъяснить задачу.
"Сбор"
Я расписал про сбор.
"Обработка"
Какая именно? Формирование статического набора отчетов в HTML, фильтрация, агрегация или что-то еще?