Introduzione
Le macchine parallele commerciali utilizzano file
system paralleli ma questi ultimi non si sono
dimostrati adatti per i Linux cluster poichè non
e
permettono alle applicazioni
di effettuare
operazioni di I/O intensivo.
Per riempire tale vuoto nasce il Parallel Virtual
File System (PVFS).
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.
Obiettivi del PVFS
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
Per essere precisi :
1.
Deve fornire operazioni lettura e scrittura concorrenti su una grande larghezza di banda
per processi e thread multipli su file comuni.
2.
Deve supportare APIs multiple: le APIs PVFS native, le APIs di I/O di UNIX/POSIX, le
APIs MPI-IO.
3.
Deve supportare i comuni comandi di shell (ls, cp, rm) per lavorare sui file PVFS.
4.
Deve essere robusto e scalabile.
5.
Deve essere facile da usare e da istallare.
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.
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.
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.
I metadati
I metadati, come già detto, sono gestiti dal manager!
I metedati per la distribuzione sono descritti tramite tre parametri:
1.
2.
3.
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.
Metadata example
In corrispondenza dell’esempio precedente i metadati saranno quelli riportata
nella seguente tabella:
Inode
1092157504
base
pcount
ssize
2
3
65536
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.
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
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.
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.
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
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;
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:
1.
2.
3.
4.
5.
6.
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
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.
(a)
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.
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)
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.
…Nel futuro
Cosa ci si aspetta nel futuro:
1.
Il PVFS porti un file system parallelo ad alte prestazioni su i cluster Linux
2.
Il PVFS non debba usare necessariamente il protocollo TCP
3.
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.
4.
Il PVFS abbia un’interfaccia migliori per l’accesso ai file memorizzati in
modo non contiguo.
Seminario realizzato da
Cuciniello Salvatore 566/1018