Pull to refresh

Comments 15

А что делает HARD?
Почему был выбран вариант с HTTP\JSON, a допустим, не реализацией модуля FreeRADIUS?
Спасибо
В hard содержится вся бизнес-логика аутентификации, авторизации и аккаунтинга. Плюс он взаимодействует с БД профилей и данных по аккаунтингу. FreeRADIUS в этой схеме используется в «тупом» варианте, фактически для того, чтобы декодировать бинарный протокол RADIUS в текстовый формат и наоборот.

Модуль FR делать не стали, потому что нужно было программировать на C, а делать это очень не хотелось. Использовали rlm_perl.
Ясно.
А CDR там же предобрабатываются, или нужно что-то еще дорисовать на картинках?
Если речь о RADIUS-аккаунтинге, то предобработка делается в hard. Если же о телефонных CDR, то нужно дорисовывать, в этом смысле схема упрощена.
Именно о CDR. А можете наложить структурную схему на домены mediation, rating, invoicing?

А сервер очередей для AAA и платежей один? Внешний или oracle queues, почему? )

>Если у вас был доступ в интернет до аварии, то после аварии он у вас останется, вы ничего не заметите.

Значит ли это, что ААА для инициации сессии всегда обращается в основную БД? Или какой-то provisioning есть, и AAA сможет самостоятельно принять решение во время инициации абонента?

Статья больше вопросов вызывает если честно…

Rating и Invoicing — темы за рамками этой статьи. Она про отказоустойчивость.

Очереди для AAA используются внешние, ActiveMQ. Очереди AQ применяются внутри ядра, но об этом, опять же, в другой раз.

AAA использует собственную БД на MongoDB, в нее реплицируются данные из провиженинга. В момент инициализации сессии обращение в ядро не происходит.

Задавайте вопросы про отказоустойчивость :).
Так для доменов разные требования по отказоустойчивости, например invoicing можно и положить на пару часов…

Очереди — тоже одна из популярных точек отказа…

Из статьи не очевидно наличия provisioning в сторону ААА, я конечно подозревал что все по канонам, но…

А что будете делать, если redo битый окажется (причины опустим)? А через пару дней основная база загнется и надо будет переключаться? )
Посмотрите на стрелочки между ядром и БД харда, у них там двусторонний обмен. Если очередь отвалится, то ничего страшного, как поднимут, так и хорошо, ее просто нужно мониторить. Своего состояния у нее не много, в любой момент можно отправить данные заново, даже если она все потеряет.
Да это то понятно, вопрос скорее во времени восстановления работы и влиянии на трафик, тут то данные критичны ко времени обработки… Не выгрузили аккаунтинг, бизнес-логика не получила данные, провиженинг не заблокировал вовремя абонента ну итд… Вот не видел в биллингах идентичных реализаций очередей, везде нюансы были )
Там все хитро. AAA-сервер может пустить абонента по старым данным. Как только соединение с основной БД восстановится, то в момент загрузки сессий будет сгенерирована команда на терминацию запрещенной сессии. Даже если сессия по какой-то причине загрузилась из-за гонки, то периодическое задание прибьет ее.
Да это тоже очевидно
Как только связь с БД восстановится, ААА начнет выгружать аккаунтинг, пока он прогрузится, пока сработает бизнес-логика, пока провиженинг сработает в сторону ААА. Да, все в конечном итоге нормализуется, состояния синхронизируются, но за какое время? А то в промежутке абонент тариф поменяет, какие-нибудь услуги не окажутся в нужном объеме и качестве, пересчитывать придется и претензии разбирать, а это деньги и немаленькие.
В разных системах принимают разные меры для оптимизации этого процесса.
Ну все перерасчеты и прочее — больше организационный вопрос. А что касается скорости, то это секунды после восстановления связи, там очереди сообщений.
А что будете делать, если redo битый окажется (причины опустим)? А через пару дней основная база загнется и надо будет переключаться? )


Битые реду-логи оракл не применяет. Мониторим отставание текущего номера SCN на резервной базе от SCN основной. Если оно становится слишком большим — выдаем алерт, принимаем меры.
в случае с базой, я так понимаю у вас не RAC кластер? для чего эти «ручные» манипуляции с копированием redo-логов и shared IP?
RAC требует более дорогой лицензии.
RAC более требователен к железу. Нужна хорошая корзина с резервированием.
RAC дороже в администрировании.

Поэтому RAC нужно использовать только там, где без него не обойтись никак. Для всего остального есть мастеркард, то есть копирование redo-логов.
Sign up to leave a comment.