NFS-Exports und Mounts, die sicher ausfallen

NFS ist eines der ältesten Werkzeuge im Koffer eines Linux-Administrators, und eines der einfachsten, um es beinahe richtig zu machen. Ein Share, das mountet, ist nicht dasselbe wie ein Share, das sich gut verhält, wenn das Netzwerk kurz aussetzt, wenn ein Client sich danebenbenimmt oder wenn der Filer neu startet. Hier sind die Einstellungen und Prüfungen, die den Unterschied machen, auf beiden Seiten des Mounts.

Warum geteilte Dateien schiefgehen

Der übliche Grund für NFS ist eine Gruppe von Web- oder Anwendungsservern, die dieselben Dateien sehen müssen: hochgeladene Medien, generierte Assets, ein geteilter Dokumentenbaum. Es wird schnell eingerichtet, oft durch Kopieren eines Beispiels, und funktioniert beim ersten Versuch. Die Probleme zeigen sich später. Ein Export, der für ein ganzes Netzwerk offen ist, lässt eine vergessene Testmaschine in Produktionsinhalte schreiben. Ein Client, der mit Optionen gemountet ist, die bei Fehlern aufgeben, verliert Schreibvorgänge still. Ein Server, der seinen Filer beim Boot nicht erreicht, hängt minutenlang, statt ohne das Share zu starten. Nichts davon ist an dem Tag sichtbar, an dem es konfiguriert wird.

Auf dem Filer: an Namen exportieren, Root squashen

Exportieren Sie jedes Share an die Hosts, die es brauchen, namentlich, mit den engsten Rechten, die funktionieren:

# /etc/exports
/export/web   web1.example.internal(rw,sync,root_squash,no_subtree_check) \
              web2.example.internal(rw,sync,root_squash,no_subtree_check)
/export/media media-reader.example.internal(ro,sync,root_squash,no_subtree_check)

Benannte Hosts, keine Netzwerke. Ein Wildcard oder ein ganzes Subnetz bedeutet, dass jede Maschine, die je in diesem Netzwerk landet, das Share mounten kann. Hosts aufzulisten macht jeden Client zu einer bewussten Entscheidung.

root_squash. Root auf einem Client wird auf dem Filer zu einem unprivilegierten Benutzer. Ohne das gehört jedem mit Root auf irgendeinem Client jede Datei auf dem Share.

sync. Der Server bestätigt einen Schreibvorgang erst, nachdem er auf stabilen Speicher geschrieben wurde. Die schnellere Alternative bestätigt Schreibvorgänge, die ein Stromausfall noch löschen könnte.

Wenden Sie an und prüfen Sie, was tatsächlich exportiert wird, was nicht immer das ist, was Sie geschrieben zu haben glauben:

exportfs -ra
exportfs -v

Beschränken Sie den Dienst dann an der Host-Firewall auf dieselben Clients. Mit firewalld hält eine eigene Zone es lesbar:

firewall-cmd --permanent --new-zone=nfsclients
firewall-cmd --permanent --zone=nfsclients --add-source=<client address>
firewall-cmd --permanent --zone=nfsclients --add-service=nfs
firewall-cmd --reload

Exports und Firewall-Regeln sind zwei unabhängige Schlösser. Nutzen Sie beide.

Auf dem Client: Hard Mounts, die den Boot nicht aufhängen

Die Client-Seite entscheidet, was passiert, wenn der Filer langsam oder kurz unerreichbar ist:

# /etc/fstab
filer.example.internal:/export/web  /srv/web  nfs  hard,proto=tcp,timeo=600,retrans=2,_netdev,nofail,x-systemd.mount-timeout=30  0 0

hard, nicht soft. Ein Hard Mount versucht es weiter, bis der Server antwortet. Ein Soft Mount liefert nach einer Zahl von Versuchen einen Fehler, und viele Anwendungen prüfen diesen Fehler beim Schreiben nicht, sodass Daten verloren gehen können, ohne dass es jemand erfährt. Wenn ein Share irgendetwas enthält, das Ihnen wichtig ist, mounten Sie es hard. Der Preis ist, dass ein Prozess, der das Share berührt, wartet, solange der Filer weg ist, was das ehrliche Verhalten ist.

