LDAP – Howto: StandbyMaster / Multi-Master

Im folgenden Blogeintrag moechte ich beschreiben, wie man eine einfache LDAP-StandbyMaster bzw. Multi-Master Loesung implementiert. Das Ziel ist, dass sich zwei LDAP-Server permanent gegeneinander replizieren so dass im Bedarfsfall der StandbyMaster die Funktionen des Masters transparent uebernimmt, ohne das angeschlossene Dienste davon etwas mitbekommen.

All mein Wissen was ich hier beschreibe habe ich aus dem wirklich tollen Buch OpenLDAP 2.4 – Das Praxisbuch, sowie den Quellen die, wenn man sie nicht beachtet, normalerweise mit der Aussage „RTFM“ gemeint sind. Das Buch kann ich nur jedem ans Herz legen, der sein Wissen ueber LDAP erweitern und auf eine feste Grundlage stellen moechte. Es ist hervorragend geschrieben, leicht verstaendlich, und bietet gute Praxisbeispiele.

Die Umgebung in der ich arbeite ist Debian Lenny 32bit. Es handelt sich bei beiden LDAP-Servern um mit KVM virtualisierte Maschinen auf zwei unterschiedlichen physikalischen Servern. Alle Konfigurationseinstellungen, Pfade etc. beziehen sich auf die beiden genannten Systeme.

Replikation vs. Spiegelung / Warum die Zeit?

Vorneweg moechte ich kurz aus dem Buch zitieren um den Hintergrund des kommenden besser Verstaendlich zu machen. Das Kapitel heist treffenderweise: „Replikation – oder: Frag dich nie, ob ein Server ausfaellt, frag dich immer nur, wann.“ (Kapitel 3.2, Seite 143). Dieser Satz alleine drueckt glaube ich gut aus, warum man sich im Zusammenhang mit LDAP mit Replikation beschaeftigen muss.
Nun ist es noch interessant den Unterschied zwischen Replikation und Spiegelung zu kennen. Das Buch erklaert dieses in meinen Augen sehr gut, deswegen zitiere ich hier aus Kapitel 3.2.1 Seite 146f:

