BEOWULF Cluester Linux/BSD

BEOWULF Cluester
Linux/BSD
Nardo Guido 784169
Introduzione
Negli anni passati, il mondo del Supercomputer inteso come clusters, è sempre stato
dominato da architetture e software proprietario delle maggiori aziende leader del
mercato con costi dei sistemi elevati.
Con l' abbassarsi del costo dei personal computer venne creato un progetto di
clustering basato sui sistemi operativi Linux e BSD. Nacque cosi' beowulf, grazie a
Thomas Sterling e a Don Becker. Il principale punto di forza di questo cluster si basa
sull’hardware: si poteva acquistare in qualsiasi negozio di PC periferiche e dispositivi ad
un costo ragionevole.
Beowulf fu' creato anche con lo scopo di riutilizzare workstation, magari inutilizzate, per
costruire un cluster basato su linux.
Caratteristiche
Sfrutta un'architettura a multicomputer che puo` essere usata per calcoli paralleli. Il
successo di questo cluster e' dovuto dal COTS (Commodity Off The Shelf) cioè la
comodità di avere macchine comuni impiegate in calcoli distribuiti. L'evoluzione di
questo cluster e' dovuta all'impiego di strumenti liberi quali sistemi operativi e
applicazioni basati sulla filosofia GNU e all'utilizzo di librerie di message passing quale
le PVM (Parallel Virtuale Machine) e le MPI (Message Passing Interface).
Inoltre espande le caratteristiche di quelle che erano i COW: Cluster Of Workstations
cioè un gruppo di workstation dotate di un software dedicato di clustering (comprese
librerie, database, scheduler, periferiche etc). Tutti gli accessi ai nodi client avvengono
remotamente. Solo il nodo server avra’ periferiche per il controllo locale.
Si distingue anche da NOW (Network Of Workstations) perche’ si comporta come un
singolo computer.
Le principali libreri utilizzare
PVM (Parallel Virtual Machine)
E’ una delle librerie parallele tramite cui è possibile programmare un cluster di classe
Beowulf. Permette ad un insieme eterogeneo di computers, collegati tramite una rete, di
essere usati come un unico calcolatore parallelo.
Possono essere affrontati problemi computazionali estremamente impegnativi
utilizzando la potenza di molti computers e delle PVM. Anche i sorgenti di queste
librerie sono disponibili liberamente.
La PVM fornisce una gestione di un "pool" di risorse definibili dall'utente, offrendo una
visione stabile e robusta dell'ambiente.
L'accesso alle macchine tramite PVM è reso possibile da programmi scritti in C e in
Fortran che accedono alle routines delle librerie. Le principali funzioni sono:
•
•
•
inizializzazione dei processi
trasmissione e ricezione di messaggi
sincronizzazione
Viene gestito in maniera trasparente l'instradamento dei messaggi e la conversione di
formati per i dati e per le diverse architetture.
Queste librerie sono state sviluppate principalmente per la portabilita, trascurando le
prestazioni. Tuttavia sono state sviluppate librerie più avanzate come le MPI. Sono stati
sviluppati molti tools per monitorare il comportamento del PVM (debugger,
performance, integrità, etc.)
MPI (Messagge Passing Interface)
Le API MPI sono state definite come standard per il “message passing”. Questo
standard è stato creato perche’ diverse aziende di MPP (Massively Parallel Processor)
stavano creando software proprietario per il messagging passing, rendendo quindi
impossibile realizzare applicazioni portabili e libere, vincolando gli sviluppatori a
specifiche architetture proprietarie. Sono state sviluppate per avere alte performance
per i calcoli paralleli e rimpiazzare le obsolete PVM.
Lo standard MPI e’ un insieme di routines per la comunicazione “peer-to-peer” e per
gruppi di processi. Fornisce la possibilita’ di definire delle " topologie di comunicazione"
particolari.
Il problema principale delle MPI e’ dovuto al fatto che definisce solo uno standard.
Esistono diverse implementazioni dello stesso standard che non sono compatibili tra
loro. Un'applicazione realizzata con una delle implementazioni MPI non puo’ inviare
messaggi ad un'altra realizzata con una diversa implementazione. Questo problema si
puo’ risolvere utilizzando le PVM.
Due differenti classificazioni
I nodi del cluster sono dedicati, aumentando le performance del load balacing. Ci sono
due diverse classificazioni di un cluster beowulf:
Classe I
Il cluster viene costruito completamente con hardware e componenti facilmente
reperibili. I principali vantaggi sono:
•
•
harware facilmente reperibile
basso costo delle periferiche e devices
•
•
•
liberta’ architetturale
supporto per driver (da comunità Linux / BSD)
supporto di standard (OSI, IEEE)
Classe II
Il cluster viene costruito con un’achitettura proprieratia. Differisce dal primo solamente
per un aumento delle prestazioni. Tuttavia ci sono degli svantaggi:
•
•
•
problematico supporto dei driver delle periferiche
vendor dependence
aumento del costo per la creazione del cluster
Beowulf e’ stato progettato per avere una liberta’ progettuale qundi vengono costruiti
principalmente cluster di Classe I.
Caratteristiche di Scyld
Don Becker ha fondato la Scyld Beowulf Cluster Operating System. Successiavente ha
sviluppato la Scyld che e’ una distribuzione rehdat –base e le sue caratteristiche
principali sono:
•
Facilita’ di utilizzo ed installazione: la procedura di installazione è identica a
quella della distribuzione linux redhat, con un tool per configurare del nodo
master.
•
Complessita’ di codice: Scyld Beowulf è richiesta solo sul nodomaster node. Gli
slave node caricano le librerie necessarie dal nodo master durante la procedura
di boot-up e in magrazione.
•
Migrazione: Scyld Beowulf immagazina le applicazioni sul master node. Al
momento della esecuzione, le applicazioni sono migrate ai nodi computazionali.
•
Scalabilita’: supporto trasparente per l’aggiunta o la rimozione di nodi del cluster
•
Tools di amministrazione: Scyld include un tool semplificati per l’amministrazione
e la manutenzione del cluster.
Questa distribuzione aumenta le dimensioni e la complessità del kernel non
degrandando le prestazioni del processore.
Migrazione e gestione processi
Beowulf Distributed Process Space sono delle regole e delle modifiche fatte al kernel, a
librerie e ad utility per consentire ad un utente di eseguire un processo in un’altra
macchina in Beowulf-stile. L’amministrazione remota e’ semplice, e viene gestita con le
classiche syscall di UNIX (utilizzando meccanismi come la wait() ). Ogni macchina fa
girare in locale un demone per interpretare la sintassi di Bproc.
Bproc implementa un meccanismo per la creazione e la migrazione di processi remoti.
Viene utilizzato il meccanismo della rexec, muovendo una classica syscall exec con un
basso overhead. Le operazioni sono non-preemptive e non-transparent. Una volta
migrato un processo, tutti i suoi file aperti vengono chiusi. Non è possibile per un
processo, farne migrare un altro.
Lo stato dei nodi puo’ essere:
•
down: il nodo non e’ connesso al master e/o il demone delle Bproc non funziona
correttamente. Per risolvere questo problema bisogna intervenire manualmente
sul nodo.
•
unavailable: il nodo non e’ raggiungibile dal master per qualche problema alla
macchina o al software
•
error: il master node esegue lo script /etc/beowulf/node_up Dopodiché
vengono settati i nodi considerati “up” e funzionanti. Gli altri nodi vengono messi
in stato di error
Ghost process: ogni processo remoto lascia traccia nel process tree del master.
Occupano poche risorse e sono simili ai thread di kflushd e kswapd. Per la maggior
parte del tempo sono processi che rimangono il “sleeping”. Si risvegliano per interagire
con il nodo remoto per compiere delle operazioni quali la kill(), exit(), wait().
Masquerading del Process ID: I nodi slave accettano processi che migrano dal nodo
master. Il problema sorge quando un processo migra e nel nodo master esiste un altro
processo con lo stesso PID. Lo slave non controlla lo spazio di memoria trattato dai
processi migranti. Questo problema viene risolto con il masquerading del PID. Bproc
assegna un identificatore secondario al processo migrato e tutte le syscall si riferiranno
al PID secondario.
VMADump: Virtual Memory Area Dumper e’ il sistema che utilizza Bproc per migrare un
processo in un nodo remoto. VMADump salva e ripristina lo spazio di memoria allocata
dal processo. Lo streaming di informazioni avviane su socket TCP. Successivamente
verranno deallocati tutti i suoi descrittori tranne lo STDOUT e lo STDERR. Molti
programmami, a tempo di esecuzione, utilizzano mmap per ottenere le copie delle varie
librerie di sistema che vengono utilizzate nella memory space.
In passato programmi analoghi caricavano e mappavano tutte le librerie anche sen la
maggior parte non venivano utilizzate.
VMADump può evitare di copiare queste regioni di memoria quando migra un processo
ad una macchina remota se siamo sicuri di garantire che le librerie siano linkate e
presenti nella macchina remota. Invece di memorizzazione tutte le librerie, memorizza
un riferimento alle locazioni. Quando l'immagine è ripristinata, tutti i file verranno
rimappati nelle stesse posizioni di memoria.
Le limitazioni di VMADump sono che non salva e ripristina tutte le informazioni dei file
descriptor inoltre compie un “dump” su un singolo theard di un programma multithreading.
Sicurezza
Purtroppo beowulf non implementa un sistema efficiente per la sicurezza. I dati
viaggiano con socket TCP in “chiaro” e non cifrati. Inoltre il nodo master ha anche la
funzione di fare da gateway aumentando ulteriormente il dischio di attacchi dall’esterno.
Link
Home Page Beowulf: www.beowulf.org
Standars MPI: www-unix.mcs.anl.gov/mpi/
Home Page PVM: www.csm.ornl.gov/pvm/pvm_home.html
Scyld Home Page: www.scyld.com
Beowulf Underground: www.beowulf-underground.org
Bproc Home Page: bproc.sourceforge.net