Wiki-Bereiche:

Informationstechnik (IT)
Hobbys

Artikel in diesem Bereich:

Clustered CIFS mit Samba

Vortrag von Michael Adam (Samba Team) auf dem LinuxTag 2009.

Die Idee: Clustered NAS

Mit Hilfe eines Cluster Dateisystems (wie z.B. GPFS, siehe LinuxTag-Vortrag) ein geclusteres NAS (in diesem Fall CIFS mit Samba Daemons auf den Cluster-Knoten) zu realisieren.
Die Vorteile: Hochverfügbarkeit und mehr Performance durch Lastverteilung (z.B. DNS Round Robin auf die IPs der Samba-Cluster-Knoten).

Herausforderung

Die Samba Daemons auf den einzelnen Cluster-Knoten müssen nach außen wie ein CIFS-Server agieren. Dabei müssen folgende Daten zwischen den Daemons geteilt werden:

  • user db (passdb.tdb)
  • join info (secrets.tdb)
  • id mapping table (winbindd_idmap.tdb)

Zusätzlich müssen u.a. folgende Informationen auf allen Daemons einheltich zur Verfügung stehen, um Loadbalancing über die Daemons und ein Failover beim Ausfall eines Knotens realisieren zu können:

  • SMB Sitzungen (smb sessions)
  • Freigabe Verbindungen (share connections)
  • Freigabe Modus (share mode)

Die einfachste Realisierung wäre die Ablage der TDB-Datenbanken auf dem Cluster-Dateisystem, so dass alle Samba-Daemons zentral darauf zugreifen können. Leider performanen die aktuellen Clusterdateisystem bei "fcntl byte range locks", die beim Zugriff auf diese Datenbanken vermehrt auftreten, sehr schlecht. Je mehr Knoten auf die Datenbankdateien zugreifen, desto langsamer wird das gesamte Cluster. Daher müssen die TDB-Datenbanken noch einmal gesondert geclustert weden: Cluster TDB, kurz CTDB

CTDB

  • Auf jedem Cluster-Knoten läuft ein ctdbd Daemon. Die Daemons gleichen ihre Informationen über LAN ab. Da keine Authentifizierung zwischen den Daemons erfolgt, sollte dringend ein dediziertes Netzwerk hierfür eingesetzt werden.
  • Der Samba Prozess smbd greift immer auf den lokalen ctdbd Daemon zu.
  • Die ctdbd Daemons halten eine vollständige, lokale Kopie der Datenbanken für schnellen Lese- und Schreibzugriff vor.
  • Die ctdbd Daemons sind mit zusätzlichen Management-Funktionen ausgestattet: Monitoring des aktuellen Betriebsstands, Starten und Stoppen der Samba Daemons (smbd).

Performance

Die besten Performance-Ergebnisse konnten mit GPFS erreicht werden. Hier die Ergebnistabelle eines "32 client subtorture nbench"-Performancetests, veröffentlicht von Andrew Tridgell auf der Linux Conf Austria 2008:

Anzahl Verbindungen Duchsatz
1 109MB/s
2 210MB/s
3 278MB/s
4 308MB/s

Failover

Über ein "election recovery lock file" auf dem Clusterdateisystem, auf dem POSIX "fcntl byte range locks" durchgeführt werden, wird beim Cluster-Split bestimmt, welcher Cluster-Teil die weitere Arbeit übernimmt. "Split Brain"-Situationen können laut Aussage des Redners damit ausgeschlossen werden.

Da die Sitzungsdaten zu einem Samba Daemon beim Ausfall nicht automatisch übernommen werden, muss sich der Client reconnecten. Um die Reconnect-Zeit möglichst gering zu halten, kann der "tickle-ACK" Trick angewendet werden. Details dazu im Samba Paper.

Voraussetzung

Wichtigste Voraussetzung an das Clusterdateisystem ist die Unterstützung des POSIX "fcntl byte range lock". Dies ist mit einem mitgelieferten "ping-pong" Test vorab prüfbar. Gebräuchliche Clusterdateisysteme wie GPFS, GFS, GlusterFS, Lustre, OCFS2 konnten erfolgreich getestet werden.

Wichtige Konfigdateien

  • /etc/sysconfig/ctdb: CTDB_RECOVERY_LOCK setzen
  • /etc/ctdb/nodes: Liste mit IPs der Cluster-Knoten. Muss auf jedem Knoten identisch sein.
  • /etc/sysconfig/ctdb: CTDB_PUBLIC_ADRESSES -> /etc/ctdb/public_addresses

Verfügbarkeit der Implementierung

Ab Samba 3.3 ist die Cluster-Funktion enthalten. Beim Kompilieren kann sie mit der Option "--with-cluster-support" aktiviert werden.

Stichwörter

Geben Sie Stichwörter ein, die dieser Seite hinzugefügt werden sollen:
Please wait 
Sie suchen ein Stichwort? Beginnen Sie einfach zu schreiben.