<!doctype Linuxdoc system>

<article>

<title> Linux Cluster HOWTO </title>

<author>Ram Samudrala <tt>(me@ram.org)</tt> </author>
<date> v1.5, 5 settembre 2005 </date>

<abstract>
Come configurare cluster Linux ad alte prestazioni
</abstract>

<!-- ************************************************************* -->

<toc>

<sect>  Introduzione

<p> Questo documento descrive come abbiamo configurato i cluster 
ad alte prestazioni che utilizziamo per <htmlurl
url="http://compbio.washington.edu" name="la nostra ricerca">. </p>

<p> L'utilizzo dell'informazione seguente &egrave; a proprio rischio. Declino
ogni responsabilit&agrave; per qualsiasi cosa si faccia dopo aver letto questo HOWTO.
L'ultima versione di questo HOWTO sar&agrave; sempre disponibile all'indirizzo <htmlurl
url="http://www.ram.org/computing/linux/linux_cluster.html"
name="http://www.ram.org/computing/linux/linux_cluster.html">. </p> 

<p> A differenza di altra documentazione che spiega come configurare cluster in
generale, questa &egrave; una descrizione specifica di come &egrave; configurato il nostro
laboratorio e include non solo dettagli sugli aspetti computazionali, ma anche
su desktop, portatili e server pubblici. Ci&ograve; &egrave; fatto principalmente 
per uso locale, ma l'ho pubblicato sul web perch&eacute; ho ricevuto molti
messaggi di posta elettronica che chiedevano le stesse informazioni.
Anche oggi, pianificando un altro cluster a 64 nodi, rilevo
scarsit&agrave; di informazione su come assemblare esattamente i componenti
per formare un nodo che funzioni in modo affidabile sotto Linux, vale a dire
informazione non solo sui nodi di calcolo, ma anche sull'hardware che 
deve funzionare bene con i nodi affinch&eacute; sia possibile una ricerca produttiva.
La principale utilit&agrave; di questo HOWTO &egrave; che riporta quale tipo di hardware
funziona bene con Linux e quale no. </p>

<p> Traduzione a cura di Amelia de Vivo. Revisione di Giulio Daprel&agrave; (giulio at pluto.it) </p>

</sect>

<!-- ************************************************************* -->

<!-- ************************************************************* -->

<sect> Hardware

<p> Questo paragrafo copre le scelte hardware che ho fatto. A meno che
non sia riportato nel paragrafo <ref id="known_hardware_issues" name="problemi 
hardware noti">, si assuma che tutto funzioni <it>realmente</it> bene.  </p>

<p> L'installazione dell'hardware &egrave; anche abbastanza facile, a meno che non 
sia esplicitamente riportato, e la maggior parte dei dettagli &egrave;
coperta dai manuali. In tutti i paragrafi l'hardware &egrave; elencato in ordine di 
acquisto (il pi&ugrave; recente &egrave; elencato per primo). </p>

<!-- ************************************************************* -->

<sect1> I nodi

<p> 32 macchine hanno la seguente configurazione: 

<itemize>
<item> 2 CPU XEON 2.66GHZ 533FSB </item>
<item> Scheda madre Supermicro 6013A-T, 1U </item>
<item> 2 moduli RAM 512MB PC2100 DDR REG ECC </item>
<item> 1 HD 80 GB SEA 7200 RPM SATA </item>
<item> 1 HD 250 GB SEA 7200 RPM SATA </item>
</itemize>
</p>

<p> 32 macchine hanno la seguente configurazione: 

<itemize>
<item> 2 CPU XEON 2.4GHZ 533FSB </item>
<item> Scheda madre Supermicro X5DPR-1G2 </item>
<item> 2 moduli RAM 512 MB PC2100 DDR REG ECC </item>
<item> 1 HD 40GB SEA 7200 RPM </item>
<item> 1 HD 120GB SEA 7200 RPM </item>
<item> CDROM Supermicro Slim 24X </item>
<item> Alloggiamento CSE-812 400 C/B 1U </item>
</itemize>
</p>

<p> 32 macchine hanno la seguente configurazione: 

