IA32/EM64T/AMD64 Compute-Cluster

Das IA32/EM64T/AMD64-Cluster des RRZE (Firma Transtec) besteht aus momentan 155 Rechenknoten, zwei Frontends und drei Servern mit folgenden Merkmalen:

• 64 Rechenknoten, 2x Xeon 3.20 GHz "Nocona" (800 MHz FSB / 666 MHz RAM), 2 GByte RAM, 80 GB IDE Festplatte pro Knoten

• 25 Rechenknoten, quad (2x Dual Core) Opteron 2.0 GHz (800 MHz FSB, ccNUMA), 4 GByte RAM, 80 GB IDE Festplatte pro Knoten

• 66 "Port Townsend" Rechenknoten, dual (1x Dual Core) Xeon 3070 2.67 GHz (Core2-Architektur, 1066 MHz FSB), 4 GByte RAM, 160 GB IDE Festplatte pro Knoten

• 2 Frontends, 2x Xeon 3.20 GHz "Nocona", Ausstattung wie Rechenknoten, jedoch 4 GB RAM und aktiviertem Hyperthreading

• 1 File-Server mit 2x Xeon 2.8 Ghz, 5.8 TB Kapazität, externes IDE-RAID mit RAID 5

• 1 File-Server mit 2x Quadcore-Xeons E5320 1.86 Ghz, 13 TB Kapazität, zwei externe SATA-RAID-Boxen mit RAID 6

• 1 File-Server mit 2x Quadcore-Xeon E5430 2.66 Ghz, 500 GB Kapazität, internes SCSI-RAID 5 für Softwareverteilung

Die Vernetzung der Maschinen ist durchgehend mit Gigabit Ethernet (GE) ausgeführt. 24 der "Nocona"- und alle "Port-Townsend"-Knoten haben zusätzlich Infiniband-Karten und sind über einen entsprechenden Switch vernetzt. Infiniband hat gegenüber GE den entscheidenden Vorteil einer 10 bzw. 20-fach höheren Bandbreite und einer ca. um den Faktor 5 geringeren Latenz. Bei Interesse an einer Nutzung des Infiniband-Netzwerks wenden Sie sich bitte an die HPC-Beratung.

Das Cluster wurde über sehr lange Zeit und sehr oft erweitert, wodurch die Hardware nicht homogen ist. Der allererste Teil des Clusters war sogar noch mit 32 Bit CPUs bestückt, dieser wurde jedoch Ende August 2009 abgeschaltet, so dass das Cluster inzwischen komplett aus 64 bit CPUs besteht und unter einem 64-Bit Betriebssystem läuft.

Zu beachten ist, dass die Nocona- wie die Opteron-Knoten teilweise für Spezialaufgaben einiger Lehrstühle bzw. eines SFB beschafft wurden und deswegen die Nutzung für normale Anwender eingschränkt ist.

Weiter unten auf dieser Seite finden Sie Informationen zu den Themen

• Zugang, Umgebung und Filesysteme
• Compiler und Tools
• Paralleles Rechnen
• Mathematische Bibliotheken
• Batch-Betrieb
• Port-Townsend-Rechenknoten
• Weitere Informationen

Überblick über die verfügbaren Knotentypen

Anzahl	Bit	Prozessoren	FSB	Arbeitsspeicher	Festplatte	Besonderheiten
86	32	2x Xeon 2.66 GHz "Prestonia"	533 MHz	2 GB (1 per core)	70 GB	abgeschaltet am 24.08.2009
64	64	2x Xeon 3.20 GHz "Nocona"	800 MHz	2 GB (1 per core)	70 GB	666 MHz RAM 24 Knoten mit SDR-Infiniband
25	64	2x Dual Core Opteron 2.0 GHz	800 MHz	4 GB (1 per core)	70 GB	ccNUMA
66	64	1x Dual Core Xeon 3070 2.67 GHz	1066 MHz	4 GB (2 per core)	140 GB	Core2-Architektur Alle Knoten mit DDR-Infiniband

Zugang, Umgebung und Filesysteme

Der Zugang zum Cluster erfolgt über zwei Frontend-Knoten:

