А accounting что мешает резервировать?

"access и accounting сервера стали автономными программами" для балансировки нагрузки...

и в отличие от freeradius наши реализации кроме "тупого" логирования и проверки прав доступа занимаются управлением оборудованием и тарификацией

и хотелось бы понять от каких ситуаций вы хотите защититься с помощью резервирования...

"access и accounting сервера стали автономными программами" для балансировки нагрузки...

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

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

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

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

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

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



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

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

1) разнесение программы по разным серверам - это один из видов балансировки

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

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

Вот что бы уточнить уточнение:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

skn, правильно ли я понял, что:

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

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

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

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

2 access сервера работать, должны . Они делались с расчетом на это.. Другой вопрос, что мы это специально не тестировали изначально.
Но есть люди, которые реально запустили такие схемы, вылезло пару багов, их справили и схемы работают.

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