<itemize>
<item> 2 CPU AMD Palamino MP XP 2000+ 1.67 GHz </item>
<item> Scheda madre Asus A7M266-D w/LAN Dual DDR </item>
<item> 2 moduli RAM Kingston 512MB PC2100 DDR-266MHz REG ECC </item>
<item> 1 HD 41 GB Maxtor 7200 RPM ATA100 </item>
<item> 1 HD 120 GB Maxtor 5400 RPM ATA100 </item>
<item> CDROM Asus CD-A520 52x </item>
<item> Floppy drive 1.44 MB </item>
<item> ATI Expert 2000 Rage 128 32 MB </item>
<item> Alloggiamento mezza torre IN-WIN P4 300ATX </item>
<item> Alimentatore Enermax P4-430ATX </item>
</itemize>
</p>

<p> 32 macchine hanno la seguente configurazione: 

<itemize>
<item> 2 CPU AMD Palamino MP XP 1800+ 1.53 GHz </item>
<item> Scheda madre Tyan S2460 Dual Socket-A/MP </item>
<item> RAM Kingston 512 MB PC2100 DDR-266MHz REG ECC </item>
<item> 1 HD 20 GB Maxtor UDMA/100 7200 RPM </item>
<item> 1 HD 120 GB Maxtor 5400 RPM ATA100 </item>
<item> CDROM Asus CD-A520 52x </item>
<item> Floppy drive 1.44 MB </item>
<item> Scheda video ATI Expert 98 8 MB AGP </item>
<item> Alloggiamento mezza torre IN-WIN P4 300ATX </item>
<item> Scheda di rete Intel PCI PRO-100 10/100Mbps </item>
<item> Alimentatore Enermax P4-430ATX </item>
</itemize>
</p>

<p> 32 macchine hanno la seguente configurazione: 

<itemize>
<item> 2 CPU Pentium III 1 GHz Intel </item>
<item> Scheda madre Supermicro 370 DLE Dual PIII-FCPGA </item>
<item> 2 moduli RAM 256 MB 168-pin PC133 Registered ECC Micron </item>
<item> 1 HD 20 GB Maxtor ATA/66 5400 RPM </item>
<item> 1 HD 40 GB Maxtor UDMA/100 7200 RPM </item>
<item> CDROM Asus CD-S500 50x </item>
<item> Floppy drive 1.44 MB </item>
<item> Scheda video ATI Expert 98 8 MB PCI </item>
<item> Alloggiamento mezza torre IN-WIN P4 300ATX </item>
</itemize>
</p>

</sect1>

<!-- ************************************************************* -->

<sect1> I server 

<p> Due server per uso esterno (diffusione di informazioni) con
le seguenti configurazioni:

<itemize>
<item> 2 CPU AMD Opteron 240 1.4 GHz </item>
<item> Scheda madre RIOWORKS HDAMB DUAL OPTERON </item>
<item> 4 moduli RAM KINGSTON 512 MB PC3200 REG ECC </item>
<item> HD 80 GB MAX 7200 RPM UDMA 133 </item>
<item> 6 HD 200 GB WD 7200 RPM 8 MB </item>
<item> CDROM ASUS 52X CD-A520 </item>
<item> Floppy drive 1.44 MB </item>
<item> Alloggiamento Antec 4U22ATX550EPS 4U </item>
</itemize>

<itemize>
<item> 2 CPU AMD Palamino MP XP 2000+ 1.67 GHz </item>
<item> Scheda madre Asus A7M266-D w/LAN Dual DDR </item>
<item> 4 moduli RAM Kingston 512 MB PC2100 DDR-266MHz REG ECC </item>
<item> CDROM Asus CD-A520 52x </item>
<item> 1 HD 41 GB Maxtor 7200 RPM ATA100 </item>
<item> 6 HD 120 GB Maxtor 5400 RPM ATA100 </item>
<item> Floppy drive 1.44 MB </item>
<item> ATI Expert 2000 Rage 128 32 MB </item>
<item> Alloggiamento mezza torre IN-WIN P4 300ATX </item>
<item> Alimentatore Enermax P4-430ATX </item>
</itemize>
</p>

</sect1>

<!-- ************************************************************* -->

<sect1> I Desktop e i Terminali

<p> Abbiamo identificato almeno due tipi di utenti per i nostri cluster:
quelli che hanno bisogno (ovvero traggono vantaggio da) di potenza computazionale
permanente e locale e spazio su disco in congiunzione con il cluster per 
velocizzare il calcolo, e quelli che hanno solo bisogno della potenza computazionale
del cluster. Ai primi sono assegnati dei "desktop" che essenzialmente sono macchine
ad alte prestazioni, e ai secondi sono assegnati dei "terminali" stupidi. I nostri
desktop son in genere macchine a due o quattro processori che montano CPU Opteron a 1.6 GHz,
attualmente di alto profilo, hanno fino a 10 GB di RAM e oltre 1 TB di spazio di 
disco locale. I nostri terminali sono essenzialmente macchine da cui un utente pu&ograve;
collegarsi e lanciare job sui cluster. In questa configurazione le persone possono
anche usare dei portatili come terminali stupidi. </p>
</sect1>

