Red Hat Training

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

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

Das GFS2-Dateisystem (Global File System 2) ermöglicht es mehreren Computern („Knoten“) in einem Cluster, kooperativ denselben Speicher zu verwenden. Um diese Zusammenarbeit zu erreichen und die Datenkonsistenz zwischen den Knoten aufrechtzuerhalten, verwenden die Knoten ein clusterweites Sperrschema für die Dateisystemressourcen. Dieses Sperrschema verwendet Kommunikationsprotokolle wie TCP/IP, um Sperrinformationen auszutauschen.
Sie können die Leistung verbessern, indem Sie den in diesem Kapitel beschriebenen Empfehlungen folgen, darunter Empfehlungen zur Erstellung, Verwendung und Pflege eines GFS2-Dateisystems.

Wichtig

Stellen Sie sicher, dass Ihre Bereitstellung des Red Hat High Availability Add-Ons Ihren Anforderungen gerecht wird und unterstützt werden kann. Beratschlagen Sie sich dazu ggf. mit einem autorisierten Red Hat Vertreter, um Ihre Konfiguration vor der Bereitstellung zu prüfen.

2.1. Überlegungen zur Formatierung

Dieser Abschnitt gibt Empfehlungen, wie Sie Ihr GFS2-Dateisystem formatieren sollten, um die Leistung zu optimieren.

2.1.1. Dateisystemgröße: Kleiner ist besser

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:
  • Es wird weniger Zeit benötigt, um eine Sicherungskopie jedes Dateisystems zu erstellen.
  • Es wird weniger Zeit benötigt, wenn Sie das Dateisystem mit dem Befehl fsck.gfs2 überprüfen müssen.
  • Es wird weniger Arbeitsspeicher benötigt, wenn Sie das Dateisystem mit dem Befehl fsck.gfs2 überprüfen müssen.
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.

2.1.2. Blockgröße: Standardblöcke (4 K) werden bevorzugt

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.

2.1.3. Anzahl der Journale: Eines für jeden einhängenden Knoten

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.

2.1.4. Journalgröße: Standard (128 MB) ist in der Regel optimal

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.

2.1.5. Größe und Anzahl der Ressourcengruppen

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:
  • Erstens: Wenn eine Ressourcengruppe gänzlich voll ist, merkt sich GFS2 das und versucht, diese für spätere Zuweisungen nicht mehr zu prüfen (bis ein Block freigegeben wird). Wenn Sie niemals Dateien löschen, werden die Konflikte weniger schwerwiegend sein. Wenn Ihre Anwendung allerdings ständig auf einem fast vollen Dateisystem Blöcke löscht und neue Blöcke zuweist, werden die Konflikte sehr hoch sein, was sich stark auf die Leistung auswirken wird.
  • Zweitens: Wenn neue Blöcke zu einer vorhandenen Datei hinzugefügt werden (z. B. durch Anhängen), wird GFS2 versuchen, die neuen Blöcke in derselben Ressourcengruppe wie die Datei zu gruppieren. Dies geschieht, um die Leistung zu erhöhen: Auf einer sich drehenden Festplatte wird die Suche weniger Zeit benötigen, wenn die Blöcke physisch nahe beisammen liegen.
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.