Re: Асинхронная авторизация

[Deomid Ryabkov]

Vladimir Romanov wrote:
>> ничем принипиально не отличается от проверки юзера/пароля.
>> не забудьте выдать пользователю куку, чтоб в следующий раз
>> не нужно было ходить в медленный лдап.
>>     
> Это конечно! Это уже сделано. Сделал как модуль авторизации nginx.
> Сейчас почти готов прототип отдельного процесаа который шлет запросы к
> LDAP (на С)
>   
>>> нагрузка будет весьма велика. Вешать авторизацию на бакенд нельзя.  В
>>> случе чего, он сдохнет под нагрузкой.
>>>
>>>       
>> в том и смысл, что нагрузка на авторизацию будет ровно такая, какую вы
>> скажете.
>>     
> На авторизацию да. Но надо будет сначал принять решение авторизовать
> или сразу послать. А для принятия такого решения надо как минимуму
> делать селект в базе.
зачем? чего селектить будем?
если ваш лдап держит N запросов в секунду, вы настраиваете ваш авторизатор
на то чтоб он засылал в среднем не более N в секунду, с каким-нибудь 
усреднением.
если у вас их таких несколько на один лдап - зависит от того как будет 
распределяться нагрузка,
если поровну, то всем поставить N/m, если нет, то приблизительно.
и главное, чтоб авторизатор понимал, когда лдапу плохо и слал народ лесом.
то есть, например, когда лдап начинает прогибаться, наверняка растёт 
время ответа.
ну вот пусть авторизатору будет выставлен порог, а лучше интервал, или 
зависимость числа допущенных
запросов от времени ответа.
в общем, масса вариантов как не положить лдап без базы и координации 
между клиентами.
>  Что при большом количестве "неокученых"
> пользователей приведет к большой загрузке.
>
>   
>> авторизатор принимает бытрое рещение - можно ещё запрос отправить лдапу или
>> нет.
>> если можно - отправляет, проверяет, даёт куку. нельзя - даёт отлуп юзеру,
>> чтоб пришёл попозже.
>>     
> Вот принятие этого решения тоже дорогая операция и выносить в бакенд,
> например на php не хочется.
>   
как я уже описал, возможно не такая и дорогая, пара математических операций.
но всё равно её надо отдать тому, кто будет делать авторизацию, то есть 
как ни крути бэкенду.

>>>  Есть еще один момент - это
>>> кластеризация. Саму вебчасть можно спокойно кластеризовать используя
>>> репликацию DB. А вот релизовтаь ограничения по количесву обращений к
>>> LDAP в таком кластере  будет сложнее.
>>>       
>> надо сказать, что лдап тоже умеет реплицироваться. может вам не парить мозг,
>> а просто обеспечить требуемую нагрузочную способность лдапа с помощью
>> репликации?
>>     
> Этот LDAP не может :(. Со временем будет другой интерфейс.
>   
>>>  Эту часть лучше оформить в виде
>>> active/stand bay пары
>>>       
>> тут я не понял.
>>     
> т.е. два сервера. Один работает, второй проверяет рабоает ли первый.
> Как только первый останавливается за заботу принимается первый.
>   
я понял что это значит, но не понял при чём это здесь.
наличие неактивного stand by не влияет на нагрузку.

-- 
Deomid "rojer" Ryabkov
myself at rojer.pp.ru
rojer at sysadmins.ru
ICQ: 8025844

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3308 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100117/314aa487/attachment.bin>