Стабильная работа Stargazer в крупных сетях с широким каналом

[Vi$0R 0]

Волнует такой вопрос,- справится ли Stargazer с постоянным ростом абонентской базы и шириной каналов, тарифными планами 10, 20 и более Мб на абонента. Есть ли реальные примеры стабильной работы этого биллинга с онлайном в 1000 человек с общим каналом 500 Мбит и выше и дальнейшем внедрении высокоскоростных тарифов. Практика показывает нестабильную работу под большими нагрузками. Может стоит сразу смотреть в сторону других разработок, тогда подскажите каких?

[nightfly 1 239]

1000 человек с общим каналом 500 Мбит

это у вас "крупная сеть"?

 

Есть-есть.

 

Вобще не вижу взаимосвязи ширины канала и скорости работы биллинга который выступает именно в роли биллинга. Рост абонбазы ~200-300/мес тоже не предел.

[madf 279]

Волнует такой вопрос,- справится ли Stargazer с постоянным ростом абонентской базы и шириной каналов, тарифными планами 10, 20 и более Мб на абонента. Есть ли реальные примеры стабильной работы этого биллинга с онлайном в 1000 человек с общим каналом 500 Мбит и выше и дальнейшем внедрении высокоскоростных тарифов. Практика показывает нестабильную работу под большими нагрузками. Может стоит сразу смотреть в сторону других разработок, тогда подскажите каких?

Расскажите поподробнее про эту практику.

У меня на работе по 2000-2500 онлайн пользователей на каждом из 3 серверов. Один из каналов на следующей неделе расширяем до 10 Гбит. Биллинги стоят как вкопанные с зимы. Никаких проблем.

[nallien 3]

+1 на биллинг, как бы, ни скорость каналов, ни нагрузка....

[Vi$0R 0]

Расскажите поподробнее про эту практику.

У меня на работе по 2000-2500 онлайн пользователей на каждом из 3 серверов. Один из каналов на следующей неделе расширяем до 10 Гбит. Биллинги стоят как вкопанные с зимы. Никаких проблем.

Да, в том-то и дело, что только недавно приобрели новое серверное железо, а стабильности добиться не получается. Вроде бы только отточили, - добавили 200Мбит канала и как правило к вечеру ложится сервак. Если смотреть на графики, то получается, что при достижении пика происходит сбой. Может проблема в службе рассылки сообщений? Изначально мы ей так и не пользуемся, так как при отправке сообщений пользователям нагрузка возрастает и сервер загибается. Это было и на старом железе, а сейчас и на новом.

Подскажите, в какую сторону копать? Кто на каком железе работает? Были ли у кого-то проблемы с рассылкой сообщений?

Кто занимается профессиональной установкой и настройкой биллинга stargazer с гарантией, для плодотворного сотрудничества!

[nightfly 1 239]

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

Омг.

 

Вам не на графики смотреть нужно а нормального админа найти. Если у вас возникает впечатление что цитирую "добавили 200Мбит канала" и "Может проблема в службе рассылки сообщений?" как-то между собой корелируют - не советую вникать в вопрос дальше.

 

1. statgazer - именно биллинг

2. посылалка сообщений (читай нормальный(!) тикетинг) - либо пишется с пол пинка либо находится готовая без проблем.

3. сдается мне что у вас проблема совсем не в биллинге а в изначальной архитектуре сети (распределении нагрузки по насам, резделении коллектинга и сенсоров трафика итд итп)

 

Если не используете mod_radius, ai и прочую черную магию - свистите, думаю что нить придумаем

[madf 279]

Расскажите поподробнее про эту практику.

У меня на работе по 2000-2500 онлайн пользователей на каждом из 3 серверов. Один из каналов на следующей неделе расширяем до 10 Гбит. Биллинги стоят как вкопанные с зимы. Никаких проблем.

Да, в том-то и дело, что только недавно приобрели новое серверное железо, а стабильности добиться не получается. Вроде бы только отточили, - добавили 200Мбит канала и как правило к вечеру ложится сервак. Если смотреть на графики, то получается, что при достижении пика происходит сбой. Может проблема в службе рассылки сообщений? Изначально мы ей так и не пользуемся, так как при отправке сообщений пользователям нагрузка возрастает и сервер загибается. Это было и на старом железе, а сейчас и на новом.

