Standard-Ein- und Ausgabe
Die Ein- und Ausgabekanäle unter Linux (und anderen unixoiden Betriebssystemen).
STDIN – die Standardeingabe
STDOUT – Standard-Ausgabe
STDERR – die Standard-Fehlerausgabe
Wie im Bild gezeigt, kann Slurm mit -o und -e beide Ausgabekanäle in (separate) Dateien umleiten.
Dabei können Platzhalter (%.) verwendet werden, die auch bei hunderten Jobs aus demselben Job-Script für eindeutige und distinkte Dateinamen sorgen:
%j – Job-ID
%x – Name des Jobs (aus #SBATCH -J myJobName)
%N – Hostname des ausführenden Rechenknoten
%A – Job-ID eines Array-Jobs
%a – Task-ID eines Array-Jobs
(mehr in „man sbatch“ unter „filename pattern“)
Zugriffsrechte für Dateien und Verzeichnisse
Abgestuft von User/Besitzer über Gruppe zu „allen anderen“, können Sie festlegen,
- ob Dateien gelesen/geschrieben oder auch (wie ein Kommando) ausgeführt werden können
bzw. - welche anderen Nutzer auf Ihre Verzeichnisse und Dateien zugreifen dürfen.
(mehr dazu in „man chmod“).
UNIX/Linux ↔ Windows/DOS „Zeilenende“-Kodierung
Während alle UNIX-artigen Betriebssysteme als „Zeilenende“-Zeichen seit langem nur das Linefeed (LF, Zeilenvorschub) nutzen, hat sich Microsoft bei MS-DOS (und damit auch bei Windows) dafür entschieden, einem anderen Standard zu folgen und eine Zwei-Byte-Kombination aus CarriageReturn (CR, \r = Wagenrücklauf) und LineFeed (LF, \n = Zeilenvorschub) zu verwenden.
Daher können leider auch reine Textdateien, die man 1:1 von Windows auf Linux/UNIX kopiert, zu Problemen führen.
Typischer Fehler beim Versuch, ein solcherart falsch formatiertes Jobscript abzuschicken:
[E] sbatch: error: Batch script contains DOS line breaks (\r\n)
sbatch: error: instead of expected UNIX line breaks (\n).Wie gezeigt, können Sie mittels „cat -A textdatei“ herausfinden, ob es eine ehemalige Windows-Datei ist, und sie dann mit „dos2unix textdatei“ in eine richtige Textdatei konvertieren.
Grafische Ausgaben darstellen
Sollen grafische Ausgaben dargestellt werden (z.B. im PNG- oder JPG-Format) oder sollen Programme genutzt werden, die eine grafische Benutzerschnittstelle (GUI) haben, gibt es mehrere Wege.
Per X11-Umleitung
Das älteste und langsamste Protokoll, mit dem *nix-/Linux-Programme ihre Fenster über das Netzwerk auf einem anderen Rechner darstellen können.
Zum „Betrachten“ von Bilddateien (oder gar dreidimensionalen Ergebnissen) ist die X11-Umleitung denkbar ungeeignet (siehe Bild rechts), da unkomprimierte Bilddaten durch das langsame X11-Protokoll durchgeleitet werden.
- Stellen Sie sicher, dass auf Ihrem lokalen Laptop/PC ein X-Server läuft (Linux/MacOS: eingebaut, Windows: z.B. vcXsrv) – dieses Programm „empfängt“ die Fenster des entfernten Programms und stellt sie auf Ihrem Laptop/PC dar.
- Stellen Sie sicher, dass in Ihrem
ssh-Programm die Option „X11 Forwarding“ aktiviert ist, bzw. starten Sie einen Kommandozeilen-ssh-Client mit der Option-X
Das ist der einzige Weg, GUI-Programme von den Login-Knoten aus zu benutzen.
Per sshfs
Der bessere Weg zur Darstellung grafischer Ergebnis-Dateien ist, sich das clusterweite Filesystem des HLR per „ssh file system“ so auf seinem eigenen Laptop/PC einzuhängen, dass man darauf wie auf eine lokale Platte bzw. ein Netzlaufwerk zugreifen kann.
- legen Sie ein lokales Verzeichnis auf Ihrem Laptop/PC an:
mkdir hpc-fs - Linux/MacOS
sshfs lclusterXX: hpc-fs - Windows:
Installieren & konfiguren Sie WinFsp and SSHFS-Win - starten Sie Ihre bevorzugten Viewer/Darstellungsprogramme nun lokal und öffnen Sie die Bilddateien über das eingehängte „
hpc-fs“-Verzeichnis bzw. über den von „SSHFS-Win“ erzeugten Laufwerksbuchstaben.
Bei dieser Methode gehen direkt die noch komprimierten Bildformate per sshfs durch das Netzwerk, und werden erst auf Ihrem lokalen Laptop/PC dekomprimiert und dargestellt.
Spezielle Betrachter
Für einige datenintensive Ergebnis-Formate gibt es spezialisierte Betrachter wie ParaView:
ParaView was developed to analyze extremely large datasets using distributed memory computing resources. It can be run on supercomputers to analyze datasets of tera-scale as well as on laptops (for smaller data).
In den meisten Fällen haben solche Visualisierer eine Client/Server-Architektur und bauen selbst eine eigene Netzwerkverbindung auf.
Hier wird auf dem Login-Node des Clusters die „Server“-Komponente gestartet und auf dem eigenen Laptop/PC die „Client“- bzw. Darstellungskomponente. Durch das Netzwerk nehmen beide zueinander Verbindung auf, und der Server lässt sich vom Client aus interaktiv steuern und liefert ihm die gewählte Visualisierung im gewünschten „Level of Detail“.
Da diese Netzwerkverbindung standardmäßig weder gesichert noch verschlüsselt ist und nicht per ssh (oder irgendeinem anderen Standard-Protokoll) aufgebaut wird:
- prüfen Sie die darzustellenden Daten auf Vertraulichkeit/Geheimhaltungsvorgaben, und nutzen Sie in diesem Fall unbedingt ssh-Tunnel
- Falls nicht, prüfen Sie im Fall von Problemen die Firewall Ihres Laptop/PC oder die Ihres Institutsnetzwerks auf Durchlässigkeit für die vom Visualisierer benutzten Ports.
Fileübertragung zum und vom Lichtenberg HPC
Vor den Rechnungen auf dem Lichtenberg müssen Ihre Daten auf die Filesysteme des Lichtenberg-Rechners und danach Ihre Resultate wieder zurück übertragen werden.
Benutzen Sie hierfür ebenfalls die Loginknoten , denn diese haben leistungsfähige Netzwerkanschlüsse auch in das Campus-Netz der TU (wir betreiben keine speziellen input/output-Knoten).
Wir empfehlen folgende Verfahren:
Einmalige Übertragungen: scp (oder sftp)
So wie man sich per ssh auf den Loginknoten anmeldet, können Dateien und Verzeichnisse mit dem SSH-Werkzeug scp (oder der FTP-Entsprechung sftp) übertragen werden.
Bei großen Text-/ASCII-Dateien wird die im SSH-Protokoll enthaltene, optionale Kompression (-C) empfohlen, die verlustfrei & transparent beim Transfer dafür sorgt, die Netzwerk-Bandbreite zu schonen und die den Transfer beträchtlich beschleunigen kann.
Lassen Sie die Kompression weg, wenn bereits vorkomprimierte Daten wie JPG-Bilder oder Videos in modernen Containerformaten (mp4, OGG) übertragen werden sollen.
Beispiel:
tu-id@logc0004:~ $ scp -Cpr myResultDir mylocalworkstation.inst.tu-darmstadt.de:/path/to/my/local/resultdir
Details: man scp
Ausfallsicherheit: keine (nach Abbrüchen überträgt scp alles neu).
Wiederholte Transfers: rsync
Einige Fälle wie z.B. wiederkehrende Transfers lassen sich mit scp nur unzureichend abbilden.
Beispiele: „zur Analyse mit grafischen Werkzeugen brauche ich die Berechnungsergebnisse des HLR umgehend auf meiner lokalen Workstation-Platte“, oder „Die Rohdaten aus meinen lokalen Experimenten müssen umgehend auf den HLR zur Auswertung“.
Sowie man ein Verzeichnis auf dem Lichtenberg zu einem lokalen bei sich im Institut weitgehend synchron halten möchte, wäre wiederholtes scp ineffizient, da es keine Ahnung von „Änderungen“ hat und blindlings alles immer wieder überträgt (auch das, was schon im Ziel vorhanden ist).
Hier kann rsync helfen. Wie scp ein Kommandozeilen-Werkzeug zur Dateiübertragung zwischen (entfernter) Quelle „SRC“ und (entfernter) „DEST“ination, kann es anders als scp aber erkennen, welche Dateien in „SRC“ geändert wurden und überträgt nur diese. Kleine Dateien werden dabei im Ganzen (neu) übertragen, bei großen analysiert rsync die Änderungen (gesichert durch Prüfsummen) und überträgt nur die geänderten Blöcke.
Während der erste Transfer eines gefüllten Verzeichnisbaums in sein noch leeres Ziel kaum schneller sein wird als mit „scp -Cr“, laufen spätere Synchronisierungen deutlich schneller, weil nur noch geänderte (Teile von) Dateien übertragen werden (unveränderte Dateien sind ja schon da).
Zusammengefaßt: ungeänderte Datein gehen ab dem zweiten Transfer gar nicht mehr über die Leitung, geänderte kleine im Ganzen und bei geänderten großen Dateien überträgt rsync nur die Änderungen (Delta).
Beispiel:
tu-id@logc0004:~ $ rsync -aH myResultDir mylocalworkstation.inst.tu-darmstadt.de:/path/to/my/local/resultdir
Details: man rsync
Ausfallsicherheit: teilweise (nach Abbrüchen überträgt rsync nur das, was im Ziel noch fehlt).
Achtung: sowohl scp als auch rsync sind nur „Einbahnstraßen“! Wenn sich zwischen zwei Transfers eine Datei in „DEST“ ändert, wird sie beim nächsten Transfer von ihrer (alten) Version in „SRC“ überschrieben.
Nicht verfügbar auf dem Lichtenberg:
HTTP(S), SMB (CIFS), rcp und andere ältere, (Klartext-) Protokolle.