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 M 2 COTS (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: “linux clustering-guru”, minor tempo parallelo serialigestibile facilmente. 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 Mhz 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 Nodo 1 Nodo 2 Nodo 3 Nodo 4 KVM Switch KVM Eth100

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 Link layer User level 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. Mosix Network Protocol Nodo 1Nodo 2 Processo locale

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 open- source.

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 xsmp) OSCAR 2.1 openMosix (kernel openmosix-4smp) LAM/MPI (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 /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 /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 5 PC biprocessore LAM/MPI rpm kernel xsmp kernel openmosix4smp

Risultati NAS /2 CG.B 11 PC biprocessore LAM –with-rpi=usysv o tcp kernel xsmp kernel openmosix2smp 8 processi

Risultati NAS /3 BT.B 11 PC biprocessore LAM –with-rpi=usysv o tcp kernel openmosix2smp kernel xsmp 16 processi

Risultati NAS /4 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: Due presentazioni dello scorso workshop: Una nota tecnica sulla installazione descritta: