Перейти к содержимому
Калькуляторы

deep_admin

Активный участник
  • Публикации

    237
  • Зарегистрирован

  • Посещение

Все публикации пользователя deep_admin


  1. Очень сомневаюсь, видите ли, freebsd очень плохо живет не на x86
  2. Очень верной дорогой идете товарищ. Хотя вот в голову пришла еще одна идея о процессе тарификации по каждому пользователю отдельно. То есть предположим что юзера конектяться по пппое, тогда при коннекте говорим биллингу - нас считать, и тогда запускается процесс вылавливающий из временной таблицы неагреггированного нетфлоу только свои данные ну и тд. Плюсы: в один момент времени тарифицируем только подключенных юзеров, диапазон просмотра временных таблиц нетфлоу можем задавать разный для каждого юзера, тарификация происходит параллельно Минусы: для тысячи он-лайн пользователей например нужно ооочень много оперативной памяти
  3. На openwrt.org есть огромный набор мануалов и how-to. Все делал по ним. Web-морда там есть, но она не функциональна абсолютно.
  4. На самом деле 5 портов (4 лан и 1-ван), каждый порт можно сделать как отдельный интерфейс, так и включить в бридж с любым другим портом. Так как чип понимает 802.1q vlan, то кол-во интефейсов практически не ограничено. Есть реально работающие линксисы с 3-4 виланами, пппое-сервер с авторизацией в радиусе (радиус есс-но на писюке) и с ipcad'ом для сбора статистики.
  5. Да собсно точно также как и в любом другом линуксе: route add -net 192.168.x.y netmask 255.255.255.0 gw a.b.c.d Мне не понравился dd-wrt впервую очередь своей веб-мордой, скрипты которой очень ограничивают реальные его возможности.
  6. Как насчет нескольких сотен терабайт в месяц ? :-) терабайты разные бывают. если это терабайты с серваков с фильмами - это одно, а если это терабайты с игровых это другое. либо одна ТСП-сессия на 700мб либо семь миллионов :) какая разница сколько терабайт? да хоть миллион, ведь на веб выводится уже просуммированная статистика за месяц, а подробно/посессионно есс-но ручками. Чем чаще снимаются данные с коллекторов, тем меньше надо ресурсов для их тарификации, достаточно умно организовать очередь из временных таблиц (если например трафик за минуту неуспеваем за следующую минуту посчитать), тем более что предварительную аггрегацию делает сам netflow, вот например в том же ipcad'е: netflow timeout active 30; # Timeout when flow is active, in minutes netflow timeout inactive 15; # Flow inactivity timeout, in seconds Более того когда у вас 7 миллионов TCP-сессий :) можно поставить N-тачек которые будут делать предбиллинг, а потом уже это сливать на сервер тарификации, к тому же еще на этапе предбиллинга можно отлавливать флуды, сканы и тд
  7. Все отлично живет в mysql для несокльких терабайт трафика в месяц и при заборе как нетфлоу так и ip-accounting на нескольких тысячах юзеров. Просто используйте много временных таблиц, главное чтоб процессы записи и выборки из таблиц не пересекались по времени. Трафик с коллекторов можно ложить сразу в БД с частотой даже раз в минуту, там же аггрегировать и любому полю, раз в час/сутки/месяц можно суммировать. При правильных индексах все будет очень быстро выбираться. Кстати очень рекомендую максимально разнести задачи биллинга на модули, например модуль аггрегации трафика не должен проводить операции с деньгами, ну и тд. Кстати обязательно используйте транзакционный тип таблиц innodb, очень удобно при большом кол-ве операций с базой, если какой-то шаг прошел неуспешно - все можно будет откатить.
  8. Используем давно и много Linksys WRT54 разных версий (G, GS, GL). Крайне приятные железки вкупе с прошивкой openwrt. Может роутить трафик по езернета до 60Мбит/с и примерно 5 килопакетов. За $85 за штуку - считаю что просто подарок