[dk_]

Интересует мнение операторов о работе этого биллинга.

Хорошее плохое, любые отзывы.

[VZP]

Пользовались мы этим биллингом. Техподдеражка оказывалась не своевременно(говорилли что очень много заказов). Возникали проблемы с авторизацией клиентов по радиусу. Компания не большая. Отдел внедрения, он же и техподдержка. Биллинг очень требовательный по ресурсам сервера(у нас сильно тормозил). В результате перешли на ланбиллинг. Сейчас все работает хорошо. Рекомендую ланбиллинг.

[vurd]

Как это "пользовались, но перешли на lan billing"? Учитывая стоимость решения от Latera это довольно таки серъезный шаг.

[vadimz]

Пользовались мы этим биллингом. Техподдеражка оказывалась не своевременно(говорилли что очень много заказов). Возникали проблемы с авторизацией клиентов по радиусу. Компания не большая. Отдел внедрения, он же и техподдержка. Биллинг очень требовательный по ресурсам сервера(у нас сильно тормозил). В результате перешли на ланбиллинг. Сейчас все работает хорошо. Рекомендую ланбиллинг.

VZP, вы похоже что-то перепутали. Биллинг Гида это который hydra-billing.ru. Во-первых, с него не было ни одного перехода на другой биллинг никогда. Это легко отследить разработчикам, потому что те, кто его внедрил оплачивают техподдержку.

Во-вторых, наоборот основная масса переходит с UTM и Lanbilling как раз из-за отсутствия новых функций и масштабируемости систем.

В-третьих, как раз основная характеристика Гидры - нелинейная зависимость между числом абонентов и требований к железу, то есть при увеличении числа абонентов в 10 раз нагрузка на железо будет всего-лишь на несколько % выше. Если внимательно посмотреть на требования к железу http://www.hydra-billing.ru/tech/ , то они там даны исходя и текущий оптимальных конфигураций, вообще приземленных без каких-либо невероятных требований к серверам. Стартапы до 2-3 тыс абонентов вообще гоняют биллинг на десктопе Core i7 и чувствуют себя прекрасно, это что, непомерные требования к железу? ;)

[Ivan_83]

VZP, вы похоже что-то перепутали.

Человек специально тут зарегался чтобы нас предупредить, он не мог ничего перепутать %)))))

[martin74]

сейчас заняты внедрением... Пока нравится ;)

[kapa]

Знакомые свалали на него с Нетапа - хвалили.

[trv7111]

Смотря в чем. Хвалить пока нечего. Одни глюки, скриптовые подпорки и затычки. Чего-то постоянно отваливается, про счто-либо забывает, с кого-то много снимает. Глюкодром, одним словом. С прошлого октября жалеем, что связались. Внятной документации нет, а поддержка, такое впечатление создается, этот биллинг также впервые видит. Подпорки постоянно падают. Под каждый вид серверов доступа нужен свой радиус сервер. То есть если у вас есть хотспот, диалап и PPPoE_ISG то вам нужно будет ТРИ радиуса. А если вам понадобится что-то еще - понадобится еще один. Так как плагины у них есть, но они не работают так как должны были бы.

 

На нас они тут тренируются - новые фичи к нему прикручивают. Например: мы в октябре начали внедрение, до марта у них не было SNMP коллектора, и они не были в курсе, как трафик по SNMP с порта собирать. Отсутствует, присутствующая в том же лан-биллинге, динамическая настройка сервисов для Cisco ISG. Будте любезны завести ВСЕ имеющиеся у вас сервисы прямо в конфиг кошака, а они ужо выберут его, очередной затычкой. Сейчас, прошел уже почти ГОД с начала внедрения, в очередной раз понадобился СТЕНД ДЛЯ ТЕСТИРОВАНИЯ НОВОЙ системы динамического конфигурирования ISG сервисов. То есть у них его ПРОСТО НЕ БЫЛО!! Совсем.

 

Ну хорошо, если у вас кошка одна, или две. А если больше десятка?

 

Так что СЫРОЙ софт. Если неохота быть подопытной крысой - не связывайтесь.

[Gunner]

еще один =)

[shicoy]

Вот читаю отзывы некоторых товарищей, и честно понять не могу. Джинца 100%.

