2.9.2. Leistungsoptimierung mit GFS2

Normalerweise ist es möglich, für eine problematische Applikation die Art und Weise anzupassen, wie diese ihre Daten speichert, um dadurch eine erheblich bessere Leistung zu erreichen.

Ein typisches Beispiel für eine problematische Applikation ist ein E-Mail Server. Diese verfügen oft über ein Spool-Verzeichnis, das Dateien für jeden Benutzer enthält (mbox) oder über ein Verzeichnis für jeden Benutzer, das eine Datei für jede Nachricht enthält (maildir). Wenn Anfragen über IMAP eingehen, wird idealerweise jedem Benutzer eine Affinität zu einem bestimmten Knoten zugewiesen. Auf diese Weise werden deren Anfragen zum Ansehen und Löschen von E-Mails tendenziell vom Cache auf diesem Knoten bedient. Falls dieser Knoten ausfällt, kann die Sitzung natürlich auf einem anderen Knoten neu gestartet werden.

Wenn E-Mail über SMTP eingeht, können die einzelnen Knoten so eingerichtet werden, dass sie die E-Mails eines bestimmten Benutzers standardmäßig an einen bestimmten Knoten weiterleiten. Falls dieser Knoten nicht läuft, kann der empfangende Knoten die Nachricht direkt im Mail-Spool-Verzeichnis des Benutzers speichern. Dieser Aufbau dient dazu, eine bestimmte Gruppen von Dateien im Normalfall vorrangig auf einem einzigen Knoten zwischenzuspeichern, erlaubt jedoch direkten Zugriff im Falle eines Knotenausfalls.

Dieser Aufbau nutzt den Seiten-Cache von GFS2 optimal aus und macht darüber hinaus Ausfälle für die Applikation (imap oder smtp) transparent.

Die Datensicherung (Backup) ist ebenfalls oft problematisch. Falls möglich, ist es sehr von Vorteil, das Working Set eines jeden Knotens direkt von dem Knoten zu sichern, der diese bestimmte Gruppe von Inodes cacht. Falls Sie zur Datensicherung ein Skript nutzen, das regelmäßig zu einem bestimmten Zeitpunkt ausgeführt wird, und dieser Zeitpunkt mit einer Spitze in der Reaktionszeit einer auf GFS2 laufenden Applikation zusammenfällt, dann deutet dies mit ziemlicher Sicherheit darauf hin, dass der Cluster den Seiten-Cache nicht effizient genug verwendet.

Falls Sie sich in der glücklichen Position befinden, die Applikation zur Datensicherung stoppen zu können, stellt dies natürlich kein Problem dar. Wird die Datensicherung nur von einem Knoten durchgeführt, wird andererseits nach Abschluss der Sicherung ein großer Teil des Dateisystems auf diesem Knoten gecacht, was Leistungseinbußen für nachfolgende Zugriffe von anderen Knoten zur Folge hat. Bis zu einem gewissen Grad kann dies vermieden werden, indem Sie nach Abschluss der Datensicherung den VFS-Seiten-Cache auf dem Backup-Knoten mit dem folgenden Befehl bereinigen:

echo -n 3 >/proc/sys/vm/drop_caches

Eine bessere Lösung besteht jedoch darin, sicherzustellen, dass das Working Set auf jedem Knoten gemeinsam hauptsächlich für Lesezugriffe im Cluster verwendet wird oder dass weitgehend nur von einem einzigen Knoten darauf zugegriffen wird.