Stockage : iSCSI vs NFS vs NVMe-oF — Lequel l’emporte vraiment et pourquoi

La vraie question : que cherchez-vous à optimiser ?

« Lequel est le plus rapide ? » n’est pas la bonne première question. Vous pouvez rendre n’importe lequel d’entre eux rapide en laboratoire et misérable en production.
La bonne question est : quelle panne êtes-vous prêt à tolérer, et quel travail êtes-vous prêt à répéter sans cesse ?

Les protocoles de stockage sont un package global :

• Sémantiques : périphérique bloc vs système de fichiers partagé, comportement de verrouillage, opérations de métadonnées.
• Modèle de concurrence : un hôte écrit son périphérique bloc vs plusieurs clients partageant un espace de noms.
• Comportement de récupération : que se passe-t-il quand un chemin oscille, un switch perd des paquets, ou un serveur redémarre en plein I/O.
• Ergonomie opérationnelle : provisionnement, redimensionnement, snapshots, multipathing, observabilité.
• Posture de sécurité : authN/authZ, chiffrement, rayon d’explosion, protection contre les « oups ».

Si vous faites de la virtualisation, des bases de données, de l’analytics ou Kubernetes, vous ne choisissez pas seulement un protocole mais un mode de vie.
Choisissez celui que vous pouvez exploiter à 3 h du matin, à moitié réveillé et légèrement agacé.

Verdicts rapides (la partie opinionnée)

Choisissez NFS quand…

• Vous voulez du stockage partagé avec des flux de travail humains raisonnables : répertoires personnels, dépôts de contenu, médias, caches de compilation.
• Vous privilégiez la simplicité du provisionnement et des restaurations rapides plutôt que la latence absolue minimale.
• Vous pouvez investir dans un bon serveur NFS (ou appliance) et vous êtes discipliné sur les options de montage et la conception réseau.

NFS est le champion du « suffisamment bon »—jusqu’à ce qu’on l’abuse avec des charges lourdes en métadonnées et qu’on fasse comme si le réseau était sans perte.

Choisissez iSCSI quand…

• Vous avez besoin de stockage bloc pour un seul hôte (ou d’un système de fichiers cluster/gestionnaire de volumes par-dessus).
• Vous avez besoin d’un multipathing mature et d’une large compatibilité avec OS, hyperviseurs et baies de stockage.
• Vous pouvez vous engager à une hygiène opérationnelle : timeouts, politiques de chemin et monitoring.

iSCSI est la berline fiable du stockage réseau. Ce n’est pas glamour. Ce n’est généralement pas la raison pour laquelle vous ratez votre SLO—sauf si vous le configurez comme un jouet de labo.

Choisissez NVMe-oF quand…

• Votre charge est sensible à la latence et déjà optimisée localement (bases de données, indexation haute fréquence, ingestion de logs à grande échelle).
• Vous disposez d’un réseau propre et sans perte et pouvez justifier la complexité opérationnelle.
• Vous êtes prêt à traiter le fabric comme un système de première classe : télémétrie, contrôle de congestion et gestion des changements soignée.

NVMe-oF peut être spectaculaire. Il peut aussi être spectaculairement humiliant quand une petite perte de paquets transforme votre rêve de « NVMe presque local » en usine à tickets.

Si vous voulez une règle par défaut : Choisissez NFS pour des fichiers partagés, iSCSI pour le bloc générique, NVMe-oF seulement si vous pouvez prouver que vous en avez besoin et l’exploiter.

Faits intéressants et contexte historique (pour arrêter de répéter les mêmes erreurs)

1. NFS est antérieur à votre budget cloud. NFS est apparu au milieu des années 1980 chez Sun Microsystems, conçu pour faire ressembler les réseaux à des systèmes de fichiers locaux.
2. NFSv3 a percé grâce à sa simplicité. Son design sans état aidait les serveurs à monter en charge et à récupérer, mais repoussait la complexité vers les clients (et le verrouillage vers des protocoles annexes).
3. NFSv4 a pris la question de l’état au sérieux. Il a introduit le verrouillage intégré et des mécanismes de sécurité plus forts, échangeant simplicité pour correction et meilleur comportement en WAN.
4. iSCSI est né pour tuer les « réseaux spéciaux ». Il a émergé au début des années 2000 pour transporter SCSI sur TCP/IP afin que les SAN puissent utiliser Ethernet au lieu de FC.
5. Les jumbo frames ont été autrefois un symbole de statut.Beaucoup d’équipes ont activé MTU 9000 sans validation bout en bout ; les incompatibilités causent encore aujourd’hui des fragmentations et des pertes étranges.
6. NVMe a été conçu pour le parallélisme.NVMe utilise des files multiples pour réduire la contention sur les verrous et exploiter les CPU modernes—contrairement aux anciennes piles conçues pour des disques tournants.
7. NVMe-oF n’est pas une seule chose.C’est une famille : transports RDMA (RoCE/iWARP/InfiniBand) et TCP. TCP est souvent plus simple à déployer ; RDMA peut être plus bas en latence mais est plus exigeant.
8. « NAS vs SAN » est surtout une guerre de proxy.La vraie séparation est fichiers vs blocs—et quelle couche gère le cache, le verrouillage et la cohérence.
9. Le multipathing précède votre plateforme conteneur.Les schémas MPIO ont été forgés à l’époque des baies à double contrôleur et des HBAs capricieux ; les leçons restent valables.

