Proxmox : délais NFS — options de montage pour améliorer la stabilité

À quoi ressemblent les « délais NFS » sur Proxmox (et pourquoi c’est inquiétant)

« Délai NFS » est généralement un euphémisme. Le système ne « time out » pas poliment ; il se bloque.
Sur Linux, un système de fichiers NFS monté en hard va continuer à retenter les opérations jusqu’à ce que le serveur réponde.
C’est un comportement correct pour l’intégrité des données, mais c’est une forme particulière de misère quand ce montage contient
des disques de VM ou des cibles de sauvegarde.

Sur Proxmox, le rayon d’impact dépend de ce qui se trouve sur NFS :

• Stockage ISO/modèles : ennuyeux mais supportable. Les récupérations échouent, les opérations retentent.
• Cible de sauvegarde (vzdump) : les jobs se bloquent, les fichiers de verrou traînent, la supervision s’affole.
• Disques VM sur NFS : l’hôte peut geler sur des E/S. Les E/S invitées se figent, parfois QEMU se met en pause, parfois on a l’impression d’un split-brain sans split-brain.
• Stockage partagé pour la migration : les migrations se bloquent en vol. Vous avez maintenant deux machines se disputant la propriété du problème.

La raison pour laquelle les délais NFS sont opérationnellement pénibles est que les défaillances sont souvent partielles :
un chemin bascule, une interface réseau lâche, le tampon d’un commutateur s’étouffe, un thread serveur se fige. Le client continue d’essayer.
Vous n’obtenez pas un « down » propre. Vous obtenez une maison hantée.

Deux vérités rapides avant de commencer l’ajustement

• Les options de montage ne répareront pas un réseau cassé. Elles peuvent rendre le comportement en cas de panne plus raisonnable et réduire les blocages, mais elles ne vaincront pas la physique.
• La stabilité vaut mieux que la vitesse pour le stockage Proxmox. Un stockage rapide qui se fige de temps en temps est plus lent qu’un stockage modeste qui ne ment jamais.

Faits intéressants et contexte historique (parce que le passé continue de nous facturer)

1. NFS est né au milieu des années 1980 chez Sun Microsystems pour partager des fichiers entre stations sans bus de disque partagé.
2. NFSv3 est conçu sans état (le serveur ne suit pas beaucoup l’état client), ce qui simplifie la récupération après redémarrage serveur mais déplace la complexité ailleurs.
3. NFSv4 a introduit la notion d’état (verrous, sessions, délégations). Meilleure sémantique, plus de pièces mobiles.
4. NFS sur UDP était autrefois courant pour la performance ; TCP a largement gagné car il se comporte mieux sur des réseaux perdants et avec les offloads NIC modernes.
5. Le montage « hard » est le défaut dans de nombreux environnements parce que la corruption silencieuse des données est pire qu’un blocage. Oui, c’est un compromis sinistre.
6. Le client NFS de Linux utilise des timeouts RPC et un backoff exponentiel ; « server not responding » ne signifie pas nécessairement que le serveur est hors ligne — parfois il est congestionné.
7. Les patterns d’E/S des disques de VM sont hostiles aux protocoles bavards : petites lectures/écritures aléatoires, opérations de métadonnées, fsyncs. NFS est mis à l’épreuve que vous le vouliez ou non.
8. pNFS existe pour monter en échelle NFS, mais la plupart des déploiements Proxmox ne l’utilisent pas ; ils sont sur une seule tête et s’étonnent qu’elle se comporte comme une seule tête.

Une citation qui mérite d’être scotchée au-dessus de chaque tableau de bord de stockage :
« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Blague #1 : NFS, c’est comme le Wi‑Fi du bureau — quand ça marche, personne ne le remarque ; quand ça marche mal, tout le monde devient ingénieur réseau.

Playbook de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Quand des délais NFS apparaissent, vous avez des minutes pour décider : est-ce un problème serveur, un problème réseau,
ou un comportement côté client ? Voici l’ordre qui trouve le goulot le plus vite dans des environnements réels.

Premier : confirmer le mode de panne (E/S bloquées vs E/S lentes vs problème de permission/verrou)

• Cherchez « server not responding » dans le journal du noyau sur le nœud Proxmox. Si c’est présent, vous êtes en territoire transport/RPC.
• Vérifiez si des processus sont bloqués en état D. Si vous voyez QEMU, vzdump ou des threads du noyau en D, vous avez des E/S bloquées.
• Confirmez si c’est un nœud ou tous les nœuds. Un seul nœud suggère un chemin NIC/commutateur ; tous les nœuds suggèrent un blocage côté serveur ou un segment réseau partagé en panne.

Second : prouver si le serveur NFS est sain maintenant

• Charge serveur et latence disque : si le serveur est saturé ou si son stockage subit des blocages, les clients vont timeouter.
• Réactivité du service RPC : si rpcbind/nfsd ont des threads bloqués, même un serveur « pingable » n’ira pas répondre aux appels NFS.
• Sanité de la configuration des exports : un export mal configuré peut se comporter comme une panne intermittente quand différents clients négocient des chemins/versions différents.

Troisième : valider le chemin réseau comme si vous ne lui faisiez pas confiance (parce que vous ne devriez pas)

• La perte et le réordonnancement de paquets importent plus que la bande passante brute. NFS est sensible à la latence et déteste les micro‑pics.
• Les incompatibilités MTU causent un comportement « ça marche la plupart du temps » qui ruine les après‑midi.
• Les erreurs de configuration LACP et le routage asymétrique provoquent des blocages périodiques qui ressemblent exactement à des problèmes serveur NFS.

