Tuning

Je nach Anwendung, die auf das GFS2 zugreift, kann ein weiteres Tuning des Dateisystems erforderlich sein. Bei GFS2 ist standardmäßig die Aktualisierung der Zeit des letzten Zugriffs (»atime«) eingeschaltet. Es gibt zwei Ansätze, um an den »atime«-Parametern zu drehen. Mit der Mount-Option »noatime« kann man die Aktualisierung komplett abschalten. Mit dem GFS2-Tuning-Werkzeug »gfs2_tool« kann der Admin die Aktualisierung des Zeitstempels auf Datei-Ebene abschalten. Der mit Ext2/Ext3 vertraute Benutzer fühlt sich an das Kommando »chattr +A« erinnert. Analog versteht GFS2 folgende Datei-Attribute: »jdata«, »immutable«, »appendonly«, »noatime« und »sync«. Tabelle 2 enthält weitere Details und Querverweise zu den entsprechenden Kommandos für Ext2/3.

Tabelle 2. Datei-Attribute bei GFS2

Attribut

 Beschreibung

 Ext2/3-Kommando

jdata

alle Daten erst ins Journal schreiben

»chattr +j«

immutable

Nur-Lese-Zugriffe erlauben

»chattr +i«

appendonly

Nur Anhängen von Daten erlauben

»chattr +a«

noatime

Zeitpunkt des letzten Zugriffs nicht aktualisieren

»chattr +A«

sync

Daten nicht puffern und sofort auf Datenträger schreiben

»chattr +S«

 

Mit »gfs2_tool« kann man eine Reihe von GFS2-Ioctl-Calls absetzen, in den meisten Fällen muss das Dateisystem gemountet sein. Mit diesem Tool hat der Admin Zugriff auf die im Superblock gespeicherten Informationen und auf Statistikinformationen über das Dateisystem. Einige Beispielaufrufe befinden sich in Listing 5; »gfs2_tool ‑h« gibt eine kurze Onlinehilfe aus.

Listing 5: GFS2-Tuning mit GFS2-Tool

# gfs2_tool sb /dev/sda1 all
  mh_magic = 0x01161970
  mh_type = 1
  mh_format = 100
  sb_fs_format = 1801
  sb_multihost_format = 1900
  sb_bsize = 4096
  sb_bsize_shift = 12
  no_formal_ino = 2
  no_addr = 22
  no_formal_ino = 1
  no_addr = 21
  sb_lockproto = lock_dlm
  sb_locktable = gfs2:gfs2test
  uuid = 0EA2D58C‑7D9F‑743A‑456E‑5047AD0F0FC6
# gfs2_tool journals /gfs2data/
journal1 ‑ 128MB
journal0 ‑ 128MB
2 journal(s) found.

Neu hinzugekommen beim Wechsel von GFS1 zu GFS2 ist Programm »gfs2_edit«. Damit kann der Admin noch tiefer in Dateisystem-Interna schauen. Dieses Werkzeug zeigt beispielsweise Detailinformationen über den Superblock, die Metadaten, reale Daten oder Storage-Größe an. Außerdem erlaubt es dem Systemadminstrator schreibend in die Dateisystem-Struktur einzugreifen. Von Praxisnutzen ist das Ändern des Allokierungstyps eines Blocks von belegt zu frei oder umgekehrt. Weitere Details und Beispielaufrufe befinden sich in der Online-Hilfe.

Für manche Applikationen ist es vorteilhaft, den Lese- und Schreib-Cache des Betriebssystems zu umgehen und direkt auf den Datenträger zu schreiben. Auf diese Direct-I/O-Technik trifft man beispielsweise bei Datenbanken. Während bei GFS1 diese Eigenschaft nur auf DateiEbene einzuschalten war, beherrscht GFS2 dies für den gesamten Mountpunkt. Standardmäßig ist Direct-I/O abgeschaltet, doch der Aufruf »gfs2_tool Mountpunkt new_files_directio 1« aktiviert es. Eine zusätzliche Mount-Option ist dabei nicht nötig. Mit »gfs2_tool Mountpunkt new_files_directio 0« stellt der Admin den Ausgangszustand wieder her.

GFS2 beherrscht auch Data-Journaling. Hier schreibt das Dateisystem neben den Metadaten auch die eigentlichen Daten in das Journal. In der Dateisystem-Statistik zeigt sich das daran, dass mehr Metadatenblöcke allokiert sind. Das entsprechende Flag heißt »new_files_jdata« und wird ebenfalls mit dem Tool »gfs2_tool« ein- beziehungsweise ausgeschaltet.

