Io credo che il miglior modo per descrivere l'architettura del
supercomputer Beowulf è quello di usare un esempio molto simile al Beowulf reale
ma molto familiare a molti amministratori di sistema. L'esempio più
vicino ad una macchina Beowulf è un laboratorio Unix con un server e un certo
numero di client. Per essere ancora più precisi userò come esempio il
laboratorio di computer DEC Alpha per laureandi della facoltà di Scienze
dell'USQ. Il computer server si chiama beldin e le macchine
client sono chiamate scilab01, scilab02,
scilab03, fino a scilab20. Tutti i client hanno
installata una copia locale del sistema operativo Digital Unix 4.0 ma
condividono la directory degli utenti /home e la directory
/usr/local dal server via NFS (Network File System). Ogni
client ha una voce per il server e una per ognuno degli altri client nel suo
file /etc/hosts.equiv, così che ogni client può eseguire una
shell remota (rsh) in tutti gli altri. La macchina server è anche server
NIS per tutto il laboratorio, così che tutti gli account sono comuni in
tutte le macchine. Una persona può sedersi davanti alla console di
scilab02 ed avere la stessa configurazione come se si fosse
fatto il login nel server o nel client scilab15. La ragione per la
quale tutti i client hanno lo stesso look and feel è che il sistema
operativo è installato e configurato allo stesso modo su tutte le
macchine e che sia /home che /usr/local sono
fisicamente sul server e condivise da tutti i client via NFS. Per
maggiori informazioni a proposito di NIS e NFS guardate i relativi HOWTO
a
NIS e
NFS.
Ora che abbiamo un'idea circa l'architettura del sistema, diamo
un'occhiata a come possiamo utilizzare i cicli di CPU disponibili nei
computer del laboratorio. Ogni persona può fare il login in ogni macchina, e
far girare un programma nella sua directory home, ma può anche
distribuire il lavoro su macchine differenti semplicemente eseguendo
shell remote. Per esempio, mettiamo che vogliamo calcolare la somma
delle radici quadrate di tutti gli interi compresi fra 1 e 10.
Scriviamo un programma chiamandolo sigmassqrt (vedi
Codice sorgente) che fa proprio questo. Per calcolare
la somma delle radici quadrate dei numeri da 1 a 10 noi eseguiamo:
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 10 22.468278 real 0m0.029s user 0m0.001s sys 0m0.024s
Il comando time ci permette di controllare il tempo trascorso
per completare l'altro comando. Come possiamo vedere, questo esempio ha
necessitato solo una frazione di secondo (0,029 sec), ma cosa
succederebbe se io volessi conoscere la somma delle radici quadrate
degli interi compresi fra 1 e 1 000 000 000 (un miliardo)? Riproviamo e
ricontrolliamo il tempo necessario.
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 1000000000 21081851083600.559000 real 16m45.937s user 16m43.527s sys 0m0.108s
Questa volta il tempo di esecuzione è decisamente maggiore. L'ovvia domanda che sorge è cosa possiamo fare per abbreviare il tempo di esecuzione di questo programma? Come possiamo cambiare il modo in cui si esegue questo programma per ridurne il tempo di esecuzione? L'ovvia risposta è quella di dividere il lavoro in una serie di sotto-compiti e di farli girare in parallelo su tutti i computer. Noi possiamo dividere il calcolo di una grossa addizione in 20 parti, calcolare una serie di radici quadrate e farli girare su ogni nodo. Quando tutti i nodi finiscono il calcolo e restituiscono i loro risultati, i 20 numeri possono essere sommati per ottenere il risultato finale. Prima di far girare questo programma noi faremo una named pipe che verrà usata da tutti i processi per scrivere il loro risultato.
[jacek@beldin sigmasqrt]$ mkfifo output [jacek@beldin sigmasqrt]$ ./prun.sh & time cat output | ./sum [1] 5085 21081851083600.941000 [1]+ Done ./prun.sh real 0m58.539s user 0m0.061s sys 0m0.206s
Il tempo che otteniamo è di circa 58,5 secondi. Questo è il tempo trascorso dall'inizio del programma fino alla restituzione all'interno della pipe dei risultati di tutti i nodi. Il tempo così calcolato non include la somma finale dei venti numeri, ma questo tempo è molto breve e può essere trascurato. Possiamo così vedere che c'è un notevole miglioramento eseguendo questo programma in parallelo. In effetti il programma parallelo ha girato 17 volte più velocemente, che è un buon risultato avendo incrementato di 20 volte il numero di CPU coinvolte. Lo scopo di questo esempio è quello di far vedere il metodo più semplice di realizzare codice parallelo concorrente. In pratica però esempi così semplici sono rari ma vengono usate altre tecniche (le API PVM e PMI) per ottenere il parallelismo.
Il laboratorio di computer descritto sopra è un perfetto esempio di un Cluster di Workstation (COW). E allora cosa ha tanto di speciale Beowulf e in cosa è diverso da un COW? La verità è che non c'è una grande differenza, ma Beowulf ha alcune caratteristiche peculiari. Innanzitutto in molti casi i nodi client di un cluster Beowulf non hanno tastiere, mouse, schede video né monitor. Tutti gli accessi ai nodi client sono realizzati in remoto dal nodo server, nodi che fungono solo da console o da un terminale seriale. Poiché non c'è bisogno per i nodi client di accedere a computer al di fuori del cluster, né per computer esterni al cluster di accedere direttamente ai nc, è pratica comune dotare i nc di IP privati come gli indirizzi compresi in 10.0.0.0/8 o 192.168.0.0/16 (vedi RFC 1918 http://www.alternic.net/rfcs/1900/rfc1918.txt.html). Normalmente l'unica macchina connessa all'esterno con una seconda scheda di rete è il nodo server. Il modo più comune per usare un sistema di questo tipo è di usare la console del ns, oppure di entrare in telnet o shell remota dal computer personale. Una volta sul ns, gli utenti possono modificare e compilare il loro codice e anche suddividere i loro programmi su tutti i nodi del cluster. In molti casi i COW sono usati per calcoli paralleli la notte e durante i fine settimana quando gli utenti non usano effettivamente i computer per i compiti di tutti i giorni, utilizzando così cicli idle di CPU. Beowulf d'altra parte è una macchina dedicata normalmente solo al calcolo parallelo e ottimizzato per questo scopo. Beowulf inoltre ha un miglior rapporto fra prezzo e prestazioni poiché è realizzato da componenti di facile reperibilità e usa normalmente software gratuito. Beowulf ha inoltre un'immagine più da sistema singolo cosa che aiuta gli utenti a vedere un cluster Beowulf come una singola workstation