1. 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

2. 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 Requisiti
Condor è 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 Operativo
Intel 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

3. piattaforma è
Piattaforma Compilatore
Red Hat Debian Linux 3.1 gcc con versione superiore alla 3.4.1
(Sarge) in x86
2.2 Installazione di Condor
Il 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_config
export 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

4. 3 Configurazione di Condor
3.1 Configurazione del nodo
Per prima cosa abbiamo modificato il file /etc/hosts nel modo seguente
127.0.0.1 localhost
192.168.200.44 nodo
192.168.200.45 master
192.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.44
NETWORK_HOST = nodo
FULL_HOSTNAME = nodo
CONDOR_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.1001
DAEMON_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/condor
UID_DOMAIN = $(FULL_HOSTNAME)
FILESYSTEM_DOMAIN = $(FULL_HOSTNAME)
COLLECTOR_NAME = My Pool
FLOCK_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 CM
La 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.45
NETWORK_HOST = master
FULL_HOSTNAME = master
CONDOR_HOST = master
e modificato

5. UID_DOMAIN = $(FULL_HOSTNAME)
FILESYSTEM_DOMAIN = $(FULL_HOSTNAME)
CONDOR_IDS = 1001.1001
DAEMON_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 = master
CKPT_SERVER_LOG = $(LOG)/CkptServerLog
CKPT_SERVER_DIR = /home/condor/condor/ckpt_server_dir
CKPT_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.new
DAEMON_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 policy
Le 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

6. 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 Condor
Eseguita 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
Illustrazione 4.1: Comando condor_status
infine è possibile interrompere l'attività di Condor eseguendo lo script
condor.boot stop
5 Esempi
In 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 job
Innanzi tutto abbiamo creato i sorgenti in linguaggio C dei jobs da sottomettere al nostro cluster.

7. Dopodiché abbiamo creato il file di sottomissione come quello seguente
nano nome_file.sub
Executable = <nome_eseguibile>
Universe = standard
Output = <nome_eseguibile.out>
Error = <nome_eseguibile.err>
Log = <nome_eseguibile.log>
should_transfer_file = YES
when_to_transfer_output = ON_EXIT
queue
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 job
Per 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.
Illustrazione 5.1: Comando condor_submit
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.2: Comando condor_q

8. 5.3 Sospensione dei job
La 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.
Illustrazione 5.3: Sospensione
5.4 Migrazione dei job
La 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.
Illustrazione 5.4: Migrazione
6 Sicurezza
La 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ò

9. 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 Esempi
In 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), nodo
HOSTDENY_ADMINISTRATOR = nodo2
● In questo esempio l'amministratore è solo il CM, “nodo” può sottomettere jobs mentre
“nodo2” no
HOSTALLOW_ADMINISTRATOR = $(CONDOR_HOST)
HOSTALLOW_READ = *
HOSTDENY_WRITE = nodo
HOSTALLOW_WRITE = nodo2