Point de décision

Si vous avez des tâches en état D + « server not responding » du noyau + retrans qui grimpe, priorisez des options de stabilité
qui évitent les blocages à l’échelle du cluster (puis corrigez la cause sous‑jacente). Si vous n’avez pas de retrans mais
des opérations lentes, regardez la latence disque serveur et la saturation des threads NFS.

Options de montage qui améliorent réellement la stabilité

Les options de montage sont un sujet d’opinions. Certains choix regardent la performance. Beaucoup concernent la façon dont votre système se comporte
quand le monde brûle. Proxmox vit plus souvent dans la catégorie « quand le monde brûle » que nous l’admettons.

Recommandation de base (valeurs par défaut stables pour le stockage NFS Proxmox)

Pour la plupart des environnements Proxmox utilisant NFS comme cible de sauvegarde ou magasin d’ISO, commencez ici :

cr0x@server:~$ cat /etc/pve/storage.cfg
nfs: nas-backup
        export /export/proxmox-backup
        path /mnt/pve/nas-backup
        server 10.10.20.10
        content backup,iso,vztmpl
        options vers=4.1,proto=tcp,hard,timeo=600,retrans=2,noatime,nodiratime,rsize=1048576,wsize=1048576
...output...

Détaillons les éléments importants :

• vers=4.1 : v4.1 ajoute des sessions et de meilleures sémantiques de récupération que v4.0, et évite certaines bizarreries de l’ère v3. C’est un bon « par défaut moderne » quand le serveur le supporte.
• proto=tcp : TCP gère la perte et la congestion avec moins de chaos que UDP. Si vous êtes encore sur UDP, j’admire votre confiance et je redoute votre fenêtre de changement.
• hard : gardez le hard pour le stockage de disques VM et pour les sauvegardes si l’exactitude compte. Les montages soft peuvent renvoyer des erreurs d’E/S en plein écriture. Ce n’est pas de la « gestion de timeout », c’est la roulette de la corruption.
• timeo=600,retrans=2 : augmente le timeout RPC (en dixièmes de seconde, donc 600 = 60s pour beaucoup d’opérations), réduit le nombre de retransmissions avant de rapporter un timeout. Cette combinaison réduit le spam de journaux et le thrash pendant les pannes. Vous bloquez toujours sur des montages hard, mais de manière plus polie.
• noatime,nodiratime : réduit les écritures de métadonnées. Ce n’est pas une réparation de timeout, mais ça enlève du bruit inutile.
• rsize/wsize : utiliser 1M peut réduire le surcoût RPC sur des réseaux modernes. Si vous observez de la fragmentation ou des problèmes NIC étranges, réduisez ces valeurs.

Hard vs soft : choisissez la panne que vous pouvez accepter

C’est la décision que les gens essaient d’éviter. Vous ne pouvez pas.

• hard signifie : les opérations NFS retentent indéfiniment. Vos processus peuvent se bloquer. Vos données sont plus sûres.
• soft signifie : après quelques réessais, NFS renvoie une erreur. Vos processus peuvent échouer rapidement. Vos données peuvent être incohérentes si l’application n’attendait pas une erreur d’E/S en cours d’écriture.

Pour les disques VM sur NFS, je préfère fortement hard. Un montage soft peut provoquer une corruption du système de fichiers invité si des écritures échouent.
Pour les cibles de sauvegarde, hard est généralement encore correct — à moins que votre modèle opérationnel exige que les jobs échouent vite et retentent plus tard
et que vous acceptiez des sauvegardes partielles comme « normales ». La plupart des entreprises ne l’avouent pas, mais certaines le font.

intr et « puis-je interrompre un montage bloqué ? »

Historiquement, intr permettait aux signaux d’interrompre les opérations NFS. Sur les noyaux Linux modernes, son comportement varie ou est ignoré selon la version et le protocole NFS.
Ne basez pas votre plan d’intervention sur lui. Prévoyez des chemins sûrs de redémarrage/évacuation à la place.

timeo et retrans : ce qu’ils font vraiment (et ce qu’ils ne font pas)

timeo est le timeout RPC de base ; retrans est le nombre de fois que le client retransmettra une requête RPC avant de rapporter un timeout dans le journal du noyau.
Avec hard, même après rapport de timeout, il continue à retenter. Alors pourquoi les régler ?

• Réduire le comportement en « tempête » : des retrans agressives peuvent générer des tempêtes RPC pendant des accrocs serveur, rendant la récupération plus lente.
• Améliorer l’observabilité : un timeo plus grand réduit les faux « server not responding » pendant de brèves micro‑pointes.
• Rendre le basculement moins dramatique : si vous avez un NFS HA (ou des VIP qui bougent), vous voulez que les clients tolèrent la transition sans fondre.

actimeo / cache des attributs : un bouton performance qui peut devenir une histoire de cohérence

Le cache d’attributs réduit les allers‑retours de métadonnées. Il peut aider la performance, en particulier avec des opérations sur des répertoires lourds.
Mais pour des répertoires partagés où plusieurs clients modifient les mêmes chemins (pensez : caches de modèles, certaines rotations de sauvegarde),
un cache trop agressif peut créer des moments « où est passé mon fichier ? ».

