File system virtuale parallelo - Parallel Virtual File System

File system virtuale parallelo
Autori originali Clemson University , Argonne National Laboratory , Ohio Supercomputer Center
Sviluppatore / i Walt Ligon, Rob Ross, Phil Carns, Pete Wyckoff, Neil Miller, Rob Latham, Sam Lang, Brad Settlemyer
Versione iniziale 2003
Rilascio stabile
2.8.2 / 1 gennaio 2010 ; 11 anni fa  ( 2010-01-01 )
Scritto in C
Sistema operativo Kernel Linux
Licenza LGPL
Sito web web .archive .org / web / 20160701052501 / http: // www .pvfs .org /

Il Parallel Virtual File System ( PVFS ) è un file system parallelo open source . Un file system parallelo è un tipo di file system distribuito che distribuisce i dati dei file su più server e fornisce l'accesso simultaneo da parte di più attività di un'applicazione parallela. PVFS è stato progettato per essere utilizzato nel cluster computing su larga scala . PVFS si concentra sull'accesso ad alte prestazioni a set di dati di grandi dimensioni. Consiste in un processo server e una libreria client, entrambi scritti interamente in codice a livello utente. Un modulo del kernel Linux e un processo pvfs-client consentono al file system di essere montato e utilizzato con le utilità standard. La libreria client fornisce un accesso ad alte prestazioni tramite l' interfaccia di passaggio dei messaggi (MPI). Il PVFS è stato sviluppato congiuntamente tra il Parallel Architecture Research Laboratory della Clemson University e la Divisione di matematica e informatica presso l' Argonne National Laboratory e l' Ohio Supercomputer Center . Lo sviluppo di PVFS è stato finanziato dal Goddard Space Flight Center della NASA, dal programma di ricerca scientifica avanzata del DOE Office of Science , dai programmi NSF PACI e HECURA e da altre agenzie governative e private. PVFS è ora noto come OrangeFS nel suo nuovo ramo di sviluppo.

Storia

PVFS è stato sviluppato per la prima volta nel 1993 da Walt Ligon ed Eric Blumer come file system parallelo per Parallel Virtual Machine (PVM) come parte di una sovvenzione della NASA per studiare i modelli di I / O dei programmi paralleli. La versione 0 di PVFS era basata su Vesta, un file system parallelo sviluppato presso l'IBM TJ Watson Research Center . A partire dal 1994 Rob Ross ha riscritto PVFS per utilizzare TCP / IP e si è allontanato da molti dei punti di progettazione originali di Vesta. La versione 1 di PVFS era destinata a un cluster di workstation DEC Alpha collegate in rete utilizzando FDDI commutato . Come Vesta, PVFS ha eseguito lo striping dei dati su più server e ha consentito le richieste di I / O in base a una visualizzazione dei file che descriveva un modello di accesso strided. A differenza di Vesta, lo striping e la visualizzazione non dipendevano da una dimensione di record comune. La ricerca di Ross si è concentrata sulla pianificazione dell'I / O del disco quando più client accedevano allo stesso file. I risultati precedenti avevano mostrato che era preferibile la pianificazione secondo il miglior modello di accesso al disco possibile. Ross ha dimostrato che ciò dipendeva da una serie di fattori tra cui la velocità relativa della rete e i dettagli della visualizzazione dei file. In alcuni casi era preferibile una pianificazione basata sul traffico di rete, quindi una pianificazione adattabile dinamicamente forniva le migliori prestazioni complessive.

Alla fine del 1994 Ligon incontrò Thomas Sterling e John Dorband al Goddard Space Flight Center (GSFC) e discusse i loro piani per costruire il primo computer Beowulf . È stato concordato che PVFS sarebbe stato portato su Linux e sarebbe stato presentato sulla nuova macchina. Negli anni successivi Ligon e Ross hanno lavorato con il gruppo GSFC tra cui Donald Becker, Dan Ridge ed Eric Hendricks. Nel 1997, in una riunione del cluster a Pasadena, CA Sterling chiese che PVFS fosse rilasciato come pacchetto open source.

PVFS2

Nel 1999 Ligon propose lo sviluppo di una nuova versione di PVFS inizialmente soprannominata PVFS2000 e successivamente PVFS2. Il design è stato inizialmente sviluppato da Ligon, Ross e Phil Carns. Ross ha completato il suo dottorato di ricerca nel 2000 e si è trasferito all'Argonne National Laboratory e la progettazione e l'implementazione sono state eseguite da Ligon, Carns, Dale Witchurch e Harish Ramachandran alla Clemson University , Ross, Neil Miller e Rob Latham all'Argonne National Laboratory e Pete Wyckoff presso l'Ohio Supercomputer Center. Il nuovo file system è stato rilasciato nel 2003. Il nuovo design prevedeva server di oggetti, metadati distribuiti, visualizzazioni basate su MPI, supporto per più tipi di rete e un'architettura software per una facile sperimentazione ed estensibilità.

