Testbetrieb - Dateistruktur: Unterschied zwischen den Versionen
Aus HPC@HU
(→Dateistruktur:: Korrektur des Pfads) |
|||
(6 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 8: | Zeile 8: | ||
Im Testbetrieb sind folgende Laufwerke verfügbar: | Im Testbetrieb sind folgende Laufwerke verfügbar: | ||
<code>/tmp</code> als lokaler scratch, über 'auto_tmpdir', etwa 1TB | |||
<code>/lustre</code> als geteiltes zentrales Netzwerklaufwerk mit etwa 1.5PB auf das alle Knoten direkt zugreifen können. Es werden automatisch Unterordner für Fachbereiche und Nutzer, ähnlich <code>$HOME</code> angelegt. | |||
<code>/home/<Fachbereich>/<UserID></code> für <code>$HOME</code> als zentrales "home directory" auf das per NFS zugegriffen wird. | |||
<!-- | |||
<code>/scratch</code> als lokaler scratch (1TB, bitte nicht 'zumüllen' und das Löschen von temporären Dateien im Script einplanen!) | <code>/scratch</code> als lokaler scratch (1TB, bitte nicht 'zumüllen' und das Löschen von temporären Dateien im Script einplanen!) | ||
<code>/globalscratch</code> als Netzwerklaufwerk welches von mehreren Virtuellen Maschinen gleichzeitig erreicht werden kann (langsame Leistung) | <code>/globalscratch</code> als Netzwerklaufwerk welches von mehreren Virtuellen Maschinen gleichzeitig erreicht werden kann (langsame Leistung) | ||
--> | |||
Es wird empfohlen im Testbetrieb das lokale Laufwerk zu privilegieren. Auch im Regelbetrieb dürfte dies aufgrund von Latenzen der bevorzugte Pfad sein. | |||
Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master). | |||
Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /<code>tmp</code> erreichbar ist (sowie <code>/var/tm</code> und <code>/dev/shm</code> ). | |||
Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren. | |||
Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen: | |||
#!/bin/bash | |||
#SBATCH --ntasks=1 # Run on a single CPU | |||
#SBATCH --mem=1gb # Job memory request | |||
#SBATCH --time=00:05:00 # Time limit hrs:min:sec | |||
#SBATCH --partition=std | |||
#SBATCH --account=nutzername | |||
## set path to root of job data | |||
basedir=/globalscratch/nutzername/myjob | |||
## copy job data | |||
cp -r $basedir/* /tmp | |||
## change to working director | |||
cd /tmp | |||
## do the work | |||
hostname > $basedir/result.log | |||
## copy the results if they are required | |||
cp -r /tmp/* $basedir | |||
===== Zugriffsrechte: ===== | ===== Zugriffsrechte: ===== | ||
Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.) | Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.) | ||
Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich. | Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich. | ||
In der der aktuellen Implementierung lassen sich diese über <code> | In der der aktuellen Implementierung lassen sich diese über <code>getfacl</code> in Erfahrung bringen, über <code>setfacl</code> setzen oder modifizieren. | ||
<!--In der der aktuellen Implementierung lassen sich diese über <code>nfs4_getfacl</code> in Erfahrung bringen, über <code>nf4_setfacl</code> setzen und über <code>nfs4_editfacl</code> editieren. | |||
Es ist möglich die Rechte über den Benutzernamen zu setzen, dabei muss dieser als <code>benutzername@localdomain</code> eingegeben werden.--> | |||
Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist. | |||
<!--Alternativ kann die ID des Nutzers oder einer Gruppe genutzt werden, welche sich über <code>id -u benutzername</code> oder <code>getent group gruppenname</code> abfragen lassen. | |||
Leserechte für eine Datei liesen sich wie folgt setzen: | Leserechte für eine Datei liesen sich wie folgt setzen: | ||
nfs4_setfacl -a "A::benutzername@localdomain:RX" test-datei | nfs4_setfacl -a "A::benutzername@localdomain:RX" test-datei | ||
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind, mit den Optionen <code>d</code> und <code>f</code> werden die Zugriffsrechte auf neu erstellte Dateien und Unterverzeichnisse vererbt. | Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind, mit den Optionen <code>d</code> und <code>f</code> werden die Zugriffsrechte auf neu erstellte Dateien und Unterverzeichnisse vererbt. | ||
nfs4_setfacl -R -a "A:df:benutzername@localdomain:rx" pfad-zur/test-datei | nfs4_setfacl -R -a "A:df:benutzername@localdomain:rx" pfad-zur/test-datei | ||
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: https://www.osc.edu/book/export/html/4523 | Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: https://www.osc.edu/book/export/html/4523--> | ||
Leserechte für eine Datei liesen sich wie folgt setzen: | |||
<code>setfacl -m u:benutzername:r test-datei</code> | |||
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind. | |||
<code>setfacl -Rm u:benutzername:r pfad-zur/test-datei</code> | |||
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl<!-- Übersicht: https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls --> | |||
Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen: | Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen: |
Aktuelle Version vom 22. Juli 2024, 08:47 Uhr
Dateistruktur:
Im Rahmen des Testbetriebs sind die endgültigen Dateipfade sowie die endgültigen Dateisysteme noch nicht vollständig konfiguriert.
Langfristig wird ein Lustre als zentrales "scratch" bereitgestellt, dieses ist aber aktuell noch nicht verfügbar.
Im Testbetrieb sind folgende Laufwerke verfügbar:
/tmp
als lokaler scratch, über 'auto_tmpdir', etwa 1TB
/lustre
als geteiltes zentrales Netzwerklaufwerk mit etwa 1.5PB auf das alle Knoten direkt zugreifen können. Es werden automatisch Unterordner für Fachbereiche und Nutzer, ähnlich $HOME
angelegt.
/home/<Fachbereich>/<UserID>
für $HOME
als zentrales "home directory" auf das per NFS zugegriffen wird.
Es wird empfohlen im Testbetrieb das lokale Laufwerk zu privilegieren. Auch im Regelbetrieb dürfte dies aufgrund von Latenzen der bevorzugte Pfad sein.
Um die Nutzung des lokalen scratch zu unterstützen wird das Plugin "auto_tmpdir" der University of Delaware genutzt (https://github.com/University-of-Delaware-IT-RCI/auto_tmpdir/tree/master).
Dieses Plugin erstellt einen dedizierten Ordner für einen ausgeführten job welcher dann unter /tmp
erreichbar ist (sowie /var/tm
und /dev/shm
).
Der Vorteil des Plugins ist, dass sich dieses um de Erstellung der Mounts sowie dem Löschen der Mounts und Dateien kümmert. Da die Dateien nach Ende des Jobs gelöscht werden, ist es wichtig die Ausgabe anderweitig zu "streamen" oder das Endergebnis zu kopieren.
Exemplarisch könnte ein Script für die Nutzung wie folgt aussehen:
#!/bin/bash #SBATCH --ntasks=1 # Run on a single CPU #SBATCH --mem=1gb # Job memory request #SBATCH --time=00:05:00 # Time limit hrs:min:sec #SBATCH --partition=std #SBATCH --account=nutzername ## set path to root of job data basedir=/globalscratch/nutzername/myjob ## copy job data cp -r $basedir/* /tmp ## change to working director cd /tmp ## do the work hostname > $basedir/result.log ## copy the results if they are required cp -r /tmp/* $basedir
Zugriffsrechte:
Typisch für ein klassisches SLURM cluster, werden die regulären UNIX Rechte und Gruppen eingesetzt. Diese ermöglichen es Ordner auf dem geteilten Laufwerk nur für bestimmte Nutzer und Gruppen freizugeben. Allerdings ist die regulären Linux Rechteverwaltung hier in Bezug auf eine detaillierte Rechteverteilung stak eingeschränkt. (Da es nicht praktisch möglich ist für alle möglichen Kombinationen dedizierte Gruppen anzulegen.)
Eine feinere Rechteverwaltung, sofern notwendig ist über Access Control Lists (ACL) möglich.
In der der aktuellen Implementierung lassen sich diese über getfacl
in Erfahrung bringen, über setfacl
setzen oder modifizieren.
Die access control lists werden für den jeweiligen Benutzernamen gesetzt, welcher hier die User-ID des HU-Accounts ist.
Leserechte für eine Datei liesen sich wie folgt setzen:
setfacl -m u:benutzername:r test-datei
Rechte lassen sich ebenfalls rekursiv setzen, wodurch alle Dateien und Ordner abgedeckt sind.
setfacl -Rm u:benutzername:r pfad-zur/test-datei
Weiterführende Informationen zu Access Control Lists inklusive einer Erklärung der "flags" finden sich auf der Seite des Ohio Supercomputing Centre: https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl
Sollte es notwendig sein die Zugriffsrechte auf spezifische Benutzer (und nicht nur einen Fachbereich) zu begrenzen wird folgender Vorgang empfohlen:
Die regulären UNIX/POSIX-Rechte werden auf den Eigentümer reduziert, ohne Zugriffsrechte für die Gruppe oder Welt. Dies entspräche einem r-x------
(500) oder rwx------
(700). Das Aufzeigen von Inhalten in Ordnern erfordert hierbei die Ausführungsrechte (x
). Für Dateien welche nicht ausgeführt werden reichen Lese- und Schreibrechte (r--
/ rw-
).
Im nächsten Schritt werden berechtigen Nutzern über die ACLs Zugriffsrechte eingeräumt - der Gruppe bleibt hierbei weiter der Zugriff auf der POSIX-Basis verwehrt.
Anmerkung: Sollte die Vertraulichkeit von Daten eine Einschränkung der Zugriffsrechte erfordern, sollte im Allgemeinen minimalste Rechte eingeräumt werden. So wenige wie möglich, so viele wie erforderlich. Andererseits ist ein konventionelles HPC-Cluster nicht für hochsensible Daten ausgelegt. In diesem Fall bitten wir darum dass mit dem HPC-Team unter hpc-suppport@hu-berlin.de Kontakt aufgenommen wird um eventuelle Lösungsansätze zu besprechen.
Externer Zugriff:
Der Zugriff auf das Dateisystem erfolgt über sftp (ftp ûber ssh) aus dem Netz der Humboldt Universität heraus.
Die ist unter Windows mit WinScp ( https://winscp.net/ ) möglich - auch in Verbindung mit putty ( https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html ) für die Befehlszeile - und wird unter Linux im Plasma Desktop nativ von Dolphin unterstützt.