NetApp Tech OnTap NetApp Logo
NetApp Tech OnTap
     
Collaborazione fra NetApp e Red Hat su pNFS
Pranoop Erasani
Technical Director, NFS
Justin Parisi
Technical Marketing Engineer

L'accesso ai dati condivisi è un fattore critico per le performance di numerose applicazioni scientifiche, ingegneristiche, aziendali e finanziarie. NFS, lo standard più utilizzato per l'accesso ai dati condivisi, può diventare un collo di bottiglia per i cluster di calcolo su larga scala, capace di subissare i file server che agiscono da singolo punto di accesso per tutti i file di un file system condiviso.

 

La maggior parte delle soluzioni per fornire performance elevate e accesso ai dati condivisi è di tipo proprietario (o quasi) e non è riuscita a ottenere il supporto per sistemi eterogenei e la vasta diffusione di protocolli standard come NFS.

 

Lo standard parallel NFS (pNFS), una sottofunzione della specifica del protocollo NFS versione 4.1 (RFC 5661), risolve il problema dei colli di bottiglia dei singoli server e ha le carte in regola per diventare una soluzione standardizzata per l'accesso ai dati in parallelo. In questo articolo illustreremo il funzionamento di pNFS, analizzeremo il lavoro congiunto svolto da NetApp e Red Hat nell'evoluzione del protocollo e descriveremo l'implementazione di pNFS in Clustered Data ONTAP® di NetApp®.

Che cos'è pNFS?

Il protocollo pNFS offre ai client un accesso diretto ai file in striping su due o più server dati. I client avranno un I/O molto più veloce con l'accesso in parallelo a diversi server dati. Il protocollo pNFS offre performance ottimali scalando in base al client e ai file, senza sacrificare la retrocompatibilità con il protocollo NFS standard: i client senza estensione pNFS potranno ugualmente accedere ai dati.

 

L'architettura pNFS e i principali protocolli

 

L'architettura pNFS è costituita da tre componenti principali:

 

  • Il server dei metadati che gestisce tutto il traffico non correlato ai dati. Si occupa della conservazione dei metadati che descrivono l'ubicazione e la modalità di memorizzazione di ciascun file.
  • I server dati che archiviano i dati relativi ai file e rispondono direttamente alle richieste di LETTURA e SCRITTURA dei client. È possibile suddividere in striping i dati dei file in diversi server.
  • Uno o più client accedono direttamente ai server dati in base alle informazioni contenute nei metadati ricevuti dal server dei metadati.

 

Vengono utilizzati tre tipi di protocolli fra client, server dei metadati e server dati:

 

  • Viene utilizzato un protocollo di controllo per sincronizzare i server dei metadati e dei dati. Questo aspetto non viene definito dalla specifica di pNFS e può variare in base al vendor.
  • Il protocollo pNFS viene utilizzato fra client e server dei metadati. Si tratta in pratica di NFSv4 con alcune estensioni specifiche di pNFS. Questo protocollo consente di recuperare e manipolare i layout contenenti i metadati che descrivono l'ubicazione e il protocollo di accesso allo storage necessario per l'accesso ai file memorizzati in diversi server dati.
  • Un insieme di protocolli di accesso allo storage viene utilizzato dai client per consultare direttamente i server dati. Lo standard pNFS definisce attualmente tre categorie di protocolli storage: protocolli basati su file (RFC5661), protocolli basati su blocchi (RFC5663) e protocolli basati su oggetti (RFC5664). Clustered Data ONTAP supporta attualmente il protocollo di storage basato su file e utilizza NFSv4.1 per accedere ai server dati.

 

 

Elementi di pNFS. I client richiedono il layout dai server dei metadati (protocollo pNFS), quindi accedono direttamente ai server dati (protocollo di accesso allo storage).

Figura 1) Elementi di pNFS. I client richiedono il layout dai server dei metadati (protocollo pNFS), quindi accedono direttamente ai server dati (protocollo di accesso allo storage).

 

 