• sfront03.rrze.uni-erlangen.de (64 bit, Nocona)
• sfront04.rrze.uni-erlangen.de (64 bit, Nocona)

Aufgrund der Verwendung von privaten IP-Adressen sind die Frontends direkt nur von innerhalb der FAU zugänglich. Von außerhalb sollte man sich sich zunächst auf dem Dialogserver "cshpc" einloggen und von dort aus dann zu den Frontends gehen.

Beim Einloggen auf einem der Frontends findet man sich im normalen RRZE-Home wieder (/home/rz[sun]home/... oder /home/hpc/...).

Das Cluster verfügt über eigene Homeverzeichnisse, die wesentlich schneller angebunden sind als das RRZE-Home. Diese befinden sich unter /home/cluster32/$gid/$uid/. Bitte beachten Sie, dass der Inhalt nicht vom RRZE gesichert wird (kein Backup)!

Jeder Knoten verfügt über 70 GB (Port Townsends: 140 GB) als temporäre Ablage, welche sich unter /scratch befindet. Jede Datei, die in diesem Verzeichnis älter als eine bestimmte Anzahl Tage (aktuell 12) ist, wird automatisch gelöscht (Gleitlöschung).

Compiler und Tools

Auf dem Cluster werden vielfätige Compiler und Tools in unterschiedlichen Versionen bereitgestellt. Um die Auswahl von und das Wechseln zwischen verschiedenen Softwarepaketen oder verschiedenen Versionen eines Softwarepakets zu erleichtern, wird das Module-Konzept verwendet. Damit lassen sich Einstellungen für unterschiedlichste Programme und Versionen einheitlich und einzelnen sehr bequem laden und ggf. später auch wieder entladen (entfernen). Die neuen, einheitlichen Module-Befehle ersetzen damit die bisherigen applikationsspezifischen source-Kommandos.

GNU Compiler Suite (gcc, g++, g77)

Verschiedene Versionen der GNU Compiler sind im Standard-Suchpfad bereits enthalten. Version 4.1.x ist die aktuelle Default-Version.

Intel Compiler (ifort,icc)

Diese Compiler gibt es in verschiedenen Versionen, die sich u.U. in der Effizienz und Korrektheit des erzeugten Codes unterscheiden können. Generell ist der Einsatz der jeweils neuesten Version anzuraten; nur in Ausnahmefällen sollte man sich auf eine ältere Version festlegen.

Um die Intel-Compiler verwenden zu können, müssen zunächst diverse Umgebungsvariablen gesetzt werden. Verwenden Sie hierfür die entsprechenden module-Befehle an Stelle der früher üblichen source-Kommandos:

module add intel64 für die 64 Bit Compiler.

Die obigen Befehle liefern die für den Alltagsgebrauch auf dem Cluster empfohlene Version. Dies ist normalerweise eine aktuelle, aber nicht die allerneueste Version, und ändert sich natürgemäss von Zeit zu Zeit.

Spezielle Releases einzelner Compiler können i.A. durch Laden von Modulen (z.B. intel-f/9.0-026) benutzt werden. module avail zeigt alle verfügbaren Möglichkeiten an.

ifort ist ein zum Fortran95-Standard konformer Compiler, icc ist der C-Compiler, und icpc ist der C++-Compiler. Obwohl es möglich ist, mit icc C++-Programme zu übersetzen, sollte zum Linken stets icpc verwendet werden. Schnelle Hilfe zu den Optionen gibt es mittels der Kommandozeilen-Option -help. Außer in den Verzeichnissen $INTEL_C_HOME/doc/ und $INTEL_F_HOME/doc/ findet man auch auf der Intel-Webseite sämtliche Dokumentation zum C/C++- bzw. Fortran-Compiler. Es wird darauf hingewiesen, dass das RRZE nicht immer die aktuellste Version der Compiler vorhält und es deswegen zu leichten Abweichungen von der verlinkten Intel-Dokumentation kommen kann.

Bei den Intel Compilern ist zu beachten, dass der Code bei Verwendung der Vektorisierungsoption -xP ausschließlich auf EM64T-CPUs von Intel laufen wird, also insbesondere nicht auf dem Opteron-Teil des Clusters. Die Option -xW stellt in dieser Hinsicht kein Problem dar, kann aber die SSE3-Erweiterungen nicht ansprechen.

