# NFS Advanced: Performance und Hochverfügbarkeit unter RHEL

TL;DR / Management Summary Während das Basis-Setup von NFS (siehe Artikel 088) für einfache Szenarien reicht, benötigen Enterprise-Applikationen mehr Power und Ausfallsicherheit. Wir optimieren den Standard nfs-kernel-server durch Erhöhung der Worker-Threads, beschäftigen uns mit NFS-Ganesha (User-Space NFS für Cluster) und bauen die Brücke zur Hochverfügbarkeit mittels Pacemaker.

# 1. Einführung & Konzepte

Wann Standard-NFS nicht mehr reicht.

Der klassische Kernel-NFS-Server ist schnell, aber schwer in Cluster-Dateisysteme (wie Ceph oder Gluster) zu integrieren. Hier kommt NFS-Ganesha ins Spiel.

# Die Performance-Faktoren (Mermaid)

graph TD
    A[NFS Request] --> B{Kernel Threads: nfsd}
    B -->|Thread 1| C[I/O Operation]
    B -->|Thread N| D[I/O Operation]
    C/D --> E[XFS / ZFS Backend]
    E --> F[Disk Latency]
    G[Network: MTU 9000] --> A

# 2. nfs-kernel-server Tuning

Die Worker-Threads optimieren.

Standardmäßig startet RHEL nur 8 nfsd Threads. Bei hunderten parallelen Clients ist das ein Flaschenhals.

# Anzahl der Threads erhöhen

Datei: /etc/nfs.conf (Modern) oder /etc/sysconfig/nfs (Legacy)

[nfsd]
threads=64

Danach: sudo systemctl restart nfs-server.

# Monitoring der Threads

Prüfen Sie, ob Ihre Threads überlastet sind:

cat /proc/net/rpc/nfsd
# Achten Sie auf 'th' Zeile: wie viele Threads wurden angefragt vs. wie viele waren verfügbar.

# 3. NFS-Ganesha: Die User-Space Alternative

Flexibilität für Cluster.

NFS-Ganesha läuft im User-Space und nutzt FSAL (Filesystem Abstraction Layer), um Daten direkt von Ceph oder GlusterFS zu lesen.

# Installation

sudo dnf install nfs-ganesha-vfs # VFS für lokales Dateisystem
sudo systemctl enable --now nfs-ganesha

# 4. Day-2 Operations: Hochverfügbarkeit

Kein Single Point of Failure.

Kombinieren Sie NFS mit Pacemaker (siehe Artikel 055), um eine virtuelle IP (VIP) bereitzustellen.

• Wichtig: Da NFSv4 stateful ist, müssen die Lock-Informationen (/var/lib/nfs/statd) auf einem Shared Storage liegen, damit der Failover-Node die bestehenden Verbindungen übernehmen kann.

# 5. Troubleshooting & “War Stories”

Wenn das Tuning nach hinten losgeht.

# Story 1: “Der CPU-Overhead durch zu viele Threads”

Symptom: Erhöhung der nfsd Threads auf 512 macht das System langsamer statt schneller. Ursache: Context-Switching Overload. Zu viele Threads kämpfen um die gleichen CPU-Kerne und Locks im Kernel. Lösung: Faustformel nutzen: 1-2 Threads pro CPU-Kern, maximal 128 bei Standard-Workloads.

# Story 2: “Mount-Hänger trotz HA”

Symptom: Die VIP schwenkt sauber zum zweiten Node, aber die Clients zeigen “Permission Denied” oder frieren ein. Ursache: Die Export-IDs (fsid) in der /etc/exports müssen auf beiden Nodes identisch sein! Lösung: Nutzen Sie immer eine feste UUID für Exports in HA-Szenarien: /data *(rw,sync,fsid=101).

# 6. Fazit & Empfehlung

• Performance: Jumboframes (MTU 9000) sind für NFS-Performance wichtiger als die Anzahl der Threads.
• Wahl: Nutzen Sie den Kernel-Server für maximale Single-Host Performance. Nutzen Sie Ganesha für verteilte Speichersysteme.
• Monitoring: Überwachen Sie nfsstat -s regelmäßig auf hohe Latenzen.

# Anhang: Cheatsheet