Università degli Studi di Perugia
LAUREA SPECIALISTICA IN INFORMATICA
Prof. Osvaldo Gervasi - A. A. 2007/2008
...
1 Introduzione
1.1 Il problema
Installare un pool di macchine Condor (almeno 3) che utilizzino lo standard Universe e un...
piattaforma è
Piattaforma Compilatore
Red Hat Debian Linux 3.1 gcc co...
3 Configurazione di Condor
3.1 Configurazione del nodo
Per prima cosa abbiamo modificato il file /etc/hosts nel modo segu...
UID_DOMAIN = $(FULL_HOSTNAME)
FILESYSTEM_DOMAIN = $(FULL_HOSTNAME)
CONDOR_IDS = 1001.1001
...
StartIdleTime.
● PREEMPT = ( ((Activity == "Suspended") && ($(ActivityTimer) >
$(MaxSuspendTime))) || (SUSPEND...
Dopodiché abbiamo creato il file di sottomissione come quello seguente
nano nome_file.sub
...
5.3 Sospensione dei job
La sospensione di un job avviene quando l'owner riprende l'utilizzo della macchina su cui esso
vie...
sconfiggere e no. Condor non può impedire violazioni della sicurezza di utenti con privilegi di root
e account di amminist...
of 9

Pool di macchine Condor con utilizzo di Checkpoint Server

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.
Published on: Mar 4, 2016
Published in: Technology      
Source: www.slideshare.net


Transcripts - Pool di macchine Condor con utilizzo di Checkpoint Server

  • 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

Related Documents