Des exports et des montages NFS qui échouent sans casse

NFS est l'un des plus vieux outils de la boîte d'un administrateur Linux, et l'un des plus faciles à régler presque correctement. Un partage qui se monte n'est pas la même chose qu'un partage qui se comporte bien quand le réseau cligne, quand un client se conduit mal ou quand le filer redémarre. Voici les réglages et les contrôles qui font la différence, des deux côtés du montage.

Pourquoi les fichiers partagés tournent mal

La raison habituelle d'utiliser NFS est un groupe de serveurs web ou applicatifs qui doivent voir les mêmes fichiers : médias téléversés, assets générés, une arborescence documentaire partagée. Cela se met en place vite, souvent en copiant un exemple, et cela marche du premier coup. Les problèmes arrivent plus tard. Un export ouvert à tout un réseau laisse une machine de test oubliée écrire dans le contenu de production. Un client monté avec des options qui renoncent sur erreur perd des écritures en silence. Un serveur qui ne peut pas atteindre son filer au démarrage reste bloqué des minutes au lieu de démarrer sans le partage. Rien de tout cela n'est visible le jour de la configuration.

Sur le filer : exporter vers des noms, écraser root

Exportez chaque partage vers les hôtes qui en ont besoin, par nom, avec les droits les plus étroits qui fonctionnent :

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

Des hôtes nommés, pas des réseaux. Un joker ou un sous-réseau entier signifie que toute machine qui atterrit un jour sur ce réseau peut monter le partage. Lister les hôtes fait de chaque client une décision délibérée.

root_squash. Root sur un client devient un utilisateur sans privilège sur le filer. Sans cela, quiconque a root sur n'importe quel client possède chaque fichier du partage.

sync. Le serveur n'acquitte une écriture qu'une fois qu'elle est posée sur un stockage stable. L'alternative plus rapide acquitte des écritures qu'une coupure de courant peut encore effacer.

Appliquez et vérifiez ce qui est réellement exporté, qui n'est pas toujours ce que vous pensez avoir écrit :

exportfs -ra
exportfs -v

Puis restreignez le service, au firewall de l'hôte, aux mêmes clients. Avec firewalld, une zone dédiée garde cela lisible :

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

Les exports et les règles de firewall sont deux verrous indépendants. Utilisez les deux.

Sur le client : des montages hard qui ne bloquent pas le démarrage

Le côté client décide de ce qui se passe quand le filer est lent ou brièvement injoignable :

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

hard, pas soft. Un montage hard réessaie jusqu'à ce que le serveur réponde. Un montage soft renvoie une erreur après un certain nombre de tentatives, et beaucoup d'applications ne vérifient pas cette erreur à l'écriture, donc des données peuvent être perdues sans que personne en soit informé. Si un partage contient quoi que ce soit qui vous importe, montez-le en hard. Le prix est qu'un processus qui touche le partage attend pendant l'absence du filer, ce qui est le comportement honnête.

_netdev et nofail. Le montage attend le réseau, et un filer absent n'empêche pas le serveur de démarrer. Combiné à un délai de montage, la machine se lève, l'application peut signaler clairement le partage manquant, et le montage se termine quand le filer revient.

Figez le protocole que vous avez testé. Clients et serveurs négocient une version de protocole. Fixez explicitement celle que vous avez testée (nfsvers= ou vers=) pour qu'une mise à jour d'un côté ou de l'autre ne puisse pas changer discrètement le comportement de verrouillage et de cache sous vos pieds.

Vérifiez ce qui a réellement été négocié, pas ce que vous avez demandé :

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

mountstats montre les comptes par opération, les retransmissions et les temps d'aller-retour. Un nombre de retransmissions qui grandit est l'alerte précoce que le chemin réseau ou le filer a besoin d'attention.

Redondance sur le câble, snapshots sur le disque

Un filer n'est disponible que dans la mesure où ses liens réseau le sont. Raccordez-le par des liens agrégés à une paire de switches, hachez le bond sur les adresses et les ports pour que les deux liens transportent du trafic, et gardez filer et clients sur le même segment Layer 2 quand vous le pouvez. Un chemin commuté a moins de pièces mobiles qu'un chemin routé et garde le trafic de fichiers à l'intérieur du réseau privé.

Côté stockage, un système de fichiers avec checksums et snapshots change la façon de traiter les erreurs. Avec ZFS, par exemple :

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

Un snapshot avant chaque déploiement ou changement en masse rend une mauvaise modification réversible en quelques secondes, et un répertoire de snapshot caché permet à un administrateur de recopier un seul fichier sans tâche de restauration.

Quand un partage de fichiers est la mauvaise réponse

NFS est excellent pour du contenu écrit occasionnellement et lu par beaucoup. C'est un mauvais foyer pour les fichiers de données d'une base, pour des charges de travail qui verrouillent lourdement entre clients, ou pour des millions de fichiers minuscules réécrits sans arrêt. Ceux-là relèvent du stockage bloc. Quand une bibliothèque dépasse le service de fichiers, déplacez-la, comptez et vérifiez par checksum chaque fichier des deux côtés avant la bascule, et gardez l'original comme retour arrière jusqu'à ce que la nouvelle copie ait fait ses preuves à l'usage.

Une courte checklist pour vos propres partages

• exportfs -v ne liste que des hôtes nommés, avec root_squash et sync.
• Le firewall n'autorise NFS que depuis ces hôtes.
• Chaque montage client est hard, avec _netdev, nofail et une version de protocole figée.
• nfsstat -m sur chaque client affiche les options que vous vouliez.
• Les retransmissions dans mountstats sont proches de zéro et ne grandissent pas.
• Le filer a des liens redondants, et vous avez testé la perte de l'un d'eux.
• Des snapshots existent, et les sauvegardes sont tirées séparément.

Comment nous le faisons

Nos services de fichiers tournent sur ZFS au-dessus de volumes de notre SAN all-flash, se raccordent par des liens agrégés à une paire de switches sur le même segment privé que leurs clients, et sont mis à jour dans un nouvel environnement de démarrage pour que le précédent reste amorçable jusqu'à ce que la mise à jour ait fait ses preuves.

Si votre stockage partagé a été mis en place rapidement et que personne ne l'a regardé depuis, nous serons heureux de le passer en revue avec vous.

CTA

Parler à un ingénieur

Related

Articles liés : Services de fichiers NAS, NFS et SMB · Stockage SAN entreprise sur HPE 3PAR, all-flash · Disaster recovery et réplicas entre sites