Introduzione
Molto spesso ci si ritrova a dover effettuare mansioni sistemistiche su un vasto parco macchine, come test configurazioni e managing di piu’ sistemi in maniera remota o locale ad ogni macchina. Controllare ripetutamente le macchine eseguendo gli stessi comandi su ogni sistema puo’ diventare noioso e, nel nostro lavoro, la noia e’ da evitare a tutti i costi.
In questo piccolo articolo si mostreranno i tools piu’ utili per eseguire una serie di comandi su piu’ sistemi in maniera remota e, soprattutto, parallela, incrementando la qualita’ del lavoro e la quantita’ riducendo il tempo ed il margine d’errore.
Saper utilizzare i tools che presentero’ di seguito puo’ aiutare nelle mansioni di manutenzione quotidiane ed a migliorare la qualita’ del lavoro svolto.
Clustering e parallelismo
Il termine “cluster” probabilmente e’ stato gia’ sentito e, molti di voi, gia’ avranno confidenza con questo termine. Qui di seguito daremo una spiegazione globale di cosa sia un cluster e perche’ ci interessa conoscere questo concetto.
Il cluster e’ un sistema di piu’ computer (detti nodi) che cooperano insieme per raggiungere un obiettivo; questo obiettivo puo’ essere il calcolo di un difficile integrale, di una rotta astronomia o di qualche formula chimica, ma non solo. Un cluster puo’ servire anche per garantire un servizio continuo nel caso in cui qualche nodo venisse a mancare a causa di un guasto di varia natura, oppure bilanciare il carico di rete in modo da non appesantire un solo nodo ma distribuire il carico fra tutti; risultato del cluster e’ quello di amalgamare tutti i nodi in un’unica entita’ e far si’ che tutti i nodi vengano visti come un unico nodo dalle notevoli capacita’.
E’ importante capire che le soluzioni proposte di seguito fanno loro il concetto di clustering, simulandolo in base alla lista di host, che noi forniremo, da controllare; inoltre e’ importante che i nodi abbiamo un uguale insieme di software, che permetta di eseguire con successo una stessa operazione su piu’ macchine contemporaneamente. Per fare un esempio, eseguire il programma “mioprogramma” su tutti i nodi implica che il programma sia presente su tutti i computer del nostro “gruppo”.
Concetto altrettanto importante e che va a braccetto con il clustering e’ il parallelismo.
Ogni nodo lavora di solito in “parallelo” ad un altro, questo principalmente per due motivi:
1- i tempi di elaborazione si dimezzano se ripartiti fra due o piu’ nodi
2- tutti i nodi devono apparire come un unico nodo.
Immaginare uno scenario di cluster, in cui i nodi cooperano in parallelo per un obiettivo comune, non dovrebbe essere difficile. Sfruttare il parallelismo per eseguire un comando su piu’ nodi contemporaneamente e’ il concetto alla base di questo articolo: avremo cosi’ che il tempo d’esecuzione del nostro programma sara’ minore in parallelo che in sequenziale (=digitarlo singolarmente su tutte le macchine) ed avremo la possibilita’ di generare un output piu’ riassuntivo piu’ o meno dettagliano adatto alle nostre esigenze.
Ci riferiremo, quindi, a cluster e a nodi ad indicare un gruppo di computer raggruppati logicamente secondo le nostre esigenze, siano essi Debian, Slackware, Archlinux o altre distribuzioni; l’unico vincolo e’ che abbiano tutti installato OpenSSH (o una sua implementazione equivalente) e che i programmi che vorremmo eseguire su uno siano presenti anche sugli altri (ipotesi di base di tutto l’articolo).
SSH
Per eseguire comandi in remoto, il metodo migliore e largamente utilizzato e’ usare SSH: il perche’ di questa scelta e’ presto detto. SSH e’ ormai uno standard de facto per la connesione remota su sistemi *nix; si puo’ fare qualsiasi cosa mantenendo un ottimo livello di sicurezza e senza modificare e/o configurare niente di particolare (dipende poi dalle esigenze). La crittografia a chiave asimmetrica e’ il punto di forza di SSH, cosa che lo rende molto sicuro ed affidabile, ma non si vuole entrare nel merito del protocollo.
E’ importante sapere che tutti questi tools si appoggiano ad SSH, in particolare all’implementazione di OpenSSH ed e’ necessario, per il corretto funzionamento degli stessi, una configurazione particolare: l’autenticazione a chiave. Questo tipo di autenticazione, a differenza della normale autenticazione con password, permette di evitare l’inserimento della stessa ogni volta che si vuole lavorare con il computer remoto. L’autenticazione a chiave di OpenSSH dovrebbe esservi chiara, altrimenti i passi da eseguire per utilizzarla sono molto semplici (in questo esempio il client e’ riferito alla macchina che eseguira’ i comandi di check ed il server e’ riferito ai nodi del cluster):
1- generare sul client le chiavi di autenticazione
2- copiare la chiave pubblica (di solito id_rsa.pub) sul server
3- sul server aggiungere la chiave al file authorized_keys2
4- impostare nel file sshd_config del server le seguenti voci:
RSAAuthentication yes PubkeyAuthentication yes
Il punto cruciale in tutto questo e’ la generazione delle chiavi: e’ possibile scegliere una passphrase che dovra’ essere immessa ogni volta che verra’ richiesta l’autenticazione a chiave oppure lasciare la passphrase vuota.
Nel primo caso, dovete impostare un meccanismo che vi eviti di inserire la password ogni volta che cerchiate di accedere ai nodi del cluster (utilizzando ssh-agent per esempio); nel secondo caso, invece, non e’ necessario nessun meccanismo perche’ non c’e’ nessuna password e, quando proverete a fare il login sui nodi del cluster, avrete automaticamente la shell. Per semplicita’ assumiamo eseguita la seconda opzione (nessuna passphrase per la chiave).
Dopo aver distribuito la chiave a tutti i nodi del cluster, possiamo vedere come sfruttare questa situazione per eseguire i comandi su tutti i nodi contemporaneamente.
Tools
Verranno ora presi in considerazione, uno per volta, gli strumenti alla base dell’articolo che sono: pssh, TakTuk e kanif.
pssh
Parallel SSH e’ una suite di programmi scritti in python che forniscono tutte le funzionalita’ di openssh implementate in parallelo. Parallel SSH mette a disposizione i seguenti programmi:
- parallel-ssh: esegue i comandi sui server remoti
- parallel-scp: copia i file sui server remoti
- parallel-rsync: rsync versione parallela
- parallel-slurp: copia i file dai server remoti a quello locale
- parallel-nuke: killa il processo specificato sui server remoti
Tutti i programmi sopracitati utilizzano la stessa sintassi: e’ necessario specificare un file che contiene la lista dei nodi da raggiungere corredati da porta ed utente (questi ultimi due campi sono opzionali in quanto di default viene utilizzata la porta 22 e l’utente puo’ essere specificato da riga di comando); e’ possibile specifiare, tra le altre cose, anche il numero di thread massimi da eseguire contemporaneamente che, nel caso non venisse specificato, ammonta al totale dei nodi presenti nel file lista. Vediamo un paio di esempi (i comandi pnuke e pssh sono dei link simbolici a parallel-nuke e parallel-ssh):
home:~$ pnuke -h noddo -l dav.barbato -v firefox Killed
Tramite pnuke abbiamo killato il processo di nome firefox e, grazie al flag -v, abbiamo in risposta “Killed” dal server.
home:~$ pssh -h nodes.txt -P uptime localhost: 22:06:17 up 4:37, 0 users, load average: 0.56, 0.43, 0.38 localhost: [1] 22:06:17 [SUCCESS] localhost 22 dav.barbato.ath.cx: 22:02:45 up 11:59, 2 users, load average: 0.01, 0.06, 0.07 dav.barbato.ath.cx: [2] 22:06:22 [SUCCESS] dav.barbato.ath.cx 22
il file nodes.txt e’ cosi’ formato:
localhost dav.barbato dav.barbato.ath.cx dav.barbato
In questo modo abbiamo la possibilita’ di specificare diversi utenti per diversi host senza digitarli da riga di comando. Il flag -P di pssh e’ molto utile in quanto ci mostra l’output che il comando da eseguire ha avuto sui nodi; senza quel flag pssh ci indica solo se il comando e’ stato eseguito con successo o meno (seconda linea). E’ possibile, inoltre, specificare delle variabili d’ambiente per la suite pssh e sono:
PSSH_HOSTS: file degli hosts (flag -h) PSSH_USER: l'utente con il quale collegarsi (flag -l) PSSH_PAR: numero massimo di processi paralleli (flag -p) PSSH_OUTDIR: directory di output dei comandi (flag -o per pssh) PSSH_VERBOSE: attiva il verbose (flag -v) PSSH_OPTIONS: opzioni per SSH (flag -O)
Per una panoramica sui comandi basta leggersi l’help dei vari strumenti o fare riferimento al sito http://www.theether.org/pssh.
TakTuk
TakTuk e’ qualcosa di piu’ complesso rispetto a parallel-ssh. TakTuk e’ scritto in perl (a differenza di parallel-ssh che e’ scritto in python) ed utilizza una strategia diversa rispetto al rivale sopracitato: TakTuk sfrutta SSH per autopropagarsi sui nodi selezionati ed evitare, quindi, l’installazione di TakTuk sugli stessi ed una volta propagatosi esegue il comando specificato dall’utente; l’unica cosa richiesta e’ che sui nodi sia presente l’interprete perl.
La sintassi e’ molto piu’ complessa poiche’ e’ possibile scriptare ed eseguire una serie di comandi complessi da riga di comando, questo perche’ utilizza dei template in perl che permettono, di fatto, di avere a disposizione tutta la potenza del cammello.
Vediamo qualche esempio:
home:~$ taktuk -s -m localhost broadcast exec { uptime } localhost-1: uptime (3775): output > 22:58:35 up 2:43, 0 users, load average: 0.31, 0.30, 0.32 localhost-1: uptime (3775): status > Exited with status 0
home:~$ taktuk -o output='$line=~ tr/a-z/A-Z/,$line."n"' -s -m localhost broadcast exec { uptime } 22:58:25 UP 2:43, 0 USERS, LOAD AVERAGE: 0.37, 0.31, 0.32 localhost-1: uptime (3765): status > Exited with status 0
Entrambi i comandi eseguono un uptime in localhost ma il secondo comando formatta l’output in maniera diversa grazie ad un patter match perl e all’opzione -o che sopprime o modifica l’output, in questo caso proprio lo stream di output viene modificato; se non viene specificata nessuna regex od operazione dopo l’opzione -o “stream” (dove stream puo’ essere output, status, error, info, taktuk, connector), TakTuk semplicemente sopprime la visualizzazione di quello stream a video.
Gli host remoti si specificano dopo il flag -m e questo flag deve essere ripetuto per ogni host a riga di comando inserito; e’ possibime altrimenti, come parallel-ssh, definire una lista di host sui quali eseguire il comando. Anche con TakTuk e’ possibile specificare l’utente con il quale fare il login (flag -l) e se non specificato si usera’ l’username dell’utente che sta eseguendo TakTuk. L’istruzione “broadcast” indica che il comando deve essere eseguito su tutti i nodi remoti escludendo quello da cui parte il comando, mentre “downcast” manda in esecuzione il comando a tutti i figli del nodo che fa il downcast. La direttiva “exec” di fatto esegue il comando racchiuso tra graffe sui nodi; esistono anche le direttive “get” e “put” che eseguono rispettivamente il download ed l’upload di file da/verso i nodi.
home:~$ taktuk -s -m dav.barbato.ath.cx -l dav.barbato broadcast put { nodes.txt } { nodescopy.txt }
Volendo utilizzare un file con l’elenco dei nodi:
home:~$ cat taknodes.txt dav.barbato@localhost dav.barbato@dav.barbato.ath.cx
possiamo utilizzarlo in questo modo:
home:~$ taktuk -s -f taknodes.txt broadcast exec { id } dav.barbato@localhost-1: id (3986): output > uid=1000(dav.barbato) gid=1000(dav.barbato)
groups=20(dialout),24(cdrom),25(floppy), 29(audio), 44(video), 46(plugdev),115(fuse),117(uml-net),120(vboxusers),1000(dav.barbato)
dav.barbato@localhost-1: id (3986): status > Exited with status 0 dav.barbato@dav.barbato.ath.cx-2: id (1295): output > uid=1004(dav.barbato) gid=1004(dav.barbato) groups=1004(dav.barbato) dav.barbato@dav.barbato.ath.cx-2: id (1295): status > Exited with status 0
Una volta propagato, TakTuk crea una sorta di rete logica rendendo inutile la ripropagazione iniziale (flag -s): lo stato di questo logical network puo’ essere controllato tramite la direttiva “network” o “network state” ed e’ possibile cancellare un nodo dalla rete logica o fare l’update della stessa.
E’ possibile scegliere il metodo di deploy (=propagazione) di TakTuk sui nodi tramite il flag -d.
Di default questo valore e’ 0 ovvero viene utilizzato un deploy dinamico automaticamente tracciato da TakTuk che propaga se stesso su un nodo e da questo ad un altro nodo in base alla velocita’ di esecuzione dei comandi; specificando il valore -1 si disattiva il deploy dinamico e TakTuk verra’ propagato dal nodo root (dove noi stiamo eseguendo il comando) a tutti i nodi in maniera diretta senza “passare” per altri nodi. Specificare un valore diverso permette di selezionare il tipo di deploy appropriato: -d1 esegue un deploy a catena, ovvero TakTuk verra’ propagato al primo nodo della lista e da li’ al successivo e dal successivo all’altro nodo suo successivo e cosi’ via; -d2 specifica un deploy di tipo binary tree, mentre e’ possibile specificare la propria struttura di deploy innestando i flag -d e quelli -m, come in questo esempio:
home:~$ taktuk -d 1 -m nodo1 -m nodo2 [ -d2 -m nodo3 -m nodo4 -nodo5 ] exec { uptime }
che esegue un deploy a catena sui primi due nodi e un binary tree sui restanti 3.
Per visualizzare il network state di taktuk, bisogna farlo partire in modalita’ interattiva, ovvero senza specificare il comando da eseguire ma solo la lista dei nodi su cui propagarsi. Questo e’ taktuk che esegue un deploy di default:
home:~$ taktuk -o connector -s -f taknodes.txt broadcast exec { id } dav.barbato@localhost-1: id (3643): output > uid=1000(dav.barbato) gid=1000(dav.barbato) groups=20(dialout),24(cdrom),25(floppy),
29(audio), 44(video), 46(plugdev),115(fuse),117(uml-net),120(vboxusers),1000(dav.barbato)
dav.barbato@localhost-1: id (3643): status > Exited with status 0 dav.barbato@srv-2: id (7578): output > uid=1000(dav.barbato) gid=0(wheel) groups=0(wheel) dav.barbato@srv-2: id (7578): status > Exited with status 0 dav.barbato@dav.barbato.ath.cx-3: id (15508): output > uid=263149(dav.barbato) gid=100(users) groups=100(users) dav.barbato@dav.barbato.ath.cx-3: id (15508): status > Exited with status 0 network state w00t (0, 1) dav.barbato@localhost (1, 1) dav.barbato@srv (2, 1) dav.barbato@dav.barbato.ath.cx (3, 1) quit home:~$
Quest’altra esecuzione, invece, implica un deploy a catena di taktuk:
home:~$ taktuk -o connector -d 1 -s -f taknodes.txt broadcast exec { id } dav.barbato@localhost-1: id (3698): output > uid=1000(dav.barbato) gid=1000(dav.barbato) groups=20(dialout),24(cdrom),25(floppy),
29(audio),44(video),
46(plugdev),115(fuse),117(uml-net),120(vboxusers),1000(dav.barbato)
dav.barbato@localhost-1: id (3698): status > Exited with status 0
dav.barbato@srv-2: id (13209): output > uid=1000(dav.barbato) gid=0(wheel) groups=0(wheel)
dav.barbato@srv-2: id (13209): status > Exited with status 0
dav.barbato@dav.barbato.ath.cx-3: id (15508): output > uid=263149(dav.barbato) gid=100(users) groups=100(users)
dav.barbato@dav.barbato.ath.cx-3: id (15508): status > Exited with status 0
network state
w00t (0, 1)
dav.barbato@localhost (1, 1)
dav.barbato@srv (2, 1)
dav.barbato@dav.barbato.ath.cx (3, 1)
N.B. E’ stato aggiunto un nodo al file taknodes, ovvero dav.barbato@srv. N.B.B. In quest’ultimo caso, ovviamente, tutti i server devono scambiarsi le chiavi l’un l’altro, poiche’ taktuk, dopo essersi propagato sull’host srv, cerchera’ di collegarsi (tramite ssh) da quella postazione al server di dopo (in questo caso dav.barbato.ath.cx) e se dav.barbato@srv non ha inserito la chiave su dav.barbato.ath.cx, il deploy di quest’ultimo nodo fallira’.
E l’ultimo e’ il deplpoy ad albero:
home:~$ taktuk -o connector -d 2 -s -f taknodes.txt broadcast exec { id } dav.barbato@localhost-1: id (3717): output > uid=1000(dav.barbato) gid=1000(dav.barbato) groups=20(dialout),24(cdrom),25(floppy),
29(audio), 44(video),46(plugdev),115(fuse),117(uml-net),120(vboxusers),1000(dav.barbato)
dav.barbato@localhost-1: id (3717): status > Exited with status 0
dav.barbato@srv-3: id (3964): output > uid=1000(dav.barbato) gid=0(wheel) groups=0(wheel)
dav.barbato@srv-3: id (3964): status > Exited with status 0
dav.barbato@dav.barbato.ath.cx-2: id (15957): output > uid=263149(dav.barbato) gid=100(users) groups=100(users)
dav.barbato@dav.barbato.ath.cx-2: id (15957): status > Exited with status 0
network state
w00t (0, 1)
dav.barbato@localhost (1, 1)
dav.barbato@dav.barbato.ath.cx (2, 1)
dav.barbato@srv (3, 1)
Nel nostro caso, l’opzione -d -1 e -d 0 coincidono come deploy. Il primo valore nella parentesi dell’host rappresenta il valore logico dell’host nella rete taktuk, mentre il secondo rappresenta lo stato (1= attivo e funzionante).
E’ inoltre possibile visualizzare tutti i parametri di default e le variabili usate da TakTuk tramite il flag -P.
Un’altra caratteristica peculiare di questo strumento e’ la sua possibile integrazione in script perl o C. Per quanto riguarda perl, TakTuk mette a disposizione taktuk_perl che e’ una funzione utilizzabile in script e programmi perl e che mette a disposizione taktuk::send, taktuk::recv, taktuk::error e taktuk::error_msg.
Viene anche fornito un header file per programmi C, taktuk.h (libtaktuk2-dev in Debian e Debian-Like system) con le stesse funzioni di quello perl: taktuk_send(), taktuk_recv(), taktuk_error, taktuk_error_msg() e tante altre funzioni.
Ci sarebbero ancora tante opzioni, ma vi consiglio di sperimentarle da voi: all’inizio sembrera’ poco intuitivo, ma bastano pochi minuti per abituarsi alla sintassi e tirare fuori il meglio da questo programma molto valido. Se poi conoscete il perl, allora potrete davvero fare cose mirabolanti.
kanif
Il comando remoto di taktuk id, tramite kanif, puo’ scriversi cosi’:
home:~$ kash -M nodes.txt id -------------------------------------------------------------------------------- STDOUT -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- dav.barbato@dav.barbato.ath.cx (1 HOST) -------------------------------------------------------------------------------- uid=263149(dav.barbato) gid=100(users) groups=100(users) -------------------------------------------------------------------------------- dav.barbato@srv (1 HOST) -------------------------------------------------------------------------------- uid=1000(dav.barbato) gid=0(wheel) groups=0(wheel) -------------------------------------------------------------------------------- dav.barbato@localhost (1 HOST) -------------------------------------------------------------------------------- uid=1000(dav.barbato) gid=1000(dav.barbato) groups=20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),115(fuse),117(uml-net),120(vboxusers),1000(dav.barbato)
kanif in sostanza e’ un wrapper per taktuk che permette di fare (quasi) le stesse cose ma con sintassi piu’ semplice.
Le potenzialita’ di kanif e’ la combinazione della sintassi del file di configrazione e di listing dei nodi in stile C3 e la potenza di esecutiva e logica di taktuk; questi due elementi combinati insieme hanno dato vita proprio a kanif, che ci aiuta nel lavoro di tutti i giorni in maniera eccellente, rapida e veloce.
Di default viene utilizzato il file ~/.kanif.conf per estrarre la lista dei nodi sul quale eseguire il deploy; ecco il file:
cluster MYCLU { eth0:eth0 dav.barbato@localhost dav.barbato@dav.barbato.ath.cx 10.50.5.[1-12] exclude 11 }
Questa sintassi ci permette di specificare un gruppo di nodi, definito dalla keywork “cluster”, di nome MYCLU e che contiene l’elenco dei nodi ai quali connetterci. La penultima riga comprende una serie di nodi nel range 10.50.5.1 – 10.50.5.12, mentre la direttiva “exclude” esclude l’IP 10.50.5.11 dall’esecuzione di comandi. La prima riga e’ l’elenco delle interfacce di rete connesse con l’esterno (a sinistra dei due punti) e quella connessa con i nodi del cluster (quella a destra) che nel nostro caso coincide, essendo tutti i nodi collegati via switch.
In questo modo e’ possibile chiamare kanif cosi’:
home:~$ kash MYCLU: id
Una feature interessante e’ la monitor mode:
dav.barbato@w00t:~$ kash -M nodes.txt -m id [KANIF MONITORING] -- Command started on dav.barbato@localhost [KANIF MONITORING] -- execution on dav.barbato@localhost terminated with status 0 [KANIF MONITORING] -- Command terminated on dav.barbato@localhost [KANIF MONITORING] -- Command started on dav.barbato@srv [KANIF MONITORING] -- execution on dav.barbato@srv terminated with status 0 [KANIF MONITORING] -- Command terminated on dav.barbato@srv [KANIF MONITORING] -- Command started on dav.barbato@dav.barbato.ath.cx [KANIF MONITORING] -- execution on dav.barbato@dav.barbato.ath.cx terminated with status 0 [KANIF MONITORING] -- Command terminated on dav.barbato@dav.barbato.ath.cx [KANIF MONITORING] -- All tasks terminated -------------------------------------------------------------------------------- STDOUT -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- dav.barbato@dav.barbato.ath.cx (1 HOST) -------------------------------------------------------------------------------- uid=263149(dav.barbato) gid=100(users) groups=100(users) -------------------------------------------------------------------------------- dav.barbato@srv (1 HOST) -------------------------------------------------------------------------------- uid=1000(dav.barbato) gid=0(wheel) groups=0(wheel) -------------------------------------------------------------------------------- dav.barbato@localhost (1 HOST) -------------------------------------------------------------------------------- uid=1000(dav.barbato) gid=1000(dav.barbato) groups=20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),115(fuse),117(uml-net),120(vboxusers),1000(dav.barbato) [KANIF MONITORING] -- Closing write channel dav.barbato@w00t:~$
Dopo aver dato il comando da shell, possiamo vedere le statistiche di kanif premendo una sola volta Ctrl-C, come in questo caso:
home:~$ kash -M nodes.txt id
^C--------------------------------------------------------------------------------
CURRENT STATE
--------------------------------------------------------------------------------
Connections initialized : 3
Connections failed : 0
Commands started : 0
Commands failed : 0
Commands terminated : 0
Type within 1 second : Ctrl-C to quit this program
Ctrl-Z to cancel ongoing connections
--------------------------------------------------------------------------------
STDOUT
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
dav.barbato@dav.barbato.ath.cx (1 HOST)
--------------------------------------------------------------------------------
uid=263149(dav.barbato) gid=100(users) groups=100(users)
--------------------------------------------------------------------------------
dav.barbato@srv (1 HOST)
--------------------------------------------------------------------------------
uid=1000(dav.barbato) gid=0(wheel) groups=0(wheel)
--------------------------------------------------------------------------------
dav.barbato@localhost (1 HOST)
--------------------------------------------------------------------------------
uid=1000(dav.barbato) gid=1000(dav.barbato)
groups=20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),115(fuse),117(uml-net),120(vboxusers),1000(dav.barbato)
premere una seconda volta Ctrl-C terminera’ kanif mentre Ctrl-Z elimina le connessioni da effettuare. E’ possibile specificare i comandi di taktuk tramite il flag -T, in modo da lasciare anche agli utenti fedeli di taktuk la possibilita’ di scegliere la sintassi che piu’ aggrada.
Conclusioni
I programmi qui presentati sono solo una serie dei molteplici strumenti messi a disposizione dal mondo opensource per gestire i cluster e non sono state mostrate tutte le potenzialita’ di questi strumenti: si e’ cercato di dare una panoramica generale e tecnica sul loro utilizzo e peculiarita’, lasciando al lettore il piacere di leggere la documentazione relativa e sperimentare nuove sintassi e soprattutto nuovi ambienti di utilizzo.
Webliography
http://taktuk.gforge.inria.fr/
http://taktuk.gforge.inria.fr/kanif/
http://www.theether.org/pssh/
http://it.wikipedia.org/wiki/Computer_cluster
http://it.wikipedia.org/wiki/Calcolo_parallelo
