Eine kostengünstige Alternative zu herkömlichen Cluster-Lösungen

Es ist nicht einfach, wenn man`s doppelt nimmt!?

Verzeichnisdienste sind heutzutage in der IT-Welt nicht mehr wegzudenken. Für viele Bereiche, wie z. B. zur Authentifizierung von Web-Diensten oder zur Benutzerverwaltung, ist ein solcher Verzeichnisdienst unerlässlich. Neben Microsofts Active Directory (AD) oder Oracles Internet Directory (OID) erfreut sich die Open Source Variante OpenLDAP immer größerer Beliebtheit. Um längere Ausfallzeiten zu verhindern, müssen solche zentralen Dienste häufig hochverfügbar sein. Heartbeat unter Linux ist eine kostengünstige Hochverfügbarkeitslösung. Wie Sie OpenLDAP mit Heartbeat und Linux komfortabel und mit geringem Kostenaufwand realisieren können, zeigt der folgende Artikel.

Warum LDAP als Hochverfügbarkeitslösung?

Viele Unternehmen setzen LDAP als Verzeichnisdienst ein. Es wird zur Domänenanmeldung, zur Authentifizierung diverser Applikationsserver oder zur Benutzerverwaltung genutzt. Sollte solch ein zentraler Dienst ausfallen, kann das die gesamte Unternehmensinfrastruktur lahm legen. Darum ist es notwendig, LDAP hochverfügbar anzubieten.

Einer rechts, einer links

Wie Hearbeat auf zwei Linux-Systemen eingerichtet wird, wurde im ORDIX News Artikel "Wenn das Herz schlägt ..." in der Ausgabe 2/2002 dargestellt. Einen Dienst über Heartbeat zu verwalten, so dass dieser Dienst bei Serverausfall auf einem anderen System gestartet wird, stellt für sich genommen keine Herausforderung mehr dar.

Meine Daten, deine Daten

Bei jeder Hochverfügbarkeitslösung muss sichergestellt sein, dass der Dienst auf seine aktuellen Daten zugreifen kann, unabhängig davon, auf welchem Knoten der Dienst gestartet wird.

Eine Lösung ist das Nutzen von Shared Disks. Hierbei greifen beide Knoten auf dasselbe Speichermedium zu. Shared Disks bedeuten jedoch einen erheblichen Hardware-Mehraufwand.

Eine andere Lösung ist Distributed Replicated Block Device (DRBD®), welcher in dem oben genannten Artikel vorgestellt wird. DRBD® spiegelt Festplatten über das IP-Netzwerk. Es können weitere Entfernungen überbrückt werden und es ist ohne spezielle Hardware zu betreiben. Da die Spiegelung über das Netzwerk erfolgt, sind Besonderheiten bei der Bedienung und Administration des Systems zu beachten.

Als dritte Lösung bietet sich die Replikation durch LDAP selbst an. Dies erfordert keine spezielle Hardware und keine zusätzliche Software, in die sich ein Administrator einarbeiten muss. Sie ist fester Bestandteil der LDAP-Funktionalität.

Replik

Der LDAP-Dämon "slapd" wird mittels /etc/ldap/slapd.conf konfiguriert. Die Konfiguration ist für Master- und Slave-Server fast gleich. Jedoch muss auf dem Master eingetragen werden, dass Datenänderungen an die Slaves repliziert werden.

Da der Slave keine virtuelle IP-Adresse hat, wird die physikalische IP-Adresse als Ziel für die Replikation eingetragen (siehe Abbildung 1). Die Konfiguration für den Master-LDAP-Server ist somit auf dem "linken" und "rechten" Rechner unterschiedlich. Der slurpd ist der Replikations-Dämon des LDAP-Servers. Dieser schiebt Veränderungen am LDAP-Daten-bestand an den LDAP-Slave.

Hoch - Runter

Auf dem Master-System müssen der slapd und der slurpd mit der Master-Konfiguration (zusammen als Master bezeichnet) gestartet sein, während auf dem anderen System der slapd mit der Slave-Konfiguration (Slave) läuft. Über Heartbeat lässt sich der Slave nicht steuern, da Heartbeat nicht sicherstellt, dass Master und Slave immer auf disjunkten Systemen laufen.

Es ist naheliegend, den Slave auf dem jeweils anderen System beim Hochfahren des Masters per ssh oder rsh zu starten. Problematisch ist das Verhalten, wenn beim Hochfahren z. B. nur ein Rechner verfügbar ist oder wenn während des Betriebs der Slave rebootet wird.

Die hier verfolgte Lösung startet beim Hochfahren, unabhängig von Heartbeat, zuerst den Slave. Anschließend wird der Heartbeat-Dämon gestartet (siehe Abbildung 2). Heartbeat wiederum stellt sicher, dass der Master auf genau einem der Knoten startet (siehe Abbildung 3).

Mit dem Start des Masters wird zugleich der Slave gestoppt. Auf dem zweiten Rechner bleibt der Slave bestehen. Mit dem Stoppen des Masters wird der Slave wieder gestartet. Somit läuft genau ein Master-Server und überall, wo gerade kein Master aktiv ist, arbeitet ein Slave.

Kardiologie

Heartbeat selbst benötigt drei Konfigurationsdateien. Die Datei ha.cf ist die globale Konfigurationsdatei des Heartbeat. Die Datei authkeys legt die Verschlüsselungsform der Heartbeat-Überwachungspakete fest. In der Datei haresources (siehe Abbildung 4) werden die zu verwaltenden Dienste angegeben. Der Rechner rechternode aktiviert die virtuelle IP-Adresse 10.10.10.1 und führt das Startskript slapd.master aus.

Fällt rechternode aus, wird diese IP-Adresse vom Backup-Knoten übernommen und das Startskript slapd.master ausgeführt. Dabei wird der LDAP-Master gestartet und gleichzeitig der LDAP-Slave gestoppt.

Fazit

Die hier vorgestellte Konfiguration ist einfach und komfortabel zu administrieren. Das beschriebene Verfahren lässt sich auch für andere Dienste z. B. DNS-Server oder DHCP-Server anwenden, sofern die Redundanz durch Slaves (ohne dass der Master-Server geschaltet wird) nicht ausreichend ist.

Frank Späth und Markus Schreier (info@ordix.de).

DRBD® ist eine eingetragene Marken der LINBIT Information Technologies GmbH, Austria

Seitenanfang

Seite drucken

Seite weiterempfehlen