Конфигурация отказоустойчивости LDAP (например, SunOne)

Question

Конфигурация отказоустойчивости LDAP (например, SunOne): знает ли anyboby, как настроить отказоустойчивость для LDAP, например, SunOne LDAP.

Я ищу через Google без каких-либо пользовательских результатов?

Спасибо

Answer 1

Предполагая, что под "отказоустойчивостью" подразумевается "высокая доступность (HA)", я бы сказал, что это может быть достигнуто за счет избыточности. И это не будет свойственно SunOne или любому программному обеспечению сервера каталогов от других поставщиков.

Есть разные способы решить эту проблему. Это зависит от бизнес-требований и доступности. Один метод, который приходит на ум, - это установить программное обеспечение LDAP на пару HA. Для этого требуется аппаратное обеспечение и возможности ОС для отработки отказа, а также два сервера (в мире виртуализации "сервер" может означать разные вещи (физический блок, фрейм, LPAR и т. Д.); Поэтому я просто оставлю интерпретацию читателю). В случае отказа одного сервера другой сервер вступает во владение и принимает на себя основную роль в паре. Это отказоустойчивая часть. При таком подходе машина / сервер с вторичной ролью пассивна (т. Е. Не обслуживает клиентов) до тех пор, пока первичный сервер не выйдет из строя. Вам нужно будет реализовать репликацию данных LDAP между двумя серверами. Они могут быть двумя мастерами LDAP в топологии репликации P2P.

Другой метод состоит в том, чтобы иметь несколько серверов LDAP (т. Е. Мастеров, реплик) и кластеризовать их, используя программное обеспечение сетевого устройства (ND) /appliance/ и т. Д., Которое будет распределять входящий трафик по отдельным серверам (обычно репликам) в кластере. Если вы потеряете одну реплику в кластере, ND не будет отправлять трафик этой реплике, пока она не вернется. Однако другие реплики будут по-прежнему получать нагрузку и, следовательно, обслуживать входящий трафик. Это отказоустойчивая часть в этом методе. Степень доступности, которую вы хотите, также будет определять то, что можно сделать в кластерной среде. У вас может быть один мастер LDAP (к которому приложения организации будут вносить обновления) и держать его вне кластера, но связать его с другим сервером для переключения при сбое (так что вы не потеряете доступность обновлений из приложений - это также дает вам свободу проводить техническое обслуживание на главном устройстве, не прерывая ваши приложения [ну, они должны быть записаны, чтобы иметь возможность записи на более чем одно ведущее устройство LDAP, если основной не доступен]). В любом случае вам потребуется вторичный сервер для получения репликации с первичного сервера. Если бюджет не позволяет вам иметь больше серверов / реплик, то вы можете разместить главный сервер вместе с репликами в кластере, чтобы помочь с трафиком чтения. Вместо HA-пары, в которой один из серверов будет пассивным, вы можете настроить два мастера в топологии репликации P2P и использовать их обоих в кластере для поддержки трафика. Существуют разные способы приближения к этому методу в зависимости от требуемого уровня избыточности или того, что может быть предоставлено.