JOB E TASK

HPC Pack, comunque, non fornisce solo la gestione del cluster, ma anche l’organizzazione delle attività svolte dai nodi di calcolo. Si parla, in questo caso, di

57

job, ossia operazioni più o meno complesse assegnate all’HPC Job Scheduler. Un

job è composto da uno o più task: questi definiscono il flusso di esecuzione in grado di fornire maggiore parallelismo, mediante la definizione di dipendenze tra task. Perché un job sia accodato nello scheduler di HPC, esso deve essere creato a partire da un Job Template. Una volta avviato, dunque, un job viene inserito in una coda: in base alle risorse di calcolo disponibili e alla priorità specifica lo scheduler si occuperà di gestire il flusso concorrente dei vari task e, più in generale, dei job presenti.

In HPC, dunque, un job è identificato da alcune proprietà fondamentali: tra gli altri la priorità (Lowest, BelowNormal, Normal, AboveNormal, Highest) consente di stabilire delle gerarchie nell’esecuzione, diverse impostazioni di notifica e di fallimento, il numero di core, socket e nodi (minimo e massimo) richiesti per l’esecuzione. È naturale, pertanto, che un job sia diviso tra più nodi di calcolo e, quindi, la sua esecuzione sia naturalmente parallelizzabile. Anche i task possono specificare numerose proprietà: in particolare, è possibile indicare anche per essi il numero di core e nodi richiesti, ma vanno specificati anche le dipendenze e i percorsi dei file di input e output. Ciò che indica nel dettaglio l’operazione da eseguire è rappresentato dalla proprietà Command Line, ossia il comando richiesto nel task.

Il ciclo di vita di un job è ben definito da HPC Pack da una serie di stati. Questi stessi sono validi anche per i task.

• Un job è in stato di Submitted se attende di essere validato per essere inserito in coda;

• Dopo una fase transitoria di Validating (consistente in una serie di controlli su permessi e impostazioni), il job è Queued, ossia schedulato e inserito in coda; • La fase di esecuzione è rappresentata da Running;

• Se l’esecuzione è stata portata a termine con successo, lo stato finale è Finished; in caso contrario, si parla di Failed;

• Se per un job, in qualsiasi stato esso si trovi, è richiesta la cancellazione (dall’amministratore del cluster, dallo scheduler o dal job owner), esso andrà in Canceled. [7]

Tra i vari tipi di job paralleli che possono essere eseguiti da un cluster HPC, ve ne sono alcuni estremamente comuni. Tra questi, i MPI Job sono formati da task

58

intrinsecamente paralleli. Solitamente, si tratta di file eseguibili singoli che eseguono su più core in parallelo, garantendo comunicazione tra processi. I task MPI si distinguono per il fatto che la loro Command Line è preceduta da mpiexec.

Un Parametric Sweep Job è formato da un numero arbitrario di istanze della stessa applicazione (o comando singolo) che vengono eseguite in maniera concorrente. Solitamente non è prevista comunicazione tra i task, e i file di input e di output sono organizzati in modo da essere posti in una cartella comune (questo non costituisce comunque un vincolo).

Un Task Flow Job, al contrario, prevede una struttura dei task più complessa e basata su un ordine prestabilito di esecuzione: questo è rappresentato dalle dipendenze espresse, spesso perché un task ha un input che necessita (direttamente o indirettamente) dell’output di un altro task.

Un ultimo tipo di job riguarda l’approccio Service Oriented Architecture (SOA). Esso è realizzato per costruire sistemi distribuiti lascamente accoppiati. In questi modelli, funzionalità distinte sono organizzate in moduli software noti come servizi: essi sono creati in modo da essere quanto più esportabili e accessibili alle altre applicazioni. Il vantaggio principale di questo modello in HPC consiste nell’uso del calcolo distribuito senza la riscrittura di codice di basso livello. Lo scenario prevede un’applicazione client che fornisca mediante interfaccia l’accesso ai vari servizi offerti da HPC; lato server, il job è strutturato in modo da contenere un task chiamato Service (uno per ogni nodo di calcolo impegnato) che comunica con il Broker Node, inviando richieste e ricevendo risposte. [7]

Esistono diversi modi per comunicare con il gestore del cluster e dei job. Se si desidera un modello più automatizzato rispetto all’interfaccia, le API che HPC Pack mette a disposizione possono tornare molto utili: è possibile, infatti, comunicare con l’HPC Scheduler mediante linea di comando o, in alcuni scenari, tramite le API .NET. In particolare, esistono alcuni file eseguibili che possono essere invocati, mediante un’opportuna sintassi che ne definisce i parametri. Tra i più utili vi sono cluscfg (per la configurazione del Job Scheduler, che fornisce gestione di certificati, credenziali, parametri del cluster e sistema di notifica dello stato dei job), clusrun (per l’esecuzione in contemporanea del comando specificato su un insieme configurabili di

59

nodi del cluster), hpcfile (per la gestione dei file nei vari nodi del cluster), hpctrace (che si occupa del logging dei servizi HPC). Inoltre, una serie di comandi permette la manipolazione di job, task, nodi e applicazioni MPI: si tratta dei sottocomandi job,

task, jobtemplate, node, mpiexec.

Lo strumento di gestione del cluster nei suoi vari aspetti in maniera interattiva è rafforzato da una serie di cmdlet di HPC Powershell dalla sintassi estremamente semplificata. Esistono, dunque, comandi per creare, eliminare, avviare, arrestare le risorse di calcolo. È possibile anche ottenere una serie di informazioni circa tutto ciò che è correlato a HPC (job, nodi di calcolo di vario tipo, Node Template e Job Template tra gli altri). Per esempio, in uno scenario come quello che verrà presentato nel prossimo Capitolo, possono essere estremamente utili i comandi Add- HpcNodeSet e Remove-HpcNodeSet. Questi cmdlet, come il nome può suggerire, permettono di creare e rimuovere dal cluster delle istanze di macchina virtuale, delle quali sono specificate informazioni quali quantità, dimensionamento e Node Template. Inoltre, HPC Powershell garantisce il controllo dei job e delle richieste SOA gestire, oltre alla possibilità di importare o esportare Node Template e Job Template. Infine, consente (tra le altre proprietà) la configurazione di AutoGrowShrink con il comando Set-HpcClusterProperty. [7]

60