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.