(diese Seite befindet sich noch im Aufbau)

Übersicht

PALMA (Paralleses Linux-System für Münsteraner Anwender) ist ein Cluster aus insgesamt 2576 Prozessorkernen. Diese sind wie folgt verteilt:

• 36 Knoten mit je 2 4-Kern Intel Nehalem Prozessoren, also 8 Kernen pro Knoten
• 198 Knoten mit je 2 6-Kern Intel Westmere Prozessoren, also 12 Kernen pro Knoten
• 1 SMP (shared memory) Knoten mit 128 Prozessorkernen

Die Ausstattung im Detail:

Compute Nodes:

• 2,6 GHz, 4 bzw. 6 Kerne
• 2 bzw. 3 bzw. 4 GB Arbeitsspeicher pro Prozessorkern (je nach Knoten)

Filesystem:

• 3 TB /home Partition
• 180 TB /scratch Partition

Als schnelles Kommunikationssystem dient Infiniband.

Organisatorisches

Infos zu PALMA-Treffen, etc. ... in Vorbereitung

Zugang zum System

Es ist grundsätzlich nur Personen möglich, Jobs auf Palma abzuschicken, die zwei Voraussetzungen erfüllen:

• Der Benutzer muß Mitglied der Gruppe u0clustr sein (geht über MeinZIV)
• Der Benutzer muß Mitglied eines der 23 Projekte sein, die für das System zugelassen sind. In diesem Fall kann der Benutzer im myJAM registriert werden

Eine Übersicht über die Warteschlangen sowie die Auslastung des Gesamtsystems befindet sich hier: https://palma1.uni-muenster.de/myJAM (anmelden mit dem üblichen Benutzernamen und dem Standardpasswort)

Der von außen per ssh erreichbare Loginknoten heißt palma1.

Rechnen auf PALMA

Kompilieren von Programmen

Das Modul-Konzept

Umgebungsvariablen (z.B. PATH, LD_LIBRARY_PATH) für Compiler und Bibliotheken werden über module-Befehle definiert:

Befehl (Kurz- und Langform)	Bedeutung
module av[ailable]	Listet alle verfügbaren Module auf
module li[st]	Zeigt alle in der aktuellen Umgebung geladenen Module.
module show modulname	Listet die Änderungen auf, die ein Modul an der Umgebung bewirkt.
module add modul1 modul2 ...	Fügt Module der aktuellen Umgebung hinzu.
module rm modul1 modul2 ...	Entfernt Module aus der aktuellen Umgebung.
module purge	Löscht alle aktivierten Module aus der Umgebung.

Um alle verfügbaren Module zu sehen, müssen die folgenden beiden Module geladen werden (dies kann am besten über die .bashrc geschehen):

module add shared

module add /Applic.PALMA/modules/path

Submittieren von Jobs

Für die Verteilung von Rechenjobs auf dem Cluster sorgen das Batchsystem TORQUE sowie der Scheduler Maui. Ein manuelles Starten von längeren Programmläufen auf den Rechenknoten oder auf PALMA am Batchsytem vorbei ist nicht erlaubt. Solche "streunenden" Prozesse werden ohne Vorwarnung vom Administrator beendet. Grundsätzlich sollten Batch-Jobs nur vom Dialogserver palma1 aus abgeschickt werden.

Erstellen des submit-files

Beispiel für ein submit-file eines MPI-Jobs:

#PBS -o output.dat
#PBS -l walltime=01:00:00,nodes=4:westmere:ppn=12
#PBS -A Projektname
#PBS -M Nutzername@uni-muenster.de
#PBS -m ae
#PBS -q default
#PBS -N Jobname
#PBS -j oe
cd $HOME/Jobverzeichnis
cp $PBS_NODEFILE $HOME/$PBS_JOBID.nodefile
mpdboot --rsh=ssh -n 2 -f ~/$PBS_JOBID.nodefile  -v
mpirun --rsh=ssh -machinefile $PBS_NODEFILE -np 32 ./Programmname

Hier wird ein MPI-Job gestartet, der mit insgesamt 32 Prozessen läuft. Dazu werden 4 westmere-Knoten mit je 12 Prozessorkernen angefordert.

Weitere Angaben:

