WP 3. Deliverable D3

Transcript

1 NICE -DIEE WP 3 Analisi di tecniche e modelli per il brokering di sessioni VDI R.3.1 Report sulle tecnologie di WMS R.3.2 Rilascio di un SRD (System Requirements Document) mirato alla progettazione di modelli e tecnologie di gestione delle sessioni interattive R.3.3 Creazione di un ADD (Architectural Design Document) relativo al sistema per la gestione del ciclo di vita delle sessioni interattive.

2 Indice 1 R.3.1 Report sulle tecnologie di WMS Workload Management System Sun Grid Engine (SGE) Load Sharing Facility (LSF) Portable Batch Systems Professional Edition (PBS Pro) LoadLeveler R.3.2 Rilascio di un SRD (System Requirements Document) mirato alla progettazione di modelli e tecnologie di gestione delle sessioni interattive Contesto Obiettivi Criticità affrontate Attività svolte R.3.3 Creazione di un ADD (Architectural Design Document) relativo al sistema per la gestione del ciclo di vita delle sessioni interattive References

3 1 R.3.1 Report sulle tecnologie di WMS 1.1 Workload Management System Per WMS (Workload Management Systems) si intende un sistemi in grado di gestire il carico di lavoro dal punto di vista computazionale, assegnando quindi risorse di calcolo agli utenti all'interno di un determinato dominio, l'esempio più comune è quello del cluster. L'obiettivo di un WMS è quello di ottenere il miglior utilizzo delle risorse e di massimizzare il throughput del sistema attraverso una efficace gestione delle risorse hardware in funzione di quanto viene assegnato ai job di calcolo richiesti dagli utenti. Questa assegnazione, nota anche come scheduling, prende infatti le decisioni su dove lanciare i job di calcolo degli utenti e quante risorse hardware devono essere allocate. In questo senso, un WMS può essere modularizzato in tre sottosistemi: job management subsystem physical resource management subsystem scheduler and queue subsystem Job Management Subsystem Il JMS (Job Management subsystem) è l'interfaccia per gli utenti che interagiscono con il WMS sia nel momento in cui richiedono risorse tramite la sottomissione dei job, sia quando hanno la necessità di controllare e monitorare il loro job in stato di running. Il JMS si occupa quindi del controllo del lancio dei job e dello stato dei job avviati. Il JMS deve essere anche in grado di gestire diversi tipi di job, da semplici script a job interattivi, job paralleli sviluppati utilizzando MPI, OpenMP, o altri tipi di librerie parallele, array job e job complessi in generale. Le funzionalità fornite da JMS dovrebbero include: Job (Re) Sottomissione Job Alter, Rerun, and Re-queue, event notification Job Status Checking: un job può assumere diversi stati: Submitted, Hold, Run, Done, Suspended, Exit, etc Job Holding/Suspension/Resuming Job Signaling Job (Re)Priorità Job Accounting: Registrare le risorse usate dagli utenti e dai job Job checkpointing, il riavvio e la migrazione a scopo di fault-tolerance e bilanciamento del carico Job Performance: gestione errori e fault Customized Job Starter, Job s Pre-Execution e Post-Execution e per tutte quelle personalizzazioni necessarie, ad esempio, per I job paralleli. Le interfacce utente saranno sempre le medesime per gli utenti, ma il JMS sarà in gradi di riconoscere le differenze tra utente e utente. Inoltre, il JMS supporterà i job file per lo staging-in e lo staging-out. Lo "stage-in" e lo "stage-out" permette all'utente di identificare i file che devono essere trasferiti da e verso le corrette location all interno del sistema informatico nel quale verrà eseguito il job. Lo Stage-in deve avvenire prima che il processo vero e proprio inizi, ma dopo che le risorse disco sono stati istanziate per quel determinato job. Lo Stage-out dovrebbe avvenire dopo la cessazione job, ma prima che le risorse disco vengono rilasciate per la riassegnazione. Physical Resource Management Il PRM (Physical Resource Management) si occupa di due task principali: 3