Pour les cibles de sauvegarde Proxmox, vous n’avez généralement pas besoin d’un cache d’attributs sophistiqué. Si vous le réglez, faites‑le avec prudence et mesurez.

lookupcache=positive et pourquoi cela peut réduire la douleur

Sur NFSv3/v4, lookupcache=positive peut réduire les effets du cache de recherche négative (où le client se souvient trop agressivement « fichier introuvable »).
Cela peut aider quand des applications créent des fichiers et les recherchent immédiatement entre nœuds.
Ce n’est pas magique, mais c’est un des rares boutons qui peut corriger les problèmes de « perception obsolète » sans changer le serveur.

nconnect : plus de connexions, moins de blocages tête-de-file (parfois)

Linux supporte nconnect pour NFSv4.x dans des noyaux récents, ouvrant plusieurs connexions TCP par montage.
Cela peut améliorer le débit et réduire le blocage tête-de-file quand une connexion subit des pertes.
Cela peut aussi amplifier la charge sur un serveur déjà en difficulté et faire pleurer les tampons de votre commutateur.

Utilisez‑le seulement après avoir vérifié que le CPU, la NIC et le stockage serveur ont de la marge. Commencez par nconnect=4, pas 16.

Options à éviter (sauf si vous aimez rédiger des postmortems)

• soft pour les disques VM : c’est un chemin rapide vers des dégâts silencieux dans les bonnes conditions de panne.
• proto=udp sur les réseaux modernes : ce n’est plus 1999, et vos commutateurs n’en raffolent pas.
• noac comme « fix » des vues obsolètes : cela peut anéantir la performance et augmenter la charge serveur ; traitez‑le comme une chimiothérapie.
• timeo excessivement bas : cela transforme la congestion transitoire en tempêtes RPC autoinfligées.

Blague #2 : Si vous réglez soft,timeo=1,retrans=1 pour « éviter les blocages », félicitations — votre stockage échoue vite, comme la première rotation d’astreinte d’une startup.

Choisir la bonne version NFS (v3 vs v4.1) avec conviction

Proxmox ne se soucie pas de votre préférence philosophique. Il se soucie que les E/S se terminent.
Le choix de version affecte le verrouillage, la récupération et l’apparence du « timeout ».

Quand NFSv4.1 est le bon choix par défaut

• Espace de noms d’export unique et pare‑feu plus simple (typiquement 2049 uniquement, selon le serveur).
• Meilleures sémantiques de session qui peuvent rendre les coupures réseau transitoires moins catastrophiques.
• Verrous avec état qui sont généralement plus prévisibles pour les scénarios multi‑clients.

Quand NFSv3 reste raisonnable

• Appliances NAS legacy avec des implémentations v4 fragiles.
• Contraintes d’interopérabilité spécifiques (certaines baies enterprise ont des idées « spéciales » sur les fonctionnalités v4).
• Préférence pour la débogabilité : v3 peut être plus facile à raisonner dans certains traces de paquets parce qu’il est plus simple.

Considérations de verrouillage

Si vous stockez des images VM sur NFS, le verrouillage compte. Pour qcow2 en particulier, l’accès concurrent est une catastrophe.
Assurez‑vous que votre configuration garantit l’exclusivité : Proxmox fait sa part, mais la sémantique des verrous NFS peut toujours jouer un rôle,
particulièrement en cas de basculement.

Une règle pratique

Si vous pouvez exécuter NFSv4.1 proprement de bout en bout, faites‑le. Si vous ne le pouvez pas, exécutez v3 proprement et acceptez que vous choisissez « simple et stable » plutôt que « riche en fonctionnalités ».
La pire option est « v4 parfois », où les clients négocient des comportements différents entre nœuds.

Réalités réseau : pertes, MTU, trames pause, et pourquoi « ça ping » est insignifiant

Le ping est une carte postale. NFS est du transport de fret avec de la paperasserie. Vous pouvez avoir un ping parfait et un NFS terrible.
Les délais viennent souvent de micro‑pics, de famine de tampons ou de retransmissions qui s’amplifient sous charge.

Ce qui cause généralement « server not responding » dans des datacenters stables

• Perte de paquets sous charge (câble défectueux, optique marginale, ToR sursouscrit, uplink congestionné).
• Incompatibilité MTU (jumbo frames d’un côté, pas de l’autre). Ça marche jusqu’au jour où ça ne marche plus, puis ça échoue comme un tour de magie.
• Étrangetés de flow control / trames pause conduisant à des courts arrêts qui déclenchent des cascades de timeouts RPC.
• Problèmes de hachage LACP où un lien membre est saturé tandis que les autres sont inactifs.
• Bugs d’offload NIC (moins courant aujourd’hui, toujours réel). Les problèmes TSO/GRO peuvent se manifester par des pics de latence étranges.

Position opérationnelle

Traitez NFS comme du trafic de stockage, pas comme « juste du réseau ». Placez‑le sur un chemin prévisible :
VLAN dédié, MTU cohérent, configuration de bonding cohérente, QoS cohérente si vous l’utilisez.
Si vous ne pouvez pas l’isoler, au moins mesurez‑le.

Modes de panne spécifiques à Proxmox : sauvegardes, migration et douleur en cluster

Vzdump vers NFS : pourquoi elles se bloquent différemment que prévu

Les sauvegardes Proxmox peuvent impliquer snapshots, compression, écritures en chunks et opérations de sync.
Quand la cible NFS se bloque, le processus de sauvegarde peut se retrouver bloqué dans des E/S noyau.
Si vous lancez plusieurs sauvegardes en parallèle, vous pouvez amplifier le blocage en un thundering herd auto‑infligé.