У нас данный биллинг работает с 2010года, да были некоторые проблемы, которые решались и решаются оперативно.

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

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

А если кому-то страшно поднять три радиус-сервера для оказания разных услуг, ну наверное тогда да, какой нить нетап мастхэв.

 

 

ps. Понял, пиарщики Ланбиллинга понабежали. Писали бы хоть какая компания так отзывается, что аж несмогли запустить у себя ISG.

[Ivan_83]

Позорный способ конкуренции.

[NiTr0]

Стартапы до 2-3 тыс абонентов вообще гоняют биллинг на десктопе Core i7 и чувствуют себя прекрасно, это что, непомерные требования к железу? ;)

Х**се, абиллс для такого же кол-ва абонентов работает на 2-головом атлоне 5200+ при нагрузке на проц до 30% в пике, т.е. запаса еще эдак 500% минимум... При том, что абиллс я бы не назвал тщательно оптимизированным и заточенным на высоконагруженные проекты...

[apm]

НЕ понял какая именно сторона тут проплачена, но явно что дело не чисто

[shicoy]

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

 

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

У нас загрузка 2% CPU (и то хер знает чем) на базе с ежесуточными начислениями порядка 20к+ абонов. Железо 2 ксеона каких-то(не помню ей богу) и оперативы 40Гбайт :)

[NiTr0]

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

Ye если весь "обсчет" заключается в периодических списаниях - тут и атома должно хватить...

Я привел пример для сети с туннелями, с интервалом аккаунтинга сессии 90 секунд.

[Cramac]

реклама сработала, начали обсуждения :)

[shicoy]

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

Ye если весь "обсчет" заключается в периодических списаниях - тут и атома должно хватить...

Я привел пример для сети с туннелями, с интервалом аккаунтинга сессии 90 секунд.

Короче все нормально там с производительностью :)

[NiTr0]

Да собссно это было больше обращено к разработчикам, чтобы не пугали народ такими цифрами. Потому как если на 3к абонов надо 4-голового монстра с гипертрейдингом - то сколько понадобится скажем на 30к, учитывая что нагрузка растет нелинейно (увеличение кол-ва абонов, над которыми нужно провести операции * увеличение кол-ва обрабатываемых записей в БД * еще что-то) - неужто кластер городить, из эдак десятка 4-сокетных серверов по 8 голов в каждом сокете? :)

[martin74]

гипертрединг они кстати рекомендуют выключать ;)

 

Мы под биллинг взяли два сервера Intel® Xeon® CPU E5620 @ 2.40GHz

Не жалуемся. Кстати - два сервера - это было наше желание, мы хотим биллинг резервировать

[lan-viper]

IPv6 держит?

 

PS

А меня огорчило то, что СУБД - Oracle. Дорого однако всё вместе получается...

[vadimz]

Oracle Standart Edition One (до 2 сокетов) ~ 1098$ с техподдержкой на год. Это действительно непомерные деньги.

Еще реально можно и дешевле взять со скидкой.

А так, действительно, зачем Oracle, там же нормальная отказоустойчивость и реально хорошо журналируемые транзакции (можно сервак по резету перегрузить и все взлетает без потерь, транзакции продолжаются), можно дампы снимать на горячую и целостность данных не нарушится (консистентный бакап), нормальная репликация в том числе кластер можно сделать (Oracle RAC, ASM).

Обновления базы можно устанавливать на горячую (накатываете обновления и потом раз и переключаете версии). Нормальный API можно сделать на стороне БД, по которому свои же приложения будут работать, то есть API будет на все автоматом, а не только на то, что разработчики сделают. Встроенные возможности по redefinition (если просто, то дефрагментация данных, по тому же трафику, реально дает существенное ускорение при работе с таблицами где по несколько десятков млн записей). Ну и куча других возможностей, которые будут ваши программисты писать годами за зарплату, выйдет дешевле? ;)

[terrible]

Судя по вышеописанным постам - гидра - нормальный биллинг, если использовать с головой.

[Sp!ZER]

Сейчас все работает хорошо. Рекомендую ланбиллинг.

ЛанБиллинг? 1.9 или 2.0? Хуже биллинга чем ЛанБиллинг и его поддержки - просто не встречал. А что стоит их код :).

[Paparaцo]