Comment ça marche réellement (et où ça fait mal)

NFS : sémantique de système de fichiers distant

Avec NFS, les clients demandent au serveur des opérations sur les fichiers : open, read, write, getattr, readdir, lock (en v4), etc.
Le serveur contrôle l’espace de noms et les métadonnées faisant foi. Les clients mettent beaucoup en cache pour réduire les allers-retours.

Le gros avantage : espace de noms partagé et provisionnement trivial. Exportez un répertoire, montez-le, terminé.
Le gros piège : la latence des métadonnées et le comportement de cohérence du cache deviennent des problèmes de performance et de correction.
NFS peut être excellent en débit séquentiel et pourtant fondre sur des modèles « millions de petits fichiers ».

iSCSI : périphérique bloc sur TCP

iSCSI encapsule des commandes SCSI sur TCP. Le client (initiator) voit un LUN distant comme un périphérique bloc local.
Systèmes de fichiers, LVM, RAID, bases de données—tout se situe au-dessus, comme avec des disques locaux.

L’avantage : les applications et les OS savent gérer les périphériques bloc. Le multipath est bien compris.
La douleur : vous héritez des angles vifs du stockage bloc : corruption si plusieurs hôtes écrivent sans couche cluster-aware, et comportements de panne disgracieux si les timeouts sont mal réglés.

NVMe-oF : sémantique NVMe à travers un fabric

NVMe-oF étend les jeux de commandes NVMe sur le réseau. Par rapport à iSCSI, il réduit généralement l’overhead du protocole et supporte un parallélisme important.
En pratique, vous pouvez vous rapprocher de la latence NVMe locale—surtout avec RDMA—mais seulement si le réseau se comporte.

La douleur n’est pas « c’est nouveau » (ce n’est plus si nouveau). La douleur est qu’il élève les attentes.
Quand la latence baisse, le prochain goulot d’étranglement devient visible : ordonnancement CPU, affinité IRQ, congestion TCP, voisins bruyants, firmware d’array, etc.

Blague #1 : NVMe-oF promet « des performances quasi locales ». Tout comme tous les CV que j’ai jamais lus.

Réalité des performances : latence, IOPS, débit

Latence : le seul indicateur auquel votre base de données croit vraiment

Si votre charge est transactionnelle, la distribution de latence compte plus que le pic d’IOPS. La médiane ne suffit pas ; la latence de queue vous ruine.
L’overhead du protocole, le jitter réseau, les profondeurs de file, et les retransmissions se manifestent comme des pics p95/p99.

• NFS : souvent excellent pour les grosses lectures/écritures séquentielles, mais les métadonnées et les écritures synchrones peuvent être coûteuses selon le serveur et les options de montage.
• iSCSI : généralement stable et prévisible ; le multipathing aide la disponibilité plus que la latence brute.
• NVMe-oF : meilleur potentiel de latence ; aussi la façon la plus rapide de découvrir que votre réseau n’est pas aussi propre que vous le supposiez.

IOPS : ce que le marketing aime et les SRE méfient

« IOPS » sans taille de bloc, mélange lecture/écriture, profondeur de file et distribution de latence est anecdotique.
Pourtant, le protocole façonne l’efficacité du transport des petites E/S.

NVMe-oF gère bien les fortes profondeurs de file et le parallélisme. iSCSI peut aussi atteindre de très hauts IOPS, mais le coût CPU et le traitement des commandes SCSI apparaissent plus tôt.
La performance NFS dépend fortement du cache client, des threads serveur, et si votre charge est orientée données ou métadonnées.

Débit : la victoire facile avec les fusils à un seul coup

Pour le débit massif, 10/25/40/100GbE compte plus que le choix du protocole. Également : cohérence MTU bout en bout, offloads NIC, et ne pas sursouscrire vos uplinks.

La défaillance de débit la plus courante n’est pas « le protocole est lent ». C’est « un port de switch a des erreurs » ou « un lien d’un LAG est à moitié mort » ou « la baie effectue des rebuilds en arrière-plan ».

Coût CPU : la taxe cachée

iSCSI et NFS roulent sur TCP, donc le CPU fait partie de la facture stockage. NVMe-oF sur TCP est similaire ; NVMe-oF sur RDMA peut réduire le coût CPU mais augmente les contraintes opérationnelles.
Si vous êtes sur des nœuds de calcul partagés, cette taxe CPU est réelle : elle vole des ressources aux threads applicatifs et fait monter la latence.

« L’espoir n’est pas une stratégie. » — idée paraphrasée souvent citée en ingénierie et opérations

Modes de panne rencontrés en production