„Bei einer Spiegelung werden die Daten einfach ungeprueft ‚parallel‘ in einen Datenbestand geschrieben (z.B. RAID Level 1-Spiegelung auf zwei oder mehr Disks).
Bei einer Replikation werden die uebermittelten Daten zunaechst lokal erfasst und die Timestamps/CSNs(Session-Cookies der betreffenden Objekte auf den beiteiligten Servern miteinander verglichen. Liegt dann eine berechtigte Replikations-Anfrage vor, wird sie durchgefuehrt und das replizierte Objekt mit einem neuen, aktuellen Timestamp/CSN verstehen. […] werden nur die Daten aktualisiert, die auch aktualisiert werden muessen, was wiederum die Performance erhoeht und das Netz weitaus weniger belastet als eine komplette Datenbanksynchronisation.

[…] Datenbankoperationen sind zeitsensibel, fuer die Replikation von Datenbanken gilt dies in besonderer Weise. (Deswegen) muessen wir […] auf allen angeschlossenen Servern die Zeit sehr genau synchronisieren.“

Einrichten zweier virtueller Maschinen mit fast exakt gleicher Zeit

Im Buch wird dieser Punkt im Kapitel 3.2.4 behandelt und sehr gut erklaert.
Mit dem Hintergrund der oben genannten Zitate erstellen wir nun zwei virtuelle Maschinen. Wie das im einzelnen mit KVM geht setze ich hier jetzt mal als bekannt vorraus, bei Fragen ueber die Kommentare melden. Die Maschinen richten wir erst einmal ganz Standard ein. Wenn dieses geschehen ist, geht es nun an die Aufgabe die Zeit auf beiden Maschinen moeglichst synchron zu bekommen. Das Mittel der Wahl dazu ist NTP. Ich habe auf einem weiteren Server einen NTP-Serverdienst laufen. Gegen diesen werden die beiden Maschinen Ihre Zeit abgleichen. Entsprechend ist darauf zu achten, dass auf dem Server der Zugang fuer Port 123 UDP in der Firewall offen ist. Bei dem NTP-Server kann man einfach ein

aptitude install ntp

machen und mit den Standardeinstellungen uebernehmen.
Auf den beiden Servern wird mit dem gleichen Befehl ebenfalls NTP installiert. Hier werden nun aber in der /etc/ntp.conf die vier Standardeintraege wie folgt auskommentiert:

#server 0.debian.pool.ntp.org iburst dynamic
#server 1.debian.pool.ntp.org iburst dynamic
#server 2.debian.pool.ntp.org iburst dynamic
#server 3.debian.pool.ntp.org iburst dynamic

und diese Zeile hinzugefuegt, wobei 123.123.123.123 natuerlich gegen die IP-Adresse ausgetauscht werden muss, auf der der NTP-Server laeuft:

 server 123.123.123.123 minpoll 4 maxpoll 10

Der Teil „server 123.123.123.123“ gibt an mit welchen NTP-Server die Zeit synchronisiert werden soll. „Die zusaetzlichen Parameter minpoll und maxpoll steuern dabei, wie oft sich der lokale ntp-Dienst mit der externen Quelle synchronisiert. minpoll gibt dabei das Intervall an, das maximal zwischen zwei Versuchen verstreicht, wenn die externe Zeitquelle nicht erreichbar ist. maxpoll gibt den Wert an, nach dem sich der lokale ntp-Dienst in jedem Fall erneut mit der externen Zeitquelle resynchronisiert.“ (Kapitel 3.2.4,  Seite 167, Absatz 2).

Das beide Server sich dann nach einem Neustart der Dienste mit unserem gemeinsamen NTP-Server abgleichen kann man mit dem Befehl

 ntpq -p

ueberpruefen.
Wichtig ist nun, den dort angegebenen offset Wert moeglichst gleich zubekommen. Es ist OK, wenn sich dieser einige Millisekunden im positiven oder negativen befindet, jedoch sollte er moeglichst konstant auf beiden Maschinen annaehernd gleich sein. Ich persoenlich war mit einer Offsetdifferenz <0,5 zufrieden und alles laeuft stabil.
Im Buch gibt es nun einen Exkurs darueber wie sich auf einem Computer die Uhrzeit bestimmt, es geht um Interrupt-Timer und dessen Herzzahl usw. Ich moechte an dieser Stelle nur sagen, dass ich die folgenden Kernelbootoptionen in grub hinzugefuegt habe um das Zeitverhalten in den Maschinen zu stabilisieren:

 clocksource=kvm-clock noapic nolapic nosmp acpi=off

Vorbereiten der LDAP-Dienste

Als naechsten Schritt geht es an das vorbereiten der LDAP Dienste auf beiden Servern. Dafuer muss als erstes auf beiden Servern der entsprechende Dienst installiert werden:

 aptitude install slapd

Anschliessend beginnen wir auf unserem zukuenfrigen Master-LDAP mit der Einrichtung. Wenn wir damit fertig sind, kopieren wir die /etc/ldap/slapd.conf 1:1 auf unseren zukuenftigen Standby-Master um Fehlerquellen auszuschliessen. Ich habe beispielsweise folgende Aenderungen vorgenommen:

• Samba-Schema hinzugefuegt:

aptitude install samba-doc
zcat /usr/share/doc/samba-doc/examples/LDAP/samba.schema.gz >> /etc/ldap/schema/samba.schema
echo "include         /etc/ldap/schema/samba.schema" | cat - /etc/ldap/slapd.conf > /tmp/slapd.out && mv /tmp/slapd.out /etc/ldap/slapd.conf

• Unnoetige root-acls entfernt:

by dn="@ADMIN@" write

• Oder einige index Optionen gesetzt:

index sambaSID                  eq
index sambaPrimaryGroupSID      eq
index sambaDomainName           eqindex uniqueMember              eq
index entryUUID,entryCSN        eq

Vorbereiten fuer die Synchronisation

Wenn wir den LDAP soweit fertig eingerichtet haben fehlen nun nur noch die Einstellungen die fuer die Replikation noetig sind.
Als erstes muss jeder LDAP-Server im Netzwerk eindeutig identifizierbar sein, in unserem Fall sind es zwei. Dafuer fuegen wir in der /etc/ldap/slapd.conf (z.B. vor der Backend Definition) die folgenden zwei Zeilen ein:

ServerID        1       "ldap://ldapmaster.mydomain.de"
ServerID        2       "ldap://ldapstandbymaster.mydomain.de"

Wichtig ist hierbei den DNS Namen zu nehmen und NICHT die IP-Adresse. Dieser kleine aber entscheidende Unterschied hat mich fast einen ganzen Arbeitstag gekostet, bis ich ueber diese Mail den entscheidenden Hinweis bekommen habe.
Um sicherzugehen das die Namensaufloesung auch immer funktioniert habe ich noch fix die entsprechenden Eintraege in die /etc/hosts gepackt:

echo "123.123.123.124	ldapmaster.mydomain.de		ldapmaster" >> /etc/hosts
echo "123.123.123.125	ldapstandbymaster.mydomain.de	ldapstandmymaster" >> /etc/hosts

Dann brauchen wir als naechstes das syncprov Overlay. Dafuer muss erst das entsprechende Modul geladen werden. Dafuer fuegen wir am Anfang der Konfigurationsdatei wo bereits der Modulpfad und das Modul back_hdb geladen werden danach die folgende Zeile ein:

moduleload      syncprov

Zu guter letzt muessen wir nun die Optionen zur Synchronisierung bzw. Replikation definieren. Dieses tun wir hier auf eine sehr einfache Art- und Weise. Hier nun erst einmal die Definition, die Erklaerung kommt dann danach. Achtung: sie muss nach der Definition des Backends stehen und auch fuer jedes Backend – wenn z.B. die Moeglichkeit der Online Konfiguration genutzt wird – neu definiert werden.

overlay         syncprov
syncprov-checkpoint    10 1
syncprov-sessionlog     100
 
syncrepl        rid=1
                provider="ldap://123.123.123.124"
                type=refreshAndPersist
                schemachecking=on
                retry="5 10 30 +"
                searchbase="dc=mydomain,dc=de"
                bindmethod=simple
                binddn="cn=admin,dc=mydomain,dc=de"
                credentials="mypass"
 
syncrepl        rid=2
                provider="ldap://123.123.123.125"
                type=refreshAndPersist
                schemachecking=on
                retry="5 10 30 +"
                searchbase="dc=mydomain,dc=de"
                bindmethod=simple
                binddn="cn=admin,dc=mydomain,dc=de"
                credentials="mypass"
 
MirrorMode on

Als erstes: Es gibt auch man slapo-syncprov ;-)

