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
Queries
closer to the user
Confirmations
Lower level scheduling instances
(heterogeneity)
Attributes to describe
features of heterogeneous
resources
closer to the resource
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
Guaranteed
completion time
Clusters
processing
2
Data
Base
Bandwidth
broker
D
a
1
t
a transfer
3
Workflow
1
2
Visualize
Visualization
cave
Advanced reservation for exclusive
allocation and run to completion
Concurrent access
Temptative schedule e
coallocazione di risorse
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.