Open Source im professionellen Einsatz
Linux-Magazin 07/2016
© mezzotint123rf, 123RF

© mezzotint123rf, 123RF

Samba mit Bordmitteln im Clustermodus betreiben

Doppelt hält besser

Ausfallsicherheit ist auch für Fileserver-Admins ein großes Thema. Dank der CTDB und Ceph lässt sich Samba auch als Cluster problemlos betreiben.

1167

Die weite Verbreitung von Samba bringt es mit sich, dass sich Fileserver-Admins regelmäßig fragen müssen, wie sie den Dienst gegen Ausfälle absichern können. Zwar ist Samba inzwischen ausgereift und läuft in den meisten Fällen problemlos. Stürzt aber der Server ab, auf dem Samba läuft, wäre der Dienst nicht mehr verfügbar, Gleiches gilt, wenn das Netzwerk Schluckauf hat. Jede Komponente wird automatisch zum Problem, wenn sie ausfällt und keine andere Komponente ihren Dienst übernimmt.

Die Samba-Entwickler wissen das und haben auf das Problem reagiert: In Samba findet sich nämlich ein waschechter Clustermodus, mit dem sich der Dienst hochverfügbar machen lässt. Das bedeutet: Mehrere Samba-Server stehen für Clientanfragen zur Verfügung und machen es untereinander aus, wie sie die abarbeiten.

In einem solchen Setup fällt der Crash eines einzelnen Samba-Servers nicht mehr ins Gewicht, weil andere Server dessen Agenda übernehmen können. Die Einrichtung gestaltet sich allerdings nicht ganz intuitiv, auch weil die Clusterimplementierung von Samba sich in den vergangenen Jahren mehrfach grundlegend geändert hat. Der folgende Artikel gibt einen Überblick über die wichtigsten HA-Fragen in Sachen Samba.

Die Herausforderung

Warum ist ein Samba-Cluster überhaupt eine besondere Herausforderung? Um das zu verstehen, ist ein kleiner Ausflug in die Theorie des Speicherns notwendig. Von besonderer Bedeutung ist dabei das Thema Locking. Die Ausgangsfrage ist stets, wie eine Anwendung mit konkurrierenden Zugriffen auf die gleiche Datei umgeht. Anwendung kann in diesem Falle ein einfaches Dateisystem auf einem Datenträger ebenso wie eine komplexe Applikation sein. Auf jeden Fall muss sie sich um das Locking kümmern. Man stelle sich das Chaos vor, das andernfalls entstünde: Zwei Clients greifen zeitgleich auf dieselbe Datei zu und verändern Teile davon. Am Ende steht eine korrupte Datei, mit deren Inhalt weder Client A noch Client B etwas anfangen kann.

Auf der Datenträger-Ebene haben die verschiedenen Dateisysteme in den vergangenen Jahren praktisch alle Lösungen durchprobiert: Ältere Dateisysteme verweigern den Zugriff auf eine Datei rigoros, wenn diese schon geöffnet ist. Moderne Dateisysteme verfolgen das Prinzip, dass der letzte Schreibvorgang gewinnt und den Inhalt der Datei bestimmt. Vim-Benutzer kennen das, denn Vim legt Swap-Dateien für geöffnete Dateien an und prüft, bevor es eine Datei öffnet, ob für diese bereits eine Swap-Datei existiert. Ist das er Fall, zeigt Vim eine deutliche Warnmeldung an, bevor es die Datei öffnet.

Weil auch Samba ein Netzwerk-Dateisystem anbietet, verfügt es ebenfalls über interne Lockingfunktionen. Sein Zauberwort heißt TDB (Trivial Database) und bezeichnet ein Datenbankformat, in dem Samba seine internen Metadaten abspeichert. Eine der wichtigsten Datenbanken ist »locking.tdb« , in der sich Samba merkt, welche Clients gerade auf welche Datei zugreifen.

Samba setzt maßgeblich auf Opportunistic Locking, weil Windows-Clients dies auf Samba-Laufwerken erwarten. Das bedeutet, dass ein Client dem Server mitteilt, dass er die exklusiven Zugriffsrechte auf eine Datei des Samba-Share für sich beansprucht. Wenn der Samba-Server der Anfrage entsprochen hat, schreibt er einen entsprechenden Vermerk in »locking.tdb« und verbietet anderen Clients den Zugriff auf dieselbe Datei.

Solange der Vorgang auf eine einzelne Samba-Instanz beschränkt ist, klappt das alles wunderbar: Schließlich kann der einzige Samba-Server dann zuverlässig davon ausgehen, dass seine Version von »locking.tdb« die aktuelle ist. Andere Samba-Instanzen, die diese verändern könnten, gibt es ja nicht.

Wenn sich diese Grundannahme jedoch ändert – wie bei geclustertem Samba –, ist die Herausforderung da: Dann müssen mehrere Samba-Instanzen der Installation untereinander die Inhalte ihrer »locking.tdb« -Dateien synchron halten. Das bedeutet nichts anderes, als den Zugriff von Clients auf Dateien des Samba-Volume clusterweit zu managen.

Die Lösung der Samba-Entwickler für dieses Problem heißt CTDB: Das "C" steht hier für Cluster und beschreibt eine Erweiterung von TDB, dank der viele Samba-Instanzen ihre TDB-Inhalte dynamisch austauschen können. Erst mit CTDB lässt sich ein Samba-Cluster also sinnvoll betreiben.

Voraussetzungen für geclustertes Samba