• overlay syncprov: Definition des syncprov Overlays das fuer das syncrepl-Verfahren benoetigt wird
• syncprov-checkpoint 10 1: Struktur: syncprov-checkpoint <ops> <minutes> ; legt fest nach wie vielen Eintraegen bzw. nach wie vielen Minuten der contextCSN (Change Sequence Number) ueberprueft werden soll. Es wird repliziert, sobald eine der beiden Optionen eintritt.(vgl.)
• syncprov-sessionlog 100: Definiert die Groesse des Sessionlogs im Speicher (nicht auf der Platte), wobei der Wert nicht die Groesse des Speichers, sondern die Anzahl der Eintraege definiert.
• syncrepl: Aktivierung der syncrepl Engine
• rid=1: Eindeutige Identifikation des LDAP-Servers. rid = replika-ID.
• provider=“ldap://123.123.123.124″: Definiert den Provider
• type=refreshAndPersist: Die Verbindung zwischen Quell- und Zielserver bleibt dauerhaft bestehen, so dass Aenderungen immer sofort repliziert werden. Alternative dazu waere refreshOnly und Festlegung eines Intervalls in der Form interval=’dd:hh:mm:ss‘.
• schemachecking=on: Ueberprueft ob die replizierenden Objekte den Anforderungen der Schema-Definitionen entspricht, z.B. ob die MUST-Attribute alle ausgefuellt sind.
• retry=“5 10 30 +“: Gibt an, in welchen Intervallen versucht werden soll mit dem Provider wiederzuverbinden, wenn die Verbindung abgebrochen ist. In diesem Fall ist es alle fuenf Sekunden, insgesamt 10 mal, danach alle 30 Sekunden ohne Limit.
• searchbase=“dc=mydomain,dc=de“: Gibt den Punkt im Baum an, ab wo gesucht (und entsprechend repliziert) werden darf.
• Die letzten drei Eintraege bindmethod, binddn und credentials definieren die Methode und die benoetigten Zugangsdaten die fuer die Replizierung benoetigt werden

Wenn soweit alles geklaert ist, dann kann die /etc/ldap/slapd.conf auf den zweiten LDAP-Server kopiert, und beide Server gestartet werden. Es empfiehlt sich fuer eine evtl. Fehleranalyse das loglevel 16384 zu setzen = sync.

Im naechsten Blogeintrag werde ich dann die dazugehoerige Konfiguration von Heartbeat beschreiben.