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.

Rechte

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.

Gruppen-Zugriffsrechte

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\

Falls der Rechner nicht in der ADS-Domain ist, muss man sich mit ads-dom\<Account> und dem Uni-Passwort verbinden.

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

 

Letzte Änderung: 06.11.2017 - Ansprechpartner:

Sie können eine Nachricht versenden an: Webmaster
Sicherheitsabfrage:
Captcha
 
Lösung: