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