Installazione di un cluster per HPC
con OSCAR e test MPI-openMosix
Domenico Diacono
Workshop CCR INFN – Paestum – Giugno
2003
Argomenti
Hardware e software utilizzati
Installazione del cluster
Test MPI-openMosix con e senza migrazione
dei processi
Beowulf

I nodi sono dedicati al Beowulf.

La rete è interamente dedicata al Beowulf.
I nodi sono computer M2COTS (Mass Market Commodity Off
The Shelf)

La rete si può definire COTS: può non essere “Mass Market”,
ma utilizza il bus PCI


I nodi utilizzano solo software open-source
Il cluster che ne risulta viene usato per High Performance
Computing (HPC), e quindi sui nodi sono installate librerie
parallele

Altri requisiti, non strettamente necessari, sono la presenza di
un nodo gateway e l'uso di Linux come SO

L’obiettivo:
Costruire, senza diventare un “linux
clustering-guru”, nel minor tempo possibile, un
cluster Beowulf per il calcolo parallelo
utilizzabile subito efficacemente da utenti
“seriali”, ed inoltre gestibile ed aggiornabile
facilmente.
Hardware
5 (poi 11) server APPRO 1124S:
Motherboard: Tyan Thunder k7
Processore: 2x Athlon MP 2000+ 1666Mhz
Chipset: AMD 760 MP
RAM: 1 Gb DDR ECC
HDD: 18.1 GB SCSI Ultra 160
CDROM: EIDE Slim
NIC: 2x 10/100 3COM 3C920
Configurazione fisica
Gateway
KVM
Eth100
Switch
KVM
Nodo 1
Nodo 2
Nodo 3
Nodo 4
openMosix
Per rendere facile ed immediato l’uso del cluster per
gli utenti di programmi seriali si è esaminata la
possibilità di usare il kernel openMosix.
OpenMosix è una estensione del kernel Linux, che
nella versione per RedHat può essere applicata
semplicemente installando un pacchetto rpm.
E' costituito da un insieme di algoritmi per la
condivisione adattiva delle risorse di macchine connesse
tra loro con una normale LAN Ethernet.
openMosix: come si usa
Un cluster openMosix è un Single System Image
(SSI) cluster: i nodi non sono visibili, è scalabile, non
bisogna cambiare i programmi.
Ogni utente si collega ad un singolo nodo (il
gateway), e lancia i suoi applicativi. Il sistema si occupa
di far eseguire le applicazioni sui nodi con maggiori
risorse disponibili.
Gli utenti vedono i processi sempre come locali alla
loro macchina (anche se “Sleeping”)
openMosix: come funziona
Nodo 1
Mosix
Network
Protocol
User level
Nodo 2
User level
remote
Processo locale
Link
layer
deputy
Kernel
Kernel
Il deputy contiene la descrizione delle risorse necessarie al
processo e il kernel-stack, il remote contiene il codice, lo user
stack, i dati, i registri e la mappa della memoria del processo.
Requisiti per il software di clustering
Installazione di n macchine da zero con tutto il
software necessario alla piena operatività
Espandibilità immediata
Gestione facile e scalabile
Distribuzione sul gateway aggiornabile
mediante i normali canali (up2date)
Utilizzo dell'hard disk dei nodi
Le (poche) soluzioni esaminate /1
LTSP (Linux Terminal Server Project)
ClusterNFS
Nodi client “leggeri”: le applicazioni sono eseguite sul
gateway. Una modifica del kernel (openMosix) permette di
utilizzare la CPU anche dei client.
Vantaggi: Esiste un solo file system comune a tutti i nodi
client, per ClusterNFS anche al gateway, utilizzato via NFS.
Facile configurazione di più interfacce di rete e di hardware
non omogeneo.
Svantaggi: Per usare i dischi locali è necessario
modificare pesantemente l'installazione standard. La
gestione è per esperti. Installazione minima.
Le (poche) soluzioni esaminate /2
 OSCAR (Open Source Cluster Application
Resource)
Nasce come insieme di software open-source dedicato alla
costruzione ed alla gestione di cluster Beowulf.
Vantaggi: Tutto il software necessario viene installato
automaticamente. E' molto semplice aggiungere nuovi nodi al
cluster e gestire quelli esistenti. I nodi utilizzano il disco locale
per l'area di swap e per il S.O.
Svantaggi: Potenzialmente l’installazione del S.O. su ciascuna
macchina potrebbe aumentare la complessità di gestione. La
configurazione di più NIC per client e di client con differente
hardware non è immediata.
OSCAR /1
Contiene i seguenti software:
System Installation Suite: collezione di programmi open
source progettati per automatizzare l'installazione e la
configurazione di nodi interconnessi.
C3 - The Cluster Command and Control tool suite:
insieme di strumenti a riga di comando per operare dal
gateway sui nodi del cluster.
LAM/MPI – MPICH: due implementazioni MPI opensource.
OSCAR /2
PBS - Portable Batch System: gestore di code batch.
Maui PBS Scheduler: job scheduler per clusters e
supercomputers.
GANGLIA: tool di monitoraggio dello stato del cluster.
Tutti i pacchetti sono precompilati ed integrati in una
procedura di installazione distribuita sotto forma di
tarball, che si preoccupa di installarli e configurarli.
Software
Linux RedHat 7.3 (kernel 2.4.18-18.7.xsmp)
OSCAR 2.1
openMosix (kernel 2.4.18-openmosix-4smp)
LAM/MPI 6.5.7 (rpm di OSCAR, rpi=usysv)
NAS NPB 2.3
Installazione: il gateway
Si parte da una installazione standard di RedHat 7.3: OSCAR infatti
contiene tutto il software di cui ha bisogno. Unica richiesta è che sia presente
un ambiente X come GNOME o KDE.
Durante l’installazione non è necessario preoccuparsi del firewall: OSCAR
usa un suo script, pfilter, che riscriverà le regole di IPTABLES.
E’ importante assegnare un hostname che non sia “localhost”, ed usare una
versione non localizzata.
Non è necessario installare un server tftpd. Bisogna però creare una
directory /tftpboot/rpm nella quale copiare gli rpm della distribuzione, e quindi
lasciare quindi nella partizione /tftpboot almeno 2.5 GB liberi. In /var è
necessario almeno 1 GB.
Si possono scaricare gli update con l’utility up2date, selezionando però le
opzioni che permettono di NON applicare gli rpm scaricati e di salvarli su
disco: in questo modo si possono copiare in /tftpboot/rpm. La loro applicazione
sul gateway è consigliata DOPO l’installazione, forse…
Installazione
> cd oscar-2.1
>./install_cluster eth0
Tutto quel che succede è registrato in
oscarinstall.log
La prima parte dello script esegue:

