> > > 1. на местах (на езернете с NAS) стоят сервера аутентификации/авторизации,
> > > которые действуют по заранее строго определенному сценарию, обеспечивая
> > > технологический уровень dialup. Клиенты входят и работают.
> > > 2. в центре стоит сервер аккаунтинга, который коллектит поступающие
> > > от многочисленных NAS'ов acct-пакеты. Что-то там свое думает, и если
> > > что, срубает юзера с NAS'а по SNMP.
> > > Лучше всего пока что под решение такой задачи подходит радиус.
> > > Та его часть, что отвечает за авторизацию - стандартна.
> > > Часть аккаунтинга заменена на собственный глюкатор на acct-порту.
> > > Для этого даже radius патчить не придется, его acct-порт просто
> > > затыкается за ненадобностью.
> >
> > Как уже говорилось, есть довольно разумная потребность в кешировании
> > выделенных IP адресов. Для того, чтобы освобождать выделенный адресс
> > сервер аутентификации/авторизации (а не эккаунтинга) должен получить
> > STOP пакет.
> >
> Во-первых, кешировать IP адрес можно самим NAS. У циско это есть.
> Проблема тут может быть только одна - адрес кешируется только в пределах
> одного NAS. Т.е. нельзя ставить несколько NAS в одну серию.
> Плохо, но не смертельно.
> Во-вторых, в этом вопросе пока также нет готового стандартного и красивого
> решения, каждый изобретает свой велосипед по-новой. Или уже есть кстати?
Нет. По идеология cisco - адрес выделяет NAS.
> И кроме того, ничто не мешает acct-коллектору отрелеить/имитировать stop
> пакет куда сказано.
А чем это лучше ситуации, когда auth sending stop to acct?
> > Второе соображение, что потеря эккаунтинга, есть не менее огорчительное
> > явление, чем потеря авторизации, и очень хочеться иметь возможность
> > буфферизировать эккаунтиг около NAS'а.
> >
> Есть множество способов потерять аккаунтинг. На мой взгляд, потеря
> коннективности между NAS и учетным центром не является самой популярной
> причиной для этого.
Но бывает. Опять-же в случае единственного acct ситуация усугубляется.
> Также есть как минимум более одного способа "восстановления" сессии
> аккаунтинга. Полностью всю сессию можно потерять только если на всем
> ее протяжении отсутствовала коннективити, когда мы не поймали ни start,
> ни alive, ни stop. Да и в этом случае можно как-то извратиться, например
> небыло конективности больше часа, значит надо попарсить лог-файл сервера
> авторизации, это же должно быть крайне редко.
Ага, значит лог-файл все-таки есть и мы умеем его парсить? А ради чего
тогда все? Этот лог файл и является буффером. Бери из него в максимальном
темпе. Эффективная реализация tail описана много где. Зачем два механизма?
Чтобы глюки потом искать?
У тебя уже есть два надежных, простых, близких к NAS сервера, где ты
предлагаешь вести авторизацию. Отдай туда эккаунтинг и забирай/передавай
дальше. По любому протоколу.
> > Эти два тезиса рушат идилию. И мы сводим авторизацию и эккаунтинг
> > в одно место. Можно отказаться от кеширования и плюнуть на потерю
> > эккаунтинга. Но если это _требования_, то обойти их не удасться.
> >
> Отнюдь. Всегда найдутся некие workaround.
Мы сейчас говорим не про workaround'ы, которых всегда немало, а про general
architecture. Тут не может быть workaround'ов.
> К тому же, нужно четко представлять масштабы бедствия в случае не учета,
> переучета и тп. Например, что лучше, потерять сессию одного-двух клиентов
> или перманентно терять одну копейку на всех сессиях из-за кривизны
> дочитывания/синхронизации десятков лог-файлов на битых дисках по всей
> сети...
Лучше не терять ничего. А битые диски своевременно выкидывать. Описание
проблемы - явно натянутое.
> > > > А теперь представь себе обратный тарификатор, который живет в том-же
> > > > животе, но запускается в начале каждой сессии, чтобы из фантиков посчитать
> > > > timeout. Далее по тексту.
> > > >
> > > Зачем timeout? Мы как раз и уходим от него.
> >
> > Чтобы сшибать более плавно и снизить нагрузку.
> >
> > > Наверно могу более конкретно изложить, если интересно.
> >
> > Да я все понял. У меня сейчас работает примерно так, как ты описал.
> > Только я хочу идти дальше.
> >
> Мы говорим о реалтайме?
> Нет необходимости получать из фантиков timeout.
> Второе, сшибить нужно ровно тогда, когда у клиента кончилось время,
> желательно в ту же секунду.
> Как?
> В начале сессии клиента мы загружаем его текущий баланс, лучше если это
> сразу время в секундах (деньги еще на стоимост поделить и округлить
> придеться;),
Пойми, ситуация когда можно поделить и округлить пройдена нами 5 лет
назад. Уже с вводом ночного тарифа все становиться веселее, а с nightsurf+
еще веселее, а с weekend еще, а с multilink еще. Описанный тобой
алгоритм тарификации (ночью считаем 10 секунды за 5) не обеспечивает
достаточной точности расчетов и требует бессмысленных прерываний,
увеличивающих нагрузку на систему.
Просто какой-то натуральный счет по пальцам. Чтобы сложить 8 и 7
ты делаешь прибавление 7 единиц.
Поэтому я и говорю про обратный тарификатор, который переводит деньги в
секунды. Это сложный алгоритм. Но он есть и работает.
> взводим таймер чтоб прерывал нас каждые 10 сек, в каждом
Какие 10сек? Что за маразм? Таймер ставиться на столько секунд сколько
нужно для данного входа. И прерывает он нас - когда нужно. Опять-же
классическая реализация таймеров по книжке.
> прерывании отнимаем от остатка времени клиента 10 сек. (5 сек., 20 сек),
> попутно коллектим acct-пакеты, отрабатываем пропадания связи и пр.,
> когда результат <= 0 то срубаем его сессию, сохраняем остаток...
Что, вот так раз в 10 секунд, по всем 1000 линиям сравниваешь с 0?
> Таким образом мы "растягиваем" время ночью, "ускоряем" в час пик, следим
> за границами дозволенного времени, контроллируем мульти-логины, проверяем
> номер звонящего, "восстанавливаем" потеряные acct-пакеты и тд., и все это
> в одном демоночке, вместо кучи подпорок по всей цепи тарификации.
Я так и не понял какие там подпорки. Там все очень просто и легковесно.
А описанный тобой алгоритм у нас давно работает. (с учетом различий
алгоритма тарификации) Живет следящий демон, сшибающий по SNMP. Правда у
нас не 1000 линий, а 650, и не 10сек, а 5 мин., поэтому проблем пока нет.
Но будут. Именно поэтому мы подготовились к внедрению нормальных таймеров.
Предыдущее решение держиться пока на святом принципе админа -
"работает не трож".
Boris.
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
