Introduzione

1. Introduzione e Le macchine parallele commerciali utilizzano file system paralleli ma questi ultimi non si sono dimostrati adatti per i Linux cluster poichè non permettono alle applicazioni di effettuare operazioni di I/O intensivo. Per riempire tale vuoto nasce il Parallel Virtual File System (PVFS).

2. Introduzione Per essere precisi bisogna fare una breve panoramica sui file system paralleli e distribuiti. Essi possono essere divisi in tre gruppi: 1.File System paralleli commerciali, come PFS,PIOFS,XFS e HFS, prevedono alte performance per applicazioni di I/0 intensivo ma sono solo disponibili su piattaforme specifiche su cui il costruttore le ha definite. (SGI, tuttavia, ha recentemente liberato XFS su Linux e CXFS per Linux cluster non ancora disponibile). 2.File System distribuiti, come NFS, AFS e GFS, non sono progettati per scritture e letture a grande larghezza di banda necessarie per le applicazioni parallele. 3.File System paralleli, come PPFS e PIOVS, sono ancora in fase di ricerca.

3. L’obiettivo primario del PVFS, come in generale di tutti i File System Paralleli, è quello di fornire l’accesso ad alta velocità ai file per le applicazioni parallele. In più permette il controllo e l’uso dello striping dei dati attraverso i dischi differenti. Obiettivi del PVFS

4. Obiettivi del PVFS Per essere precisi : • Deve fornire operazioni lettura e scrittura concorrenti su una grande larghezza di banda per processi e thread multipli su file comuni. • Deve supportare APIs multiple: le APIs PVFS native, le APIs di I/O di UNIX/POSIX, le APIs MPI-IO. • Deve supportare i comuni comandi di shell (ls, cp, rm) per lavorare sui file PVFS. • Deve essere robusto e scalabile. • Deve essere facile da usare e da istallare.

5. Architettura del sistema PVFS L’architettura del PVFS è client-server. I server sono multipli e sono chiamati demoni di I/O e lavorano tipicamente su nodi separati chiamati nodi di I/O. Ogni nodo di I/O ha un proprio disco attaccato.

6. Il Manager del PVFS Il PVFS ha un solo processo manager che è responsabile della memorizzazione e dell’accesso dei metadati dei file PVFS. I metadati descrivono le caratteristiche di un file, quali i permessi e, più importanti, la distribuzione fisica dei dati del file. In tal caso bisogna memorizzare la posizione del file su uno specifico disco e la posizione del disco nel cluster. Diverso da un file system tradizionale in cui i dati sono memorizzati su di un singolo disco. In questo caso i file sono striped in modo ordinato su un insieme di nodi per facilitare l’accesso parallelo. La figura mostra un nodo in cui c’è il demone manager.

7. Streping Proviamo a fare un esempio di streped: Il file originario è diviso in tre partizioni e ognuna di esse ha tre stripe di dimensione di 65536 bytes. Ogni partizione è memorizzata in un disco. Si osservi che non sono stati utilizzati tutti i dischi e tramite un’implementazione reale proviamo a spiegarne il motivo.

8. I metadati I metadati, come già detto, sono gestiti dal manager! I metedati per la distribuzione sono descritti tramite tre parametri: • base:il primo disco su cui è effettuato lo striped • Pcount :il numero di dischi su cui è effettuato lo striped • Ssize: dimensione dello stripe. Questi parametri insieme alla caratteristica dello streped ordinato permettono che la distribuzione dei file sia completamente specificata.

9. Metadata example In corrispondenza dell’esempio precedente i metadati saranno quelli riportata nella seguente tabella: Il primo disco in cui inizia la memorizzazione è il secondo ( base=2) ed effettuando un immagazzinamento sequenziale dei dischi i successivi saranno 3, 4 e 5 (pcount=3). La memorizzazione è fatta dai demoni di I/O: ognuno memorizza la sua porzione del file PVFS su un file system locale del nodo I/O.

10. Client & Demone di I/O I processi di applicazione interagiscono con il PVFS attraverso una libreria del client. Il processo client comunica inizialmente con il manager per verificare i permessi e aggiornare, eventualmente, i metadati. Il manager invia delle richieste al demone di I/O per far iniziare la comunicazione tra il client ed il demone di I/O: il client da questo momento invia e riceve direttamente le informazioni dal demone di I/O. Quest’ultimo accede direttamente al disco: esegue le operazioni di lettura e scrittura sul disco. Con la spiegazione delle APIs forniremo una spiegazione più dettagliata per l’accesso al file da parte del demone di I/O in corrispondenza di una richiesta de l client