4 1. Controllare l'utilizzo delle risorse hardware, come i cicli di CPU, la memoria, area di swap, lo spazio su disco e la banda di rete disponibile 2. Riportare e calcolare lo stato e l'utilizzo delle risorse. Il controllo delle risorse riguarda i vincoli e le policy di utilizzo delle risorse. Lo stato e le informazioni di account delle risorse sono utilizzate per lo scheduling eper lo status check da parte degli utenti o degli amministratori di sistema. Per quanto riguarda le informazioni sulle risorse, queste possono essere: informazioni statiche, come il numero di nodi, numero di CPU per nodo, il sistema operativo, lo spazio di memoria condivisa, lo spazio disco disponibile, tipologia di rete, la banda, la latenza, librerie e utilities condivise, il compilatore, JVM, etc. informazioni dinamiche, come ad esempio informazioni sul carico delle risorse, il valore di carico normalizzato, la percentuale di utilizzo della memoria, larghezza di banda disponibile, il valore normalizzato dell'uso delle risorse generali. Scheduler and Queue Systems Nel WMS, l'assegnazione delle risorse deve rispettare determinate policy e criteri di utilizzo delle risorse stesse, queste vengono puntualmente gestite da diversi algoritmi di scheduling particolarmente complessi. Infatti devono essere riconosciuti i confini di dominio, facendo rispettare la sicurezza nel caso in cui la programmazione di alcuni job diventi cross-domain. Nei cluster particolarmente performanti, al fine di migliorare le prestazioni aumentando le risorse hardware, lo scheduler e il sitema di gestioen delle code deve essere in grado di riconoscere l aumento delle prestazioni dovute all inserimento di un hardware speciale, come ad esempio multi-nic sui nodi, networking ad alte prestazioni, nodo multi-core, gerarchia di memoria e cache, e file system paralleli. Queste caratteristiche in grado di percepire il miglioramento e l ampliamento di performance hardware devono essere prese in considerazione nel processo di scheduling delle risorse, al fine di avere il miglior throughput del sistema e, di conseguenza, delle prestazioni delle applicazioni. Un sottosistema di code organizza i job in diversi gruppi. Tale sistema di code ben progettato può ridurre notevolmente il tempo di attesa dei job in coda e di conseguenza il tempo medio di inattività delle risorse di sistema. Le code sono sempre progettate al fine di utilizzare al meglio le risorse hardware e abbinare i diversi tipi di job con le relative risorse hardware favorite. Ad esempio, una coda dove i nodi del cluster sono collegati allo stesso switch di rete, renderanno l esecuzione di un applicazione parallela particolarmente performante, sfruttando la comunicazione intra-switch ad alta velocità; o una coda creata ad hoc per job brevi, oppure job interattivi che hanno bisogno di bassa latenza e quasi real-time; Nel resto di questo deliverable, verranno trattati i WMS più diffusi: SGE, LSF, PBS Pro, e LoadLeveler. 1.2 Sun Grid Engine (SGE) Sun open source Grid Engine è un prodotto migrato nelle Distributed Networked Environment (CO-DINE) / Global Director Resource (GRD), che ha avuto origine però origine in Distributed Queue systems (DQS). SGE rappresenta il passo strategico più importante per Sun verso il mondo del grid computing. Ma ora Sun è di Oracle giusto? Software e architettura In figura 1 viene mostrata l architettura di installazione del demone SGE. L host master con l SGE Qmaster e i demoni SGE schedd rappresentano il server di controllo e il database dell unità amministrativa SGE, che viene 4

5 definita dalla stessa SGE: "cella". Il demone Qmaster SGE contiene i dati più recenti sugli stati dei job, sulle code, sulle risorse, e si occupa anche di rispondere a tutte le richieste che arrivano dai client circa il controllo dei job e delle relative risorse. Il demone scheduler (SGE schedd) gestisce le code dei job e assegna risorse adeguate (host, code) per i job in attesa di essere posti in run. Le policy di scheduling SGE gestiscono la coda secondo l FCFS (First-come, first-served), ma anche in base alle priorità come sharetree. Gli host in esecuzione, che rappresentano le risorse di calcolo-sge, hanno iinstallaot il demone execd sge sia per la gestione dei job sia per gestione delle risorse hardware. SGE Execds si occupa sia di riportare informazioni sul carico delle risorse e sull'esecuzione dei job di daemon all SGE master, ma anche di lanciare i job inoltrati dal SGE Qmaster. Per evitare che Qmaster diventi il collo di bottiglia in caso di fail o errori, un host shadow master ha in esecuzione un demone SGE shadowd che controlla l'host master e avvia una nuova coppia Qmaster-schedd se rileva un fallimento dei demoni o degli host. Una tipica installazione SGE prevede la configurazioni di sistema e il file di database spooling sul file server accessibile dagli host SGE. Figure 1: SGE Installation architecture Mentre SGE Qmaster risponde alle richieste di sottomissione dei job e mette in coda le richiesta degli utenti, l SGE execd è responsabile del lancio dei job e del loro controllo. Inoltre, invece di effettuare il direttamente il fork del job, l SGE execd crea per ogni job un demone SGE shepherd a runtime. Dopo aver impostato l'ambiente di esecuzione del job, l SGE shepherd fa partire il job, e su di esso svolge task di controllo. Quando il job termina, l SGE pastore colleziona gli stati dei job in exit, riporta il tutto all SGE execd e pulisce gli ambienti. L SGE execd svolge anche compiti relativi al controllo delle risorse fisiche hardware, si occupa dell accounting e del monitoraggio. Per segnalare il valore dell esecuzione del carico a runtime, una funzione denominata load sensor recupera nell SGE execd lo stato e il valore di carico effettivo dell host in esecuzione e lo invia di nuovo al execd SGE. Il execd SGE riporta le informazioni ricevute al SGE Qmaster ai fini di scheduling. Scheduling e Gestione delle Code L SGE Schedd si occupa di prendere le decisioni circa l'allocazione delle risorse nell SGE. Dopo aver registrato se stesso con il Qmaster e prima di far partire ogni processo in scheduling, schedd aggiorna i suoi dati interni provenienti dal Qmaster. Questi dati sono strutturati come un lista di eventi consistenti con gli stati delle risorse, con gli holding jobs, con le code, ecc. Per ogni run schedulato, schedd genera un cosiddetto ordine per ogni decisione circa l'assegnazione delle risorse per ogni job, e quindi invia una lista di ordini per Qmaster che effettuerà le azioni necessarie relative a questi ordini. 5

