BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 04 мар 2024, 11:29

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 38 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: 04 фев 2016, 20:48 
Не в сети

Зарегистрирован: 11 мар 2015, 11:06
Сообщения: 198
Карма: 0
Здравствуйте.
Подскажите, есть ли какая-то инструкция, как нам сделать сабж ?
Почитали тему
viewtopic.php?f=44&t=8527&hilit=%D1%80%D0%B5%D0%B7%D0%B5%D1%80%D0%B2%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
Там только общие формулировки.
Интересует в первую очередь резервный радиус.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 05 фев 2016, 07:58 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Мы у себя сделали резервирование Access-серверов, работает.
Нюансов вроде нет особых -просто два или больше access-сервера настраиваются на один и тот же rootDeivceId.
Только app.id разный нужно конечно.
Единственно, если ложится аккаунтинг, циска считает, что радиус умер весь и резерв не работает.
Так что толку немного.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 08 фев 2016, 10:49 
Не в сети

Зарегистрирован: 11 мар 2015, 11:06
Сообщения: 198
Карма: 0
Если аккаунтинг не резервируется - наверное действительно большого смысла нет.
Спасибо.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 08 фев 2016, 18:59 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
А accounting что мешает резервировать?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 17 фев 2016, 14:37 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
vdd писал(а):
А accounting что мешает резервировать?


Надо пробовать. Проблема у кого-то возникла, ее исправили и с тех пор больше не пробовали. Ну там еще есть ограничения не переобработку логов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 14:15 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
А если accounting на резервном сервере принимать на другой радиус? На freeradius, например.
Что бы циска не считала сервер не исправным.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 14:32 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Хм... Навскидку - стопы не обрабатываем => Access не узнает, что сессия завершена, и по лимиту отбивать будет.
Тогда уж и Access сделать на Freeradius и пускать всех с дефолтным тарифом :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 14:56 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
Дефолтный тариф это совсем резерв. У каждого, наверное, такой резервный резерв настроен.

Во freeradiusе, например, "настроить" закрытие сессий в биллинге, что бы access не путался в количестве сессий.

Я, наивным образом, думал, что access и accounting сервера стали автономными программами, в первую очередь, для возможности резервирования. Какая разница, кто обработал stop-пакет - первый сервер или двадцать первый.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 15:00 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
"access и accounting сервера стали автономными программами" для балансировки нагрузки...
и в отличие от freeradius наши реализации кроме "тупого" логирования и проверки прав доступа занимаются управлением оборудованием и тарификацией
и хотелось бы понять от каких ситуаций вы хотите защититься с помощью резервирования...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 17:01 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn писал(а):
"access и accounting сервера стали автономными программами" для балансировки нагрузки...

А балансировка разве не автоматически обеспечивает резервирование? Ну кроме случаев, когда суммарная нагрузка больше, чем может переварить один элемент.
skn писал(а):
и в отличие от freeradius наши реализации кроме "тупого" логирования и проверки прав доступа занимаются управлением оборудованием и тарификацией

freeradius был назван исключительно в качестве чего-то, что способно принять Accounting-Request на 1813 порту и отдать Accounting-Response. Для того, что бы NAS не забраковал bgb-access на 1812 порту. Потому как второй bgb-accounting то ли можно запускать, то ли нельзя.
skn писал(а):
и хотелось бы понять от каких ситуаций вы хотите защититься с помощью резервирования...

От самых стандартных - отказ основной пары bgb-access+bgb-accounting, например, из-за выхода из строя железа.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 17:05 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn писал(а):
"access и accounting сервера стали автономными программами" для балансировки нагрузки...

Предлагаю с этой стороны и зайти.

Какие сейчас есть рабочие схемы балансировки нагрузки для Операторов, использующих RADIUS?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 17:12 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
vdd писал(а):
skn писал(а):
"access и accounting сервера стали автономными программами" для балансировки нагрузки...

Предлагаю с этой стороны и зайти.