NFS : quand le serveur éternue, les clients attrapent un rhume

NFS est centralisé. C’est à la fois le but et le risque. Si le serveur est surchargé, tous les clients le ressentent.
Le cache client peut masquer les problèmes jusqu’à ce qu’il ne puisse plus, et alors vous avez des foules tonnantes.

• Stale file handles : typiquement après des modifications d’export côté serveur, des rebuilds de système de fichiers, ou des basculements qui n’ont pas préservé l’identité des inodes.
• Entrées I/O « bloquées » : clients en attente de réponses serveur, souvent à cause de pertes réseau, famine de threads serveur, ou contention de verrouillage.
• Tempêtes de métadonnées : systèmes de build, gestionnaires de paquets, et conceptions « stockons des millions de petits objets comme fichiers ».

iSCSI : mort par timeouts et pannes partielles

iSCSI a tendance à échouer de façon moche et partielle : un chemin se dégrade, un switch perd des paquets, une NIC se met à osciller.
Votre OS maintient le périphérique bloc en vie jusqu’à ce qu’il ne puisse plus. Ensuite les systèmes de fichiers paniquent, ou pire : ils continuent et votre appli se corrompt.

• Oscillations de chemin : problèmes de lien intermittents déclenchant des basculements fréquents et des pics de latence.
• Effondrement du queueing : I/O qui s’accumulent derrière un chemin bloqué ; au moment du basculement, vous paginez déjà.
• Accès split-brain : plusieurs initiateurs écrivant le même LUN sans coordination (ce n’est pas un « peut-être » ; c’est un « quand »).

NVMe-oF : le réseau est désormais votre backplane

NVMe-oF brille quand vous traitez le fabric comme un bus interne de haute qualité. Mais Ethernet est une démocratie des paquets ; il se fiche de vos objectifs de latence.
Congestion, micro-bursts, réglages ECN, comportement des buffers et firmware NIC importent tous.

• Sensibilité à la perte de paquets : même de faibles taux de perte peuvent faire grimper la latence tail, surtout sous charge.
• Multipath mal configuré : asymétries ou politiques erronées menant à des chemins chauds et des performances imprévisibles.
• Manque d’observabilité : des équipes déploient NVMe-oF avant de pouvoir expliquer la latence par file et les retransmissions.

Blague #2 : Les gens du stockage aiment les « cinq neuf » jusqu’à ce que l’équipe réseau demande quelles cinq minutes vous êtes prêt à perdre.

Trois mini-histoires d’entreprise issues du terrain

Incident : la mauvaise hypothèse (« C’est juste un montage »)

Une entreprise de taille moyenne exécutait des builds CI sur une flotte de workers Linux. Ils stockaient les artefacts de build sur un partage NFS parce que c’était facile à gérer et à nettoyer.
Quelqu’un a noté que le partage était « peu utilisé » et a décidé de consolider : déplacer les répertoires personnels, caches de build et logs applicatifs sur le même export.

L’hypothèse erronée était subtile : ils supposaient que NFS se comporte comme un disque local sous l’impact des métadonnées. Ce n’est pas le cas.
La charge CI a généré une tempête de créations de fichiers, stats, renommages et suppressions. Les répertoires personnels ont ajouté un flux constant de petites lectures/écritures.
Les logs ont ajouté des append synchrones plus des rafales lors des rotations.

Les symptômes étaient déroutants. Le CPU des workers de build grimpait, mais pas dans une manière « occupé à compiler »—plutôt « bloqué en état D ».
Les builds commençaient à expirer. Les connexions SSH devenaient lentes parce que le démarrage de shell touche beaucoup de fichiers. Le monitoring montrait que le réseau du serveur NFS n’était pas saturé.

La cause racine : les threads du serveur NFS et le stockage sous-jacent étaient saturés par les opérations de métadonnées et écritures synchrones, tandis que le cache côté client était constamment invalidé.
« Mais la bande passante est correcte » était la mauvaise perspective. Le vrai goulot était les ops/sec côté serveur et la latence des RPCs de métadonnées.

La correction fut ennuyeuse et efficace : séparer les exports par charge, isoler les caches CI sur leur propre serveur (ou disques locaux), et ajuster les options de montage et le nombre de threads serveur.
Ils ont aussi ajouté un benchmark synthétique de métadonnées à la planification de capacité. Le service a récupéré, et le serveur NFS a cessé d’être l’anxiété partagée non officielle de l’entreprise.

Optimisation qui a mal tourné : jumbo frames et la perte silencieuse

Une autre organisation voulait meilleur débit sur iSCSI. Quelqu’un a activé MTU 9000 sur le VLAN stockage et sur les NIC iSCSI.
La fenêtre de changement était courte, et ils n’ont pas validé chaque saut. « C’est un VLAN dédié, tout va bien. »

Pendant une semaine, tout semblait correct—jusqu’à l’apparition de pics de latence périodiques durant les heures de pointe. Pas d’indisponibilité totale. Juste ce genre de lenteur aléatoire qui fait blâmer « le cloud »
même quand on gère ses propres racks.