La versione 1 di PVFS è stata ritirata nel 2005. La versione 2 di PVFS è ancora supportata da Clemson e Argonne. Carns ha completato il suo dottorato di ricerca nel 2006 ed è entrato a far parte di Axicom, Inc. dove PVFS è stato distribuito su diverse migliaia di nodi per il data mining. Nel 2008 Carns si è trasferito ad Argonne e continua a lavorare su PVFS insieme a Ross, Latham e Sam Lang. Brad Settlemyer ha sviluppato un sottosistema di mirroring a Clemson e successivamente una simulazione dettagliata di PVFS utilizzata per la ricerca di nuovi sviluppi. Settlemyer è ora all'Oak Ridge National Laboratory . nel 2007 Argonne ha iniziato a portare PVFS per l'utilizzo su un IBM Blue Gene / P. Nel 2008 Clemson ha iniziato a sviluppare estensioni per supportare directory di grandi dimensioni di file di piccole dimensioni, miglioramenti della sicurezza e funzionalità di ridondanza. Poiché molti di questi obiettivi erano in conflitto con lo sviluppo per Blue Gene, un secondo ramo dell'albero dei sorgenti CVS è stato creato e soprannominato "Orange" e il ramo originale è stato soprannominato "Blue". PVFS e OrangeFS si monitorano molto da vicino, ma rappresentano due diversi gruppi di requisiti dell'utente. La maggior parte delle patch e degli aggiornamenti vengono applicati a entrambi i rami. A partire dal 2011 OrangeFS è la principale linea di sviluppo.

Caratteristiche

In un cluster che utilizza PVFS, i nodi sono designati come uno o più tra: client, server di dati, server di metadati. I server di dati conservano i dati dei file. I server di metadati contengono metadati che includono informazioni sulle statistiche, attributi e handle di file di dati, nonché voci di directory. I client eseguono applicazioni che utilizzano il file system inviando richieste ai server sulla rete.

Progettazione basata su oggetti

PVFS ha un design basato su oggetti, vale a dire che tutte le richieste del server PVFS coinvolgono oggetti chiamati dataspaces. Uno spazio dati può essere utilizzato per contenere dati di file, metadati di file, metadati di directory, voci di directory o collegamenti simbolici. Ogni spazio dati in un file system ha un handle univoco. Qualsiasi client o server può cercare quale server detiene lo spazio dati in base all'handle. Uno spazio dati ha due componenti: un bytestream e un set di coppie chiave / valore. Il bytestream è una sequenza ordinata di byte, generalmente utilizzata per contenere i dati del file, e le coppie chiave / valore vengono generalmente utilizzate per contenere i metadati. Il design basato sugli oggetti è diventato tipico di molti file system distribuiti, inclusi Lustre , Panasas e pNFS .

Separazione di dati e metadati

PVFS è progettato in modo che un client possa accedere una volta a un server per i metadati e quindi possa accedere ai server di dati senza ulteriori interazioni con i server dei metadati. Ciò rimuove un collo di bottiglia critico dal sistema e consente prestazioni molto maggiori.

Richieste basate su MPI

Quando un programma client richiede dati da PVFS, può fornire una descrizione dei dati basata su MPI_Datatypes. Questa funzione consente di implementare direttamente le visualizzazioni dei file MPI dal file system. MPI_Datatypes può descrivere modelli di dati complessi non contigui. Il server PVFS ei codici dati implementano flussi di dati che trasferiscono in modo efficiente i dati tra più server e client.

Supporto di più reti

PVFS utilizza un livello di rete denominato BMI che fornisce un'interfaccia di messaggi non bloccante progettata specificamente per i file system. BMI ha più moduli di implementazione per una serie di reti diverse utilizzate nel calcolo ad alte prestazioni tra cui TCP / IP, Myrinet , Infiniband e Portals .

Server senza stato (lockless)

I server PVFS sono progettati in modo da non condividere alcuno stato tra loro o con i client. Se un server si blocca, un altro può essere facilmente riavviato al suo posto. Gli aggiornamenti vengono eseguiti senza utilizzare i blocchi.

Implementazione a livello di utente

I client e i server PVFS vengono eseguiti a livello utente. Non sono necessarie modifiche al kernel. Esiste un modulo kernel opzionale che consente di montare un file system PVFS come qualsiasi altro file system, oppure i programmi possono collegarsi direttamente a un'interfaccia utente come MPI-IO o un'interfaccia simile a Posix . Questa funzionalità rende PVFS facile da installare e meno incline a causare arresti anomali del sistema.

Interfaccia a livello di sistema

