Dateisystem als Black Box

Wer CTDB einsetzt, braucht ein Cluster-Dateisystem, das auf allen Knoten gemounted ist, Posix-»fcntl()«-Locking-Semantik anbietet und seine Locks knotenübergreifend konsistent hält. Dabei spielt es keine Rolle, um welches Dateisystem genau es sich handelt und ob der Speicherplatz per Fibre Channel aus einem SAN kommt, aus einem per I-SCSI angebundenen Storage-Knoten oder sogar aus lokalen Plattenpartitionen. CTDB ist glücklich, solange es auf allen Knoten das gleiche Dateisystem gemounted hat und Byte-Range-Locks darauf setzen darf. Im Minimalfall reicht ein einzelner Rechner mit lokaler Ext-3-Partition.

Ob ein Cluster-Dateisystem für CTDB geeignet ist, zeigt der so genannte Pingpong-Test. Unter [9] liegt das kleine Programm »ping_pong.c« bereit, das testet, ob ein Cluster-Dateisystem kohärentes Byte-Range-Locking anbietet. Außerdem misst es die Locking-Performance und bestimmt die Korrektheit und Performance bei simultanen Schreibzugriffen und des Memory-Mapping (»mmap()«). Details zum Pingpong-Test hält [10] bereit.

Das am besten mit CTDB getestete Dateisystem ist das proprietäre GPFS [11] von IBM; CTDB und das Samba-Clustering verdanken ihre Entstehung nämlich maßgeblich dem Sponsoring von IBM. Als gut evaluiert gilt auch Red Hats Global File System (GFS) in der Version 2 ([12], [13]). CTDB-Pakete werden daher Einzug in die nächste Fedora-Version halten. Außerdem liegen positive Berichte vor vom Einsatz mit dem GNU Cluster File System (Gluster-FS, [14]) und Suns Lustre [15]. Das Oracle Cluster File System (OCFS2, [16], [13]) wird sich erst eignen, wenn die Implementierung des Posix-»fcntl()«-Locking abgeschlossen ist [17].

01 192.168.46.70
02 192.168.46.71
03 192.168.46.72

So arbeitet CTDB

Und so funktioniert das Ganze: Auf jedem Knoten läuft ein CTDB-Daemon »ctdbd«. Die Daemons handeln untereinander die Metadaten der Cluster-TDB-Datenbanken aus. Jeder CTDB-Daemon hält für die von CTDB verwalteten TDB-Datenbanken je eine lokale Kopie (LTDB), die nicht im Cluster-Dateisystem liegt, sondern auf schnellem lokalen Speicher. Der Zugriff auf die eigentlichen Daten erfolgt über die lokalen TDBs.

Wegen der unterschiedlichen Anforderungen gibt es für die flüchtigen und die persistenten Datenbanken zwei völlig verschiedene Verfahrensweisen: Für persistente Datenbanken hält jeder Knoten stets eine komplette und aktuelle Kopie vor. Lesezugriffe darauf erfolgen lokal. Will der Knoten schreiben, dann sperrt er dazu die gesamte Datenbank in einer Transaktion und erledigt innerhalb der Transaktion seine Lese- und Schreibvorgänge. Der Commit der Transaktion verteilt dann sämtliche Record-Änderungen an alle anderen CTDB-Knoten und schreibt sie auch lokal.

Für flüchtige Datenbanken dagegen hält jeder Knoten immer nur die Records in der lokalen TDB vor, auf die er schon zugegriffen hat. So besitzt immer nur ein Knoten die Hoheit über die aktuellen Daten eines Record: der Data Master. Will ein Knoten einen Record schreiben oder lesen, prüft er zuerst, ob er dessen Data Master ist. Wenn ja, greift er direkt auf die LTDB zu. Anderenfalls besorgt er sich über den »ctdbd« zunächst die aktuellen Record-Daten sowie die Data-Master-Rolle und schreibt dann lokal.

Dadurch, dass der Data Master immer direkt in die lokalen TDBs schreibt, ist ein einzelner CTDB-Knoten nicht langsamer als ein ungeclustertes Samba. Darin, dass bei flüchtigen Datenbanken die Record-Daten nur auf Anfrage an einzelne und nicht an alle Knoten gehen, liegt ferner das Geheimnis des guten Skalierens von CTDB. Denn: Die Änderungen, die ein Knoten an den flüchtigen Datenbanken vornimmt, dürfen, ja sollen ruhig verloren gehen, wenn er aus dem Cluster verschwindet! Die Informationen betreffen ohnehin nur Clientverbindungen auf diesem sowieso ausgefallenen Knoten. Alle anderen Knoten können mit den Daten naturgemäß nichts anfangen.

Performance-Messungen auf einem Cluster [18] bestätigen das Design sehr befriedigend. Ein dort mit 32 Clients gefahrener Smbtorture-»NBENCH«-Test [19] skaliert, wie in Tabelle 1 zu sehen. Eine einzige Verbindung auf einem Clusterknoten-Share erreicht eine Übertragungsrate von 1,7 GByte pro Sekunde.