Le schéma était vicieux : seuls certains hôtes le voyaient, et seulement quand le trafic traversait une paire particulière de switches.
Les retransmissions TCP augmentaient légèrement, mais personne ne surveillait les retransmissions sur le VLAN stockage parce que, historiquement, « les VLANs stockage sont propres ».

Le vrai problème : une interface de switch dans le chemin était encore en MTU 1500 et rejetait les trames surdimensionnées au lieu de les fragmenter.
Le trafic iSCSI était retransmis, les files se formaient, et la couche multipath basculait occasionnellement—ajoutant plus de turbulence.
Les graphiques de bande passante restaient calmes parce que les paquets perdus n’apparaissent pas comme débit utilisé.

Le rollback—retour à MTU 1500 bout en bout—stabilisa tout immédiatement. Plus tard, ils réintroduisirent les jumbo frames seulement après avoir appliqué des vérifications de conformité MTU dans l’automatisation
et alerté sur les drops d’interface et les retransmissions TCP. La leçon : des « optimisations » non bout en bout ne sont que de nouveaux modes de panne.

Pratique ennuyeuse mais correcte qui a sauvé la journée : discipline du multipath

Une plateforme liée à la finance exécutait des bases de données critiques sur des LUNs iSCSI. La configuration n’était pas exotique : double contrôleur de stockage, deux fabrics, multipath sur chaque hôte.
Ce qui était différent, c’était la discipline de l’équipe. Chaque hôte avait le même template de config multipath, les mêmes timeouts, et un test trimestriel « tirer un câble » en staging.

Un après-midi, un switch top-of-rack commença à logger des erreurs CRC sur un port connecté à un contrôleur de stockage.
Les erreurs étaient assez intermittentes pour que le lien reste up, mais suffisantes pour causer des retries et des problèmes de session iSCSI occasionnels.

Les bases de données ne tombèrent pas. La latence applicative augmenta légèrement, puis se stabilisa.
Le monitoring détecta des basculements de chemin accrus et une latence I/O élevée sur un groupe de chemins. L’astreinte drainât le trafic, fit volontairement échouer le lien suspect, et ouvrit un ticket hardware.

Le postmortem n’était pas dramatique. C’est le but. Le multipath avec des timeouts sensés transforma un problème physique instable en un événement de maintenance plutôt qu’en incident client.
Ils n’ont pas « résolu » la physique ; ils l’ont planifiée et pratiquée jusqu’à ce que cela devienne un réflexe.

Pratique : tâches concrètes avec commandes, sorties et décisions

Voici les tâches que vous effectuez réellement quand les systèmes vacillent. Chacune inclut ce que signifie la sortie et quelle décision prendre ensuite.
Les commandes supposent un client Linux sauf indication contraire.

1) Identifier si vous êtes sur NFS, iSCSI ou NVMe-oF depuis l’hôte

cr0x@server:~$ findmnt -t nfs,nfs4
TARGET           SOURCE                 FSTYPE OPTIONS
/mnt/shared      nas01:/export/shared   nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
NAME   TYPE  SIZE MODEL             TRAN
sda    disk  200G Virtual Disk
sdb    disk  2.0T LIO-ORG   iscsi    iscsi
nvme0n1 disk  1.6T NVMeDisk          nvme

cr0x@server:~$ nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:...
\
 +- nvme0 tcp traddr=10.20.0.50 trsvcid=4420 live

Signification : findmnt montre les montages NFS actifs ; lsblk montre le transport ; nvme list-subsys confirme les sessions NVMe-oF.

Décision : Choisissez la bonne voie de diagnostic. Ne pas dépanner NFS comme du stockage bloc ou l’inverse.

2) NFS : confirmer les options de montage qui peuvent faire ou défaire la latence

cr0x@server:~$ nfsstat -m
/mnt/shared from nas01:/export/shared
 Flags: rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.20.1.21

Signification : hard signifie réessais I/O indéfiniment (plus sûr pour les données, peut « bloquer » les applis) ; timeo et retrans influencent le comportement d’attente ; rsize/wsize impactent le débit.

Décision : Pour les données critiques, conservez hard. Si les applis visibles par les utilisateurs ne tolèrent pas de longs blocages, envisagez des changements d’architecture (cache local, pipelines asynchrones) plutôt que de passer à soft.

3) NFS : mesurer le comportement au niveau RPC (latence et retrans)

cr0x@server:~$ nfsstat -rc
Client rpc stats:
calls      retrans    authrefrsh
2143098    153        2143120

Client nfs v4:
null         read         write        open         close        getattr
0            152340       91822        4311         4309         602111

Signification : les retransmissions suggèrent perte/congestion réseau ou surcharge serveur. Même des comptes « faibles » de retrans peuvent corréler avec des pics de latence tail.

Décision : Si retrans est non nul et en hausse, traitez-le comme un P1. Vérifiez les erreurs réseau et la charge serveur avant d’ajuster les applis.

4) NFS : repérer les blocages induits par le serveur dans les logs kernel