L'interfaccia PVFS è progettata per integrarsi a livello di sistema. Ha somiglianze con Linux VFS , questo lo rende facile da implementare come file system montabile, ma è ugualmente adattabile a interfacce a livello utente come interfacce MPI-IO o Posix . Espone molte delle funzionalità del file system sottostante in modo che le interfacce possano trarne vantaggio se lo si desidera.

Architettura

PVFS è costituito da 4 componenti principali e una serie di programmi di utilità. I componenti sono il server PVFS2, il pvfslib, il core client PVFS e il modulo kernel PVFS. Le utilità includono lo strumento di gestione del karma, utilità (ad esempio, pvfs-ping, pvfs-ls, pvfs-cp, ecc.) Che operano tutte direttamente sul file system senza utilizzare il modulo del kernel (principalmente per la manutenzione e il test). Un altro punto chiave di progettazione è il protocollo PVFS che descrive i messaggi passati tra client e server, sebbene questo non sia strettamente un componente.

Server PVFS2

Il server PVFS viene eseguito come processo su un nodo designato come nodo I / O. I nodi di I / O sono spesso nodi dedicati ma possono essere nodi regolari che eseguono anche attività dell'applicazione. Il server PVFS di solito viene eseguito come root, ma può essere eseguito come utente se si preferisce. Ogni server può gestire più file system distinti ed è progettato per essere eseguito come server di metadati, server di dati o entrambi. Tutta la configurazione è controllata da un file di configurazione specificato sulla riga di comando e tutti i server che gestiscono un determinato file system utilizzano lo stesso file di configurazione. Il server riceve le richieste sulla rete, esegue la richiesta che può coinvolgere l'I / O del disco e risponde al richiedente originale. Le richieste normalmente provengono da nodi client che eseguono attività dell'applicazione, ma possono provenire da altri server. Il server è composto dal processore delle richieste, dal livello del lavoro, da Trove, BMI e dai livelli di flusso.

Richiedi processore

Il processore delle richieste è costituito dal loop principale del processo del server e da una serie di macchine a stati. Le macchine a stati si basano su un semplice linguaggio sviluppato per PVFS che gestisce la concorrenza all'interno del server e del client. Una macchina a stati è costituita da un numero di stati, ognuno dei quali esegue una funzione di azione di stato C o chiama una macchina a stati annidata (subroutine). In entrambi i casi, i codici di ritorno selezionano lo stato successivo. Le funzioni di azione di stato in genere inviano un lavoro tramite il livello di lavoro che esegue una sorta di I / O tramite Trove o BMI. I lavori non sono bloccanti, in modo che una volta che un lavoro viene emesso, l'esecuzione della macchina a stati viene posticipata in modo che un'altra macchina a stati possa eseguire il servizio di un'altra richiesta. Quando i lavori sono completati, il ciclo principale riavvia la macchina a stati associata. Il processore di richiesta dispone di macchine a stati per ciascuno dei vari tipi di richiesta definiti nel protocollo di richiesta PVFS più un numero di macchine a stati annidate utilizzate internamente. L'architettura della macchina a stati rende relativamente facile aggiungere nuove richieste al server per aggiungere funzionalità o ottimizzare per situazioni specifiche.

Livello di lavoro

Il livello Lavoro fornisce un'interfaccia comune per l'invio di lavori Trove, BMI e di flusso e per segnalare il loro completamento. Implementa inoltre lo scheduler delle richieste come un lavoro non bloccante che registra il tipo di richieste in corso su quali oggetti e previene gli errori di coerenza dovuti al funzionamento simultaneo sugli stessi dati del file.

Raccolta

Trove gestisce l'I / O per gli oggetti archiviati sul server locale. Trove opera su raccolte di spazi dati. Una raccolta ha il proprio spazio handle indipendente e viene utilizzata per implementare distinti file system PVFS. Uno spazio dati è un oggetto PVFS e ha il proprio handle univoco (all'interno della raccolta) ed è memorizzato su un server. Gli handle vengono mappati ai server tramite una tabella nel file di configurazione. Uno spazio dati è costituito da due parti: un bytestream e un insieme di coppie chiave / valore. Un bytestream è una sequenza di byte di lunghezza indeterminata e viene utilizzato per memorizzare i dati del file, in genere in un file sul file system locale. Le coppie chiave / valore vengono utilizzate per memorizzare metadati, attributi e voci di directory. Trove ha un'interfaccia ben definita e può essere implementata in vari modi. Ad oggi l'unica implementazione è stata l'implementazione Trove-dbfs che memorizza bytestreams in file e coppie chiave / valore in un database Berkeley DB . Le operazioni Trove non sono bloccanti, l'API fornisce funzioni di post per leggere o scrivere i vari componenti e funzioni da controllare o attendere il completamento.

BMI

Flussi

pvfslib

PVFS-client-core

Modulo kernel PVFS

Guarda anche

Riferimenti

link esterno