Il server dei metadati in pNFS viene stabilito quando un client avvia un montaggio utilizzando NFSv4.1 o versione successiva quando pNFS è abilitato sul server NFS. Una volta eseguita questa operazione, tutto il traffico di metadati viene inviato tramite questa connessione e rimane su questa connessione per tutta la durata del montaggio, anche se l'interfaccia viene migrata su un altro nodo.

Il supporto pNFS viene determinato durante la chiamata di montaggio, in particolare nelle chiamate EXCHANGE_ID. Ciò può essere osservato in un'acquisizione di pacchetti sotto le operazioni NFS come flag. Quando i flag pNFS EXCHGID4_FLAG_USE_PNFS_DS E EXCHGID4_FLAG_USE_PNFS_MDS sono impostati su 1, l'interfaccia è idonea sia per le operazioni sui dati che sui metadati in pNFS.

I metadati in NFS sono generalmente costituiti da attributi di file e cartelle, come handle di file, autorizzazioni, orari di accesso e modifica e informazioni sulla proprietà. I metadati possono includere anche la creazione e l'eliminazione di chiamate, il collegamento e la disconnessione di chiamate e le rinomine.

In pNFS, esiste anche un sottoinsieme di chiamate di metadati specifiche per la funzionalità pNFS e sono trattate in modo più dettagliato in "RFC 5661". Queste chiamate vengono utilizzate per aiutare a determinare i dispositivi idonei per pNFS, le mappature dei dispositivi sui set di dati e altre informazioni richieste. La tabella seguente mostra un elenco di queste operazioni sui metadati specifiche di pNFS.

Dopo che il server dei metadati è stato stabilito e le operazioni sui dati hanno inizio, ONTAP inizia a tracciare gli ID dei dispositivi idonei per le operazioni di lettura e scrittura pNFS, nonché le mappature dei dispositivi, che associano i volumi nel cluster alle interfacce di rete locali. Questo processo si verifica quando viene eseguita un'operazione di lettura o scrittura nel mount. Chiamate di metadati, come GETATTR. non attiverà queste mappature dei dispositivi. In quanto tale, l'esecuzione di un ls il comando all'interno del punto di montaggio non aggiornerà le mappature.

I dispositivi e le mappature possono essere visualizzati utilizzando ONTAP CLI con privilegi avanzati, come mostrato di seguito.

Quando un client tenta di leggere o scrivere su un file situato su un nodo remoto rispetto alla connessione al server dei metadati, pNFS negozierà i percorsi di accesso appropriati per garantire la località dei dati per tali operazioni e il client verrà reindirizzato al dispositivo pNFS pubblicizzato anziché tentare di attraversare la rete del cluster per accedere al file. Ciò aiuta a ridurre il sovraccarico della CPU e la latenza di rete.

Oltre alle porzioni di metadati e dati di pNFS, esiste anche un percorso di controllo pNFS. Il percorso di controllo viene utilizzato dal server NFS per sincronizzare le informazioni del file system. In un cluster ONTAP , la rete del cluster backend si replica periodicamente per garantire che tutti i dispositivi pNFS e le mappature dei dispositivi siano sincronizzati.

Di seguito viene descritto come un dispositivo pNFS si popola in ONTAP dopo che un client effettua una richiesta di lettura o scrittura di un file in un volume.

I volumi FlexGroup in ONTAP presentano lo storage come componenti FlexVol volume che si estendono su più nodi in un cluster, consentendo a un carico di lavoro di sfruttare più risorse hardware mantenendo un singolo punto di montaggio. Poiché più nodi con più interfacce di rete interagiscono con il carico di lavoro, è naturale vedere il traffico remoto attraversare la rete del cluster backend in ONTAP.

Quando si utilizza pNFS, ONTAP tiene traccia dei layout dei file e dei volumi del volume FlexGroup e li mappa alle interfacce dati locali nel cluster. Ad esempio, se un volume costituente contenente un file a cui si sta accedendo risiede sul nodo 1, ONTAP notificherà al client di reindirizzare il traffico dati all'interfaccia dati sul nodo 1.

pNFS consente inoltre la presentazione di percorsi di rete paralleli ai file da un singolo client, cosa che NFSv4.1 senza pNFS non fornisce. Ad esempio, se un client desidera accedere a quattro file contemporaneamente dallo stesso mount utilizzando NFSv4.1 senza pNFS, verrà utilizzato lo stesso percorso di rete per tutti i file e il cluster ONTAP invierà invece richieste remote a tali file. Il percorso di montaggio può diventare un collo di bottiglia per le operazioni, poiché tutte seguono un unico percorso e arrivano a un unico nodo, oltre a gestire operazioni sui metadati insieme alle operazioni sui dati.

Quando pNFS viene utilizzato per accedere simultaneamente agli stessi quattro file da un singolo client, il client e il server negoziano i percorsi locali per ciascun nodo con i file e utilizzano più connessioni TCP per le operazioni sui dati, mentre il percorso di montaggio funge da posizione per tutte le operazioni sui metadati. Ciò offre vantaggi in termini di latenza grazie all'utilizzo di percorsi locali ai file, ma può anche aggiungere vantaggi in termini di produttività grazie all'utilizzo di più interfacce di rete, a condizione che i client possano inviare dati sufficienti a saturare la rete.

Di seguito sono riportati i risultati di un semplice test eseguito su un singolo client RHEL 9.5 in cui quattro file da 10 GB (tutti residenti su volumi costituenti diversi su due nodi del cluster ONTAP ) vengono letti in parallelo utilizzando dd. Per ogni file, la produttività complessiva e il tempo di completamento sono stati migliorati utilizzando pNFS. Utilizzando NFSv4.1 senza pNFS, il delta delle prestazioni tra i file locali al punto di montaggio e quelli remoti era maggiore rispetto a quello con pNFS.