Gespaltene Identitäten

Wenn Samba von mehreren Knoten eines Dateisystem-Clusters aus Clients dieselbe Datei zeitgleich anbietet, entstehen prinzipbedingt einige Probleme:

• Das CIFS-Protokoll arbeitet mit ausgefeilten Dateisperren
  (Locks): Share Modes, die ganze Dateien exklusiv sperren, und Byte
  Range Locks, um Teile einer Datei zu sperren. Diese verpflichtenden
  (Mandatory-)Locks der Windows-Welt sind nicht einfach in die
  lediglich empfohlenen (Advisory-) Locks der Posix-Welt
  übersetzbar [5]. Darum speichert Samba die
  CIFS-Locking-Informationen in internen Datenbanken und prüft
  sie bei jedem neuen Dateizugriff. Der Cluster muss das Locking
  knotenübergreifend konsistent halten, wenn Clients auf
  unterschiedliche Knoten zugreifen.
• Die verschiedenen Samba-Prozesse schicken einander Nachrichten.
  Zum Beispiel kann ein Client einen Lock-Request mit Timeout auf
  einen im Moment von einem anderen Client gesperrten Dateibereich
  absetzen. Hebt der eine Client dann innerhalb des Timeout die
  bestehende Sperre auf, gewährt Samba die neue Sperre und
  informiert per Signal den wartenden Zielprozess darüber, dass
  eine Nachricht vorliegt.
• ID-Mapping-Tabellen, die Windows-Benutzer und -Gruppen den
  Unix-Benutzer- und -Gruppen-IDs zuordnen, müssen auf den
  Knoten synchron sein, damit Sambas Sicht der Datei-Eigentümer
  im Cluster-Dateisystem auf allen Clusterknoten dieselbe ist.
• Besitzt ein Server eine eigene Benutzerdatenbank, fällt
  Samba die Aufgabe zu, sie clusterweit zu pflegen.
• Als Domänen-Mitgliedsserver muss Samba auf allen Knoten
  die gleichen Join-Informationen vorhalten, also das Passwort des
  Computerkontos und die Domänen-SID.
• Die aktiven SMB-Client-Verbindungen und -Sessions auf den
  Knoten sollen knotenübergreifend bekannt sein.

Bis auf die Signale, die das Messaging-System neben den Nachrichteninhalten verwendet, um andere Prozesse über das Vorhandensein neuer Nachrichten zu informieren, sind dies alles Informationen, die Samba in seinen internen TDB-Datenbanken ablegt:

• Die Share Modes in der »locking.tdb«
• Die Byte Range Locks in »brlock.tdb«
• Die Nachrichten in »messages.tdb«
• Das ID-Mapping in der »winbindd_idmap.tdb«
• Die Benutzerdatenbank in der »passdb.tdb«, falls
  der Parameter »passdb backend = tdbsam« gesetzt
  ist
• Die Join-Informationen in der
  »secrets.tdb«-Datenbank
• Die Verbindungen in der »connections.tdb«
• Die Sessions in der »sessionid.tdb«

TDB [6] ist Sambas Trivial Database, eine kleine, schnelle Datenbank ähnlich der Berkeley DB und GNU DBM, die zusätzlich Locking und damit simultanes Schreiben unterstützt. Samba benutzt TDB intern an sehr vielen Stellen, neben den eben genannten Datenbanken beispielsweise für diverse Caches. Falls möglich verwendet Samba den Memory-Mapping-Mechanismus »mmap()«, um Bereiche der TDBs direkt in den Hauptspeicher einzublenden - so fungieren TDBs als schneller gemeinsamer Speicher.

Abbildung 1: Samba-Entwickler 2007 zu Gast bei Google (vorne rechts der Autor des Artikels). Ein Team um Volker Lendecke (Mitte hinten mit schwarzem Shirt) und Andrew Tridgell (ganz links, mittlere Reihe) entwickelt seit 2006 den Clustercode von Samba.

Performance wichtig

Die verwendeten Datenbanken sind durchaus unterschiedlicher Natur: Datenbanken für Locking, Messaging, Verbindungen und Sessions beherbergen nur Daten kurzer Lebensdauer, die Samba aber häufig schreibt und liest. Die anderen Datenbanken enthalten nicht-flüchtige Informationen, deren Überleben über Restarts hinaus wichtig ist. Auf sie greift Samba nur selten schreibend, umso öfter aber lesend zu. Für diese persistenten Datenbanken gelten somit höhere Anforderungen an die Datenintegrität als für die flüchtigen. Andererseits sind die flüchtigen Datenbanken deutlich Performance-kritischer als die persistenten.

Der naive Ansatz, alle Datenbanken in das Cluster-Dateisystem zu legen, funktioniert zwar im Prinzip, nicht aber in der Praxis. TDB arbeitet nämlich beim Locking der Datenbank-Records exzessiv mit Posix-»fcntl()«-Byte-Range-Locks [5]. Die sind auf Cluster-Dateisystemen nicht nur langsam, sondern skalieren vor allem schlecht bis negativ mit der Anzahl der Knoten. Die TDBs ins Cluster-Dateisystem zu legen bedeutet zudem, in der Regel auf das schnelle Memory-Mapping verzichten zu müssen.

Als Hauptaufgabe beim Samba-Clustering erweist sich also das Implementieren einer skalierenden Clustervariante der TDB-Datenbank. Außerdem muss man das Messaging so erweitern, dass es Signale auch an Prozesse entfernter Knoten zu schicken vermag. CTDB (Clustered TDB), Sambas performante Cluster-Implementation der TDB, löst genau diese Probleme. Der Kasten "Fleißige Entwickler" skizziert die Projektgeschichte.