+8
На рассмотрении

Сделать инструкцию: "Схема в которой присутствуют 2- FreeRadius сервера и 2 - ядра "MikBill", так же набор NAS(сателлитов) их может быть сколько угодно"

dmitrenko17 4 года назад обновлен mikbill (CEO) 4 года назад 22

В описании биллинга на страцице Архитектура https://www.mikbill.ru/asr/arkhitektura.html приведена схема резервирования биллинга. При попытке реализации подобной схемы столкнулись со сложностью ее реализации. Так же интересно возможно ли сделать 2 базы MySql, 2- FreeRadius сервера и 2 - ядра "MikBill", так же набор NAS? 2 базы MySql: master-master, master-slave?

Ответ

Ответ

ок, спасибо, понял, будем тестировать.

Не знаю как так совпало, но вот я вчера себе так сказать в режиме теста это запускать начал.

Вот тоже думаю над схемой и способом синхронизации двух БД.

Хочу получить два полностью рабочих биллинга,

с двумя отдельными ядрами биллинга, двумя радиусами, двумя БД, и тд.

На двух разных физ машинах.


Пробовали так делать и возник ряд трудностей:
- Если использовать репликацию Mysql то происходит рассинхронизация при первом же любом действии с резервной машиной.
- 1 база - 2 биллинга, снимается двойная абонплата, как вариант можно убрать все из крона на резервном тазике, но как бы немного не то чего хочется достичь
- Так же интересно как будет работать система, если ставить радиус от микбилла на НАС сервера, как я понимаю он в базу смотрит, а значит можно указать базу на другом сервере.

- Так же интересно как будет работать система, если ставить радиус от микбилла на НАС сервера, как я понимаю он в базу смотрит, а значит можно указать базу на другом сервере.

Все правильно. Только вам еще надо запустить второе ядро чтобы тоже смотрело на базу.

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

2 ядро может быть а может и не быть.

тут ваш выбор.


А смотрели в сторону "кеша" ?

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

Да тут система как "дышло" куда повернешь так и вышло.

Вариантов много и все правильные.


зависит больше от схемы сети и сервера доступа как реализовать.

те все таки намекаете что руки из жо...))) понял, будем копать.

нет не намекаю, зачем мне это. глупости какие то вы пишите.


Какая логика сети сейчас ?

Попробуем придумать что нить

Я вот то же ещё сам не могу определится, как я это хочу и что хочу.

Пока пробую.

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

accel-cmd b5fee831eedf9ea8282aa35f12053c1b1ebaf29d
все замедляется еще и экзотическими сетевушками)))

на демо стенде кеш у нас работал, но с котылём, а именно не работало копирование файла с юзерами на НАС, решили отдельным скриптом на копирования этого файлика.
Очень хочется увидеть что Вы переделали в версии 2.10.2 в работе с аццелом и там уже оттестировать работу с кешем, а пока ждем)))


А там есть вариант чтобы включить их 2 вместе и не ребутать аксель вовсе.

только в файле кеша стоит поставить время сесси 3600 чтобы абоненты потом возвращались в биллинг а то они навечно остануться в кеше..

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

во втором надо ограничивать время жизни сессии

SESSION-TIMEOUT атрибут

Ответ

ок, спасибо, понял, будем тестировать.

пожалуйста, ждем результатов

как я понял из вышесказанного, необходимо к каждой записи о данных абона добавить атрибут SESSION-TIMEOUT в файл "users" который генерирует скрипт исполняемый на сервере с биллингом. т.е. необходима доработка скрипта? или же эти параметры можно задать в конфиге акселя?

сейчас сделал что бы скрипт добавлял к каждой записи SESSION-TIMEOUT=600, пока тестируем..но как я понимаю, это не самый лучший выход, т.к. каждые 10мин у абона будет отваливаться интернет на 2-3 мин. что не очень хорошо, если проблемы с биллингом затянутся на несколько часов, абоны растерзают тех.поддержку, даже если сессии будут длится по часу. и слишком большое значение туда не укажешь, т.к. хочется видеть онлай в востановившемся биллинге и понимать что уже все хорошо

часа достаточно, сессия переоткроета...dhcp lease time 300 ?

при таком соотношении

3600 - 300 абонента не "залипнет" без сессии

если у абона на прямую комп включен - все ок, а вот роутеры, особенно тплинки тупят 2.5 мин прежде чем попытаться сессию обновить..даже если им листайм 30 сек поставить, он будет постоянно продлевать, а как только у него это не выйдет будет тупить примерно 2.5 минуты...только что засекали)
все равно, думаю не критично если на пару минут сессия у абона отвалится, в ввиду альтернативы полного отсутствия интернета...

там как раз тупняк у роутеров из за короткой лизы

в акселе сделайте

lease-time=300

max-lease-time=3600

уверен что картина измениться в более правальную сторону

Сервис поддержки клиентов работает на платформе UserEcho