Подскажите, в какую сторону копать? Кто на каком железе работает? Были ли у кого-то проблемы с рассылкой сообщений?

Кто занимается профессиональной установкой и настройкой биллинга stargazer с гарантией, для плодотворного сотрудничества!

Что за сбой? Какие проблемы с рассылкой сообщений? Как реализован сбор трафика? Какая версия Stargazer установлена? Что используется в качестве хранилища данных?

[Vi$0R 0]

Может проблема в службе рассылки сообщений?" как-то между собой корелируют

Из-за чего попытался связать это, так как в случае падения приходит сообщение всем пользователям:

"Incorrect request DISCONN_SYN"

А объяснить корректно причину я не могу, так как сам не являюсь администратором этого сервера и особого доступа не имею.

Поэтому, вопрос остается открытым,-Кто занимается профессиональной установкой и настройкой биллинга stargazer с гарантией, для плодотворного сотрудничества?

[keshaLG 5]

Имеем опыт внедрения stg-2.407-rc1 под СentOS 5 в production с хранением в базе postgresql + самописная статистика к ней,

пометровка ip_query,

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

Пугает только кол-во записей в базе дет.трафа юзеров с торрентами))

Вопрос только в хорошем железе под это дело.

stg модульный, значит можно масштабировать под ваши задачи.

Я сделал все сервисы виртуальными машинами под xen-ом - милое дело! Рекомендую.

 

На счет посотрудничать - стучитесь в личку, я с удовольсвием поделюсь своим опытом.

 

ps виртуалка с биллингом:

[root@stg data]# uptime
22:45:17 up 148 days,  5:16,  1 user,  load average: 0.12, 0.09, 0.03

[nightfly 1 239]

принципиально не считаю в них траф, а надо бы, но это просто ipcad прикрутить я так понял.

в чем проблема сенсоров софтовых наставить типа тогоже softflowd?

[keshaLG 5]

да в принципе ничего, только целесообразность сего дела.

По данным уважаемого Madf

... 96 Гб - таблица детальной статистики...

т.е. "слонячих" размеров оно достигает, может кому-то и надо, а мне - нет.

Разве что раз в год для милиции, когда кто-то нашухарит.

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

Можно конечно оптимизировать (снимать статистику реже, и т.д.), а надо ли?

[Небесный 26]

А, кто мешает чистить базу? Оставлять например Детальной статистики всего за 3 месяца, если не ошибаюсь именно столько и нужно по закону.

В установочном пакете есть даже скрипт, который чистит Детальную статистику, правда только для файловой БД, но что мешает склепать скрипт и для СУБД. Запускаем его по крону раз в месяц и все.

У меня не так много пользователей всего 280 чел, но База не превышает 1-3 Гб, в зависимости от активности хомячков в течении месяца.

 

А, не писать статистику мне кажется - это даже глупо.

[nightfly 1 239]

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

Как в вашем сознании корелирует считание трафика и писание по сессиям детальной статистики?

 

cap_nf практически пофиг с точки зрения быстродействие - молотить гигабит или два с последующим писанием только каунтеров. Доказано практикой. Не считать трафик вообще как таковой с практической точки зрения как-то не целесообразно в даный момент.

[keshaLG 5]

Смысл в том, а зачем на безлимитах считать трафик? (тут я оговорюсь: дет.статистика + сумма вообщем)

Мне хватало, что СТГ пишет просто сессии пользователя.

Насколько я понимаю на сбор статистики должен же некий ресурс тратиться процессорного времени.

Может я чего-то не понимаю, конечно, просветите пожалуйста.

Есть стг - в нем пометровка (ip_query) и рядом через ВПН безлимиты,

на сервере ВПН я должен настроить сенсор netflow (ipcad), что бы он слал в стг статистику - так?

Или чем суммарные каунтеры собираются?

Коллектором netflow же выступает сам стг ? или еще чего-то надо?

[nightfly 1 239]

Смысл в том, а зачем на безлимитах считать трафик?

Банально для того чтобы знать что пользователь работает, фильтровать качков с торентами 24/7/31, крутить динамические шейпера на лету... много для чего.

 

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

 

Насколько я понимаю на сбор статистики должен же некий ресурс тратиться процессорного времени.

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

 

На данном этапе флов с ~гигабита порождает не более чем

 

10:06PM up 326 days, 9:20, 1 user, load averages: 0.56, 0.46, 0.43

