BiTel

Вынашивается проект к 5.2 версии взамен IPN/DialUp модулей выдать единый модуль учёта трафика, объединив в нём возможности обоих модулей.
Встроить систему учёта ресурсов. И оборудования. Сделать более гибкой систему управления шлюзами.
В аттаче - намётка ТЗ. Если у кого-то есть вопросы/пожелания и т.п. - прошу писать.

Какие плюсы:
1) Возможности реалтайм тарификации, динамической выдачи адресов для любого вида доступа.
2) Детализация и переобработка логов без костыльной настройки планировщиков (сейчас переобработка логов в DialUp если неверно были определены категории трафика сделано через подсовывание логов планировщику). Детализацию модулю DialUp делает IPN, т.к. DialUp не хранит первичные логи.
3) RADIUS Accounting - один из видов первичных данных о трафике, возможность переобработки и его логов.
4) Хранение запросов RADIUS на диске в бинарном виде, разгрузка БД.

Немного скриншотов...

Главные задачи:

конвергентный обсчет,
возможность работы нескольких аккаунтинг серверов одновременно,
возможность разделения аккаунтинг серверов на непересекающиеся группы,
быстрый перезапуск аккаунтинг сервера,
логический разрыв сессий при смене месяца и других событиях,
установка услуги в тарифе по аналогии с модулем phone (например, для деления включенного и превышения)
уход от набора атрибутов к более абстрагированному типу,
отдельный сервер, отвечающий за выдачу ресурсов (ip, vlan, порты коммутаторов прямого доступа)

тут все ipn-щики воспряли духом


о да! ДА! ДА!!!

основные вопросы которые возникли: получается у нас будет два-в-одном, т.е. dialup + ipn ... объясните, пожалуйста, на пальцах - т.к. у меня везде чистейший, не замутненный, dialup, то что мне даст "новый ipn", кроме понятных вещей в духе переобработки RADIUS Accounting? что даст "новый dialup" у кого ipn? а то из ТЗ как то не очень понятно это все
самый скользкий вопрос - как быть с лицензиями?

бител сцуко РУЛИТ!!!111 простите, не сдержался ... в очередной раз убеждаюсь в правильности выбора биллинга

С точки зрения dialup - это более быстрый перезапуск аккаунтинг(радиус) сервера, возможность запускать несколько серверов, как резерв, и для распределения нагрузки.
С точки зрения ipn - уход от задач планировщика, т.е. конвергентный обсчет и работа со шлюзами по событиям.
Общее - установка услуги в тарифе (как в модуле телефонии, т.е. в тариф входит не услуга, как раньше, а тип трафика, по которому в тарифе можно будет установить услугу), также в планах более простой редактор в договоре, зависящий от выбранного типа устройства (шлюза).

Смутно пока понятно все.

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

пока не решено, но скорее всего просто будет обмен лицензий по формуле: diaup + ipn = inet (новый модуль)

А потом цена будет дороже - этого модуля?? и остануться ли модули ipn и dialup ? мне то это всеравно (у меня и те и те модули работают), но думаю народ заинтересуется

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

_________________
интеграция биллинга с 1с http://bgbilling-1c.ru/

Обмен будет. Т.е. если есть хотя бы один безлимит - будет безлимит inet. Т.к. складывание безлимита с чем угодно даст безлимит.
Для новых пользователей планку безлимита может повысим, но для тех кто купил - так и останется.
Подумайте над функционалом.

Даст абстракцию от типа получения доступа в сеть. Т.е. единые тарифы, реалтайм там и там.
Можно дать вперемешку доступ через туннели и фиксированный. Единую квоту, например, выделить в тарифе.
Учётные периоды там и там, максимальные трафики и превалирующий трафик там и там.
Несколько схем привязок услуг там и там.
Более простую настройку получения детализации, т.к. не надо будет в конфиге NASов прописывать сообветствие источников IPN NASам.

