BiTel

Как с этим обстоят дела в Inet?

Иными словами, можно ли задать для одного и того же корневого устройства >1 Access и/или Accounting - сервера?
Если да, то как это будет работать? Вернее, как это задумано разработчиками (если задумано)?
Как будет по факту - будем тестировать

[quote=Администратор]1) Единый модуль трафика. IPv6, ISG (и Juniper ERX), DHCP.82 + динамика и т.п. Резервирование шлюзов авторизации (RADIUS).[/quote]
viewtopic.php?p=32364#p32364

Вот ещё интересная темка:
viewtopic.php?f=44&t=8482

C accounting-серверами есть как миним 2 проблемы
1. Обработка логов
Сейчас тот, кто успеет забрать задачу , тот ее выполняет .Причем могут успеть забрать сразу оба, так вначале обрабатывают, потом удаляют задачу из базу. Если логов у accounting-а нет, то он просто удалит детализацию по всем сессиям.

2. Переобсчет . Тут такой алгоритм

Вначале запускается задача планировщика — назовем ее Координатор . Он берет опцию accounting.application.ids в конфигурации модуля . Этот список accounting-серверов. Потом каждому шлет событие - кто готов считать ? Если accounting отвечает , то он его запоминает в список . Если accounting.application.ids не указан, то планирощик просто шлет событие - кто первый ответит , того он и запоминает . В любом случае координатор на выходе получает список account-серверов ( 1 или более). После этого он делит договора между ними по остатку деления id договора на количество accounting серверров ( четные считает один, нечетные другой, если 2 accounting-а ). Далее идут варианта


a)Обсчет месяца в прошлом или дня в нем(если он указан).
Просто переобсчитвается месяц целиком , или день в нем .

б) Обсчет текущего месяца или дня в нем(если он указан). Процесс делится на этапы :

1) Координатор( задача execute-a) дает команду всем аккунтингам - Обсчет текущего месяца до вчерашенго дня включительно. Или просто перобсчет одного
дня в прошлом(если указан день в прошлом). При этом обсчет не совем полноценный, он обсчитывает только сессий(session_log), и наработку сессий(session_account),
детализацию счетчиков за конретные дни. Общую наработку по услугам и счеткичи, баланс он не обсчитвает.
Список затронутых договоров(которым нужно обсчитать услуги, счетчики и баланс) запоминается в каждом accounting-е Ответ - OK.

2) Координатор( задача execute-a) говорит всем аккунтингам - перестать обсчитывать и сбросить все(flush) , они отвечают - ok.

3) Обсчет текущего дня . При обсчете текущего дня мы делаем хитрые переобсчет, который сразу 2 таблицы правит : сессии закрытые , сессии текущие. После этого
Если для всех затронутых договоров, исключая те, котоых мы обсчитали в текущий день) из 1-го этапа обновляем наработку по услугам и счеткичи, баланс.
OK.

4) Координатор( задача execute-a) говорит - продолжайте считать runtime . OK.
Аккаунтинги перечитают данные и запускают тарификаторы.

При обсчете одного дня в прошлом обновляется delta этого дня. Если нужно пользователь сам обсчитывает следующие дни .

В общем процесс взаимодействия особенно при переобрабоке логов не доработан, нужно решить как будем делать.

up

Есть какие-то мысли?
Меня сейчас сетевики спрашивают, можно ли бэкапить radius-ы для access?

Access'ы, у которых один и тот же rootDeviceId, должны работать нормально.
И RADIUS получать, и DHCP (DHCP с фильтром по serverIdentifier в 6.0), и CoA/PoD/команды на коммутаторах выполнять.
Другое дело, что так еще никто не запускал, т.е. есть вероятность, что что-нибудь да вылезет.

Как это никто, мы же заказывали у вас этот функционал и у нас он работает, по крайней мере DHCP cluster функционирует нормально, за исключением вывода DHCP логов в интерфейсе мониторинга сессий.

Ну я же не знаю, что запустили уже
По поводу DHCP-логов - вчера нашли старую багу, из-за которой был неправильный вывод - логи выводились вроде бы только за тот день когда пришел первый для сессии DHCP-пакет.

UP!

Для BGInetAccess с Radius кто-нибудь такую схему пробовал?

Про 2 Access-сервера.
Попробовали сначала на тестовой ветке, а вчера запустили на малоиспользуемой ветке модуля Inet.
Вроде работает нормально.
Позже попробуем сделать для основной ветки.

Кромешник, а что именно сделали?
2 Access сервера, один из которых не активен, и если падает основной - то на второй переключаются запросы?
Или они оба активны, у обоих один и тот же rootDeviceId, и на них идут запросы от 2х и более NAS?

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Оба активны, могут принимать запросы от NAS-а, но NAS работает с 1-м, пока он не упадёт.
Как я понял, у BG логика такая: когда нужно послать CoA и т.п., в приоритете 1 сервер (у которого меньше id вроде). Если он не обрабатывает запрос - работает второй.

ps. Занимался другой сотрудник, больше подробностей не расскажу.

По поводу CoA - нет приоритета, вполне может и второй задачу забрать и выполнить.

Не стал создавать новую тему т.к. нашел эту аналогичную.
В ближайшее время собираемся переходить на BG. У нас в сети сотни коммутаторов, выполняющих роль NAS серверов, со всех них собирается трафик (ведется accounting) десятью netflow-агентами(источники данных). Причем трафик с одного NAS может посчитаться как одним агентом, так и другим, такая структура сети на сегодня, есть общие VLAN'ы. В связи с этим возник вопрос можно ли составить такое дерево устройств, в котором можно указать чтоб один и тот же NAS могли корректно считать различные netflow-агенты ?

Если проблема только в том что уже нас может быть несколько netflow-источников, то с этим нет проблем. Тут резервирование не причем .

Да, согласен резервирование не причем, наверное стоило создать отдельный топик. Stark, можешь подсказать, как все таки правильно должна выглядеть такая схема (конфигурация), в виде дерева?!