Kapitel 2. Überlegungen zur Konfiguration und zum Betrieb von GFS2

GFS2 basiert auf einer 64-Bit-Architektur, die theoretisch ein 8 EB Dateisystem handhaben kann. Allerdings beträgt die derzeit maximal unterstützte Größe für ein GFS2-Dateisystem für 64-Bit-Hardware 100 TB. Die derzeit maximal unterstützte Größe für ein GFS2-Dateisystem für 32-Bit-Hardware beträgt 16 TB.

Beachten Sie, dass große Dateisysteme nicht unbedingt empfehlenswert sind, auch wenn diese mit GFS2 möglich sind. Als Faustregel gilt, dass kleine Dateisysteme mit GFS2 vorzuziehen sind: Es ist besser, 10 Dateisysteme mit 1 TB Kapazität zu haben als ein Dateisystem mit 10 TB Kapazität.

Es gibt mehrere Gründe, warum Sie Ihre GFS2-Dateisysteme klein halten sollten:

Darüber hinaus bedeutet die Pflege von weniger Ressourcengruppen eine bessere Leistung.

Andererseits sollten Sie Ihr GFS2-Dateisystem nicht zu klein machen, da ungenügender Speicherplatz eine Reihe anderer Probleme mit sich bringt. Sie sollten sich über Ihre eigenen Anforderungen im Klaren sein, bevor Sie sich für eine bestimmte Größe entscheiden.

Ab der Red Hat Enterprise Linux 6 Release versucht der Befehl mkfs.gfs2 eine optimale Blockgröße basierend auf der Gerätetopologie zu schätzen. Im Allgemeinen ist 4 K die bevorzugte Blockgröße, da 4 K die standardmäßige Seitengröße (Arbeitsspeicher) für Linux ist. Im Gegensatz zu einigen anderen Dateisystemen führt GFS2 die meisten seiner Operationen mit 4-K-Kernel-Puffern durch. Wenn Ihre Blockgröße 4 K beträgt, hat der Kernel weniger Arbeit bei der Handhabung der Puffer.

Es wird empfohlen, dass Sie die Standardblockgröße verwenden, da diese die beste Leistung bringen sollte. Sie müssen Sie eine andere Blockgröße wahrscheinlich nur dann verwenden, wenn Sie eine effiziente Speicherung von vielen sehr kleinen Dateien benötigen.

GFS2 erfordert ein Journal für jeden Knoten im Cluster, der das Dateisystem einhängen muss. Wenn Sie zum Beispiel einen 16-Knoten-Cluster haben, aber das Dateisystem von nur zwei Knoten eingehängt werden muss, benötigen Sie nur zwei Journale. Wenn Sie von einem dritten Knoten einhängen möchten, können Sie jederzeit ein Journal mit dem Befehl gfs2_jadd hinzufügen. Mit GFS2 können Sie jederzeit Journale im laufenden Betrieb hinzufügen.

Wenn Sie den Befehl mkfs.gfs2 ausführen, um ein GFS2-Dateisystem zu erstellen, können Sie die Größe der Journale festlegen. Wenn Sie keine Größe angeben, wird sie auf 128 MB festgelegt, was für die meisten Anwendungen optimal sein dürfte.

Einige Systemadministratoren könnten meinen, dass 128 MB zu groß ist, und versuchen, die Größe des Journals auf das Minimum von 8 MB oder auf konservativere 32 MB zu reduzieren. Dies könnte zwar funktionieren, kann sich jedoch stark auf den Durchsatz auswirken. Wie in vielen Journaling-Dateisystemen werden jedes Mal, wenn GFS2 Metadaten schreibt, die Metadaten in das Journal übergeben, bevor sie an ihren Platz geschrieben werden. Dadurch wird sichergestellt, dass im Falle eines Systemabsturzes oder Stromausfalls alle Metadaten wiederhergestellt werden, wenn das Journal automatisch beim Einhängen wieder eingespielt wird. Allerdings ist nicht viel Aktivität auf dem Dateisystem notwendig, um ein 8 MB kleines Journal zu füllen, und wenn das Journal voll ist, verlangsamt sich die Leistung, da GFS2 auf die Schreibvorgänge in den Speicher warten muss.

Es wird allgemein empfohlen, die standardmäßige Journalgröße von 128 MB zu verwenden. Wenn Ihr Dateisystem sehr klein ist (z. B. 5 GB), könnte ein 128 MB Journal unpraktisch sein. Wenn Sie ein größeres Dateisystem nutzen und den Platz dafür haben, könnten Journale mit 256 MB die Leistung verbessern.

Wenn ein GFS2-Dateisystem mit dem Befehl mkfs.gfs2 erstellt wird, teilt es den Speicher in gleichmäßige Abschnitte, die Ressourcengruppen genannt werden. Dabei wird versucht, die optimale Größe für die Ressourcengruppen (zwischen 32 MB und 2 GB) abzuschätzen. Sie können diesen Standard mit der Option -r des Befehls mkfs.gfs2 überschreiben.

Die optimale Größe für Ihre Ressourcengruppen hängt davon ab, wie Sie das Dateisystem verwenden werden. Bedenken Sie dabei, wie voll es sein wird und ob es stark fragmentiert sein wird oder nicht.

Sie sollten mit anderen Größen der Ressourcengruppen experimentieren, um zu sehen, welche Größe eine optimale Leistung erzielt. Eine bewährte Methode ist das Experimentieren mit einem Test-Cluster, bevor GFS2 für den Einsatz in der Produktionsumgebung bereitgestellt wird.

Wenn Ihr Dateisystem zu viele Ressourcengruppen hat (von denen jede zu klein ist), können die Blockzuweisungen zu viel Zeit mit der Suche von Zehntausenden (oder Hunderttausenden) von Ressourcengruppen für einen freien Block verschwenden. Je voller das Dateisystem, desto mehr Ressourcengruppen müssen durchsucht werden, und jede von ihnen erfordert eine clusterweite Sperre. Dies führt zu einer verlangsamten Leistung.

Wenn Ihr Dateisystem jedoch zu wenige Ressourcengruppen hat (von denen jede zu groß ist), könnten Blockzuweisungen oft die Sperre der gleichen Ressourcengruppe verlangen, was ebenfalls Auswirkungen auf die Leistung hat. Wenn Sie beispielsweise ein 10 GB großes Dateisystem haben, das in fünf Ressourcengruppen zu je 2 GB aufgeteilt ist, werden die Knoten in Ihrem Cluster um diese fünf Ressourcengruppen öfter kämpfen, als wenn das gleiche Dateisystem in 320 Ressourcengruppen zu je 32 MB aufgeteilt wäre. Das Problem wird noch verschärft, wenn Ihr Dateisystem fast voll ist, da jede Blockzuweisung ggf. durch mehrere Ressourcengruppen suchen muss, bevor sie eine mit einem freien Block findet. GFS2 versucht dieses Problem auf zwei Arten zu verhindern:

Der schlimmste Fall ist ein zentrales Verzeichnis, in dem alle Knoten Dateien erstellen, da in diesem Fall alle Knoten ständig darum kämpfen werden, die gleiche Ressourcengruppe zu sperren.