<!-- ************************************************************* -->

<sect1> Varie/accessori

<p> Generalmente usiamo/preferiamo monitor Viewsonic, mouse Microsoft Intellimouse 
e tastiere Microsoft Natural. Questi in genere hanno funzionato in modo abbastanza
affidabile per noi. </p>

</sect1>

<!-- ************************************************************* -->


<sect1> Hardware per mettere tutto insieme 

<p> Per l'accesso visuale ai nodi, inizialmente usavamo switch KVM
con un monitor economico per connettersi e "guardare" tutte le macchine.  
Sebbene fosse una bella soluzione, non scalava. Attualmente portiamo
un piccolo monitor in giro e attacchiamo dei cavi quando serve.
Quello che ci serve &egrave; un piccolo monitor portatile che si pu&ograve; collegare
dietro a un PC (alimentato con una stilo, come un Palmare). </p>

<p> Per la rete, in genere usiamo switch Netgear e Cisco. </p>

</sect1>

<!-- ************************************************************* -->


<sect1> Costi

<p> Abbiamo acquistato il nostro hardware presso Hard Drives Northwest (<htmlurl
url="http://www.hdnw.com" name="http://www.hdnw.com">). Per ciascun
nodo del cluster (contenente due processori), abbiamo speso circa
1500-2000 dollari, tasse incluse. Generalmente, il nostro scopo &egrave; tenere il costo
di ciascun processore sotto i 1000 dollari (compreso l'alloggiamento). </p>

</sect1> 

<!-- ************************************************************* -->

</sect>

<!-- ************************************************************* -->

<sect> Software

<!-- ************************************************************* -->

<sect1> Sistema operativo: Linux, naturalmente!

<p> I kernel e le distribuzioni in uso sono i seguenti:

<itemize>
  <item> Kernel 2.2.16-22, distribuzione KRUD 7.0
  <item> Kernel 2.4.9-7, distribuzione KRUD 7.2
  <item> Kernel 2.4.18-10, distribuzione KRUD 7.3
  <item> Kernel 2.4.20-13.9, distribuzione KRUD 9.0
  <item> Kernel 2.4.22-1.2188, distribuzione KRUD 2004-05
</itemize>

Queste distribuzioni vanno molto bene per noi perch&eacute; gli aggiornamenti
ci vengono mandati su CD e non c'&egrave; nessun bisogno di connessioni esterne.
Inoltre sembrano "pi&ugrave; pulite" delle normali distribuzioni Red Hat e la
configurazione &egrave; estremamente stabile. </p>

</sect1>

<!-- ************************************************************* -->

<sect1> Software di rete

<p> Noi usiamo Shorewall 1.3.14a (<htmlurl url="http://www.shorewall.net"
name="http://www.shorewall.net">) per il firewall. </p>

</sect1>

<!-- ************************************************************* -->

<sect1> Software per il calcolo parallelo

<p> Noi usiamo software proprietario per parallelizzare le applicazioni,
ma abbiamo fatto esperimenti con <htmlurl url="http://www.csm.ornl.gov/pvm/pvm_home.html"
name="PVM"> e <htmlurl url="http://www-unix.mcs.anl.gov/mpi/mpich/"
name="MPI">. Secondo me l'overhead di 
queste librerie preconfezionate &egrave; troppo alto. Raccomando di scrivere 
codice specifico per l'applicazione che vi interessa (&egrave; un opinione
personale). </p>

</sect1>

<!-- ************************************************************* -->

<sect1> Costi

<p> Linux e la maggior parte del software che gira sotto Linux sono
liberamente utilizzabili. </p>

</sect1>

<!-- ************************************************************* -->

</sect>

<!-- ************************************************************* -->

<sect> Installazione, configurazione e manutenzione

<!-- ************************************************************* -->

<sect1> Configurazione dei dischi

