Problemi di schedulazione distribuita su Gridenrico/IngegneriaDelSoftware/... · 2009. 5. 20. ·...

Scheduling 1

Problemi di schedulazione distribuita su Grid

Ivan Porro

Università degli Studi di Genova, DIST, Laboratorio BioLab

[email protected]

010-3532789

Si ringrazia per il materiale il Dr. Andrea Clematis dell’ IMATI –CNR di Genova

mailto:[email protected]

Scheduling 2

Unit

1. Le fasi dello scheduling in Grid

2. Requisiti delle applicazioni eattributi delle risorse

• /* Esempio di scheduling su risorse locali */

Scheduling 3

Le fasi dello scheduling in Grid3

Scheduling 4

11 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

Scheduling 5


• 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

Scheduling 6


• 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

Scheduling 7

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.

Scheduling 8

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)

Scheduling 9

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

Scheduling 10

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

Scheduling 11

Le tre fasi e gli 11 passi di base per lo scheduling

• Fase 1: Resource discovery– Passo 1: 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

Scheduling 12

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

Scheduling 13

Scheduling 14

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

Scheduling 15

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.

Scheduling 16

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.

Scheduling 17

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

Scheduling 18

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

Scheduling 19

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.

Scheduling 20

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.

Scheduling 21

Requisiti delle applicazioni eattributi delle risorse4

Scheduling 22

Requisiti dell’applicazione per il resource brokering su Grid

Scheduling 23


• 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

Scheduling 24


• 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.

Scheduling 25

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.

Scheduling 26

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

Scheduling 27

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 closer to the user

Queries Confirmations Attributes to describe features of heterogeneous resources

Lower level scheduling instances closer to the resource(heterogeneity)

LSF, PBS LoadLeveler,Maui/Silver, Condor

Scheduling 28

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

Scheduling 29

Un esempio di applicazione

Clusters

Data Base

Visualization cave

Bandwidth broker

Data transfer

processing

Visualize

Guaranteed completion time

Advanced reservation for exclusive allocation and run to completion

1

2

3

Concurrent access

Temptative schedule e coallocazione di risorse

Workflow1

2

3

Scheduling 30

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)

Scheduling 31

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.

Scheduling 32


• 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)

Scheduling 33


• 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.

Scheduling 34

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.

Scheduling 35


• 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.

Scheduling 36


• 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.

Scheduling 37

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.

Scheduling 38


• 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.

Scheduling 39


• 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.

Scheduling 40