Aus Kompatibilitätsgründen wird auch immer noch die Version 7.1 vorgehalten. Diese Version ist jedoch hoffnungslos veraltet und sollte nicht mehr verwendet werden.

Endianness

Der Xeon-Prozessor speichert wie alle x86-Designs seine Daten im little-endian Format, d.h. das LSB eines Multi-Byte-Datenwertes hat die niedrigste Speicheradresse. Dieses Format wird folglich normalerweise auch für unformatierte Fortran-Files verwendet. Um die Weiterverarbeitung von big-endian Files zu erleichtern, kann der Intel-Fortran-Compiler jedoch die nötige Konversion automatisch beim Lesen bzw. Schreiben vornehmen. Dies ist sogar selektiv für einzelne Units möglich. Gesteuert wird das zur Laufzeit durch die Umgebungsvariable F_UFMTENDIAN . Beispiele:

Wirkungen der Variable F_UFMTENDIAN.

F_UFMTENDIAN=	Wirkung
big	alles BE
little	alles LE (default!)
big:10,20	alles LE bis auf Units 10 und 20
"big;little:8"	alles BE bis auf Unit 8

Profiling

Mit den aktuellen Intel- und GNU-Compilern ist das gewohnte Profiling mittels gprof möglich, das die Bestimmung der inklusiven und exklusiven Laufzeiten aller Funktionen in einem Programm erlaubt (dazu muss mit geeigneten Compiler-Switches übersetzt werden).

Die HPC-Beratung verfügt aber über Profiling-Tools, die weit über die Funktionalität von gprof hinausgehen und die wir auf Anfrage mit den Benutzern zusammen einsetzen.

Debugger

Natürlich steht der GNU-Debugger gdb und das grafische Frontend ddd zur Verfügung, die sich allerdings nur sehr eingschränkt zum Debuggen paralleler Programme eignen.

Der TotalView-Debugger (ehemals Firma Etnus) ist für 32-bit Executables verfügbar. Die Lizenz gilt für 4 CPUs und nur einen User, es ist also darauf zu achten, den Debugger nicht unnötig zu blockieren, falls er nicht gebraucht wird. Starten des Debuggers erfolgt mit
module add totalview; /usr/totalview/bin/totalview

Zusätzlich ist der vom Woodcrest-Cluster bekannte DDT-Debugger der Firma Alinea auch auf dem EM64T/Opteron-Cluster über das Modul ddt64 nutzbar.

Die HPC-Gruppe unterstützt Sie gerne beim Debuggen.

Dokumentation zum Totalview-Debugger findet sich im passwortgeschützten Kundenbereich.

Paralleles Rechnen

OpenMP

Die Intel-Compiler unterstützen den OpenMP-Standard in der Version 2.0/3.0.

MPI

MPICH und andere MPI-Implementierungen sind über ist in einer aktuellen Version auf allen Rechnern über Module verfügbar. Die Meta-Module der Intel-Compiler (z.B. intel) laden automatisch auch die entsprechenden MPICH-Module. Werden dagegen die GNU Compiler verwendet, so müssen die entsprechenden MPI-Module noch per Hand geladen werden, beispielsweise mittels module add mpich/gnu. Das gleiche gilt, wenn eine MPI-Variante für Infiniband benötigt wird.

Interaktive MPI-Testläufe auf den Frontends werden seit März 2008 nicht mehr unterstützt. Bitte verwenden Sie stattdessen interaktive Batchjobs".

Mathematische Bibliotheken

LAPACK, BLAS und andere häufig benötigte Bibliotheken sind auf den Systemen vorhanden, und zwar in diversen Spielarten:

