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