Перейти к содержимому
Калькуляторы

ldmitry

Пользователи
  • Публикации

    8
  • Зарегистрирован

  • Посещение

1 подписчик

О ldmitry

  • Звание
    Абитуриент
  1. BgBilling

    Добрый день! Мы команду из 3-4 человек можем подключить к BGBilling-у в Москве. Цена вопроса? Обслуживаем оператора в несколько десятков тыс. абонентов на BG. Отличный биллинг. Отдельно можно сделать развернутую аналитику.
  2. Radius + MSSQL

    У Microsoft есть свой Radius сервер, называется IAS, но он вам не подойдет это продукт для управления серверами доступа RRAS того же Microsoft. Идеально в своем применении. А вот во FreeRADIUS есть очень хорошая модульность, чего наверно нигде больше нет. Я бы не стал менять FreeRADIUS ни на что другое ради теоретической "единой платформы" между СУБД и RADIUS. Мне кажется надо просто испытать под синтетической нагрузкой и понять сколько тянет и как растет. Перейти с MySQL на что-то иное задача хорошая, если это обосновывается потребностями. Скажу, что я сам большой поклонник MS SQL. Мы этот продукт использовали в телекоме в целой куче направлений. Конкретно для FreeRADIUS2 + MS SQL есть образец конфигурации http://www.larionov.pro/2010/08/freeradius2-ms-sql-2008.html. Ещё про ODBC. Вообще, несмотря на старость, ODBC не теряет актуальности. Довольно простой интерфейс и особой медленности там нет. Представьте себе, Microsoft планирует отказ от OLE DB в пользу ODBC в некотором будущем. Но это я про ODBC под Windows, конечно говорю, у вас со стороны FreeRADIUS другой ODBC.
  3. Я думаю, если биллинг будет предоставлять очень-очень базовый функционал по биллингованию и обойдется без всяких инвентори и helpdesk-ов, то может быть это можно сделать и собрать денег. Самое сложное - собрать денег, т.к. люди должны увидеть серьезность проекта и этих людей должно быть реально много. А из-за того, что их много, вы с ними этот функционал не согласуете никогда, поэтому вам (автору биллинга) придется ваше виденье реализовать - поэтому нельзя делать широкий функционал. Вы слышали, что ежегодно в мире 80 миллиардов долларов тратится в софтверной индустрии на реализацию требований, которые никогда не используются? Вы же не хотите потратить своего времени годик впустую? Советую Вам (инициатору) написать ТЗ. Если это будет хороший документ, Вы может быть найдете людей, которые смогут это реально поддержать. Я бы для упрощения реализации написал бы конфигурацию к FreeRadius2, которая бы собирала данные в базу, написал бы процедуры обработки к этим данным и веб-интерфейс и этим ограничился бы для начала. Люди меняли бы процедуры обработки (а это делают все), но продолжали "иметь сертифицированный биллинг" (хотя мы то с вами понимаем...) - это закрыло бы проблему. В свое время был такой проект FreeNIBS - популярный был, он представлял собой доработку к FreeRadius, где код биллингования был вставлен в MySQL модуль (C модуль, который сохранял данные в базу, ну вот тарификация была вставлена туда же). Проект как-то свернулся потом, как и многие другие - автор утратил интерес. Поэтому нужен фонд. Ибо кто будет сертифицировать? Но в C я бы тарификацию делать не стал - сделайте отложенную тарификацию на процедурах - пусть будет лаг, уверяю вас небольшой минус за реально полученные услуги это не проблема; большая (ударение на о) проблема это код на C или свой радиус. Нужно меньше нового кода. Но никто не поддержит это со старта. Любой проект начинается или с полезного хоть как-то работающего приложения (обычный вариант OpenSource), или хотя бы с понятной документации, что это будет (обычный вариант с инвестициями). Для NetFlow, я бы рекомендовал испльзовать flow-tools в качестве коллетора. В базу можно собирать как написано здесь. Чтоб вам не пришло в голову расширять возможности в сторону helpdesk скажу, что проработав 10 лет в операторах связи по части автоматизации, я вижу что только в одном из десяти внедрений используется встроенная в биллинг система заявок. Это из-за сложности требований телекомов к таким системам. Вот с какими требованиями сталкивался я. Я предлагаю не делать это в биллинге, а делать это примерно так. В общем резюмируя, рецепт такой: 1. Меньше кода, используйте имеющиеся коллекторы и радиусы. 2. Пишите документацию или сразу делайте проект, потом собирайте деньги на разработку или сертификацию.
  4. Тестирование Ericsson SmartEdge 100

    Вот это меня больше всего заинтересовало. Где находится стандартная документация? ;-) Я извиняюсь, может все уже в курсе где она, но найти поиском так просто не удалось.
  5. Всяк корректно, я давно работаю в провайдерах и скажу, что по NetFlow корректно и, я бы сказал, стандартно. Главное, Вы можете дать клиенту детализацию, которая совпадет полностью с суммой.На порту, как вы правильно заметили по зонам не разделишь. Хотя это чаще всего не нужно, зато объемы данных заметно меньше. А вот насчет счетчиков фаервола - это для совсем маленьких объемов, т.к. вам надо промаршрутизировать трафик через машину со счетчиками. Есть методы, связанные с пассивным слушанием, но тогда вы не имеете контроля над не подсчитанным объемом. Ведь если свитч, который делает mirroring на ваш "слушающий" интерфейс, или сам интерфейс или ОС дропают такой трафик (из-за нехватки буферов на пиках и т.п.) вы ничего о нем не знаете. В отличие от NetFlow роутеров, которые отчитываются о дропнутых потоках в т.ч. В общем, последними двумя методами (счетчики фаервола и "слушание") пользуются небольшие провайдеры, а для крупных - NetFlow и данные с портов.
  6. О, а я тоже использовал ipacct, ещё когда полоса была в пару мегабит всего. Для него 20 тыс. потоков в час уже неплохая нагрузка, к тому же он на роутере работает-то. А по нетфлоу с 400 Мегабитного потока получаем статистику и нет проблем, а там до 70 млн. потоков в час доходит.С ipacct-то я все данные в MySQL заносил и БД не была узким местом :-)
  7. Друзья, Во-первых, нельзя получать данные по NetFlow ни равномерно, ни по завершении сессии, т.к. роутер должен держать свободными свои буфера, и освобождает их так быстро как возможно. К тому же, счетчик байт на поток только 32 бита. Так что на одну в понимании TCP сессию, вы можете получить многие сотни потоков в понятиях NetFlow. Как вы это обработаете уже не проблема роутера ;-) Во-вторых, БД MySQL в силу многих ограничений очень плохо работает с такими объемными данными которые вы можете получить по NetFlow (большие массивы не удаляются, при параллельных извлечениях и одновременно с этим "большой" вставке запросы на извлечение черезвычайно (встают практически) замедляются вне зависимости от извлекаемого объема). Вам обязательно надо предварительно обработать данные ещё до этой базы. Я имел опыт обработки NetFlow утилитами из пакета flow-tools, работал с тремя базами - MySQL, MS SQL и PostgreSQL, и скажу что для задач работы с сетевой статистикой, баз равных PostgreSQL просто нет. Например, оказалось быстрее загнать данные в PostgreSQL, там суммировать и выгрузить итоги в нужную мне базу, чем делать это утилитами или, тем более (упаси бог) грузить сырые данные в MS или (упаси бог дважды) в MySQL. Вот тут я написал всё на эту тему: http://ldmitry.blogspot.com/2010/07/netflow-3_12.html
  8. Мы пользуемся LanBilling, я занимаюсь интеграцией с этим продуктом нашей CRM/ServiceDesk системы. Особенность системы в том, что вся работа с БД идет через процесс LBcore написанный на С с закрытым кодом. Путь интеграции с системой через доработки путем добавления полей в БД официально закрыт, т.к. как-там LBcore поведет себя если вы поправите таблицы не понятно. Допустим, вы положите деньги своим импортом из кассового ПО путем update таблицы с балансами и обнаружите что деньги не упали - не удивляйтесь - ведь вы не знаете, не сделал ли LBcore в этот момент update поля известными ему значениями. Официальный путь интеграции - через основанный на SOAP протокол обращения к LBcore, поддерживающий свою собственную авторизацию и прочее. Этот путь сложнее дороже и если вы хотите добавить какие-то поля в LB, делайте это через разработчиков. Эта беда касается не только интеграции, но и доработки ибо суть та же.