LSF Load Sharing Facility

Load Sharing Facility (LSF) ist ein Cluster Monitor und Queueing System. Interaktive und Batch Jobs werden mit Hilfe einer intelligenten Lastverteilung über das Cluster verteilt. Ein Master Host übernimmt Scheduling, Priority Queuing und Lastverteilung für die definierten Submission und Execution Hosts.

• Monitoring der Cluster Load
• Starten von interaktiven und Batch Jobs auf dem least loaded

Cluster Node

• Automatisches Login auf least loaded Cluster Node
• Parallel Processing (PVM oder MPI)
• GUI und Terminal Interface

LSF bietet eine effiziente Fehlertoleranz , die u.a. in den nachfolgenden Situationen von Bedeutung ist:

• Master stürzt ab: Ein anderer Host übernimmt automatisch die Rolle des Masters.
• Master nicht verfügbar: keine LSF Operation möglich (Ist das kein Widerspruch?)
• Farm-Rechner stürzt ab : Die laufenden Jobs dieses Rechners sind verloren, ein automatischer Restart ist in diesem Fall möglich (?)
• LizenzServer nicht verfügbar: Es könenn keine neue Jobs aufgegeben werden.

Batch queues

The batch farm is logically divided into several queues with different characteristics, see table below.

• As of Monday, May 18 2009, the Linux batch farm's default queue batch submits jobs only to boxes running Debian Etch, 64 bit.
• The queue batch accepts jobs from all GSI users.
• Compilation and job submission can be done using the interactive machines lxi001 - lxi015, lxetch32, lxetch64.
• For compilation/submission under 32 bit Etch, there is the interactive box lxetch32.
• For compilation/submission under 64 bit Etch, there are five interactive boxes, all accessible as lxetch64.

The Etch nodes and so the corresponding batch queues will be shut down at the end of October 2011 (see ReleasePlan).

The number of CPUs in the following table is split into exclusive and total CPUs: Exclusive CPUs can only be accessed by the mentioned queue, while total CPUs may be open to this queue, _if_ there are no jobs from queues with higher priority and in particular from preemptive queues (a preemptive -queue job can suspend jobs from other queues for its own running time).

Overview over all queues

Name	Priority	OS	exclusive / total CPUs	restrictions
proof	80	Lenny64	0/448	only for ALICE, preemptive, CPU time < 12 hours, interactive parallel analysis via ROOT/PROOF
dgrid	60	Lenny64	0/872	only for CBM-GRID and PANDA-GRID, preemptive
alicetest64	60	Lenny64	0/500	only for ALICE-GRID
alice-t3_2h	60	Lenny64	0/900	only for ALICE, preemptive, CPU time < 8 hours
theory	60	Lenny64	0/200	only for THEORY, MPI enabled
hades	60	Etch64	0/500	only for HADES
short	30	Lenny64	0/6	preemptive, CPU time < 6 hours, 6 jobs at all, 3 jobs per user
research	20	Lenny64	0/15	preemptive, CPU time < 5 hours, 15 jobs at all, 5 jobs per user
batch	10	Lenny64	0/700	standard queue
betch64	9	Etch64	0/500	for using Debian 4.0 Etch with 64 bit
gropi	10	Etch32	12/12	only for FOPI
cbm_night	10	Etch32	40/40	only for CBM, runtime < 2 hours, run window from 19:00 to 7:00, dispatch window 19:00 to 0:00
hades_night	10	Etch32	34/34	only for HADES, runtime < 4 hours, run window from 21:00 to 8:00, dispatch window 21:00 to 6:00
alice-t3_train	9	Lenny64	0/1400	only for ALICE
alice-t3	8	Lenny64	0/2300	only for ALICE

Job priorities

Fairshare scheduling for all users is enabled.

Attention

Normal output of batch jobs (stdout, stderr) will automatically be sent to you via e-mail by the LSF system. Please keep that output small or write it directly into a file (e.g. by appending > _filename 2&>1 to your command). We got e-mails larger than 500 MBytes in the past.
Output is also written to the directory .lsbatch in your home directory. This directory should be cleaned from time to time: we have seen ~/.lsbatch directories of more than 30 GB, flooding the entire home file system.
A way to prevent this is to create a symbolic link .lsbatch in your home directory pointing to the scratch file system :

