Requisiti dellapplicazione per il resource brokering su Grid

Particolare rilevanza hanno i requisiti di performance che possono essere catalogati in prima approssimazione come segue Compute related – da questo punto di vista la grandezza di riferimento è la potenza di calcolo. Tuttavia i requisiti di applicazioni diverse possono essere differenti, privilegiando ad esempio la velocità di calcolo o chiedendo di ottimizzare il rapporto costo/prestazioni ed altro. Di particolare rilevanza è la necessità di considerare la disponibilità di risorse eterogenee

Requisiti dellapplicazione per il resource brokering su Grid Data related – Per quanto riguarda i dati i requisiti riguardano loccupazione di memoria ai diversi livelli della gerarchia (ram, disco, …), la distribuzione dei dati e laccesso a dati distribuiti in modo trasparente, lesigenza di trasferire grandi quantità di dati tra diversi moduli dellapplicazione (es. DB simulatore visualizzatore), la necessità di avere informazioni sul contenuto dei dati (metadati), la possibilità di replicare i dati per ragioni di fault tolerance e performance Network related – I requisiti relativi alla rete riguardano principalmente la banda di comunicazione e la latenza (quindi la velocità) e laffidabilità delle comunicazioni e del trasferimento dati. In alcuni casi (ad esempio applicazioni real time e communication intensive) possono richiedere un servizio di brokering con capacità di gestione della qualità del servizio (QoS). Possibili problemi possono derivare dallutilizzo di sistemi di protezione locali, quali ad esempio firewall.

Requisiti dellapplicazione per il resource brokering su Grid Problemi Aperti Esistono diversi problemi aperti per quanto riguarda la gestione dei requisiti di un applicazione ed il resource brokering Application Deployement - il problema principale consiste nella definizione di un descrittore che sia in grado di individuare i requisiti dellapplicazione (tipo di processore, quantità di memoria, sistema operativo, necessità di compilazione …) in modo standard permettendo lutilizzo dellapplicazione in ambienti e contesti differenti. E da notare come molti requisiti relativi al deployement possono avere un impatto sulle performance. Ad esempio la necessità di ricompilare il codice può rappresentare un overhead in alcuni casi molto pesante (vedi il caso di Cactus in cui un codice può richiedere da pochi minuti (su alcune macchine) ad alcune ore (su altre) per essere compilato). Un aspetto molto importante per lo sviluppo di applicazioni efficienti è la loro portabilità. Questo problema è ancora aperto soprattutto se considerato dal punto di vista delle prestazioni e per applicazioni parallele.

Problemi Aperti Metacomputing – la piena utilizzabilità delle tecniche di metacomputing è per il momento parzialmente limitata dalla scarsa disponibilità di strumenti di programmazione ampiamente accettati (MPICH-G2). Nel momento in cui il metacomputing, inteso come distribuzione di unapplicazione parallela su diversi cluster di domini differenti, avrà una maggiore diffusione lo scheduler si troverà ad affrontare notevoli problemi di co-allocazione di nodi appartenenti a domini diversi e banda di comunicazione. Predicting performance – la capacità di fornire una stima delle performance di unapplicazione su un certo insieme di risorse, può facilitare di molto lo sviluppo di adeguati sistemi di brokering. Tale capacità si basa su tre tecniche di riferimento: –Approccio teorico basato su modello di costo per lapplicazione –Utilizzo di dati storici –Utilizzo di test case Adaptive Brokering – le condizioni di elevata dinamicità del contesto e delle applicazioni rendono molto importante lutilizzo di una politica adattiva

Organizzazione a livelli e attributi per la comunicazione tra le diverse istanze del Grid Scheduling Risorse in ambiente multidominio con politiche di gestione locali Architettura a più livelli Higher level scheduling instances closer to the user Queries Confirmations Attributes to describe features of heterogeneous resources Lower level scheduling instances closer to the resource (heterogeneity) LSF, PBS LoadLeveler, Maui/Silver, Condor

Attributi per la comunicazione tra le diverse istanze del Grid Scheduling Gli attributi considerati possono essere classificati in 4 gruppi: Per accedere alle informazioni di scheduling disponibili Per la richiesta di risorse Per la richiesta delle proprietà di allocazione Per la modifica dellallocazione

Un esempio di applicazione Clusters Data Base Visualization cave Bandwidth broker DataData transfer processing Visualize Guaranteed completion time Advanced reservation for exclusive allocation and run to completion Concurrent access Temptative schedule e coallocazione di risorse Workflow 1 2 3

Accesso alle informazioni di scheduling disponibili Definiamo come allocazione lassegnazione di risorse ad una richiesta, allocazione di tentativo è unallocazione prima del effettivo uso della risorsa; Una schedulazione (schedule) fornisce informazioni sulle allocazioni previste e/o garantite (unallocazione garantita prevede lassegnazione garantita di risorse ma non implica il completamento del job a cui le risorse sono assegnate) Un primo gruppo di attributi considera informazioni sullo scheduling locale che sono rese disponibili a livello più alto, queste informazioni riflettono e le differenze tra gli scheduler locali e possono essere: –non completamente certe (tentative schedule), nel caso in cui lo scheduler locale non abbia il completo controllo delle risorse gestite –certe (exclusive control), –riguardare eventi inattesi (event notification)