Creazione delle dir. di OSCAR

Copia degli rpms in /tftpboot/rpm
Installazione degli rmps dei server
(PVM, SIS, NFS, DHCP, LAM, C3)

Aggiornamento dei files di sistema
(hosts, exports, profile, init.d/dhcpd –
ntpd – pfilter – pbs_* – systemimager)


Start dei servizi e del wizard
/1
Installazione /2
Si possono selezionare i pacchetti
da installare, ma dopo l’installazione
non si può cambiare idea.
La configurazione dei pacchetti si
limita a poche opzioni (quale MPI
installare).
L’installazione dei pacchetti server
lancia uno script che installa e
configura gli RPM server.
L’installazione dei client avviene
usando la System Installation Suite, a
partire da una immagine del
filesystem che risiede sul gateway. Il
software in se è molto flessibile, ma in
OSCAR viene usato solo parzialmente
(manca ad esempio l’update dei client
dalla immagine)
Installazione /3
E’ sicuramente necessario
personalizzare il file che definisce le
partizioni del disco dei client.
Durante la costruzione dell’immagine
nella directory
/var/lib/systemimager/images/oscarimage
vengono compiuti i seguenti passi:
●
Installazione degli RPM redhat
●
Installazione degli RPM OSCAR
●
Copia e personalizzazione dei files di
sistema
●
Setup di nfs per montare la directory
/home
●
Generazione delle chiavi ssh
Installazione /4
A questo punto è possibile cambiare il kernel che verrà
installato nei client, intervenendo sulla immagine.
Per installare openMosix bisogna portarsi con un chroot
nella directory della immagine e installare gli rpm, poi
modificare il file /etc/systemconfig/systemconfig.conf
aggiungendo una sezione per il nuovo kernel, infine
modificare il file /etc/mosix.map per renderlo uguale a
quella presente sul gateway.
In via generale un nuovo kernel va installato copiando
bzImage e i moduli e modificando il file systemconfig.conf.
La creazione del ramdisk viene fatta del systemconfigurator.
Installazione /5
La definizione dei client avviene tramite
un dialogo che modifica i files /etc/hosts del
server e della immagine.
Infine un ultimo dialogo permette di:
a. raccogliere i MAC address dei client
b. assegnarli ad uno degli IP prima definiti
c. configurare il dhcp server perché risponda
solo ai client del cluster
d. configurare il boot via PXE o via
Etherboot
Al termine si possono far partire i client
via rete: verranno configurati ed installati
come specificato nell’immagine.
Installazione /6
Cosa accade quando un client viene installato:
1. Dal server dhcp vengono presi IP ed hostname
2. Da /var/lib/systemimager/scripts viene scaricato lo script corrispondente al
nome del client
3. Via rsync si preleva ogni utility eventualmente necessaria
4. Il disco viene partizionato usando sfdisk e le informazioni contenute nella
immagine.
5. Le nuove partizioni vengono montate su /a
6. Il client esegue un chroot /a e via rsync copia tutti i files della immagine
7. Viene eseguito systemconfigurator per adattare l’immagine al particolare
hardware (setup del networking e del bootloader)
8. Infine vengono smontati tutti i filesystems e /a
Installazione /7
Una volta fatti ripartire tutti i client si è giunti alla fine della
installazione: l’ultimo passo consiste nell’eseguire uno script che
chiede il numero di processori ad ogni host ed esegue una serie di
inizializzazioni non meglio definite…
Ogni utente aggiunto sul server d’ora in avanti verrà propagato
automaticamente sui client: OPIUM sincronizza passwd, group,
shadow e gshadow. L’intervallo di sincronizzazione può essere
variato modificando il file /opt/opium/etc/sync_users.conf.
L’aggiunta di nuovi client o l’eliminazione di client esistenti
avviene con una procedura guidata.
The Pros & Cons
Nel giro di 2 ore si ha un cluster SSI pienamente operativo, con MPI,PVM, PBS
e openMosix installati e funzionanti.
Questa comodità si paga con i seguenti difetti, da aggiungere a quelli visti
finora:
• Non è prevista una procedura di gestione degli aggiornamenti di OSCAR.
• Non è possibile tornare sui propri passi e installare/rimuovere un pacchetto.
• In genere i pacchetti sono “Oscarizzati”, quindi il loro aggiornamento non è
proprio immediato.
• Può succedere che l’aggiornamento automatico dei pacchetti rpm di RedHat
(xinetd, python2) introduca problemi nello script di partenza di OSCAR. Il risultato
è che per aggiungere un nuovo client bisogna metter mano allo script o inventarsi
qualcosa
NAS Benchmarks
Ci si è posti un problema: l’uso di openMosix nel cluster avrebbe
comportato problemi agli utenti MPI?
Per provare ad appurarlo si sono usati i benchmark NAS NPB.
Si tratta di 8 programmi, sviluppati dalla Nasa Advanced
Supercomputing Division, nati per misurare le prestazioni di
supercomputer paralleli. I test, derivanti da applicazioni di fluido
dinamica computazionale (CFD), si dividono in cinque kernel-test e 3
pseudo-applicazioni.
Tutti i test sono dotati di timer interno: i valori possono essere
utilizzati per confrontare le prestazioni del cluster al variare della
configurazione, nel caso in esame la presenza o meno di openMosix.
Risultati NAS /1
LU.B.8
2000
Beowulf
openMosix
1000
500
MG.B.8
0
750
1
2
3
4
5
Numero utenti
500
Secondi
Secondi
1500
5 PC biprocessore
250
LAM/MPI 6.5.7 rpm
0
kernel 2.4.18-18.7.xsmp
1
2
3
Numero utenti
kernel 2.4.18-openmosix4smp
4
5
Risultati NAS /2
8 processi
5000
CG.B
tcp
tcp_oM
shared
shared_oM
3000
2000
1000
2500
0
1
2
3
4
2000
5
Numero utenti
11 PC biprocessore
LAM 6.5.9 –with-rpi=usysv o tcp
Secondi
Secondi
4000
1500
1000
500
0
16
kernel 2.4.18-24.7.xsmp
kernel 2.4.20-openmosix2smp
32
64
128
Numero processi
256
Risultati NAS /3
16 processi
4000
BT.B
tcp
tcp_oM
shared
shared_oM
2000
1000
1400
0
1
2
3
4
1200
5
1000
Numero utenti
Secondi
Secondi
3000
11 PC biprocessore
LAM 6.5.9 –with-rpi=usysv o tcp
kernel 2.4.20-openmosix2smp
800
600
400
200
0
16
32
64
128
Numero processi
kernel 2.4.18-24.7.xsmp
256
Risultati NAS /4
Secondi
EP.C.16
800
700
600
500
400
300
200
100
0
tcp
tcp_oM
shared
shared_oM
1
2
3
4
5
Numero utenti
Questo è l’unico test che si avvantaggia della migrazione dei processi MPI
In conclusione…
Dai test effettuati non si può dire una parola
definitiva sul vantaggio che la migrazione
openMosix può apportare al calcolo MPI non
schedulato.
Tutti i test però sembrano concordare sul fatto
che con il kernel openMosix le applicazioni
LAM/MPI che usano la memoria condivisa, e
quindi non migrano, sono più veloci che con il
kernel standard RedHat.
Riferimenti
1. OSCAR e openMosix:
http://openmosix.sourceforge.net
http://oscar.sourceforge.net
2. Due presentazioni dello scorso workshop:
http://www.ts.infn.it/events/ccr2002/talks/esposito1.ppt
http://www.ts.infn.it/events/ccr2002/talks/davini1.ppt
3. Una nota tecnica sulla installazione descritta:
http://www.ba.infn.it/calcolo/documenti/INFN-TC-03-04.pdf