NFS est un protocole de stockage par le réseau dont la création remonte à 1984. Il permet à une machine de servir des volumes de fichiers (appelés « shares » NFS) pour qu’une autre machine, cliente, puisse accéder en lecture et écriture à ces fichiers.
NFS supporte l’accès à une même share NFS par plusieurs machines en même temps, un système de réplication pour redonder un serveur NFS sur plusieurs machines, et même des algorithmes de chiffrement du transit basés sur Kerberos.
NFS a été mis en place sur notre infrastructure le 7 mars 2022, avec la migration vers l’infrastructure V2, qui fait émerger la distinction entre les serveurs « de calcul » et « de stockage » plutôt qu’un seul serveur sur lequel tous nos conteneurs sont hébergés.
Nous utilisons notre propre image Docker, inspirée de erichough/nfs-server et basée sur Debian.
Notre configuration inclut des règles AppArmor spécifiques. Cette intégration doit être mise en place car le protocole NFS interagit de manière rapprochée avec le kernel Linux pour fonctionner.
Le dæmon est configuré à travers les variables d’environnnement à l’aide du fichier entrypoint.sh fourni par le dépôt original.
Une share NFS est créée par volume Docker. Chaque IP qui nécessite l’accès à une share NFS est explicitement listée dans les exports NFS.
Ces commandes permettent de monter une share NFS sur une machine cliente en configurant un nouveau volume :
docker volume create --driver local --opt type=nfs4 --opt o=nfsvers=4.2,addr=IP_DE_LA_MACHINE_NFS,rw,hard,timeo=600,retrans=2,sync,fsc --opt device=:/nfs-share-test nfs-share-test
docker run --rm -it -v nfs-share-test:/nfs-share-test nicolaka/netshoot
$> touch /nfs-share-test/a
L’argument fsc ne peut être utilisé que si un cache local est configuré avec FS-Cache.
NFS consomme extrêmement peu de ressources : nous mesurons une consommation à 2 Mo de RAM en production. Cela dit, compte tenu de la nature du protocole, il est possible que des processus consomment des ressources à l’extérieur du conteneur, mais nous n’avons pas mesuré de consommation significative sur l’hôte.
Par défaut, NFS fonctionne sans aucune sécurité :
Un paramètre de NFS permet de résoudre ces trois problèmes de sécurité à l’aide de Kerberos. Cela dit, en production, nous avons opté pour la sécurisation du transit avec un VPN (WireGuard) à la place, ce qui ne résout pas tous les problèmes.
Lorsque le processus qui utilise la share sur le client NFS dispose de droits root, il pourrait écrire des fichiers en tant que root sur la share. Cela pose un problème, car les fichiers appartiendront également à root sur la machine de stockage, pouvant conduire à une élévation de privilèges sur la machine qui héberge le serveur NFS.
Pour mitiger ce problème, il existe les options root_squash et all_squash qui modifient la propriété du fichier sur la share de destination. Un client ne peut alors plus créer de fichiers en tant que root.
Cette limitation importante conduit à l’impossibilité d’utiliser NFS avec des conteneurs qui fonctionnent avec les privilèges root, et limite ainsi fortement les cas d’utilisation possibles du protocole.
En cas de panne du serveur NFS, les services qui l’utilisent se retrouveront immédiatement affectés, même avec un système de cache.
Nous utilisons une version modifiée du fichier entrypoint.sh pour permettre une récupération rapide du lien NFS (par défaut : 90 secondes).
L’utilisation du stockage par le réseau implique de fait un réseau rapide. Lors de pics de trafic, il peut arriver que l’un de nos serveurs atteigne sa limite de bande passante autorisée, impactant ainsi le transit vers le serveur de stockage. La latence est par ailleurs extrêmement impactante sur la qualité de service : elle doit rester constamment inférieure à 5 ms entre le serveur de stockage et le serveur de calcul.
L’utilisation du serveur de stockage pour d’autres besoins que NFS (pour la journalisation, par exemple) peut considérablement réduire la bande passante disponible en cas de pic de trafic, ce pourquoi il pourrait être envisagé d’héberger la journalisation et le stockage NFS sur deux machines distinctes.
Ce service demande peu d’entretien et fonctionne généralement en autonomie, mis à part l’usage de l’espace disque dédié aux shares NFS qu’il convient de surveiller régulièrement.
Comme pour l’image syslog-ng, partir d’une image Debian implique de s’occuper des mises à jour soi-même en reconstruisant l’image sans le cache de Docker (manager build nfs-server --no-cache).
Voir cette section.