Die beiden Themen "Compute-Server" (Hr. Pulina) und "Archiv-Server" (Hr. Schiller) waren dabei wohl die interessantesten.
Der bzw. die Rechner, um die es hier geht, sollen die "Comparex" des RZ ersetzen, die hauptsächlich von Physikern benutzt wird. Die derzeitige Rechenleistung der Comparex entspricht ungefähr dem 1,5-fachen einer SparcStation IPX. Sie besitzt 32MB RAM und einen Plattenspeicher von 15GB.
Der Compute-Server soll mit einer Rechenleitung von über 800 SPECfp92 ca. 5 bis 6-mal schneller als die Comparex sein, mindestens 1 GB Hauptspeicher und über 30GB Plattenplatz zur Verfügung stellen.
Aus welcher Hardware besteht der Compute-Server? Darüber war zum Zeitpunkt des Workshops noch nicht das letzte Wort gesprochen. Im Gespräch waren Rechner der Hersteller Sun, Silicon Graphics, HP, IBM und DEC. Von letzteren hat man sich eigens einen Rechner mit Alpha-Prozessor zum Testen angeschafft.
Von welchem Hersteller schließlich gekauft wird, hängt nicht nur von der puren Rechenleistung ab. Eine wichtige Rolle spielt auch die Basis, die für verteilte Anwendungen zur Verfügung gestellt wird. Entsprechend den Rechnern ergeben sich hier zwei mögliche Architekturen.
Bei einem Mehrprozessor-Rechner spielt das Problem der Lastverteilung auf die einzelnen CPUs eine untergeordnete Rolle, da dies in Hardware realisiert ist. Beim Konzept der verteilten CPUs, also bei mehreren einzelnen Workstations, kommt dies jedoch stark zu tragen, da ein Programme dabei auf mehrere unabhängige Rechnern verteilt werden muß. Für dieses Problem ist die passende Software nötig.
Für den Benutzer soll dies jedoch keinen Unterschied machen. Er wird sich von einer Workstation aus über das Ethernet-Backbone in den zum Compute-Server gehörenden File-Server einloggen und dort seine Aufträge starten. Sie werden dann über FDDI an die eigentliche Recheneinheit des Compute-Server weitergeleitet, die den Job in ihr Batch-Processing mit aufnimmt. Dies impliziert, daß der Compute-Server für Multi-User-Betrieb geeignet sein muß, das Betriebssystem wird definitiv Unix-basierend sein.
Auf einer weiteren Besprechung wurde dann beschlossen, die Server der L-Klasse von Silicon Graphics näher unter die Lupe zu nehmen, da diese die interessantesten Merkmale aufweisen: Die Übertragungsrate des Systembusses mit über 1,2GB/s dürfte sich äußerst positiv auf das Multiprocessing auswirken. Außerdem wird vom Compiler parallele Programmierung unterstützt, man kann also z. B. sagen, er soll ein Programm erzeugen, das auf 5 der geplanten 10 CPUs parallel läuft.
Die Tatsache, daß es sich beim verwendeten Prozessor (MIPS R4400) um einen 64Bit-Prozessor handelt, wird keinen sonderlichen Geschwindigkeitszuwachs bringen. Der eigentliche Vorteil besteht aus dem weitaus größeren Adreßraum, der sich bei 64 Bit bietet, was für einige Anwendungen der Physik bereits heute durchaus nötig ist.
Die Rechenleistung, die der Compute-Servers bietet, dürfte wohl einige Zeit ausreichen und die Workstations des Rechenzentrums wieder für "normale" Anwendungen freimachen, so daß man sich nicht mehr über mangelnden Speicher oder CPU-Zeit ärgern muß.
Er wird zum einen für Backups der auf dem Campus verstreuten Unix-Server und in Zukunft auch für den Compute-Server verwendet. Eine Verwendung als Bilddaten-Speicher für die Bereiche Biologie und Klinikum ist ebenfalls denkbar.
Der Archiv-Server besteht aus aus drei Komponenten:
Bei der Auslagerung auf Band bietet sich die Möglichkeit an, gleichzeitig bis zu 16 Sicherheitskopien auf verschiedene Bänder zu schreiben, momentan werden 2 Kopien gemacht. Beim Löschen von Dateien auf dem Server wird das Konzept von Trash-Cans (Mülleimern) unterstützt, gelöschte Dateien können mit einem einfachen Kopier-Befehl daraus zurückgeholt werden.
Wenn Dateien von Bändern gelöscht werden, entstehen Löcher. Diese werden durch ein automatisches Repacking beseitigt, sobald die Belegung einen gewissen Wert unterschreitet.
Der Archiv-Server arbeitet File-basiert mit einer Block-Größe von 60k. Es ist also sinnvoll, nur große Dateien (z. B. tar- oder dump-Archive) abzulegen, da sonst Speicherplatz verschwendet wird. Dafür spricht auch das Limit von maximal 11800 Dateien auf den Cache-Platten. Es ist außerdem darauf zu achten, daß keine Datenkompression vorgenommen wird.
Der Zugriff erfolgt wahlweise über FTP oder NFS. Dabei sind beim Zurückholen von Daten über FTP zwei "get"-Befehle nötig: Einer zum Einspielen des Bandes auf die Cache-Platte, der zweite, um die Datei auf die lokale Platte zu kopieren.
Wie schnell ist der Server? Um eine Kassette einzulegen benötigt der Roboter 8 Sekunden, innerhalb von zwei Minuten wird die Datei dann auf dem Band gefunden. Die Übertragungsrate zwischen Bandlaufwerk und Cache-Platten beträgt 200MB/s, wobei auf beiden Laufwerken parallel gelesen und/oder geschrieben wird. Insgesamt dauerte z. B. das Zurücksichern eines 800MB-Backups ca. 70 Minuten, wobei die Übertragung von der Cache- auf die lokale Platte die meiste Zeit in Anspruch nahm.
Insgesamt wird eine Datensicherheit von 10 Jahren angegeben, was eine erhebliche Verbesserung gegenüber bisherigen Verfahren ist. Nach 2 bis 3 Jahren sind auf herkömmlichen Magnetbändern 20% defekt, so daß sich schon aus Gründen der Datensicherheit die Verwendung des Servers anbietet.