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

[Vladimir Romanov <vromanov@xxxxxxxxx>]

селектить надо тк лдапов несколько. точнее несколько пар. каждая пара
обслуживает свою часть пользователей. вот и приходится сначала понять
к какому лдапу обращаться. сейчас таких пар 6 штук. будет больше.

On 1/17/10, Deomid Ryabkov <myself@xxxxxxxxxxx> wrote:
> Vladimir Romanov wrote:
>>> ничем принипиально не отличается от проверки юзера/пароля.
>>> не забудьте выдать пользователю куку, чтоб в следующий раз
>>> не нужно было ходить в медленный лдап.
>>>
>> Это конечно! Это уже сделано. Сделал как модуль авторизации nginx.
>> Сейчас почти готов прототип отдельного процесаа который шлет запросы к
>> LDAP (на С)
>>
>>>> нагрузка будет весьма велика. Вешать авторизацию на бакенд нельзя.  В
>>>> случе чего, он сдохнет под нагрузкой.
>>>>
>>>>
>>> в том и смысл, что нагрузка на авторизацию будет ровно такая, какую вы
>>> скажете.
>>>
>> На авторизацию да. Но надо будет сначал принять решение авторизовать
>> или сразу послать. А для принятия такого решения надо как минимуму
>> делать селект в базе.
> зачем? чего селектить будем?
> если ваш лдап держит N запросов в секунду, вы настраиваете ваш авторизатор
> на то чтоб он засылал в среднем не более N в секунду, с каким-нибудь
> усреднением.
> если у вас их таких несколько на один лдап - зависит от того как будет
> распределяться нагрузка,
> если поровну, то всем поставить N/m, если нет, то приблизительно.
> и главное, чтоб авторизатор понимал, когда лдапу плохо и слал народ лесом.
> то есть, например, когда лдап начинает прогибаться, наверняка растёт
> время ответа.
> ну вот пусть авторизатору будет выставлен порог, а лучше интервал, или
> зависимость числа допущенных
> запросов от времени ответа.
> в общем, масса вариантов как не положить лдап без базы и координации
> между клиентами.
>>  Что при большом количестве "неокученых"
>> пользователей приведет к большой загрузке.
>>
>>
>>> авторизатор принимает бытрое рещение - можно ещё запрос отправить лдапу
>>> или
>>> нет.
>>> если можно - отправляет, проверяет, даёт куку. нельзя - даёт отлуп юзеру,
>>> чтоб пришёл попозже.
>>>
>> Вот принятие этого решения тоже дорогая операция и выносить в бакенд,
>> например на php не хочется.
>>
> как я уже описал, возможно не такая и дорогая, пара математических операций.
> но всё равно её надо отдать тому, кто будет делать авторизацию, то есть
> как ни крути бэкенду.
>
>>>>  Есть еще один момент - это
>>>> кластеризация. Саму вебчасть можно спокойно кластеризовать используя
>>>> репликацию DB. А вот релизовтаь ограничения по количесву обращений к
>>>> LDAP в таком кластере  будет сложнее.
>>>>
>>> надо сказать, что лдап тоже умеет реплицироваться. может вам не парить
>>> мозг,
>>> а просто обеспечить требуемую нагрузочную способность лдапа с помощью
>>> репликации?
>>>
>> Этот LDAP не может :(. Со временем будет другой интерфейс.
>>
>>>>  Эту часть лучше оформить в виде
>>>> active/stand bay пары
>>>>
>>> тут я не понял.
>>>
>> т.е. два сервера. Один работает, второй проверяет рабоает ли первый.
>> Как только первый останавливается за заботу принимается первый.
>>
> я понял что это значит, но не понял при чём это здесь.
> наличие неактивного stand by не влияет на нагрузку.
>
> --
> Deomid "rojer" Ryabkov
> myself@xxxxxxxxxxx
> rojer@xxxxxxxxxxxx
> ICQ: 8025844
>
>


-- 
Vladimir Romanov
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru