Red Hats Global File System GFS2

Red Hats Global File System GFS2

Lastverteilung und Hochverfügbarkeit im SAN stellen hohe Ansprüche nicht zuletzt an das Dateisystem. Das Cluster-Dateisystem GFS2 ist angetreten, sich diesen Anforderungen zu stellen.

Klassische Fileserver, die etwa NFS verwenden, stellen lokale Dateisysteme via Netzwerk zur Verfügung. Dabei bilden allerdings sowohl der Server als auch der Massenspeicher einen Single Point of Failure (SPOF). Will man das umgehen, indem man mehrere Server installiert, die über den gleichen Datenbestand verfügen, ergeben sich jedoch neue Probleme, denn eine Grundvoraussetzung dieses Konzepts ist die synchrone oder zumindest zeitnahe Replikation der Daten. Das ist mit zunehmender Datenmenge aber kein einfaches Unterfangen mehr. Dieses Dilemma löst sich, sobald man Shared Devices verwendet. Hier haben alle beteiligten Rechner direkten Zugriff auf dasselbe Speichergerät. Cluster-Dateisysteme regeln dann sich überschneidende die Zugriffe auf die Dateien. Red Hats Global File System 2 (GFS2) gehört zu dieser Gruppe von Filesystemen und zum Lieferumfang des Vanilla-Kernels. Neben dem Dateisystem selbst sind Locking- und Fencing-Mechanismen zentrale Bestandteile von GFS2.

Verschiedene Szenarien

Für den Einsatz von GFS2 sind verschiedene Szenarien möglich, die sich hinsichtlich Preis, Performance und Skalierbarkeit unterscheiden (Abbildung 1). In jedem Fall gibt es eine Reihe von Applikationsservern, die auf ein Shared Filesystem zugreifen. Tun sie das auf direktem Weg (typischerweise via Fibre Channel oder iSCSI), bietet das GFS die beste Leistung. Allerdings ist diese Architektur auch die teuerste Variante. Im zweiten Szenario erhält nur eine begrenzte Anzahl von Rechnern direkten Zugriff auf das SAN. Diese Server fungieren dann als GNDB-Server (Global Network Block Device) und exportieren SAN-Blockgeräte an die Applikationsrechner. Für die ist es dann wieder so, als hätten sie direkten Zugriff auf den Storage. Das Einfügen der GNDB-Schicht geht allerdings zu Lasten der Performance. Außerdem muss sich der Anwender gegen den Ausfall eines GNDB-Servers versichern. Im dritten Fall existiert kein SAN. GNDB-Server exportieren stattdessen lokale Massenspeicher über das Netzwerk an die Applikationsserver. Da GFS2 nicht mehrere Blockgeräte in einem Dateisystem verwalten kann, muss der Admin eine weitere logische Schicht einziehen und die Blockgeräte zu einem virtuellen Gerät zusammenfassen.

Abbildung 1: Beim GFS2-Einsatz sind verschiedene Szenarien möglich, beispielsweise mit und ohne GNDB-Server.
Abbildung 2: Der Schichtaufbau der GFS2-Architektur.

Aus Sicht der Applikationsserver ist es wiederum so, als hätten sie direkten Zugriff auf ein Blockgerät. Diese Architektur macht allerdings jeden GNDB-Server zu einem Single Point of Failure – man muss also zusätzliche Failover-Mechanismen implementieren, die die Ausfallsicherheit erhöhen.

Parallele Schreibzugriffe

Im Cluster-Dateisystem ist völlig natürlich, was sonst verboten ist, nämlich dass mehrere Rechnerknoten auf dieselben Datenblöcke zugreifen. GFS2 verwendet einen Locking-Mechanismus, diese Zugriffe zu koordinieren und so Inkonsistenzen des Dateisystems zu vermeiden. Dabei stehen zwei verschiedene Lock-Modi zur Auswahl. Zum einen kann GFS2 den Distributed Lock Manager (DLM) benutzen, der auch in der Red Hat Cluster Suite zum Einsatz kommt. Alle Cluster-Knoten sind am Locking beteiligt, eine extra Locking-Konfiguration entfällt. Das Kernel-Modul »lock_dlm.ko« und die Bibliothek »libdlm.so« stellen die DLM-Funktion bereit, die erste Wahl für GFS2 ist. Prinzipiell kann GFS2 auch im Single-NodeModus laufen. Es verhält sich dann wie ein lokales nicht-clusterfähiges Dateisystem und benötigt keinen Cluster-Stack. Weil auch das Cluster-Locking nicht mehr nötig ist, konfiguriert der Admin die Locking-Methode »nolock«. Auf Kernel-Seite benötigt man dafür das Modul »lock_nolock.ko«.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023