_netdev und nofail. Der Mount wartet auf das Netzwerk, und ein fehlender Filer hindert den Server nicht am Booten. In Kombination mit einem Mount-Timeout kommt die Maschine hoch, die Anwendung kann das fehlende Share klar melden, und der Mount wird vollendet, wenn der Filer zurückkehrt.

Das getestete Protokoll festnageln. Clients und Server handeln eine Protokollversion aus. Setzen Sie die getestete ausdrücklich (nfsvers= oder vers=), damit ein Update auf einer der beiden Seiten das Locking- und Caching-Verhalten nicht still unter Ihnen ändern kann.

Prüfen Sie, was tatsächlich ausgehandelt wurde, nicht, was Sie verlangt haben:

nfsstat -m
findmnt -t nfs,nfs4
mountstats /srv/web

mountstats zeigt Zähler pro Operation, Neuübertragungen und Umlaufzeiten. Eine wachsende Zahl von Neuübertragungen ist die Frühwarnung, dass der Netzwerkpfad oder der Filer Aufmerksamkeit braucht.

Redundanz auf der Leitung, Snapshots auf der Platte

Ein Filer ist nur so verfügbar wie seine Netzwerk-Links. Verbinden Sie ihn mit gebondeten Links an ein Switch-Paar, hashen Sie den Bond auf Adressen und Ports, damit beide Links Traffic führen, und halten Sie Filer und Clients im selben Layer-2-Segment, wo Sie können. Ein geswitchter Pfad hat weniger bewegliche Teile als ein gerouteter und hält den Dateiverkehr im privaten Netzwerk.

Auf der Storage-Seite ändert ein prüfsummenbildendes Dateisystem mit Snapshots, wie Sie mit Fehlern umgehen. Mit ZFS zum Beispiel:

zfs snapshot tank/web@before-deploy
zfs list -t snapshot
ls /export/web/.zfs/snapshot/before-deploy/

Ein Snapshot vor jedem Deployment oder jeder Massenänderung macht eine schlechte Änderung in Sekunden umkehrbar, und ein verstecktes Snapshot-Verzeichnis erlaubt einem Administrator, eine einzelne Datei ohne Restore-Job zurückzukopieren.

Wann ein File Share die falsche Antwort ist

NFS ist ausgezeichnet für Inhalte, die gelegentlich geschrieben und von vielen gelesen werden. Es ist ein schlechtes Zuhause für die Datendateien einer Datenbank, für Workloads, die stark über Clients hinweg locken, oder für Millionen winziger Dateien, die ständig neu geschrieben werden. Die gehören auf Block-Storage. Wenn eine Bibliothek dem File Serving entwächst, verschieben Sie sie, zählen und prüfsummen Sie jede Datei auf beiden Seiten vor dem Cutover, und behalten Sie das Original als Rollback, bis sich die neue Kopie im Betrieb bewährt hat.

Eine kurze Checkliste für Ihre eigenen Shares

• exportfs -v listet nur benannte Hosts, mit root_squash und sync.
• Die Firewall erlaubt NFS nur von diesen Hosts.
• Jeder Client-Mount ist hard, mit _netdev, nofail und festgenagelter Protokollversion.
• nfsstat -m auf jedem Client zeigt die Optionen, die Sie beabsichtigt haben.
• Neuübertragungen in mountstats liegen nahe null und wachsen nicht.
• Der Filer hat redundante Links, und Sie haben getestet, einen zu verlieren.
• Snapshots existieren, und Backups werden separat gezogen.

Wie wir es machen

Unsere Dateidienste laufen auf ZFS über Volumes aus unserem All-Flash-SAN, sind über gebondete Links an ein Switch-Paar im selben privaten Segment wie ihre Clients angebunden und werden in eine neue Boot-Umgebung aktualisiert, sodass die vorherige bootfähig bleibt, bis sich das Update bewährt hat.

Wenn Ihr geteilter Storage schnell eingerichtet wurde und sich seitdem niemand mehr angesehen hat, prüfen wir ihn gern mit Ihnen.

CTA

Mit einem Ingenieur sprechen

Related

Verwandt: NAS-Dateidienste, NFS und SMB · Enterprise-SAN-Storage auf HPE 3PAR, All-Flash · Disaster Recovery und standortübergreifende Replikate