/*Esempio di scheduling su risorse locali

Scheduling 41

I passi fondamentali• Avere un cluster

[pivan@master ~]$ bqueuesQUEUE_NAME PRIO STATUS MAX JL/U JL/P JL/H NJOBS PEND RUN SUSPvnc 50 Open:Active - - - - 18 0 18 0owners 43 Open:Active - - - - 0 0 0 0priority 43 Open:Active - - - - 0 0 0 0night 40 Open:Active - - - - 0 0 0 0chkpnt_rerun_qu 40 Open:Active - - - - 0 0 0 0short 35 Open:Active - - - - 0 0 0 0license 33 Open:Active - - - - 0 0 0 0normal 30 Open:Active - - - - 0 0 0 0idle 20 Open:Active - - - - 0 0 0 0

[pivan@master ~]$ lsloadHOST_NAME status r15s r1m r15m ut pg ls it tmp swp memnode05.ada.dist ok 0.0 0.0 0.0 0% 0.0 0 5456 116G 8188M 15Gnode04.ada.dist ok 0.2 0.0 0.0 0% 0.0 0 5436 116G 8188M 15Gnode02.ada.dist ok 0.2 0.0 0.0 0% 0.0 0 5468 116G 8188M 15Gnode03.ada.dist ok 0.3 0.0 0.0 0% 0.0 0 5760 116G 8188M 15Gmaster.ada.dist ok 0.8 0.9 0.7 8% 0.0 1 0 6981M 18G 17Gnode01.ada.dist ok 1.5 2.3 1.6 59% 0.0 0 13888 58G 8188M 7476M

Scheduling 42

I passi fondamentali• Avere un job…#!/bin/shecho "Io sono il job $1"/bin/hostnamesleep 4/bin/hostname –f

• … e una complicata strategia di submission

[pivan@master ~]$ for i in `seq 1 10`; do echo $i; done12345678910

Scheduling 43

I passi fondamentali• Evitiamo l’inglese…: Sottomettiamo il job:[pivan@master ~]$ for i in `seq 1 10`; do bsub -q short -o out$i.log -e err$i.log

/home/pivan/simple.sh $i; doneJob <187> is submitted to queue <short>.Job <188> is submitted to queue <short>.Job <189> is submitted to queue <short>.Job <190> is submitted to queue <short>.Job <191> is submitted to queue <short>.Job <192> is submitted to queue <short>.Job <193> is submitted to queue <short>.Job <194> is submitted to queue <short>.Job <195> is submitted to queue <short>.Job <196> is submitted to queue <short>.

• … e verifichiamo i danni:[pivan@master ~]$ bjobsJOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME187 pivan PEND short master.ada. *mple.sh 1 May 10 10:32188 pivan PEND short master.ada. *mple.sh 2 May 10 10:32189 pivan PEND short master.ada. *mple.sh 3 May 10 10:32190 pivan PEND short master.ada. *mple.sh 4 May 10 10:32191 pivan PEND short master.ada. *mple.sh 5 May 10 10:32192 pivan PEND short master.ada. *mple.sh 6 May 10 10:32193 pivan PEND short master.ada. *mple.sh 7 May 10 10:32194 pivan PEND short master.ada. *mple.sh 8 May 10 10:32195 pivan PEND short master.ada. *mple.sh 9 May 10 10:32196 pivan PEND short master.ada. *ple.sh 10 May 10 10:32

Scheduling 44

I passi fondamentali• Ancora…[pivan@master ~]$ bjobsJOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME191 pivan RUN short master.ada. node04.ada. *mple.sh 5 May 10 10:32192 pivan RUN short master.ada. node03.ada. *mple.sh 6 May 10 10:32193 pivan RUN short master.ada. node02.ada. *mple.sh 7 May 10 10:32194 pivan RUN short master.ada. node05.ada. *mple.sh 8 May 10 10:32195 pivan PEND short master.ada. *mple.sh 9 May 10 10:32196 pivan PEND short master.ada. *ple.sh 10 May 10 10:32

• … e ancora…[pivan@master ~]$ bjobsJOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME195 pivan RUN short master.ada. node04.ada. *mple.sh 9 May 10 10:32196 pivan RUN short master.ada. node03.ada. *ple.sh 10 May 10 10:32

• …finchè:[pivan@master ~]$ bjobsNo unfinished job found

• Interpretiamo i risultati:[pivan@master ~]$ cat out6.log |grep IoIo sono il job 6

Example: LSF Job Submission & Control Commands (1)

• bsub [options] command [cmdargs]– Submit job(s) to a queue

• bjobs [-a][-J jobname][-u usergroup|-u all][…] jobID– Query job(s) status – pend/run/done/exited jobs

• bhist [-a][-J jobname][-u usergroup|-u all][…] jobID– Query job(s) status – finished and archived jobs

• bkill [jobID | -J jobname] [-m] [-u ] [-q] [-s signalvalue] – Kill job(s)

• bpeek [-f] jobID– View stdout/stderr of a running job

Example: LSF Job Submission & Control Commands (2)

• bstop/bresume jobID– Stop/resume a running or pending job

• bbot/btop [jobID | "jobID[index_list]“] [position]– Move a job in a queue to bottom/top

• bmod [bsub_options] jobID– Modify job submission parameters

• bswitch destination_queue jobID– Move a job to a new queue

LSF Job Submission Command (1)

• bsub [commonly used options]

-q qname - submits the job to the specified queue

-n number - number of CPUs/cores/slots required for the job

-o filename - redirect stdout, stderr and resource usage information of the job to the specified filename

-e filename - redirect stderr to the specified error file

-i filename - use the specified file as standard input for the job

-J jobname - assigns the specified name to the job

-P projname - assigns the job to the specified project

-G user_group – Associate job with specified user group (pre-defined)

-g jobgroup - submit job to specified group name (dynamically defined)


• bsub [setting limits]-C core_limit – Set the per-process core file size limit (KB)

-c cpu_time – Limit the total CPU time for the job ([HH:]MM)

-D data_limit – Set the per-process data segment size limit (KB)

-F file_limit – Set the per-process file size limit

-M mem_limit – Set the memory limit for the job (KB)

-p process_limit – Limit the total number of processes for the job

-S stack_limit – Set the per-process stack size limit (KB)

-T threadlimit - Limit the total number of threads for the job

-v swap_limit – Set the virtual memory limit for all processes in the job (KB)

-W runlimit – Set the run time limit for the job ([HH:]MM)


• bsub [resource requirements]-R resource_requirements – Specify the scheduling resource

requirements conditions

Where resource_requirements is:

select[select_string] order[order_string] rusage[rusage_string] span[span_string] same[same_string]

Example:

bsub –R “select[swp > 15] rusage[mem=1000:tmp=5000]span[ptile=2] same[model]” myjob


• bsub [other options]-U reservation_id – Submit to an “advanced resource reservation”

-w dependency_string – Specify job scheduling dependency

-b begin_time – Dispatch the job after the specified time ([[MM:]DD:]HH:MM)

-t term_time – Specify the job termination deadline ([[MM:]DD:]HH:MM)

-sp priority – Specify a user assigned relative job priority

-B – Send email when the job is dispatched

-H – Hold the job in the PSUSP state after submission

-N – Email job header only when job completes

-u mail_user – Send email to the specified address

-L login_shell – Initialized execution environment using specified shell

Available Methods for Submitting Jobs

By script or command % bsub –q minute –n 4 scriptfile

By job spooling % bsub < spoolfile

Interactively% bsubbsub> #BSUB –q minute –n 4bsub> #BSUB –a poebsub> cd /home/user/applicationbsub> pam ./myjobbsub> ^DJob <1234> submitted to queue <minute>

Example spoolfile#BSUB –q minute#BSUB –n 4 –a poecd /home/user/applicationpam ./myjob

Example scriptfilecd /home/user/applicationpam ./myjob

LSF Job Submission – Examples (1)

bsub sleep 100

Submit the UNIX command sleep together with its argument 100 as a batch job

bsub -q short -o my_output_file "pwd; ls“

Submit the UNIX command pwd and ls as a batch job to the queue named short and store the job output in my_output file

bsub -b 20:00 -J my_job_name my_program

Submit my_program to run after 8 p.m. and assign it the job name my_job_name.


bsub -q night < my_scriptwhere my_script contains:

#!/bin/sh#BSUB -q test#BSUB -o outfile -e errfile # my default stdout, stderr files#BSUB -m "host1 host2" # my default candidate hosts#BSUB -f "input > tmp" -f "output << tmp“#BSUB -D 200 -c 10/host1#BSUB -t 13:00#BSUB -k "dir 5“sim1.exesim2.exe

The job is submitted to the night queue instead of test, because the command line overrides the script.


Example #1 % bsub sleep 1000 Job <1234> is submitted to default queue <normal> % bstop 1234 Job <1234> is being stopped % bresume 1234 Job < 1234> is being resumed % bkill 1234 Job < 1234> is being killed

Example #2 % bsub –q night –m "host1 host2" night_job Job <1235> is submitted to queue <night> % bmod –m "hostGroupA" 1235 Parameters of job <1235> are being changed

Scheduling 55

Example #3 % bsub –i "/home/user1/in.dat" -o "/home/user1/out.dat" –e "/home/user1/error.dat" long_job Job <1236> is submitted to default queue <normal>

% bswitch night 1236 Job <1236> is switched to queue <night> Example #4 % bsub –P Research –J Projection1 project_job Job <1238> is submitted to default queue <normal>

% btop 1238 Job <1238> has been moved to position 1 from top % bbot 1238 Job <1238> has been moved to position 1 from bottom


Resource usage – Examples (1)

bsub –R "select[type==any && swap>=300 && \mem>500] order[swap:mem] \rusage[swap=300:mem=500]" job1

– On the selected execution host, reserve 300MB of swap space and 500MB of memory for the duration of the job

bsub –R rusage[mem=500:app_lic_v2=1 || \ mem=400:app_lic_v1.5=1]" job1

– Job will use 500MB with app_lic_v2, or 400MB with app_lic_v1.5

*/Resource usage – Examples (2)

bsub –R "r1m*ut<1.0 || (r15m<0.2 && r15s<0.3) \ order[r1m:ut:r15s:-mem] \ rusage[r1m=0.3:duration=30,ut=0.4:duration=20:decay=1]"\ job2

– On the selected execution host, reserve 0.3 of the one minute run queue length for 30 minutes and reserve 40% of cpu utilization and linearly decay the amount of cpu utilization reserved over the duration of the period (i.e. 0.4/20=0.02%/min)

bsub –R "select[type == SUNSOL && mem > 300] \rusage[mem=300:duration=30:decay=1]" job2

– On the selected execution host, reserve 300MB of memory for 30 minutes and linearly decay the amount of memory reserved over the duration period (i.e. 300MB/30min = 10MB/min)

Problemi di schedulazione distribuita su Gridenrico/IngegneriaDelSoftware/... · 2009. 5. 20. ·...

Documents

Transcript of Problemi di schedulazione distribuita su Gridenrico/IngegneriaDelSoftware/... · 2009. 5. 20. ·...