Infrastruktur: Der Biocluster
Der Bioinformatik-Cluster ist seit dem 19.12.2011 in Betrieb und steht allen Studierenden der Bioinformatik zur Verfügung. Der Cluster wurde aus Studienbeiträgen finanziert.
Hardware
Der Cluster steht im Serverraum der Bioinformatik in der Amalienstr. 17 und besteht aus 2 Servern und
10 Rechenknoten.
Bei den
Servern handelt es sich um zwei Hewlett-Packard DL 360 mit 2x Xeon E5620 (2.4 GHz, 4-Core) und 48 GB RAM.
bioserver1.bio.ifi.lmu.de ist der NFS-, Web- und
Mysql-Server und erlaubt keine interaktiven Logins.
bioserver2.bio.ifi.lmu.de dient als Ersatzserver und arbeitet im
Normalfall als normaler Rechenknoten im Grid.
Die 10
Rechenknoten stammen von RaidMedia und sind mit ebenfalls mit 2 Xeon E5620 und 48 GB RAM ausgestattet. Sie heißen
bioclient1[-10].bio.ifi.lmu.de
Zugriffsrechte
Jeder Biofinformatik-Student kann sich mit seinem CIP-Login auf dem Bioinformatik-Cluster
einloggen.
Das interaktive Login zum Ausprobieren oder Compilieren von Programmen ist nur auf
bioclient1.bio.ifi.lmu.de gestattet. Das Login auf die anderen Knoten ist zwar möglich, um
z.B. lokale Daten in /usr/local/storage anzuschauen. Berechnungen oder sonstige Programme
dürfen jedoch außer auf bioclient1 nur über das Grid gestartet werden. Wichtig: Der sshd läuft auf allen Hosts auf Port 12 statt 22. Unter Linux also slogin -p 12 bioclient1 .
Home-Directories und Storage
Die Homedirectories auf dem Biocluster sind dieselben wie im CIP-Pool.
Zusätzlicher Storage auf /mnt/biocluster/
muss beantragt werden, z.B. für Masterarbeiten oder Praktika.
Außerhalb des Bioclusters ist /mnt/biocluster/ nur im CIP-Pool in der
Amalienstr. 17 gemountet.
In /mnt/biocluster/tmp kann jeder schreiben. Wir empfehlen dringend, dieses Verzeichniss
für temporäre Daten bei Grid-Berechnungen zu nutzen und nach der Berechnung nur die
wirklich benötigten Daten in euer Home-Verzeichnis zu kopieren, da es für das tmp-Verzeichnis kein
Backup gibt und es regelmäßig aufgeräumt wird.
Zusätzlich kann für temporäre Daten auf jedem bioclient /usr/local/storage mit
einer Größe von 850 GB genutzt werden (siehe Grid-Jobs unten).
Unter /mnt/biosoft/ stellt der Lehrstuhl (nach und nach) Software und Daten zur
Verfügung, die für Praktika etc. benutzt werden können. Auch dieses Verzeichnis ist
in gemountet. In diesem Verzeichnis können auf Anfrage auch gemeinsame
Projektverzeichnisse für mehrere Studenten angelegt werden.
Grid-Nutzung
Auf den Rechenknoten läuft eine Sun-Grid-Engine. Jobs können von bioclient1 und von jedem
CIP-Rechner in der Amalienstr. submitted werden.
Projekte/Queues
Rechenjobs werden in bestimmte Queues submitted. Auf dem Biocluster werden jedoch Projekte statt
Queues verwendet. Der Unterschied besteht darin, dass ein Projekt Jobs in mehrere Queues verteilen
kann. Wenn z.B. ein Job in das Praktikums-Projekt submitted wird, kann das Grid ihn entweder in die
speziell reservierte Praktikums-Queue oder auch in die normale Short-Queue stecken, falls dort nicht viel los ist.
Es gibt auf dem Biocluster 3 Projekte: long_proj , short_proj und and prakt_proj . Jobs im
short-Projekt werden nach 30 Minuten automatisch beendet. Längere Jobs müssen explizit in das
long-Projekt submitted werden. Über das prakt-Projekt werden bei Praktika einem beschränkten
Benutzerkreis spezielle Resourcen reserviert. Jobs die in short-Projekt submittet werden, können
auf allen Knoten laufen, jobs die in long-Projekt submittet werden, werden nur auf eine Untermenge
der Knoten ausgeführt. Es empfehlt sich, die Berechnungen in Blöcke von weniger als 30 Minuten zu unterteilen, dadurch
werden die jobs insgesamt schneller bearbeitet. Jobs, die ins prakt_proj submittet werden, laufen nur, wenn
der Benutzer in die Praktikums-Benutzerliste aufgenommen wurde (macht der grid admin).
Job-Kontrolle
Ausführliche Infos zu den nachfolgend beschriebenen Grid-Befehlen findet man im Grid User's Guide .
Vor Benutzung des Biocluster-Grid müssen die entsprechenden Parameter durch
. /mnt/biosoft/software/sge61/default/common/settings.sh
in der bash oder zsh gesetzt werden (für (t)csh mit source
.../settings.csh ).
Die Grid-Binaries wie qsub etc. befinden sich in
/mnt/biosoft/software/sge61/bin/lx24-amd64/ . Es empfiehlt sich, ein kleines
Script zu schreiben, dass dieses Verzeichnis zum Pfad hinzufügt und die Settings-Datei
ausführt.
jobs können mit dem Befehl qsub submittet werden, z.B.:
qsub -b y -N testjob -P long_proj -l vf=1500M
-o $HOME/testjob/test.out
-e $HOME/testjob/test.err
Die wichtigsten Parameter von qsub:
Das <command> kann ein selbstgeschriebenes Script oder ein Aufruf
eines Binaries mit Parametern sein, z.B. sleep 10 oder
$HOME/bin/work_hard .
-P short_proj : gibt an, in welches Projekt der job submittet wird. Per default
wird alles in long_proj submittet.
-b y : Gibt an dass der zu submittende job binary ist. Ohne diesen Parameter wird
das command als Script interpretiert, das auch weitere Grid-Optionen enthalten kann (siehe
Users Guide). Man kann den Parameter auch für bash-Script etc. verwenden, in denen keine
Grid-Anweisungen enthalten sind. Das Script wird dann genau wie ein Binary einfach ausgeführt..
-l needed_resource : Spezifiziert die benötigten Resourcen für den
Job (# CPUs, Memory usw.).
WICHTIG: Bei jobs, die größere Mengen
an Hauptspeicher benötigen, bitte durch -l vf=1024M (für 1 GB) die
benötigte Menge spezifizieren.
Ansonsten kann es zum overbooking und damit zum killen einiger Jobs kommen, wenn der
Speicher voll ist (das kann leider jobs von jemand anderem auch betreffen). vf steht hier für Virtual
Free (memory).
Die andere resource die man spezifizieren könnte ist h_rt, i.e. wie lang der job vermutlich laufen wird.
Vor allem wenn während eines Praktikums jobs submittet werden, können sie ja mit -P prakt_proj submittet werden,
und landen so in allen queues, auch in der short queue. Wenn das nicht gewollt ist, da der job länger läuft kann man
es zB durch: -l vf=4000M,h_rt=12:00:00 angeben, daß der job um die 12:00 Stunden braucht, und somit
nicht für short.q geeignet ist.
Andere resourcen sind bis jetzt nicht konfiguriert, wenn jemand was
braucht, bitte Bescheid sagen.
-N name_of_the_job Default nimmt Grid den
Name des Skriptes.
-o output -e error Erlaubt die Angabe, wohin die normalen und
wohin die Fehlermeldungen des Jobs geschrieben werden sollen. Default ist ~/jobname.o$jobid und ~/jobname.e$jobid , wobei $jobid ist eine von
Grid vergebene sequentielle Nummer. Wenn die angegebene Pfade nicht lesbar oder schreibbar
sind, wird der job mit Fehlern abbrechen. Wenn die Ergebnisse vom Programm selbst woanders
hin geschrieben werden (z.B. nach mysql), kann man /dev/null für beide verwenden.
-wd und -cwd ("working directory" und "use current working directory").
Gibt an, in welchem Verzeichniss der job ausgeführt wird. Das spezifiziert
auch das default Verzeichniss für die Ausgabe/Error streams. Der Parameter ist vor allem
für array jobs (siehe unten) wichtig.
-m mail options Man kann angeben, bei welchen Aktionen eines Jobs eine Mail
geschickt werden soll:
Start (b ), Ende e , Suspend s , Abort a (zum Beispiel beim killen)
Array Jobs
Wenn man viele Jobs (oder aufgeteilte Jobs) submittet, kann man auch job arrays submitten.
Der qsub Parameter dafür ist -t <startid>:<endid> . Beim Ausführen
wird die Variable SGE_TASK_ID gesetzt. Mit -t 1:1000 wird der job 1000-mal
aufgerufen (so weit es geht parallel) mit der SGE_TASK_ID von 1 bis 1000. Die Ausgabe/Error streams
werden mit job-id und array-id versehen ins Arbeitverzeichniss geschrieben, also muss hier
-wd sinnvoll spezifiziert werden!
Beispielaufruf:
qsub -b y -N testjob -P short_proj -l vf=500M
-o $HOME/testjob/test.out -e $HOME/testjob/test.err
-wd $HOME/gridtest -t 1:1000
$HOME/bin/sleep.sh 100
Job Monitoring
Liste alle running jobs abfragen: qstat -s r
Liste eigene jobs abfragen: qstat -u $USER
Wenn der State eines Jobs 'E' beinhaltet, befindet dieser sich im Error state. Näheres kann
man mit qstat -j jobid abfragen. Da sieht man die
Scheduling Info und den den Grund des Fehlers.
Löschen von jobs
qdel [-f ] jobid löscht [mit force] ein job
qdel [-f ] -u user löscht alle jobs von einem Benutzer
Support
Bei Fragen zur Hardware oder allgemeinen Benutzung wendet ihr euch an
Frank Steiner
Zimmer 3-01, 3. Etage
Amalienstr. 17
Bei Fragen zum Grid wendet ihr euch an
Gergely Csaba
Zimmer 4-07, 4. Etage
Amalienstr. 17