Architettura del Workload Management System e Job Description Language

Presentazione sul tema: "Architettura del Workload Management System e Job Description Language"— Transcript della presentazione:

1 Architettura del Workload Management System e Job Description Language
Federico Bitelli Dipartimento di Fisica Roma Tre Antonio Budano INFN Roma Tre

2 WORKLOAD MANAGER SYSTEM
Lo scopo del WMS è quello di accettare richieste di sottomissione e di gestione dei Job ed effettuare le appropriate azioni per soddisfarle La complessità della gestione delle risorse e delle applicazioni della griglia è nascosta all’utente. L’interazione dell’utente con il WMS avviene attraverso un linguaggio (JDL) atto a descrivere i requisiti e le caratteristiche idonee alla propria richiesta L’atto finale del WMS è quello di decidere quale risorsa deve esser usata per soddisfare la richiesta ,inviare il job e seguirne l’evoluzione. Roma Tutorial WMS-JDL

3 ARCHITETTURA DEL WORKLOAD SYSTEM
WM WMS Roma Tutorial WMS-JDL

4 COMPONENTI DEL WMS Network Server NS Workload Manager Proxy WMProxy
E’ un generico demone che accetta le richieste dalla UserInterface Workload Manager Proxy WMProxy E’ uno servizio che fornisce accesso al WMS per esempio attraverso Web Services Workload Manager WM E’ il cuore di tutto il WMS Data una valida richiesta esso si incarica di soddisfarla invocando l’aiuto dei vari moduli Resource Broker(MatchMaker) RB Si incarica di decidere quali risorse meglio soddisfano la richiesta. Information SuperMarket ISM E’ il componente sul quale sono immagazinate le informazioni sulle risorse disponibili.Viene updatato dal ISMupdater che controlla periodicamente lo stato dei sui record Roma Tutorial WMS-JDL

5 TASK QUEUE SCHEDULING WM Task Queue
se non vi sono risorse immediatamente disponibili (con i requisiti richiesti) offre la possibilità di mantenere la richiesta di sottomissione 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) 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. Roma Tutorial WMS-JDL

6 COMPONENTI DEL WMS Job Adapter CondorC DAG Manager (DAGMan)
da i ritocchi finali all’espressione scritta in JDL per un Job, prima che esso sia passato al CondorC per una effettiva sottomissione; crea lo script “wrapper” del job che a sua volta crea un appropriato ambiente di esecuzione nel nodo del worker Computing Element CondorC E’ il modulo responsabile di eseguire le operazioni sul Job (ad esempio sottomissione,rimozione…) che gli vengono richieste dal WM Esso permette le operazioni di gestione del job DAG Manager (DAGMan) È il modulo incaricato di verificare i DAG , determina le risorse che sono libere da dipendenze e segue l’esecuzione dei Job corrispondenti Log Monitor (LM) È 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) Roma Tutorial WMS-JDL

7 ELEMENTI DI SUPPORTO Proxy Renewal Service Logging & Bookkeeping (LB)
è 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 Logging & Bookkeeping (LB) Da supporto a tutti i moduli precedenti per monitorare lo stato del Job. Le informazioni di ogni azione effettuata da ogni altro modulo vengono registrate ed immagazinate dal LB Roma Tutorial WMS-JDL

8 Jobs State Machine (1/9) Submitted IL job viene passato dall’utente alla UI ma non ancora trasferito al Network Server In the next few slides I will show you how the job’ status changes during its lifetime. The starting point, as I said before, is rappresented by a User that from a trusted UI submit to the grid a request for job submission in order to be executed in one of the grid resource. Request that has to be expressed using the JDL. With this languages user can also specify a list of input file that needs to be transfered from the UI to the WN. We said that the job status is SUBMITTED when it has been entered to the grid but it has not yet received by the Network Server. Roma Tutorial WMS-JDL

9 Jobs State Machine (2/9) Waiting IL Job è accettato dal NS ed è in attesa di esser processato dal WM o dai suoi moduli When the job request reaches the WMS the Match-Maker process starts to search the best resource where this request can be satisfyied. To do so, the MM interacts with the BDII in order to retrieve the status of all the grid resources, and with the Catalog in order to detect the location of data if the job needs to use file that have been stored within a Storage Element. Roma Tutorial WMS-JDL

