Комментарии 4
А Найфаем или Пентахой не вариант было импортозаместить?
Раз комментариев мало, то я могу получить ответы на несколько вопросов:
Вы знаете, что кроме CDR-записей существуют IDR-записи? Если да, то почему о них ничего не сказали (методы сбора, формат, обработка, нюансы операторов)?
Основные пользователи системы предбиллинга это не инженеры сети: в крупных компаниях есть отдельные подразделения, в мелких эту функцию делают биллингисты.
"Быстрый запуск" - это с учетом миграции легаси-схем? или сначала мигрируют старые схемы, а потом запускают вашу платформу в течении 2х дней. Как вы оцениваете время запуска?
После перехода к обработке упорядоченных форматов (ASN.1(видимо)Ber, BinaryOffset, CSV) столкнулись ли вы с нюансами того же ASN (заголовки, padding byte и т.д.)? Вы решали их в процессе написания кода или уже знали решение (на основании спеки, документации и т.д.)?
Модель акторов - это внутренний протокол работы системы или это внутриБД сущность? каким образом конвейер обработки взаимодействует?
Суть вашей системы - это application server с запущенной JAVA? Можно ли эту систему распределить на VM?
Существует ли у этой системы возможность работы одновременно в разных ЦОДах? Active-Active, например.
В каком виде хранится конфигурация настроенной системы? Есть ли варианты бэкапа, чтобы сократить время ее приведения до актуального состояния?
1. Цель данной статьи — рассказать в целом о разработке новой платформы Nexign Mediation, о возможностях ее использования в разных сферах, об общих принципах настройки и поддержки, не акцентируя внимания на обработке определенных типов данных.
Упомянутый в статье CDR — это только частный случай из телекома, так как он, на данный момент, ближе всего к компании. Но в целом платформа может собирать и обрабатывать любые данные внутри поддерживаемых форматов, назовем их xDR.
Кроме всего прочего, Nexign Mediation собирает и обрабатывает данные по NetFlow.
Что касается IDR — то это записи регистрации абонентских данных, которые приходят в запросе по DIAMETER с оборудования. Для этого у нас есть другой продукт, который занимается онлайн-сбором данных по DIAMETER, в этой статье мы его не упоминаем.
2. Платформа Nexign Mediation спроектирована в "открытом" виде, биллингистам не составит труда быстро научиться с ней работать: отслеживать её состояние, модифицировать сценарии и добавлять новые, поддерживать НСИ и расписание запусков сценариев, проводить аналитику по отчетам о принятых данных, работать с ошибками, делать сверку и т.д. Все действия разграничены разными правами и фиксируются аудитом.
К тому же, в помощь для настройки, мы поставляем набор из тестовых сценариев с примерами настройки разных парсеров и обработки в целом, которые можно использовать как шаблон при создании собственных сценариев. Также есть пакет подробной документации по работе с продуктом.
3. У нас есть наработки по инструментам миграции, но миграция миграции рознь и для каждого оператора ее длительность будет отличаться по времени, связано это время с типом реализации старых конфигураций и настроек обработчиков.
Под "быстрым запуском" имеется ввиду время без миграции. Продукт можно запустить за несколько часов или даже минут с предустановленными настройками (бекап), например, если речь о новой площадке. Обновление продукта также проходит достаточно быстро — за несколько минут.
4. Мы разобрали несколько протоколов, к которым у нас был доступ (Alcatel, Ericsson, Nokia, ZTE…), и нашли, что их можно описать в общем виде следующим образом:
· Присутствует или нет «не-ASN1» заголовок, и длина заголовка задана фиксировано или внутри самого заголовка.
· Весь файл — единая ASN1-структура, или последовательный их список.
· Если единая ASN1-структура, то искомый список xDR надо искать либо по указанному тегу, либо просто сместиться на указанное число тегов внутрь.
· Если это список готовых xDR, то: а. они могут быть разделены на блоки указанной длины и с указанным разделителем (0x00, 0xFF); b. может быть несколько байт, которые надо пропускать; c. может быть сложная структура, для которой следует спуститься вниз на несколько элементов или брать только элементы внутри заданного тега.
В целом, таких правил оказалось достаточно, чтобы описать все встретившиеся нам типы ASN1-кодирования. Ну а после декодирования, получив уже просто список деревьев с параметрами, можно их мапить на результирующий плоский список. Нюансов в CSV мы не встретили (кроме разного вида разделителей), а с BinaryOffset были аналогичные вопросы, как и с ASN1, и решались аналогично.
5. Это, конечно, не сущность БД и не протокол. Это некая программная реализация, состоящая из объектов пакетов с метаданными, шины данных для их передачи, и потоковой реализации, вызывающей интерфейсы акторов в нужный момент.
6. Да, можно запустить на нужном количестве серверов, в том числе виртуальных.
7. В разных ЦОД’х один кластер запустить не получится. Это по большей части ограничение используемого PostgreSQL, так что если его выйдет запустить Active-Active в нескольких ЦОД’х — то можно попробовать.
8. Конфигурация хранится в служебной БД (postgres, oracle), прозрачно экспортируется/импортируется через XML-ки. Каждый оператор (актор) — одна строка таблицы. При редактировании мы пишем в БД новые данные и в исторические таблицы — изменения. Бэкап выполняется как на уровне БД, так и, для удобства работы на нескольких площадках (ПРОМ/тестовые зоны), через автоматический экспорт через файловую систему: измененные сценарии сбрасываются на диск и там попадают под контроль git. Соответственно, поставка сценариев тоже идет через xml-ки, которые автоматически читаются с диска в БД.
.
Как мы разработали российскую систему предбиллинга на замену решениям HP IUM и Oracle