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 (GRIS- GIIS 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.