Humboldt-Universität zu Berlin - Computer- und Medienservice

LSF (Load Sharing Facility)

LSF Logo

1. Charakteristik von LSF

Mit der LSF-Software wird ein System bereitgestellt, dass eine optimale Lastverteilung in einer heterogenen Umgebung (UNIX- und NT-Systeme) ermöglicht. LSF wird von der Firma Platform Computing Corp. in Kanada vertrieben. In Deutschland wird die Software durch die Firma s+c (Science and Computing) bereitgestellt. LSF ist ein netzwerkweites Batchsystem, das auch parallele Anwendungen unterstützt und damit ein gleichzeitiges Rechnen von seriellen und parallelen Jobs innerhalb des LSF-Clusters ermöglicht.

2. LSF-Cluster im Computer- und Medienservice

Im Computer- und Medienservice sind alle Computeserver (alle Knoten des LINUX Beowulf-Clusters) in dem LSF-Cluster CLOU4 ( CLuster Of Unix machines ) zusammengefasst. Eine genaue Beschreibung des LINUX Clusters findet man unter LINUX-Cluster ( clan ). Die von LSF benötigten Dämonen werden beim Start der einzelnen Knoten des Clusters gestartet. Die folgende Tabelle gibt eine Übersicht über die Dämonen auf den Servern und Knoten des LSF-Clusters CLOU4. Alle Dämonen sind während der gesamten Systemlaufzeit aktiv.


Dämon Funktion Hosts Hosts in CLOU4
lim Load Information Manager Master und Server clan[2-3],alle nodes
pim Process Information Manager Master und Server clan[2-3],alle nodes
res Remote Execution Server Master und Server clan[3],alle nodes
sbatchd Slave Batch Daemon Master und Server clan[3],alle nodes
mbatchd Master Batch Daemon Master clan2
mbschd Master Scheduler Daemon Master clan2

Kontrollkommandos:
lsid    listet LSF-Cluster- und Masternamen
lshosts listet Client- und Server-Hosts des LSF-Clusters
lsload  listet Informationen zum Load auf allen LSF-Hosts
bhosts  listet die auf den Hosts verfügbaren Ressourcen 

3. Queuekonfiguration

Das LSF-Cluster CLOU4 bietet durch die unterschiedliche Ausstattung der Knoten eine breite Palette von Anwendungsmöglichkeiten. Es können sowohl parallele als auch serielle Rechnungen ausgeführt werden.


Queue Knotenname Betriebssystem Prozessorlimit Slotlimit Runlimit Memorylimit
comp clan RedHat EL4 WS, 32-bit 1 1 60 min 1 GB
comp64 clan3,node41-46 RedHat EL4 ES, 64-bit 1 2 60 min 1 GB
ser clan RedHat EL4 WS, 32-bit 1 1 24 h 3 GB
ser64 clan3,node41-43 RedHat EL4 ES,WS 64-bit 1 9 24 h 2 GB
long64 node41,43 RedHat EL4 ES,WS 64-bit 1 8 7 d 2 GB
extlong64 node41,node43 RedHat EL4 WS, 64-bit 1 4 14 d 2 GB
par64 node41-46 RedHat EL4 WS, 64-bit 2-4 20 24 h 12 GB
par64l node44-46 RedHat EL4 WS, 64-bit 2-4 24 7 d 12 GB
inter clan RedHat EL4 WS, 32-bit 1 1 6 h 1 GB
inter64 clan3,node41-46 RedHat EL4 WS, 64-bit 1 4 6 h 1 GB

Für alle parallelen Programme sind die Queues par64 und par64l geeignet, da diese mehrere Prozessoren auf einem Knoten zur Verfügung stellen. Serielle Rechnungen sind an die Queues ser oder ser64 abzuschicken. Interaktive Rechnungen sind in die Queues inter oder inter64 zu stellen.

Das Kommando
bqueues

listet alle Queues in einer Kurzform auf. Es zeigt auch die Prioritäten der einzelnen Queues, sowie ihren Status (open oder closed, aktiv oder inaktiv). Eine exakte Auflistung aller Parameter einer Queue liefert das Kommando

bqueues -l par64

Eine inaktive Queue lässt bereits rechnende Jobs weiter laufen, bis sie beendet sind, aber kein neuer Job wird gestartet. Die Jobs verbleiben dann in der Warteschlange, bis die Queue wieder aktiv wird. Eine geschlossene Queue nimmt überhaupt keine Jobs an.
Nutzer einer Arbeitsgruppe werden auch unter LSF zu einer Gruppe zusammengefasst. Das Kommando

bugroup -l

listet die Nutzer aller Gruppen. Ein zugelassenes Kennzeichen muss in einer dieser Gruppen auftauchen. Anderenfalls kann unter dem Account kein Job an das LSF-Cluster abgeschickt werden. Außerdem muss die Arbeitsgruppe in der Queue unter USERS eingetragen sein.

4. Submitten von Jobs