Ist kein CLVM im Einsatz, ist die »freeze«-Funktion von »gfs2_tool« recht nützlich. Damit kann der Admin jeden Schreibzugriff auf das gemountete GFS2 unterbinden. Die Systemaufrufe, wie »unlink()« oder »mkdir()«, bleiben einfach stehen, Lesezugriffe sind aber weiterhin erlaubt. In diesem Zustand kann man ein Backup fahren oder ein Speicherabbild für computerforensische Untersuchungen anlegen. Ein »gfs2_tool unfreeze MountPunkt« öffnet das Dateisystem wieder für Schreibzugriffe. Ist GFS2 zusammen mit CLVM im Einsatz, empfiehlt sich die Nutzung von Snapshots für die Datensicherung. Aus verschiedensten Gründen sollte die Systemzeit aller Cluster-Knoten synchronisiert sein. Beim Cluster-Dateisystem würden Clients, die zeitlich nicht synchron laufen, durch Inode-Updates unnötige Schreibzugriffe verursachen. Die Konfiguration der Rechner als NTP-Clients ist daher auch aus Performance-Gründen empfehlenswert.

Verwaltung für Fortgeschrittene

Eine notwendige Überlegung vor dem Anlegen des GFS2 gilt der Frage, wie viele Knoten auf das Dateisystem zugreifen sollen. Die Anzahl der Journale ist entsprechend zu wählen. Ein sehr simpler Ansatz wäre, einfach 256 Journale anzulegen. Dagegen spricht, dass dann GFS2 in der Standardeinstellung 32 GByte für alle Journal Dateien reserviert – Platz, der nicht mehr für Nutzdaten zur Verfügung steht. In Zeiten, in denen man selbstverständlich mit TByte umgeht, ist das nicht unbedingt ein großes Problem, aber elegant wäre dieses Vorgehen dennoch auf keinen Fall.

Zum Zweiten muss der Cluster-Knoten, der das GFS2 als erster mounten soll, alle Journale einlesen und auswerten – eine vermeidbare Zeitverzögerung. Sollte sich die ursprüngliche Journal-Anzahl tatsächlich als zu klein erweisen, gibt es zwei Auswege: das Dateisystem komplett neu aufsetzen oder das Kommando »gfs2_jadd«. Mit »gfs2_jadd« erhöht man die Anzahl der Journale im GFS. Der Admin gibt bei »gfs2_jadd« die Anzahl der zu addierenden Journale an und kann sogar eine andere Größe der Journal-Datei wählen.

Wie jedes gute Dateisystem beherrscht GFS2 auch Online-Resizing, zumindest teilweise. Mit »gfs2_grow« kann man das Dateisystem im gemounteten Zustand vergrößern, jedoch nicht verkleinern. Beim Starten prüft »gfs2_grow«, wie viel Platz zwischen dem Ende des Dateisystems und dem Ende des zugrundeliegenden Massenspeichers vorhanden ist, und allokiert anschließend diesen Raum für neue Resource Groups. Ein zu 100 Prozent gefülltes GFS2 lässt sich al-

lerdings nicht so einfach vergrößern. Der Grund ist, dass GFS2 Platz benötigt, um die neuen Metadaten abzulegen. Ist dies nicht möglich, kann der Admin GFS2 nicht vergrößern. Abhilfe schafft hier leider nur das, zumindest temporäre, Löschen von Nutzdaten.

Das GFS2 aus dem Beispiel-Cluster besitzt nur zwei Journaldateien. Sollte nun ein dritter Rechner hinzugefügt werden, könnte dieser das Global File System nicht mounten. Im Syslog würde sich eine entsprechende Fehlermeldung finden. Mit »gfs2_jadd« ist es nun aber möglich, weitere Journale hinzuzufügen. Bei GFS1 war es ohne zusätzlichen Storage überhaupt nicht möglich, weitere Journale hinzuzufügen. Diese Beschränkung gibt es bei GFS2 glücklicherweise nicht mehr. Anhand der verwendeten Journalgröße kann man leicht ausrechnen, wie viel zusätzlicher Speicherplatz dafür notwendig ist. Sind genügend Journale vorhanden, dann steht der übrig bleibende Platz für eine Vergrößerung des Dateisystems selbst zur Verfügung.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023