Università degli Studi di Perugia

LAUREA SPECIALISTICA IN INFORMATICA

Prof. Osvaldo Gervasi - A. A. 2007/2008

Laboratorio di Sistemi Operativi Avanzati

Progetto:

Pool di macchine Condor con utilizzo di Checkpoint Server

Studenti:

Manfucci Andrea

Ciambelli Davide

1 Introduzione

1.1 Il problema

Installare un pool di macchine Condor (almeno 3) che utilizzino lo standard Universe e un checkpoint server e verificare che, sotto opportune condizioni (es.: l'owner ricomincia a utilizzare la macchina), i job vengono sospesi e migrati e che venga utilizzato il checkpoint server. Verificare inoltre il supporto di Condor per delegare l'amministrazione ad utenti che non siano root e le restrizioni applicabili.

1.2 Che cos'è Condor?

Condor è un sistema batch sviluppato dall'Università del Wisconsin, che consente di implementare High Throughput Computing (HTC). Esso si occupa della gestione del carico computazionale di jobs che richiedono grandi risorse di calcolo. Inoltre fornisce un meccanismo di coda per i jobs, consente la scelta della politica di scheduling e dello schema di priorità e permette la gestione ed il monitoraggio delle risorse. Condor fornisce il controllo completo e costante al proprietario della macchina sull'impatto che un processo di tipo batch può avere sulla qualità del servizio. Inoltre il proprietario ha un controllo totale di chi può accedere alle risorse e di quando e quanto queste possono essere usate. Le condizioni di utilizzo sono definite da regole stabilite dal proprietario: quando una condizione è valida la risorsa può essere utilizzata, quando non lo è più la risorsa viene rilasciata. Diverse regole possono essere stabilite per controllare quando un job può essere eseguito, sospeso, eliminato e risottomesso. Una risorsa può essere facilmente rimossa dal pool in ogni momento. Semplicemente, gli utenti sottomettono i loro jobs paralleli o seriali a Condor, il quale li posiziona in coda, sceglie dove e quando eseguire i jobs basati su una certa politica, e controlla attentamente il loro avanzamento; infine, Condor informa gli utenti del completamento dei jobs.Condor può essere configurato per usare solo le workstations nelle quali sia il mouse che la tastiera sono in uno stato di inattività; nel momento in cui una macchina uscirà dallo stato di idle, Condor produrrà un checkpoint e migrerà il job su un'altra macchina in idle.Ricordiamo che Condor è un software open-source sviluppato dal Condor Research Project e disponibile per più piattaforme assieme ad una dettagliata documentazione.

2 Installazione

2.1 RequisitiCondor è disponibile gratuitamente dal sito http://www.cs.wisc.edu/condor/downloads. Sono disponibili anche distribuzioni binarie di Condor per determinate piattaforme. Una piattaforma è la combinazione architettura/sistema operativo. Dovendo utilizzare lo standard Universe abbiamo dovuto installare la versione 6.8.8 di Condor supportata dalla seguente piattaforma

Architettura Sistema OperativoIntel x86 Debian Sarge Linux 3.1 (usando i

binari RHEL3)

I jobs sottomessi all'universo Standard utilizzano condor_compile per relinkare programmi con librerie messe a disposizione da Condor. Nel nostro caso il compilatore supportato dalla nostra

piattaforma è

Piattaforma CompilatoreRed Hat Debian Linux 3.1 (Sarge) in x86

gcc con versione superiore alla 3.4.1

2.2 Installazione di CondorIl Condor pool che abbiamo realizzato è costituito dalle seguenti macchine:

● un Central Manager (CM) che si occupa del coordinamento del sistema e che funge anche da Checkpoint Server capace di sottomettere ma non di eseguire i jobs;

● due nodi slave capaci di sottomettere ed eseguire i jobs.

Inizialmente abbiamo scaricato la release di Condor

condor-6.8.8-linux-linux-x86-rhel3-dynamic-tar.gz

Una volta scaricato il file abbiamo creato l'utente condor e successivamente abbiamo decompresso il file eseguendo il comando

tar -zxvf condor-6.8.8-linux-linux-x86-rhel3-dynamic-tar.gz

A questo punto ci siamo spostati nella cartella decompressa e abbiamo eseguito lo script di installazione tramite il seguente comando

./condor_configure--install=/home/condor-6.8.8/release.tar--install-dir=/home/condor/condor--local-dir=/home/condor/condor--type=submit,execute,manager--central-manager=master

Al termine dell'installazione abbiamo aggiunto al file .bashrc dell'utente condor i seguenti comandi che servono per esportare le variabili d'ambiente che interessano Condor

export CONDOR_CONFIG=/home/condor/condor/etc/condor_configexport PATH=$PATH:/home/condor/condor/sbin/export PATH=$PATH:/home/condor/condor/bin/export PATH=$PATH:/home/condor/condor/etc/examples/

I processi presenti dopo l'installazione di Condor sono:

● condor_negotiator (solo su CM)

● condor_collector (solo su CM)

● condor_master

● condor_schedd

● condor_startd

● condor_ckpt_server (solo su CM)

● condor_shadow

3 Configurazione di Condor

3.1 Configurazione del nodoPer prima cosa abbiamo modificato il file /etc/hosts nel modo seguente

127.0.0.1 localhost192.168.200.44 nodo192.168.200.45 master192.168.200.46 nodo2

A questo punto è stato necessario modificare il file /home/condor/condor/condor_config.local contenente le impostazioni locali di Condor. In esso abbiamo aggiunto le seguenti macro

NETWORK_INTERFACE = 192.168.200.44NETWORK_HOST = nodoFULL_HOSTNAME = nodoCONDOR_HOST = master

inoltre, sempre nello stesso file, è stato modificato il valore delle seguenti variabili

UID_DOMAIN = $(FULL_HOSTNAME)FILESYSTEM_DOMAIN = $(FULL_HOSTNAME)CONDOR_IDS = 1001.1001DAEMON_LIST = MASTER, SCHEDD, STARTD

A questo punto è stato necessario modificare il file /home/condor/condor/etc/condor_config nel seguente modo

RELEASE_DIR = /home/condor/condorUID_DOMAIN = $(FULL_HOSTNAME)FILESYSTEM_DOMAIN = $(FULL_HOSTNAME)COLLECTOR_NAME = My PoolFLOCK_FROM = *FLOCK_TO = *HOSTALLOW_READ = *HOSTALLOW_WRITE = *

L'ultima operazione necessaria è stata quella di modificare il parametro MASTER nel file /home/condor/condor/etc/examples/condor.boot nel seguente modo

MASTER = /home/condor/condor/sbin/condor_master

3.2 Configurazione del CMLa modifica del file /etc/hosts nel Central Manager è analoga a quella del nodo mentre nel file /home/condor/condor/condor_config.local abbiamo aggiunto

NETWORK_INTERFACE = 192.168.200.45NETWORK_HOST = masterFULL_HOSTNAME = masterCONDOR_HOST = master

e modificato

UID_DOMAIN = $(FULL_HOSTNAME)FILESYSTEM_DOMAIN = $(FULL_HOSTNAME)CONDOR_IDS = 1001.1001DAEMON_LIST = MASTER,SCHEDD,STARTD,COLLECTOR,NEGOTIATOR

La modifica del file /home/condor/condor/etc/condor_config è analoga a quella del nodo così come la modifica del parametro MASTER nel file /home/condor/condor/etc/examples/condor.boot .

3.2.1 Configurazione del Checkpoint Server

Le macchine che svolgono le funzioni di CM e checkpoint server vengono definite nei file di configurazione condor_config e condor_config.local . Pertanto abbiamo modificato il file generale aggiungendo le seguenti macro

CONDOR_HOST = master

CKPT_SERVER_HOST = masterCKPT_SERVER_LOG = $(LOG)/CkptServerLogCKPT_SERVER_DIR = /home/condor/condor/ckpt_server_dirCKPT_SERVER = $(BIN)/condor_ckpt_server

USE_CKPT_SERVER = TRUE

Nel nostro caso CONDOR_HOST e CKPT_SERVER_HOST coincidono in quanto la stessa macchina svolge entrambe le funzioni. La variabile CKPT_SERVER_DIR indica la directory di checkpoint del pool. Nel file di configurazione locale invece, abbiamo modificato il valore delle seguenti macro

MASTER = $(BIN)/condor_master.newDAEMON_LIST=MASTER,SCHEDD,STARTD,COLLECTOR,NEGOTIATOR,CKPT_SERVER

La prima linea specifica la collocazione del binario che sarà eseguito per primo nella formazione del pool. La seconda linea dichiara la serie di processi che vengono attivati per costruire il CM e il checkpoint server; se il CM non funge anche da checkpoint server la stringa CKPT_SERVER non è specificata.

3.3 Configurazione delle policyLe policy sono espressioni booleane definite nei file di configurazione locale di Condor che vengono definite su ogni macchina. Ognuna di queste policy serve per definire le regole da applicare ad un job al verificarsi di determinate condizioni. Nel nostro caso, per quanto riguarda i nodi, abbiamo inserito le seguenti regole

● START = ( (KeyboardIdle > $(StartIdleTime)) && ( $(CPUIdle) || (State != "Unclaimed" && State != "Owner")) )Avvia un job quando il tempo di inattività è maggiore della variabile StartIdleTime e la CPU è in stato di idle oppure quando lo stato è diverso da Unclaimed e da Owner.

● SUSPEND = ( $(KeyboardBusy) || ( (CpuBusyTime > 1 * $(MINUTE)) && $(ActivationTimer) > 90 ) )Sospende il job se la tastiera viene toccata oppure se la CPU è occupata per più di 2 minuti e il job è stato eseguito da più di 90 secondi.

● CONTINUE = ($(CPUIdle) && KeyboardIdle > $(StartIdleTime))Continua il job se la CPU è libera è l'inattività della tastiera è maggiore di

StartIdleTime.● PREEMPT = ( ((Activity == "Suspended") && ($(ActivityTimer) >

$(MaxSuspendTime))) || (SUSPEND && (WANT_SUSPEND == False)) )Acquisisce per prelazione se l'attività è Suspended e il job è stato sospeso da molto tempo oppure se la sospensione non è voluta e la macchina è occupata.

● VACATE = ($(StateTimer) > $(MaxSuspendTime))Richiede l'esecuzione di checkpoint e la migrazione del job su un'altra macchina se tale job è sospeso da MaxSuspendTime.

Per quel che riguarda il CM invece abbiamo applicato le policy di default con la modifica della macro START settata a FALSE. In questo modo il CM assume sempre lo stato di Owner potendo solo sottomettere ma non eseguire i jobs.

4 Avvio di CondorEseguita la configurazione è stato possibile avviare Condor con lo script

condor.boot start

A questo punto, attendendo alcuni secondi per dar tempo ai demoni di partire, sarà possibile visualizzare lo stato di Condor con il comando

condor_status

che produrrà il seguente output

infine è possibile interrompere l'attività di Condor eseguendo lo script

condor.boot stop

5 EsempiIn questa sezione verrà mostrata la sottomissione di alcuni jobs in modo tale da vedere la loro distribuzione, esecuzione, sospensione e migrazione nei nodi del nostro cluster. Ricordiamo che i jobs posso essere sottomessi da tutte e tre le macchine ma solo i due slave possono eseguirli.

5.1 Creazione di un jobInnanzi tutto abbiamo creato i sorgenti in linguaggio C dei jobs da sottomettere al nostro cluster.

Illustrazione 4.1: Comando condor_status

Dopodiché abbiamo creato il file di sottomissione come quello seguente

nano nome_file.subExecutable = <nome_eseguibile>Universe = standardOutput = <nome_eseguibile.out>Error = <nome_eseguibile.err>Log = <nome_eseguibile.log>should_transfer_file = YESwhen_to_transfer_output = ON_EXITqueue

Visto che l'universo utilizzato è lo standard, per permettere la sospensione e la migrazione dei lavori in batch senza che il progresso accumulato su una macchina ospite vada perduto, Condor utilizza una libreria di checkpoint che consente di salvare l'intero stato di esecuzione di un programma prima di interromperlo, per poi riprendere l'esecuzione più tardi, eventualmente su un altra macchina ospite. Per utilizzare questa libreria, i programmi devono essere compilati con il seguente comando

condor_compile gcc -o <nome_eseguibile> nome_file.c

Nell'universo Standard Condor fornisce checkpointing e remote system calls; per preparare un programma per essere eseguito in questo universo si dovrà provvedere al re-link attraverso il comando condor_compile (non è quindi necessario modificare il codice sorgente). Tale universo comunque presenta alcune restrizioni come l’impossibilità di utilizzare shared memory, memory mapped files, interprocess communication e multi-process job. Ora abbiamo tutto quello che ci serve per sottomettere un job al nostro pool.

5.2 Sottomissione di jobPer sottomettere job a Condor si utilizza il comando

condor_submit file.sub

Tramite l'utilizzo di questo comando un job aggiunto finisce in coda e appena una macchina è libera (idle) viene eseguito.

Si può visualizzare a video lo stato della coda con il comando condor_q . Uno o più jobs possono essere eliminati dalla coda utilizzando il comando condor_rm .

Illustrazione 5.1: Comando condor_submit

Illustrazione 5.2: Comando condor_q

5.3 Sospensione dei jobLa sospensione di un job avviene quando l'owner riprende l'utilizzo della macchina su cui esso viene eseguito. In questo modo, tramite il checkpointing, viene salvato lo stato attuale del job che attende la migrazione verso un'altra macchina libera.

5.4 Migrazione dei jobLa migrazione di un job avviene quando quest'ultimo viene riattivato dopo una sospensione. Quando questo accade si cerca una macchina del pool libera e se esiste, l'esecuzione del job riparte esattamente da dove era stata sospesa.

6 SicurezzaLa sicurezza in Condor è un problema ampio, con molti aspetti da prendere in considerazione. Visto che lo scopo principale di Condor è di consentire agli utenti di eseguire codice arbitrario su un gran numero di computer, è importante provare a limitare chi può accedere ad un Condor pool e quali privilegi hanno quando l'utilizzano. C'è una distinzione tra i tipi di attacchi che Condor può

Illustrazione 5.3: Sospensione

Illustrazione 5.4: Migrazione

sconfiggere e no. Condor non può impedire violazioni della sicurezza di utenti con privilegi di root e account di amministrazione. Un esempio di job maligno è un attacco DoS distribuito. Condor assume che gli utenti siano fidati. Condor può impedire l'accesso non autorizzato al Condor pool, e aiuta a garantire che solo gli utenti fidati possano accedere al pool di macchine. Inoltre, Condor fornisce la crittografia e il controllo di integrità, per garantire che i dati non siano stati esaminati o manomessi da altri. Per garantire la sicurezza all'interno di un pool di macchine abbiamo studiato in maniera approfondita l'utilizzo delle macro

● HOSTALLOW_ADMINISTRATOR● HOSTALLOW_READ● HOSTALLOW_WRITE

Queste macro definiscono il supporto di Condor per delegare l'amministrazione, controllare lo stato del pool, controllare lo stato della coda, sottomettere jobs ecc.. ad utenti che non siano amministratori. Viceversa grazie all'utilizzo delle macro

● HOSTDENY_ADMINISTRATOR● HOSTDENY_READ● HOSTDENY_WRITE

è possibile applicare delle restrizioni agli utenti del pool.

6.1 EsempiIn questa sezione presentiamo alcuni esempi di possibili configurazioni utilizzando le macro spiegate in precedenza.

● In questo esempio l'amministrazione, oltre che al CM, viene delegata al nodo “nodo” mentre viene negata a “nodo2”HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST), nodoHOSTDENY_ADMINISTRATOR = nodo2

● In questo esempio l'amministratore è solo il CM, “nodo” può sottomettere jobs mentre “nodo2” noHOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST)HOSTALLOW_READ = *HOSTDENY_WRITE = nodoHOSTALLOW_WRITE = nodo2