<p> Questo paragrafo descrive le strategie di partizionamento dei dischi. 
Il nostro scopo &egrave; mantenere le strutture virtuali delle macchine organizzate
in modo tale che siano tutte logiche. Stiamo constatando che i mapping fisici alle
strutture logiche non sono sostenibili quando l'hardware e il software
(sistema operativo) cambiano. Attualmente, la nostra strategia &egrave; la seguente: 

<tscreen><verb>
nodi dei cluster:

partizione 1 sul disco di sistema 		- swap   (2 * RAM)
partizione 2 sul disco di sistema 		- /      (il resto dello spazio del disco)
partizione 1 su un disco addizionale 	- /maxa  (tutto il disco)

server:

partizione 1 sul disco di sistema        	- swap  (2 * RAM)
partizione 2 sul disco di sistema        	- /     (4-8 GB)
partizione 3 sul disco di sistema        	- /home (il resto dello spazio del disco)
partizione 1 sul disco addizionale 1	- /maxa (tutto il disco)
partizione 1 sul disco addizionale 2	- /maxb (tutto il disco)
partizione 1 sul disco addizionale 3	- /maxc (tutto il disco)
partizione 1 sul disco addizionale 4	- /maxd (tutto il disco)
partizione 1 sul disco addizionale 5	- /maxe (tutto il disco)
partizione 1 sul disco addizionale 6	- /maxf (tutto il disco)
partizione 1 su disco/i addizionale/i	- /maxg (spazio totale sui dischi)

desktop:

partizione 1 sul disco di sistema        	- swap   (2 * RAM)
partizione 2 sul disco di sistema        	- /      (4-8 GB)
partizione 3 sul disco di sistema       	- /spare (il resto dello spazio del disco)
partizione 1 sul disco addizionale 1	- /maxa (tutto il disco)
partizione 1 su disco/i addizionale/i	- /maxb (spazio totale sui dischi)
</verb></tscreen>
</p>

<p> Si noti che nel caso di server e desktop, maxg e maxb possono
essere un singolo disco o un agglomerato di dischi. </p>

</sect1>

<!-- ************************************************************* -->

<sect1> Configurazione dei pachetti software 

<p> Installare un insieme minimale di pacchetti per la collettivit&agrave;. Gli utenti possono
configurare i desktop come vogliono, fermo restando che la struttura virtuale
&egrave; mantenuta come descritto sopra. </p>

</sect1>

<!-- ************************************************************* -->

<sect1> Installazione e manutenzione del sistema operativo

<!-- ************************************************************* -->

<sect2> Strategia personale di clonazione

<p> Io credo nell'utilit&agrave; di avere un sistema completamente ditribuito.
Ci&ograve; significa che ogni macchina ha una copia del sistema operativo.
Installare il SO su ciascuna macchina manualmente &egrave; scomodo. Per ottimizzare
questo processo, prima installo e configuro una macchina esattamente come voglio.
Poi creo un file tar compresso dell'intero sistema e lo metto su un CD-ROM 
di avviamento che infine clono su ogni macchina del mio cluster. </p>

<p> I comandi che uso per creare il tar sono i seguenti: 

<tscreen><verb>
tar -czvlps --same-owner --atime-preserve -f /maxa/slash.tgz /
</verb></tscreen>
</p>

<p> Uso uno script che si chiama <tt>go</tt> che prende in input un
numero di macchina, scompatta il file <tt>slash.tgz</tt> dal
CD-ROM e sostituisce l'hostname e l'indirizzo IP nelle locazioni appropriate.
Una versione dello script <tt>go</tt> e i relativi file input si trovano a: <htmlurl
url="http://www.ram.org/computing/linux/cluster/"
name="http://www.ram.org/computing/linux/linux/cluster/">. Questo script
dovr&agrave; essere modificato in base alla configurazione del vostro cluster. </p>

<p> Per fare questo lavoro uso Custom Rescue Disk di Martin Purschke
(<htmlurl url="http://www.phenix.bnl.gov/~purschke/RescueCD/"
name="http://www.phenix.bnl.gov/~purschke/RescueCD/">) per creare 
su un CD di avviamento un'immagine contenente il file .tgz che 
rappresenta il sistema clonato, come pure lo script <tt>go</tt> 
e altri file relativi. Tutto ci&ograve; &egrave; impresso su un CD-ROM. </p>

<p> Ci sono parecchi documenti che descrivono come creare un proprio
CD di avviamento, compreso il Linux Bootdisk HOWTO (<htmlurl
url="http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO/"
name="http://www.linuxdoc.org/HOWTO/Bootdisk-HOWTO/">), che contiene anche
dei link ad altri dischi di boot/root preconfezionati. </p>

