Requisiti dell’applicazione per il resource brokering su Grid

Requisiti dell’applicazione 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 dell’applicazione per il resource brokering su Grid

• Data related – Per quanto riguarda i dati i requisiti riguardano l’occupazione di memoria ai diversi livelli della gerarchia (ram, disco, …), la distribuzione dei dati e l’accesso a dati distribuiti in modo trasparente, l’esigenza di trasferire grandi quantità di dati tra diversi moduli dell’applicazione (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 l’affidabilità 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 dall’utilizzo di sistemi di protezione locali, quali ad esempio firewall.

Requisiti dell’applicazione 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 dell’applicazione (tipo di processore, quantità di memoria, sistema operativo, necessità di compilazione …) in modo standard permettendo l’utilizzo dell’applicazione 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 un’applicazione 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 un’applicazione 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 l’applicazione– Utilizzo di dati storici– Utilizzo di test case

• Adaptive Brokering – le condizioni di elevata dinamicità del contesto e delle applicazioni rendono molto importante l’utilizzo 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 dell’allocazione

Un esempio di applicazione

Clusters

Data Base

Visualization cave

Bandwidth broker

Data transfer

processing

Visualize

Guaranteed completion time

Advanced reservation for exclusive allocation and run to completion

1

2

3

Concurrent access

Temptative schedule e coallocazione di risorse

Workflow1

2

3

Accesso alle informazioni di scheduling disponibili

• Definiamo come allocazione l’assegnazione di risorse ad una richiesta, allocazione di tentativo è un’allocazione prima del effettivo uso della risorsa;

• Una schedulazione (schedule) fornisce informazioni sulle allocazioni previste e/o garantite (un’allocazione garantita prevede l’assegnazione 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 un’istanza 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

• L’allocazione delle risorse può essere differente per quanto riguarda il tempo e l’affidabilità; ad esempio l’allocazione di un job multi-stage multi-site deve essere affidabile. Per questa ragione si descrivono le proprietà di un’allocazione.

• Revoca di un’allocazione: il propietario di una risorsa può permetterne l’uso sulla Grid a bassa priorità, quindi l’utilizzo 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 dell’allocazione.

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 all’utente e/o allo scheduler di livello più alto.

• Esecuzione fino al completamento dell’applicazione 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 l’esecuzione. Ha quindi un impatto sull’affidabilità 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 dell’allocazione

• Questo tipo di attributi permette di gestire situazioni che si creano dinamicamente a causa di modifiche inaspettate nell’allocazione 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 l’applicazione corrispondente, che però continua a risiedere sulla risorsa e può essere fatta ripartire in un secondo tempo. E’ un’azione diversa dalla preemption in un sistema multitasking. Non richiede checkpointing.

Modifica dinamica dell’allocazione

• Checkpointing Il sistema di gestione locale può permettere di effettuare l’operazione di checkpointing per salvare lo stato di un’applicazione 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 l’applicazione.

Modifica dinamica dell’allocazione

• Migrazione In alcuni casi è possibile sospendere l’esecuzione 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 l’attributo non descriverà eventuali migrazione all’interno di un dominio locale.

• Restart il sistema locale permette di far ripartire un’applicazione che era stata in precedenza fermata. In alcuni casi questo è possibile solo se era stato effettuato un checkpoint.