Approche pratique : limiter la concurrence, garder le montage stable et éviter les réglages qui créent des tempêtes de réessais.
Si les sauvegardes doivent « toujours se terminer », utilisez des montages hard et de la pression opérationnelle (ordonnancement, limites de concurrence).
Si les sauvegardes doivent « échouer vite », acceptez le risque et construisez des logiques de retry et d’automatisation de nettoyage.

Disques VM sur NFS : les pics de latence deviennent des incidents invités

Même de petits arrêts NFS apparaissent comme de la latence côté invité. Les bases de données le remarquent. Les systèmes de fichiers le remarquent. Les humains le remarquent.
Si vous placez des disques VM sur NFS, vous acceptez :

• un contrôle strict du comportement réseau,
• des performances serveur prévisibles,
• et des options de montage choisies pour l’exactitude plutôt que pour « ne pas se bloquer ».

Effets en cluster : un nœud défaillant peut gâcher la réunion

Dans un cluster Proxmox, des problèmes de stockage NFS partagé peuvent se présenter comme :

• plusieurs nœuds journalisant des timeouts simultanément,
• opérations de migration bloquées,
• opérations GUI en attente d’actualisation du statut du stockage,
• et le amusant : « tout semble sain sauf que rien ne fait quoi que ce soit. »

Votre objectif est de rendre le mode de panne prévisible. Prévisible = débogable. Débogable = réparable.

12+ tâches pratiques avec commandes, sorties et décisions

Ce sont des tâches de terrain. Chacune inclut : une commande, une sortie exemple, ce que cela signifie, et la décision à prendre.
Exécutez‑les sur le nœud Proxmox sauf indication contraire.

Task 1: Confirm what Proxmox thinks the NFS storage is

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        196540280        90581232       96023420   46.07%
nas-backup        nfs     active       7812500000      2123456789     5600000000   27.18%
...output...

Ce que cela signifie : Le stockage est « active » du point de vue de Proxmox. Cela ne garantit pas qu’il est réactif ; cela signifie seulement que le montage existe et semble utilisable.

Décision : Si le statut bascule entre active/inactive pendant l’incident, suspectez un flap de montage ou des problèmes de disponibilité côté serveur.

Task 2: Inspect the actual mount options in effect

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/pve/nas-backup
10.10.20.10:/export/proxmox-backup /mnt/pve/nas-backup nfs4 rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.21,local_lock=none
...output...

Ce que cela signifie : Confirme les options effectives. « relatime » apparaît parce que le noyau normalise le comportement atime.

Décision : Si vous ne voyez pas hard/timeo/vers comme attendu, corrigez storage.cfg ou fstab et remontez délibérément.

Task 3: Watch the kernel complain in real time

cr0x@server:~$ journalctl -kf | grep -i nfs
Dec 26 10:14:21 pve1 kernel: nfs: server 10.10.20.10 not responding, still trying
Dec 26 10:14:52 pve1 kernel: nfs: server 10.10.20.10 OK
...output...

Ce que cela signifie : C’est le comportement classique de retrans/timeout avec récupération.

Décision : Si « still trying » se répète pendant des minutes sans « OK », traitez‑le comme une panne réelle. Isolez : santé du serveur vs réseau.

Task 4: Find blocked tasks (D state) and identify who’s stuck

cr0x@server:~$ ps -eo pid,state,comm,wchan:32,args | awk '$2=="D"{print}' | head
23145 D qemu-system-x86  nfs_wait_bit_killable       /usr/bin/kvm -id 102 -name vm102 ...
30411 D vzdump           rpc_wait_bit_killable       vzdump 102 --compress zstd --storage nas-backup
...output...

Ce que cela signifie : Les processus en état D attendent des E/S non interruptibles. Les tuer ne fonctionnera généralement pas ; ils sont bloqués dans le noyau.

Décision : Si QEMU est bloqué, supposez un impact invité. Envisagez de déplacer les charges hors de ce nœud après récupération NFS ; ne faites pas un simple « kill -9 » et espérez.

Task 5: Check NFS client RPC stats for retrans and timeouts

cr0x@server:~$ nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
189432     814        0

Client nfs v4:
null         read         write        commit       open         open_conf    ...
0            48212        27111        135          324          0            ...
...output...

Ce que cela signifie : Les retransmissions sont un indice fort de perte réseau ou de problèmes de réactivité serveur.

Décision : Si retrans augmente rapidement sous charge normale, priorisez l’enquête réseau. Si retrans est faible mais la performance est mauvaise, regardez la latence disque/CPU serveur.

Task 6: Check per-mount NFS state and age (useful for “stale handle” narratives)

cr0x@server:~$ cat /proc/mounts | grep nas-backup
10.10.20.10:/export/proxmox-backup /mnt/pve/nas-backup nfs4 rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.21 0 0
...output...

Ce que cela signifie : Confirme que c’est NFSv4 et affiche les options principales. C’est un contrôle rapide « qu’est‑ce qu’on exécute au juste ? ».

Décision : Si vous attendez v4.1 et voyez v3 (ou vice versa), vous avez trouvé une dérive de configuration ou un problème de négociation.

Task 7: Verify NFS server exports from the client perspective