cr0x@server:~$ dmesg -T | tail -n 8
[Tue Feb  4 10:44:21 2026] nfs: server nas01 not responding, still trying
[Tue Feb  4 10:44:23 2026] nfs: server nas01 not responding, still trying
[Tue Feb  4 10:44:41 2026] nfs: server nas01 OK

Signification : Les clients ont connu des timeouts ; la récupération a eu lieu. C’est souvent le premier signal sur l’hôte d’un hic serveur ou d’une micro-interruption réseau.

Décision : Corrélez avec les compteurs d’interface de switch et le CPU/IO du serveur NFS. Si ça se répète, planifiez des mitigations (séparer les charges, ajouter HA, améliorer le réseau).

5) iSCSI : valider sessions et découverte des targets

cr0x@server:~$ sudo iscsiadm -m session
tcp: [1] 10.20.0.10:3260,1 iqn.2003-01.org.linux-iscsi.san01:storage.lun1 (non-flash)
tcp: [2] 10.20.0.11:3260,1 iqn.2003-01.org.linux-iscsi.san01:storage.lun1 (non-flash)

cr0x@server:~$ sudo iscsiadm -m node -o show | head
# BEGIN RECORD 2.1.8
node.name = iqn.2003-01.org.linux-iscsi.san01:storage.lun1
node.tpgt = 1
node.startup = automatic

Signification : Deux sessions représentent typiquement deux chemins (bien). startup automatic signifie reconnexion au boot.

Décision : Si vous ne voyez qu’une session alors que vous en attendez deux, arrêtez : vous avez un point de défaillance unique et probablement un déséquilibre de performance.

6) iSCSI : vérifier santé du multipath et politique de chemin

cr0x@server:~$ sudo multipath -ll
mpatha (36001405a7c3d2a1b9c2d7f1a4e5b6c7d) dm-2 LIO-ORG,iscsi_disk
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Signification : Les deux chemins sont active/ready. queue_if_no_path signifie que les I/O font la queue en cas de perte totale de chemin (peut causer des blocages applicatifs).
La politique influence l’équilibrage de charge.

Décision : Si un chemin est faulty ou failed, corrigez d’abord les problèmes physiques/réseau. Ne « tweakez » pas autour d’un chemin cassé.

7) iSCSI : confirmer les timeouts pour éviter « bloquer pour toujours » ou « échouer trop vite »

cr0x@server:~$ sudo iscsiadm -m node -T iqn.2003-01.org.linux-iscsi.san01:storage.lun1 -p 10.20.0.10:3260 -o show | egrep 'noop|replacement|timeout'
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.session.timeo.replacement_timeout = 120

Signification : Les noops détectent les chemins morts ; replacement timeout contrôle le comportement de basculement. Trop grand = longs blocages ; trop petit = sessions instables.

Décision : Alignez ces valeurs avec multipath et la tolérance applicative. Testez le basculement sous charge ; ne devinez pas en production.

8) NVMe-oF : lister contrôleurs et détails de transport

cr0x@server:~$ sudo nvme list
Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
/dev/nvme0n1     deadbeefdeadbeef     NVMeOF-Target                             1         2.00  TB / 2.00  TB       4 KiB +  0 B     1.3

cr0x@server:~$ sudo nvme list-subsys
nvme-subsys0 - NQN=nqn.2014-08.org.nvmexpress:uuid:3b8d...
\
 +- nvme0 tcp traddr=10.20.0.50 trsvcid=4420 live

Signification : Confirme NVMe-oF sur TCP et quelle IP/port de target vous utilisez.

Décision : Si vous voyez des transports inattendus ou des chemins manquants, arrêtez et corrigez la topologie avant de chasser la performance.

9) NVMe-oF : vérifier le multipath et l’état ANA (accès asymétrique)

cr0x@server:~$ cat /sys/module/nvme_core/parameters/multipath
Y

cr0x@server:~$ sudo nvme list-ana /dev/nvme0
ANA Log for NVMe device:nvme0
ANA group ID: 1
  state: optimized
  NSIDs: 1
ANA group ID: 2
  state: non-optimized
  NSIDs: 1

Signification : Le multipath est activé. Un chemin est optimized, un autre non-optimized (commun avec les systèmes à double contrôleur).

Décision : Assurez-vous que votre hôte préfère les chemins optimized. Si le trafic passe par des chemins non-optimized, vous subirez une latence évitable.

10) Réseau : vérifier les erreurs d’interface (la vérité peu glamour)

cr0x@server:~$ ip -s link show dev ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    9876543210 1234567  0      12      0        0
    TX:  bytes packets errors dropped carrier collsns
    8765432109 1122334  0      0      0       0

Signification : Des drops RX existent. Les drops sur une interface de stockage sont des multiplicateurs de latence.

Décision : Investiguer la couche physique, les mismatches MTU, la congestion. N’acceptez pas « quelques drops » sur les réseaux stockage.

11) Réseau : mesurer les retransmissions TCP (surtout pour iSCSI/NFS/NVMe-TCP)

