Cluster-Dateisystem
Van Wikipedia, de gratis encyclopedie
Der Begriff Cluster-Dateisystem beschreibt ein Dateisystem, das in einem Rechnerverbund konkurrierenden Zugriff auf eine Shared Storage gestattet.
Auf ein Cluster-Dateisystem greifen alle im Cluster befindlichen Rechner direkt ohne Vermittlung eines Servers zu. Das Dateisystem muss sich dazu auf einem Speichermedium befinden, das von allen Rechnern direkt erreichbar ist. Dies wird im Allgemeinen durch den Aufbau eines SAN auf der Basis von Fibre Channel oder iSCSI erreicht. Durch den direkten Zugriff ergibt sich eine bessere Performance als bei der Nutzung eines Netzwerk-Dateisystems wie NFS oder CIFS. Insbesondere bei Datenbanken oder Anwendungen, die große Datenmengen manipulieren (Video) ist der Leistungsgewinn erheblich.
Motivation[Bearbeiten | Quelltext bearbeiten]
Wenn mehrere Computer in einem Netzwerk zusammenarbeiten, ist es generell wünschenswert oder sogar notwendig, dass alle auf einen gemeinsamen Datenbestand zugreifen. Dieser Zugriff kann jedoch nicht unkoordiniert ablaufen, denn dies würde zu Problemen führen.
- Beispiel
- Zwei Rechner, A und B, haben einen gemeinsamen Datenbestand, der die Datei X enthält.
- Es öffnet nun A die Datei X zum Schreiben und schreibt einen Wert W1 hinein.
- Gleichzeitig öffnet B die Datei X und schreibt einen Wert W2 hinein.
- Beide schreiben nun die Datei auf das Speichermedium zurück.
- Beide Rechner haben legitime Operationen durchgeführt, jedoch bleibt die Frage, welche Version nun schließlich auf dem Medium abgelegt ist.
Diesen Zustand nennt man Inkonsistenz. Das Auftreten von Inkonsistenz muss zur Vermeidung von Datenverlusten unbedingt vermieden werden. Um dies zu erreichen, ist es notwendig, sobald ein Teilnehmer A schreibenden Zugriff auf eine Datei im gemeinsamen Datenbestand erlangt hat, alle weiteren Schreibzugriffe auf dieselbe Datei zu blockieren, bis Teilnehmer A den schreibenden Zugriff wieder aufgegeben hat.
Dieses Problem besteht grundsätzlich auch innerhalb eines Rechners mit Multitasking-Betriebssystem, in dem die einzelnen Prozesse um den Schreibzugriff auf einzelne Dateien konkurrieren. Hier obliegt es dem Betriebssystemkern, dafür Sorge zu tragen, dass niemals zwei Prozesse gleichzeitig Schreibzugriff auf ein und dieselbe Datei erhalten. Da es zwischen den Rechnern eines Netzwerkes keine übergeordnete Instanz gibt, der diese Funktion naturgemäß zufällt, sind zusätzliche Maßnahmen erforderlich, um die Konsistenz der Daten zu gewährleisten. Ein Cluster-Dateisystem übernimmt diese Steuerungsaufgabe.
Beispiele für Cluster-Dateisysteme[Bearbeiten | Quelltext bearbeiten]
- RMS (OpenVMS),
- AdvFS (HP Tru64 UNIX),
- Veritas Cluster File System (verschiedene Betriebssysteme),
- OCFS2 (Linux)
- der Vorgänger OCFS (Linux und Windows, jedoch nur für Oracle-Datenbanken),
- GPFS (AIX, Linux, Windows),
- Google File System (Linux, proprietär)
- GlusterFS (Linux, FreeBSD, Solaris, Mac OS X),
- CXFS (IRIX, Linux, Solaris, macOS und Windows),
- StorNext FS (Linux, Solaris, HP-UX, AIX, IRIX, Windows und in der XSan Variante auch macOS) oder
- Polyserve Matrix Server (Linux).
- Lustre (Linux).
- Global File System (Linux).
- MelioFS[1] (Windows).
- Ceph (Linux)
- QFS Shared Writer, ein hierarchisches Dateisystem mit Clustersupport
Um die Konsistenz der Daten sicherzustellen, müssen die Verwaltungsdaten, d. h. Verzeichnisse, Attribute und Speicherplatzzuweisungen (Metadaten), koordiniert gespeichert werden. Hierzu wird üblicherweise ein Metadaten-Server eingesetzt, der all diese Daten von den verschiedenen Teilnehmern am Cluster-Dateisystem übermittelt bekommt, üblicherweise über ein Ethernet. Dieser übernimmt auch die Koordinierung der Caches und der Dateisperren (Locks). In manchen Cluster-Dateisystemen kann der Metadaten-Server auch andere Aufgaben übernehmen, bei anderen (CXFS) müssen ein oder mehrere dedizierte Metadatenserver eingesetzt werden um die Betriebssicherheit zu erhöhen.
Gelingt den Servern aufgrund einer Störung im Netzwerk die Synchronisation nicht, so besteht die Gefahr von Inkonsistenzen. Üblicherweise wird das betroffene Dateisystem sich dann auf all jenen Servern herunterfahren, die (sich selbst eingerechnet) nur noch maximal 50 % der Gesamtheit an Servern sehen können. Da es nur maximal eine Gruppe geben kann, die mehr als 50 % der Server umfasst, bleibt nur diese aktiv, es können keine Inkonsistenzen entstehen. Man sagt auch, das Quorum liegt bei über 50 %.
Aus dem Quorum ergibt sich, dass ein so konfiguriertes Dateisystem mindestens drei Server benötigt, wenn Hochverfügbarkeit erwünscht ist. Diese sollten dann konsequenterweise auch in getrennte Infrastrukturen eingebunden sein, das heißt, drei Server-Räume in unterschiedlichen Brandabschnitten, drei unterbrechungsfreie Stromversorgungen usw.
Ein Cluster-Dateisystem, das lediglich eine gemeinsame Datenbasis für eine Vielzahl parallel arbeitender Server dient, muss zwar nicht zwangsläufig hoch verfügbar sein, doch wird man eine solche Serverfarm ohnehin aus viel mehr als zwei Rechnern aufbauen. Die Mehr-Raum-Notwendigkeit stellt sich bei solchen Anwendungen zunächst nicht.
Im Gegensatz zu der weitgehend autarken Position der Server in einem Cluster-Dateisystem steht der Zugriff auf Dateien über ein Netzwerk, z. B. über Network File System (NFS) auf Unix-Systeme, über Netware von Novell oder über SMB von Microsoft. Hier „gehört“ der Plattenplatz einem bestimmten Server, der den Datenzugriff vermittelt. Fällt er aus, ist das betroffenen Dateisystem nicht verfügbar.
Die dritte Möglichkeit des verteilten Zugriffs auf Dateien ist die Verwendung von Raw Devices. Hier verzichtet man ganz auf Dateisysteme und überlässt es der Anwendung, den verfügbaren Platz auf dem betreffenden Plattensystem zu verwalten. Die Anwendung muss also gegebenenfalls die Synchronisation zwischen den Servern durchführen und mit Störungen umgehen. Moderne Betriebssysteme erlauben es, auch Anteile eines physischen Plattensystems als Raw Devices zu benutzen, während andere Anteile für Dateisysteme reserviert werden.