10 Jobs State Machine (3/9) Ready IL Job è processato dal WM ma non ancora trasferito al CE (sistema di coda locale) If at the end of the matchmaking algorithm the available resource has been found, the JA starts to preparate the wrapper script in order to correctly set the environment on the WN and the job’ status become READY. Roma Tutorial WMS-JDL

11 Jobs State Machine (4/9) Scheduled II job è in attesa sul CE
When the job’ status becomes Scheduled this means that the job has reached the grid resource and that now it’s waiting the the CE will dispatch it in one of the available worker node in order to start its execution. Roma Tutorial WMS-JDL

12 Running è in esecuzione
Jobs State Machine (5/9) Running è in esecuzione Roma Tutorial WMS-JDL

13 Jobs State Machine (6/9) Done Il Job è terminato con successo o considerato(da condorC) terminato con errore. (es: a causa di errori irrecuperabile sul CE) Roma Tutorial WMS-JDL

14 Jobs State Machine (7/9) Aborted Il job processato viene abortito dal WMS (troppo tempo in coda sul WM o CE , credenziali utente scadute) If something goes wrong, for example the job stays too long in a CE’s queue, or the user’s credentials expires, the job’ status becomes Aborted. Roma Tutorial WMS-JDL

15 Jobs State Machine (8/9) Cancelled IL Job viene cancellato dall’utente. Job’ status is CANCELLED if it has been succesfully deleted by the user. Roma Tutorial WMS-JDL

16 Jobs State Machine (9/9) Job’ status become CLEARED if the output files have been correctly retrieved or removed due to the timeout. Cleared output è stato trasferito dall’utente o rimosso a causa di un timeout Roma Tutorial WMS-JDL

17 Link Utili WMS – User Guide https://edms.cern.ch/document/572489/1
WMS Architecture overview LB Architecture overview Roma Tutorial WMS-JDL

18 Job Description Language (JDL)
PARTE SECONDA Job Description Language (JDL)

19 Il linguaggio JDL La sintassi del JDL è del tipo : Attributo = valore;
In gLite Job Description Language (JDL) è usato per descrivere con quali modalità un Job dovrà esser eseguito in griglia. Il file JDL verrà poi processato dal “Match-making process” per selezionare la risorsa desiderata. Il JDL dovrà descrivere il Job stesso e quali risorse dovranno esser usate per la sua esecuzione. La sintassi del JDL è del tipo : Attributo = valore; Gli attributi vengono raggruppati in due categorie: Job Attributes Definiscono il Job stesso Resources Indicano requisiti per il Job Computing Resource Data and Storage resources I commenti devono esser preceduti da # JDL è sensibile agli spazi ed ai tabs Nessun spazio o tabs deve seguire il “ ; ” alla fine della riga Roma Tutorial WMS-JDL

