2.9. GFS2-Knotensperrung


Um die beste Leistung aus einem GFS2-Dateisystem herauszuholen, ist es wichtig, einige Aspekte der zugrunde liegenden Theorie zu verstehen. Ein Ein-Knoten-Dateisystem wird zusammen mit einem Cache implementiert, um die Latenz der Plattenzugriffe für häufig aufgerufene Daten zu verringern. In Linux erfüllt der Seiten-Cache (und historisch der Puffer-Cache) diese Caching-Funktion.
Bei GFS2 besitzt jeder Knoten seinen eigenen Seiten-Cache, der einen Teil der Festplattendaten enthalten kann. GFS2 verwendet ein Sperrverfahren namens Glocks (ausgesprochen „Dschie-Locks“), um die Integrität der Caches auf allen Knoten zu bewahren. Das Glock-Untersystem liefert eine Cache-Verwaltungsfunktion, die unter Verwendung des Distributed Lock Managers (DLM) als zugrunde liegende Kommunikationsschicht implementiert ist.
Glocks schützen den Cache auf Inode-Basis, das heißt es gibt eine Sperre pro Inode, die zur Steuerung der Caching-Schicht verwendet wird. Wird das Glock im gemeinsamen Modus (DLM-Sperrmodus: PR) zugewiesen, so dürfen die Daten unter diesem Glock auf einem oder mehreren Knoten gleichzeitig gecacht werden, sodass alle Knoten lokalen Zugriff auf diese Daten haben.
Wird das Glock im exklusiven Modus (DLM-Sperrmodus: EX) zugewiesen, so darf nur ein einziger Knoten die Daten unter diesem Glock cachen. Dieser Modus wird von allen Operationen genutzt, die Daten verändern (z. B. der write-Systemaufruf).
Falls ein anderer Knoten ein Glock anfordert, das jedoch nicht sofort zugewiesen werden kann, dann sendet der DLM eine Nachricht an die Knoten, die derzeit das Glock halten und dadurch die Anfrage blockieren, damit diese ihre Sperren verwerfen. Das Verwerfen von Glocks kann (gemessen an den Maßstäben der meisten Dateisystemoperationen) ein langwieriger Vorgang sein. Das Verwerfen eines gemeinsam verwendeten Glocks erfordert lediglich, dass der Cache für ungültig erklärt wird (Invalidierung), was vergleichsweise schnell und proportional zur Menge der gecachten Daten ist.
Das Verwerfen eines exklusiven Glocks erfordert die Bereinigung der Protokolle und das Schreiben sämtlicher veränderter Daten auf die Festplatte, gefolgt von der Invalidierung des Caches wie beim gemeinsam verwendeten Glock.
Der Unterschied zwischen einem Ein-Knoten-Dateisystem und GFS2 besteht darin, dass ein Ein-Knoten-Dateisystem über einen einzigen Cache verfügt, während GFS2 über separate Caches auf jedem Knoten verfügt. In beiden Fällen ist die Latenz beim Zugriff auf gecachte Daten ähnlich groß, allerdings ist die Latenz beim Zugriff auf nicht gecachte Daten deutlich größer mit GFS2, wenn ein anderer Knoten bereits dieselben Daten gecacht hatte.

Anmerkung

Aufgrund der Art und Weise, wie Caching in GFS2 implementiert ist, erreichen Sie die beste Leistung in einer dieser beiden Fälle:
  • Ein Inode wird auf allen Knoten nur zum Lesezugriff verwendet.
  • Schreibzugriffe auf einen Inode erfolgen nur von einem einzigen Knoten aus.
Beachten Sie, dass das Einfügen und Entfernen von Einträgen aus einem Verzeichnis bei der Dateierstellung oder -löschung als Schreibvorgang in den Verzeichnis-Inode gilt.
Es ist möglich, diese Regel zu ignorieren, sofern dies nur selten geschieht. Wird diese Regel zu oft missachtet, sind erhebliche Leistungseinbußen die Folge.
Falls Sie mmap() für eine Datei auf einem GFS2-Dateisystem mit einem Lese/Schreib-Mapping anwenden, diese Datei jedoch nur lesen, zählt dies als Lesevorgang. Auf GFS dagegen zählt dies als Schreibvorgang, sodass GFS2 sehr viel skalierbarer ist mit mmap() I/O.
Falls Sie den Parameter noatime mount nicht setzen, führen Lesevorgänge auch zu Schreibvorgängen, um die Timestamps der Datei zu aktualisieren. Wir empfehlen im Allgemeinen, dass alle GFS2-Benutzer mit noatime einhängen sollten, sofern kein besonderer Grund für die Verwendung von atime vorliegt.

2.9.1. Probleme mit Posix-Sperren

Bei der Verwendung von Posix-Sperren sollten Sie die folgenden Aspekte berücksichtigen:
  • Die Verwendung von Flocks ermöglicht eine schnellere Verarbeitung als die Verwendung von POSIX-Sperren.
  • Programme, die POSIX-Sperren in GFS2 verwenden, sollten die GETLK-Funktion vermeiden, da sich in einer Cluster-Umgebung die Prozess-ID auf einen anderen Knoten im Cluster beziehen kann.
Red Hat logoGithubRedditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

© 2024 Red Hat, Inc.