11. Le APIs Le APIs utilizzate dal PVFS sono: le native API, le API UNIX/POSIX e le MPI-IO. Tutte le API rendono trasparente la comunicazione con i demoni di I/O e il manager. Le native API per PVFS hanno funzioni analoghe a quelle del UNIX/POSIX per le lettura e le scritture contigue. Esse includono anche le “interfacce per i file partizionati” che devono permettere l’accesso agli stripe dei file. Il concetto del partizionamento permette, tramite una singola chiamata di sistema, di accedere agli stripe dei file. L’utente può accedere ad una singola partizione del file usando una chiamata ioctl. Sono necessari tre parametri per accedere ad una partizione: • offset: indica l’inizio della partizione in corrispondenza del primo byte del file. • Gsize: indica la dimensione di uno stripe di una partizione; • Stride: indica la distanza tra due stripe consecutivi.

12. Parametri di una partizione Esempi di file partizionati in modo non contiguo e in modo contiguo. Per individuare tutti gli stripe di una singola partizione è necessario definire i parametri: offset, gsize e stride. Se volessimo accedere univocamente alla partizione colorata di blu dovremmo definire come offset il valore zero (inizia in corrispondenza del primo byte del file), come stride il valore 4000 e come gsize il valore 1000. In questo caso il file è diviso in tre partizioni ed ognuna di esse non è divisa in stripe. In tal caso il valore di stride è nullo.

13. I/O stream Quando un processo di un’applicazione (client) apre un file PVFS, il manager PVFS informa tale applicazione delle posizioni dei demoni di I/O. In questo modo i client possono comunicare direttamente con quest’ultimi. Quando i client vogliono accedere ai dati di un file, la libreria trasmette il descrittore della regione interessata a cui i demoni devono accedere. Questi determinano quali parti del file contengono nel proprio disco in modo da effettuare i relativi trasferimenti. Le parti trasferite sono date dall’intersezione degli stripe fisici memorizzati e la partizione logica dell’applicazione

14. I/O calls Si ricorda, innanzitutto, che le chiamate di sistema rappresentano un metodo di basso livello che permettono alle applicazioni di comunicare con il Kernel. Queste chiamate sono tipicamente fatte dalle funzioni implementate nella libreria C. Nel PVFS le chiamate di sistema prevedono un collegamento dinamico con le librerie in modo da ridurre la dimensione dell’eseguibile ed evitarne la ricompilazione nel caso siano definite nuove librerie con le stesse funzioni. Questo prevede di intrappolare le chiamate di sistema prima che esse inviano i dati al kernel. La figura (a) mostra il meccanismo delle system-calls prima che la nostra libreria sia caricata; la figura (b) dopo. La libreria caricata determina il tipo di file su cui bisogna effettuare la chiamata di sistema: nel caso il file è di tipo PVFS le informazioni sono inviate alla libreria di I/O del PVFS; altrimenti direttamente al Kernel. Questo metodo presenta uno svantaggio: nel caso si utilizza un exec() non è possibile usare i file PVFS aperti prima della chiamata;

15. Prestazioni del PVFS Uno dei motivi principali per cui è stato introdotto il PVFS è stato proprio per rendere veloci le letture e le scritture in parallelo. Vediamo cosa è successo nella realtà! Gli studi svolti nel laboratorio nazionale di Argonne hanno utilizzato una determinata configurazione: vediamo quale ed i risultati ottenuti! I cluster sono costituiti da 256 nodi ed ognuno di essi ha: • 2 processori di Pentium III di 500 Mhz • Una RAM di 512 MByte • Un disco SCSI di 9 Gbyte • Una scheda di fast-Ethernet di 100 Mbit/sec • Una scheda Myrinet di 64 bit • Linux 2.2.15pre4 Si osservi che dei 256 nodi soltanto 60 sono stati utilizzati per gli esperimenti: alcuni come nodi di calcolo ed altri come nodi di I/O. In ogni nodo è stato possibile utilizzare un singolo processore poiché l’altro è necessario per la compilazione del kernel. Si è visto che ogni nodo di calcolo ha scritto 2N Mbytes su N nodi di I/O in uso. Esempio: nel caso di 26 processi d’applicazione e con 8 nodi di I/O si è potuto verificare che ogni applicazione ha scritto 16 Mbyte avendo così un file di dimensione totale di 416 Mbytes. Secondo le prestazioni che si hanno con un singolo nodo ci si chiede: perché non utilizzare più nodi di calcolo e di I/O? La risposta è data in corrispondenza di ciò che accade per fast-Ethernet e pre Myrinet

