Dateisysteme des Clusters

Dateisysteme

Für Nutzerdaten stehen die folgenden Dateisysteme zur Verfügung:

Mountpoint /home /work/scratch /work/projects /work/local
Größe >300 TByte (300.000 GByte) >900 TByte (900.000 GByte) >150 TByte (150.000 GByte) >100 GByte pro Knoten
Zugriffszeit normal schnell schnell sehr schnell, besonders kurze Latenzzeiten
Daten
erreichbar
global von allen Knoten global von allen Knoten global von allen Knoten lokale Platten an den Rechenknoten, Daten sind von anderen Knoten aus nicht erreichbar
Daten
verfügbar
dauerhaft Daten werden nach 8 Wochen unwiderruflich und ohne Vorankündigung gelöscht für die Projektlaufzeit nur während der Job läuft
Quota 15 GByte, nach Absprache evtl. mehr 10 TByte oder 2 Mio. Dateien, nach Absprache evtl. mehr nach Absprache keine
Backup Snapshots (s.u.) +
tägl. Tape-Backup (desaster recovery)
nein

/home

Das Homedirectory sollte für alle Daten verwendet werden, die dauerhaft wichtig sind. Der /home-Bereich liegt auf besonders gesichertem Plattenplatz. Auf der anderen Seite ist das Dateisystem daher relativ langsam (im Vergleich zu /work/scratch oder $HPC_LOCAL) und jeder Nutzer bzw. jede Nutzerin darf dort nur eine begrenzte Datenmenge ablegen. Die Standardquota beträgt derzeit 15 GByte. Nach Absprache kann die Quota im begründeten Einzelfall erhöht werden. Das Verzeichnis /home/$USER („Home“) wird gleichzeitig mit dem Nutzerkonto erzeugt. Man kann es wie üblich mit der Umgebungsvariable $HOME erreichen.

In regelmäßigen Abständen wird ein Abbild des Home-Verzeichnisses eingefroren („Snapshots“). So ist es möglich, selbst und ohne Administratorhilfe auf ältere Versionen Ihrer Daten zurückzugreifen. Die Snapshots sind in dem unsichtbaren Verzeichnis .snapshots gespeichert (das auch mit 'ls -la' nicht angezeigt wird). Sie können trotzdem mit „cd $HOME/.snapshots“ in dieses Verzeichnis wechseln (<TAB>-completion funktioniert nicht, man muss „.snapshots“ komplett ausschreiben). Darin findet man in Unterverzeichnissen (hourly.*/, 6hour.*/, daily.*/ und weekly.*/) den Zustand seines $HOME der letzten Stunden, Tage oder Wochenenden.
Die Dateien im Snapshotverzeichnis belegen weiterhin Speicherplatz! So ist es möglich, dass Sie die Quota für Ihr Homeverzeichnis bereits überschreiten, obwohl ein 'df' noch freien Platz anzeigt. Desweiteren können Sie Snapshots nicht selbst löschen (denn ein Löschen entfernt die Dateien nur aus der aktuellen Sicht, nicht jedoch aus dem Snapshotbereich).

Durch häufiges Anlegen und Löschen von Dateien füllt sich der Snapshot-Bereich (und damit Ihre Quota) schneller und beansprucht mehr Platz im Homeverzeichnis. Darum sollte häufiges Anlegen/Löschen von Dateien in $HOME – wenn möglich – vermieden werden. In dringenden Fällen können wir jedoch Snapshots auf administrativer Ebene löschen und damit wieder Platz freigeben.

Außerdem findet regelmäßig (derzeit wöchentlich) ein Band-Backup des gesamten Home-Bereichs statt, jedoch nur für ein Desaster-Recovery. Eine Wiederherstellung einzelner Nutzerdateien daraus ist nicht möglich.

/work/scratch

Hier gibt es für alle NutzerInnen Plattenplatz in (nahezu) unbegrenzter Menge, aber nur für begrenzte Zeit: Die hier abgelegten Daten werden ohne vorherige Warnung nach 8 Wochen gelöscht. Sie sind nicht durch ein Backup gesichert. Die Standardquota beträgt derzeit 10 TByte oder 2 Mio. Dateien. Nach Absprache kann die Quota im Einzelfall erhöht werden.

Die Plattenkonfiguration für die /work-Bereiche ist ganz auf Performance und Kapazität ausgelegt – von den clusterweit verfügbaren Filesystemen ist /work/scratch das durchsatzstärkste.

Das Verzeichnis /work/scratch/$USER („Scratch“) wird gleichzeitig mit dem Nutzerkonto erzeugt. Man kann es mit der Umgebungsvariable $WORK_SCRATCH erreichen.

/work/local

Die lokalen Platten der einzelnen Compute-Knoten werden unter „/work/local“ gemountet und eignen sich zum Speichern von rein intermediären/temporären Daten während der Laufzeit eines Jobs auf einem Knoten. Durch die kurzen Latenzzeiten können Zwischenergebnisse hier effizient und schnell gespeichert und gelesen werden.
Beim Starten des Jobs werden auf den einzelnen Knoten die Verzeichnisse /work/local/$SLURM_JOBID und /work/local/$SLURM_JOBID/tmp erzeugt und es werden die entsprechenden Umgebungsvariablen $WORK_LOCAL und $TMP gesetzt.
Nach dem Ende des Jobs werden die Verzeichnisse samt Inhalt wieder automatisch gelöscht. Wichtige Endergebnisse müssen daher vor dem Ende des Jobs ins Home-Verzeichnis oder ins Scratch-Verzeichnis (s. o.) gerettet werden!
Daraus ergibt sich auch, dass $HPC_LOCAL/ nicht zum Ablegen von Checkpoint/Restart-Files geeignet ist, mittels derer Folgejobs die Rechnungen fortsetzen sollen.

Der lokale Plattenplatz der Login Knoten ist größtenteils dem /tmp-Verzeichnis zugewiesen, da hier der auf Slurm-Job-IDs basierende Mechanismus nicht paßt.

Technik

Alle oben aufgeführten globalen, also cluster-weit verfügbaren Dateisysteme sind mittels IBMs Spectrum Scale (früher General Parallel File System) aufgesetzt. Dieses kommerzielle, lizenzpflichtige Produkt erlaubt es, große Plattenverbünde an Tausende von Knoten über Infiniband freizugeben.
Die Schreib-/Lesevorgänge solch enormer Knotenzahlen zu prüfen und zu verarbeiten dauert natürlich etwas länger als auf lokale Platten zuzugreifen. Daher kann es auf dem GPFS immer mal wieder zu kurzen „Gedenksekunden“ kommen, wenn man ls -l o.ä. ausführt.

Die lokalen Platten in den Compute- und Login-Knoten sind meist übliche SATA-Disks (auf einigen Knoten im RAID-Verbund) mit ext4. Da Jobs ihre(n) Knoten (und dessen Platten) jedoch meist exklusiv für sich haben, sind diese lokalen Platten meist schneller als das globale GPFS.