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

[Deomid Ryabkov]

Vladimir Romanov wrote:
> селектить надо тк лдапов несколько. точнее несколько пар. каждая пара
> обслуживает свою часть пользователей. вот и приходится сначала понять
> к какому лдапу обращаться. сейчас таких пар 6 штук. будет больше.
>   
пардон, а не в том ли смысл шардинга, чтоб убрать ту самую центральную базу,
которая всё знает и куда все ходят?
сделайте так, чтобы сервера однозначно выбирались на основании каких-то 
атрибутов входных данных.
айпишник у вас на входе? ну вот по нему и побейте.
> On 1/17/10, Deomid Ryabkov <myself at rojer.pp.ru> wrote:
>   
>> 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
>>
>>
>>     
>
>
>   


-- 
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/110485f9/attachment.bin>