cpreuss@lxi010:~$ mkdir /s/cpreuss/.lsbatch cpreuss@lxi010:~$ ln -s /s/cpreuss/.lsbatch .lsbatch

cpreuss@lxi010:~$ ls -al .lsbatch lrwxrwxrwx 1 cpreuss rz 19 2009-03-10 08:39 .lsbatch -> /s/cpreuss/.lsbatch

To redirect the job output you can also use the options -o (append) or -oo (overwrite) for bsub. In this case you will not receive an e-mail notification after your job has been finished unless you're using the option -N additionally, e.g. bsub -o /path/to/outputfile -N yourjob.

Command line tools

Alle Befehle besitzen die Optionen -h für eine kurze Hilfe und -V für die Version. Die in [] angegebenen Optionen sind optional, | steht für ODER. Die Option -u ...|all (bei Jobsubmission/Jobcontrolling) ist nur für Root und LSF-Admins von Bedeutung, da nur diese Jobs anderer User beeinflussen können. Die Verwendung der JobID 0 beeinflusst nur die eigenen Jobs.

Job submission

bsub

lsrun

lsgrun

Job controlling

bstop

bsuspend

bresume

bkill

bkill [ -l ] [ -s (signal_value|sig nal_name ) ]
 [ -q queue_name ] [ -m host_name ]
 [ -J job_name ] [ jobId | "jobId[index_list]" ... ]

-l
 Zeigt die verfügbaren Signalnamen an..
-s value | name
 Sendet das spezifizierte Signal an die angegebenen Jobs. Standard: SIGKILL oder 9.
-q queue
 Send a signal to the jobs in the specified queue.
-m host
 Send a signal to the jobs dispatched to the specified host or host group.
 Ignored if a job ID other than 0 is specified.
-J jobname
 Send a signal to the named jobs.
 Ignored if a job ID other than 0 is specified.
JobID(s) | 0
 Send a signal to the specified job(s) or all jobs.

brequeue : Killt und/oder resubmittet Jobs

brequeue [-J job_name | -J "job_name[index_list]"] [ job_ID | "job_ID[index_list]"] [-d] [-e] [-r] [-a] [-H]
              Since job names are not unique, multiple job arrays may have the same name with a different or same set of indices.
       job_ID | "job_ID[index_list]"
              Operates on the specified job or job array elements.
              The value of 0 for job_ID is ignored.
       -d
             Resubmittet Jobs, mit dem Status DONE.
       -e
             Resubmittet Jobs, mit dem Status EXIT.
       -r
             Killt und resubmittet Jobs, mit dem Status RUN.
       -a
              Killt und resubmittet alle Jobs.
       -H
              Killt und resubmittet Jobs, mit dem Status PSUSP.

bswitch

Information retrieval

bjobs

bhist

bacct

bqueues

Tools with GUI

xlsmon: GUI Monitor für LSF

Die Rechenlast der LSF-Farm kann mit xlsmon beobachtet werden. xlsmon zeichnet die zur Lastverteilung verwendeten Resourcen, wie CPU, I/O, Paging, etc für die einzelnen Nodes auf:

Zusätzlich stehen History Load Informationen zur Verfügung, die wahlweise auf einzelne Nodes beschränkt werden können:

lsload: Show the current Load

lsload bzw lsmon liefern die xlsmon Informationen im Terminal Mode.

HOST_NAME status r15s r1m r15m ut pg ls it tmp swp mem
linux5.gsi.de ok 0.0 0.0 0.0 0% 0.5 2 10 15G 128M 236M
linux4.gsi.de ok 0.0 0.0 0.2 6% 4.2 6 2 14G 125M 213M
linux2.gsi.de ok 2.0 2.0 1.7 100% 0.6 5 2 14G 127M 222M
linux1.gsi.de ok 2.3 1.5 0.2 100% 2.9 10 0 13G 128M 186M
linux3.gsi.de unavail

xlsbatch: GUI für LSF Batch

xlsbatch ist das Usertool, um Jobs abzuschicken, die Priorität innerhalb der eigenen Jobs zu verändern, eigene Jobs zu killen oder den Output des Jobs während der Ausführung anzuschauen (Peek). Außerdem können Informationen über Jobdetails und History abgefragt werden.

bqueues: Queue Information

Die BatchQueues können mit bqueues auf der Konsole abgefragt werden.