cr0x@server:~$ showmount -e 10.10.20.10
Export list for 10.10.20.10:
/export/proxmox-backup 10.10.20.0/24
/export/iso            10.10.20.0/24
...output...

Ce que cela signifie : Confirme la visibilité des exports. Cela ne valide pas complètement le comportement du namespace NFSv4, mais attrape les changements d’export évidents.

Décision : Si l’export n’est pas listé ou si l’accès est restreint de façon inattendue, arrêtez de tuner les montages et corrigez les exports/ACL.

Task 8: Test I/O behavior directly on the mount (simple latency sniff test)

cr0x@server:~$ time sh -c 'dd if=/dev/zero of=/mnt/pve/nas-backup/.iotest bs=1M count=256 conv=fdatasync status=none'
real    0m5.842s
user    0m0.012s
sys     0m0.221s
...output...

Ce que cela signifie : Cela inclut un sync pour forcer le serveur à committer. Si cela passe de secondes à minutes, vous voyez le problème, pas une illusion.

Décision : Si c’est lent mais que retrans est faible, suspectez la latence disque serveur ou la satiété des threads du serveur NFS.

Task 9: Check network error counters on the Proxmox node

cr0x@server:~$ ip -s link show dev bond0
4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210 12345678  0       124      0       112233
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109 11223344  0       0        0       0
...output...

Ce que cela signifie : Des drops RX sur le trafic de stockage sont une mauvaise nouvelle. Les paquets perdus peuvent produire des retrans/timeouts.

Décision : Si les drops augmentent pendant les fenêtres de sauvegarde, vous avez de la congestion ou des problèmes de tampons NIC/commutateur. Envisagez QoS, VLAN séparé ou corrections de capacité.

Task 10: Validate MTU end-to-end (the jumbo frame trap)

cr0x@server:~$ ping -c 3 -M do -s 8972 10.10.20.10
PING 10.10.20.10 (10.10.20.10) 8972(9000) bytes of data.
8972 bytes from 10.10.20.10: icmp_seq=1 ttl=64 time=0.431 ms
8972 bytes from 10.10.20.10: icmp_seq=2 ttl=64 time=0.438 ms
8972 bytes from 10.10.20.10: icmp_seq=3 ttl=64 time=0.422 ms

--- 10.10.20.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
...output...

Ce que cela signifie : Cela confirme que les jumbo frames fonctionnent entre client et serveur. Si cela échoue avec « Frag needed », vous avez une incompatibilité MTU.

Décision : Si les jumbo échouent, corrigez le MTU partout ou redescendez à 1500 partout. Un MTU mixte est une taxe de fiabilité.

Task 11: Confirm the NFS server responds to RPC/NFS probes

cr0x@server:~$ rpcinfo -t 10.10.20.10 nfs 4
program 100003 version 4 ready and waiting
...output...

Ce que cela signifie : Le service NFS est joignable via TCP. Si cela bloque ou échoue pendant l’incident, c’est soit le réseau soit la pile RPC serveur qui a des ennuis.

Décision : Si rpcinfo échoue depuis plusieurs clients, concentrez‑vous sur le serveur ou le segment réseau partagé plutôt que sur le tunage client.

Task 12: Trace one hung process to confirm it’s stuck in NFS I/O

cr0x@server:~$ cat /proc/30411/stack
[<0>] rpc_wait_bit_killable+0x1d/0x60
[<0>] __rpc_execute+0x3a/0x90
[<0>] rpc_execute+0x44/0x50
[<0>] nfs4_call_sync+0x6a/0xa0
[<0>] nfs4_proc_write+0xa1/0x140
[<0>] nfs_file_write+0x10a/0x2a0
[<0>] vfs_write+0x1b4/0x2a0
[<0>] ksys_write+0x67/0xe0
[<0>] do_syscall_64+0x5b/0x110
...output...

Ce que cela signifie : La pile montre le processus en attente dans le chemin d’écriture RPC/NFS. Ce n’est pas une « lenteur applicative ». C’est une non‑réactivité du chemin stockage.

Décision : Arrêtez de débattre du tunage applicatif. Stabilisez le chemin NFS et envisagez de suspendre de nouveaux jobs de sauvegarde jusqu’à récupération.

Task 13: Remount with safer options (controlled change)

cr0x@server:~$ umount /mnt/pve/nas-backup
umount: /mnt/pve/nas-backup: target is busy.
...output...

cr0x@server:~$ fuser -vm /mnt/pve/nas-backup | head
                     USER        PID ACCESS COMMAND
/mnt/pve/nas-backup: root      30411 f.... vzdump
/mnt/pve/nas-backup: root      23145 f.... qemu-system-x86
...output...

Ce que cela signifie : Vous ne pouvez pas démonter parce que des processus y accèdent, potentiellement bloqués.

Décision : Ne forcez pas le démontage d’un montage qui contient des disques VM. Si ce n’est qu’une cible de sauvegarde, envisagez d’arrêter/gestionner les jobs d’abord, puis remontez pendant une fenêtre calme.

Task 14: Check Proxmox task logs for storage-related stalls

cr0x@server:~$ tail -n 30 /var/log/pve/tasks/active
UPID:pve1:000076CB:0012ABCD:676D0B31:vzdump:102:root@pam:
status: running
starttime: 1766743800
...output...

Ce que cela signifie : La tâche est « running » mais ne progresse pas. Combinez avec les vérifications d’état D pour confirmer qu’elle est bloquée sur le stockage.