cr0x@server:~$ nstat -az | egrep 'TcpRetransSegs|TcpExtTCPSynRetrans|TcpTimeouts'
TcpRetransSegs            1842
TcpExtTCPSynRetrans       0
TcpTimeouts               21

Signification : Les retransmissions et timeouts indiquent perte ou congestion sévère. Cela corrèle souvent avec des pics de latence p99.

Décision : Si ces compteurs augmentent pendant les incidents, traitez le chemin réseau comme suspect, pas seulement la baie de stockage.

12) OS : vérifier si le kernel attend sur l’I/O (blocage stockage vs problème CPU)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 812344  92124 933112    0    0   120   340  890 1200 12  4 80  4  0
 3  5      0 810120  92124 933900    0    0   110   500  910 1300 10  3 60 27  0
 1  6      0 808992  92124 934100    0    0   130   480  920 1290  9  3 58 30  0

Signification : Un b élevé (processus bloqués) et un wa élevé (I/O wait) pointent le stockage comme goulot.

Décision : Passez du « debug app » au « debug chemin I/O ». Collectez iostat, stats protocole et compteurs réseau immédiatement.

13) Périphériques bloc : surveiller latence par disque et profondeur de file

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   r_await   w_await   aqu-sz  %util
sdb              120.0   80.0     6.10    18.40      2.95   98.0
dm-2             240.0  160.0     7.50    21.30      6.10   99.0

Signification : await est la latence moyenne ; aqu-sz montre les I/O en file ; un %util élevé sur un dm suggère saturation quelque part sur le chemin.

Décision : Si les await montent alors que le réseau est propre, suspectez la charge de l’array/du contrôleur ou un déséquilibre de chemin. Si les await montent avec retrans/drops, suspectez le réseau/transport.

14) NFS : détecter la douleur des métadonnées avec une simple sonde intensive en syscalls

cr0x@server:~$ sudo strace -f -tt -T -e trace=file ls -l /mnt/shared >/dev/null
10:51:02.112345 statx(AT_FDCWD, "/mnt/shared", AT_STATX_SYNC_AS_STAT, STATX_BASIC_STATS, ...) = 0 <0.012341>
10:51:02.124910 openat(AT_FDCWD, "/mnt/shared", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 <0.020118>

Signification : Ces opérations fichier à <0.02s> sont lentes pour un simple listing. C’est de la latence métadonnée.

Décision : Si les ops métadonnées sont lentes, arrêtez de blâmer le « débit disque ». Séparez les charges, ajustez les threads/cache du serveur NFS, ou redesign pour réduire le bavardage de métadonnées.

15) NVMe-oF : vérifier que l’hôte voit les files attendues et le comportement d’interruptions

cr0x@server:~$ cat /proc/interrupts | egrep 'nvme|ens192' | head
 42:  1234567  0  0  0  IR-PCI-MSI 524288-edge  nvme0q0
 43:  2345678  0  0  0  IR-PCI-MSI 524289-edge  nvme0q1
 58:  3456789  0  0  0  IR-PCI-MSI 393216-edge  ens192-TxRx-0

Signification : Des queues NVMe existent ; les interruptions sont déclenchées. Si tout est bloqué sur un seul CPU, vous verrez un déséquilibre et de la latence.

Décision : Si les interruptions se concentrent sur un cœur, ajustez l’affinité IRQ / RSS, et retestez la latence sous charge. NVMe-oF récompense le tuning CPU/réseau ; il punit la négligence.

Playbook de diagnostic rapide (trouver le goulot sans une guerre de salle d’astreinte d’une semaine)

Premier : classifier la panne en 60 secondes

• Est-ce la latence stockage ou le CPU applicatif ? Vérifiez vmstat (processus bloqués, iowait) et l’état des threads applicatifs.
• Est-ce spécifique au protocole ? logs client NFS vs événements de session iSCSI vs resets de contrôleur NVMe.
• Est-ce isolé ou systémique ? Un hôte, un rack, une AZ, ou tout le monde ?

Second : vérifiez le réseau sérieusement

1. Drops/erreurs d’interface sur clients et ports stockage : ip -s link.
2. Retrans/TCP timeouts pour les protocoles TCP : nstat.
3. Consistance du chemin : MTU bout en bout, santé LACP, bonne VLAN.

Si vous trouvez des drops/retrans, arrêtez. Corrigez cela avant d’optimiser le stockage. Le trafic stockage n’est pas « juste du trafic ». C’est le sang de vos applis.

Troisième : validez le pathing et le comportement de basculement

• iSCSI : iscsiadm -m session, multipath -ll, et logs kernel pour resets de session.
• NVMe-oF : nvme list-subsys, nvme list-ana, multipath activé.
• NFS : rechercher « server not responding » et augmentation de retrans avec nfsstat -rc.

Quatrième : vérifier le système de stockage backend (sans langue de bois)

• L’array est-elle en rebuild, scrub, ou throttle ?
• Satigez-vous le CPU du contrôleur ou le cache ?
• Un chemin/contrôleur est-il plus chaud que l’autre (asymétrie) ?