<p> Ora avete un sistema grazie al quale tutto quello che dovete fare &egrave;
inserire un CDROM, accendere la macchina, andare a prendere un caff&egrave; 
(o una lattina di coca) e tornare a vedere un clone completo. Ripetete
questo processo per tutte le macchine che avete. Questa procedura ha funzionato
meravigliosamente bene per me e se avete qualcun altro che effettivamente fa il
lavoro (di inserire e rimuovere i CDROM), allora &egrave; l'ideale.
Nel mio sistema, specifico l'indirizzo IP specificando il numero della 
macchina, ma questo potrebbe essere completamente automatizzato con l'uso di DHCP.
</p>

<p> Rob Fantini (<htmlurl url="mailto:rob@fantinibakery.com"
name="rob@fantinibakery.com">) ha contribuito alle modifiche
dei suddetti script che ha usato per clonare un sistema Mandrake 8.2 
accessibili all'indirizzo <htmlurl
url="http://www.ram.org/computing/linux/cluster/fantini_contribution.tgz"
name="http://www.ram.org/computing/linux/cluster/fantini_contribution.tgz">.
</p>

</sect2>

<!-- ************************************************************* -->

<sect2> Pacchetti per la clonazione e la manutenzione

<sect3> FAI 

<p> FAI (<htmlurl url="http://www.informatik.uni-koeln.de/fai/"
name="http://www.informatik.uni-koeln.de/fai/">) &egrave; un sistema automatico
per installare un sistema operativo GNU/Linux Debian su un cluster di PC.
Potete prendere uno o pi&ugrave; PC vergini, accenderli e dopo pochi minuti Linux
sar&agrave; installato, configurato e funzionante sull'intero cluster, senza necessit&agrave; 
di alcuna interazione.

</sect3> 

<sect3> SystemImager 

<p> SystemImager (<htmlurl url="http://systemimager.org"
name="http://systemimager.org">) &egrave; un software che automatizza 
l'installazione di Linux, la distribuzione del software e la
rapida produzione.
</p>

</sect3>

</sect2>

<!-- ************************************************************* -->

<sect2> DHCP e indirizzi IP fissi

<p> Se avete configurato il DHCP, non avete bisogno di risistemare
gli indirizzi IP e la relativa parte pu&ograve; essere rimossa dallo script
<tt>go</tt>. </p>

<p> Il DHCP ha il vantaggio di non farvi affatto impazzire con gli indirizzi 
IP, posto che il server DHCP sia configurato in modo esatto. Ha per&ograve; lo 
svantaggio di dipendere da un server centralizzato (e come ho detto, io
tendo a distribuire le cose quanto pi&ugrave; &egrave; possibile). Inoltre, legare gli 
indirizzi delle schede ethernet agli indirizzi IP pu&ograve; essere scomodo 
se volete sostituire macchine o cambiare hostname spesso. </p>

</sect2>

<!-- ************************************************************* -->

</sect1>

<!-- ************************************************************* -->

<sect1> Problemi hardware noti <label id="known_hardware_issues">

<p> L'hardware in generale ha funzionato veramente bene. Problemi 
specifici sono elencati di seguito: </p>

<p> Le macchine AMD bi-processori 1.2 GHz dissipano molto calore. Due 
in una stanza fanno aumentare significativamente la temperatura. 
Mentre potrebbero essere adatte come desktop, il raffreddamento e
il consumo di energia quando le si usa come parte di un grosso
cluster vanno considerati. La configurazione AMD Palmino precedentemente
descritta sembra funzionare veramente bene, ma di sicuro raccomando 
di avere due ventole nell'alloggiamento--questo ha risolto tutti i 
nostri problemi di instabilit&agrave;. </p>

</sect1>

<!-- ************************************************************* -->

<sect1> Problemi software noti <label id="known_software_issues">

<p> Alcuni eseguibili tar a quanto pare non creano un file tar
nel modo che ci si aspetta (specialmente per quanto riguarda il 
riferimento e il de-riferimento dei link simbolici). La soluzione
che ho trovato &egrave; usare un eseguibile tar che funzioni correttamente,
come quello fornito da RedHat 7.0. </p>

</sect1>

<!-- ************************************************************* -->

</sect>

<!-- ************************************************************* -->

<sect> Eseguire task sul cluster

<!-- ************************************************************* -->

