Chapitre 9. Network File System (NFS)
Un système de fichiers NFS (« Network File System ») permet aux hôtes distants de monter les systèmes de fichiers sur un réseau et d'interagir avec ces systèmes de fichiers tant que ceux-ci sont montés localement. Ceci permet aux administrateurs système de consolider leurs ressources sur des serveurs centralisés sur le réseau.
Ce chapitre traite des concepts NFS fondamentaux et fournit également des informations supplémentaires
9.1. Fonctionnement NFS
Actuellement, il y a trois versions de NFS. NFS version 2 (NFSv2) est une version plus ancienne avec une prise en charge plus généralisée. NFS version 3 (NFSv3) prend en charge les écritures asynchrones sécurisées et offre une gestion des erreurs plus robuste que NFSv2. NFSv3 prend aussi en charge les fichiers et décalages d'une taille de 64 bits, permettant ainsi aux clients d'accéder à plus de 2 Go de données de fichiers.
NFS version 4 (NFSv4) fonctionne à travers les pares-feu et sur internet, ne nécessite plus le service
rpcbind, prend en charge les ACL, et utilise des opérations « Stateful » (avec état). Red Hat Enterprise Linux 6 prend en charge les clients NFSv2, NFSv3, et NFSv4. Lors du montage d'un système de fichiers via NFS, Red Hat Enterprise Linux utilise NFSv4 par défaut si le serveur le prend en charge.
Toutes les versions de NFS peuvent utiliser TCP (Transmission Control Protocol) exécuté sur un réseau IP, avec NFSv4 qui le requiert. NFSv2 et NFSv3 peuvent utiliser le protocole UDP (User Datagram Protocol) exécuté sur un réseau IP afin de fournir une connexion réseau sans état (« Stateless ») entre le client et le serveur.
Lors de l'utilisation de NFSv2 ou NFSv3 avec UDP, la connexion UDP sans état (sous des conditions normales) possède un alourdissement du protocole moindre que TCP. Ceci se traduit par de meilleures performances sur des réseaux propres et non encombrés. Cependant, comme UDP est sans état, si le serveur tombe en panne de manière inattendue, les clients UDP continueront de saturer le réseau avec des requêtes pour le serveur. En outre, lorsqu'une trame est perdue avec UDP, la requête RPC entière doit être retransmise. Avec TCP, seule la trame perdue doit être envoyée à nouveau. Pour ces raisons, TCP est le protocole préféré lors d'une connexion à un serveur NFS.
Les protocoles de montage et de verrouillage ont été incorporés au protocole NFSv4. Le serveur écoute aussi le port TCP 2049. Ainsi, NFSv4 n'a pas besoin d'interagir avec les démons
rpcbind [3], lockd, et rpc.statd. Le démon rpc.mountd est requis sur le serveur NFS pour créer les exports.
Note
TCP est le protocole de transport par défaut de NFS version 2 et 3 sous Red Hat Enterprise Linux. UDP peut être utilisé à des fins de compatibilité selon les besoins, mais n'est pas recommandé pour une utilisation globale. NFSv4 requiert TCP.
Tous les démons RPC/NFS possèdent une option de ligne de commande
'-p' pouvant définir le port, ce qui rend la configuration du pare-feu plus facile.
Une fois que les emballages TCP auront fourni l'accès au client, le serveur NFS se réfèrera au fichier de configuration
/etc/exports pour déterminer si le client a le droit d'accéder à un système de fichiers exporté. Une fois cette vérification effectuée, toutes les opérations des fichiers et répertoires seront disponibles pour l'utilisateur.
Important
Pour que NFS puisse fonctionner avec une installation par défaut de Red Hat Enterprise Linuc avec un pare-feu activé, veuillez configurer IPTables avec le port TCP par défaut 2049. NFS ne fonctionnera pas correctement sans une configuration d'IPTables correcte.
Le script d'initialisation NFS et le processus
rpc.nfsd permettent désormais la liaison vers tout port spécifié pendant le démarrage système. Cependant, ceci est prône aux erreurs si le port est indisponible, ou s'il est en conflit avec un autre démon.
9.1.1. Services requis
Red Hat Enterprise Linux utilise une combinaison des processus de démons et de support technique au niveau du noyau pour fournir le partage de fichiers NFS. Toutes les versions NFS reposent sur les RPC (Remote Procedure Calls) entre clients et serveurs. Les services RPC sous Red Hat Enterprise Linux 6 sont contrôlés par le service
rpcbind. Pour partager ou monter les systèmes de fichiers NFS, les services suivants travaillent ensemble selon la version NFS implémentée :
Note
Le service
portmap a été utilisé pour mapper les numéros de programmes RPC à des combinaisons de numéros de port d'adresses IP dans des versions plus récentes de Red Hat Enterprise Linux. Ce service est désormais remplacé par rpcbind dans Red Hat Enterprise Linux 6 afin de permettre la prise en charge d'IPv6. Pour obtenir des informations supplémentaires sur ce changement, veuillez consulter les liens suivants :
- TI-RPC / prise en charge rpcbind : http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php
- Prise en charge IPv6 sur NFS : http://nfsv4.bullopensource.org/doc/nfs_ipv6.php
- nfs
service nfs startlance le serveur NFS et les processus RPC appropriés pour servir les requêtes des systèmes de fichiers NFS partagés.- nfslock
service nfslock startactive un service obligatoire qui lance les processus RPC appropriés, ce qui permet aux clients NFS de verrouiller des fichiers sur le serveur.- rpcbind
rpcbindaccepte les réservations de ports des services RPC locaux. Ces ports sont ensuite mis à disponibilité (ou publicisés) afin que les services RPC à distance correspondants puissent y accéder.rpcbindrépond à des requêtes de service RPC et paramètre des connexions vers le service RPC requis. Ceci n'est pas utilisé avec NFSv4.- rpc.nfsd
rpc.nfsdpermet de définir les versions et protocoles NFS explicites publicisés par le serveur. Celui-ci fonctionne avec le noyau Linux afin de répondre aux demandes des clients NFS, comme pour fournir des threads chaque fois qu'un client NFS se connecte. Ce processus correspond au servicenfs.Note
À partir de Red Hat Enterprise Linux 6.3, seul le serveur NFSv4 utiliserpc.idmapd. Le client NFSv4 utilisenfsidmapde l'imapper basé-keyring .nfsidmapest un programme autonome appelé par le noyau à la demande pour effectuer les mappages d'ID ; ce n'est pas un démon. S'il y a un problème avecnfsidmap, le client utilise alorsrpc.idmapd. Vous trouverez plus d'informations surnfsidmapdans la page man de nfsidmap.
Les processus RPC suivants facilitent les services NFS :
- rpc.mountd
- Ce processus est utilisé par un serveur NFS pour traiter les requêtes
MOUNTdes clients NFSv2 et NFSv3. Il vérifie que le partage NFS requis est actuellement exporté par le serveur NFS, et que le client est autorisé à y accéder. Si la requête de montage est autorisée, le serveur rpc.mountd répond avec le statutSuccess(« Opération réussie ») et retourne l'identificateur de fichier «File-Handle» de ce partage NFS au client NFS. - lockd
lockdest un thread du noyau qui peut être exécuté sur les clients et les serveurs. Il implémente le protocole NLM (« Network Lock Manager »), qui permet aux clients NFSv2 et NFSv3 de verrouiller des fichiers sur le serveur. Il est lancé automatiquement à chaque fois que le serveur NFS est exécuté et à chaque fois qu'un système de fichiers NFS est monté.- rpc.statd
- Ce processus implémente le protocole RPC NSM (« Network Status Monitor »), qui notifie les clients NFS lorsqu'un serveur NFS est redémarré sans avoir tout d'abord été éteint correctement.
rpc.statdest automatiquement démarré par le servicenfslock, et ne requiert pas de configuration utilisateur. Ce protocole n'est pas utilisé avec NFSv4. - rpc.rquotad
- Ce processus fournit des informations sur le quota d'utilisateur des utilisateurs distants.
rpc.rquotadest automatiquement démarré par le servicenfset ne requiert pas de configuration utilisateur. - rpc.idmapd
rpc.idmapdfournit des appels ascendants client et serveur NFSv4, qui mappent simultanément les noms NFSv4 (chaînes sous le formatutilisateur@domaine) et les UID et GID locaux. Pour queidmapdpuisse fonctionner avec NFSv4, le fichier/etc/idmapd.confdoit être configuré. Au minimum, le paramètre « Domaine », qui définit le domaine de mappage NFSv4, doit être spécifié. Si le domaine de mappage NFSv4 est le même que le nom de domaine DNS, oubliez ce paramètre. Le client et le serveur doivent se mettre d'accord sur le domaine de mappage NFSv4 pour que le mappage d'ID fonctionne correctement. Veuillez consulter l'article de la base de connaissances https://access.redhat.com/site/solutions/130783 lorsque vous utilisez un domaine local.
[3]
Le service
rpcbind remplace portmap, qui était utilisé dans des versions précédentes de Red Hat Enterprise Linux pour mapper les numéros de programme RPC sur les combinaisons de numéros de port d'adresses IP. Pour obtenir des informations supplémentaires, veuillez consulter la Section 9.1.1, « Services requis ».
