Red Hat Training

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

2.3.2. Dateizuweisung durch die jeweiligen Knoten, wenn möglich

Aufgrund der Funktionsweise des Distributed Lock Managers (DLM) treten mehr Sperrkonflikte auf, wenn alle Dateien von einem Knoten zugeordnet wurden und andere Knoten Blöcke zu diesen Dateien hinzufügen müssen.
In GFS (Version 1) wurden alle Sperren von einem zentralen Sperrmanager verwaltet, dessen Aufgabe es war, die Sperren im gesamten Cluster zu steuern. Dieser zentrale Sperrmanager (Grand Unified Lock Manager oder kurz GULM) war problematisch, da er einen Single-Point-of-Failure bildete. Das neue Sperrschema in GFS2 – DLM – verteilt die Sperren im gesamten Cluster. Wenn ein Knoten im Cluster ausfällt, werden die Sperren von den anderen Knoten wiederhergestellt.
Mit DLM wird der erste Knoten, der eine Ressource (z. B. eine Datei) sperrt, zum Besitzer („lock master“) der Sperre. Andere Knoten können diese Ressource zwar sperren, müssen jedoch zunächst den Besitzer der Sperre um Erlaubnis bitten. Jeder Knoten weiß, welche Sperren er besitzt, und jeder Knoten weiß, welchen anderen Knoten er eine Sperre geliehen hat. Das Erstellen einer Sperre auf dem Besitzerknoten ist viel schneller als Sperren auf einem anderen Knoten, der unterbrechen und den Besitzer der Sperre um Erlaubnis bitten muss.
Wie in vielen Dateisystemen versucht die GFS2-Zuweisung, Blöcke der selben Datei nahe beieinander zu platzieren, um die Bewegung der Festplattenköpfe zu reduzieren und die Leistung zu steigern. Ein Knoten, der Blöcke einer Datei zuweist, muss wahrscheinlich die gleichen Ressourcengruppen für die neuen Blöcke verwenden und sperren (es sei denn, alle Blöcke in der Ressourcengruppe werden bereits verwendet). Das Dateisystem wird schneller laufen, wenn der Besitzer der Sperre für die Ressourcengruppe, welche die Datei enthält, seine Datenblöcke zuordnet (das heißt, es ist schneller, wenn der Knoten, der zuerst die Datei öffnete, alle Schreibvorgänge von neuen Blöcken durchführt).