Когда наш сервер OpenLDAP потерял питание, консоль машины CentOS стала практически непригодной для использования.
Мы пытались войти в систему с локальной учетной записью, но для возврата каждой команды требовалось несколько минут. Даже простые команды вроде ls просто сидели там.
Это не похоже на проблему с той же конфигурацией под Ubuntu. Для успешного первоначального входа в систему для локальной учетной записи требуется некоторое время, но как только вы вошли, все работает.
Я ищу способ смягчить проблему и придумал несколько идей:
Есть ли лучшие решения для управления резервированием / переключением при отказе с помощью LDAP?
У вас есть несколько вариантов.
Мы используем репликацию, чтобы иметь несколько серверов LDAP в сети, скрытых за балансировщиком нагрузки, поэтому, если один из них выйдет из строя, он останется доступным. Мы используем keepalived для балансировки нагрузки. Вы также можете использовать keepalived в настройке аварийного переключения, где у вас есть горячее резервное ведомое устройство.
Во-вторых, у вас может быть локальный сервер LDAP на каждой рабочей станции, но это приведет к серьезной головной боли в обслуживании, так как вам необходимо администрировать все это и контролировать их, чтобы убедиться, что они не отстают от репликации. Вы же не хотите, чтобы они рассинхронизировались.
Если у вас есть подчиненный сервер, убедитесь, что вы установили параметр updateref, чтобы любые попытки обновления отправлялись на главный сервер.
В /etc/ldap.conf есть несколько настроек, которые можно использовать для улучшения ситуации. Самый важный из них:
bind_policy soft
По умолчанию установлено «жесткое», при котором будут повторяться попытки связаться с сервером с промежуточным ожиданием. Если вы установите его на мягкий, он немедленно вернется. Вы также можете использовать параметры тайм-аута, чтобы сократить время ожидания.
# Search timelimit
timelimit 30
# Bind/connect timelimit
bind_timelimit 30
Я знаю, что у вас есть принятый ответ от Дэвида, но я хотел бы предложить здесь другой подход и поделиться своим опытом.
Я обнаружил проблему с использованием bind_policy soft заключается в том, что если вы не получите ответ от сервера сразу, скажем, например, он занят или у вас высокая нагрузка на сеть, вы сразу получите сбой LDAP. Для nss_ldap это означает, что поиск по nss завершится неудачно, и какой бы процесс ни пытался его использовать, он просто сообщит, что не смог найти пользователя или группу, которую искал, и завершится ошибкой. Это может быть проблемой во время нормальной работы, когда ваш сервер LDAP включен, что IMO хуже, чем проблемы, когда ваш сервер не работает.
Я нашел более приемлемое решение, используя следующие настройки:
bind_policy hard
nss_reconnect_tries 3
nss_reconnect_sleeptime 1
nss_reconnect_maxsleeptime 8
nss_reconnect_maxconntries 2
Таким образом, у вас по-прежнему будет политика жесткого подключения, но nss_reconnect_* настройки значительно сократят время, которое ваш клиент LDAP будет тратить на попытки получить результат LDAP. Это также означает, что при нормальном использовании, если он не может получить результат LDAP с первой попытки, он попытается снова и обычно получит его во второй раз. Это означает меньшее количество отказов при нормальном использовании.
Что касается запуска локального сервера LDAP на каждой рабочей станции, я этого не рекомендую. Вместо этого я могу указать вам на nsscache. Он был написан некоторыми инженерами Google и решает эту проблему, создавая локальный кеш базы данных LDAP и постепенно обновляя его с помощью задания cron. Затем вы настраиваете свой источник nsswitch на использование их библиотеки вместо nss_ldap, и все поиски являются локальными. Это имеет то преимущество, что значительно снижает нагрузку на ваш сервер LDAP и делает доступными все поиски, если соединение с сервером не работает. На данный момент у него нет лучшей документации и он не широко используется, но он действительно хорошо работает, и списки рассылки довольно отзывчивы.
У нас была эта проблема, и наше решение заключалось в том, чтобы указать LDAP не быть источником групп, необходимых для работы серверов. Для этого в конце нашего ldap.conf
# We need to ensure that various things can work without LDAP being available
# for example: booting, ssh in as root, apache ...
nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,daemon,dhcp,dhcpd,games,gdm,gnats,haldaemon,hplip,irc,klog,libuuid,list,lp,mail,man,messagebus,munin,mysql,nbd,news,ntp,nut,polkituser,proxy,pulse,root,sshd,statd,sync,sys,syslog,uucp,www-data
Из страница руководства nss_ldap
nss_initgroups_ignoreusers <user1,user2,...,userN>
This option directs the nss_ldap implementation of initgroups(3)
to return NSS_STATUS_NOTFOUND if called with a listed users as
its argument.
Таким образом, в основном LDAP делает вид, что не знает этих пользователей, даже не связываясь с главным сервером, поэтому NSS возвращается к локальным пользователям, и система работает нормально.
Мы также установили реплики LDAP на нескольких серверах для использования ремня и скоб.