Jobs, die an eine Queue abgeschickt werden sollen, können in ein Skript verpackt werden und mit dem Kommando "bsub" abgeschickt werden. Jede Menge Beispielskripte findet man im Verzeichnis /perm/run_test/clou4. Um z.B. das Skript "run_ser64" in die Queue "ser64" zu stellen ist das Kommando

bsub < run_ser64
zu verwenden.

Die Queue, in die der Job gestellt werden soll, kann in der Kommandozeile oder im Skript angegeben werden. Die Angabe in der Kommandozeile überschreibt die des Skriptes.

Alle Jobs, die nicht sofort abgearbeitet werden können, kommen in die Liste der wartenden Jobs (Pending-Liste). Ein Job muss auf die Abarbeitung warten, wenn entweder der Grenzwert für die Anzahl der Jobs in der Queue oder wenn der Grenzwert für die Anzahl der Jobs, die der Nutzer im LSF-Cluster starten darf (siehe busers unter MAX), bereits erreicht sind.

Der Nutzer erhält als Reaktion auf den Submit-Befehl die Antwort, dass der Auftrag akzeptiert wurde sowie die Nummer des Auftrages. Bei der Angabe einer falschen Queue wird der Auftrag nicht angenommen. Im Falle, dass die Parameter im Submit-Befehl nicht stimmen, z.B. die CPU-Zeit ist größer als die in der Queue erlaubte, so antwortet das System mit der Ausgabe: "CPULIMIT: Cannot exceed queue's hard limit(s). Job not submitted".

Die genaue Beschreibung der Optionen kann in dem Manual zu bsub nachgelesen werden.

MPI Jobs

Jobs, die unter MPI laufen sollen, sind mit dem Kommando mpirun zu starten. Um diese Jobs mittels LSF zu verwalten, müssen im Skript die Anzahl der gewünschten Tasks (z.B. 4), sowie die Methode der parallelen Kommunikation (z.B. mpich_gm) mitgeteilt werden. LSF organisiert dann die Verteilung der Tasks mit Hilfe des Parallel Job Launchers (PJL), des PJL Wrappers und des Parallel Application Manager (PAM). Die Tasks werden auf die von LSF zugewiesenen Hosts verteilt und dann über PAM gestartet. Im Skript wird durch Aufruf von mpirun.lsf mittels des PJL Wrappers das gewünschte mpirun Kommando gestartet. Auf dem Cluster werden die unterschiedlichen Compiler und Compilerversionen sowie die gewünschte Kommunikation mittels module Kommando geladen.

module load intel-comp-101-15
module load mpich-1.2.7p1-intel
which mpirun  -> liefert den Pfad des MPI Kommandos

Das folgende Beispiel

/perm/run_test/clou4/run_mpich_p4

lädt die Compilerumgebung für den Intel Compiler in der Version 10.1.015. Im mpirun wird das MPI Programm gerufen, das mit diesem Compiler erzeugt wurde. Es werden 4 Prozessoren angefordert. Mit der Option -a mpichp4 wird der Wrapper für das MPICH_P4 aufgerufen, d.h. das mpirun.lsf entspricht dem /usr/local/mpi/mpich-1.2.7p1-intel/bin/mpirun.ch_p4

Soll die Anzahl der Prozessoren variabel sein, so können mit der Option
#BSUB -n 2,4

2-4 Prozessoren angefordert werden. Das hat den Vorteil, dass der Job nicht warten muss, bis tatsächlich 4 Prozessoren verfügbar sind.
Der Nutzer findet auf allen Knoten des LSF-Clusters dieselbe Umgebung vor, d.h. sein Homeverzeichnis ist auf allen Rechnern identisch. Da die Homeverzeichnisse nur über einen geringen Speicherplatz verfügen, stehen auf allen Rechnern lokale /scratch Bereiche mit unterschiedlichen Kapazitäten zur Verfügung, die temporäre Daten aufnehmen können. Die Daten in den /scratch Bereichen unterliegen einem Kontrollmechanismus, sie sind dort nicht sicher gespeichert und müssen zur permanenten Ablage in das Verzeichnis /perm/$USER gesichert werden.

5. Kontrolle der laufenden Jobs


Die Kontrolle der laufenden Jobs erfolgt mit dem Kommando bjobs, es liefert Informationen zu

bjobs             den eigenen Jobs
bjobs -u all      allen laufenden Jobs
bjobs -u all -pl  allen wartenden Jobs und den Grund des Wartens
bjobs -s          allen eigenen suspendierten Jobs

Der Modifikation eines wartenden Jobs dienen die Kommandos

btop              setzt den Job an die Spitze der Wartenden
bswitch           lenkt den wartenden Job um in eine andere Queue
bmod              modifiziert den Job

Zum Abbrechen oder Anhalten laufender oder wartender Jobs dienen die Kommandos

bkill <jobid>     bricht den Job ab
bstop <jobid>     hält den Job an (suspendiert ihn)
bresume <jobid>   fährt fort mit dem angehaltenen Job       

Auch für die Kontrolle der laufenden Jobs existiert ein GUI ( xlsbatch ).

6. LSF Dokumentationen