Сейчас повсеместно начинается переход на управляемые сети с схемой VLAN на юзера, при этом зачастую требуется динамическая выдача адреса.

Нам проще будет единый модуль в перспективе сопровождать.
А то вот появляется учёт ресурсов IP адресов в IPN - просят в DialUp и т.п. Это портирование занимает много сил, удваиваются практически трудозатраты и время.

Ещё интересно - а как там будут настройки наса выглядеть ?? как там будут происходить разрывы??

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

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

Да
Можно подробней? Для чего и как, например...

Тарификация по времени превышения определенного порога скорости востребована клиентами, имеющими профиль трафика с пиками, многократно превышающими среднюю загрузку. Пример: некая фирма потребляет интернет как для "общеофисных" нужд и для некоего бизнес-процесса.
Для удовлетворения общеофисных нужд достаточно анлима шириной 1 мегабит/с. Бизнес-процесс требует несколько раз в неделю скачивать большой объем данных за короткое время, удовлетворительными являются, например, порядка 50мегабит/с в течении часа.
Для такого клиента является оптимальным тариф, отдельно учитывающий длительность всплесков 50 мегабит/с. Для формирования такого тарифа биллинг должен понимать не только "байты через интерфейс", но и "скорость через интерфейс". Либо уметь тарифицировать по времени некие "состояния" - например: час состояния "пиковая загрузка" стоит 1000р, состояние длилось 30 минут, начислить 500р.


В данный момент можно самостоятельно решить вопрос с тарификацией по времени превышения определенного порога скорости или длительности любого другого "состояния": самостоятельно детектировать такие состояния и конвертировать их длительность в байты трафика на определенные адреса.
Но самостоятельная обработка нетфлоу, да еще и в реальном времени, да еще и совместимая с БГБ, видится не совсем тривиальной вещью для большинства клиентов БГБ. Поэтому удачная система плагинов IPN, позволяющая реализовать пре- и пост- обработку нетфлоу и snmp счетчиков дала бы возможность получить нужные нам тарифы (например, по пикам) без непосредственной реализации их силами разработчиков БГБ.

даете анлим в 1 мегабит, а когда людям надо - они заходят активируют тарифную опцию на 50 мегабит ... как Вы ее посчитаете - по нулям или по цене > 0 - это уже Ваше личное дело

Я во подумал: а как будет происходить миграция со старой схемы на новую? Кстати, тогда лицензии нужно не обменивать, а давать бесплатно, если уже есть Ipn и/или dialup - со старой схемы сразу не слезешь.

Я что-то никак вас не могу развернуть ход ваших мыслей от коммерческой составляющей.
Если мы перейдём на единый модуль трафик, то в перспективе dialup/ipn умрут совсем. Новым клиентам продавать не будем, для старых оставим поддержку, но без внесения фич. Оставить лицензию - тоже не проблема.

Ясно, спасибо.

NAS в текущем его понимании разделится на 2 понятия: шлюз и источник.
В свойствах шлюза будет прописано, какой источник ему соответствует. Соотношение шлюз - источник в общем случае один-ко-многим.
В качестве шлюза NAS (например MPD) генерирует RADIUS Auth запросы, отсылая их на AccessServer. Там поднимается сессия (фиксируется факт аренды ресурсом на источнике абонентом), информация по JMS передаётся на ProcessServer.

ProcessServer ловит: RADIUS Accounting (Start/Stop/Update), NetFlow, сохраняет на диск и сопоставляет трафик ресурсам выделенным с привязкой к нему как статически (просто фиксированные адреса) так и динамически (RADIUS, DHCP). Помимо этого ProcessServer ведёт тарификацию в реальном времени сессий абонентов. При этом ему постоянно нужно взаимодействовать с другими ProcessServer ами других источников, т.к. договор может одновременно потреблять услуги на нескольких источниках, это необходимо учитывать в тарифах. Обмен по JMS.

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

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