16. Fast-Ethernet Le figure mostrano i risultati che si ottengono con fast-ethernet. La figura (a) mostra le prestazioni che si sono ottenute con le letture. Si può osservare che si ha un incremento, approssimativamente, di 11 Mbytes/sec per ogni nodo di calcolo, raggiungendo: -46 Mbytes/sec con 4 nodi di I/O; -90 Mbytes/sec con 8 nodi di I/O; -177 Mbytes/sec con 16 nodi di I/O. Per questi tre casi le prestazioni sono aumentate fino a circa 25 nodi di calcolo, dopodiché si ha avuto persino un decremento. Quindi aumentare i nodi di calcolo non è stato più necessario. In corrispondenza dei nodi di I/O si è notato che con 24 e 32 nodi di I/O si è raggiunto lo stesso picco di 222 Mbytes/sec (con 24 nodi di calcolo) ma l’andamento di crescita con 32 nodi di I/O è stato persino inferiore. (a) La figura (b) mostra i risultati che si sono ottenute con le scritture. Si può osservare che si ha un incremento, approssimativamente, di 10 Mbytes/sec per ogni nodo di calcolo, raggiungendo: -42 Mbytes/sec con 4 nodi di I/O; -83 Mbytes/sec con 8 nodi di I/O; -166 Mbytes/sec con 16 nodi di I/O. Per questi tre casi le prestazioni sono aumentate fino a circa 24 nodi di calcolo, dopodiché si ha avuto persino un decremento. In corrispondenza di 24 nodi di I/O si è raggiunto il picco di 226 Mbytes/sec e con 32 nodi di I/O non si sono avute prestazioni migliori. Quindi aumentare i nodi di I/O non è stato più necessario (b)

17. Myrinet Gli stessi esperimenti si sono ripetuti sulla rete Myrinet e si è notato che si sono avuti dei miglioramenti rispetto a fast-Ethernet ma ci sono ancora delle limitazioni. Con un esempio proviamo a verificare quali! La figura mostra le prestazioni che si sono ottenute con le letture. Si può osservare che si ha un incremento, approssimativamente, di 31 Mbytes/sec per ogni nodo di calcolo, raggiungendo: -138 Mbytes/sec con 4 nodi di I/O; -255 Mbytes/sec con 8 nodi di I/O; -450 Mbytes/sec con 16 nodi di I/O; -650 Mbytes/sec con 24 nodi di I/O; -687 Mbytes/sec con 32 nodi di I/O. Anche in questo caso si può verificare che non si ottengono delle prestazioni migliori aumentando il numero di nodi di calcolo. Inoltre secondo il grafico si ha che si hanno delle prestazioni sempre migliori aumentando il numero di nodi di I/O, ma pure se non è riportato graficamente si è dimostrato che si hanno le stesse prestazioni sia con 28 nodi di I/O e sia con 32 nodi di I/O. Questi esempi dimostrano che le prestazioni non sono direttamente proporzionali al numero di nodi di calcolo e di I/O utilizzati; o per meglio dire si hanno dei miglioramenti fino ad un limite massimo di numero di nodi di I/O e di calcolo.

18. …Nel futuro Cosa ci si aspetta nel futuro: • Il PVFS porti un file system parallelo ad alte prestazioni su i cluster Linux • Il PVFS non debba usare necessariamente il protocollo TCP • Il PVFS supporti algoritmi migliori per l’esecuzione dei demoni di I/O al fine di rendere più efficienti le operazioni di I/O e la condivisione di risorse di rete. • Il PVFS abbia un’interfaccia migliori per l’accesso ai file memorizzati in modo non contiguo. Seminario realizzato da Cuciniello Salvatore 566/1018