Décision : Si elle est bloquée et que le montage est hard, planifiez la récupération : restaurez la disponibilité NFS plutôt que d’essayer de tuer la tâche.

Task 15: Server-side check (on the NFS server): NFS thread saturation

cr0x@server:~$ ps -eLo pid,cls,pri,rtprio,stat,comm | grep -E 'nfsd|rpc'
  8123 TS  19      - S    nfsd
  8124 TS  19      - R    nfsd
  8125 TS  19      - D    nfsd
...output...

Ce que cela signifie : Si des threads nfsd sont en état D, ils sont probablement bloqués sur le stockage serveur (disque local, ZFS, contrôleur RAID, etc.).

Décision : Si les threads nfsd côté serveur bloquent, aucune option de montage côté client ne vous sauvera. Corrigez la latence du stockage serveur ou réduisez la charge.

Trois mini‑histoires du monde de l’entreprise (toutes anonymisées, toutes plausibles)

1) Incident causé par une mauvaise hypothèse : « Le NAS a des liens redondants, donc le réseau ne peut pas être en cause. »

Une entreprise de taille moyenne exploitait un cluster Proxmox avec des sauvegardes sur NFS. Le NAS avait deux NIC en agrégat avec LACP.
L’équipe supposait que la redondance signifiait résilience. Les sauvegardes étaient planifiées la nuit et « marchaient généralement » jusqu’à un pic de fin de trimestre
qui a augmenté la charge et, soudain, les sauvegardes ont commencé à se bloquer sur deux des cinq nœuds.

La première hypothèse : si le NAS est joignable, il est sain. Le ping fonctionnait. L’interface graphique chargeait. Le tableau de bord du NAS affichait « healthy ».
Mais sur les nœuds Proxmox, les journaux noyau montraient des répétitions de « nfs: not responding ». Certains processus vzdump étaient en état D.

Ils ont passé des heures à ajuster les options de montage — baisser les timeouts, augmenter les timeouts, ajouter soft sur un nœud « juste pour tester ».
Ce nœud a cessé de se bloquer… et a commencé à produire des sauvegardes partielles avec erreurs d’E/S. Ils ont failli promouvoir une sauvegarde corrompue comme « réussie » parce que le job s’était terminé.
Le système de sauvegarde n’a pas corrompu les données silencieusement ; il a échoué bruyamment. C’était la seule partie positive.

La vraie cause était un décalage de hachage LACP : le commutateur hachait sur L3/L4, le NAS hachait différemment, et la majorité du trafic NFS atterrissait sur un lien physique.
Sous charge, ce lien laissait tomber des rafales de paquets. TCP se rétablissait, mais la latence RPC montait suffisamment pour déclencher des retransmissions NFS et des « not responding ».

La correction fut ennuyeuse : aligner les politiques de hachage LACP, valider avec les compteurs d’interface, et garder NFS sur un VLAN prévisible.
Ce n’est qu’après que le réseau fut stable que le tuning du montage a eu de l’intérêt — et encore, modestement.

2) Optimisation qui a mal tourné : jumbo frames + « nconnect partout »

Une autre équipe voulait des migrations VM plus rapides et des sauvegardes plus réactives. Ils ont activé les jumbo frames (MTU 9000) sur les nœuds Proxmox et le serveur NFS,
et ils ont activé nconnect=8 parce que quelqu’un avait vu un graphique de benchmark. Le premier jour fut merveilleux.
Puis des timeouts NFS intermittents ont commencé à apparaître durant les fenêtres de sauvegarde lourdes.

Le compliqué : ce n’était pas une rupture nette. La plupart du temps tout volait. Parfois, ça se bloquait.
Les comptes retrans augmentaient, mais seulement sous pic. L’équipe a blâmé le NAS.
L’équipe NAS a blâmé Proxmox. L’équipe réseau a blâmé le « trafic inconnu ». Chacun avait partiellement raison, ce qui est la pire forme de raison.

Le problème caché était une incohérence MTU : les ToR supportaient le jumbo, mais un lien inter‑switch sur le chemin était resté à 1500.
La plupart du trafic contournait ce lien. Certains flux ne le faisaient pas. Ces flux souffraient de fragmentation/blackholing selon le traitement ICMP.
Avec nconnect, il y avait plus de flux, augmentant la probabilité que certains prennent le mauvais chemin. L’optimisation a rendu la panne plus facile à déclencher.

Ils ont corrigé le MTU de bout en bout, puis ont réduit nconnect à 4 après avoir observé une augmentation du CPU serveur.
Les performances sont restées bonnes. Les timeouts ont cessé. Personne n’a pu garder le récit « on devrait juste tuner plus fort ».

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : montages conservateurs + limites de concurrence

Une entreprise faisait des sauvegardes nocturnes de nombreuses VM vers une cible NFS. Très tôt, ils ont remarqué que le NAS se mettait parfois en pause pour des tâches de maintenance
et répondait lentement pendant une ou deux minutes. Ils ont accepté cela comme une réalité et ont conçu autour.

Ils ont fait trois choses qui n’étaient pas assez excitantes pour un talk en conférence :
NFSv4.1 stable sur TCP avec hard,timeo=600,retrans=2, une fenêtre de sauvegarde dédiée, et une limite stricte de concurrence pour que seules quelques VM soient sauvegardées simultanément.
Ils avaient aussi un tableau de bord qui suivait les retrans clients et la latence disque serveur côte à côte.