Какие сейчас есть рабочие схемы балансировки нагрузки для Операторов, использующих RADIUS?


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 17:14 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
vdd писал(а):
vdd писал(а):
и хотелось бы понять от каких ситуаций вы хотите защититься с помощью резервирования...

От самых стандартных - отказ основной пары bgb-access+bgb-accounting, например, из-за выхода из строя железа.


у вас так часто выходит железо из строя?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 17:23 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn писал(а):
под балансировкой подразумевается, что если железка не справляется с нагрузкой, то часть компонентов может быть вынесена на другое железо
(ни о какой параллельной работе и динамическом распределение нагрузки речь не идет)


Тогда не стоит называть это балансировкой.

skn писал(а):
у вас так часто выходит железо из строя?


Нет.
А резервирование делают только для того, что выходит из строя часто?
И, кстати, что такое "часто" для компонента, без которого надцать тысяч абонентов не смогут воспользоваться основной услугой Оператора?

Вот Оператор вынес из-за того, что один сервер не справляется с нагрузкой часть компонентов (bgb-access и bgb-accounting) на другие сервера и получил три разных железки: bgb-сервер, bgb-access и bgb-accounting. Может Оператор увеличить надежность такой схемы?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 17:34 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
vdd писал(а):
skn писал(а):
под балансировкой подразумевается, что если железка не справляется с нагрузкой, то часть компонентов может быть вынесена на другое железо
(ни о какой параллельной работе и динамическом распределение нагрузки речь не идет)


Тогда не стоит называть это балансировкой.

skn писал(а):
у вас так часто выходит железо из строя?


Нет.
А резервирование делают только для того, что выходит из строя часто?
И, кстати, что такое "часто" для компонента, без которого надцать тысяч абонентов не смогут воспользоваться основной услугой Оператора?

Вот Оператор вынес из-за того, что один сервер не справляется с нагрузкой часть компонентов (bgb-access и bgb-accounting) на другие сервера и получил три разных железки: bgb-сервер, bgb-access и bgb-accounting. Может Оператор увеличить надежность такой схемы?


1) разнесение программы по разным серверам - это один из видов балансировки
2) резервирование делают для снижения ВЕРОЯТНОСТИ отказа в обслуживании оборудования и ПО. Любое резервирование стоит денег и не всегда окупается, поэтому если у вероятность отказа в обслуживании не высока, например 1% и резервирование уменьшит его до 0,8% (то не факт что имеет смысл его делать).
3) что значит "надежность" в данном случае?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 17:43 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn писал(а):
1) разнесение программы по разным серверам - это один из видов балансировки

Разнесение программы по разным серверам - да.
Но в бгб нельзя разнести программу по разным серверам.
В бгб по вашему же описанию, можно перенести программу на другое железо. Это - масштабирование, а не балансировка.

skn писал(а):
2) резервирование делают для снижения ВЕРОЯТНОСТИ отказа в обслуживании оборудования и ПО. Любое резервирование стоит денег и не всегда окупается, поэтому если у вероятность отказа в обслуживании не высока, например 1% и резервирование уменьшит его до 0,8% (то не факт что имеет смысл его делать).

При принятии решения о резервировании оценивается не только вероятность отказа, но и последствия такого отказа. Я не зря обратил внимание на то, что произойдет, если перестанет работать bgb-access.

Вы исходники не бекапите же? Вероятность отказа всех жестких дисков в компании же крайне мала. :wink:

skn писал(а):
3) что значит "надежность" в данном случае?

Это величина, обратно пропорциональная вероятности отказа. Или что-то вроде того.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 18:00 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
Вот что бы уточнить уточнение:

Допустим, у Оператора две железки: на одной (железка А) bgb-access + bgb-accounting, на другой (железка Б) все остальное.

Может Оператор добавить еще железку А1 (bgb-access + bgb-accounting) и задействовать схемы:
1) железка А и железка А1 работают одновременно.
NAS взаимодействует только с A.
При отказе А NAS взаимодействует только с А1.
После устранения отказа NAS взаимодействует только с А.

Будут ли проблемы в биллинге? Если да, то какие?

