Installazione di un cluster per HPC con OSCAR e test MPI-openMosix Domenico Diacono Workshop CCR...
-
Upload
rosabella-de-marco -
Category
Documents
-
view
216 -
download
1
Transcript of Installazione di un cluster per HPC con OSCAR e test MPI-openMosix Domenico Diacono Workshop CCR...
Installazione di un cluster per HPCInstallazione di un cluster per HPC con OSCAR e test MPI-openMosix con OSCAR e test MPI-openMosix
Domenico DiaconoWorkshop CCR INFN – Paestum – Giugno 2003
ArgomentiArgomenti
Hardware e software utilizzati
Installazione del cluster
Test MPI-openMosix con e senza migrazione dei processi
BeowulfBeowulfI 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:L’obiettivo:
Costruire, senza diventare un ““linux linux clustering-guru”clustering-guru”,, nel minor tempominor tempo possibile, un cluster Beowulf per il calcolo parallelo parallelo utilizzabile subito efficacemente da utenti “serialiseriali”, ed inoltre gestibilegestibile ed aggiornabile facilmentefacilmente..
HardwareHardware
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 fisicaConfigurazione fisica
GatewayGateway
Nodo 1Nodo 1 Nodo 2Nodo 2 Nodo 3Nodo 3 Nodo 4Nodo 4
KVMKVM SwitchSwitchKVM
Eth100
openMosixopenMosix
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 usaopenMosix: 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 funzionaopenMosix: come funziona
Linklayer
User level User level
Kernel Kernel
deputy
remote
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.
MosixNetworkProtocol
Nodo 1 Nodo 2
Processo locale
Requisiti per il software di clusteringRequisiti 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 Le (poche) soluzioni esaminate /1/1
LTSP (Linux Terminal Server Project)LTSP (Linux Terminal Server Project)ClusterNFSClusterNFSNodi 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 Le (poche) soluzioni esaminate /2/2
OSCAR (Open Source Cluster Application OSCAR (Open Source Cluster Application Resource)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 OSCAR /1/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 open-source.
OSCAR OSCAR /2/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.
SoftwareSoftware
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 gatewayInstallazione: il gatewaySi 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 Installazione /1/1
> 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
Installazione Installazione /2/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 Installazione /3/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 Installazione /4/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 Installazione /5/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 Installazione /6/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 Installazione /7/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 & ConsThe 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 BenchmarksNAS 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
0
500
1000
1500
2000
1 2 3 4 5
Numero utenti
Se
co
nd
i
Beowulf
openMosix
5 PC biprocessore
LAM/MPI 6.5.7 rpm
kernel 2.4.18-18.7.xsmp
kernel 2.4.18-openmosix4smp
MG.B.8
0
250
500
750
1 2 3 4 5
Numero utenti
Se
co
nd
i
Risultati NAS Risultati NAS /2/2
0
1000
2000
3000
4000
5000
1 2 3 4 5
Numero utenti
Se
co
nd
i tcp
tcp_oM
shared
shared_oM
CG.BCG.B
0
500
1000
1500
2000
2500
16 32 64 128 256
Numero processi
Se
co
nd
i
11 PC biprocessore
LAM 6.5.9 –with-rpi=usysv o tcp
kernel 2.4.18-24.7.xsmp
kernel 2.4.20-openmosix2smp
8 processi
Risultati NAS Risultati NAS /3/3
0
1000
2000
3000
4000
1 2 3 4 5
Numero utenti
Se
co
nd
i tcp
tcp_oM
shared
shared_oM
BT.BBT.B
0
200
400
600
800
1000
1200
1400
16 32 64 128 256
Numero processi
Se
co
nd
i
11 PC biprocessore
LAM 6.5.9 –with-rpi=usysv o tcp
kernel 2.4.20-openmosix2smp
kernel 2.4.18-24.7.xsmp
16 processi
Risultati NAS Risultati NAS /4/4
EP.C.16
0100200300400500600700800
1 2 3 4 5
Numero utenti
Se
co
nd
i tcp
tcp_oM
shared
shared_oM
Questo è l’unico test che si avvantaggia della migrazione dei processi MPI
In conclusione…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.
RiferimentiRiferimenti
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