Linux sans magie #56 — Du stockage au réseau : diagnostiquer la bonne couche

Depuis l'article #36, nous avons parcouru le stockage Linux, de df et du jusqu'aux filesystems, aux partitions, à LVM, au RAID, à LUKS et aux procédures de réparation. Cette progression suit une idée simple : avant d'agir, identifier la couche qui produit réellement le symptôme.

Mais une application qui n'arrive plus à lire un fichier n'a pas toujours un problème de disque. Son répertoire peut se trouver sur un partage NFS distant, une ressource fournie par une plateforme cloud ou un volume dont le fonctionnement dépend d'une connexion. Le diagnostic doit alors franchir une frontière : celle entre le stockage et le réseau.

Ce dernier article du chapitre stockage propose une méthode de synthèse, un exemple d'incident et les premiers outils qui serviront de point d'entrée au prochain chapitre consacré au réseau Linux.

Ce que les vingt articles précédents ont construit

La progression du #36 au #55 n'était pas une succession de commandes isolées. Elle a suivi les dépendances d'un système Linux en production :

Articles	Sujet	Question opérationnelle
#36 à #40	Occupation, disques, identifiants, montage et `fstab`	Quel espace est réellement utilisé et où est-il monté ?
#41 à #43	GPT/MBR, partitions et extension	Quelle structure de disque porte les données ?
#44 à #48	LVM et snapshots	Quelle couche logique présente le volume à l'application ?
#49 à #50	RAID logiciel `mdadm`	Quelle redondance reste disponible en cas de panne ?
#51	LUKS et `cryptsetup`	Qui peut déverrouiller les blocs stockés ?
#52 à #55	Disque plein, lecture seule, inodes, `fsck`	Quel incident empêche l'exploitation du filesystem ?

La leçon commune est plus importante que n'importe quel utilitaire : un symptôme visible dans un fichier peut venir du filesystem, de la couche bloc, du service ou d'une infrastructure externe.

Le RAID ne tient pas lieu de sauvegarde ; un snapshot n'est pas systématiquement une copie indépendante ; le chiffrement ne garantit pas la disponibilité ; et un fsck ne résout pas un problème de connectivité. Chaque technologie possède un rôle et des limites.

Une application, plusieurs couches à vérifier

Sur un serveur Linux, un chemin tel que /srv/data/rapport.csv ne renseigne pas, à lui seul, la localisation physique des données.

Application
    |
    +-- /srv/data/rapport.csv
            |
            +-- Montage local ext4 ou XFS
            |       |
            |       +-- LVM / LUKS / RAID / disque
            |
            +-- Montage réseau NFS
                    |
                    +-- Interface réseau → IP → route
                            |
                            +-- Serveur NFS distant → stockage distant

Les deux situations peuvent produire une erreur d'accès à un même chemin. Pourtant, la bonne intervention diffère radicalement : réparer le filesystem local d'un client ne corrigera pas un serveur NFS indisponible.

Cette frontière constitue la transition naturelle vers le réseau : avant de tester la connexion, il faut prouver que le service dépend réellement du réseau.

Situation terrain : un répertoire de données ne répond plus

Prenons un exemple fictif. Une application sur le serveur app01 consulte des fichiers dans /srv/data. Elle devient lente et finit par signaler des erreurs de lecture. La supervision mentionne simultanément des délais d'accès au répertoire.

Trois hypothèses sont possibles :

un filesystem local est plein ou en lecture seule ;
un volume local rencontre des erreurs d'E/S ;
/srv/data est un montage distant et sa dépendance réseau ou son serveur ne répond plus.

Ne supposez pas que le problème vient du disque simplement parce que la ressource ressemble à un répertoire.

Étape 1 — Identifier le type de stockage

Commencez par les outils connus :

findmnt --target /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f
df -hT /srv/data

findmnt révèle le point de montage et le type de filesystem. Un montage local peut apparaître comme ext4 ou xfs avec un périphérique bloc. Un partage NFS peut afficher nfs ou nfs4 et une source de type serveur:/export.

