Seite druckenPDF Version herunterladenSeitenstruktur anzeigenSeite durchsuchen
nach oben

Vorbemerkungen

  • Für das Hochleistungsrechnen am RRZ der Universität Hamburg steht seit 2009 ein Linux Cluster mit Intel-Harpertown-CPUs zur Verfügung. Die Benutzung des Parallelrechners setzt eine besondere Zugangsberechtigung in Form einer projektbezogenen Kennung voraus. Bitte lesen sie weitere Informationen zu Projektkennungen der Benutzerverwaltung.
    Bitte geben Sie auf dem Formular zusätzliche eine aktive eMail-Adresse an, falls Sie die mit der Projektkennung vergebene Adresse nicht nutzen! Das beschleunigt das Verfahren.
  • Projekte mit sehr hohen Ressourcenanforderungen können im Rahmen des HLRN (Norddeutscher Verbund für Hoch- und Höchstleistungsrechnen) bearbeitet werden. Als lokaler Ansprechpartner fungiert das Rechenzentrum als Schnittstelle zwischen dem HLRN und den Nutzern. Ein Projektantrag auf Benutzung des HLRN-Systems kann direkt beim HLRN über ein Web-Formular gestellt werden.

Informationen zum Linux-Cluster

Hardware

Die nutzbaren Knotentypen sind:

  • 68 Computenodes: 2x Intel Xeon E5462 Quad Core, 8x2,80 GHz, FSB 1600 MHz, 16 GB RAM (Knotentyp c)
  • 20 Computenodes: 2x Intel Xeon E5462 Quad Core, 8x2,80 GHz, FSB 1600 MHz, 32 GB RAM (Knotentyp d)
  • 2 Computenodes: 2x Intel Xeon E5640 Quad Core, 8x2,66 GHz, FSB 1333 MHz, 96 GB RAM

Datentransfer (NFS, ssh): Gigabit Ethernet, Fileserver mit 10 Gb/s
Interprozess-Kommunikation: Infiniband DDR 4x

Betriebssystem

GNU/Linux auf x86-64 (SLES10SP2, Kernel 2.6.16.60)

Batch-System und Scheduler

Aufträge an den Cluster werden mit einem Batch-System verwaltet. Als solches wird Torque in der Version 2.3.6 mit Maui in der Version 3.2.6p21 als Scheduler eingesetzt. Bitte beachten Sie unsere Hinweise zur Bedienung des Batch-Systems.

Login

Der Loginknoten des Clusters hpclogin.rrz.uni-hamburg.de ist weltweit per SSH über die IP-Adresse 134.100.32.122 zu erreichen.

Storage

Den Benutzern ($USER als Platzhalter für die Kennung) stehen folgende Verzeichnisse zur Verfügung:

Heimatdateisystem /G/home/$USER (Home, 6,3 TiB gesamt)

Hier gilt ein Quota von 200GB Soft- und 250GB Hardlimit. Daten im Home werden täglich im Backup-System gesichert. Dieses Dateisystem ist global auf allen Knoten verfügbar. Hier haben Programme/Skripte sowie moderate Log-Dateien ihren Platz. Primär liegen hier Dinge, die der Nutzer selbst berarbeitet, im Gegensatz zu den automatisch reproduzierbaren Ergebnissen von Rechenjobs.

Ausgabedaten / Analyseergebnisse können hier zwischengelagert werden und genießen auch gewisse Sicherheit durch das Backup. Langfristig sollten Nutzer aber ihre Ergebnisse auf eigene Systeme kopieren (per ssh bzw. scp). Es sollte vermieden werden, intensive Dateioperationen von Rechenjobs unter /G/home auszuführen!

Globales Arbeitsverzeichnis /G/scratch/$USER (Scratch, 5,4 TiB gesamt)

Dieses für alle Knoten verfügbare Verzeichnis ist für Vorbereitung und Ergebnisse von Rechenjobs gedacht. Einfache Dateioperationen (Einlesen von Eingabedaten oder Produktion von Ausgabedaten als kontinuierlicher Strom bzw. in großen Blöcken) können auch von den Jobs direkt hier durchgeführt werden. Aufwändigere Operationen mit starker Beanspruchung (klassisch als „scratch I/O“ bezeichnet) sind in der Regel auf lokalem Speicherplatz besser aufgehoben, da sich die Zugriffe verschiedener Knoten sonst gegenseitig behindern und das Dateisystem für alle Nutzer ausbremsen.

