Workshop: LDAP skalieren

Die Praxis zeigt: Es ist nichts Schlechtes daran, dass Verzeichnisdienste wie LDAP fast so alt wie manche Baumriesen sind, genauer: auf den X.500-Standard der ITU-T (International Telecommunication Union) zurückgehen. Denn LDAP profitiert vom hohen Reifegrad des Konzepts und der Implementierungen, was bei Infrastruktur-Software wichtiger ist als hippe Features. Selbst Microsofts vergleichsweise junges Active Directory fußt auf LDAP.

Dieser Workshop vermittelt keine Grundlagen wie [1] und [2], sondern will zeigen, was Sie tun können, um einen Single Point of Failure bei LDAP zu vermeiden und Performance-Engpässe auf dem zentralen LDAP-Server zu bekämpfen. Er zeigt, wie Sie Redundanzen schaffen oder Außenstellen der Firma mit einem LDAP-Spiegel versorgen. Das geht naturgemäß mit den Themen Replikation und Synchronisation Hand in Hand und passt bestens zum Titelthema dieser Ausgabe.

Zum Szenario: Wer die IT einer Außenstelle mit Anmeldediensten zu versorgen hat, kämpft damit, dass der zentrale Anmeldedienst kilometerweit entfernt in der Firmenzentrale steht. Dabei laufen sämtliche Daten über eine WAN-Leitung mit ihren hohen Latenzzeiten. Wenn sich morgens dann der ganze Mitarbeiterstamm innerhalb weniger Minuten anmeldet - dann guten Morgen. Sind die IT-Verantwortlichen vor Ort keine Experten, rufen sie in der Situation gern einen Berater in Haus, der es richten soll - mit diesem Workshop vertraut, könnten das Sie sein.

LDAP als lokaler Service mit Verzweigungen

Sofern der Anmeldedienst aus Open-Source-Komponenten, also auch aus OpenLDAP besteht, ist das gar kein gravierendes Problem, sondern eher eine Fleißaufgabe. Die Lösung heißt Slurpd (Stand-alone LDAP Update Replication Daemon) und ist der weitere Dienst, den Sie zusätzlich zum LDAP-Serverdienst Slapd auf dem Masterserver betreiben werden. Er spielt die zentralen Rolle, wenn es um die Replikation von Daten im Verzeichnisbaum geht.

In einer Grund- und Basiskonfiguration behandelt Slapd, der Stand-alone LDAP-Daemon, alle Anfragen beziehungsweise Queries einer Domäne. Den darunter liegenden Baum behandelt ein zentraler Server, es findet keinerlei Interaktion zu anderen Verzeichnisdiensten statt. Diese Konfiguration ist nur in kleinen Umgebungen sinnvoll. Kommt nun eine weitere Umgebung hinzu, brauchen Sie nicht unbedingt die Replikation als Verbindungsglied. X.500 sieht die Verzweigung und Verbindung von weiteren Verzeichnissen mittels Referrals vor.

Vereinfacht gesagt, darf man sich dieses wie einen Uniform Resource Locator (URL) vorstellen. Wenn der Baum am Ende seines Lateins angelangt ist und der Benutzer etwas in einem Zweig sucht, was irgendwo anders auf der Welt liegt, teilt der Verzeichnisdienst einen Link mit. Der Client löst nun automatisch den Verweis auf und fordert die gesuchten Informationen an, schematisch zu sehen in Abbildung 1. Die Technik eines Referral dient zwar im Single-Master-Modus zur Verzweigung auf andere Verzeichnisdienste, stellt aber auch ein wesentliches Element im verteilten Szenario mit redundanten Servern dar.

Abbildung 1: Wenn ein LDAP-Baum die angeforderte Information nicht vorrätig hat, teilt der Verzeichnisdienst einen Referral-Link mit. Der Client fordert damit die gesuchten Informationen von anderer Stelle ein.

Ein großer Dienst am Objekt

In größeren Organisationen erlauben die IT-Budgets meist einen zentralen Anmeldeserver. So auch im folgenden Beispiel: Sie sind also ein optimistischer Jung-Consultant und erhalten den Auftrag, einen Verzeichnisdienst für das Unternehmen Hxchaos aufzubauen. Und damit es nicht im selbst verursachten Chaos versinkt, arbeiten Sie in das Design bereits eine verteilte Umgebung ein. Das Ziel der ganzen Mühe ist es, das verzweigte Unternehmen mit zwei Außenstellen zu versorgen.

Aus Erfahrung wissen Sie bereits, dass das Design der Verzeichnisstruktur elementar ist. Nach endlosen Diskussionen mit Managern über die Namensgebung darf es losgehen: Sie strecken den Baum »dc=hxchaos,dc=local« von einem Master- auf zwei Slave-Server. Den daraus resultierenden Netzwerkaufbau zeigt Abbildung 2.

Abbildung 2: Das vorgestellte LDAP-Setup mit drei Servern, einem Master und zwei Slaves. Die Lastverteilung und die Failover-Funktion ist recht einfach über einen gemeinsamen DNS-Eintrag realisierbar.

Nachdem Sie Ihr Netzwerkdiagramm fertiggestellt haben, installieren Sie auf dem Master »idefix.hxchaos.local« den Slapd-Dienst und konfigurieren ihn wie in einem lokalen Szenario. Hier ist nicht viel zu tun. Sie legen den Distinguished Name des Admin fest, vergeben ein Kennwort und bauen Basisobjekte für den Verzeichnisdienst auf. Den Slapd als Binärpaket zu installieren oder aus den Sourcen zu kompilieren gelingt normalerweise auf Anhieb und soll darum hier keinen Platz verschwenden.

Wichtig sind allerdings die Parameter, die Sie in der Default-»slapd.conf« anzupassen haben, das Basis-Suffix des Verzeichnisdienstes und den Root-DN des Verzeichnisdienstes beziehungsweise den administrativen Account für OpenLDAP:

suffix       "dc=hxchaos,dc=local"
rootdn       "cn=admin,dc=hxchaos,dc=local"

Abschließend vergeben Sie noch ein Kennwort für den Root-DN.