Gruppenlaufwerke CIFS/NFS
Allgemeines
Für jedes Institut/Zentrale Einrichtung (Gruppe) wird im zentralen Storage-System der OVGU ein Speicherbereich für gemeinsame Projekte zur Verfügung gestellt. Die Struktur ist an das LSF angelehnt.
Die NetApp-Einbindung für Ubuntu-Systeme finden Sie hier.
Zugriffsrechte
Die Nutzer sind entsprechend ihrer Kostenstelle(n) einzelnen Gruppen zugeordnet. Durch die DV-Beauftragten der Einrichtung können lokale Gruppen unter https://wlux.urz.uni-magdeburg.de/localadmin erstellt und gepflegt werden. Für die Unterordner können die Rechte feingranular auf Gruppen- oder Nutzerbasis eingestellt werden. Der unter jedem Institut angelegte Ordner "public" ist per Standard mit Leserechten für alle OVGU-Accounts ausgestattet und ist für öffentliche Dateien und Verzeichnisse gedacht.
Verbindung aufbauen
\\stgroup.ovgu.de\group\FAKULTÄT\INSTITUT\ Beispiel: \\stgroup.ovgu.de\group\ \\stgroup.ovgu.de\group\ze\urz\ \\stgroup.ovgu.de\group\fmb\ilm\
Wenn Ihr Computer nicht Teil der ADS-Domain ist, so fügen Sie Ihrem Benutzernamen @ads.uni-magdeburg.de an.
Für den Zugang per NFS muss der Client die Kerberos-Server des URZ (lem, bowles, strugazki) benutzen. Weiterhin ist ein NFS-Serviceticket für die /etc/krb5.keytab erforderlich, welches vom URZ ausgestellt wird. Es wird zurzeit nur die NFS-Version 4.1 angeboten.
mount -o nfsvers=4,minorversion=1,sec=krb5 stgroup.ovgu.de:/group /import/group
mount -o nfsvers=4,minorversion=1,sec=krb5 stgroup.ovgu.de:/group/ze/urz /mnt
mount -o nfsvers=4,minorversion=1,sec=krb5 stgroup.ovgu.de:/group/fmb/ilm /mnt
CentOS5 - kann max. NFS 4.0
- bietet keine ausreichend starke Verschlüsselung für die Authentifizierung
- wird deshalb nicht unterstützt
CentOS6 - wird unterstützt
CentOS7 - wird unterstützt
Quota
- 100GB per default mittels Qtree für Institute und zentrale Einrichtungen
- ist individuell und global anpassbar
- bei speziellem Bedarf werden weitere Volumes eingebunden
Backup
Snapshots zum Restore durch die Nutzer selbst:
- für die letzten 24 Stunden einer pro Stunde, insgesammt 24
- für die letzte Woche einer pro Tag, insgesammt 7
- für die letzten 3 Monate einer pro Woche, insgesammt 14
- bei einer hohen Änderungsrate muss entweder die Speicherzeit verkürzt oder der Platz für Snapshots vergrößert werden
Backup auf Band für Desaster-Recovery:
- einmal pro Woche am Wochenende
- alle 4 Wochen ein Full-Backup
- dazwischen Cumulative Backups, d.h. jedes Mal die Differenz zum Full-Backup
- Aufheben für 6 Monate
- wenn das Backup über das Wochenende nicht fertig wird, muss entweder darauf verzichtet oder in andere Technologien investiert werden