2) железка А включена. Железка А1 выключена.
NAS взаимодействует только с A.
При отказе А NAS взаимодействует только с А1 после ее включения.
После устранения отказа NAS взаимодействует только с А после выключения А1.

Будут ли проблемы в биллинге в этом случае? Если да, то какие?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 18:37 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
"Я не зря обратил внимание на то, что произойдет, если перестанет работать bgb-access."

а что произойдет? клиенты какое то время не смогут выйти в интернет...
тут весь вопрос как "часто" это происходит: раз в 5 лет или каждую неделю...

и сколько вы за это готовы заплатить, выбирайте
1) ручной перезапуск bgb-access в течение 30 минут (без дополнительных затрат)
2) автоматическое перераспределение нагрузки в течение 1 секунды (затраты на дополнительное оборудование и разработку соответствующего ПО - 10 млн. руб)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 18:40 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
vdd писал(а):
Вот что бы уточнить уточнение:

Допустим, у Оператора две железки: на одной (железка А) bgb-access + bgb-accounting, на другой (железка Б) все остальное.

Может Оператор добавить еще железку А1 (bgb-access + bgb-accounting) и задействовать схемы:
1) железка А и железка А1 работают одновременно.
NAS взаимодействует только с A.
При отказе А NAS взаимодействует только с А1.
После устранения отказа NAS взаимодействует только с А.

Будут ли проблемы в биллинге? Если да, то какие?

2) железка А включена. Железка А1 выключена.
NAS взаимодействует только с A.
При отказе А NAS взаимодействует только с А1 после ее включения.
После устранения отказа NAS взаимодействует только с А после выключения А1.

Будут ли проблемы в биллинге в этом случае? Если да, то какие?


тут есть важная особенность, и в первой и во втором случае требуется ручное вмешательство для перенастрйки наса
а так я разницы между 1 и 2 не вижу...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 18:42 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn писал(а):
"Я не зря обратил внимание на то, что произойдет, если перестанет работать bgb-access."

а что произойдет? клиенты какое то время не смогут выйти в интернет...
тут весь вопрос как "часто" это происходит: раз в 5 лет или каждую неделю...

и сколько вы за это готовы заплатить, выбирайте
1) ручной перезапуск bgb-access в течение 30 минут (без дополнительных затрат)
2) автоматическое перераспределение нагрузки в течение 1 секунды (затраты на дополнительное оборудование и разработку соответствующего ПО - 10 млн. руб)


Это реальные величины: 30 минут? 10 млн. руб?
Если да, то как они были определены.
Если нет, то почему именно эти величины?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 18:46 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn писал(а):
vdd писал(а):
Вот что бы уточнить уточнение:

Допустим, у Оператора две железки: на одной (железка А) bgb-access + bgb-accounting, на другой (железка Б) все остальное.

Может Оператор добавить еще железку А1 (bgb-access + bgb-accounting) и задействовать схемы:
1) железка А и железка А1 работают одновременно.
NAS взаимодействует только с A.
При отказе А NAS взаимодействует только с А1.
После устранения отказа NAS взаимодействует только с А.

Будут ли проблемы в биллинге? Если да, то какие?

2) железка А включена. Железка А1 выключена.
NAS взаимодействует только с A.
При отказе А NAS взаимодействует только с А1 после ее включения.
После устранения отказа NAS взаимодействует только с А после выключения А1.

Будут ли проблемы в биллинге в этом случае? Если да, то какие?


тут есть важная особенность, и в первой и во втором случае требуется ручное вмешательство для перенастрйки наса
а так я разницы между 1 и 2 не вижу...


Вмешательство для перенастройке наса не требуется.
Разница уже в том, что в первом случае с биллингом работают одновременно два комплекта bgb-access + bgb-accounting.
а во втором случае - одновременно только один комплект работает с тем, что на железке Б.

