OneFS : Pratiques d’excellence pour les paramètres du client NFS

Versions de protocole prises en charge

À ce stade, PowerScale prend en charge les versions 3 et 4 de NFS. NFS version 2 n’est pas pris en charge.

NFSv3

La version 3 est la plus utilisée du protocole NFS à ce jour. Elle est généralement considérée comme étant celle dont l’adoption client et serveur est la plus large. Voici les composants clés de cette version :

• Sans état - Un client n’a pas techniquement besoin d’établir une nouvelle session s’il dispose des informations appropriées pour demander des fichiers, etc. Cela permet un basculement simple entre les nœuds OneFS via des pools d’adresses IP dynamiques.
• Les informations utilisateur et de groupe sont présentées sous forme numérique : le client et le serveur communiquent les informations utilisateur par des ID numériques, ce qui permet au même utilisateur d’apparaître sous différents noms entre le client et le serveur.
• Le verrouillage des fichiers est hors bande : la version 3 de NFS utilise un protocole de support appelé NLM pour effectuer des verrouillages. Cela nécessite que le client réponde aux messages RPC du serveur pour confirmer que les verrous ont été accordés, etc.
• Peut fonctionner sur TCP ou UDP : cette version du protocole peut fonctionner sur UDP au lieu de TCP, laissant la gestion des pertes et des retransmissions au logiciel plutôt qu’au système d’exploitation. Nous vous recommandons toujours d’utiliser TCP.

NFSv4

La version 4 est la dernière révision majeure du protocole NFS, et elle est progressivement adoptée. À ce stade, NFSv4 est généralement moins performant que la version 3 par rapport au même workflow en raison de la plus grande quantité de travail de mappage des identités et de suivi des sessions obligatoires pour répondre. Voici quelques-unes des différences clés entre la version 3 et la version 4

• Stateful - NFSv4 utilise des sessions afin de gérer la communication, à ce titre le client et le serveur doivent suivre l’état de la session pour continuer à communiquer.
  • Avant OneFS 8.X, cela signifiait que les clients NFSv4 avaient besoin de pools d’adresses IP statiques sur PowerScale, faute de quoi ils pouvaient rencontrer des problèmes.
• Les informations sur les utilisateurs et les groupes sont présentées sous forme de chaînes : le client et le serveur doivent résoudre les noms des informations numériques stockées. Le serveur doit rechercher les noms à présenter, tandis que le client doit les remapper en chiffres de son côté.
• Le verrouillage des fichiers est intrabande : la version 4 n’utilise plus de protocole séparé pour le verrouillage des fichiers. Au lieu de cela, elle en fait un type d’appel qui est généralement composé avec OPEN, CREATE ou WRITE.
• Appels composés : la version 4 peut regrouper une série d’appels dans un seul paquet, ce qui permet au serveur de traiter tous ces appels et de répondre à la fin. Cela permet de réduire le nombre d’appels impliqués dans les opérations courantes.
• Prend uniquement en charge le TCP : la version 4 de NFS a laissé la perte et la retransmission au système d’exploitation sous-jacent.

NFSv4.1 et version supérieures

NFSv4.1 et v4.2 sont disponibles à partir de OneFS version 9.3

Voici les informations officielles sur la version 9.3:

https://dl.dell.com/content/docu105998_powerscale-onefs-9-3-0-0-release-notes.pdf?language=en_us
 

Options de montage

Même si nous n’avons pas d’exigences strictes concernant les options de montage, nous formulons tout de même quelques recommandations sur la manière dont les clients peuvent se connecter. Nous n’avons pas fourni de chaînes de montage spécifiques, car la syntaxe utilisée pour définir ces options varie en fonction du système d’exploitation. Vous devez conserver la documentation de vos responsables de maintenance de distribution pour en savoir plus sur la syntaxe de montage spécifique.

Définition des nouvelles tentatives et des délais d’expiration

Bien que PowerScale réponde généralement très vite aux communications des clients, lorsqu’un nœud est privé d’alimentation ou de connectivité réseau, il peut s’écouler quelques secondes avant que ses adresses IP ne soient transférées vers un nœud fonctionnel. Il est donc important de définir correctement les valeurs de délai d’expiration et de relance. PowerScale recommande généralement un délai d’expiration de 60 secondes pour tenir compte du pire scénario de basculement, paramétré pour réessayer deux fois avant de signaler un échec.

Montages conditionnels et inconditionnels

Les montages inconditionnels obligent le client à recommencer indéfiniment ses opérations en cas de délai d’expiration ou d’erreur. Cela permet de s’assurer que le client ne déconnecte pas le montage dans les cas où le cluster PowerScale déplace les adresses IP d’un nœud à l’autre. Un montage conditionnel entraînera une erreur et l’expiration du montage, ce qui nécessitera un nouveau montage pour restaurer l’accès après un changement d’adresse IP.

Autoriser l’interruption

Par défaut, la plupart des clients ne vous permettent pas d’interrompre une entrée/sortie ou une attente d’E/S, ce qui signifie que vous ne pouvez pas utiliser ctrl+c, entre autres, pour mettre fin au processus d’attente si le cluster cesse de répondre. Inclure l’option de montage interrupt permet à ces signaux de passer normalement à la place.

Comparaison locale avec le verrouillage à distance

Lors du montage d’une exportation NFS, vous pouvez spécifier si un like effectuera ses verrouillages localement ou en utilisant le coordinateur de verrouillage sur le cluster. La plupart des clients utilisent le verrouillage à distance par défaut, ce qui est généralement la meilleure option lorsque plusieurs clients accèdent au même répertoire. Toutefois, le verrouillage local peut présenter des avantages en termes de performances lorsqu’un client n’a pas besoin de partager l’accès au répertoire avec lequel il travaille. En outre, certains logiciels et bases de données vous demanderont d’utiliser le verrouillage local, car elles ont leur propre coordinateur.