Richiesta di risorse Le differenze tra gli scheduler locali riguardano anche il tipo di informazioni che questi richiedono / producono a fronte di una richiesta di risorse Offerte di allocazione Il manager locale può generare delle offerte di allocazione e il Grid scheduler sceglie fra queste quella più indicata al problema che sta trattando. Costo di allocazione Il manager locale può generare informazioni di costo per una certa allocazione e il Grid scheduler sceglie fra queste quella più indicata al problema che sta trattando.

Richiesta di risorse Advanced reservation E molto importante quando si deve effettuare uno scheduling multi-stage e/o multi-site (Advanced reservation API GGF QoS of Grid resources) Maximum allocation length per ragioni di efficienzalo scheduler locale può richiedere informazioni sulla massima allocazione di tempo relativa ad un job (non mi è chiaro se per time slice o completion)

Richiesta di risorse De-allocazione Alcuni sistemi di gestione locale comprendono politiche di de-allocazione di una richiesta, ad esempio nel caso in cui i requisiti della richiesta e la sua validità non siano confermati periodicamente. Co-scheduling Uno scheduler locale può in alcuni casi delegare ad unistanza di scheduler più alta la gestione (almeno parziale) delle risorse. Questo permette al Grid scheduler di coordinare le azioni di scheduling su diversi siti. Dipendenze tra i job In casi di job complessi esistono dipendenze tra questi che devono essere tenute in considerazione sia a livello di scheduling globale che locale.

Proprietà dell allocazione Lallocazione delle risorse può essere differente per quanto riguarda il tempo e laffidabilità; ad esempio lallocazione di un job multi-stage multi-site deve essere affidabile. Per questa ragione si descrivono le proprietà di unallocazione. Revoca di unallocazione: il propietario di una risorsa può permetterne luso sulla Grid a bassa priorità, quindi lutilizzo della risorsa può essere revocato dallo scheduler locale Allocazioni con tempo di completamento garantito alcuni scheduler locale posssono garantire che un allocazione sarà completata (? Cioè disponibile, oppure il job sarà completato) entro una deadline stabilita. Questo attributo va di solito combinato con quello che riguarda la lunghezza massima dellallocazione.

Proprietà dell allocazione Numero di tentativi garantiti per completare un job In alcuni casi, come ad esempio nella trasmissione dei dati sulla rete, può accadere che il job previsto non sia completato per guasti ed altro. Lo scheduler locale dovrebbe garantire un numero minimo di tentativi prima di rinunciare e trasmettere il problema allutente e/o allo scheduler di livello più alto. Esecuzione fino al completamento dellapplicazione Lo scheduler locale fornisce la garanzia che il job non sarà interrotto, ma sarà eseguito fino al completamento o allo scadere del tempo richiesto. Lo scheduler di più alto livello può usare questa informazione per rendere più affidabile la previsione sul tempo di completamento di un job.

Proprietà dell allocazione Allocazione esclusiva garantisce un utilizzo esclusivo e non time shared delle risorse. Come per il caso precedente può essere utile per stimare in modo affidabile il tempo necessario ad un job per essere eseguito su un set di risorse. Malleable (moldable) allocation prevede la possibilità, per lo scheduler locale, di aggiungere e/o togliere risorse ad una allocazione in modo dinamico, cioè durante lesecuzione. Ha quindi un impatto sullaffidabilità della stima che lo scheduler di Grid può fare sul tempo di completamento di un job. Il problema è meno grave nel caso in cui le risorse possono essere solo aggiunte.

Modifica dinamica dellallocazione Questo tipo di attributi permette di gestire situazioni che si creano dinamicamente a causa di modifiche inaspettate nellallocazione delle risorse (ad esempio una risorsa locale non è più disponibile). Lo scopo è quello di permettere allo scheduler di più alto livello di intervenire in modo diretto senza coinvolgere lo scheduler locale. Preemption Lo scheduler locale permette allo scheduler di più alto livello di effettuare una preemption temporanea di una allocazione e quindi fermare lapplicazione corrispondente, che però continua a risiedere sulla risorsa e può essere fatta ripartire in un secondo tempo. E unazione diversa dalla preemption in un sistema multitasking. Non richiede checkpointing.

Modifica dinamica dellallocazione Checkpointing Il sistema di gestione locale può permettere di effettuare loperazione di checkpointing per salvare lo stato di unapplicazione e quindi poterla riavviare. Esistono diverse strategie e problematiche di checkpointing e non per tutti i job è possibile effettuare questa operazione. In alcuni casi è necessaria una cooperazione con lapplicazione.

Modifica dinamica dellallocazione Migrazione In alcuni casi è possibile sospendere lesecuzione di un job su un sito e riprenderla su di un sito diverso dopo aver spostato i dati necessari. Questo tipo di operazione ha un interesse per lo scheduler di più alto livello solo se questo può controllarla, quindi lattributo non descriverà eventuali migrazione allinterno di un dominio locale. Restart il sistema locale permette di far ripartire unapplicazione che era stata in precedenza fermata. In alcuni casi questo è possibile solo se era stato effettuato un checkpoint.