Fileservice an der Humboldt-Universität

Stand und Entwicklung

Im Heft Nr. 5 der RZ-Mitteilungen vom April 1993 wurde in zwei Artikeln das von uns geplante Konzept des Fileservice an der Humboldt-Universität (HUB) beschrieben. Zwischenzeitlich gab es in loser Folge Berichte zur Realisierung des zentralen Fileservice, der mittels der Convex C3820 ES sowie dem VHS- Robotersystem RSS-48 als Hardware und der dazugehörigen Software UniTree stabil im Einsatz am Rechenzentrum ist. Inzwischen sind die Beschaffungen und Erprobungen zum dezentralen Fileservice soweit gediehen, daß hierzu auch ein Bericht zum Stand gegeben werden kann.
Zielstellung des dezentralen Fileservice an der HUB ist, daß an ausgewählten Standorten, die sich in erster Linie aus der Anzahl der dort eingesetzten UNIX-Workstations (WS) ergeben, Fileserver installiert werden, die den Plattenplatz der WS über NFS erweitern, den Hintergrundspeicher der Convex über UniTree nutzen und einen Filesicherungs- und -archivierungsdienst anbieten. Die Nutzung des zentralen Fileservers - der Convex - geschieht über den zentralen FDDI-Ring der HUB.

Abb. 1: Netzstruktur für den Fileservice an der HUB

Für diese Dienste wurden 8 Server vom Typ SPARCServer 1000 mit unterschiedlicher Konfiguration, die sich an den zu erwartenden Bedürfnissen der Standorte und der Aufgabe als File- und nicht als Computeserver orientierte, angeschafft.

Sie sind mit folgender Hardware ausgerüstet

An Software enthalten sie Diese Rechner sind standortbezogen und gehören nicht dem Institut, in dem sie aufgestellt sind. Ihre Administration erfolgt durch das Rechenzentrum in Zusammenarbeit mit dem DV-Verantwortlichen vor Ort.

Versorgte Standorte und zur Verfügung stehender Plattenplatz:

  1. Clara-Zetkin-Str. 26/28, Universitätsstr. 3b und Geschwister-Scholl-Str. 6. Dieser Rechner wird im Rechnerraum des Rechenzentrums aufgestellt.
    10 GB Hard Disk
  2. Invalidenstr. 42/43
    10 GB Hard Disk
  3. Burgstr. 26
    10 GB Hard Disk
  4. Bunsenstr. 1
    1 GB Hard Disk und 12,6 GB Storage Array (Netto 10 GB)
  5. Hessische Str. 1/2
    1 GB Hard Disk und 12,6 GB Storage Array (Netto 10 GB)
  6. Invalidenstr. 110
    2,1 GB Hard Disk und 18,9 GB Storrage Array (Netto 15 GB)
  7. Spandauer Str. 1
    2,1 GB Hard Disk und 18,9 GB Storrage Array (Netto 15 GB)
  8. Unter den Linden 6
    2,1 GB Hard Disk und 31,5 GB Storrage Array (Netto 25 GB)
Die Storrage Array arbeiten unter Raid-Level 5. Daraus ergibt sich der Unterschied zwischen dem Brutto- und Nettospeicherplatz.
Der unter 8. angegebene Server hat zusätzlich zu der Fileservicefunktion für das Hauptgebäude und die dort befindlichen Institute und zentralen Einrichtungen noch die Aufgabe, die Daten für die Datensicherung bzw. -archivierung aus dem gesamten Campus zu sammeln.

Aufteilung des Plattenplatzes auf den Servern und Arbeit mit UniTree

Folgende Aufteilung des Plattenplatzes ist für den Server an einem Standort vorgesehen:
Im DiskCache hat jeder Nutzer - analog zum "normalen" UNIX - ein HOME-Verzeichnis, auf das er mittels FTP oder NFS zugreifen kann. Voraussetzung dafür ist, daß am Standort eine einheitliche Nutzerverwaltung, z.B. über das Network Information System NIS (auch als Yellow Page YP bekannt), existiert.
Files, die im DiskCache abgelegt werden, werden von UniTree nach einem voreingestellten Zeitraum in den Sekundärspeicher migriert. Dies ist bei uns das VHS-Robotersystem RSS-48 an der Convex im Rechenzentrum. Solange genügend Speicherplatz im DiskCache vorhanden ist, existieren die Files in beiden Ebenen. Wird der DiskCache zu voll, streicht UniTree die größten und am längsten nicht mehr angefaßten Files aus dem DiskCache, so daß sie nur noch im Robotersystem vorhanden sind. Wird so ein File vom Nutzer angefaßt, wird er aus dem Robotersystem in den DiskCache wieder eingelagert. Dieser Vorgang heißt caching oder auch staging.
Die Arbeitsweise von UniTree ist im Heft 6 der RZ-Mitteilungen genauer beschrieben.
Um den Datentransfer auf dem Netz etwas einzuschränken, werden die Zeiten für die Migration so eingestellt, daß sie in erster Linie in den Abend- und Nachtstunden erfolgt.
Eine schematische Darstellung des Zusammenspiels zwischen einer WS, UniTree auf einem dezentralen Fileserver (DZFS) und dem zentralen UniTree auf der Convex (joker) ist in der folgenden Abbildung 2 dargestellt. Dabei wurde angenommen, daß der DiskCache des DZFS mittels NFS auf der WS gemounted ist.

Einige Empfehlungen zur Arbeit mit dem DiskCache:

Abb. 2: Datenfluß innerhalb UniTrees in der Zusammenarbeit von dezentralem und zentralem Fileserver

Sicherung und Archivierung von Daten

Mit der Beschaffung der dezentralen Fileserver wurde die Software "SM-arch" gekauft, die eine Datensicherung für ausgewählte Rechner ermöglicht. Mit ihrer Hilfe kann auch eine Archivierung von Daten realisiert werden. Zu den Begriffen Datensicherung und -archivierung kann in dem Artikel über den Fileservice an der HUB in Heft 5 der RZ-Mitteilungen nachgelesen werden.
In einer ersten Etappe wird für die Archivierung auf jedem Fileserver ein Bereich angelegt, der über Nacht mittels SM-arch in das UniTree auf dem dezentralen Fileserver des Rechenzentrums abgezogen wird. Von dort wird er auf spezielle VHS-Bänder, die gedoppelt werden, migriert. Wenn die Daten erfolgreich archiviert sind, werden sie aus dem Bereich gestrichen, so daß sie dann nur noch im Archiv vorliegen.
Da diese Archivierungsbänder aus Kapazitätsgründen nicht im Robotersystem enthalten sind, muß sich der Nutzer zum Rearchivieren mit den Bedienern des Rechenzentrums abstimmen.
Zu diesem Punkt erscheinen in der nächsten Ausgabe der RZ-Mitteilungen weitere Informationen.

Abb. 3: Schematische Darstellung des Archivierungsvorganges

Christoph Weickmann

6.1.95 / cs
last Update: 11.1.95, 11:30, cs