Unter Linux beschleunigen gleich mehrere Open-Source-Cache-Projekte die Zugriffe auf Festplatten. Mit »dm-cache« lassen sich hybride Datenträger mit einer Kombination aus traditionellen Festplatten und SSDs erstellen. »fs-cache« geht einen anderen Weg: Es puffert Zugriffe auf der Ebene des Dateisystems. Damit ließen sich ebenfalls auch hybride Datenträger mit lokalen Platten und SSDs erstellen. Allerdings empfiehlt sich FS-Cache für einen anderen Zweck: dem Cachen von Netzwerk-Dateisystemen wie NFS.

Bei einer solchen Konfiguration geht es nur in Umwegen darum, den Zugriff auf NFS-Freigaben zu Beschleunigen. Nutzen viele NFS-Clients einen gemeinsamen NFS-Share, reduziert FS-Cache zunächst die Netzwerklast. Mit dem geringeren Traffic auf dem LAN, der niedrigeren Belastung des NFS-Servers und den häufig genutzten Daten im lokalen FS-Cache steigt unweigerlich die Performance bei der  Arbeit mit Netzwerkdateien. Das setzt allerdings voraus, dass die NFS-Clients in erster Linie lesend auf NFS-Freigabe zugreifen. Schreibaktionen müssen unweigerlich den Cache außen vor lassen, um die Kohärenz der gemeinsamen Datenbestände zu gewährleisten.

Anzeige

FS-Cache im Detail

Laut Howto kann der Administrator den FS-Cache eigentlich mit sehr wenigen Schritten in Betrieb setzen. Der Teufel steckt jedoch in ein paar Details, die es zu berücksichtigen gilt.

FS-Cache genügt ein Unterverzeichnis auf einem Dateisystem, welches erweiterte Attribute unterstützt. Das beherrschen XFS, BTRFS und ext4 per Default. Nur bei ext3 muss man diese Funktion separat aktiveren. FS-Cache setzt dabei weder einen exklusiven Datenträger noch eine SSD voraus. Für viele Anwendungen kann es genügen, den Cache auf einer regulären Platte abzulegen.

Per Default nutzt FS-Cache das Verzeichnis /var/cache/FS-Cache für die Zwischenspeicherung. Natürlich lässt sich auch ein anderes Directory verwenden, jedoch ist dabei Vorsicht geboten. Auf Systemen mit aktiviertem selinux – und das sollte bei allen produktiven Linux-Systemen laufen – müssen die Cache-Daten und -Verzeichnisse dem Kontext »cachefiles_var_t« angehören. Setzt der Verwalter ein anderes Verzeichnis für den Cache ein und vergisst, den Kontext anzupassen, wird der Cache Dienst nicht starten.

Natürlich lässt sich der Kontext bestehender Verzeichnisse über »chcon« ändern. Jedoch sind diese Änderungen im Zweifelsfall nicht permanent. Ein System-Update mit neuen Selinux-Regeln könnte die manuelle Korrektur überschreiben. Zusätzlich wäre es also vonnöten, die Änderungen in der Selinux-Datenbank via »semanage fcontext...« einzutragen.

Es gibt jedoch alternativ einen sehr einfachen Trick, um die selinux-Probleme komplett zu umgehen: Der Verwalter belässt einfach die Konfiguration auf dem vorgegebenen Verzeichnis /var/cache/FS-Cache und bindet das Cache-Verzeichnis des SSD-Laufwerks über einen bind-mount ein:

mount –bind /mnt/ssd/fscace /var/cache/fscace

Anders als bei einem symbolischen Link übernimmt das System dann den Selinux-Kontext des Zielverzeichnisses auf alle Daten. Bind Mounts lassen sich in der /etc/fstab eintragen und werden somit beim Systemstart automatisch eingebunden.

FS-Cache einrichten

Der FS-Cache Dienst wird auf RPM-basierten Linux-Systemen über das Paket cachefilesd bereitgestellt:

yum install cachefilesd

Auf Systemen mit RHEL/Centos/Scientiffic bis zur Version 6 wird der Dienst mit

chkconfig cachefiled on

aktiviert. Auf neueren Versionen mit »Systemd« lautet das Kommando entsprechend:

systemctl enable chacefilesd.service

Die Konfiguration des Dienstes liegt in /etc/cachefiled

Die Parameter des Konfigurationsdatei erklären sich weitgehend von selbst: »dir« gibt an, wo der Cache liegt und »secctx« spezifiziert den Security Linux Kontext. Die verschiedenen %-Parameter geben die Grenzwerde für Blöcke und Dateien im Cache an. Sie limitieren die Cache Nutzung bestimmen, ab welchem Füllstand der Cache bereinigt wird. Die optimale Konfiguration dieser Parameter hängt ganz vom Einsatzgebiet ab.

Sobald die Konfiguration stimmt und das Cache-Verzeichnis korrekt angelegt oder eingebunden wurde, lässt sich der Dienst starten

systemctl start cachefilesd.service

oder

service cahchefilesd start

je nach verwendeter Distribution. Ob der Dienst ordnungsgemäß gestartet wurde verrät

systemctl status cachefilesd.service

oder

service cachefiled status.

Erscheint hier eine Fehlermeldung, gibt es in der Regel Probleme mit dem Selinux-Kontext des Cache-verzeichnisses.

FS-Cache nutzen

Sobald der FS-Cache-Daemon läuft, lässt er sich über das Mount-Kommando einbinden. Eine NFS-Freigabe binde das System dann mit der Option »fsc« ein:

mount -t nfs -o fsc server:/nfs /mnt/nfs

ebenso lässt sich diese Option in /etc/fstab einbinden oder in eine der Auto-Mounter-Konfigurationsdateien.

Greift das System nun auf die NFS-Freigabe zu, legt FS-Cache von jeder benutzten Datei eine Kopie im lokalen Cache an. Zugriffe auf bereits verwendete Dateien liefert fortan FS-Cache aus. Über die eigentliche NFS-Verbindung wird zuvor lediglich geprüft, ob die gecachte Datei nach wie vor aktuell ist oder sich das Original verändert hat und neu geladen werden muss.

FS-Cache Testen

Ein simpler Test prüft, ob das Caching ordnungsgemäß arbeitet. Kopieren sie dazu eine Datei von einem NFS-Mount, der mit der Option »fsc« eingebunden wurde zweimal hintereinander via dd auf die lokale Platte oder das Nul-Device.

sudo dd if=/nfsmount/datei.bin of=/dev/nul bs=8192

Der zweite Copy-Vorgang sollte dabei deutlich schneller arbeiten und keine Last auf dem LAN erzeugen. Zudem muss auf dem Cache-Datenträger der Größe der kopierten Datei entsprechend weniger Platz frei sein.

Hier endet die Workshop-Serie zum Thema NAS im Eigenbau. In einer neuen Workshop-Serie wird sich speicherguide.de mit Software defined Storage Lösungen beschäftigen. In Kürze beginnen wir einen mehrteiligen Workshop zum verteilten Objekt- und Blockspeichersystem Ceph.