6 Lo scheduler SGE è stato progettato per essere facilmente personalizzato in termini di algoritmi di scheduling all'interno dello stesso SGE. Ma per estendere le feature attuali, in molti casi, è necessario cambiare o migliorare le strutture di dati con i nuovi parametri. I motivi principali sono menzionati nella documentazione interna di SGE schedd: "Questo implica la necessità di amministrare questi nuovi parametri e solitamente risulta necessario modificare le interfacce utente. Per memorizzare le impostazioni di tali nuovi parametri su disco, si rende necessario modificare il formato di file in cui Qmaster e altri componenti memorizzano il loro stato. Cambiando il formato del file, è necessario pensare a come gestire l eventuale migrazione verso un altra installazione Grid Engine." Inoltre, estendere o aggiungere nuovi algoritmi di scheduling deve essere fatto proprio a livello di codice sorgente, non è invece possibile intervenire a livello di API. Questo potrebbe essere considerato un grosso limite in termini di futura estensibilità dello scheduler. C è da dire che lo scheduler SGE di default è molto potente e risulta abbastanza versatile per la maggior parte dei portali di amministrazione. Sono supportati due policy model nell attuale versione di Grid Engine: SGE mode and SGEEE mode. Nella modalità SGE, si cerca di mediare tra la policy FCFS e quella di ordinamento tra gli utenti, si cerca cioè di essere equi in termini di numero di job per ciascun utente. Chiaramente la definizione delle priorità punteranno ad ignorare sia l FCFS che lo user sort. In modalità SGEEE, la priorità di un job è impostata in base a quattro criteri di alto livello: share tree, functional, deadline, and override. 1) Nella policy share tree, i diritti di utilizzo delle risorse ai diversi gruppi e agli utenti è organizzata in una struttura gerarchica ad albero e le foglie dell'albero rappresentano progetti individuali e/o utenti. Ogni sottoalbero (comprese le foglie) ha il diritto di ricevere alcune percentuali di tutte le risorse che la sua radice riceve dal livello superiore. 2) La policy functional considera dei cosiddetti Diritti funzionali che rappresentano una sorta di priorità relativa e sono definite sulla base di attributi funzionali come essere un certo utente o essere associato ad un progetto o ad un certo gruppo di utenti. 3) Nella deadline policy, le priorità dei job cresce automaticamente quando si avvicina la loro scadenza. I tre criteri automatici elencati possono essere sostituiti manualmente tramite la policy di override che consente, per esempio, di raddoppiare la priorità di un singolo job (ma anche di un intero progetto o un utente). E 'anche spesso utilizzato per assegnare un livello costante di priorità ad un utente, ad un gruppo di utenti o ad un progetto. Combinando le quattro policy, vengono assegnati dei ticket ai job e i job con il maggior numero di biglietti sono serviti per primi dallo scheduler. Quindi la policy è basata essenzialmente sulle priorità, ma la priorità stessa può essere modificata in modo dinamico. Lo Schedd riempie code con job nell'ordine del numero di sequenza o in funzione del carico della coda. Il numero di sequenza di una coda è determinato dall amministratore di sistema. Il carico della coda viene rappresentato da una semplice espressione algebrica utilizzata per derivare un valore pesato singolarmente da tutti o parte dei parametri di carico di una coda riportata dall SGE execd per ogni host e da tutti o da parte delle risorse consumabili mantenute da ciascun host. Quindi il carico di una coda è altamente configurabile mediante una espressione algebrica basata sui parametri della coda. Inoltre, viene usato un calendario per specificare i periodi "in servizio" e "fuori servizio" per le code in un qualunque momento della giornata, della settimana o su base annua. Impostando "fuori servizio", nel calendario della coda sui periodi di manutenzione ordinaria implica fermare la coda di job in arrivo. Supporto alle Applicazioni Parallele Al fine di supportare i vari tipi di applicazioni parallele, SGE fornisce un oggetto chiamato parallel environment (PE) che deve essere utilizzato al momento della sottomissione di un job parallel. SGE PE cattura le informazioni sulla quantità di slot di calcolo, sull accesso utente/ gruppo, su eventuali personalizzazioni dell avvio/spegnimento del PE e relativi parametri, fatto ciò alloca uno slot in round robin. L SGE PE inoltre supporta lo scheduler nell allocazione delle risorse per i parallel job. Per quanto riguarda il controllo dei job (in pratica all'avvio e all arresto), SGE integra con comandi client di implementazione del MPI, del PVM e dei modelli multi-thread. Le integrazioni sono script-based e debolmente accoppiate con l SGE PE. In questi 6

7 metodi, il task principale è quello di estrarre dalla lista degli host dei PE quel job che è stato sottomesso e schedulato. Da questa lista di host, saranno lanciati i comandi di ruan dei job (come mpirun). Sono forniti (specialmente per Sun MPI) anche script per altre istruzioni di job control (come ad esempio il suspend e il resume), questi script wrappano i comandi MPI-provided e sono configurati nei relativi campi delle code. Quando l'utente esegue questi comandi di job control, verranno lanciati gli script personalizzati. Sun ha inoltre sviluppato una stretta integrazione tra WMS e Sun Cluster Runtime Environment (CRE), che supporta il lancio, lo stop e il monitoraggio dei processi paralleli, in particolare quelli per Sun MPI. Gli svantaggi di un integrazione poco flessibile sono principalmente due, la prima è che lo scripting varia con in funzione dei differenti modelli di programmazione parallela adottata e non ci sono interfacce uniformi (API) per gli script; il secondo è relativo al monitoraggio, infatti i processi generati sfuggono al controllo e al monitoraggio dello SGE dopo l'avvio di un job. 1.3 Load Sharing Facility (LSF) LSF di Platform Computing (IBM) è un set di prodotti maturi che include LSF, LSF HPC e altri prodotti complementari e supplementari. Nel nostro studio, ci siamo concentriamo su LSF HPC che è più vicino agli intenti del progetto Software e architettura LSF è senza dubbio il sistema di schedulino più complesso per quanto riguarda l'installazione e la configurazione dei demoni come mostrato in Figura 2. Su ciascun server host, sia esso un master host, un execution host o un submission host, devono essere installati almeno quattro demoni LSF: sbatchd, lim, pim, e res. Figure 2: LSF installation architecture 7

8 Lo Sbatchd (Slave Batch Daemon) ed il RES (Remote Execution Server) si occupano di eseguire i task correlati alla gestione dei job; Lo Sbatchd è anche responsabile di far rispettare le policy locali; Il LIM (Load Information Manager) raccoglie il carico dell'host e le informazioni di configurazione e riporta il tutto al master LIM in esecuzione sul host master; IL PIM (Process Information Manager) iniziato dal LIM, raccoglie le informazioni sull'utilizzo delle risorse sui job processati e le riporta allo sbatchd. Sull host master sono installati mbatchd (Master Daemon batch) e Master LIM al fine di controllare le attività globali di gestione e scheduling dell intero sistema. Inizializzatoto dallo sbatched locale, l mbatchd risponde alle richieste degli utenti, gestisce i job in coda, e invia i job agli host relativi come determinato all interno del mbschd, il che rende il decison dello scheduling basato sulle esigenze dei job, sullo stato del carico e sulle risorse e politicy. Il master LIM riceve le informazioni sul carico dal LIMS in esecuzione su ogni server host e inoltra le informazioni all mbschd tramite l mbatchd a supporto delle decisioni di scheduling.oltre all LSF LIM su ciascun server host, può essere installato un External LIM (ELIM) al fine di raccogliere e tenere traccia delle informazioni di carico dinamico personalizzato. ELIM è un eseguibile che può essere uno script o un programma binario. Scheduling e Code In LSF, ci sono due fasi principali nel processo decisionale di assegnazioni di risorse per i job sottomessi: coda e la programmazione. Una volta sottomessi, i job vengono messi e tenuti in una coda specificata dagli utenti o di default del sistema. Gli step necessari per la messa in coda dei job impatta con il tempo di dispacciamento degli stessi job, questo perché LSF tenta di schedulare i per primi i job nella coda con priorità più alta. Le code implementano diverse policy di scheduling e di controllo. Tutti i lavori sottomessi all interno della stessa coda condividono le stesse policy di controllo e di scheduling. Le code non corrispondono ai singoli host; ogni coda può utilizzare tutti gli host server o un sottoinsieme configurato dei server host. Le code hanno i seguenti attributi: Priorità, dove un intero più grande è una priorità superiore Nome, che identifica in modo univoco la coda Limiti della coda, che riducono gli host, il numero job, gli utenti, i gruppi, i Processori, ecc limiti UNIX standard: di memoria, di swap, di processo, di CPU, ecc Policy di scheduling: FCFS, fairshare, preemptive, exclusive Amministratori Condizioni di Run dei job Condizioni di condivisione e di carico Valore UNIX, che stabilisce la priorità di scheduling UNIX Ci sono diverse policy di scheduling in LSF: the simple FCFS, Fairshare scheduling, Deadline and exclusive scheduling, preemptive scheduling, e SLA-driven scheduling. La deadline constraint scheduling in LSF è diversa dalla SGE deadline. La LSF deadline è per code e se un job non può completare il proprio ciclo di vita ll interno di quella deadline, allora il job viene sospeso. Come detto, per SGE la deadline è per il job e se per un job si sta avvicinando la scadenza, il sistema aumenterà la sua priorità in modo che possa essere pianificato per essere eseguito il prima possibile. L exclusive scheduling permette ad un job di utilizzare gli host esclusivamente durante la sua esecuzione. LSF invia il job ad un host che non ha altri job in esecuzione, e non pone più altri job sull host fino a quando il job esclusivo è terminato. La policy di Preemptive scheduling consente ad un job ad alta priorità in attesa, di prendere le risorse da un job in esecuzione di priorità inferiore. Quando abbiamo due job concorrenti per la stessa risorsa, LSF sospende automaticamente il job a bassa priorità per rendere le risorse a disposizione per il job ad alta priorità. Il processo a bassa priorità viene ripreso appena possibile. 8

9 La policy di Fairshare scheduling punta a suddivide la potenza di elaborazione di un cluster tra gli utenti e i gruppi per fornire un accesso equo alle risorse. La FairShare può essere definita sia a livello di coda che a livello di host. Tuttavia, essi sono mutuamente esclusivi ed il queue-level fairshare e l host partition fairshare non potranno essere configurati nello stesso cluster. Se si desidera gestire la priorità di una coda basata sugli utenti in una coda che dipende dalle loro attività in un'altra coda, è necessario utilizzare il cross-queue FairShare oppure l host-level FairShare. Ogni criterio FairShare assegna un numero fisso di quote a ciascun utente o gruppo. Queste azioni rappresentano una frazione delle risorse disponibili nel cluster. Gli utenti più importanti o gruppi sono quelle con il maggior numero di quote. Gli utenti privi di quote non possono eseguire job nella partizione di coda assegnata. La priorità degli utenti è quindi dinamica e dipende dalla quota a loro assegnata e dalle risorse che il loro job ha già utilizzato, possiamo quindi affermare che l'ordine dei job in coda è secondario. La cosa più importante è la priorità dinamica dell'utente che ha sottomesso il job. Quando si utilizza lo schedulino FairShare, LSF cerca di posizionare il primo job nella coda che appartiene all'utente con la priorità dinamica più alta. A questo proposito, LSF FairShare si comporta in maniera simile a quanto avviene nello SGE share-tree. La policy FairShare configurata a livello di host gestisce la richiesta di risorse tra più code. È inoltre possibile definire una policy FairShare diversa per ogni partizione. Se più code utilizzano la medesima partizione, un utente ha la stessa priorità su più code. Una policy FairShare configurata a livello di coda gestisce anche la richiesta di risorse tra gli utenti della stessa coda. È possibile definire una policy FairShare diversa per ogni coda, anche se condividono gli stessi host. La priorità degli utenti viene calcolato separatamente per ogni coda. È possibile inoltre definire una policy FairShare che si applica a diverse code contemporaneamente. Si definisce la policy FairShare per una coda master e per una lista di code slave alle quali si applica la stessa policy; le code slave erediteranno la medesima policy FairShare della coda master. Ai fini dello scheduling dei processi, questo equivale ad avere una coda con un albero di tipo FairShare. In questo modo, se un utente inoltra i job su diverse code, la priorità dello user è calcolata tenendo conto di tutti i job che l'utente ha sottomesso all interno delle sue code. Nella gerarchica FairShare, per entrambe le partizioni della coda e dell host, se i gruppi hanno dei sottogruppi, possono essere configurati ulteriori livelli di quote, con un conseguente albero multi-livello che diventa parte della policy FairShare. Nel sistema di coda basato sulle priorità, una coda di priorità elevata tenta di sottomettere il maggior numero di job prima che le code a priorità più bassa possano sottomettere i loro job. Le code di priorità più bassa vengono bloccate fino a quando la coda di priorità superiore non ha inviato tutti i suoi job. Tuttavia, può capitare di voler dare una sorta di preferenza alle code con priorità inferiore e regolare il flusso dei job in coda. La policy FairShare basata sulle code consente anche di assegnazione degli slot flessibili per dare ad alcune code una priorità alternativa. Ciò consente di organizzare le priorità del proprio lavoro, ottimizzando il numero di job inviati da una coda, in modo che nessuna singola coda monopolizzi le risorse cluster, lasciando le altre code di attesa di poter sottomettere i loro job. È possibile bilanciare la distribuzione job tra le code configurando un certo valore di job in attesa di essere sottomessi da ogni coda. LSF poi tenta di sottomettere una certa percentuale di job da ogni coda, ignorando le priorità, ovvero non tenterà di svuotare i job nella coda a priorità più alta. Se una sola coda nel pollo ha job, quella coda può utilizzare tutte le risorse disponibili e può estendere il suo utilizzo a tutti gli host che sono in grado di lanciare i job. 1.4 Portable Batch Systems Professional Edition (PBS Pro) PBS Pro è la versione commerciale avanzata di PBS, originariamente sviluppato dalla NASA per soddisfare le esigenze di supporto al calcolo parallelo distribuito, che rappresentava la principale lacuna nei Queuing Network Systems (NQS) di prima generazione. Software e architettura Compared with LSF, PBS architecture keeps the minimum necessary daemons in the installation, as shown in Figure 3. On the master host, which is called server host in PBS, only pbs server and pbs sched are installed, responsible for answering user request and scheduling. On the execution host, pbs mom is the only daemon taking care of job launching, enforcement of site policies and managing physical resources. 9

10 Rispetto ad LSF, l architettura PBS considera il numero minimo di demoni necessari, come mostrato in Figura 3. Sull host master, chiamato in PBS server host, sono installati solamente server PBS e sched PBSi, responsabili nel soddisfare le richieste degli utente e dello scheduling. Nell execution host il pbs mom è l'unico demone che si prende cura di lanciare i job, di applicare le policy e di gestire le risorse fisiche. Figure 3: PBS Pro Installation Architecture Scheduling e Code Il PBS Pro supporta tutte le policy di scheduling più diffuse, come la FIFO, quella basata sulle priorità degli utenti o dei gruppi, la FairShare, e la preemptive and backfilling. Di default i job nelle code a più alta priorità saranno presi in considerazione per l'esecuzione prima di quelli nelle code a priorità più bassa; ma è comunque possibile configurare una gestione alla round robin nel quale viene gestita una rotazione in funzione della quale viene eseguito un lavoro da ciascuna coda. Ci sono due tipi di code, il routing e l execution. Una coda di routing viene utilizzata per spostare i job tra le code, comprese quelle che esistono su server PBS differenti. Affincè un job possa essere messo in stato di run, deve risiedere in una coda di tipo excution e deve rimanere in tale coda durante tutto il tempo di esecuzione. 1.5 LoadLeveler Il LoadLeveler è stato originariamente sviluppato per sfruttare al meglio le workstation che sono tipicamente inattive per gran parte del tempo quando non vengono utilizzate. Il LoadLeveler è un gestore delle risorse su misura per sistemi IBM SMP e cluster e può essere installato sull IBM AIX, anche su Linux alcune restrizioni. Il LoadLeveler si integra con tanti moduli di basso livello di AIX, come l AIX Workload Manager (WLM), l AIX punti di checkpointing/restarting al fine di fornire un grado controllo più granulare delle risorse rispetto ai sistemi IBM. Software e installazione L'architettura di LoadLeveler è leggermente differente ed è relativamente più scalabile rispetto ad altri sistemi, vedi Figura 4. Il demone principale chiamato LoadLeveler (LoadL master) è in esecuzione su ogni execution host e gestisce i demoni. In effetti non è il vero "master" dato che in altre WMS svolge il ruolo di manager centrale e risponde alle richieste degli utenti. Ma sull'host designato come central manager, il master esegue il demone negoziatore, che è il vero "master" che gestisce i dati generali del sistema e imposta le policy e di scheduling globale. Un altro demone che può essere confuso con il corrispondente in altre WMSs è il demone 10

11 scheduler (LoadL schedd). Il LoadL schedd può essere configurato per funzionare su qualsiasi execution host. Invece di eseguire I task di allocazione delle risorse, Il LoadL schedd risponde alle richieste di sottomissione dei job degli utenti e le inoltra al negoziatore (LoadL negotiator) sull'host central manager, che rappresenta il vero decision-maker circa l'allocazione delle risorse. Il negoziatore si occupa anche della raccolta delle informazioni sulle risorse utilizzate per lo scheduling. Il LoadL schedd può essere configurato su più execution host al fine di rispondere alle richieste degli utenti e alle code di job sottomessi. Questi meccanismi sono molto utili per i negoziatori e sono molto scalabili perchè distribuiscono i task di sistema e rispondono alle richiesta di diversi demoni. Lo scheduler LoadLeveler e i sistemi di code Il LoadLeveler usa il termine "class" al posto di code per gli utenti che devono sottomettere job. Viene utilizzato il termine job class per gestire diversi tipi di job. Ad esempio, una class creata per brevi job in esecuzione o per job che richiedono rapido tempo di risposta. L'amministratore di sistema può definire queste job class e selezionare gli utenti che sono autorizzati a sottomettere job all interno di queste classi. La gestione della coda è implementata internamente, una coda di job è un elenco di job in attesa di essere processato. Quando un utente invia un job al LoadLeveler, il job viene inserito in un database interno, che risiede su una delle macchine del cluster LoadLeveler fino a quando è pronto per essere inviato per essere sottomesso su un'altra macchina. Il LoadLeveler supporta tre scheduler interni: lo scheduler di default (LL DI DEFAULT), lo scheduler BACK-FILL, e lo scheduler GANG. Inoltre, il LoadLeveler fornisce un'api funzionale in modo da poter utilizzare anche uno scheduler esterno. Attualmente, lo scheduler Maui scheduler è perfettamente integrato. Lo scheduler di default: LL DEFAULT, è disponibile da quando il prodotto è stato introdotto per la prima volta sul mercato. Per i job seriali, il LoadLeveler vede semplicemente i job in cima alla coda, e se c'è un nodo disponibile che soddisfi tutti i requisiti supplementari, il job verrà eseguito. Per job paralleli, lo scheduler di default cerca di accumulare risorse sufficienti per lanciarlo, riservando le risorse disponibili e le nuove appena rilasciate. Il tempo necessario affinchè il job possa riservare nodi è un parametro configurabile, questo per assicurarsi che le risorse inattive non siano tenute troppo a lungo inutilizzate per job particolarmente esigenti. Ci sono due principali svantaggi in questa gestione. In primo luogo, pian piano che sempre più nodi vengono riservati per un job parallelo, il sistema nel suo insieme diventa progressivamente meno utilizzato. E in secondo luogo, i lavori paralleli spesso non riescono ad accumulare abbastanza nodi all'interno del tempo consentito. Lo scheduler Backfill fornisce i mezzi per riempire i cicli di inattività delle risorse riservate da job paralleli e quindi elimina gli svantaggi dello scheduler di default. Nella gestione dei job paralleli, cerca di guardare avanti e determinare (se possibile) il momento in cui le risorse necessarie saranno disponibili, lo scheduler Backfill calcola quindi quanto tempo e attuali risorse disponibili, che saranno inattive prima che vengano utilizzate nei job. Lo scheduler cerca quindi piccoli job che terminino entro il periodo di inattività calcolato, e quindi vengono sottomessi al fine di riempire queste risorse inutilizzate. Per contribuire a questa previsione, i job dovrebbero fornire il tempo limite della loro esecuzione, che rappresenta una delle principali differenze tra lo scheduler Backfill e quello LL DEFAULT dal punto di vista degli utenti. Lo Scheduler GANG consente a due o più job di essere contemporaneamente attivi su un nodo e durante l'esecuzione i job si possono scambiare da intervalli regolari. Nel caso di un processo parallelo, lo swith tra i task viene coordinata nel cluster. Il numero di colonne è determinato dal numero di processori sotto il controllo dello scheduler GANG. The GANG scheduling was first introduced in production system like LoadLeveler. The GANG Scheduler uses a two-dimensional GANG matrix where columns represent processors, and rows represent time slices. The interval of the time slice is set by the LoadLeveler administrator to be the minimum length of execution for jobs such that the overhead of context switch does not significantly impact the overall system performance. La Scheduler GANG è stato introdotto per primo in produzione come il LoadLeveler. Lo Scheduler GANG utilizza una matrice bidimensionale in cui le colonne rappresentano i processori e le righe rappresentano gli 11

12 intervalli di tempo. L'intervallo di tempo è impostato dall'amministratore del LoadLeveler per avere una durata di esecuzione minima per i job in modo tale che il sovraccarico non influisca in modo significativo sulle prestazioni complessive del sistema. 12

13 2 R.3.2 Rilascio di un SRD (System Requirements Document) mirato alla progettazione di modelli e tecnologie di gestione delle sessioni interattive 2.1 Contesto La costante evoluzione del mercato ICT e la nascita di tecnologie e piattaforme per la virtualizzazione di infrastrutture e servizi di calcolo hanno portato sempre di più all affermazione del modello del Computing Center e, con la virtualizzazione, del modello di Cloud con la centralizzazione delle risorse. In questo paradigma le risorse di calcolo, in termini di hardware, workstation di calcolo o grafiche, e software, applicazioni che possono richiedere licenze molto costose, vengono aggregate e gestite centralmente. I vantaggi di questo approccio sono numerosi e vanno dalla maggior efficienza nell utilizzo delle risorse stesse e nell accesso a dati e applicazioni, ottimizzando ad esempio l uso delle licenze, alla più efficiente manutenibilità dell infrastruttura, alla possibilità di imporre centralmente politiche di utilizzo e gestione, ecc. In questo contesto gli utenti non lavorano più solamente su una loro workstation personale ma si rivolgono all infrastruttura per richiedere disponibilità di calcolo sottomettendo job di tipo batch oppure per richiedere una piattaforma di lavoro che soddisfi determinati requisiti di sistema operativo, applicazioni e altro, per attività di tipo interattivo. Gli ambienti di calcolo ad alte prestazioni (HPC) che seguono questo approccio costituiscono l ambito in cui NICE opera come fornitore di soluzioni avanzate, attraverso lo sviluppo di prodotti software e l integrazione con le tecnologie dei clienti. Considerando le attività di tipo interattivo oggetto del progetto, NICE, dopo un analisi dello stato dell arte tecnologico di soluzioni commerciali ed open source, ha indagato e studiato la possibilità di realizzare e offrire una soluzione tecnologica per poter fornire agli utenti dei servizi di alto livello per la richiesta di piattaforme di lavoro, ovvero sessioni interattive. Con il termine di sessione interattiva si intende un ambiente di lavoro richiesto dall utente che comprende un sistema operativo, Linux o Windows, ed eventualmente una determinata applicazione o insieme di applicazioni. Si definisce come schedulatore di sessioni, il sistema in grado di soddisfare le richieste degli utenti individuando e allocando le risorse adeguate e in grado di monitorare e gestire l insieme delle risorse disponibili e delle sessioni interattive precedentemente attivate. Parlando di schedulatori di sessioni, mentre per ambienti Linux sono già presenti tecnologie che NICE è in grado di adattare allo scopo, DA INTEGRARE, si è individuata invece una lacuna tecnologica per quanto riguarda gli ambienti con cluster di macchine con sistema operativo Windows. Lo studio si è rivolto quindi alla formulazione, progettazione e realizzazione di uno schedulatore di sessioni interattive per cluster di macchine Windows, che fosse efficiente, dinamico, scalabile, affidabile e facile da gestire, quindi senza richiedere un esperienza specifica nel campo delle tecnologie per l HPC. 2.2 Obiettivi Il progetto ha permesso la progettazione e la realizzazione dello schedulatore di sessioni interattive su cluster Windows. Gli obiettivi fissati si possono distinguere in funzionali e non funzionali. Le funzionalità e le caratteristiche messe di seguito tra gli obiettivi sono state realizzate nel corso del progetto. 13

14 Obiettivi funzionali Con obiettivi funzionali si intendono le funzionalità fornite dal sistema. Monitorare lo stato delle risorse che compongono il cluster Windows o Elencare le macchine presenti nel cluster con informazioni che sommarizzano lo stato di ogni macchina, ad esempio se può o meno ricevere task o sessioni. o Per ogni macchina avere la possibilità di richiedere ulteriori dettagli sulle risorse quali: numero di cpu/core, quantità di memoria, software installati, attività schedulate sul nodo, se vi sono utenti loggati, ecc. Selezionare ed allocare macchine Windows per sessioni interattive, in modo che soddisfino i requisiti di risorse espressi dal client che ne ha fatto richiesta o I requisiti possono esprimere caratteristiche hardware (ad es. la presenza di una certa quantità di memoria o di una determinata GPU), software (la presenza di un applicazione) o altre caratteristiche della macchina quali ad esempio la presenza o meno di utenti connessi, ecc. Monitorare e gestire le sessioni sottomesse. o I task relativi alle sessioni espongono uno stato che esprime se la sessione è attiva, oppure terminata. o Deve essere possibile controllare il ciclo di vita di una sessione e permettere la sua interruzione e terminazione. Tracciare la sottomissione e le informazioni delle sessioni su un supporto persistente ed essere in grado di ricostruire lo stato del cluster al riavvio del sistema. Supportare almeno due profili di utenza, l utente normale in grado di richiedere sessioni interattive e visualizzare le sue sessioni attive e un utente amministratore in grado di visualizzare e gestire tutte le sessioni presenti nel sistema. Obiettivi non funzionali Tra gli obiettivi non funzionali si menzionano le caratteristiche che deve avere il sistema. Il sistema deve essere in grado di supportare un cluster elastico in cui le macchine possono essere aggiunte o tolte dinamicamente. Il sistema deve essere in grado di scalare su cluster con centinaia e migliaia di nodi. Deve avere il più basso impatto possibile per gli amministratori del cluster, ovvero non richiedere attività di manutenzione dopo l installazione ed avere una gestione semplice. Deve offrire la possibilità di essere configurato in alta affidabilità garantendo resistenza ai guasti ed evitando di avere un singolo componente dal quale tutto il sistema dipende. 2.3 Criticità affrontate Le criticità affrontate nel corso della attività di RI e SS si possono riassumere nei seguenti punti Definizione del protocollo di comunicazione tra i Master e gli Agent. Il protocollo tiene conto della caratteristiche di dinamicità ed elasticità del sistema, quindi adattando il comportamento in modo automatico allo scalare dell infrastruttura del cluster. Nelle interazioni tra Master e Agent si è inoltre tenuto conto di eventuali errori nella comunicazione ed eventuali disallineamenti di informazioni tra Master e Agent. La messa a punto della tecnologia di condivisione dei dati tra i Master e la loro persistenza ha richiesto un iniziale sforzo di scouting tecnologico, prototipazione e testing per verificare che la tecnologia potesse essere adatta agli obiettivi desiderati. In particolare agli obiettivi di condivisione di dati tra processi diversi su macchine diverse e la fault-tolerance dei dati persistiti evitando di avere un single- 14

15 point-of-failure nel sistema. C è inoltre l aspetto di astrazione rispetto alla tecnologia di basso livello utilizzata. La definizione dei task con la scrittura degli script per il setup e la gestione del ciclo di vita di una sessione interattiva ha richiesto vari passi di raffinamento successivi. Le difficoltà incontrate sono derivate principalmente dall affrontare i molteplici scenari a cui può dar origine l utente nell interazione col sistema. Altro elemento di difficoltà è stato rendere queste procedure valide per le diverse versioni del sistema Windows supportate: XP, 7, Server 2008, Server 2012, 32 e 64 bit. 2.4 Attività svolte Volendo fare un summary delle attività svolte per lo sviluppo del broker vdi possiamo elencare: Design del sistema con identificazione dei componenti principali Master e Agent e definizione di ruoli e funzionalità Studio e prototipazione delle tecnologie a servizio dei componenti da sviluppare Progettazione e sviluppo del bus di comunicazione e del protocollo di messaggi utilizzato tra Master e Agent Design e definizione dell XML per la scrittura della definizione di un task Lato Master - Progettazione e sviluppo del componente per la persistenza della definizione dei task Lato Master - Progettazione e sviluppo del componente per la persistenza dei dati sui task, integrazione con tecnologie di terze parti Lato Master - Design ed implementazione del sistema di definizione e valutazione dei predicati per esprimere requisiti che deve soddisfare un nodo per poter eseguire un task Lato Agent, sviluppo del sistema di estrazione delle informazioni statiche (numero di CPU/cores, quantità di memoria, ecc.) e dinamiche (percentuale di CPU utilizzata, quantità di memoria utilizzata, ecc) e comunicazione delle informazioni al Master Lato Agent, sviluppo del sistema di gestione dei task e dei processi nativi generati Consolidamento del codice del Master e dell Agent Implementazione di una infrastruttura di logging sia lato Master che Agent Implementazione dei task per la sottomissione di sessioni interattive che fanno uso delle tecnologie VNC e RGS per la remotizzazione del Desktop utente Sviluppo di una libreria client per interagire con il sistema creato Sulla base della libreria client, sviluppo di un applicazione shell per permettere un interazione command-line con il sistema Implementazione di due diverse applicazioni per installare i componenti Master e Agent Implementazione del sistema automatico di build e pacchettizzazione dei componenti software 15

16 3 R.3.3 Creazione di un ADD (Architectural Design Document) relativo al sistema per la gestione del ciclo di vita delle sessioni interattive Ad inizio progetto avevamo solo un idea di tecnologia da realizzare, ovvero l ìdea di un componente software per schedulare sessioni interattive e più genericamente di attività/task su un cluster di macchine Windows. A valle di uno studio delle tecnologie e consci delle richieste e delle esigenze da una parte dei clienti, in termini di requisiti di alto livello funzionali e non, e dall altra da NICE stessa, in termini di requisiti tecnologici, si è formulato una prima istanza di progetto. L architettura che pi si è implementata è la seguente Come si evidenzia dalle immagini, l architettura del sistema è costituita da diversi componenti software tutti sviluppati nel prototipo finale: Master: è il componente responsabile di ricevere e servire le richieste provenienti dai client. Raccoglie inoltre le informazioni dagli Agent presenti in ogni nodo del cluster. E possibile installare più istanze del Master sui nodi di front-end offrendo quindi un infrastruttura con caratteristiche di bilanciamento di carico e resistenza ai guasti. Agent: è il software installato su ogni nodo del cluster Windows. E responsabile di ricevere e servire le richieste dei Master, di raccogliere inoltre le informazioni dinamiche sullo stato del nodo e dei task che vi girano e di inviarle ai Master in modo asincrono. Sistema di persistenza delle informazioni: responsabile di salvare in modo persistente i dati rilevanti del sistema: la definizione dei task che possono essere sottomessi, i dati relativi ai task già sottomessi. L infrastruttura è stata progettata e realizzata per essere elastica, ovvero avere la capacità di adattarsi dinamicamente ai cambiamenti del cluster. Un Agent alla partenza si annuncia al Master e il nodo su cui gira 16

17 diventa automaticamente parte del cluster senza ulteriori interventi umani. Analogamente se un nodo viene spento, per esempio per manutenzione, dopo qualche istante sparirà dalla lista delle macchine disponibili nel cluster e il sistema si comporterà di conseguenza ai cambiamenti. Il tutto è stato realizzato in modo da schedulare attività (chiamate task, in genere degli script Windows) generiche, e di consentirne il monitoraggio e la gestione durante tutto il ciclo di vita. Le sessioni interattive sono quindi diventate dei particolari task che vengono eseguiti sui vari nodi del cluster. Particolare attenzione si è posto alla tecnologia di condivisione dei dati tra i Master e la loro persistenza. Questo componente di gestione dei dati da un lato assicura che tutti i Master possano accedere in ogni momento agli stessi dati, quindi data-sharing, e dall altro si cura anche degli aspetti di fault-tolerance garantendo che anche in caso di caduta di uno o più Master quello o quelli rimasti siano in grado di tenere in vita e far funzionare il sistema, evitando così di avere un singolo punto di criticità, cha farebbe fallire l intero sistema (single-point-offailure). Un'altra caratteristica del componente per la persistenza dei dati è quella di avere uno strato di astrazione rispetto alla tecnologia utilizzata per persistere i dati in modo distribuito. 17

18 4 References [1] Altair Grid Technologies. OpenPBS: Open Portable Batch System. [2] Altair Grid Technologies. PBS Pro: Portable Batch System Professional Edition. [3] Mark Baker, Geoffrey Fox, and Hon Yau. Cluster Computing Review. Technical Report SCCS- 748, Northeast Parallel Architecture Center, Syracuse University, USA, November [4] Chansup Byun, Christopher Duncan, and Stephanie Burks. A Comparison of Job Management Systems in Supporting HPC ClusterTools. In Technical Forum of Sun Users Performance Group-SUPerG, Fall [5] Sun Microsystems. Sun HPC ClusterTools 5 Software. [6] Platform Computing. Platform Load Sharing Facility (LSF). 18