<p> Questo paragrafo &egrave; ancora in evoluzione man mano che evolve 
l'utilizzo del cluster, ma finora tendiamo a scrivere insiemi 
proprietari di funzioni message passing per la comunicazione 
dei processi su macchine diverse. </p>

<p> Molte applicazioni, particolarmente nell'area della genomica 
computazionale, sono massivamente e banalmente parallelizzabili, 
vale a dire che si pu&ograve; ottenere una perfetta distribuzione ripartendo
i task equamente tra le macchine (per esempio, quando si analizza
un intero genoma usando una tecnica che opera su un singolo gene/proteina,
ciascun processore in un dato istante pu&ograve; lavorare su un gene/proteina 
indipendente da tutti gli altri processori). </p>

<p> Finora non abbiamo trovato necessario usare un sistema
professionale a code, ma ovviamente dipende fortemente dal 
tipo di applicazioni che si vogliono eseguire. </p>

<!-- ************************************************************* -->

<sect1> Benchmark grossolani

<p> Per l'unico programma pi&ugrave; importante che eseguiamo (il nostro
programma di simulazione <it>ab initio</it> del ripiegamento delle
proteine), utilizzando il processore Pentium 3 a 1 GHz come punto
di riferimento, in media:

<tscreen><verb>
Xeon    1.7 GHz &egrave; circa il 22% pi&ugrave; lento
Athlon  1.2 GHz &egrave; circa il 36% pi&ugrave; veloce
Athlon  1.5 GHz &egrave; circa il 50% pi&ugrave; veloce
Athlon  1.7 GHz &egrave; circa il 63% pi&ugrave; veloce
Xeon    2.4 GHz &egrave; circa il 45% pi&ugrave; veloce
Xeon    2.7 GHz &egrave; circa il 80% pi&ugrave; veloce
Opteron 1.4 GHz &egrave; circa il 70% pi&ugrave; veloce
Opteron 1.6 GHz &egrave; circa il 88% pi&ugrave; veloce
</verb></tscreen>
</p>

<p> S&igrave;, l'Athlon 1.5 GHz &egrave; pi&ugrave; veloce dello Xeon 1.7 GHz poich&eacute; lo
Xeon esegue solo sei istruzioni per clock (IPC) mentre l'Athlon
esegue nove IPC (fate voi i conti!). Comunque questo &egrave; un confronto
assolutamente non rigoroso perch&eacute; gli eseguibili sono stati entrambi compilati
sulle macchine (quindi la qualit&agrave; delle librerie matematiche per esempio
avr&agrave; un suo impatto) e l'hardware di supporto &egrave; diverso. </p>

</sect1>

<!-- ************************************************************* -->

<sect1> Uptime

<p> Queste macchine sono incredibilmente stabili sia in termini di
hardware che di software una volta che sono state debuggate (in genere
qualcuna in un nuovo gruppo di macchine ha problemi hardware), funzionando
costantemente sotto carichi molto pesanti. Di seguito &egrave; dato un esempio.
I reboot sono generalmente avvenuti quando &egrave; scattato un interruttore.

<tscreen><verb>
  2:29pm  per 495 giorni,  1:04,  2 utenti,  carico medio: 4.85, 7.15, 7.72
</verb></tscreen>
</p>

</sect1>

<!-- ************************************************************* -->

</sect>

<!-- ************************************************************* -->

<sect> Ringraziamenti 

<p> Le seguenti persone hanno utilmente contribuito a questo HOWTO:

<itemize>
<item> Michal Guerquin (<htmlurl url="mailto:mikeg@u.washington.edu" name="Michal Guerquin">)
<item> Michael Levitt (<htmlurl url="mailto:michael.levitt@stanford.edu" name="Michael Levitt">)
</itemize>
</p>

</sect>

<!-- ************************************************************* -->

<sect> Bibliografia <label id="references">

<p> I seguenti documenti potrebbero essere utili---sono link a 
progetti che fanno uso di cluster ad alte prestazioni:

<itemize>
<item> <htmlurl url="http://www.ram.org/research/research.html" name="Ram
Samudrala's research page (che descrive il tipo di ricerca fatto con questi cluster)">

<item> <htmlurl url="http://www.ram.org/computing/ramp/ramp.html"
name="RAMP web page">

<item> <htmlurl url="http://www.ram.org/computing/rambin/rambin.html"
name="RAMBIN web page">
</itemize>
</p>

</sect>

<!-- ************************************************************* -->

</article>