Хотелось бы все таки узнать для обоих вариантов, или хотя бы для одного, если вы считаете их одинаковыми: Будут ли проблемы в биллинге? Если да, то какие?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 18:56 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
vdd писал(а):
skn писал(а):
"Я не зря обратил внимание на то, что произойдет, если перестанет работать bgb-access."

а что произойдет? клиенты какое то время не смогут выйти в интернет...
тут весь вопрос как "часто" это происходит: раз в 5 лет или каждую неделю...

и сколько вы за это готовы заплатить, выбирайте
1) ручной перезапуск bgb-access в течение 30 минут (без дополнительных затрат)
2) автоматическое перераспределение нагрузки в течение 1 секунды (затраты на дополнительное оборудование и разработку соответствующего ПО - 10 млн. руб)


Это реальные величины: 30 минут? 10 млн. руб?
Если да, то как они были определены.
Если нет, то почему именно эти величины?


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

за 30 минут вполне можно не спеша запустить резервный сервер и перенастроить ПО на его использование
а для горячего переключения требуется почти полностью переписать bgb-access (а это работа группы программистов в течение года)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 19:02 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn писал(а):
а для горячего переключения требуется почти полностью переписать bgb-access (а это работа группы программистов в течение года)


Cromeshnic писал(а):
Мы у себя сделали резервирование Access-серверов, работает.
Нюансов вроде нет особых -просто два или больше access-сервера настраиваются на один и тот же rootDeivceId.
Только app.id разный нужно конечно.

Cromeshnic, вы переписали почти полностью bgb-access? Как говорится, снимаю шляпу. :facepalm:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 19:07 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
vdd писал(а):
Cromeshnic писал(а):
Мы у себя сделали резервирование Access-серверов, работает.
Нюансов вроде нет особых -просто два или больше access-сервера настраиваются на один и тот же rootDeivceId.
Только app.id разный нужно конечно.

Cromeshnic, вы переписали почти полностью bgb-access? Как говорится, снимаю шляпу. :facepalm:


что то вы как то выборочно цитируете....
Цитата:
Мы у себя сделали резервирование Access-серверов, работает.
Нюансов вроде нет особых -просто два или больше access-сервера настраиваются на один и тот же rootDeivceId.
Только app.id разный нужно конечно.
Единственно, если ложится аккаунтинг, циска считает, что радиус умер весь и резерв не работает.
Так что толку немного.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 19:10 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn, правильно ли я понял, что:

1) одновременно два комплекта bgb-access + bgb-accounting работать не могут. По крайней мере, они не предназначались для такой схемы и не проверялись?
2) можно сколь угодно быстро "переключать" комплекты между собой. Возможные проблемы будут точно такими же, как если бы выдернуть из розетки железку с одним комплектом и воткнуть вилку обратно?
3) обеспечение одновременной работы комплектов bgb-access + bgb-accounting не входит в планы разработки?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 22:17 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4489
Откуда: Уфа, Россия
Карма: 186
vdd писал(а):
skn, правильно ли я понял, что:

1) одновременно два комплекта bgb-access + bgb-accounting работать не могут. По крайней мере, они не предназначались для такой схемы и не проверялись?
2) можно сколь угодно быстро "переключать" комплекты между собой. Возможные проблемы будут точно такими же, как если бы выдернуть из розетки железку с одним комплектом и воткнуть вилку обратно?
3) обеспечение одновременной работы комплектов bgb-access + bgb-accounting не входит в планы разработки?


1) да - "они не предназначались для такой схемы и не проверялись"
2) "сколь угодно быстро" это несколько преувеличено, мы не рекомендуем часто переключать сервера между собой...
по хорошему для резервирование хорошо иметь два одинаковых сервера которые могут потянуть 100% нагрузку, один из них основной и второй резер, в случае сбоя основного они меняются местами и продолжают работать до следующего сбоя...
3) 100% резервирования не получится реализовать (еще не кому в мире не удалось), можно реализовать резервирование для некоторых частных ситуаций и конфигураций (но это нужно обсуждать, именно поэтому я и спрашивал, что нужно резервировать и для каких ситуаций, так как кроме данных серверов нужно еще много чего для корректной работы системы (сервер БД, activeMQ, NAS серверов, ОС сервера и т.д.) )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 22:33 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
skn писал(а):
vdd писал(а):
1) одновременно два комплекта bgb-access + bgb-accounting работать не могут. По крайней мере, они не предназначались для такой схемы и не проверялись?

