Geclusterter CIFS-Server mit Samba und CTDB

Selbstheilend

Wenn ein Knoten wegbricht, dann ist den flüchtigen Datenbanken vermutlich für ein paar Records auch der Data Master abhanden gekommen. Der Recovery-Prozess versetzt die Datenbank wieder in einen konsistenten Zustand: Ein Knoten ist der Recovery Master, der die Records von allen Knoten einsammelt. Für solche Records, für die er keinen Data Master findet, sucht er den Knoten mit der jüngsten Kopie. Dazu pflegt CTDB in einem zur Standard-TDB zusätzlichen Headerfeld eine Record Sequence Number, die bei jedem Transfer des Record auf einen anderen Knoten hochzählt. Am Ende der Recovery ist der Recovery Master der Data Master jedes Record jeder TDB.

Der Recovery Master geht aus einem Wahlprozess hervor, der mit dem so genannten Recovery Lock arbeitet. Das ist eine Datei im Cluster-Dateisystem, auf die der frisch gekürte Recovery Master am Ende ein Lock erhält. Genau wegen dieses Recovery Lock verlangt CTDB von seinem Cluster-Dateisystem, Posix-»fcntl()«-Locks zu unterstützen. Es sind auch andere, kompliziertere Wahlprozesse denkbar, die diese Anforderung nicht stellen. Andererseits verhindert ein intaktes Cluster-Dateisystem bei CTDB das fehlerträchtige Split-Brain-Problem.

Butter bei die CTDB-Fische

Nach der Theorie nun zur Admin-Praxis. Der Kasten "CTDB besorgen und kompilieren" erklärt, wie der Admin zu einer lauffähigen CTDB-Software kommt. Das eigentliche Samba-Setup passiert nachher im Abschnitt "Samba konfigurieren". Die Samba-Entwickler empfehlen für ein CTDB-Setup (mindestens) zwei, am besten physikalisch getrennte Netze: Ein öffentliches, aus dem die Clients auf die angebotenen Dienste zugreifen (Samba, NFS, FTP, ...), und ein privates Netz, über das CTDB die Cluster-interne Kommunikation abwickelt.

CTDB besorgen und kompilieren
Seit Ende 2007 verwendet das Samba-Projekt das dezentrale Code-Managementsystem Git [20]. Die Entwickler pflegen Samba und CTDB auf dem Server [git://git.samba.org] beziehungsweise dem Webfrontend [21]. Die Branches für die offiziellen Samba-Versionen sowie der Entwicklungsbranch »master« befinden sich im Repository [git://git.samba.org/samba.git]. Der Mirror [22] liefert sogar Tarball-Snapshots von jeder einzelnen Revision. Die offiziellen CTDB-Quellen bietet Ronnie Sahlberg in seinem Repository [7] an. Das Repository [git://git.samba.org/obnox/samba-ctdb.git] enthält auf den offiziellen Release-Branches fußende Samba-Versionen mit Cluster-Erweiterungen, insbesondere eine produktionstaugliche Clustervariante »v3-2-ctdb« der Samba-Version 3.2. Derzeit ist die CTDB-Software auf Linux und AIX lauffähig [23]. Die übliche Kommandosequenz baut und installiert sie: cd ctdb/ ./autogen.sh ./configure [Optionen] make make install Besondere »configure«-Optionen sind nicht nötig. Mit dem üblichen »--prefix« kann der Admin die Installationsverzeichnisse anpassen. Für RPM-Systeme darf er ein Paket auch direkt aus einem Git-Checkout produzieren: cd ctdb/ ./packaging/RPM/makerpms.sh Bereits kompilierte CTDB- und »v3-2-ctdb«-RPMs für Red Hat gibt es unter [24], für weitere Distributionen bei [25].

CTDB besorgen und
kompilieren

Seit Ende 2007 verwendet das Samba-Projekt das dezentrale Code-Managementsystem Git [20]. Die Entwickler pflegen Samba und CTDB auf dem Server [git://git.samba.org] beziehungsweise dem Webfrontend [21]. Die Branches für die offiziellen Samba-Versionen sowie der Entwicklungsbranch »master« befinden sich im Repository [git://git.samba.org/samba.git]. Der Mirror [22] liefert sogar Tarball-Snapshots von jeder einzelnen Revision.

Die offiziellen CTDB-Quellen bietet Ronnie Sahlberg in seinem Repository [7] an. Das Repository [git://git.samba.org/obnox/samba-ctdb.git] enthält auf den offiziellen Release-Branches fußende Samba-Versionen mit Cluster-Erweiterungen, insbesondere eine produktionstaugliche Clustervariante »v3-2-ctdb« der Samba-Version 3.2. Derzeit ist die CTDB-Software auf Linux und AIX lauffähig [23]. Die übliche Kommandosequenz baut und installiert sie:

cd ctdb/
./autogen.sh
./configure [Optionen]
make
make install

Besondere »configure«-Optionen sind nicht nötig. Mit dem üblichen »--prefix« kann der Admin die Installationsverzeichnisse anpassen. Für RPM-Systeme darf er ein Paket auch direkt aus einem Git-Checkout produzieren:

cd ctdb/
./packaging/RPM/makerpms.sh

Bereits kompilierte CTDB- und »v3-2-ctdb«-RPMs für Red Hat gibt es unter [24], für weitere Distributionen bei [25].

Das Netz des Cluster-Dateisystems kann ein getrenntes Netz sein oder dasselbe wie das CTDB-interne. Mitunter erweist sich ein separates Managementnetz als sinnvoll, etwa für SSH-Logins auf den Knoten. Den prinzipiellen Aufbau eines CTDB-Clusters zeigt Abbildung 2.

Abbildung 2: Prinzipielles CTDB-Setup mit zwei Serviceknoten und einem separaten Managementknoten. Wie der Storage angebunden und das Cluster-Dateisystem unter »/shared« eingehängt sind, beschreibt die Abbildung bewusst schematisch.

CTDBs zentrale Konfigurationsdatei ist die »/etc/sysconfig/ctdb«. Ganz wichtig ist hier, das Recovery-Lock-File über die Variable »CTDB_RECOVERY_LOCK« zu spezifizieren! Ferner muss der Admin die Datei »/etc/ctdb/nodes« mit den IP-Adressen aller CTDB-Knoten im privaten Netz füllen (Listing 1). Sie muss zudem auf allen Knoten identisch sein.