lsblk liste les périphériques blocs visibles, pas tous les stockages distants : l'absence d'un partage dans lsblk ne prouve pas qu'il n'existe pas. Quant à df, certaines requêtes à un montage réseau bloqué peuvent elles-mêmes attendre ou expirer. Sur un hôte en incident, exécutez les sondes selon une procédure qui tient compte de leur délai et de leur impact.

Si la source est locale, reprenez les méthodes des #52 à #55 et examinez les journaux noyau. Si elle est distante, ne lancez pas e2fsck sur le client : passez à l'investigation du chemin réseau et du service de fichiers.

Étape 2 — Conserver les preuves avant d'agir

Le premier diagnostic doit éviter de changer l'état du système. Relevez les heures, l'hôte, la source du montage, les messages applicatifs et les éventuelles interventions récentes.

journalctl -k --since "1 hour ago" --no-pager
journalctl --since "1 hour ago" --no-pager -n 150
findmnt --target /srv/data

Des messages NFS indiquant des délais d'attente, un serveur injoignable ou des problèmes de récupération d'état suggèrent une dépendance distante. Des erreurs d'I/O peuvent cependant avoir plusieurs origines : corrélez les journaux et la supervision côté serveur avant de conclure.

N'enchaînez pas les démontages forcés, les remounts ou les redémarrages de services : ces gestes peuvent interrompre des écritures, masquer des traces ou provoquer un incident supplémentaire.

Étape 3 — Introduire les premiers outils réseau

Une fois la dépendance distante établie, Linux fournit des outils de lecture qui permettront de commencer le prochain chapitre :

ip -br link
ip -br address
ip route show
getent ahosts serveur-exemple.invalid

ip -br link résume l'état des interfaces ; ip -br address présente leurs adresses IP ; ip route show affiche la table de routage concernée dans l'espace réseau courant. Ces commandes observent la configuration : elles ne créent aucune interface et ne changent pas les routes.

Le nom serveur-exemple.invalid est fictif : son échec de résolution est attendu. Sur un incident réel, remplacez-le par le nom exact et autorisé du serveur. getent ahosts interroge la résolution de noms du système ; selon sa configuration, cela peut déclencher des requêtes réseau. Le résultat ne garantit pas que le service distant est joignable.

Un exemple de résultat plausible :

enp1s0           UP             192.0.2.20/24
default via 192.0.2.1 dev enp1s0
192.0.2.0/24 dev enp1s0 proto kernel scope link

Les adresses 192.0.2.0/24 sont réservées à la documentation. Ce schéma montre une interface configurée avec une adresse et une route par défaut ; il ne prouve ni la connectivité effective ni l'ouverture du service NFS.

Une nouvelle méthode : séparer nom, chemin et service

Face à un service distant indisponible, trois questions doivent être examinées dans l'ordre, sans confondre leurs réponses.

Question	Observation initiale	Ce qui reste à prouver
Le nom du serveur est-il résolu ?	`getent ahosts`	Que l'adresse obtenue est bien celle attendue
Existe-t-il un chemin IP prévu ?	`ip route show`	Que les paquets atteignent réellement le serveur
Le service de fichiers répond-il ?	Journaux client et supervision serveur	Que le service distant accepte et traite les requêtes

Une route présente n'est pas une preuve de bout en bout. Une résolution DNS correcte n'implique pas une session NFS fonctionnelle. Inversement, une adresse IP peut être joignable alors que le service de fichiers est indisponible.

Les futurs articles réseau approfondiront les interfaces, les adresses IPv4/IPv6, les routes, la résolution DNS et les méthodes de test ciblées. Cette synthèse ne prétend pas constituer un guide complet de dépannage NFS.

Ce que le stockage distant change dans l'exploitation