• Intel Math Kernel Library (MKL). Diese enthält außer hochoptimierten LAPACK und BLAS auch FFT-Routinen. Eine stabile Version ist stets /opt/intel/mkl verfügbar, aktuellere (oder ältere) Versionen finden sich unter /opt/intel/mkl/<Version>. MKL kann sowohl statisch als auch dynamisch gelinkt werden; für EM64T-Systeme kann zudem eine speziell optimierte 64-Bit-Version verwendet werden, die auch auf den Opterons funktioniert (aber natürlich die Verwendung eines 64-Bit-Compilers/Linkers voraussetzt):

  Linken mit der MKL-Bibliothek

  statisch	-L/opt/intel/mkl/lib/em64t -lmkl_lapack -lmkl_em64t -lguide -lpthread
  dynamisch	-L/opt/intel/mkl/lib/em64t -lmkl_lapack64 -lmkl_lapack32 -lmkl -lguide -lpthread

  Bei dynamisch gelinkten Binaries ist dann durch Setzen der LD_LIBRARY_PATH-Variable zur Laufzeit oder durch andere Maßnahmen (z.B. einlinken des Suchpfades mittels der Optionen -Xlinker -rpath -Xlinker <PFAD>) sicher zu stellen, dass die MKL-Bibliotheken auch gefunden werden.

• AMD Core Math Library (ACML). Auf Opteron-Prozessoren ist ACML in vielen Fällen besser als MKL. Eine aktuelle Version findet sich stets in /opt/acml, wobei es verschiedene Kompilate für verschiedene Compiler gibt; die "gnu64"-Variante sollte mit dem Intel-Compiler zusammenarbeiten. Zu linken wäre dann mit -L/opt/acml/gnu64/lib -lacml.

• Vanilla-BLAS bzw. LAPACK und auch ATLAS-Versionen sind unter /usr/lib installiert.

Batch-Betrieb

Allgemeines

Produktionsläufe und längere Testruns sind über das Queueing-System Torque abzuwickeln. Torque ähnelt dem lange bekannten NQS und ist von Benutzerseite aus gesehen identisch mit dem früher eingesetzten OpenPBS. Ein Job wird an Torque übergeben, indem ein sogenanntes Jobskript erstellt und an das qsub-Kommando übergeben wird. Folgende Schritte sind notwendig:

1. Erstellen eines Jobskriptes. Beispiele:

   Beispiel-Jobskripten für Torque

   Serieller Job:

   Paralleler Job:

   #!/bin/bash -l # # eine CPU fuer 8h anfordern # #PBS -l nodes=1,walltime=08:00:00 # # erste nichtleere Zeile ohne Kommentar: Start! # Ausfuehrung beginnt im Home-Directory # $PBS_O_WORKDIR ist das Verzeichnis, in dem # qsub aufgerufen wurde cd $PBS_O_WORKDIR # falls ein lokales temporäres Verzeichnis benötigt # wird, kann $TMPDIR verwendet werden; es wird am Jobende # automatisch gelöscht! # falls nötig können via "module add" beötigte # Module geladen werden # los! ./a.out

   #!/bin/bash -l # # 8 Knoten (16 CPUs) fuer 3 Stunden anfordern # #PBS -l nodes=8:ppn=2,walltime=03:00:00 # cd $PBS_O_WORKDIR # falls ein lokales temporäres Verzeichnis benötigt # wird, kann $TMPDIR verwendet werden; es wird am Jobende # automatisch gelöscht! # falls nötig können via "module add" beötigte # Module geladen werden # -np kann beim mpirun i.A. weggelassen werden (wird automatisch erzeugt). # Anhand der Queue wird versucht, das verwendete MPI zu erraten; sollte # dies schief gehen, kann durch die Optionen "-mpich", "-mvapich", # "-mvapich2" "-intelmpi" ein spezielles mpirun erzwungen werden mpirun ./a.out

   Die mit #PBS beginnenden Kommentarzeilen geben Optionen für qsub an, die man im Prinzip alle auch in der Kommandozeile unterbringen kann (s.u.).

2. Submittieren mittels

    qsub <weitere Optionen> < script
   

3. Die Angabe einer Queue ist im Allgemeinen nicht erforderlich. Siehe jedoch unten.

4. Der Job-Status kann mit dem Kommando
   qstat -a
   kontrolliert werden. Dort wird (bei bereits laufenden Jobs) auch die Wallclock-Zeit angezeigt, seit der der Job bereits im Zustand RUNNING ist. qstat zeigt nur Daten über eigene Jobs an.