Cinquième : mesurer, puis changer une seule chose

Capturez la latence de référence (p50/p95/p99), retrans/drops, tailles de file, et états de chemin. Faites un seul changement, re-mesurez.
Si vous ne pouvez pas mesurer, vous n’affinez pas ; vous jouez.

Erreurs courantes : symptômes → cause racine → correction

1) Symptomatique : Les montages NFS « se bloquent » et les processus passent en état D

• Cause racine : montages hard attendant un serveur lent/injoignable, ou contention de verrou sur le serveur.
• Correction : diagnostiquer la santé serveur et les pertes réseau ; ajouter HA (active/active si possible), séparer les charges bruyantes, et s’assurer que les timeouts clients sont raisonnables. Évitez de « corriger » en passant à soft pour des données critiques.

2) Symptomatique : timeouts iSCSI intermittents, erreurs système de fichiers, pauses VM aléatoires

• Cause racine : oscillation de chemin (câble/SFP/NIC défectueux), mismatch MTU causant des drops, ou mauvaise configuration multipath.
• Correction : assurer des chemins redondants, valider MTU bout en bout, surveiller retrans et erreurs d’interface, standardiser les politiques multipath sur les hôtes.

3) Symptomatique : « Super débit, latence terrible » sur NFS

• Cause racine : latence métadonnées et opérations synchrones ; trop de clients en contention sur le même export ; famine de threads serveur.
• Correction : séparer les charges par export/serveur, ajuster les threads et le backend du serveur NFS, envisager des caches locaux pour les systèmes de build, et réduire l’explosion du nombre de fichiers.

4) Symptomatique : NVMe-oF over TCP montre des pics p99 aléatoires sous charge

• Cause racine : perte de paquets ou micro-bursts de congestion ; problèmes d’affinité CPU/IRQ ; buffering/ECN mal configurés dans le fabric.
• Correction : éliminer d’abord les drops ; tuner NIC RSS/affinité IRQ, vérifier la stratégie ECN/aqm (si utilisée), et s’assurer que multipath/ANA préfère les chemins optimized.

5) Symptomatique : corruption ou incohérences mystérieuses de système de fichiers sur LUNs iSCSI

• Cause racine : même LUN monté en lecture-écriture par plusieurs hôtes sans coordination cluster-aware ; absence de fencing.
• Correction : imposer des sémantiques mono-auteur ou utiliser un système de fichiers cluster-aware avec fencing (ou passer à NFS si vous avez vraiment besoin de fichiers partagés).

6) Symptomatique : erreurs « stale file handle » NFS après maintenance

• Cause racine : système de fichiers/export côté serveur déplacé ou remplacé de manière à changer les file handles/inodes ; le basculement n’a pas préservé l’identité.
• Correction : remonter les clients ; corriger la procédure HA pour préserver l’identité du système de fichiers ; éviter les échanges manuels d’export sans coordination.

7) Symptomatique : iSCSI semble OK, mais pics de latence pendant les fenêtres de sauvegarde

• Cause racine : contention backend array (snapshots, réplication, rebuild), ou sursouscription réseau quand le trafic de sauvegarde partage les uplinks.
• Correction : isoler le trafic de sauvegarde, planifier les opérations lourdes de l’array, appliquer du QoS, et surveiller latences côté array et taux de hit du cache.

8) Symptomatique : « On est passé à 100GbE mais rien de plus rapide »

• Cause racine : limites d’un flux unique, mauvaises profondeurs de file, goulot CPU, ou limites media/contrôleur du stockage.
• Correction : mesurer l’utilisation CPU et la distribution des IRQ ; paralléliser les charges ; valider que l’array peut réellement fournir davantage ; ajuster soigneusement les profondeurs de file.

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

Checklist de décision : choisir le protocole selon la charge et la réalité de l’équipe

1. Besoin de fichiers POSIX partagés ? Commencez par NFSv4.1+.
2. Besoin d’un périphérique bloc brut ? Commencez par iSCSI (sauf besoin prouvé de NVMe-oF).
3. Besoin d’une latence ultra-faible et d’un fort parallélisme ? Envisagez NVMe-oF, mais exigez d’abord des SLO réseau et de l’observabilité.
4. Besoin multi-writer ? NFS pour fichiers, ou une couche bloc cluster-aware avec fencing. Ne « montez jamais simplement le LUN sur les deux ».
5. Maturité ops disponible ? Si votre équipe ne peut pas gérer de façon cohérente MTU, LACP et monitoring, ne déployez pas le protocole qui amplifie ces erreurs (NVMe-oF).

Checklist construction : faire survivre aux pannes normales

1. Deux chemins réseau indépendants (switches séparés) pour le trafic stockage.
2. Stratégie MTU explicite, validée bout en bout, avec contrôles automatisés.
3. Monitoring hôte : retransmissions, drops d’interface, percentiles de latence, profondeur de file.
4. Procédures documentées et testées de basculement : tirer un lien, redémarrer un contrôleur, confirmer la récupération sous charge.
5. Gestion des changements : les modifications du réseau stockage requièrent la même rigueur que les changements de schéma de base de données.