Le stockage en réseau ajoute des dépendances difficiles à voir dans un simple arbre de répertoires : lien physique ou virtuel, réseau local, routage, contrôle d'accès, serveur distant et disponibilité des services associés.

Un problème de montage au démarrage peut ainsi venir d'une ressource distante indisponible plutôt que d'une erreur dans le filesystem local. La configuration de /etc/fstab, les options du montage et l'ordonnancement des services doivent alors être examinés selon la distribution et le protocole.

De la même manière, une application peut continuer à voir un chemin tout en bloquant pendant certaines opérations d'E/S. La disponibilité apparente d'un point de montage n'établit pas la santé de ses dépendances.

Pour améliorer l'exploitation, documentez :

le serveur ou service propriétaire des données ;
le protocole utilisé et le nom attendu du serveur ;
les équipes responsables du client, du réseau et du stockage distant ;
les alertes et les journaux permettant de corréler les incidents ;
la procédure de restauration des données indépendante du simple remontage.

L'objectif n'est pas de déplacer tous les incidents vers l'équipe réseau, mais de donner à chaque équipe des preuves sur la couche réellement en défaut.

Sécurité : la frontière réseau compte aussi

Un filesystem chiffré localement avec LUKS et un accès à un partage réseau répondent à des modèles de menace différents. Le chiffrement du disque et le chiffrement du transport ne sont pas interchangeables.

Avec un service de fichiers distant, évaluez séparément l'authentification, les autorisations, l'exposition du service, le réseau de transport et la protection des données au repos côté serveur. Ne présumez pas qu'un montage NFS constitue un tunnel chiffré ; les protections dépendent du protocole et de son déploiement.

Évitez d'exposer inutilement un service de stockage sur un réseau non maîtrisé. Pour toute modification de routes, de filtrage ou d'authentification, exigez une validation explicite et une procédure de retour arrière, en particulier si l'accès d'administration lui-même passe par le réseau.

Vérifier sans modifier la production

Cette synthèse ne propose aucune écriture, réparation ou reconfiguration. Dans un environnement de test ou lors d'un incident autorisé, le premier résultat attendu est documentaire : identifier le point de montage, son type, sa source et la couche qui présente la première anomalie vérifiable.

La vérification minimale consiste à comparer les sorties de findmnt, lsblk, ip et les journaux avec la topologie officielle de l'environnement. Si le montage est local, documentez l'état du filesystem et du périphérique. S'il est distant, faites corréler le nom, la route, les alertes et l'état du serveur avec les équipes concernées.

Les commandes d'observation peuvent produire des informations sensibles sur les hôtes et la topologie. Protégez les extraits de journaux et évitez de les publier sans vérification.

Bilan du chapitre stockage

Les articles #36 à #55 nous ont appris à distinguer cinq familles de questions : où sont les données, comment les blocs sont organisés, quelles couches assurent redondance ou confidentialité, pourquoi les accès échouent et comment intervenir sans détruire l'existant.

Une méthode durable se résume ainsi :

Localiser l'objet et sa couche réelle.
Observer avec les outils les moins intrusifs.
Corréler les traces entre filesystem, bloc, service et plateforme.
Évaluer le risque avant toute modification.
Vérifier l'état après une intervention autorisée.

Elle s'applique aussi au réseau. La différence est qu'il faudra apprendre à suivre un paquet plutôt qu'un bloc, et à distinguer interface, adresse, route, résolution de noms et service distant.

Références officielles

Conclusion — Du bloc au paquet

Avec le #56, le parcours consacré au stockage se clôt. Nous avons appris à suivre les données depuis un chemin applicatif jusqu'aux couches qui les conservent, les protègent et les rendent accessibles. La même discipline de diagnostic sera notre fil conducteur pour le réseau.

La prochaine étape de la série ouvrira donc un chapitre Réseau Linux, en commençant par les interfaces et leurs états : avant de modifier une adresse ou une route, il faut savoir identifier correctement l'interface et comprendre ce que ses indicateurs disent — ou ne disent pas — de la connectivité.