ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: Inet-Admins
Inet-Admins mailing list archive (inet-admins@info.east.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [inet-admins] =?KOI8-R?Q?=D3=C5=D2=D4=C9=C6=C9=CB=C1=C3=C9=D1?= =?KOI8-R?Q?_=C2=C9=CC=CC=C9=CE=C7=CF=D7=CF=CA?= =?KOI8-R?Q?_=D3=C9=D3=D4=C5=CD=D9?=



> > > 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 http://info.east.ru/rus/inetadm.html



 




Copyright © Lexa Software, 1996-2009.