Checklist opérationnelle : ce que vous standardisez sur les hôtes

1. NFS : options de montage cohérentes ; utiliser NFSv4.1+ quand approprié ; alerter sur les logs « server not responding » et les retrans.
2. iSCSI : paramètres iscsiadm cohérents ; config multipath cohérente ; exercices périodiques de défaillance de chemin.
3. NVMe-oF : multipath activé ; préférences de chemin ANA-aware ; standards de tuning IRQ/RSS ; alertes sur drops/retrans et resets de contrôleur.

FAQ

1) NFS est-il « plus lent » qu’iSCSI ?

Pas intrinsèquement. NFS peut être extrêmement rapide pour les I/O séquentielles importantes. Il perd souvent face aux petites opérations synchrones et aux charges riches en métadonnées.
iSCSI tend à être plus prévisible pour les modèles orientés bloc.

2) Peut-on exécuter des bases de données sur NFS ?

Oui, et beaucoup le font. Mais il faut valider les sémantiques et la latence (en particulier le comportement fsync), et disposer d’un serveur NFS robuste.
Si vous ne pouvez pas mesurer la latence tail, vous jouez aux dés avec vos redo logs.

3) Pourquoi les clients NFS « se bloquent » au lieu d’échouer rapidement ?

Parce que les montages hard priorisent l’intégrité des données : le client continue de réessayer pour éviter des écritures partielles et la corruption.
Si votre appli ne tolère pas cela, la bonne correction est généralement architecturale (timeouts, retries, files), pas passer à soft.

4) iSCSI est-il sûr pour un accès partagé depuis plusieurs hôtes ?

Seulement avec une couche cluster-aware et fencing (système de fichiers cluster, gestionnaire de volumes cluster, etc.). Sinon vous risquez la corruption.
Les périphériques bloc supposent un auteur unique à moins d’avoir prouvé le contraire.

5) NVMe-oF over TCP a-t-il du sens, ou RDMA est-il obligatoire ?

NVMe-oF over TCP est souvent le choix pragmatique : plus facile à déployer sur Ethernet existant, moins de réglages spécialisés.
RDMA peut offrir une latence plus basse et un coût CPU réduit, mais il élève le niveau de configuration du fabric et l’expertise opérationnelle requise.

6) Quel est le coût caché le plus important de NVMe-oF ?

Le coût opérationnel. Vous aurez besoin d’une meilleure observabilité réseau, d’un contrôle de changement plus strict et d’une discipline de tuning accrue.
Quand vous pouvez le faire, c’est excellent. Quand vous ne le pouvez pas, c’est une façon coûteuse d’apprendre l’humilité.

7) Faut-il toujours activer les jumbo frames pour le stockage ?

Seulement si vous pouvez garantir la cohérence MTU bout en bout et surveiller les drops. Sinon vous échangez un gain théorique contre un mode de panne réel.
Un MTU 1500 correctement configuré bat un MTU 9000 « majoritairement configuré ».

8) Quelle est la façon la plus rapide de dire si le réseau est le problème ?

Vérifiez les drops/erreurs d’interface (ip -s link) et les retrans/timeouts TCP (nstat) pendant la fenêtre d’incident.
Si ces compteurs augmentent, votre « problème de stockage » est au moins en partie un problème réseau.

9) Pour les datastores de virtualisation, NFS ou iSCSI ?

Les deux peuvent fonctionner. NFS l’emporte souvent sur la simplicité (un export, provisionnement facile), iSCSI peut l’emporter sur la prévisibilité et l’intégration avec certaines fonctionnalités d’hyperviseur.
Choisissez selon vos forces opérationnelles et vos exercices de panne, pas selon le folklore.

Conclusion : étapes pratiques suivantes

Si vous choisissez aujourd’hui sans contraintes particulières : utilisez NFS pour les fichiers partagés, iSCSI pour le stockage bloc polyvalent,
et réservez NVMe-oF aux charges qui peuvent prouver qu’elles ont besoin d’une latence plus faible et aux équipes qui prouvent qu’elles savent exploiter le fabric.

Faites ceci ensuite, dans l’ordre :

1. Notez votre objectif de latence et votre tolérance aux pannes (p95/p99, durée de blocage, attentes de récupération).
2. Instrumentez le chemin : drops, retransmits, stats protocole, latence backend.
3. Exécutez un drill de panne : tirez un lien, redémarrez un contrôleur, faites tomber un switch—mesurez l’impact applicatif.
4. Standardisez les configs (options de montage, multipath, timeouts) et appliquez-les via l’automatisation.
5. Séparez les charges incompatibles avant de chasser des tunings héroïques (les tempêtes de métadonnées et les logs n’ont pas leur place sur le même export NFS).

Le protocole gagnant est celui qui respecte vos SLOs et ne demande pas des exploits quotidiens. Votre futur vous remerciera. Silencieusement. En dormant.