Per accedere a un file, il client contatta il server dei metadati per aprire il file e ne richiede il layout. Quando il client riceve il layout del file, utilizza tali informazioni per eseguire direttamente operazioni di I/O da e verso i server dati in parallelo, utilizzando il corretto protocollo di accesso allo storage senza coinvolgere ulteriormente il server dei metadati. I client pNFS memorizzano nella cache il layout fino a quando non vengono completate le operazioni di I/O in parallelo. I server pNFS possono revocare il layout del file nel caso in cui il server non possa garantire un accesso parallelo ai server. Inoltre, pNFS non modifica l'attuale procedura di accesso ai metadati utilizzata dal server NFS.

Collaborazione fra NetApp e Red Hat per pNFS

Per utilizzare una soluzione pNFS è necessario che i componenti client e server funzionino correttamente. NetApp e Red Hat hanno collaborato con l'intera community per creare il primo prodotto pNFS end-to-end basato su standard.

 

NetApp ha risolto i problemi di scalabilità unendo clustering storage e pNFS. Lo storage NetApp FAS e V-Series con Clustered Data ONTAP 8.1 o versioni successive può scalare da pochi terabyte di dati fino a oltre 69 petabyte, gestibili come singola entità storage in modo da semplificare la gestione di un ambiente pNFS ed eliminare i downtime pianificati e non.

 

Grazie al primo client pNFS sul mercato con supporto completo, incluso in Red Hat Enterprise Linux®, è possibile pianificare e progettare soluzioni di file system scalabili di nuova generazione basate su pNFS. I carichi di lavoro delle applicazioni possono sfruttare al meglio pNFS senza apportare alcuna modifica, garantendo una transizione senza interruzioni delle applicazioni esistenti.

pNFS e Clustered Data ONTAP

NetApp ha iniziato a implementare pNFS a partire da Clustered Data ONTAP 8.1 (non esistono implementazioni per 7-Mode o Data ONTAP 7G). La versione di pNFS implementata in Clustered Data ONTAP offre numerosi vantaggi:

 

  • Infrastruttura semplificata. L'infrastruttura complessiva di pNFS è più semplice di quella degli altri file system in parallelo come Lustre e GPFS, che richiedono diversi server dedicati oltre allo storage.
  • Gestibilità. Di solito, pNFS prevede diversi file server che devono essere gestiti separatamente. Clustered Data ONTAP consente di gestire tutti i componenti di pNFS del lato server come un unico sistema.
  • Operazioni senza interruzioni. Le installazioni di pNFS in un cluster NetApp possono avvalersi delle operazioni senza interruzioni per attività come la manutenzione e il bilanciamento del carico (ad esempio failover dello storage, migrazioni LIF e trasferimenti di volume senza interruzioni) come qualsiasi altro carico di lavoro.
  • Tutti i nodi possono fungere da server di metadati. In un'implementazione di Clustered Data ONTAP, tutti i nodi del cluster di storage possono operare come server di metadati o dati. In questo modo è possibile eliminare i potenziali colli di bottiglia presenti con un singolo server di metadati e facilitare la distribuzione delle operazioni dei metadati in tutto il cluster.

 

Confronto fra pNFS di Data ONTAP e NFS. Tutti i nodi possono fungere da server di metadati o dati.

Figura 2) Confronto fra pNFS di Data ONTAP e NFS. Tutti i nodi possono fungere da server di metadati o dati.

 

 

Per comprendere il funzionamento di pNFS con Clustered Data ONTAP, si supponga di avere un client su cui è stato montato un file system pNFS da un nodo di un cluster. Per accedere a un file, il client invia una richiesta di metadati al nodo. L'implementazione di pNFS raccoglie e restituisce informazioni come la posizione, il layout del file e i dati di rete necessari per raggiungere tale posizione. Il client utilizza le informazioni per accedere ai dati direttamente dal nodo o dai nodi in cui risiedono. Fornendo un percorso diretto al volume, pNFS aiuta le applicazioni a migliorare il throughput e a ridurre la latenza.

 