да - "они не предназначались для такой схемы и не проверялись"


Большое спасибо за точный ответ. А то одни "ромашки": "наверное будет, но попробуйте... вроде может быть будет работать, но вот что насчет переобсчета..."

"Да! Не могут!" - другое дело. :D
skn писал(а):
vdd писал(а):
2) можно сколь угодно быстро "переключать" комплекты между собой. Возможные проблемы будут точно такими же, как если бы выдернуть из розетки железку с одним комплектом и воткнуть вилку обратно?

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

А что будет, если переключение окажется слишком частым? Что-то сломается? Задублируются сессии там, или наоборот, пропадут? Еще какая беда?

vdd писал(а):
3) обеспечение одновременной работы комплектов bgb-access + bgb-accounting не входит в планы разработки?

Вопрос вроде вполне конкретный. Без никаких "дайте 100% гарантий" Конфигурацию я уже описывал: самая простая схема: две одновременно работающие железки. На каждой пара bgb-access + bgb-accounting, подключенные к одному и тому же биллингу.
Так все таки? 8)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 22:40 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
2 access сервера работать, должны . Они делались с расчетом на это.. Другой вопрос, что мы это специально не тестировали изначально.
Но есть люди, которые реально запустили такие схемы, вылезло пару багов, их справили и схемы работают.

C accounting в принципе такая же ситуация.. Но там вроде никто еще не тестировал. Оба accounting-а в теории могут работать параллельно, они пишут дельты в базы вместо абсолютных значений и т.п. Но надо пробовать.
Тут возникает вопрос с переобработкой логов. Если случилась авария и задним числом что-то надо переобработать логи, тот тут сложнее. Надо будет скорее как-то вручную собирать логи на одном accounting-е и запустить переобработку только на нем. Но и над этим можно подумать. Тут надо пробовать. Пока не попроубуем и не получим проблему, мы не сможем ее решить.

Еще есть масштабирование вширь, когда вы делите разные услуги по своими парам access+accounting серверов. Например PPoE на одной паре, а IPoE на другой. В этому случае у вас каждая пара получает свой непересекающийся сегмент дерева устройств со своим rootDeviceId. Это работает.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 22:46 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
И еще узкое место все равно остается - база. В режиме master-slave, в случае аварии все равно придется вручную переключать. Кто-то тестировал master-master на mysql с нашим биллингом, но там возникли проблемы, кажется отказались от этой схемы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24 фев 2016, 22:57 
Не в сети

Зарегистрирован: 16 ноя 2007, 16:11
Сообщения: 829
Карма: 49
stark писал(а):
2 access сервера работать, должны . Они делались с расчетом на это.. Другой вопрос, что мы это специально не тестировали изначально.
Но есть люди, которые реально запустили такие схемы, вылезло пару багов, их справили и схемы работают.


Но у них либо не циски, либо вообще не используется радиус? Ибо с мест сообщают, что циски игнорируют радиус-сервера, если они не отвечают на аккаунтинг-реквесты.

stark писал(а):
C accounting в принципе такая же ситуация.. Но там вроде никто еще не тестировал. Оба accounting-а в теории могут работать параллельно, они пишут дельты в базы вместо абсолютных значений и т.п. Но надо пробовать.
Тут возникает вопрос с переобработкой логов.

Допустим, что переобработка логов с резервного сервера не нужна. Пусть они потеряются в итоге. Подсчет количества одновременных сессий будет работать корректно? Как и где (bgb-access, bgb-accounting, база, где-то еще) проверяется наличие уже открытой сессии?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 38 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


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

Найти:
Перейти:  
cron
POWERED_BY
Русская поддержка phpBB
[ Time : 0.076s | 80 Queries | GZIP : On ]