Обзор биллинговой системы BGBilling
Предыстория
Примерно полтора года назад столкнулись с проблемой, заключающейся в том, что наша биллинговая система (кем-то и когда-то написанная, поддерживаемая местной контрой, в которой автора уже не было) ну никак уже не справлялась с возложенными на нее задачами.
Заказывать разработку новой системы под свои задачи — слишком дорого и слишком долго. Поэтому встала задача — найти подходящее решение. Выбор в итоге пал на BGBilling. В итоге вот уже год как мы работаем с этой системы и в целом всем довольны. Почему мы выбрали именно систему и чем она хороша (минусы тоже постараюсь осветить) постараюсь подробно изложить ниже.
Введение
Итак, для кого в первую очередь предназначен пост? Для людей, подобно мне полтора года назад, озадаченных руководством, находящихся в поиске подходящего решения и ищущих описания различных систем, чтобы начать тестирование (да, есть замечательный ресур наг.ру, но лично мне он не импонирует, слишком уже хаотично все, поэтому хабру я верю больше). Так же думаю будет интересно тем, кто переживает/пережил бурный рост/выход на новую нишу и ощущает необходимость апгрейда/переезда на новую платформу.
О системе
Система — российская. Сайт — bgbilling.ru
Как я понял, система писалась для сети УфаНет, и потом выросла в отдельный продукт. Разработка идет где-то с 2003 года. Текущая версия 5.0 (у нас стоит 4.6, отличий от текущей — практически никаких, новая версия была вызвана окончанием действия сертификата), в разработке находится версия 5.1, в которой разработчики обещают много нового, но про нее пока я ничего сказать не могу.
Архитектура системы — серверная часть написана на Java. Первое время беспокоила производительность и стабильность такой системы. По прошествии года могу сказать — с производительностью и стабильностью нет никаких проблем. Но есть одно НО. Сервер требует последнюю Java, а с ней есть определенные проблемы на FreeBSD. Поэтому этой системы нет в списке поддерживаемых. Но зато есть — Windows, Linux. Конкретно у нас стоит на Fedora 10. Mac как поддерживаемая платформа не заявляется, но в целом мне ничто не помешало запустить сервер и клиент у себя на ноутбуке. СУБД — MySQL.
Документированность БД — изумительная. Идем на сайт dbinfo.bitel.ru и шаримся, смотрим что и как с чем связано, какие параметры могут быть. Честно признаюсь, для меня документированность БД была одним из решающих факторов. Было ясно, что функционал специфичный только для нас придется допиливать самому, поэтому такое подспорье как адекватная документация, меня как радовали, так все больше и радуют.
Клиент для оператора биллинга — отдельное GUI приложение.
Что следует отметить — в клиенте есть встроенные sql редактор, который из самого клиента позволяет выполнять зарпосы к бд и получать результаты в удобоваримом виде.
Стоимость, лицензии и прочее
Система — модульная. Каждый модуль имеет количество лицензий с которыми он может работать (или бесконечное количество). Чем больше лицензий — тем дороже модуль. Максимальная цена — за бесконечное количество лицензий.
Какие модули стоит выделить — модуль списания абонентский плат, модуль diap up, модуль ipn, voiceip. Рассчитать стоимость лицензии можно на сайте — bgbilling.ru/price_count.shtml
Какие модули кому нужны будут? Без модуля абонентских плат — никуда. Берем его, максмальная цена за бесконечное количество лицензий (бесконечное начинается с 10000 лицензий) —
100тр.
А теперь смотрим чем мы занимаемся? Оператору КТВ по сути больше ничего не нужно. Провайдеру еще бы и модуль работы с сетью. Это или IPN или DialUP — и тот и другой максимально стоят тоже порядка 100тр.
Модуль телефонии — один из самых дорогих. Порядка 240тр.
Остальные модули — voiceip, модуль цифрового телевидения — по-моему не так популярны, их рассматривать не будем. Если интересно — можно посчитать на сайте.
Техподдержка, комьюнити
Спорный вопрос по техподдержке. Она платная. При покупке лицензии предлагается заключить контракт на техподдержку и приобрести пакет обращений. За 25тр можно получить 50 обращений на год. За 9тр — 15 обращений, тоже на год. Много это или мало? Мы использовали за год — 5 обращений. Сообщения об ошибках за обращения не засчитываются, но для их сообщения все равно нужен пакет хоть с одним обращением.
Бесплатная поддержка оказывается разработчиками на форуме, но в негарантированные сроки. Если через личный кабинет ответ будет дан в среднем через пару часов, то через форум придется подождать день-два. Но зато на форуме очень много таких же пользователей как и вы, которые подчас подсказывают и помогают оперативней.
Что и приводит нас к вопросу о комьюнити и вики-базе. Сообщество мне очень понравилось. На форуме можно найти помощи практически по любому вопросу. В последнее время и ко мне в аську начали с вопросами обращаться, с радостью подсказываю, если знаю что и как.
Производительность и факапы
Официальные данные представлены на соответствующей странице сайта — bgbilling.ru/program/speed.shtml. В целом им можно верить. АП списываются довольно шустро. Радиус(мы используем модуль DiapUP для доступа к сети) держит нагрузку при одновременной авторизации 1000-1500пользователей (пропадаение света в районе, а потом включение) вполне нормально. Радиус же занимается обсчетом нетфлоу статистики. Справляется с потоком от 6 цисок с гигабитом трафика на каждой.
Если не считать факапов вызванных своими кривыми руками, то был один довольно неприятный факап 1 января 2010 года. На каждый месяц автоматически создаются новые таблицы с балансом. Из-за какой то недоработки в логике в 2010 году новые таблицы не создались. Поэтому в момент списания АП у всех был 0 на счету. Благо БД очень хорошо документирована и есть функции групповых операций — это удалось очень быстро устранить (до того как большая часть абонентов отошла от похмелья и полезла в интернет).
Запуск, перенос существующих баз
Настройка и запуск системы осуществляются довольно просто, особо выделить даже нечего. Распаковать архив, добавить исполняемые .sh в автозапуск, загрузить структуру таблицы из файла дампа и пожалуй все — уже будет работать =).
Инетересный момент. Основные компоненты системы — сервер, радиус, шедулер — можно разнести на разные сервера, в настройках указать айпишники и все отлично будет работать, цепляться к серверу и распределять нагрузку.
Кстати про распределение нагрузки. Все задачи сваливаются в очередь, которую обрабатывает шедулер. Причем он практически никак не связан с сервером. Т.е. задача на выгрузку статистики, переобсчет трафика — нагрузит шедулер, но никак не скажется на производительности самого сервера биллинга — он будет работать в нормальном режиме, складывая задачи в очередь, будет давать доступ до бд радиусу и других модулям.
Заключение, сравнение с другими системами
В целом биллингом я доволен. Сейчас дописываю свой интерфейс (опять радуюсь документированности бд — написать нужные запросы к бд очень легко)
Сравнить с другими системами особо возможностей и не было. По отзывам тех кто переезжает с UTM — небо и земля — документированность и открытость бд, возможность дописать свои скрипты, реализовать собственную бизнес логику.
PS если появились какие-то вопросы — задавайте, постараюсь ответить.
Источник
Развертывание биллинга для небольшой сети с нуля
Предыстория:
Некие хорошие люди решили начинать провайдерский бизнес. Растянули и разварили оптику в небольшом районе, поставили ящички, засунули туда минимальные свичи, с помощью которых можно организовать VLAN-Per-User, закупили небольшой, для начала, канал у ближайшего магистрала. Встал у них вопрос о том, чем же считать пользователям трафик/денежки и нарезать скоростя.
Общая схема сети должна выглядеть следующим образом:
Кому интересно, далее под катом очень много букв и картинок.
Условности:
— Шлюз аплинка будет 1.2.3.3
— Сетевые адаптеры NAS смотрящие на аплинка будут в сети 1.2.3.3/24
— Сеть, предоставляемая пользователям, будет 172.16.0.0/18, или, если угодно, 255.255.192.0
— IP адреса 172.16.0.0-172.16.0.10 мы резервируем для серверов доступа и прочих собственных нужд
— Сервер пользовательской статистики будет доступен по адресу stat.isp и, учитывая бюджетность решения, будет находиться на одном хосте с биллинговым сервером, хотя хорошим тоном является не только разделять биллинг и трафик абонентов, но и разносить на раздельные хосты БД, ядро биллинга и веб-интерфейс.
Изначальные потребности были четко оговорены:
— Проектная емкость сети — до 10000 абонентов
— Раздача IP абонентам при помощи DHCP
— Авторизация либо по связке IP+MAC
— Несколько полностью безлимитных тарифов
— Трафик все же считать нужно для контроля
— Очень желательно видеть активность каждого отдельного пользователя
— Разделение прав касиров/бухгалтеров/менеджеров/администраторов
— Возможность масштабирования решения относительно роста количества абонентов
— Так как своей АС еще нету и в наличии имеются три с половиной айпишки, выданных аплинком, первых пользователей предполагается NAT-ить.
— Естественно все это максимально бюджетно 🙂
Беглое изучение ассортимента opensource биллинговых систем показало, что оптимальным в данной ситуации может оказаться Stargazer по следующим причинам:
— Проект открыт, активно развивается, новые версии выходят с завидным постоянством.
— Не страдает врожденной монстроидальностью и позволяет допиливать функционал не привязываясь к внутренней механике
— Ядро написано на C/C++ и категорически быстрое
— Большой выбор методов подсчета трафика
— На выбор поддержка хранения данных в Файлах/MySQL/Firebird/PostgreSQL
— Волшебный механизм исполнения команд на удаленных серверах
Установка будет проходить на голую FreeBSD 8.2-RELEASE, установленную в варианте kern-developer + порты. Весь трафик пользователей будем рулить через удаленный NAS на все
той же FreeBSD 8.2, производя по нему NAT/Shape/NetFlow и отрисовку графиков загрузки абонентского канала при помощи bandwidthd. В роли вебинтерфейса для stargazer 2.407-p1 у нас будет выступать последний на момент написания топика Ubilling 0.1.7, хотя выбор фронтендов у Stargazer довольно широк — от Win-конфигуратора до нескольких консольных и XML-RPC API.
Далее прямой копипаст из консоли с периодическими заострениями внимания на концептуальных моментах.
Итак приступим к настройке биллингового сервера.
1. Морально готовимся
2. Установка зависимостей
Для простоты isc-dhcp собираем без DHCP_PARANOIA
php5 должен быть собран как минимум с поддержкой CLI и модулем Apache (последний должен нормально подтянуться зависимостью)
Собираем жизненно необходимые расширения PHP, а именно: ставим галочки на MYSQL, MBSTRING и ICONV
3. Собираем сам stargazer и его консольные конфигураторы в две строчки 🙂
4. Разворачиваем текущую версию Ubilling
5. Делаем особую симлинковую магию
6. Запускаем Apache и MySQL
7. Устанавливаем новый пароль пользователя root для mysql (newpassword — для примера)
#mysqladmin -u root password newpassword
8. Приводим /etc/stargazer/stargazer.conf к следующему виду
9. Редактируем конфиг /etc/stargazer/rules оставля аж одно нужное нам направление, а именно интернеты.
10. Добавляем наш первый NAS в /etc/stargazer/remote_nas.conf
10. запускаем/останавливаем stargazer
11. Убеждаемся, что умолчальная БД развернулась
12. Редактируем /usr/local/etc/sudoers, добавляя туда пользователя, под которым будет работать Web интерфейс
13. Разворачиваем дамп Ubilling
14. Убеждаемся, что все хорошо
15. Редактируем файл config/billing.ini, доводя его до кондиции:
16. Разворачиваем заготовки стартовых скриптов
17. И делаем прибивание IP+MAC в скрипте /etc/stargazer/OnConnect
18. Редактируем конфиг /etc/stargazer/config, прописывая в него текущие параметры MySQL
19. Аналогично редактируем конфиг config/mysql.ini
20. Запускаем stargazer и меняем пароль администратора по умолчанию
21. приводим наш /etc/rc.conf к виду
22. Добавляем служебную зону «.isp» в /etc/namedb/named.conf
и в /etc/namedb/master/isp
23. Создаем стартовый скрипт запуска stargazer в /etc/rc.d/billing
и назначаем ему нужные права
24. Прописываем нужные виртуалхосты в /usr/local/etc/apache/httpd.conf
25. Правим глобальный шаблон по которому будут генерироваться конфиги dhcp, он находиться вот здесь: /usr/local/www/data/billing/config/dhcp/global.template
26. Выставляем нужный уровень логирования для dhcpd в /etc/syslog.conf
27. Можем сделать профилактический ребут чтобы посмотреть как все подымается, либо поперезапускать все, что мы уже понастраивали вручную.
28. А теперь самое интересное ради чего все затевалось 🙂
Заходим на наш servername.isp/billing и логинимся с логином и паролем по умолчанию admin/demo (не забываем сразу же сменить) и видим следующую картину:
Добавляем нужный нам класс трафика:
Добавляем сеть и сервис (напоминаю, что мы резервируем первых 10 IP под свои нужды)
Добавляем сети обработчик DHCP
и применяем к нему свой шаблон подсети
намекая таким образом, что шлюз по умолчанию должен быть в сторону нашего NAS сервера.
Проверяем, удачно ли создается конфиг dhcpd.conf в справочнике «Сети»
Добавляем свой первый тариф, пусть он будет зваться Unlim-1 и будет безлимиткой с абонплатой 50 денег в месяц
Навешиваем на него симметричную скорость в 1 мегабит/с
Добавляем наш сервер доступа который мы будем настраивать чуть пожже
В справочниках Городов, Улиц и домов добавляем наш населенный пункт, улицы и дома где будут жить абоненты
Ну и вроде все, регистрируем нашего первого абонента
Назначаем ему MAC, тариф, вписываем Ф.И.О. и все что нужно в «редактировании», и, в общем-то, он должен работать.
Настройка NAS сервера.
Опять же, имеем Голую FreeBSD 8.2, от которой хотим, чтобы она выступала шлюзом по умолчанию для наших пользователей.
Нужные модуля можно и просто подгрузить, но это дело привычки, так что соберем ядро руками с попутным выкидыванием всего что нам не нужно.
Заменяем в конфиге нашего нового ядра ident GENERIC на NAS1
И собираем/ставим его в одну строчку:
Следим за тем, чтобы наш /etc/rc.conf имел где-то такой вид:
Устанавлиеваем thttpd, которым будем показывать графички
Отличный сенсор NetFlow
И умеренно врущий, но идеально простой в настройке bandwidthd для отрисовки per-user графиков
PHP собираем с поддержкой CLI
И модуль MYSQL к нему
Приводим наш /etc/firewall.conf к виду:
Выставляем правильные права на наш скрипт инициализации фаервола
Собираем rscriptd и обеспечиваем его запуск при ребуте
редактируем /etc/rc.d/rscriptd, приводя его к виду
и назначаем ему правильные права
Разворачиваем заготовки скриптов Ubilling
Редактируем конфиг /etc/rscriptd/config, прописывая в него текущие параметры MySQL для того, чтобы скрипты GetSpeed, GetUpSpeed, GetMAC могли нормально получать информацию о пользователях.
Также, не забываем поправить /etc/rscriptd/OnConnect, указав в нем входной интерфейс для шейпинга, который в нашем случае
Настраиваем bandwidthd для того, чтобы он рисовал красивые графики, которые мы потом должны лицезреть в Ubilling:
В файл /usr/local/bandwidthd/etc/bandwidthd.conf вписываем сеть наших пользователей
добавляем периодический SIGHUP для bandwidthd в crontab -e
И опять страшная симлинковая магия, чтобы наш thttpd мог нормально показывать графички
Обеспечиваем при загрузке запуск
И как последний штрих, добавляем более-менее универсальные вещи, помогущие хоть как-то поднять быстродействие в дальнейшем в /etc/sysctl.conf
После перезагрузки получаем работающий NAS, получающий удаленно команды от биллинга, отправляющий ему сведения о трафике и все остальное, что от него требовалось.
Хотелось бы еще написать о настройке кабинета пользователя, недокументированых «фичах» с переходом на следующий месяц и прочих вещах, на которых можно споткнуться в первое время. Но статья и так уже получилась слишком монстроидальной и нудной. Обещаюсь, если карма позволит, на недельке описать все эти вещи в отдельном сказании.
Источник
