Le serveur de métadonnées dans pNFS est établi lorsqu'un client initie un montage en utilisant NFSv4.1 ou une version ultérieure lorsque pNFS est activé sur le serveur NFS. Une fois cette opération effectuée, tout le trafic de métadonnées est envoyé via cette connexion et y reste pendant toute la durée du montage, même si l'interface est migrée vers un autre nœud.

La prise en charge de pNFS est déterminée lors de l'appel de montage, plus précisément dans les appels EXCHANGE_ID. Cela peut être observé dans une capture de paquets sous les opérations NFS, sous forme d'indicateur. Lorsque les drapeaux pNFS EXCHGID4_FLAG_USE_PNFS_DS et EXCHGID4_FLAG_USE_PNFS_MDS si la valeur est définie sur 1, l'interface est alors éligible pour les opérations sur les données et les métadonnées dans pNFS.

Les métadonnées dans NFS consistent généralement en attributs de fichiers et de dossiers, tels que les descripteurs de fichiers, les permissions, les dates d'accès et de modification, et les informations de propriété. Les métadonnées peuvent également inclure la création et la suppression d'appels, la liaison et la dissociation d'appels, ainsi que les renommages.

Dans pNFS, il existe également un sous-ensemble d'appels de métadonnées spécifiques à la fonctionnalité pNFS, qui sont traités plus en détail dans "RFC 5661". Ces appels servent à déterminer les appareils éligibles au pNFS, à associer les appareils aux ensembles de données et à fournir d'autres informations nécessaires. Le tableau suivant présente une liste de ces opérations de métadonnées spécifiques à pNFS.

Une fois le serveur de métadonnées établi et les opérations de données lancées, ONTAP commence à suivre les ID des périphériques éligibles aux opérations de lecture et d'écriture pNFS, ainsi que les mappages de périphériques, qui associent les volumes du cluster aux interfaces réseau locales. Ce processus se produit lorsqu'une opération de lecture ou d'écriture est effectuée dans le montage. Appels de métadonnées, tels que GETATTR. ne déclenchera pas ces mappages de périphériques. De ce fait, la gestion d'un ls La commande exécutée à l'intérieur du point de montage ne mettra pas à jour les mappages.

Les périphériques et les mappages peuvent être visualisés à l'aide de l'interface de ligne de commande ONTAP en mode privilégié, comme indiqué ci-dessous.

Lorsqu'un client tente de lire ou d'écrire dans un fichier situé sur un nœud distant de la connexion au serveur de métadonnées, pNFS négocie les chemins d'accès appropriés pour garantir la localité des données pour ces opérations et le client est redirigé vers le périphérique pNFS annoncé plutôt que de tenter de traverser le réseau du cluster pour accéder au fichier. Cela permet de réduire la charge du processeur et la latence du réseau.

En plus des métadonnées et des données, le pNFS comporte également un chemin de contrôle. Le chemin de contrôle est utilisé par le serveur NFS pour synchroniser les informations du système de fichiers. Dans un cluster ONTAP , le réseau du cluster backend se réplique périodiquement pour garantir que tous les périphériques pNFS et les mappages de périphériques sont synchronisés.

La section suivante décrit comment un périphérique pNFS est configuré dans ONTAP après qu'un client a effectué une requête de lecture ou d'écriture d'un fichier dans un volume.

Les volumes FlexGroup dans ONTAP présentent le stockage sous forme de constituants de FlexVol volume qui s'étendent sur plusieurs nœuds d'un cluster, ce qui permet à une charge de travail d'exploiter plusieurs ressources matérielles tout en conservant un seul point de montage. Étant donné que plusieurs nœuds dotés de plusieurs interfaces réseau interagissent avec la charge de travail, il est naturel de voir le trafic distant traverser le réseau du cluster backend dans ONTAP.

Lors de l'utilisation de pNFS, ONTAP conserve la trace des configurations de fichiers et de volumes du volume FlexGroup et les mappe aux interfaces de données locales du cluster. Par exemple, si un volume constituant contenant un fichier auquel on accède réside sur le nœud 1, ONTAP notifiera le client de rediriger le trafic de données vers l'interface de données sur le nœud 1.

pNFS permet également la présentation de chemins réseau parallèles vers des fichiers à partir d'un seul client, ce que NFSv4.1 sans pNFS ne permet pas. Par exemple, si un client souhaite accéder simultanément à quatre fichiers depuis le même point de montage en utilisant NFSv4.1 sans pNFS, le même chemin réseau serait utilisé pour tous les fichiers et le cluster ONTAP enverrait plutôt des requêtes distantes à ces fichiers. Le chemin de montage peut devenir un goulot d'étranglement pour les opérations, car elles suivent toutes un seul chemin et arrivent à un seul nœud, et il prend également en charge les opérations de métadonnées ainsi que les opérations de données.

Lorsque pNFS est utilisé pour accéder simultanément aux quatre mêmes fichiers depuis un seul client, le client et le serveur négocient des chemins locaux vers chaque nœud contenant les fichiers et utilisent plusieurs connexions TCP pour les opérations de données, tandis que le chemin de montage sert d'emplacement pour toutes les opérations de métadonnées. Cela permet de réduire la latence en utilisant des chemins d'accès locaux aux fichiers, mais peut également améliorer le débit grâce à l'utilisation de plusieurs interfaces réseau, à condition que les clients puissent envoyer suffisamment de données pour saturer le réseau.

Ce qui suit montre les résultats d'un test simple exécuté sur un seul client RHEL 9.5 où quatre fichiers de 10 Go (tous résidant sur différents volumes constitutifs sur deux nœuds de cluster ONTAP ) sont lus en parallèle à l'aide de dd. Pour chaque fichier, le débit global et le temps d'exécution ont été améliorés grâce à l'utilisation de pNFS. Lors de l'utilisation de NFSv4.1 sans pNFS, la différence de performances entre les fichiers locaux au point de montage et les fichiers distants était plus importante qu'avec pNFS.