Infrastructure: The Biocluster

Der Cluster steht im Serverraum der Bioinformatik in der Amalienstr. 17 und besteht aus 2 Servern, 10 Rechenknoten und einem Raid mit 3.5 TB Festplattenplatz.

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

• 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 24 statt 22. Unter Linux also slogin -p 24 bioclient1.

• Die Homedirectories auf dem Biocluster sind dieselben wie im CIP-Pool.
• Der zusätzliche Storage von 3.5 TB ist auf dem Biocluster unter /home/proj/biocluster/ erreichbar. Es gibt dort im Unterverzeichnis stud/ für jeden Bioinformatik-Studenten ein schreibbares Verzeichnis mit seinem Namen.
• Außerhalb des Bioclusters ist /home/proj/biocluster/ nur im CIP-Pool in der Amalienstr. 17 gemountet.
• Es gibt keine Quota für /home/proj/biocluster/. Ihr könnt den Platz dort nutzen, bis er voll ist. Danach schreiben wir diejenigen mit den größten Verzeichnissen an, damit sie Platz schaffen. Es ist also in eurem eigenen Interesse, euer Verzeichnis hin und wieder aufzuräumen.
• /home/proj/biocluster/ wird jede Nacht ins LRZ gesichert.
• In /home/proj/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 biocluster- oder euer Home-Verzeichnis zu kopieren. Zum einen wird dieses Verzeichnis nicht gesichert, wodurch das Backup schneller wird, zum anderen können wir im Zweifel durch Löschen aus diesem Verzeichnis schnell Platz schaffen, wenn das Raid voll sein sollte.
• 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 /home/proj/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.

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 bBeschriebenen Grid-Befehlen findet man im Grid User's Guide.

• Vor Benutzung des Biocluster-Grid müssen die entsprechenden Parameter durch

  . /home/proj/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 /home/proj/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 
    <i><command></i>

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

Bei Fragen zur Hardware oder allgemeinen Benutzung wendet ihr euch an

Frank Steiner

Zimmer 3-01, 3. Etage

Amalienstr. 17

biocluster * at * bio.ifi.lmu.de

Bei Fragen zum Grid wendet ihr euch an

Gergely Csaba

Zimmer 4-07, 4. Etage

Amalienstr. 17

biogrid * at * bio.ifi.lmu.de