xlsbatch oder xbsub: Submit a Job

xbsub ist ein Untermenue von xlsbatch, kann jedoch auch direkt aufgerufen werden. Die gewünschten Optionen werden über das Menue eingegeben, Advanced Angaben über Pre-Exec Commands, Job Dependences etc über ein weiteres Untermenue:

Die Resource Limits sind Soft Limits, die vom User gesetzt werden können. Ein Hard Limit für diese Resourcen kann über die Queues definiert werden. Dies ist momentan in der Linux Farm nur für Queues short und quick beim CPU Limit verwirklicht.

xlsbatch oder xbsub: Remote File Transfer

Über die Remote File Transfer Feature ist es möglich, etwa ohne NFS auf die Daten des Submission Hosts zu zugreifen. Diese Feature kann über den Advanced Button des xlsbatch/xbsub Menues angesprochen werden:

bjobs: Display Job Details

bjobs [-l | -w] [-a] [-d] [-p] [-s] [-r] [-N spec] [-q queue]
[-m host|cluster] [-u user|all] [-J jobname] [-P project] [jobId...]

-l
 Display information in a (long) multi-line format.
-w
 Display fields in a (long) multi-line format without truncation.
-a
 Display information about all jobs, including unfinished jobs
 (pending, running or suspended) and recently finished jobs.
-d
 Display only recently finished jobs.
-p
 Display only pending jobs, with the reasons they were not
 dispatched during the last dispatch turn.
-s
 Display only suspended jobs, showing the reason for suspension.
-r
 Display only running jobs.
-N spec
 Display CPU time consumed by the job.
 The appropriate CPU scaling factor for the specified host,
 or defined host model, is used to normalize the actual CPU time
 consumed by the job.
-q queue
 Display only jobs in the named queue.
-m hostname
 Display only jobs dispatched to the named host or host group.
-u user|all
 Display jobs submitted by the named user or by all users.
 Default: display the jobs submitted by the user who invoked
 this command.
