Der Zusammenschluss von Einzelrechnern zu Clustern dient heute nicht mehr nur der Ausfallsicherheit, vielmehr werden die Verbünde als skalierbare Rechenressourcen angesehen. Traditionelle Fail-over-Cluster arbeiten mit einer minimalen Knotenzahl; die einzelnen Arbeitsstationen sind schon aus Kostengründen so dimensioniert, dass ein Knoten beim Ausfall des anderen dessen Last mit übernehmen kann, unter Umständen freilich mit Einbußen beim Datendurchsatz. In einem Cluster aus vielen kleinen Knoten hingegen beeinträchtigt der Absturz eines einzelnen Rechners die Gesamtleistung meist nicht: Die Arbeitslast kann in der Regel von den anderen Maschinen im Verbund geschultert werden. Der Ausfall selbst wird durch die Anwendungssoftware entdeckt. Allerdings: Für den sinnvollen Betrieb eines solchen Clusters ist es unerlässlich, allen Knoten die gleiche Sicht auf die Daten zu geben. Hierzu gibt es mehrere Möglichkeiten.
Raw Devices sind Bereiche auf einem Festplatten-Array, die nicht mit einem Dateisystem versehen sind und auf die alle Cluster-Knoten gleichzeitig Zugriff haben. Ihre Verwaltung obliegt der Applikation. Die Synchronisierung beziehungsweise Serialisierung der Zugriffe übernimmt ein Lock-Manager. Beliebt ist diese Methode bei Datenbanksystemen, etwa Oracles "Parallel Server" und "Real Application Cluster".
Zugriff über NAS oder einen zentralen File-Server
Hierbei stellt ein zentraler File-Server oder eine NAS-Appliance die Daten über die Protokolle Common Internet File System (CIFS) oder Network File System (NFS) bereit. Die Cluster-Knoten binden das Verzeichnis des Speichergeräts in ihren eigenen Verzeichnisbaum ein. Der File-Server empfängt alle zu speichernden Informationen und schreibt sie in sein Dateisystem. Diese Art des Zugriffs ist sehr einfach zu implementieren, worin auch ihr größter Vorteil besteht. Allerdings leiden Skalierbarkeit und Verfügbarkeit erheblich: Fällt der File-Server aus, bleibt auch das Cluster nicht verschont. Ansonsten ist er im Wesentlichen damit beschäftigt, die I/O-Anfragen der Cluster-Knoten entgegenzunehmen und die erforderlichen Lese- und Schreiboperationen zu betreiben. Gehen zu viele Requests ein, wird der File-Server zum Flaschenhals. Diese Zugriffsmethode bietet sich somit nur dann an, wenn die Cluster-Knoten viel rechnen müssen und nur kleine Datenmengen lesen oder schreiben.
Zugriff über ein Shared-SAN-File-System
Dieser Ansatz basiert auf einem zentralen Massenspeicher, der den angeschlossenen Hosts virtuelle Festplatten für die Einrichtung von Dateisystemen zur Verfügung stellt. Auf diesen virtuellen Festplatten wird ein zentrales Dateisystem eingerichtet, auf das alle Cluster-Knoten gleichzeitig zugreifen. Die Verwaltung des Dateisystems erfolgt über einen speziellen Meta-Server, der die Zugriffe serialisiert und die Metadaten-Strukturen, zum Beispiel die Free List, die Bitmap freier Blöcke im Dateisystem oder Inodes verwaltet. Inodes beinhalten die Pointer auf die Daten im Dateisystem sowie deren Datenblöcke.
Bei einem Shared-SAN-File-System greifen alle Knoten über ihren als Kernel-Erweiterung implementierten Dateisystemtreiber via Fibre-Channel- oder iSCSI-Host-Adapter auf die gleiche virtuelle Festplatte des Plattensubsystems zu.
Der Knoten kann Client oder Metadaten-Server werden
Während der Initialisierung der Kernel-Erweiterung - entweder beim Systemstart oder beim ersten Zugriff auf ein Dateisystem - wird entschieden, ob der jeweilige Knoten als normaler Client fungiert oder als Metadaten-Server konfiguriert wird und damit die Oberherrschaft über die strukturellen Layout-Informationen des Dateisystems erhält. Im letzteren Fall übernimmt er das Setzen von Locks zur Zuweisung von Blöcken, das Anlegen oder Löschen von Verzeichniseinträgen und die Verwaltung der Inodes. Schreibzugriffe werden generell über den Metadaten-Server koordiniert, wenn nicht von ihm selbst ausgeführt. Die Lesezugriffe wickelt jeder Client unmittelbar mit dem Festplattensubsystem ab. Zur Entlastung der Fibre-Channel- oder iSCSI-Infrastruktur werden die Metadaten in der Regel über ein eigenes IP-Netzwerk geroutet, am besten über Gigabit Ethernet.
Gleiche Sicht auf Daten erspart doppelte Datenhaltung
Der größte Vorteil eines Shared-SAN-File-Systems ist, dass alle Geräte, die direkt auf das Dateisystem zugreifen können, die gleiche Sicht auf den Datenbestand erhalten. Eine doppelte Datenhaltung mit allen ihren Problemen bezüglich Daten- inkonsistenz entfällt. Der Verwaltungsaufwand sinkt vor allem deshalb ungemein, weil auch das SAN-Dateisystem zentral administriert werden kann und sich der Systemad- ministrator nach dem Setup auf die Pflege nur eines Dateisystems beschränken kann, anstatt sich mit etlichen unterschiedlichen File-Servern und deren Shares auseinander setzen zu müssen. Über eine HSM-Schnittstelle (HSM = Hierarchisches Speicher-Management) lassen sich zudem Data-Lifecycle-Management-Systeme realisieren, indem Speicherklassen definiert und ältere oder als weniger wichtig eingestufte Dokumente automatisch auf nachrangige Speicherklassen (secondary/tertiary storage), kostengünstige Plattensubsysteme oder Bandbibliotheken) ausgelagert werden.
Volle SAN-Bandbreite auch beim Backup
Auch Backup- und Recovery-Konzepte profitieren: Ein Backup eines Shared-SAN-File-Systems kann von einem beliebigen Client aus als normales Dateisystem-Backup gestartet werden. Der Zugriff auf die Daten erfolgt dabei mit voller SAN-Bandbreite, da der Knoten, der das Backup vornimmt, seine direkte SAN-Anbindung zum Lesen der Daten ausnutzen kann. Werden das Plattensubsystem und der Metadaten-Server über Fibre Channel oder Gigabit Ethernet in ein Ausweich-Rechenzen- trum gespiegelt, so ist damit gleichzeitig ohne weitere aufwändige Klimmzüge ein Schutz vor größeren Katastrophen wie Wasserschaden oder Feuer geschaffen.
Ein Nachteil von SAN-Dateisystemen ist der Zeitaufwand für die Verwaltung der Metadaten. Liegen nur wenige große Dateien im Dateisystem, fällt der Verwaltungs-Overhead durch File-Locking und die Token-Verwaltung für die Serialisierung von Schreibzugriffen nicht wirklich ins Gewicht. Bei kleineren Dateien (unter 20 KB) hingegen steigt der Verwaltungsaufwand überproportional mit entsprechend negativen Auswirkungen auf den Datendurchsatz. Hier können aber intelligente Caching-Mechanismen, insbesondere der Metadaten, Abhilfe schaffen. Eine weitere Schwachstelle der Lösung ist, dass alle angeschlossenen Systeme ne- ben den Treibern für den Host-Bus-Adapter zusätzliche Treibersoftware für das Dateisystem benötigen. Im homogenen Umfeld mag dieser Punkt zu vernachlässigen sein. In einer heterogenen Systemlandschaft jedoch schlägt der notwendige Aufwand für Rollout und Pflege durchaus als zusätzlicher Kostenfaktor für die Systemadministration zu Buche.
Für die Einführung eines Shared-San-File-Systems gilt der IT-typische Projektzyklus aus Assessment, Design, Proof of Concept, Implementierung und Wartung.
Im Assessment sollte sich der potenzielle Betreiber über seine Anforderungen Klarheit verschaffen. Zwar haben Shared-SAN-File-Systeme sowohl im technisch-wissenschaftlichen als auch im kommerziellen Umfeld zur Konsolidierung von File-, Web- oder Application-Servern ihre Berechtigung. Die Anforderungen sind je nach Verwendung aber durchaus unterschiedlich. Beim High Performance Computing ist beispielsweise die Anbindung an ein HSM-System zur Implementierung eines Data-Lifecycle-Management meist überflüssig, da die Rohdaten in der Regel nicht längere Zeit aufbewahrt werden. Kommerzielle Anwender hingegen sollten von Anfang an die Konzeption von Speicherungs- und Archivierungsrichtlinien und deren Umsetzung in Speicherklassen in Betracht ziehen. Auch ist vorher die Datenbeschaffenheit zu klären - unstrukturierte Daten sind anders zu behandeln als strukturierte, kleine Dateien verlangen andere Caching-Mechanismen als große.
Vor der Implementierung die Systeme untersuchen
Die Implementierung eines Shared SAN File Systems ist eine IT-Infrastruktur-Maßnahme. Somit hat die Systemlandschaft einen gewichtigen Einfluss auf die Produktauswahl. Während im technisch-wissenschaftlichen Bereich vor allem homogene Cluster aus teilweise Hunderten bis Tausenden von Knoten mit demselben Betriebssystem zum Einsatz kommen, sind Systeme im kommerziellen Umfeld eher heterogen mit einer Vielzahl von Hardwareplattformen und den unterschiedlichsten Betriebssystemen.
Vor diesem Hintergrund ist der Betriebssystem-Support sowie eine weitgehende Hardware-Unabhängigkeit ein wesentliches Auswahlkriterium für ein Shared-San-File-System: Nichts ist lästiger, als einen Prototypen in Betrieb zu nehmen und dann festzustellen, dass das eingesetzte Produkt nicht die Hardware und die Betriebssysteme unterstützt, die von einer Plattenkonsolidierung am meisten profitieren würden. Bei der Erstellung der Benutzeranforderungen sind auch etwaige Schnittstellen zwischen technisch-wissenschaftlichen und kommerziellen Abteilungen zu beachten, um die Entstehung von Insellösungen von vornherein vermeiden zu können.
Aus dem Assessment entstehen die Benutzeranforderungen, die dann in der Designphase mit Produktauswahl und technischem Design umgesetzt werden. Der daraus entstehende Prototyp sollte dort entstehen, wo er die größten Vorteile bringt. Das ist im technischen Bereich die Stelle, an der er die höchsten Leistungszuwächse bringt, im kommerziellen Umfeld der Ort, an der die höchsten Einsparungen, etwa durch Server-Konsolidierung, zu erwarten sind.
Die Implementierung eines Shared-SAN-File-Systems stellt eine größere Infrastruktur- maßnahme dar und erfordert eine genaue Planung. Dann winken eine erhebliche Performance-Steigerung sowie wirksamere Server- und Datenkon- solidierung. Allein aus diesem Grunde lohnt sich eine Evalua- tion. (kk)