5. Falls der Job wichtige Ausgaben auf stdout macht, kann zur Laufzeit die bisherige Standard-Ausgabe mittels
   /opt/rrze/bin/qcat [-f] <Job-ID>
   ausgegeben werden. Die Option -f hat kontinuierliche Ausgabe zur Folge (ähnlich wie bei tail -f).

6. Ein laufender oder wartender Job kann mittels des Kommandos qdel unter Angabe der Job-ID aus der Queue entfernt werden.

Wichtige qsub-Optionen

Wichtigste qsub-Optionen und deren Bedeutung.

Option	Bedeutung
-N <Jobname>	Setzt einen Namen für den Job, der bei qstat angezeigt wird
-o <outfile>	In das angegebene File wird die Standard-Ausgabe abgelegt
-e <errfile>	dito für Standard-Fehlerausgabe
-q <Queue>	Auswahl der Torque-Queue (s.u.). Default-Queue ist route.
-l nodes=<Knotenzahl>[:ppn=[1|2|4]][:<property>]	Anforderung von Rechenknoten bzw. CPUs. Ohne ppn=... wird nur eine einzige CPU pro Knoten angefordert, die andere(n) sieht Torque weiterhin als frei an! Für parallele Jobs also bitte immer ppn=2 (fü Intel-Knoten) bzw. ppn=4 (für Opteron-Knoten) angeben. Siehe auch den Abschnitt über Paralleljobs. Über die "property" lässt sich in bestimmten Fällen genauer festlegen, auf welcher Art von Knoten der Job laufen soll. Dies ist für Standardbenutzer nicht relevant (s.u.).
-l walltime=HH:MM:SS	Angabe der benötigten Wallclock-Zeit (Laufzeit) für den Job. Wird nichts angegeben, so werden Queue-spezifische (kurze) default-Werte angenommen. Die Nennung eines Laufzeitlimits hilft dem Scheduler bei der Entscheidung, welche Jobs gestartet werden sollen (Kurzläufer haben Vorteile).
-I	Interaktiver Job. Ein Jobskript darf weiterhin angegeben werden, es werden aber dort nur die PBS-Optionen eingelesen und kein Code ausgeführt. Der Benutzer bekommt dann eine interaktive Shell auf einem der reservierten Knoten und kann dort direkt alle Kommandos ausführen, die auchin einem Jobskript möglich sind.
-M x@y -m abe	Bei Abbruch, Start und Beendigung des Jobs wird eine E-Mail an x@y versandt.

Queues und Job-Parameter

Folgende Queues sind auf dem Cluster für User direkt per -q anwählbar:

