Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

2.5.5. Einrichten von NFS auf GFS2

Durch die zusätzliche Komplexität des GFS2-Sperrsubsystems und dessen vernetzter Natur erfordert das Einrichten von NFS über GFS2 viele Vorsichtsmaßnahmen und sorgfältige Konfiguration. Dieser Abschnitt beschreibt die Einschränkungen, die Sie bei der Konfiguration eines NFS-Dienstes auf einem GFS2-Dateisystem berücksichtigen sollten.

Warnung

Falls das GFS2-Dateisystem per NFS exportiert wird und NFS-Client-Applikationen POSIX-Sperren verwenden, dann müssen Sie das Dateisystem mit der Option localflocks einhängen. Dadurch werden POSIX-Sperren von jedem Server dazu gezwungen, lokale sperren zu sein, d. h. nicht geclustert und unabhängig voneinander. (Es können eine Reihe von Problemen auftreten, falls GFS2 versuchen sollte, POSIX-Sperren von NFS auf den Knoten in einem Cluster zu implementieren.) Für Applikationen, die auf NFS-Clients laufen, bedeuten lokale POSIX-Sperren, dass zwei Clients gleichzeitig dieselbe Sperre halten können, falls die beiden Clients von verschiedenen Servern aus einhängen. Wenn alle Clients NFS nur von einem Server aus einhängen, dann stellt sich das Problem nicht, dass verschiedene Server unabhängig voneinander dieselbe Sperre vergeben. Wenn Sie nicht sicher sind, ob Sie Ihr Dateisystem mit der localflocks-Option einhängen sollen, dann sollten Sie die Option nicht verwenden. Es ist immer sicherer, die Sperren auf einer geclusterten Grundlage zu verwenden.
Zusätzlich zu den Überlegungen hinsichtlich der Sperren sollten Sie Folgendes bedenken, wenn Sie einen NFS-Dienst auf einem GFS2-Dateisystem konfigurieren.
  • Red Hat unterstützt nur solche Konfigurationen des Red Hat High Availability Add-Ons, die NFSv3 mit Sperren in einer Aktiv/Passiv-Konfiguration mit den folgenden Eigenschaften verwenden:
    • Das zugrunde liegende Dateisystem ist ein GFS2-Dateisystem, das auf einem Cluster mit 2 bis 16 Knoten läuft.
    • Ein NFSv3-Server ist als ein Dienst definiert, der das gesamte GFS2-Dateisystem zu jeder Zeit von nur einem einzigen Cluster-Knoten exportiert.
    • Der NFS-Server kann im Rahmen der Ausfallsicherung von einem Cluster-Knoten auf einen anderen wechseln (Aktiv/Passiv-Konfiguration).
    • Außer über den NFS-Server ist keinerlei Zugriff auf das GFS2-Dateisystem gestattet. Das betrifft sowohl lokalen GFS2-Dateisystemzugriff als auch den Zugriff über Samba oder Clustered Samba.
    • Es gibt keine NFS-Kontingentunterstützung auf dem System.
    Diese Konfiguration bietet Hochverfügbarkeit für das Dateisystem und reduziert Ausfallzeiten, da ein ausgefallener Knoten nicht dazu führt, dass der fsck-Befehl ausgeführt werden muss, wenn der NFS-Server von einem Knoten auf einen anderen wechselt.
  • Die NFS-Option fsid = ist zwingend erforderlich für NFS-Exporte auf GFS2.
  • Falls Probleme mit Ihrem Cluster auftreten (falls z. B. der Cluster das Quorum verliert und das Fencing nicht erfolgreich ist), werden die geclusterten logischen Datenträger und das GFS2-Dateisystem eingefroren und der Zugriff ist erst wieder möglich, wenn der Cluster wieder ein Quorum erlangt. Sie sollten diese Möglichkeit bei der Entscheidung berücksichtigen, ob eine einfache Ausfallsicherungslösung, wie in diesem Verfahren beschrieben, für Ihr System geeignet ist.