10 azioni per lo scheduling su Grid
• Uno scheduler per Grid deve selezionare le risorse in un
ambiente dove non ha il controllo diretto delle risorse
locali, le risorse sono distribuite, le informazioni
disponibili sono a volte limitate e spesso “datate”
• La selezione delle risorse è collegata strettamente alle
funzionalità fornite dal Grid Information Service (GRISGIIS per Globus)
• La schedulazione su Grid può essere divisa in tre fasi:
– Resource discovery
– Selezione
– Esecuzione del programma
10 azioni per lo scheduling su Grid
• Grid Scheduling: il processo di schedulazione che coinvolge
risorse appartenenti a diversi domini operativi;
• Job: qualsiasi entità che abbia bisogno di una risorsa, ad
esempio una richiesta di banda di comunicazione,
un’applicazione o un insieme di applicazioni;
• Risorsa: una qualsiasi entità che possa essere schedulata, ad
esempio una macchina, dello spazio disco, una rete
caratterizzata da QoS
10 azioni per lo scheduling su Grid
• Il grid scheduler può essere confrontato con il local
scheduler: quest’ultimo è responsabile della schedulazione
per una singola locazione ed ha il controllo sulle risorse
gestite, mentre il grid scheduler non ha questa capacità di
controllo;
• Allo stesso modo il Grid scheduler può non avere il pieno
controllo dei job sottomessi;
• Il grid scheduler si basa su un approccio “best effort” e la
mancanza di possesso delle risorse e di pieno controllo dei
job, in un contesto in cui è necessaria una politica di
ottimizzazione globale, è uno dei principali problemi
L’utente come primo esempio di Grid Scheduler
• L’utente è il più comune scheduler in ambito Grid, per lo
meno dal punto di vista storico.
• E’ utile considerare l’utente come primo esempio di
scheduler per poter chiarire i meccanismi coinvolti
nell’operazione di scheduling su Grid ed identificare le fasi
delle operazioni di scheduling.
L’acquisizione delle informazioni: un servizio
essenziale per lo scheduler
• Le decisioni dello scheduler sono prese sulla base delle
informazioni disponibili sui job e sulle risorse
• In ambito Grid non possiamo, di solito, contare su
informazioni molto accurate e aggiornate
• Lo scheduler normalmente interagisce con il Grid
Information System (GIS) che a sua volta colleziona le
informazioni dalle singole risorse
• Esempi di GIS sono il Monitoring and Discovery Service
(MDS) di Globus ed la Grid Monitoring Architecture
(GMA) sviluppata dal Global Grid Forum (GGF)
Caratteristiche principali di un GIS
• Gestione di insiemi di sensori in grado di fornire
informazioni sulle risorse
• Distinzione tra informazioni statiche ( ad esempio il tipo di
sistema operativo di un nodo) e caratteristiche dinamiche
(la quantità di memoria disponibile o il carico della CPU)
• Scelta di differenti politiche per aggiornare le informazioni
sulle risorse: in ogni caso necessità di una interazione
stretta e pesante per avere informazioni molto aggiornate,
questo porta ad adottare diverse strategie di caching delle
informazioni raccolte
Caratteristiche principali di un GIS
• Necessità di fornire un sistema estendibile in modo tale da
poter descrivere risorse non considerate inizialmente,
sviluppare servizi di più alto livello, sviluppare servizi di
“previsione”
• Necessità di prevedere uno schema condiviso di descrizione
degli attributi di una risorsa in modo da poter sviluppare
sistemi interoperanti
Le tre fasi e i dieci passi di base per lo
scheduling
• Fase 1: Resource discovery
– Passo1: Filtraggio delle risorse in base
all’autorizzazione
– Passo 2: Individuazione dei requisiti dell’applicazione
– Passo 3: Filtraggio delle risorse che soddisfano i
requisiti minimali
• Fase 2: Scelta delle risorse (system selection)
– Passo 4: Raccolta delle informazioni dinamiche
– Passo 5: Scelta delle risorse
Le tre fasi e i dieci passi di base per lo scheduling
• Fase 3: Job execution
–
–
–
–
–
–
Passo 6: Advanced reservation
Passo 7: Job submission
Passo 8 Preparazione dell’ambiente
Passo 9: Monitoraggio dell’esecuzione
Passo 10: Job completion
Passo 11: Cleanup
Fase 1: resource discovery
• All’inizio di questa fase non abbiamo alcuna risorsa a
disposizione.
• Passo1: Filtraggio delle risorse in base
all’autorizzazione – questa operazione è necessaria per
stabilire ad esempio se l’applicazione X è autorizzata ad
usare la macchina Y ed è di particolare importanza in un
ambiente multi dominio.
• Passo 2: Individuazione dei requisiti dell’applicazione –
questa operazione dovrebbe permettere di stabilire in modo
più o meno preciso quali sono i requisiti sia statici (ad
esempio il sistema operativo) che dinamici (ad esempio la
RAM necessaria) che una risorsa deve soddisfare per poter
essere utilizzata per una data applicazione
Fase 1: resource discovery
• Passo 3: Filtraggio delle risorse che soddisfano i
requisiti minimali – identificato l’insieme delle risorse su
cui l’applicazione è autorizzata e noti i requisiti principali
della stessa si seleziona un insieme di risorse su cui il job
può essere eseguito.
• Alla fine di questa fase avremo a disposizione un insieme
di risorse che l’applicazione è autorizzata ad utilizzare e
che soddisfano i requisiti minimali per poter essere
utilizzate. Si procede quindi alla selezione delle risorse che
si intendono utilizzare.
Fase 2: Scelta delle risorse (system selection)
• Questa fase comprende in genere due passi, uno dedicato
ad una raccolta di informazioni dettagliate, soprattutto
dinamiche, sullo stato delle risorse, ed uno di scelta.
• Passo 4: Raccolta delle informazioni dinamiche – questo
passo è di grande importanza anche perché permette di
verificare se una risorsa candidata ad essere scelta è
effettivamente, o almeno con buona probabilità,
disponibile. Tuttavia questo passo può essere molto critico
da realizzare per diverse ragioni tra le quali l’eterogeneità
delle risorse e delle applicazioni, l’interazione con domini
amministrativi e politiche locali di gestione diverse, la
natura distribuita del sistema, l’esigenze di scalabilità e
consistenza. In genere una risorsa per cui non sono
disponibili informazioni dinamiche aggiornate non
dovrebbe essere scelta.
Fase 2: Scelta delle risorse (system selection)
• Passo 5: Scelta delle risorse – durante questa fase
possono essere adottate diverse strategie di ottimizzazione,
la cui efficacia dipende dalla qualità delle informazioni
prodotte nei passi precedenti
Fase 3: Job execution
• Passo 6: Advanced reservation – questo passo è
opzionale ed è finalizzato a consentire un migliore uso del
sistema. Non sempre è possibile realizzare l’ advanced
reservation di una risorsa. Vedi anche i Service Level
Agreement (SLA)
• Passo 7: Job submission – quest’operazione può essere
banale (esecuzione di un singolo comando) ma anche
molto complicata richiedendo il setup dell’ambiente e lo
staging dei file necessari all’esecuzione del job. Al
momento non esiste uno standard per quest’operazione se
non quello di Globus. GGF sta lavorando ad un insieme
di API per questa operazione
Fase 3: Job execution
• Passo 8: Preparazione dell’ambiente – questa operazione
può coinvolgere lo staging di file (anche attraverso FTP o
Grid FTP), la richiesta di prenotazione o altre azioni
necessarie all’esecuzione di un job. La gestione delle
autorizzazioni, dei nomi locali ed altro può complicare la
situazione a questo livello.
• Passo 9: Monitoraggio dell’esecuzione – per applicazioni
la cui durata è maggiore di un certo valore di soglia (ad
esempio stabilito considerando il tempo medio di
variazione dello stato di una risorsa critica) è opportuno
avere la possibilità di monitorare l’evoluzione del job in
esecuzione. Un job che non riesce ad eveolvere può essere
rischedulato.
Fase 3: Job execution - continua
• Passo 10: Job completion – L’utente dovrebbe essere
informato della terminazione di un job. Questa azione può
essere anche molto complicata in un sistema distribuito a
causa di possibili guasti e/o per l’impossibilità di rilevare
la terminazione effettiva di un job
• Passo 11: Cleanup – L’ambiente che è stato creato per
permettere l’esecuzione di un job deve essere cancellato
quando il job termina.