Name der Queue	Beschreibung
route	Dies ist die Default-Queue, wenn vom Anwender keine spezielle Queue angegeben ist. "route" verteilt submittierte Jobs anhand verschiedener Kriterien (Laufzeit, CPU-Zahl, ACLs) auf andere Queues. Die genauen Parameter und Beschränkungen dieser Queues können sich ohne Ankündigung ändern und sind für Benutzer normalerweise ohne Belang. Über diese Queue können nur Intel-Knoten angesprochen werden!
serial (Routing-Queue für swork	Diese Queue ist ausschliesslich für kurzlaufende serielle Durchsatzjobs gedacht. Ein spezieller Knotentype wird nicht garantiert.
iband	Für parallele Jobs auf EM64T-Knoten mit Infiniband-Interconnect. Die minimale Knotenzahl ist auf 2 gesetzt. Wichtig: In dieser Queue dürfen nur Paralleljobs laufen, die mit Infiniband-MPI übersetzt sind!
opteron (Routing-Queue für oexpress und owork)	Für serielle und parallele Jobs auf Opteron-Knoten. Bei Paralleljobs sind immer komplette Knoten anzufordern (ppn=4). Anhand der Laufzeit, ACLs und anderer Kriterien wird der Job dann in eine von mehreren Execution-Queues einsortiert. Für "oexpress" steht Montags bis Freitags von 8:00 bis 21:00 ein Knoten dediziert zur Verfügung. Außerhalb dieser Perioden ist die Queue weiterhin aktiv, es kann aber zu längeren Wartezeiten kommen.
townsend (Routing-Queue für texpress und twork)	Zugang zu dieser Queue gibt es auf Anfrage bei der HPC-Beratung. Für parallele Jobs auf den Port-Townsend-Knoten. Es sind immer komplette Knoten anzufordern (ppn=2). Anhand der Laufzeit, ACLs und anderer Kriterien wird der Job dann in eine von mehreren Execution-Queues einsortiert.
fhg, special, ...	Queues für Spezialaufgaben bzw. besondere Nutzer.

Das Queueing-System ist so eingerichtet, dass (serielle) Jobs mit kurzer Laufzeit (insbesondere unter 6 Stunden) bevorteilt werden. Jobs von Benutzern ohne besondere Rechte können eine maximale Laufzeit von 48 Stunden haben.

Für einige Queues sind Default-Wallclock-Limits gesetzt, die dann verwendet werden,wenn der Benutzer die benötigte Walltime nicht explizit mittels -l walltime=... angibt.

Queue-Limits.

Submit-Queue	Execution-Queue	min. Walltime	Default-Walltime	max. Walltime	max. Knotenzahl	ppn	Knotentype / Anmerkung
(route)	s1	--	00:10:00	06:00:00	16	1|2	em64t:[gbit|mnox]
(route)	s2	06:00:01	--	48:00:00	16	1|2	em64t:gbit
(route)	s3	48:00:01	--	240:00:00	8	1|2	em64t:gbit; Zugang limitiert
(route)	ls_normal	--	00:01:00	48:00:00	16	1|2	em64t:gbit; Zugang limitiert
(route)	ls_long	48:00:01	--	240:00:00	4	1|2	em64t:gbit; Zugang limitiert
serial	swork	--	00:10:00	06:00:00	1	1	alle Knoten
serial	swork48h	06:00:01	--	48:00:00	1	1	alle Gbit-Knoten
iband	iband	--	00:10:00	72:00:00	24	2	em64t:mnox
opteron	oexpress	--	00:10:00	01:00:00	4	1|4	opteron
opteron	owork	01:00:01	--	48:00:00	8	1|4	opteron
townsend	texpress	--	00:10:00	01:00:00	4	2	townsend; Zugang limitiert
townsend	twork	01:00:01	--	24:00:00	32	2	townsend; Zugang limitiert

Da Jobs in Spezialqueues (v.a. special) auf verschiedenen Knotentypen laufen dürfen, können bei Bedarf "Properties" angegeben werden, die den Knotentyp genauer spezifizieren. Folgende Properties sind gesetzt:

Erlaubte Properties beim Job submit.

Property	Bedeutung
normal	alle Intel-Knoten
gbit	nur Gbit-Interconnect (EM64T oder Opteron)
mnox	EM64T-Infiniband-Knoten
em64t	64-Bit-Intel-Knoten (Nocona)
opteron	Opteron-Knoten (AMD64)
townsend	Port-Townsend-Knoten (Core2 Xeons)

Die Angabe einer Property erfolgt dann nach der Festlegung der Knoten- und CPU-Anzahl:

qsub -l walltime=05:00:00,nodes=4:ppn=2:em64t:gbit ...

Bei Angabe sich widerprechender Properties (z.B. opteron:mnox oder ppn=4:em64t) verbleibt der Job im "Q"-Zustand und wird nicht gestartet.

Diverse relevante Queue-Parameter (maximale Knotenzahl pro Job etc.) bekommt man auch mittels der Kommandos qstat -q bzw. qstat -Q -f.

Job-Priorität und Reservierungen

Der Scheduler des Batchsystems vergibt an jeden wartenden Job eine Priorität, die von verschiedenen Faktoren abhängt, u.a. Wartezeit, Queue, Gruppenzugehörigkeit und in letzter Zeit verbrauchte Rechenzeit (Fairshare). Diese Priorität ist normalerweise für Benutzer nicht einsehbar, und die Reihenfolge wartender Jobs bei Eingabe von qstat hat nichts damit zu tun. Um die Verteilung der Prioritäten transparenter zu machen, gibt es im Kundenbereich (passwortgeschützt) eine Webseite, in der die aktuell vom Batchsystem berücksichtigten Jobs mit ihrer aktuellen Priorität in anonymisierter Form aufgeführt sind. Außerdem sieht man dort, welche Jobs auf welchen Knoten laufen und welche Reservierungen der Scheduler auf den Knoten eingerichtet hat. Falls ein Job aus welchen Gründen auch immer nicht in Betracht gezogen werden kann, ist dies ebenfalls ersichtlich. Auf dem Cluster gibt es darüber hinaus noch die beiden Textfiles /home/cluster32/hpcop/joblist bzw. /home/cluster32/hpcop/nodelist. Ersteres ist eine direkte Kopie der Informationen über wartende Jobs aus o.a. Webseite. Das zweite File zeigt die aktuelle Belegung der Clusterknoten und Queues an.

Zugang zu den Rechenknoten und stage-out von Daten

Ein direktes Login auf einem Rechenknoten ist nur dann erlaubt, falls dort aktuell ein eigener Job läuft. Die Beendigung des letzten Jobs eines Benutzers auf einem Knoten hat auch die Beendigung aller seiner Prozesse und damit auch aller Shells zur Folge. Dies führt dann zu Problemen, wenn ein Job durch Zeitlimit oder explizites qdel abgebrochen wird und seine lokalen Daten unter /scratch nicht mehr auf ein globales Verzeichnis kopieren kann. Um in solchen Fällen die Daten verfügbar zu machen, kann das SIGTERM-Signal, das Torque an das Jobskript schickt, abgefangen werden. Ein Signalhandler muss dann das Kopieren der Daten übernehmen. Dazu bleibt eine Zeit von 60 Sekunden, bis Torque das finale SIGKILL-Signal sendet, das nicht abgefangen werden kann. Beispiel für ein Jobskript (da sich in csh-basierten Shells das SIGTERM-Signal nicht abfangen lässt, ist man hier auf Bourne-Shells angewiesen):

#!/bin/bash -l
#
#PBS ....
#

TMPDIR=/scratch/${USER}/${PBS_JOBID}
export TMPDIR

# SIGTERM abfangen, im Handler scratch-Verzeichnis retten
trap "sleep 5 ; cd /scratch/${USER} ; tar cf - ${PBS_JOBID} | tar xf - -C /home/cluster32/${GROUP}/${USER} ; exit" 15

# ... ab hier beginnt das eigentliche Jobskript, das Daten in
# /scratch/${USER}/${PBS_JOBID} ablegt

cd $PBS_O_WORKDIR

# scratch-Verzeichnis anlegen
mkdir -p $TMPDIR

# los!
./a.out

Der Schlüssel ist das trap-Kommando, das das angegebene Signal (hier 15 = SIGTERM) abfängt und daraufhin Kommandos ausführt, die die lokalen Daten (hier in /scratch/${USER}/${PBS_JOBID}) auf ein globales Verzeichnis (hier /home/cluster32/${GROUP}/${USER}) kopiert. Der sleep-Befehl wartet zunächst einige Sekunden, bis das eigentliche Programm wirklich beendet wurde. Der exit-Befehl am Ende ist notwendig, um das Jobskript nach dem Signalhandler endgültig zu beenden.

Port-Townsend Rechenknoten

Die 66 Port-Townsend-Rechenknoten sind der neueste Teil des Clusters. "Port Townsend" ist der Codename für das S3000PT Mainboard von Intel. Dieses Mainboard hat eine so kompakte Bauform, dass zwei der Boards nebeneinander in ein normales 1 Höhen-Einheit (= 4,45 cm) hohes Gehäuse passen. Die 66 Knoten stecken also in nur 33 Gehäusen. Da jedes Einzelboard nur einen Sockel hat, hat dieser exklusiven Zugriff auf den Speicher und somit die komplette Speicherbandbreite für sich. Gleichzeitig sind die Knoten untereinander mit DDR-Infiniband vernetzt. Diese Kombination von grosser Speicherbandbreite und schnellem Kommunikationsnetz ist für einige Anwendungen sehr vorteilhaft.

Weitere Informationen

Technische Dokumentationen zur IA32/EM64T-Architektur, Programmierung und Optimierung finden sich unter IA32 Intel Architecture Software Developer's Manuals.

Weiterführende Informationen zur AMD64-Architektur, Programmierung und Optimierung finden sich unter AMD Developer Resources - Documentation.

Letzte Änderung: 19. Januar 2010, Ansprechpartner, Historie