Es gibt hier kein Quota und kein Backup. Nutzer, die längerfristig große Datenmengen auf /G/scratch belegt haben werden aufgefordert, alte Daten zu löschen. Wichtige Ergebnisse sollten zeitnah auf eigene Dateisysteme kopiert werden (im Rahmen der Quota-Grenze auch zwischenzeitlich im Home). Bei akuter Überfüllung von /G/scratch können Daten ohne Vorwarnung gelöscht werden, um den Betrieb sicherzustellen!

Temporäres Job-Arbeitsverzeichnis ($TMPDIR)

Für intensive Dateioperationen (im Zweifelsfall für alle transienten Daten des Jobs) wird für jeden Job automatisch ein temporäres Verzeichnis angelegt. Nach Beendigung des Jobs wird dieses auch automatisch wieder gelöscht. Im Normalfall liegt es auf der lokalen Festplatte des ersten Knotens für den Job und ist für alle anderen Knoten transparent erreichbar. Es ist sehr wichtig, dass temporäre Daten, wie sie z.B. Gaussian und Schrödinger-Anwendungen erzeugen, bevorzugt auf lokalen Dateisystemen liegen, um den Cluster effizient zu nutzen.

Die Shell-Variable $TMPDIR enthält den Pfad des erzeugten und für den Job spezifischen Verzeichnisses. Man erhält sie durch zwei Zeilen im Job-Script, für Bourne Shell (sh, bash):

source /G/home/rrz/lib/modules.sh
module load rrz/tmpdir

und für C-Shell (csh, tcsh):

source /G/home/rrz/lib/modules.csh
module load rrz/tmpdir

Danach kann der durch $TMPDIR angegebene Ort für temporäre Daten genutzt werden. Es werden automatisch Variablen gesetzt, die bestimmte Programme dazu veranlassen, temporäre Daten dort zu speichern. Dazu gehören $GAUSS_SCRDIR (Gaussian) und $SCHRODINGER_TMPDIR. Insbesondere die Einstellung für Gaussian ist wegen der intensiv genutzten .rwf-Dateien wichtig. Falls man weiß, dass mehr als 100 GiB temporärer Speicherplatz benötigt werden, kann mittels der Variable $RRZ_TMPDIR_GLOBAL erzwungen werden, dass $TMPDIR auf /G/scratch eingerichtet wird. Das sollte aber die Ausnahme sein. Der qsub-Aufruf sieht dann z.B. so aus:

qsub -v RRZ_TMPDIR_GLOBAL=1 -q c8 jobscript.sh

Das zu einem aktiven eigenen Job gehörige temporäre Arbeitsverzeichnis kann vom Nutzer unter Kenntnis der Job-ID mit dem Befehl

/G/home/rrz/bin/rrz-job-get-tmpdir $job_id

erfragt werden. Solange der Job läuft, is dieses Verzeichnis auch vom Login-Knoten aus einsehbar. Da es mit Beendigung (auch Abbruch) des Jobs notwendigerweise gelöscht wird, sollte der Job so gestaltet sein, dass er notwendige Zwischenergebnisse bzw. Restart-Files an permanenter Stelle hinterlässt. Auch wenn dieser Aspekt unbequem erscheint, sollte unbedingt mit dem unabhängigen $TMPDIR gearbeitet werden, damit der gesamte Cluster sinnvoll ausgelastet ist.

Bitte beachten Sie: Der alte Mechanismus, per Variable PBS_LOCAL_SCRATCH ein lokales Arbeitsverzeichnis anzufordern, ist nun überflüssig und wird in Zukunft, sobald gesichert ist, dass kein Job diesen mehr braucht, deaktiviert.

Autor: Elisabeth Kahnert, Stand: 07.07.2014 18:39 Uhr

 Impressum  Datenschutzerklärung