Cluster Filesysteme [updated]
Aktuell geht das Thema Cluster Filesysteme durch die Presse. Oracle erwartet die Aufnahme seines OCFS2 in den Linux Kernel und RedHat bewirbt sein GFS in Fedora Core 4.
Typischer Einsatzzweck eines Cluster Filesystems ist das Number Crunching (High Performance Computing) für die Lösung von Simulationen oder Mathematischen Berechnungen im Bereich Forschung oder Engeneering. Dabei teilen sich viele Rechner-Knoten die Eingangsdaten und Berechnungsergebnisse. Jedoch auch kommerzielle Enterprise Systeme skalieren zunehmend in die Horizontale. Datenbanken, Fileserver und Application Server Cluster benötigen den Zugriff auf gemeinsame Datenbestände.
Ein Cluster Filesystem soll den gleichzeitigen direkten Zugriff von mehren Knoten eines Clusters auf die selben Files ermöglichen. Im Gegensatz zu Netzwerk Filesystemen erfolgt dabei der Datenfluss direkt zwischen den Knoten um Cluster und der Storage Hardware. Zum Einsatz kommen FC SANs. Kleinere Installationen können auch mit SCSI Storage Enclosures realisiert werden die mehrere Host Adapter erlauben. Für Test und Entwicklung lassen sich auch Firewire Lösungen einsetzen. Ganz aktuell boomt auch der IP basierende Block Zugriff. Mit iSCSI oder diversen Linux Netzwerk Block Devices kann hier eine Gigabit Ethernet eingesetzt werden.
Da der Datenzugriff direkt erfolgt, an einem Server Prozess vorbei sind Cache Konsistenz und das Locking von Datenblöcken wichtige Aufgaben des Cluster Filesystem. Die Leistungsfähigkeit und die Eignung für einen bestimmten Einsatzzweck eines Cluster Filesystems im wesentlichen durch das Meta Data Handling und die Locking Strategie bestimmt. Durchaus üblich ist z.B. dass in einem Cluster ein Node zum zentralen Lock Manager bestimmt wird, was ein Engpass bilden kann wenn viele Dateien benutzt werden, oder die Locks auf Block Ebene sich oft ändern. Die typische Semantik von lokalen oder Netzwerk Filesystemen lässt sich bei Cluster Filesystemen schwer nachbilden. GFS versucht hier Posix Semantik anzubieten, was den Anwendungen entgegen kommt, die nicht geändert werden müssen. OCFS hat ein einfacheres Ziel: das bereitstellen einer Verzeichnishierarchie auf mehreren Knoten (die Programmdaten und Konfigurationsfiles der Oracle Installation enthält). Oracle Datenbank benötigt für die Produktivdaten kein Cluster Filesystem. Bei einer parallelen Installation eines DB Servers können sich die einzelnen Instanzen selbst verständigen wer welche Daten cachen oder verändern darf. Durch diese Intelligenz kann Oracle dadurch gehobene Konsistenz und Persistenz Ansprüche erfüllen (ACID Transaktionen). Dies erklärt auch, warum das OCFS relativ einfach gehalten ist. Die Last auf dem Filesystem für eine Oracle RAC Installation ist gering, ausgefeilte Locking und Caching Strategie sind nicht notwendig. Das GFS ist hier deutlich anspruchsvoller, damit aber auch deutlich komplexer. Falls jemand von den Lesern praktische Erfahrungen hat mit den einzelnen Filesystemen, bitte mitteilen. Der Review der OCFS Patches auf den Kernel Mailinglisten hat jedenfalls klar gemacht, dass keine allzu aufwändige Entwicklungsarbeit in das Oracle Angebot geflossen ist. Ganz im Gegensatz zum GFS, was ja das Vorzeigeprodukt der aufgekauften Firma Sistina war. Update: in der Diskussion um die Aufnahme von GFS und OCFS2 in den Linux Kernel hat mich Kurt Hackel von Oracle drauf hingeweisen, dass OCFS und OCFS2 durchaus für Oracle Datenfiles gedacht ist. Durch die bessere POSIX Semantik von OCFS2 lassen sich auch die ORACLE_HOME Programmdateien im OCFS2 speichern, was bei OCFS noch nicht möglich war. OCFS wird von Oracle supported, bei OCFS2 stehen wohl die Zertifizerungen noch aus. Der Vorteil eines Filesystems für Oracle Datenfiles liegt ganz klar in der einfacheren Handhabbarkeit, besonders für die Archive Logs. Update2: Im aktuellen OTN TechCast "Inside Oracle's Linux Projects" vom 22. September sprechen Wim Coekaerts (Director of Linux Engineering) und Todd Trichler (OTN's Linux evangelist) über OCFS2: dessen Geschichte, kommerzielle Hintergründe und die Aufnahme in den Main Kernel.
Comments
Display comments as Linear | Threaded
Christian Brabandt on :
Bernd Eckenfels on :
Bernd Eckenfels on :
Bernd Eckenfels on :