OpenLDAP im HA-Cluster

[cgarling]

Moin zusammen,

ich habe als Versuchsaufbau mit VMWare einen HA-Cluster installiert. 2x Debian Etch mit DRBD und Heartbeat. Als Dienst läuft Samba als reiner Fileserver. Samba als PDC ist nicht vorgesehen. Jetzt stehe ich vor der Frage der Benutzerverwaltung. Damit jeder der beiden Server auf einen identischen Benutzerdatenstamm zugreifen kann, dachte ich an LDAP.

Da bei diesem Setup jeder der Server Master sein kann, es also keinen bevorzugten gibt, weiss ich nicht wie ich das einrichten soll. Entweder das Datenbankverzeichnis von OpenLDAP aufs DRDB legen und ebenfalls spiegeln lassen oder Replikaltion mit slurpd einrichten? Würde die Replikation in letzerem Fall in beide Richtungen funktionieren?

Steh grad etwas auf dem Schlauch ...

Gruß,

Christian

[mauser]

Hey,

"richtiges" HA-LDAP ist ne schwierige Sache. Auf Filesystemebene zu tricksen würde ich gleich sein lassen - das macht nur Stress (du kannst eh net 2 Server auf dieselbe DB schreiben lassen). Um die Server synchron zu halten benötigst du schon einen Dienst wie slurpd(deprecated) oder das syncrepl-Overlay.

Das Problem liegt nun beim Schreibzugriff: Mit syncrepl und OpenLdap 2.3 kann es jeweils nur einen aktiven Master-Server geben. Du kannst nun folgendes machen:

• * OpenLdap 2.4 benutzen (hat multimasterfähigkeit, aber noch sehr unstable)
  * Ein Skript bauen welches bei Ausfall den Slave zum Master macht (bei syncrepl austauschen von 4 Zeilen)
  * Im Notfall von Hand den Master auf Slave umstellen

Deine Wahl sollte davon abhängen wie wichtig Schreiboperationen für dich sind. Wenn du es als reine Benutzerdatenbank betreibst sind die oft Zweitrangig. Ok, dann kann halt mal jemand nicht für 10min sein Passwort wechseln. Who cares? Wenn du allerdings noch andere Sachen im Ldap verwaltest auf die zwingend geschrieben werden muss (Druckdaten oder sowas) sieht die Sache schon wieder anders aus... Imho würde dann aber auch die Lösung mit dem umschalten per Skript reichen.
Gruss,
mauser

PS: Ich denke ja mal der Versuchsaufbau nachher verschwinden soll oder ? Denn Ldap in Vmware ist im Produktivbetrieb nicht unbedingt toll, habe ausführlich mal mit dem freien Vmware-Server und ESX getestet.

[cgarling]

Hi,

also es gibt immer nur einen Master, der andere ist zwangsweise Slave. Was ich meinte ist die Tatsache das diese Rolle wechseln kann. Schreiboperationen sind eher unwichtig. Es geht sich nur darum das nach einem "Rollentausch" auch auf dem neuen Master Benutzer angelegt werden können.

Gruß,

Christian

[cgarling]

Hatte ich eben überlesen ... also VMWare ist nur zum Test. Es gibt diesen Cluster Produktiv seit ein paar Jahren im Einsatz. Zwar unter anderem von mir installiert, aber durch andere Personen betreut. Zur Zeit sind die Benutzer normale Unix Accounts. Es gibt also jeden Benutzer sowohl auf Server 1 wie auch auf Server 2. So lange man immer brav die /etc/passwd und Konsorten auf den 2. Server kopiert ist die Welt schön. Aber genau das wurde nicht gemacht. Und wie der Zufall so will, ist der "gute" Server jetzt ausgefallen und der mit der nicht aktuellen Benutzerliste musste übernehmen. Und da liegt halt das Problem. Ich meine es muss nicht zwingend LDAP sein, wenn jemand eine andere Idee hat ist das auch toll.

Gruß,

Christian

[mauser]

Hey..

Hm ja dafür ist OpenLdap wirklich nicht die richtige Lösung. Das lohnt sich nur wenn man eine wirklich grosse Benutzerliste hat die sich ständig ändert. Warum machst du dir nicht einfach ein Skript, welches jede Nacht die passwd und die entsprechenden anderen Files per rsync kopiert ? Das wäre doch eigentlich die beste Möglichkeit !
Gruss,
mauser

[cgarling]

Hmm,

also müsste der Heartbeat auf dem aktiven Knoten ein Script starten das diesen Job übernimmt. Oder aber als Cronjob mit einem Script das abfragt ob der Knoten auf dem es läuft Master ist und nur in dem Fall die Dateien kopieren.

Man könnte aber auch hingehen und ein alias für smbpassed und useradd bzw. adduser einrichten, das nach anlegen des Benutzers die passwd rüberschaufelt.

Was meinst du? Es muss halt gewährleistet sein, das nicht in die falsche Richtung kopiert wird.

Gruß,

Christian

[mauser]

Hallo,

tut mir leid das das mit der Antwort etwas gedauert hat

Ich weiss nicht genau wie dein Cluster aussieht. Wenn du 2 verschiedene Rechner mit 2 verschiedenen Namen hast (nehmen wir mal an das der Master immer "master" heisst und der Slave immer "slave") Dann ist das ja kein Problem (wenn die Namen im Falle eines Ausfalls entsprechend wechseln). Dann könntest du von einem Rechner der sich nicht im Cluster befindet immer die Dateien kopieren.

Wenn das nicht der Fall ist müsstest du schauen ob du auf einem Knoten per Skript herausfinden kannst ob das nun gerade der Master oder Slave ist. Da ich noch nie so eine Art von Cluster mit Heartbeat und drbd gebaut habe kann ich dir da leider auch nicht sagen, ob und wie das geht. Wenn er aber weiss das er der Master ist muss er dann halt die Dateien auf den jeweils anderen Rechner kopieren, aber soweit hattest du die Idee ja auch schon.

Gruss,
mauser

[cgarling]

Moin,

der Cluster sieht so aus:

1. Server:
Hostname: node1
IP-Adresse: 192.168.0.1 zum LAN / 172.16.0.1 zum 2. Server für Heartbeat und DRBD
Filesystem: /dev/sdb1 als /dev/drbd0

2. Server:
Hostname: node2
IP-Adresse: 192.168.0.2 zum LAN / 172.16.0.2 zum 1. Server für Heartbeat und DRBD
Filesystem: /dev/sdb1 als /dev/drbd0

Es gibt eine produktive IP-Adresse 192.168.0.10. Ich lese aktuell den Status (Primary / Secondary) aus /proc/drbd aus.

Heartbeat startet die Dienste samba und monit. Beim Systemstart wird nichts gestartet. Vielleicht wäre ein 3. und evtl. 4. Rechner mit einem LDAP Server eine Idee um die User zu verwalten. Das Script ist zwar OK, aber lässt mich nur gering besser schlafen. Im Grunde mehr ein Ausweg als eine Lösung.

Gruß,

Christian