Oracle Standart Edition One (до 2 сокетов) ~ 1098$ с техподдержкой на год. Это действительно непомерные деньги.

Еще реально можно и дешевле взять со скидкой.

 

...нормальная репликация в том числе кластер можно сделать (Oracle RAC, ASM)...и куча других возможностей, которые будут ваши программисты писать годами за зарплату, выйдет дешевле? ;)

 

Если речь идет о лицензии Oracle Standart Edition One NU Plus за 1000USD, то это нарушение лицензионного соглашения Oracle, читайте внимательно OLSA! Но насколько я понимаю для разработчика гидры это не принципиально, ведь это "подстава" для оператора, а не для него. :)

А использование Oracle RACа и прочего оракловского МРАКа для данной софтинки "за гранью добра и зла" по затратам.

 

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

1. Отсутствии финансовой подсисистемы. Нет учета сч-ф, корректировок сч-ф, учета дебиторки, ОСВ и пр.

2. "Костыль" в реализации циска ISG и, скорее всего, прочих похожих на хуавеях, джуниперах. Также непонятно насчет CoA, похоже тоже "костыль".

3. Ограниченные возможности перерасчета, его как бы там совсем нет ни для традиционного голоса, ни для трафик (если его еще кто-то считает)

4. Потенциальные проблемы с производительность в следствии использовании "прокладки" между FreeRAD-DB. У них она называется хард. Вот боюсь, что этот хард может жестко аукнуться на производительности.

5. Какой-то убогий интерфейс для абонентов (но это "вкусовые" вещи)

6. Подтормаживает AJAX-интерфейс даже при 2-х тыс. абонентов, при 10К страшно подумать.

7. В целом ощущение "зоопарка": Ruby, Python, Erlang, PL\SQL, AJAX, Perl.

 

 

Работают в конторе, по ощущениям, 3-5 человек, кого-то привлекают на аутсорс, вообщем как-то так. И насчет поддержке - про SLA ни слова, но зато много про то, что за ваши деньги, все что угодно, что никаких проблем с работой биллинга не было, нет и не будет, вообщем как говорится "дуют в уши".

 

В принципе может у гидры и было бы будущее, если бы рынок биллинговых систем не "сдулся"...

[vadimz]

Позволю себе сделать уточнение для предыдущего поста.

 

1. Отсутствие учета дебеторки у биллинга это как можно понять? Присутствуют отчеты по взаиморасчетам с клиентом, формирование списков для отключения (КТВ) и возможность вообще работать с должниками - выбирать их, слать им смс и тд.

2. CoA - это не костыль, а технология. Суть заключается в возможности сделать что-то с BRAS по инициативе биллинга, а не только когда BRAS-у захочется сделать запрос по RADIUS. Вообще понятие "костыль" это когда вы делаете что-то "против шерсти", а не когда в рамках существующей технологии, когда красиво расписываете RADIUS-атрибуты в биллинге, их подстановки и удобными CoA-запросами, которые тоже настраиваете с интерфейса делаете дополнительные действия.

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

4. HARD можно исключить между FreeRADUIS и биллингом вообще. Просто тогда при каждом чихе без кэширования будет обращение в базу и теряются все его "фишки" в виде многопоточной работы и автономного кэша на случай потери связи. А так если он кажется высокорискованным убираете его и работаете "без смазки" сразу с базой.

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

6. Не обоснованно, во-первых, работа интерфейса вообще от числа абонентов не зависит, во-вторых, где вы увидели тормоза? Не дадут соврать ребята, которые смотрели презентацию на УКОС 2012 в Крыму 2 дня назад, по WiFi и непонятному к нему каналу все шустро летало с серверов в России.

7. -Erlang, -Perl. Каждый язык или каждая технология - для своих задач. AJAX - http://ru.wikipedia.org/wiki/AJAX , честно говоря даже не знаю как прокомментировать.

 

По поводу персонала, как вы себе представляете нужно работать, чтобы сделать такое втроем? ;). Если бы это было возможно, было бы прекрасно, но даже по support понятно, что на одном внедрении сидит 5 человек (без разработчиков и прочего пресонала).

 

По поводу рынка биллингов, интересно, куда он сдулся-то? Что, у всех в мире ВНЕЗАПНО решились вопросы с биллингом?

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