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