pNFS si integra in modo trasparente con le operazioni senza interruzioni di Clustered Data ONTAP come migrazione LIF, failover dello storage e spostamento dei volumi. Quando viene eseguita una di queste operazioni, il client pNFS e il server negoziano automaticamente il nuovo percorso di I/O diretto al server, contribuendo a mantenere integro il throughput senza alcuna interruzione per le applicazioni. Ciò rappresenta un notevole vantaggio per gli amministratori dello storage, poiché non occorre fornire esplicitamente percorsi di rete ai file system durante le operazioni di manutenzione del cluster. Pertanto, pNFS con Clustered Data ONTAP aiuta non solo a incrementare le performance, ma anche a semplificare i flussi di lavoro di amministrazione durante le operazioni di manutenzione. Si tratta di una funzionalità indispensabile per il provisioning e l'implementazione di cluster di grandi dimensioni.

 

Senza pNFS, i percorsi dei metadati e quelli dei dati diventano di tipo più o meno statico. Grazie a pNFS, il servizio dei metadati viene distribuito su diversi nodi, mentre i percorsi dei dati vengono instradati all'interfaccia di rete del nodo che contiene il file. Durante lo spostamento dei dati, i relativi percorsi possono adattarsi automaticamente per garantire performance ottimali.

Figura 3) Senza pNFS, i percorsi dei metadati e quelli dei dati diventano di tipo più o meno statico. Grazie a pNFS, il servizio dei metadati viene distribuito su diversi nodi, mentre i percorsi dei dati vengono instradati all'interfaccia di rete del nodo che contiene il file. Durante lo spostamento dei dati, i relativi percorsi possono adattarsi automaticamente per garantire performance ottimali.

 

 

Best Practice

 

