Am Samstag 18 September 2010, 20:58:45 schrieb Heiko Schlittermann:
Das müsstes Du mal bitte besser erklären. Backup impliziert noch kein HA.
Das war auch nicht als HA gemeint. Vielmehr können die per ldapsearch oder slapcat entstehenden ASCII-Dateien sehr schön gesichert/versioniert/wasauchimmer und für LDAP-Migrationen oder im DisasterRecovery-Fall zum Neuaufsetzen des/der LDAP-Provider-Server genutzt werden. Die Konfigurationsdateien (/etc/openldap/...) liegen ja sowieso in einem Versionskontrollsystem, oder? ;-)
Und wo LDAP HA by Design ist, kann ich auch nicht erkennen.
s.u.
Du brauchst Master und Slaves und eine gescheite Replikation - die Openldap bietet. Aber das hat mit LDAP an sich nichts zu tun, denke ich.
s/master/provider/g s/slave/consumer/g Das Ganze heißt bei OpenLDAP syncrepl, ist in rfc4533 spezifiziert und funktioniert hier(TM) in einer größeren, weltweiten Produktivumgebung ohne Probleme. slurpd (das wo der Master per push die Slaves zu aktualisieren versucht) ist abgekündigt und zumindestens im Debian 5 auch nicht mehr dabei.
Und Du must den Clients beibringen, daß es nicht nur einen LDAP-Server gibt und daß sie im Notfall mehrere probieren sollen
Genau das ist es: Die Clienten haben immer _mindestens_ zwei LDAP-Server konfiguriert, die abgefragt werden können. Ausfall von LDAP-Servern haben keinen Einfluß auf die ordnungsgemäße Funktion der Clients, solange davon mindestens ein LDAP-Server erreichbar ist und antwortet. Desweiteren wird so die Last (=LDAP-Abfragen) auf alle konfigurierte LDAP-Server verteilt, was in größeren Umgebungen von Vorteil ist.
, oder zu Krücken wie DNS-Round-Robin greifen (was wieder mit HA nichts zu tun hat, außer Du änderst die DNS-Einträge je nach Situation) …
Das will man nicht wirklich und braucht es bei LDAP auch nicht.