20 JDL : Attributi base [ Executable = “test.sh”; StdOutput = “std.out”;
In JDL, alcuni attributi sono obbligatori altri sono opzionali. Il più “semplice” file JDL deve contenere: [ Executable = “test.sh”; StdOutput = “std.out”; StdError = “std.err”; InputSandbox = {“test.sh”}; OutputSandbox = {“std.out”,”std.err”}; ] Eventuali argomenti necessari all’”executable” devono esser passati con: Arguments = “lista argomenti”; Roma Tutorial WMS-JDL

21 JDL : Attributi base Executable = “test.sh”; StdOutput = “std.out”;
StdError = “std.err”; InputSandbox = {“test.sh”}; OutputSandbox = {“std.out”,”std.err”}; Executable = < stringa > deve essere inserito anche nell’Input Sandbox obbligatorio per tutti i job caratteri speciali non consentiti gli argomenti sono riportati in un attributo a parte Roma Tutorial WMS-JDL

22 JDL : Attributi base Executable = “test.sh”; StdOutput = “std.out”;
StdError = “std.err”; InputSandbox = {“test.sh”}; OutputSandbox = {“std.out”,”std.err”}; StdOutput, StdError, StdInput, = < stringa > i percorsi per I file di di uscita / di errore / ingresso bisogna specificare anche in Output Sandbox StdOutput e StdError possono coincidere attributo non richiesto per i job interattivi Roma Tutorial WMS-JDL

23 JDL : Attributi base Executable = “test.sh”; StdOutput = “std.out”;
StdError = “std.err”; InputSandbox = {“test.sh”}; OutputSandbox = {“std.out”,”std.err”}; InputSandbox, OutputSandbox = < stringa | lista di stringhe > identifica: i file di input da copiare dalla UI sul WN prima dell’esecuzione del job i file di output che devono essere ricopiati dal WN alla UI dopo l’esecuzione del job (il trasferimento dal WN vero e proprio è effettuato con l’istruzione glite-job-output dalla UI) non ammessi i file remoti (si richiedono InputData o script di copia) i file in InputSandbox non devono superare 10 MB ciascuno i nomi dei file devono essere differenti (la directory di arrivo è uguale per tutti) esempio: InputSandbox= { “myfile1.dat“ , ”data/myfile2.dat” }; Roma Tutorial WMS-JDL

24 JDL : Attributi base Arguments = < stringa >
argomenti per il file eseguibile: “-out outputfile.dat” insieme con: Executable = “execprog”; forma sul Worker Node (WN) la linea di comando: $ execprog -out outputfile.dat le virgolette “” devono essere precedute dalla \ “ -a \”quoted string\” -bcd” diventa (con l’eseguibile precedente): $ execprog -a ”quoted string” –bcd I caratteri speciali come &, |, >, < possono essere inseriti precedendoli con tre \ : Arguments = "-f file1\\\&file2"; Roma Tutorial WMS-JDL

25 “Interactive” + “MPI” non è ancora supportato
JDL : Attributi avanzati JobType (optionale) Normal (semplice, job sequenziale ) Interactive (un job che stabilisce una sessione interattiva con l’utente) MPICH (un job parallelo MPI) Checkpointable (un job che conserva il suo stato e può ripartire da una punto predefinito ) Partitionable (un job composto da un insieme di passi indipendenti adatti ad una esecuzione parallela) Parametric (un job con uno o più attributi parametrici che variano da una sottomissione all’altra) E.g. JobType = “Interactive”; JobType = {“Interactive”,”Checkpointable”}; “Interactive” + “MPI” non è ancora supportato Roma Tutorial WMS-JDL

26 JDL : Attributi avanzati
Requirements (opzionale) Requisiti del job riguardo I componenti della griglia (CE,SE,…) Specificati usando gli attributi pubblicati dall’Information Service Se non specificato ,viene usato il valore di default definito sulla UI: Requirements = other.GlueCEStateStatus == "Production“; Esempi: Requirements=other.GlueCEUniqueID == “adc006.cern.ch:2119/jobmanager-pbs-infinite” Requirements=Member(“ALICE ”, other.GlueHostApplicationSoftwareRunTimeEnvironment); Requirements = other.GlueCEInfoTotalCPUs > 2 && other.GlueCEPolicyMaxRunningJobs < 2;

27 JDL : Attributi avanzati
Environment = < stringa | lista di stringhe > variabili d’ambiente formato delle stringhe: < nome variabile > = < stringa > esempio: Environment = { “JOB_LOG_FILE=/tmp/job.log”, “INP_DIR=/tmp/input_files” }; InputData = < stringa | lista di stringhe > identifica i file remoti ( Logical File Name (LFN), Grid Unique Identifier (GUID)) copia i file nella directory corrente del WN influenza la scelta del matchmaking esempio: InputData = { “lfn:/grid/gilda/isospin.dat”, “guid:135b7b23-4a6a-87e7-9d101f8c8b70”}; Roma Tutorial WMS-JDL

28 JDL : Attributi avanzati
DataAccessProtocol (obbligatorio se è stato specificato InputData) i protocolli da usare per le operazioni sui file obbligatorio con InputData I protocolli supportati in gLite sono : gsiftp e file DataAccessProtocol = {“file”,“gsiftp”}; OutputSE = < stringa > L’ URL di uno StorageElement (SE) dove l’utente vuole salvare i file di output influenza la decisione sulla destinazione del job esempio: OutputSE = “grid009.ct.infn.it”; Roma Tutorial WMS-JDL

29 JDL : Attributi avanzati
NodeNumber = < intero > un intero >1 per indicare quante CPU usare per un job MPI obbligatorio per il JobType = “MPICH” esempio: NodeNumber = 3; JobSteps = < intero | lista di stringhe > un intero che indica il numero di passi di un job partizionabile o una lista di stringhe associate con le parti di programma eseguibili in maniera parallela esempi: JobSteps = 1000; (esegue 1000 passi) JobSteps = { “a”,”b”,”c” }; (esegue le sezioni “a”, “b”, “c”) Roma Tutorial WMS-JDL

30 JDL : Attributi avanzati
CurrentStep = < intero > un numero >0 da cui iniziare l’elaborazione di un job (checkpointable o partitionable) esempio: CurrentStep = 2; (default=0) Roma Tutorial WMS-JDL

31 Command Line Interface
Sottomissione di un job Per sottomettere un job sulla Grid. $ glite-job-submit [options] <jdl_file> Esempi di [options] : --output, -o <output file> salva il jobid in un file. --resource, -r <resource value> specifica la risorsa su cui si vuole inviare il job. $ glite-job-submit test.jdl ====================glite-job-submit Success ===================== The job has been successfully submitted to the Network Server. Use glite-job-status command to check job current status. Your job identifier (edg_jobId) is: - ============================================================== First of all I will present you the most relevant command that can be used to interact with the WMS. Roma Tutorial WMS-JDL

32 Command Line Interface
Nel caso di fallimento della richiesta il sistema stamperà un messaggio di errore: **** Error: API_NATIVE_ERROR **** Error while calling the "NSClient::multi" native api AuthenticationException: Failed to establish security context... **** Error: UI_NO_NS_CONTACT **** Unable to contact any Network Server Questo tipo di messaggio significa che: ci sono stati problemi di autenticazione tra la UI e il RB (in questo caso controllare il certificato) Roma Tutorial WMS-JDL

33 Command Line Interface
E’ possibile sapere, dato un file jdl, con quale CE il nostro job risulta “compatibile”, usando il comando: glite-job-list-match test.jdl Connecting to host lxshare0380.cern.ch, port 7772 Selected Virtual Organisation name (from UI conf file): dteam ********************************************************************* COMPUTING ELEMENT IDs LIST The following CE(s) matching your job requirements have been found: adc0015.cern.ch:2119/jobmanager-lcgpbs-infinite adc0015.cern.ch:2119/jobmanager-lcgpbs-long adc0015.cern.ch:2119/jobmanager-lcgpbs-short ********************************************************************** Roma Tutorial WMS-JDL

34 Command Line Interface
Dopo aver sottomesso il nostro job possiamo sapere il suo stato attraverso il comando glite-job-status specificando il nostro jobid: glite-job-status ************************************************************* BOOKKEEPING INFORMATION: Printing status info for the Job: Current Status: Scheduled Status Reason: unavailable Destination: lxshare0277.cern.ch:2119/jobmanager-pbs-infinite reached on: Fri Aug 1 12:21: Roma Tutorial WMS-JDL

35 Command Line Interface
Attraverso l’opzione -i <file path> possiamo passare al comando glite-job-status un file che contiene la lista di tutti i job che abbiamo sottomesso: glite-job-status -i jobs.list 1 : 2 : 3 : a : all q : quit Choose one or more edg_jobId(s) in the list - [1-3]all: (possiamo salvare il jobid dei job sottomessi su di un file, attraverso l’opzione -o nel comando glite-job-submit). Roma Tutorial WMS-JDL

36 Command Line Interface
Un job può essere cancellato utilizzando il comando glite-job-cancel con argomento il jobid: glite-job-cancel Are you sure you want to remove specified job(s)? [y/n]n :y =================== glite-job-cancel Success==================== The cancellation request has been successfully submitted for the following job(s) - =========================================================== Roma Tutorial WMS-JDL

37 Command Line Interface
Quando un job termina ( status = DONE ), i file di output possono essere copiati nella UI attraverso il comando: glite-job-output Retrieving files from host lxshare0234.cern.ch ***************************************************************** JOB GET OUTPUT OUTCOME Output sandbox files for the job: - have been successfully retrieved and stored in the directory: /tmp/jobOutput/snPegp1YMJcnS22yF5pFlg Di default la directory dove vengono salvati i file di output e’ : /tmp, possiamo cambiare il default utilizzando l’opzione : - -dir <path name> Roma Tutorial WMS-JDL

38 Link Utili JDL Attributes
Roma Tutorial WMS-JDL