È importante conoscere alcune best practice per ottenere performance ottimali con pNFS:

 

  • Consulta la matrice di interoperabilità NetApp per ottenere le informazioni più aggiornate sulla compatibilità con i client pNFS e NFSv4.1 (è richiesto l'accesso al sito di supporto NetApp).
  • Occorre configurare ciascun nodo del cluster con supporto pNFS con almeno un'interfaccia logica (LIF) per far sì che i client pNFS possano accedere direttamente ai volumi memorizzati in tale nodo.
  • Per i carichi di lavoro intensivi in termini di metadati, i client pNFS devono essere configurati in modo che il file system venga montato su tutti i nodi del cluster, che possono quindi fungere da server dei metadati. È possibile ottenere questo risultato utilizzando un DNS round-robin esterno oppure attraverso il bilanciamento del carico del DNS integrato in Clustered Data ONTAP.

 

Per ulteriori informazioni sull'implementazione di pNFS nello storage NetApp, consultare il documento TR-4063.

Client pNFS di Red Hat

Il client pNFS di Red Hat è stato commercializzato a partire dalla versione 6.2 del kernel di Red Hat Enterprise Linux (RHEL), nel 2011. RHEL 6.2 e RHEL 6.3 sono stati etichettati come versioni "Tech Preview" di pNFS.

 

RHEL 6.4, pubblicato nel febbraio del 2013, conteneva la prima versione a disponibilità generale di pNFS. Per informazioni complete sull'utilizzo dei client Red Hat con lo storage NetApp dotato di NFS o pNFS, consultare il documento TR-3183 (si tratta di un report tecnico attualmente in revisione e che potrebbe non essere disponibile al momento della pubblicazione di questo articolo. Se necessario, verificare in un secondo momento).

Casi di utilizzo di pNFS

Oltre alla normale idoneità per applicazioni scientifiche e ingegneristiche basate su calcoli in parallelo, le funzionalità esclusive di pNFS sono un'ottima scelta per numerosi casi di utilizzo enterprise.

 

Applicazioni business-critical

 

Per definizione, le applicazioni business-critical richiedono i massimi livelli di servizio. La larghezza di banda e la capacità storage devono poter crescere in modo trasparente insieme ai requisiti dei server. Quando viene eseguita la migrazione trasparente dei volumi storage NetApp su controller più potenti del cluster NetApp, il client pNFS Red Hat Enterprise Linux segue lo spostamento dei dati adeguandosi automaticamente per poi ottimizzare di nuovo i percorsi dei dati. Il risultato è l'assenza quasi totale di downtime, senza dover riconfigurare i server o le applicazioni.

 

Soluzioni storage multi-tenant

 

L'accesso ai dati in parallelo consente ai carichi di lavoro eterogenei e multi-tenant di sfruttare direttamente le caratteristiche di pNFS. I dati risiedono nel cluster NetApp e non sono vincolati ad alcun controller NetApp specifico. Grazie a pNFS, i server Red Hat Enterprise Linux possono individuare il percorso dati ottimale e adattarsi automaticamente al fine di ottenere un throughput eccellente.

 

Carichi di lavoro e client misti

 

NFSv4.1 e pNFS consentono di montare il file system da qualsiasi punto del namespace del cluster. È possibile montare le applicazioni clustered via pNFS, lasciando quelle di generazione precedente montate via NFSv3. I file system esportati dallo storage possono disporre di client montati attraverso diverse versioni di NFS, in modo da farli coesistere senza dover apportare modifiche significative alle applicazioni che accedono ai dati. Questo livello di flessibilità riduce l'overhead causato da una frequente gestione dei cambiamenti.

 

Ambienti di virtualizzazione

 

Gli hypervisor e le macchine virtuali che utilizzano il client pNFS Red Hat Enterprise Linux possono gestire più connessioni per sessione e distribuire il carico su diverse interfacce di rete. Si pensi a una sorta di multipath per NFS senza driver o configurazione multipath separati.

Conclusioni

NetApp è fra i principali promotori di NFSv4.1 e pNFS, condividendo gli sforzi del gruppo di lavoro. Inoltre, NetApp ha creato e modificato una parte significativa della specifica NFSv4.1. Si tratta di un lavoro in linea con il nostro impegno ad affrontare eventuali problemi legati allo storage ricorrendo agli standard di settore.

 

Grazie alla recente disponibilità generale del client pNFS presente nella versione 6.4 di RHEL, è possibile implementare pNFS a scopo di test e/o produzione usando client Red Hat e Clustered Data ONTAP di NetApp.

Qual è la tua opinione?

Pranoop è lead NFS architect della divisione Protocols Technology Engineering di NetApp, in cui si occupa dello sviluppo del protocollo NFS per Data ONTAP. Ha svolto un ruolo di primo piano nella progettazione di pNFS per Clustered Data ONTAP. Pranoop è un sostenitore dell'utilizzo di NFSv4.1/pNFS nei sistemi clustered. Ha partecipato a numerosi dibattiti sullo standard pNFS IETF ed è spesso relatore in eventi sull'interoperabilità di NFS. Lavora come key technical advisor per la gestione dei prodotti e il marketing tecnico delle implementazioni dei clienti in corso e delle soluzioni storage software.

Justin lavora in RTP e negli ultimi 5 anni ha svolto la sua attività in NetApp Global Support come technical support engineer ed escalation engineer per la risoluzione dei problemi critici. In qualità di esperto di Clustered Data ONTAP ha sviluppato il materiale formativo sulla risoluzione dei problemi e ha scritto numerosi articoli della knowledge base. I suoi interessi riguardano numerosi settori come CIFS, NFS, SNMP, OnCommand® System Manager, Unified Manager, SnapDrive® e SnapManager®, nonché Microsoft® Exchange, SQL Server®, Active Directory®, LDAP e molto altro, rendendolo di fatto un asso nella manica della cultura NetApp.

Explore
Explore
Ulteriori informazioni su pNFS

Desideri ottenere ulteriori informazioni su pNFS e il modo in cui implementarlo per accelerare il tuo ambiente IT? Consulta i seguenti collegamenti:

Explore
 
TRUSTe
Contatti   |   Come acquistare   |   Commenti   |   Opportunità di lavoro  |   Sottoscrizioni   |    Direttiva sulla privacy   |    © 2013 NetApp