на биллинговом сервере

 

А сказки о "ой ресурсоемко" или "ой рудиментарно" порождаются вот такими вещами как

Есть стг - в нем пометровка (ip_query)

или

Коллектором netflow же выступает сам стг ? или еще чего-то надо?

[keshaLG 5]

+1 Ваши применение очень интересны,

согласен со всем выше сказанным, прошу прощения за "демагогию", действительно я обладаю "недоделаной" рабочей системой

и рассуждал теоретически,

Ваша статистика думаю интересна не только мне, если можно, пожалуйста, поподробнее опишите её (железо, кол.туннелей, pps, софт и тд), а то la - мало информативно.

но я имел ввиду объёмы детальной статистики при полном логировании всех соединений, а это N-миллионов строк в таблице как писалось выше (это я точно увидел на своей системе).

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

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

там идет разработка accel-pptpd работающего на kernel-level, очень интересный проект.

[nightfly 1 239]

(железо, кол.туннелей, pps, софт и тд)

Железо дешевое, билинг + бд естественно отдельно(ла оттуда как вы поняли), выносные NASы на rscriptd + freebsd, тунелей нет, vlan per user, option 82, средний nas - 120-150kpps, сетевухи недорогие - класса HP NC364T или из ихних родственников. Детальная статистика действительно имеет глубинный смысл только для тарифов с предоплаченным трафиком, для остальных естественно она отключена по дефолту.

 

N-миллионов строк в таблице как писалось выше

ну да - есть такое

 

В любом случае этот вопрос уползает в область оптимизации БД, периодичного клинапа и вдумчивого кеширования.

 

В любом случае отказыватся от счетчиков вообще не практично. К чему я и веду.

[keshaLG 5]

thanks, Респект за vlan per user и option 82.

В свое время не доделал сенсор, как надо. А потом, как обычно, нет ничего постояннее временного.)

В моем случаи, достаточно поставить и настроить ipcad или как Вы предложили softflowd, как я понял.

С ipcad имел дело, когда крутил ноудени - понравилось простотой.

[madf 279]

Если все пойдет нормально, сегодня запущу тестовый сервер с полной нагрузкой одного из наших районов. Это примерно 2500 онлайнеров (в пике за сутки) из 6000 пользователей. Сейчас в базе (PostgreSQL 8.4) лежат данные за последний месяц преобразованные из файловой (в т.ч. детальная статистика, логи сессий и логи изменений параметров, для чего писались отдельные утилиты). Сейчас все это добро вместе с индексами (но без журналов транзакций, которые вынесены на отдельный винт) весит всего 87 Гб. Индексы, правда, еще не все, но основные. Лежит все это добро на четырех терабайтных винтах объединенных в RAID10 объемом в 2 Тб. Для таблицы детальной статистики выполнено партицирование по месяцам. Сбор детальной статистики для безлимитчиков (которых порядка 30%) отключен, но для теста собираюсь включить.

 

Нагрузка Stargazer'а на процессор при подсчете нормального трафика на обычном железе (C2D) не превышает 40% в пике. Я недавно внес некоторые изменения в траффкаунтер которые позволят еще сбить нагрузку и нормально справляться с ненормальным трафиком.

 

Вообще этот сервер собирался для оптимизации работы с БД чтобы в скором будущем плавно и безпроблемно полностью перейти на PostgreSQL, но я на нем и Stargazer запущу для проверки возможности обслуживания всех районов одним сервером.

 

По результатам наблюдений, возможно, напишу небольшую статью по настройке и тюнингу связки Stargazer + PostgreSQL. В любом случае о результатах расскажу.

 

Если кому нужны утилиты для конвертации детальной статистики и логов - милости прошу в Jabber. Если будут популярны - выложу исходники в публичный доступ. Собственно, парсер детальной статистики на Boost.Spirit2 я уже опубликовал.

[keshaLG 5]

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

там идет разработка accel-pptpd работающего на kernel-level, очень интересный проект.

применил данный софт - результаты впечатлительные: производительность VPN-сервера увеличилась в разы (3..10).

Рекомендую

[inlocal 1]

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

там идет разработка accel-pptpd работающего на kernel-level, очень интересный проект.

применил данный софт - результаты впечатлительные: производительность VPN-сервера увеличилась в разы (3..10).

Рекомендую

А причем stargazer ?