FESR Trinacria Grid Virtual Laboratory Workload Management System (WMS) Muoio Annamaria INFN - Catania Primo Workshop TriGrid VL Catania,
Catania, Primo Workshop TriGrid VL, Outline In questa sessione tratteremo i seguenti argomenti: Panoramica di gLite middleware Panoramica dell’architettura del Workload Management System (WMS) Task Queue, Information Supermarket, MatchMaker, Scheduling Policies, Job Submission Service, Job Logging & Bookkeeping.
Catania, Primo Workshop TriGrid VL, Panoramica di gLite Middleware
Catania, Primo Workshop TriGrid VL, Job Management Service ACCOUNTINGCOMPUTING ELEMENT JOB PROVENANCE PACKAGE MANAGER WORKLOAD MANAGEMENT Job Management Service
Catania, Primo Workshop TriGrid VL, Architettura del Workload Management System (WMS)
Catania, Primo Workshop TriGrid VL, Workload Management System Workload Management SystemWorkload Management System (WMS) comprende un insieme di componenti del middleware Grid responsabili per la distribuzione e gestione dei tasks attraverso le risorse di Grid. Lo scopo del Workload Manager (WM) è di accettare e soddisfare le richieste per gestire i jobs sottomessi dai suoi utenti – Con la richiesta di sottomissione si trasferisce la responsabilità del job al Workload Manager (WM). Il Workload Manager passerà il job ad un appropriato Computing Element (CE) per l’esecuzione considerando i requirements e le preferences espresse nella descrizione del job matchmakingLa decisione di quale risorsa usare, non è altro che il risultato del processo di matchmaking tra la richiesta sottomessa e le risorse disponibili.
Catania, Primo Workshop TriGrid VL, Strategie di programmazione del WM Il Workload Manager puo’ adottare due differenti strategie: –eager scheduling (“push” model) un job è associato ad una risorsa appena possibile e, una volta che la decisione è stata presa, il job passa alla risorsa selezionata per l’esecuzione, e finirà in una coda. –lazy scheduling (“pull” model) se non vi sono risorse disponibili, allora il job è trattenuto dal Workload Manager(WM). Appena una risorsa diventa disponibile, essa sarà associata con i jobs sottomessi. Tra i vari jobs quello che meglio si adatta alla risorsa verrà eseguito immediatamente.
Catania, Primo Workshop TriGrid VL, Strategie di programmazione del WM JOB 1 N N 1
Catania, Primo Workshop TriGrid VL, L’Information SuperMarket (ISM) L’ISM rappresenta uno dei miglioramenti nel Workload Manager L’ ISM è un insieme di informazioni sulla risorsa, che è prontamente disponibile in modalità di sola lettura, per il matchmaking. Quindi, l’ISM implementa il meccanismo che permette l’ applicazione di differenti strategie attraverso la differenzazione tra le informazioni delle risorse e il loro uso. –Il suo continuo aggiornamento è il risultato dell’arrivo di notifiche o di un attivo polling delle risorse oppure di alcune combinazioni arbitrarie di entrambe.
Catania, Primo Workshop TriGrid VL, Il Task Queue Il Task Queue rappresenta il secondo notevole miglioramento nella struttura interna del Workload Manager –offre la possibilità di mantenere la richiesta di sottomissione del job, se per il momento non vi sono risorse immediatamente disponibili, che corrispondono alle requisiti(requirements) del job. - Se le richieste non sono state soddisfatte: –saranno riprocessate periodicamente (eager sheduling) –oppure attendono la notifica delle risorse disponibili che appaiono nell’ Information Supermarket (lazy scheduling) Alternativamente queste situazioni possono solo condurre ad una interruzione del Job per la mancanza di risorse.
Catania, Primo Workshop TriGrid VL, Job Submission Services I componenti del Workload Manager Service compiono management del Job durante il suo tempo di esistenza e ne effettuano la sottomissione: Job Adapter –permette di dare i ritocchi finali all’espressione scritta in JDL per un Job, prima che esso sia passato al CondorC per una effettiva sottomissione; creare lo script “wrapper” del job che a sua volta crea un appropriato ambiente di esecuzione nel nodo del worker Computing Element CondorC permette le operazioni di gestione del job. sottomissione o rimozione del job
Catania, Primo Workshop TriGrid VL, Job Submission Services Log Monitor è responsabile di monitorare il file log di CondorC intercettare eventi interessanti relativi ai jobs attivi; eventi riguardanti lo stato del job (job done, job cancelled) selezionare azioni appropriate; DAGMan –è un meta-scheduler il cui scopo è di navigare il “graph” di determinare quali nodi sono liberi da dipendenze; di seguire l’esecuzione dei corrispondenti jobs;
Catania, Primo Workshop TriGrid VL, Job Submission Services Logging & Bookkeeping (LB) è responsabile di registrare gli eventi generati dai vari componenti del WMS poter richiedere informazioni circa lo stato del job Proxy Renewal Service è responsabile di assicurare che, per tutto il tempo di vita di un job, uno user proxy valido esista nel WMS MyProxy Server è contattato per rinnovare le credenziali dello user
Catania, Primo Workshop TriGrid VL, Architettura del WMS Le richieste diJob management (submission, cancellation) (submission, cancellation) sono espresse con Job Description Language (JDL)
Catania, Primo Workshop TriGrid VL, Trova un appropriato Computing Element per ogni sottomissione richiesta, considerando job requests e preferences, lo stato della Grid,l’uso di policies sulle risorse
Catania, Primo Workshop TriGrid VL, Architettura del WMS Prende la richiesta di sottomissione Le richieste sono mantenute Le richieste sono mantenute se nessuna combinazione con la risorsa è disponibile
Catania, Primo Workshop TriGrid VL, Architettura del WMS Registra le informazioni per le risorse per le risorse disponibili al matchmaker. Aggiorna con notifiche e/o con polling sulle sorgenti
Catania, Primo Workshop TriGrid VL, Architettura del WMS Realizza la Sottomissione e il Monitoraggio del Job e il Monitoraggio del Job
Catania, Primo Workshop TriGrid VL, Processa il Job submitted
Catania, Primo Workshop TriGrid VL, Referenze WMS – User Guide WMS Architecture overview LB Architecture overview
Catania, Primo Workshop TriGrid VL, Request types “Job”un semplice job (default) “DAG” un Direct Acyclic Graph di job collegati “Collection”un insieme di job indipendenti