Quand un commutateur a commencé à laisser tomber des paquets sous charge des mois plus tard, les sauvegardes ont ralenti mais ne se sont pas effondrées.
Les journaux montraient des timeouts, mais le système s’est rétabli sans cascades de tâches bloquées.
L’astreinte a eu assez d’air pour identifier la montée des drops RX et basculer le trafic avant que cela ne devienne une crise.

La revue post‑incident fut rafraîchissante de banalité : confirmer les drops, remplacer une optique suspecte, valider MTU et LACP, fini.
Le système de sauvegarde n’est jamais devenu la une. C’est l’objectif.

Erreurs fréquentes : symptôme → cause racine → correction

1) Symptom: « server not responding, still trying » pendant les sauvegardes ; jobs bloqués pendant des heures

Cause racine : montage hard + stall serveur ou perte de paquets. Le client fait la bonne chose (retenter indéfiniment).

Correction : gardez hard, augmentez timeo (par ex. 600), gardez retrans bas (2–3), corrigez la perte réseau et/ou la latence du stockage serveur. Réduisez la concurrence des sauvegardes.

2) Symptom: les sauvegardes « finissent » mais la restauration échoue ou des fichiers manquent

Cause racine : montages soft renvoyant des erreurs d’E/S en plein write ; l’outil de sauvegarde n’interprète pas toujours les écritures partielles comme vous l’espérez.

Correction : évitez soft pour les cibles de sauvegarde à moins d’avoir une vérification bout en bout et une logique de retry. Préférez hard et l’ordonnancement opérationnel.

3) Symptom: un seul nœud Proxmox a des problèmes NFS

Cause racine : problèmes NIC par nœud, mauvaise config de bonding, câblage/optique, bugs de driver, ou port de commutateur unique avec tampons problématiques.

Correction : comparez les compteurs ip -s link entre nœuds ; échangez câbles/ports ; validez le mode de bonding et le hachage ; vérifiez le MTU.

4) Symptom: les problèmes n’apparaissent que pendant les pics

Cause racine : congestion, micro‑pics, drops de queues, saturation CPU serveur, ou pics de latence du disque de backing.

Correction : mesurez retrans et drops RX ; limitez la concurrence des sauvegardes ; envisagez VLAN/QoS séparés ; corrigez les goulots serveur (disque, CPU, NIC).

5) Symptom: « stale file handle » après maintenance serveur

Cause racine : export déplacé, système de fichiers recréé, rollback de snapshot, ou changements d’inodes sous le chemin d’export.

Correction : évitez les opérations destructrices sous les exports ; utilisez des datasets/chemins stables ; remontez les clients après des changements serveur disruptifs ; pour v4, assurez une pseudo‑root cohérente.

6) Symptom: migration bloquée même si le stockage est « partagé »

Cause racine : le stockage partagé est présent mais souffre de pics de latence ou de stalls RPC intermittents ; la migration déclenche des E/S synchrones.

Correction : stabilisez NFS (réseau, serveur), utilisez NFSv4.1/TCP, et évitez le tunage héroïque. Si vous devez migrer pendant une instabilité, arrêtez et corrigez le stockage d’abord.

7) Symptom: opérations GUI lentes, vérifications de statut du stockage ralenties

Cause racine : opérations de gestion touchant des chemins montés ; les blocages NFS peuvent se propager dans les outils userland.

Correction : gardez les montages NFS problématiques hors des chemins critiques ; montez uniquement où nécessaire ; assurez‑vous des options de montage et de la stabilité serveur ; ne mettez pas « tout » sur un NFS instable.

Listes de contrôle / plan étape par étape

Étape par étape : stabiliser un montage NFS de sauvegarde Proxmox existant

1. Identifier l’étendue : un nœud ou plusieurs ? Utilisez les journaux noyau et nfsstat -c.
2. Confirmer les options de montage effectives : findmnt. Arrêtez de faire confiance aux fichiers de config sans vérifier.
3. Assurer la sanity du protocole : préférez vers=4.1,proto=tcp sauf raison contraire.
4. Définir un comportement de timeout conservateur : hard,timeo=600,retrans=2 comme baseline pour la stabilité.
5. Réduire le churn de métadonnées : noatime,nodiratime.
6. Vérifier MTU de bout en bout : les jumbo fonctionnent partout ou nulle part.
7. Vérifier les drops : ip -s link sur les clients ; compteurs d’interface sur les commutateurs (oui, regardez vraiment).
8. Limiter la concurrence des sauvegardes : moins de jobs vzdump parallèles, surtout durant les fenêtres où le NAS est occupé.
9. Mesurer les tendances de retrans : si retrans monte avec la charge, arrêtez de blâmer les options de montage et corrigez le transport/serveur.
10. Tester avec des écritures sync forcées : dd ... conv=fdatasync pour détecter la latence de commit.
11. Planifier les tâches serveur disruptives : scrubs, snapshots, réplication, déduplication — ne les superposez pas aux pics de sauvegarde sauf si vous aimez jouer.
12. Documenter la sémantique choisie : « montage hard ; les timeouts signifient stall ; la réponse incidente est restaurer le service, pas tuer les processus. » Rendez‑le explicite.

Check‑list : quand vous stockez des disques VM sur NFS (soyons honnêtes)

