Nutzung des Clusters thot.informatik.unihalle.de

Nutzung des Clusters thot.informatik.uni­halle.de
Allgemeine Informationen:
Der Cluster hat die IP 172.30.7.61. Er ist über diese IP bzw. den Namen „thot.informatik.uni­
halle.de“ nur aus den Netzen der Universität erreichbar. Soll doch von außerhalb auf den Cluster zugegriffen werden, so ist dies nur über den VPN­Zugang bzw. auf Umwegen über den Gatewayrechner seschat.informatik.uni­halle.de möglich.
Der Cluster wird administriert von der Rechnerbetriebsgruppe des Institutes für Informatik.
Bei Fragen, Problemen, Wünschen bitte die Mailadresse clusteradmin@
informatik.
uni­
halle.
de
verwenden.
Weitere Informationen und die aktuelle Version dieser Hinweise findet man auf der Webseite:
http://www.informatik.uni­halle.de/ti/mitarbeiter/thuering/34361_1052295/cluster.
1. Konfiguration der Umgebung
1.1 Module
Jeder Nutzer kann und muss sich seine eigene Umgebung konfigurieren. Hierzu stehen unterschiedliche Softwarepakete und Paketversionen zur Verfügung. Je nachdem welche Applikationen gerade laufen sollen, müssen die entsprechenden Module geladen werden.
Befehle:
module
module
module
module
available
add modulname
list
rm modulename
//
//
//
//
welche Module sind verfügbar
lädt das entsprechende Modul
zeigt alle Module, die im Moment geladen sind
entfernt das entsprechende Modul
Die Module liegen im Dateisystem unter /cvos/shared/modulefiles oder /cvos/local/modulefiles. 2. Jobs mit der SGE verwalten
2.1 Installierte Queue
Es gibt genau eine Queue mit dem Name main.q, welche alle Jobs auf die Knoten verteilt.
Um eine möglichst gerechte Verteilung der Rechenzeit zu erhalten, wird die Priorität eines Jobs über folgende Kriterien bestimmt:
●
●
●
●
bisher vom Nutzer verbrauchte Rechenzeit (lange Rechenzeit = niedrigere Priorität)
Arbeitsspeicher, welcher von einem Job benötigt wurde (viel Arbeitsspeicher = niedrigere Priorität)
Laufzeit des Jobs ( lange Laufzeit = niedrigere Priorität)
Rechenkontingente der einzelnen Arbeitsgruppen (siehe Nutzerordnung und Betriebsordnung)
Weiterhin wurde festgelegt, dass aufgrund der nur wenigen vorhanden Lizenzen derartige Jobs bevorzugt behandelt werden.
2.2 Jobs in die Queue stellen
Zur Berechnung der Priorität über die unter 2.1 aufgeführten Kriterien muss ein Job mit den Informationen „maximale Rechenzeit“ und „maximal benötigeter Arbeitsspeicher“ gestartet werden.
Ressource
Option
Format
maximale Rechenzeit h_rt
HH:MM:SS oder
Sekunden
maximal benötigeter Arbeitsspeicher
h_data
Megabyte z.B. 1024M
2.2.1 Kommandozeile
Beispiel: Starten eines Prozesses mit dem Namen berechne, welcher 4 GB Arbeitsspeicher benötigt und eine Laufzeit unter 3,5 Stunden hat.
Kommando: qsul ­l h_rt=03:30:00 ­l h_data=4096M berechne
Ein Job, welcher mehr Zeit benötigt, wird abgebrochen!
2.2.2 Jobskript
Beispielbatchskript :
####################
# Rahmen fuer Jobs # ####################
# Fehlerprotokoll soll in die Standardoutputdatei geschrieben werden
#$ -j y
# benoetigter maximalen Arbeitsspeicher
#$ ­l h_data=4096M
# benoetigte maximale Rechenzeit
#$ ­l h_rt=03:30:00
# Name des Jobs
#$ ­N berechne
./berechne
Ohne diese Angaben wird der Job zwar in die Queue übernommen, aber er wird nicht gestartet.
2.3 Aufbau eines Jobs
2.3.1 Jobs, mit hoher Netzlast (Eingabe­ bzw. Ausgabedaten)
Beim Erstellen von Programmen sollte immer bedacht werden, dass die gesamte Kommunikation zwischen den Knoten im Cluster und die Datenübertragung über ein 1 GBit Ethernet erfolgt.
Jobs, welche während ihrer Laufzeit sehr oft Daten in das Homeverzeichnis des Nutzers schreiben, erzeugen eine hohe Netzlast und belasten somit gegebenenfalls den gesamten Cluster. Jobs, welche auf diese Weise andere Jobs behindern werden von den Administratoren gestoppt!
Für Prozesse, welche viele Daten produzieren, wird daher folgendes Konzept empfohlen:
Jeder Knoten besitzt eine 200 GB Partition mit dem Namen /local. Diese ist für alle Nutzer des Clusters beschreibbar. Zu Beginn eines Jobs sollten auf dieser Partition für den Job ein Verzeichnis angelegt werden.
Wenn der Job Daten benötigt, so sollten diese in das neue Verzeichnis gelegt werden.
Zwischenergebnisse, welche während der Laufzeit des Jobs produziert werden, können in diesem Verzeichnis als Datei abgelegt werden. Nachdem der Job beendet wurde, sollten alle wichtigen Daten aus diesem temporären Verzeichnis wieder in das Homeverzeichnis geschoben werden. Anschließend muss das zum Prozess gehörige Verzeichnis unter /local wieder gelöscht werden.
Beispielrahmen für ein Programm mit dem Namen berechne:
#!/bin/bash ############################################################### # Rahmen fuer Jobs mit viel Zwischenergebnissen # # # # Beispiel: Der Job muss in dem Verzeichnis gestartet werden, #
# in welchem sich das Programm und die Daten # # befinden # ###############################################################
# benoetigter maximalen Arbeitsspeicher # Bitte Wert anpassen #$ ­l h_data=4096M
# benoetigte maximale Rechenzeit anpassen # Bitte Wert anpassen
#$ ­l h_rt=03:30:00
### Bitte hier den Namen des Jobs anpassen jobname="berechne" ################################################# ################################################# #$ ­cwd tarfile=$HOME"/"`hostname``echo $jobname | cut ­d"." ­f1``date +"%y%m%d_%k_%M_%S"`".tar" ##### Daten (Verzeichnis) kopieren cp ­r * $TMPDIR cd $TMPDIR ##### Ausfuehren des Jobs ./$jobname ##### Daten sichern und temporaeres Verzeichnis loeschen # gibt es noch weitere Jobs weitereprogs=`ps ­ef |grep $jobname | grep ­v grep`
if [ ­z "$weitereprogs" ] # dies ist der letzte Job auf diesem Knoten then ##### Daten in das Homeverzeichnis kopieren tar ­cf $tarfile * fi 2.3.1 Jobs ohne Netzlast
Jobs ohne Netzlast sind Jobs, welche über die gesamte Laufzeit weder Eingabedaten benötigen noch Ausgabedaten erzeugen. Es werden lediglich Informationen, welche über die Standardausgabe angezeigt werden sollen, generiert.
Die Umgebung für solche Programmen sollte über die Parameter der SGE definiert werden.
Beispielbatchskript :
################################################# ##############
# Rahmen fuer Jobs, welche nur auf die Standardout schreiben # ################################################ ###############
#Spezifikation des Dateinamens für den Output (stdout) # Bitte Dateinamen anpassen #$ ­o /$TMPDIR/berechne_log
# Fehlerprotokoll soll in die Standardoutputdatei geschrieben werden
#$ -j y
# benoetigter maximalen Arbeitsspeicher # Bitte Wert anpassen #$ ­l h_data=4096M
# benoetigte maximale Rechenzeit anpassen # Bitte Wert anpassen
#$ ­l h_rt=03:30:00
# Name des Jobs
# Bitte Jobnamen anpassen
#$ ­N berechne
./berechne
mv /$TMPDIR/berechne_log ~/berechne_log
Wer Jobs ohne Batchskript direkt mit qsub in eine Queue stellt, muss sich nach Ende des Jobs selbst um die Sicherung der Daten (Verschieben der Daten von /local nach /home) bzw. das Aufräumen kümmern. Hierzu sollte man zur Laufzeit des Jobs feststellen auf welchem Knoten der Job lief.
2.4 Einige Kommandos zur Job­Verwaltung
1. einen Job anhalten: qmod ­sj [JOBID]
2. einen angehaltenen Job wieder starten: qmod ­usj [JOBID]
3. einen Job aus einer Queue entfernen: qdel [JOBID]
4. alle Jobs auflisten (JOBID ermitteln):
qstat
__________________
Version vom 4.5.2009