Um einen Samba-Cluster zu bauen, müssen mehrere Voraussetzungen erfüllt sein. Storage und RZ-Infrastruktur spielen eine große Rolle. Dass mehrere Samba-Instanzen Zugriff auf dasselbe Dateisystem brauchen, wenn sie es im Clustermodus bereitstellen wollen, klingt wie eine Binsenweisheit, ist aber entscheidend, um an den Clusterbetrieb mit CTDB überhaupt denken zu können.

Noch vor wenigen Jahren hätten sich Admins hier mit geteilten Dateisystemen befassen müssen: GFS oder OCFS2 (Oracle Cluster File System 2) verwalten den clusterweiten Zugriff auf dasselbe Dateisystem, etwa einen per I-SCSI verbundenen NAS-Share. Doch das setzt auch zwingend den Betrieb eines Clustermanagers voraus, bevorzugt Pacemaker. Und der sorgt bei vielen Admins für Verdruss, weil er ausgesprochen komplex ist und gerade im Gespann mit GFS oder OCFS2 kaum zu durchdringen.

Zum Glück haben die verteilten Speicherlösungen ihren Kollegen inzwischen den Rang abgelaufen. Verteilte Speicher funktionieren anders: Sie bilden aus vielen kleinen Segmenten der teilnehmenden Server ein großes Dateisystem und kümmern sich intern um dessen Konsistenz. Der Zugriff erfolgt durch festgelegte, eigenständige Mechanismen über einfache Schnittstellen. Im Grunde ist ein verteilter Speicher zwar nicht weniger komplex als Pacemaker mit OCFS2, aber er versteckt seine Komplexität besser. Die Einstiegshürde ist bei verteilten Speichern also deutlich niedriger.

Zwei Konkurrenten dominieren den Markt, beide kommen von Red Hat: Auf der einen Seite bietet Gluster-FS ein klassisches verteiltes Dateisystem, auf der anderen Seite ist Ceph ein Objektspeicher, der seine Inhalte auch in Form eines Posix-kompatiblen Dateisystems – Ceph-FS – anbieten kann. Ceph-FS steckte mehrere Jahre im Betastadium, doch die letzte Ceph-Version "Jewel" hat das geändert: Laut Aussage der Entwickler eignet sich Ceph-FS nun auch für den produktiven Betrieb. Für diesen Artikel fiel die Wahl des Samba-Speichers deshalb auf Ceph mit Ceph-FS.

Drei Server stehen im folgenden Beispiel für Ceph bereit: Alice, Bob und Charlie – jeder davon hat eine Festplatte zur Verfügung, die er für den Ceph-Objektspeicher beisteuert. Der Inhalt dieser Anleitung lässt sich so mit virtuellen Maschinen nachstellen. Wer also erst ausprobieren möchte, muss dafür keine extra Hardware anschaffen.

Doch der schönste Samba-Cluster hilft nicht, wenn zuvor grundlegende Regeln der Hochverfügbarkeit keine Beachtung fanden. Im Grunde steht ein HA-Cluster mit Samba den gleichen Herausforderungen gegenüber, mit denen sich auch alle anderen Dienste auf einem Server herumschlagen müssen: Durch das Clustern auf Software-Ebene ist nur ein Punkt abgedeckt. Der Ausfall von Infrastruktur, die Samba nicht kontrolliert, kann Samba noch immer aus dem Tritt bringen.

Die beiden klassischen Fälle sind Netzwerk und Strom: Mehrere Samba-Server im Clusterverbund sind gut, doch wenn beide am selben Stromkreis hängen und dieser ausfällt, dann sind auch beide Server tot. Beim Ethernet ist die Problematik gleich: Wenn alle Knoten des Clusters an demselben Switch hängen und dieser ausfällt, ist der Samba-Dienst zwar noch verfügbar, doch seine Clients können ihn nicht mehr erreichen.

Hier empfiehlt es sich, den Bonding-Treiber für Linux zu nutzen und mehrere Switches einzubinden, deren Uplink ebenfalls redundant sein sollte.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Verteilte Dateisysteme

    Das Versprechen von Software Defined Storage ist es, heterogenen Speicher zentral und mit eingebauter Redundanz zu verwalten. Der folgende Test geht der Frage nach, wie kompliziert das Aufsetzen der dazu nötigen verteilten Dateisysteme ist. Ein Benchmark zeigt, welche Operationen jedes am besten beherrscht.

  • Ceph-Day

    Das Storage-Backend mit dem Tintenfisch-Namen hat eine sehr aktive Community. Das freut den Hersteller Inktank – er lud Ende Februar zum zweiten "Ceph-Day Europe" nach Frankfurt ein.

  • Storage-Cluster

    Wer Cloudumgebungen baut, braucht nicht nur eine skalierbare Infrastruktur, sondern auch eine performante Storagekomponente. Zu den relevanten Speicherlösungen, die dieser Schwerpunkt vorstellt, gehört auch der Newcomer Ceph, der als Objectstore für die Cloud ein schönes Paar mit Open Stack abgibt.

  • Ceph 0.87 verbessert Datendurchsatz und Performance

    Das verteilte Dateisystem Ceph kommt unter anderem in Open Stack zum Einsatz. Version 0.87, Codename Giant, verbessert die Rados-Performance und den Umgang mit Object Store Devices (OSD).

  • Ceph 0.80 mit Löschcodes und Cache-Pools für heiße Objekte

    Firefly heißt die neue Version 0.80 von Ceph. Sie bringt unter anderem Löschcodes mit und kann Cache-Pools erstellen.

comments powered by Disqus

Ausgabe 08/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.