-J jobname
 Display all jobs with the s[ecified name.
-P project
 Display only jobs belonging to the named project.
 Default: display jobs belonging to all projects.
jobId...
 Display the job(s) with the specified job ID.
 The value 0 is ignored.

bhist Displays history of Job(s)

bhist [-b] [-l] [-w] [-a] [-d] [-p] [-s] [-r] [-f logfile] [-N spec]
[-C time0,time1] [-S time0,time1] [-D time0,time1] [-q queue] [-m host]
[-u user|all] [-J job] [-n number] [-P project] [jobId...]

-b
 Display the job history in a brief format.
 Default: display summary format.
-l
 Display the job history in a (long) multi-line format,
 giving detailed information about each job.
 Default: display summary format.
-w
 Display the job history in a (wide) multi-line format without
 truncation. Default: display summary format.
-a
 Display all, both finished and unfinished, jobs.
 Default: finished jobs are not displayed.
-d
 Display only the finished jobs.
-p
 Display only the pending jobs.
-s
 Display only the suspended jobs.
 If option -l or -b is also specified, show the reason why
 each job was suspended.
-r
 Display only the running jobs.
-f logfile
 Specify the file name of the event log file.
 Either an absolute or a relative path name may be specified.
 Default: use the system event log file lsb.events.
-N spec
 Display CPU time consumed by the job.
 The appropriate CPU scaling factor for the specified host,
 or defined host model, is used to normalize the actual
 CPU time consumed by the job.
-C time0,time1
 Display only those jobs whose completion or exit times
 were between time0 and time1.
 Default: display all jobs that have completed or exited.
-S time0,time1
 Display only those jobs whose submission times were between
 time0 and time1.
 Default: display all jobs that have been submitted.
-D time0,time1
 Display only those jobs whose dispatch times were between
 time0 and time1.
 Default: display all jobs that have been dispatched.
-q queue
 Display jobs submitted to the specified queue only.
 Default: display all queues.
-m host
 Display jobs dispatched to the specified host only.
 Default: display all hosts.
-u user|all
 Display jobs submitted by the named user or by all users.
 Default: display the jobs submitted by the user who invoked this command.
-J jobname
 Display all jobs with the s[ecified name.
-P project
 Display only jobs belonging to the named project.
 Default: display jobs belonging to all projects.
jobId...
 Display the specified job(s).

bpeek Display Output and Error Output (std) of unfinished Jobs

bpeek [-f] [-q queue | -m host | -J jobname | jobId]

-f
 Display the output of the job using the command "tail -f".
 Default: use the command "cat".
-q queue
 Display the output of the most recently submitted job in
 the specified queue.
-m host
 Display the output of the most recently submitted job that
 has been dispatched to the specified host.
-J jobname
 Display the output of the most recently submitted job that
 has the given name.
jobId
 Display the output of the specified job.
 Default: display the output of the most recently submitted
 job that satisfies options -q, -m, or -J.

bsub Command Line Submit

Das Command Line Submit bsub ist in vielen Fällen flexibler als das graphische Tool xbsub, insbesonders bei der Verwendung in LSF Scripts.

 bsub [ -h ] [ -V ] [ -H ] [ -x ] [ -r ] [ -N ] [ -B ] [ -I | -Ip |
 -Is | -K ]
 [ -q queue_name ... ] [ -m host_name[+[pref_level]] . ]
 [ -n min_proc[,max_proc] ] [ -R res_req ]
 [ -J job_name_spec ] [ -b begin_time ]
 [ -t term_time ] [ -i in_file ] [ -o out_file ]
 [ -e err_file ] [ -u mail_user ] [ [ -f " lfile op [
 rfile ]" ] .. ]
 [ -E "pre_exec_command [ argument ... ]" ]
 [ -c cpu_limit[/host_spec ] ] [ -F file_limit ]
 [ -W run_limit[/host_spec ] ]
 [ -M mem_limit ] [ -D data_limit ] [ -S stack_limit ]
 [ -C core_limit ]
 [ -k "chkpnt_dir [ chkpnt_period ]" ]
 [ -w depend_cond ] [ -L login_shell ]
 [ -P project_name ] [ -G user_group ]
 [ command [ argument ... ] ]

Job Scripts werden in Unix/Linux erstellt und können interactiv oder als Files zur Verfügung gestellt werden, etwa in der hier interactiven Form:

# submit a Job in Queue Short

bsub -q short

# change working directory
bsub > cd /u/lasi/lsf
# submit Job myjob with Parameter 1
bsub > myjob 1
# change Jobname to TESTJOB
bsub > #BSUB -J TESTJOB
# submit the Job
bsub > ^D

# submit a Job to Queue batch

bsub -q batch

# change Submit Queue to test
bsub > #BSUB -q test
# send output to data/out and submit the Job to a
# host with > 100 MB available Memory
bsub > -o data/out -R "mem > 100"
# submit Job cpu with Paramter 20
bsub > cpu 20
# change Jobname to TEST1
bsub > #BSUB -J TEST1
# submit the Job
bsub > ^D

bsub: Erklärung einiger Parameter

Job Arrays :

bsub -J myjobs[1-500,5] /bin/hostname

Der Job myjobs besteht aus 100 Jobs (1-500 / 5). Der Status kann mittels bjobs -A JobID abgefragt und als Tabelle angezeigt werden.

Job Dependencies: bsub -w depend_cond ...

Beispiel: Jobs werden erst gestartet, wenn andere erfolgreich beendet sind

bsub -w " FirstJob && SecJob " -J ThrdJob myjob

Der Job myjob wird unter dem Namen ThrdJob gestartet, nachdem die beiden Jobs *FirstJob * und SecJob beendet wurden.

Der Job Status -w *started / done / exit / ended * kann abgefragt werden. Default bei -w Angabe ist done.

Host dependent Jobs: bsub -m $LSB_HOSTS

Beispiel: Starten von x-Jobs auf dem Host des VorJobs

Command Line: bsub myjob 1

File myjob :

i=$1

i=`expr $i + 1`

while i=`expr $i - 1 `; do
   bsub -q batch -m $LSB_HOSTS /u/lasi/c/cpu$i 20
done

Alle innerhalb myjob gestarteten Jobs werden auf dem Host gestartet, der für bsub myjob 1 von LSF ausgewählt wurde.

Preexecution Commands bsub -E pre_exec_command

Beispiel: Abfrage des tmp Spaces eines beliebigen Hosts und gegebenenfalls Cleanup durch Deleten aller tmp Files, vor Aufruf eines Programms

File myjob3:

set `df tmp`

if [$11 -lt 10000000 ]; then
   # freier Space unter 10 GB ?
   date=`/bin/date`
   uname=`/bin/uname -nm`
   echo "Cleanup started on $uname at $date"
   direct=/
   expr 0 = `/bin/ls -1Aq ${direct}tmp | \
      /usr/bin/grep -v "\`/bin/echo '[ \t]'\`" | \
      /usr/bin/wc -l` > /dev/null
   case $? in
      1 )
         ESC_direct=`echo "${direct}" | /bin/sed "s!/!\\\\\\\\/!g"`
         /bin/ls -1Aq ${direct}tmp | \
            /usr/bin/grep -v "`/bin/echo '[ \t]'`" | \
            /bin/sed "s/^/${ESC_direct}tmp\//" | \

            # Delete all /tmp Files

            /usr/bin/xargs -e /bin/sh -c '`/usr/bin/find ${0} ${@} \
            -type f -exec rm {} 2> /dev/null \; `' 
      ;;
   esac
fi

Aufruf von myjob3 als Preexecution Command

Command Line: bsub myjob_preex

File myjob_preex :

bsub -E lsf/myjob3 -q batch -m $LSB_HOSTS c/cpu 20

Das Programm c/cpu wird nur ausgefuehrt, wenn der Job lsf/myjob3 erfolgreich beendet wurde.

Remote File Access...*bsub -f "[lfile op rfile]]" *

Falls ein File auf dem Execution Host nicht verfügbar ist, z.B. durch NFS Probleme, besteht die Möglichkeit, diesen File vom Submission Host auf den Execution Host zu kopieren. Etwa von linux2 nach linux1:

user@lxi007:/u/user> bsub -m linux1 -f "/tmp/mb >" myjob

kopiert vor Ausführung des Programms myjob die Datei /tmp/mb von linux2 nach linux1.

Parallel Jobs...*bsub -n min_proc,_max_proc_*

Es wird versucht max_proc Prozessoren dem entsprechenden Job zur Verfügung zu stellen. Der Job wird nur gestartet, wenn mindestens min_proc Prozessoren allokiert werden können. Nach Jobstart werden keine zusätzlichen Prozessoren verwendet.

Mit Hilfe der JobSlot Reservation Feature können Prozessoren für eine bestimmte Zeit reserviert werden. Dadurch vergrößert sich die Wahrscheinlichkeit die gewünschte Anzahl an Prozessoren zu erhalten.

bsub oder lsrun: Run an Interactive Remote Job

Interaktive Jobs sind auf unmittelbare Benutzereingaben angewiesen.

LSF kann über Konsole oder GUI direkt den Kontakt mit dem Execution Host ermöglichen, selbst Tastenkombinationen wie Ctrl-C verhalten sich wie bei lokalen Anwendungen. Wird die Interactive Job Facility über bsub angesprochen, so verlängern sich die Wartezeiten vor Start um die Job Pending Zeiten.

Interactive Jobs: bsub -I

bsub wartet bis das entsprechende Kommando abgearbeitet ist, z.B.:

bsub -I -m linux3 dir /tmp/scratch

Der Output erfolgt in diesem Fall auf das Terminal.

Ein effizienterer Weg führt über das Kommando lsrun, das eine sofortige Ausführung ermöglicht.

Interaktive Jobs lsrun

lsrun -m linux3 dir /tmp/scratch

In beiden Fällen ist auch interaktive Remote Execution über ein Pseudo-Terminal realisierbar:

lsrun -m linux3 -P vi /tmp/m1

bzw.

bsub -Ip -m linux3 vi /tmp/m1

lsgrun: Run interactive parallel Jobs

Der entsprechende Job wird interaktiv auf den angegebenen Rechnern bearbeitet. Im nachfolgenden Beispiel werden nacheinander die Dateien /tmp/m1 auf den Hosts linux1=-=linux3 zusammengefasst:

lsgrun -m "linux1 linux2 linux3" cat /tmp/m1 >> /tmp/m1

Um diese Files simultan zu löschen, kann man die lsgrun Option -p (parallel) verwenden:

lsgrun -m "linux1 linux2 linux3" -p rm /tmp/m1

---

-- CarstenPreuss - 15 Apr 2009

-- Bärbel Lasitschka - Jun 1999 -- Christo - 06 Apr 2004