• Projektname: Muss unbedingt durch das eigene Projekt erstetzt werden, ansonsten startet der Job nicht.
• Nutzername: Durch eigene Kennung ersetzen, damit Emails korrekt zugestellt werden können
• Jobverzeichnis: Durch Pfad, in dem das Programm liegt, ersetzen.
• Programmname: Hier den Namen der auszuführenden Datei eintragen.
• walltime: Die nötige Zeit, die das Programm läuft, angeben. Nach Ablauf der Zeit wird der Job abgebrochen. Maximal 48 Stunden sind möglich.

Benötigt das Programm kein MPI, kann die Datei entsprechend vereinfacht werden.

Beispiel für ein submit-file eines openmp Jobs:

#PBS -o output.dat
#PBS -l walltime=01:00:00,nodes=1:westmere:ppn=12
#PBS -A Projektname
#PBS -M Nutzername@uni-muenster.de
#PBS -m ae
#PBS -q default
#PBS -N Jobname
#PBS -j oe
cd $HOME/Jobverzeichnis
./Programmname

Abschicken des Jobs/Verwaltung der Warteschlange

Ein Job wird gestartet, indem die oben erzeugte submit-Datei mittels

 qsub submit.cmd 

abgeschickt wird, wobei submit.cmd der Name der submit-Datei ist.

Weitere Befehle:

• qstat: Zeigt die derzeitige Warteschlange an
• qstat -a: Selbiges, nur mit Anzahl der angeforderten Knoten
• qstat -n: Alle Knoten, die den Jobs zugeordnet sind, werden aufgeschlüsselt
• qdel Jobnummer: Löscht Jobs aus der Warteschlange
• showbf: Zeigt die Anzahl der freien Prozessorkerne

Die Auswahl der Rechenknoten

Mit der Option -l legt man die Ressourcenanforderungen für den Batch-Job fest. Bei der Festlegung der Anzahl und Art der Nodes ist zu beachten, dass die Rechenknoten des Systems zur Unterscheidung mit den Eigenschaften "nehalem" und "westmere" gekennzeichnet sind. Außerdem gibt es pro Node mehrere CPU-Kerne, so dass die Angabe nodes zwei unterschiedliche Bedeutungen haben kann. Die folgende Tabelle soll verdeutlichen, wie sich die Angabe nodes auf die Auswahl der Rechenknoten auswirkt:

Angabe im Batch-Job	Auswahl der Rechenknoten
-l nodes=10	10 beliebige CPU-Kerne. Nicht zu empfehlen.
-l nodes=2:ppn=12	2 westmere Knoten
-l nodes=1:ppn=8	8 Prozessorkerne eines westmere oder nehalem Knotens
-l nodes=2:nehalem:ppn=8+3:westmere:ppn=12	16 Prozessorkerne von 2 nehalem Knoten und 36 Prozessorkerne von 3 westmere Knoten
-l nodes=8:ppn=1	Fehlerhafte Zuteilung. Die Anzahl von ppn, wenn angegeben, sollte größer oder gleich 2 sein. Aufgrund eines Bugs in TORQUE erhält man für ppn=1 nicht das erwartete Ergebnis, sondern z.B. in diesem Fall 8 willkürlich über die HPC-Rechnenknoten verteilte Cores.

Generell sollten immer komplette Knoten angefordert werden, d.h. Angaben wie

nodes=x:nehalem:ppn=8

oder

nodes=x:westmere:ppn=12

gemacht werden.

Bei Bedarf können die einzelnen Chassis, in denen die Knoten stecken, auch direkt angefordert werden. Dazu ist statt der Angabe #PBS -q default die Angabe des Chassis nötig. Es kann zwischen folgenden Chassis gewählt werden: chassisd1, chassisd2, chassisd3, chassisd4, chassise1, chassise2, chassise3, chassisf1, chassisf2, chassisf3, chassisg1 wobei die Chassis d1 und d2 nehalem Prozessoren besitzen und das chassis g1 48GB statt 24 GB Hauptspeicher pro Knoten hat.

Die scratch Partition

Paralles speichern von Daten auf /scratch... in Vorbereitung

Unter /scratch befinden sich 180 TB Speicherplatz, der genutzt werden kann, um die in den Programmen generierten Daten zu speichern. Diese sollten aus Platz- und Geschwindigkeitsgründen nicht im Homeverzeichnis gespeichert werden. Als Dateisystem kommt lustre zum Einsatz, das einige Besonderheiten besitzt.

Es wird kein Backup dieser Partition durchgeführt!

Das Webinterface myJAM

-- HolgerAngenent - 2010-07-08