• Chemin réseau de stockage dédié (VLAN ou physique), MTU cohérent.
• NFSv4.1 sur TCP ; envisager nconnect seulement après stabilité de base.
• Montage hard. Toujours. Si vous voulez soft, vous voulez une autre conception de stockage.
• Le serveur a une latence prévisible sous charges d’écriture sync.
• La supervision inclut retrans, latence disque serveur et drops de commutateur.
• Plan de réponse à une panne NFS : ce qui arrive aux invités, ce que vous faites en premier, et ce que vous ne faites jamais.

Check‑list : surveillance minimale qui attrape le vrai problème

• Taux de retransmissions client (depuis nfsstat -c ou équivalents node exporter).
• Drops et erreurs RX/TX client (depuis ip -s link).
• Latence disque serveur et profondeur de queue (outils selon la pile serveur).
• Santé des threads serveur NFS (nfsd non bloqués).
• Durée et concurrence des jobs de sauvegarde.

FAQ

1) Dois‑je utiliser soft pour éviter que Proxmox ne se fige ?

Pas pour les disques VM. Pour les sauvegardes, seulement si vous acceptez explicitement des échecs partiels et que vous vérifiez les sauvegardes bout en bout.
Sinon, gardez hard et corrigez l’instabilité sous‑jacente.

2) Quel est un timeo et retrans raisonnable pour Proxmox ?

Une baseline pragmatique est timeo=600,retrans=2 pour les montages axés sur la stabilité. Puis mesurez.
Si vous avez un basculement rapide et voulez une détection plus rapide, baissez timeo prudemment, mais n’engendrez pas des tempêtes de réessais.

3) NFSv4 est‑il toujours meilleur que NFSv3 ?

Non. NFSv4.1 est souvent meilleur quand il est bien implémenté, surtout pour la récupération de session et le pare‑feu simplifié.
Mais un serveur NFSv3 solide battra un serveur NFSv4 instable tous les jours de la semaine.

4) rsize/wsize corrigent‑ils les timeouts ?

Pas directement. Ils peuvent réduire le surcoût RPC et améliorer le débit, ce qui peut réduire les stalls liés à la congestion.
Mais si vous avez perte de paquets ou stalls serveur, des tailles plus grandes peuvent rendre les symptômes plus aigus.

5) Mon montage NFS est « active » dans Proxmox, mais les opérations se bloquent. Pourquoi ?

« Active » signifie monté et accessible à un niveau basique. NFS peut être monté tout en étant non réactif sur certaines opérations.
Utilisez les journaux noyau, les vérifications d’état D et nfsstat -c pour confirmer le stall.

6) Puis‑je démonter et remonter NFS en toute sécurité pendant un incident ?

Si cela contient des disques VM : généralement non, pas en toute sécurité, pas rapidement. Si ce n’est qu’une cible de sauvegarde et que vous pouvez arrêter proprement les jobs, parfois.
Votre but est de restaurer le service NFS, pas de jouer à la corde avec la couche VFS.

7) Qu’est‑ce qui cause « stale file handle » et comment l’éviter ?

Des changements côté serveur sous le chemin d’export : rollback, recréation, déplacement de datasets ou modification des racines d’export.
Évitez‑le en conservant les chemins d’export stables et en évitant les opérations destructrices sous des exports actifs.

8) Dois‑je activer nconnect ?

Seulement après avoir prouvé la stabilité de base (pas de drops, latence raisonnable, serveur avec marge CPU).
Cela peut améliorer le débit et réduire le blocage tête‑de‑file, mais peut aussi amplifier la charge serveur et exposer des incohérences du chemin réseau.

9) Ai‑je besoin d’un réseau de stockage dédié pour NFS ?

Si NFS héberge des disques VM ou des sauvegardes critiques, oui — au minimum un VLAN dédié avec MTU prévisible et peu de voisins bruyants.
Les réseaux « tout partagé » sont là où la fiabilité vient prendre une raclée.

10) Quelle est la meilleure chose à faire quand des timeouts surviennent en cours de sauvegarde ?

Arrêtez de lancer de nouveaux jobs de sauvegarde. Réduisez la charge pendant que vous diagnostiquer. Puis confirmez si le problème est des retrans/drops (réseau) ou un stall disque/CPU (serveur).

Conclusion : prochaines étapes qui survivent au contact avec la production

Si Proxmox subit des délais sur NFS, ne le traitez pas comme une chasse aux options de montage. Les options comptent, mais elles ne sont pas la cause racine.
Servez‑vous en pour façonner le comportement en cas de panne : moins de tempêtes, signaux plus clairs, sémantiques plus sûres.

Prochaines étapes pratiques :

1. Verrouillez une baseline de montage stable : vers=4.1,proto=tcp,hard,timeo=600,retrans=2,noatime,nodiratime, plus des rsize/wsize sensés.
2. Exécutez le playbook de diagnostic rapide lors du prochain incident : confirmez l’état D, confirmez les retrans, vérifiez les drops/MTU, puis vérifiez la latence serveur.
3. Limitez la concurrence des sauvegardes et évitez de chevaucher les maintenances serveur lourdes avec les fenêtres de sauvegarde.
4. Instrumentez les retrans et les drops d’interface en tant que métriques de première classe. Si vous ne voyez pas la montée des retrans, vous déboguez à l’aveugle.
5. Quand vous avez besoin de plus de performance, ajoutez de la capacité ou corrigez la topologie avant d’ajouter des astuces comme du caching agressif ou un nconnect élevé.

NFS peut être stable sur Proxmox. Il faut juste des adultes dans la pièce : des sémantiques conservatrices, un tunage mesuré et un réseau qui n’improvise pas.