BiTel

Сорри, если ответ где-то на поверхности, но я не увидел
Какие требования и рекомендации по железу серверной части для версии Linux? Как рекомендуется разносить модули - достаточно ли двух серваков: ядро и БД?

Планируются модули: IPN, Phone, NPAY и ессесно Bill, Reports. Клиентов не много - юр.лица, скажем где-то около 300

Достаточно LINUX совмещенного БД и BILL сервера, 2 ГГц CPU, 1 ГБ ОЗУ (это с большим запасом). Вринципе для таких объемов железо не очень критично. Единственно отнеситесь внимательно к жестким дискам, очень желательно RAID с зеркалом т.к. при активной работе БД диски существенно изнашиваются, так чтобы полетевший один диск не привел к потере данных.

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

Оптимально поместить его на центральном узле.

Спасибо за оперативные ответы.
Можно ли как-то (среднепотолочно) оценить объем трафика между сервером биллинга и оператором?

Трафик будет примерно равен как при активном WEB серфинге

Какие требования к системе? планируется IPN=1000юзеров dialup=4000юзеров

Core Dual 2200
+ 2 Гб ОЗУ
+ SATA RAID
Должно быть достаточно..

А подскажите плиз. какой сервер понадобиться если уже предоставляется кабельное ТВ 20000 абонентов и планируется предоставлять еще и инет скажем на 6000 юзеров???

КТВ прямо скажем железо не ест почти совсем.. Ну начислите вы им абонки раз в месяц, ну даже если переначисление сделаете раз в сутки, ничего страшного. А инет какой? VPN, прямой доступ?

Прямой

С какой оперативностью обсчет нужен?

ну чем оперотивнее тем лучше. Приведите минимальные требования и наилучшие.

Ну указанные выше требования будут вполне достаточные, обсчет рекомендую раз в час, не чаще. Особенность модуля такова, что он перетарифицирует каждый раз весь месяц. Перетарификация будет до 10 минут.

Здравствуйте!

Чтобы не поднимать новую тему, пишу в этой же.

На данный момент имеется:
Абонентская база - около 10000 абонентов.
Доступ по PPTP VPN (NAS'ы на poptop, Linux)
Авторизация через RADIUS
Подсчет траффика - через RADUIS.
Около 2500 абонентов онлайн (одновременных сессий).
Тарифные планы - 85% безлимитные, остальные - с оплатой за траффик


Сейчас стоит задача выбора биллинга.
Планируемые модули: для начала DialUP/VPN, Npay
В связи с этим вопросы к разработчикам:


1. Какое железо (особенно дисковая подсистема) "без тормозов потянет" 2500 одновременных vpn-сессий (допустим, с radius-аккаунтингом при interim-update=2 мин) ?

2. Как биллинг относится к 300-500 одновременным подключениям (именно одновременные запросам на авторизацию и т.д) ?
(Например, отключили свет во всем районе, потом дали,
и все дружно ломятся в Интернет; к сожалению, у нас такое не редкость)
поэтому ответ на этот вопрос очень важен.

3. Сколько будет длиться снятие абонентской платы (через модуль npay ) с этих 10000 пользователей?
А/П желательно снимать каждый день.

4. Нужно ли при такой нагрузке разносить сервер RADIUS и Сервер биллинга+БД на разные компьютеры ?

В будующем скорее всего придется этим же биллингом обсчитывать netflow с около 100 выделенных каналов.

5. Справится ли со всем этим сервер с 4 Гб RAM, Intel Xeon X3370 и дисками SATA без RAID?
Или в обязательном порядке для повышения производительности придется организовывать какой-либо из серьезных RAID-массивов? (stripped для производительности + зеркало для отказоустойчивости...)

у нас примерно похожая ситуация, поделюсь опытом

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

1-2 минуты

я бы советовал разнести. чтобы от пиковых нагрузок на радиус не страдал сервер биллинга с основной бд.

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

огромное спасибо!



это грустно. В связи с этим появился еще вопрос. Под "полным затыком" Вы понимаете полную неработоспособность радиуса, из которого он без ручного вмешательства (то есть перезапуска ) выйти уже не может
или же все-таки он постепенно, съев часть запросов, сам приходит в себя?

Но в описании биллинга сказано, что он должен сбрасывать соединения при переходе с месяца на месяц.
В таком случае после такого сброса гарантировано около 700 одновременных попыток зайти. Кошмар с падением радиуса обеспечен?

и отделываться только тем, что на NAS-ах приделывать костыль в виде ограничения на количество SYN-пакетов на 1723 порт...

мы на бгбиле с 1го числа работаем, так что смену месяца пока еще не ощутили =) но возможно мы еще и радиус просто не отлизали до нужной степени. у нас апдейт пакеты с каждого наса шли каждую минуту, сейчас поставили реже и чтобы не одновременно с каждого. плюс активно читаем про слэйв базы и вообще про обращение к базе.

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

из правок - унесли списание абонплат на глубокое утро, когда совсем мало народа в онлайне. а то в 00:00 летом сидит еще дай бог сколько народа =)

To: Феанор
Проверьте скорость чтения с диска командой hdparm -t ..
Гораздо большие объемы тянутся без проблем.

40-45 мегабайт в секунду.

ps поправка. это было на бутовом разделе. раздел на котором находится сама база выдает 90-120 мегабайт в секунду

Там сбрасывает не сразу а постепенно. Вообще 4.6 не должен умирать никак, т.е. потихоньку авторизовывать должен все равно.. За Феаноровским будем еще наблюдать. Там вообще какое-то аномальное поведение было, радиус почему-то вообще не отвечал..