RADIUS запросы в бинарном виде хотим хранить на диске, при необходимости просмотра в мониторе запросов и ответов по сессии - по JMS запрашивать соответствующий AccessServer.

Выкрутиться можно разными способами.

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

Я бы со своей стороны предложил сделать некий внутренний язык запросов для ТП, с помощью которого было бы возможно создавать нестандартные тарифные планы. Как это может выглядеть, мне трудновато представить, но например - добавляется специальный узел "Запрос", в котором админ биллинга пишет SQL (а может и BGBilling Script?), возвращающий нужное значение или группу значений...
В частности мой 1-й случай - для модуля IPN мне необходимо снимать наработку не только по превалирующему объему трафика, но и по наибольшой сумме за потребленный трафик. Чтобы была понятна "нестандартность" данного решения, объясняю суть ТП:
модуль IPN (предполагается новая версия модуля, в которой реализован горячий обсчет трафика и временные периоды деления (льготный, основной) за отчетные сутки), в ТП предусмотрены льготный период по одной цене и основной период по другой (большей) цене. Кроме того, при каждом обсчете трафика в течение суток, определяется превалирующий трафик (и тарифицируется, чтобы клиент не ушел в большой минус). Вообщем функционал DialUp за одним исключением - на границе суток определяется превалирующий трафик, потребленный за сутки, не взирая на льготный/основной периоды. При этом у клиента появляется возможность искуственно сгенерировать исходящий трафик в льготный период времени скажем на 1Гб, а в основной период потребить входящего на 999Мб и фактически заплатить за него по льготной цене. Чтобы клиент не мог обмануть провайдера, для таких случаев введен функционал списания денег не за наибольший объем трафика, а за наибольшую стоимость трафика, то есть в данном примере клиент заплатит за меньший по объему трафик, однако по стоимости он будет дороже.
Мой 2-й случай: для модуля Phone необходимо кроме повременной платы за потребленные минуты (секунды), взымать плату за соединение. Т.е. стоимость за минуты + фиксированная стоимость за звонок (опять-таки при условии, что сам звонок длился не менее N секунд).

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

Кастомный узел в ТП - это интересно. Можно реализовать вызовом метода какого-нибудь java-класса, который пишет клиент по заданной абстракции.
Но тут важно соблюсти одно условие - функция должна быть детерминированной. Т.е. на одних и тех же входных данных (включая все данные договора) должна возвращать одинаковые значения. Чтобы при каждом пересчете за один и тот же период получалась одна и та же сумма.

боюсь это может послужить плохую шутку . народ дорвётся до самых своих сокровенных фантазий , и переобсчет просто ляжет и не будет никакого real-time .
Аналогично и про филтры netflow . Если дать кому-то sql запрос писать по каждому событию получения цепочки netflow, то все точно ляжет .

Сейчас кто-то может все положить в любом синхронном обработчике события.

А вот фильтр на входе в нетфлоу-коллектор (ну или на выходе в сброс на диск) позволил бы нам не хранить на винтах кучу мусорного флоу.

ну, если это событие вызывается раз в год , то это не так страшно, как 100 раз в секунду

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

собирать netflow только с/на нужные сети не выход?

Вообще тарифные узлы и сейчас просто реализуют какой-то интерфейс. Вернее их два: клиентский редактор и серверный обработчик.
Вот только реализовать _любую_ логику даже с такими мега-узлами не получится.
Например, возьмём тот самый пример с превалирующим трафиком. Обработчик вычисляет лидирующий на текущий момент трафик, определяет его приращение после чего запрашивает цену в тарифе. Если этого функционала не будет, то тарификатор запросит цену входящего и цену исходящего. Какие манипуляции надо при этом провернуть, чтобы провести указанную тарификацию?
Это весь тарификатор нужно подменять, а не один узел.
По телефонии впринципе такой узел сделать можно. Для 5.1 по крайней мере, там в запросе идёт длительность звонка а в ответе - цена.