Около 1 года мы используем openldap на ubuntu сервер 10.04LTS для аутентификации около 20 ИТ-пользователей, и все работает нормально (операции на сервере LDAP были в основном ограничены созданием / удалением пользователей с помощью Студия каталогов apache).
Совсем недавно (6 месяцев назад) мы также начали внедрять openldap (openldap-2.4.21 / debian) в качестве внешней системы аутентификации для нашего веб-сайта, который переносится с внешней CMS на новую платформу, которую мы разрабатываем собственными силами. Drupal CMS. У нас есть база данных на 45 тыс. Пользователей, и все идет не так гладко. У нас были следующие проблемы:
-ldap аварийно завершает работу после восстановления из резервной копии, требуется восстановление.
-инструмент восстановления ldap не может восстановить базу данных ldap в некоторых случаях
-slapd потребляет 100% ЦП при отсутствии активности аутентификации на веб-сайте.
Из-за нехватки внутренних ресурсов и знаний все, что мы сделали до сих пор, - это найти способы поддерживать работу LDAP, не исследуя ни одну из этих проблем (используйте monit перезапустить его, когда он выйдет из строя, db_recover для восстановления БД, если необходимо, и slapcat чтобы воссоздать базу данных с нуля, когда db_recover не удается).
Недавно мы провели серию собеседований, чтобы нанять старшего инженера по инфраструктуре, который помог бы нам со всеми различными инфраструктурными решениями. проблемы, с которыми мы сталкиваемся. Несколько кандидатов подтвердили, что они либо сталкивались, либо слышали о проблемах с openldap в больших производственных средах, и никогда не удавалось создать единую стабильную автономную openldap server, но вместо этого пришлось придумать избыточные развертывания (репликация, балансировка нагрузки, процедуры автоматического восстановления / перезапуска), чтобы поддерживать работу ldap. Некоторые кандидаты даже сказали, что openldap просто не подходил для производственной среды, и вместо этого использовались альтернативы, такие как Novel eDirectory было необходимо.
В: Если у вас есть опыт работы с ldap в производственных средах с тысячами пользователей, есть ли у вас факты, которыми можно поделиться, которые, как правило, доказывают, что openldap действительно нестабилен для таких настроек и действительно рекомендуется использовать другие серверы ldap?
Я использую OpenLDAP, поддерживающий около 10 000 активных пользователей, которые полагаются на него в течение дня во всем. Проблемы бывают редко. Многие службы полагаются на него для аутентификации и других вещей.
Однако у нас есть 4 реплики только для чтения (подчиненные устройства / потребители) за балансировщиком нагрузки, скрытый мастер и главный сервер горячего резерва. Раньше было 2 интерфейсных сервера, но у нас были проблемы с загрузкой в определенные периоды пиковой нагрузки (когда около 4000 из этих пользователей отчаянно пытались задействовать его в ту же секунду). Доступ на запись в LDAP осуществляется через наш код.
Это оборудование и ОС старые, и мы работаем над заменой их новой установкой, которая вернется только к 2 репликам (которые не делают столько других вещей) и репликации "зеркального режима" между парой мастеров в конфигурация высокой доступности. Опять же, проблемы бывают редко.
Раньше у нас были проблемы с ошибкой репликации, но в основном это связано с тем, что мы использовали slurpd вместо syncrepl. Кроме того, нечистые отключения сервера могут повредить данные.
По моему опыту, ключи к запуску OpenLDAP в крупномасштабной производственной среде:
Дополнение: По запросу DB_CONFIG из моего каталога БД openldap. смотреть на http://docs.oracle.com/cd/E17076_02/html/api_reference/C/configuration_reference.html для подробностей.
set_cachesize 0 536870912 1
set_flags DB_TXN_NOSYNC
set_flags DB_TXN_WRITE_NOSYNC
set_lg_regionmax 268435456
set_lg_max 536870912
set_lg_bsize 134217728