Sittel, Frank

German

edoc Publication server

Überblick zum Fileservice ab 1990

Dokumenten-Publikationsserver der Humboldt-Universität zu Berlin

50 Jahre Rechenzentrum /  Computer- und Medienservice  der Humboldt-Universität zu Berlin54Überblick zum Fileservice ab 1990Frank SittelEinleitungDie ersten Jahre des ORZ (Or- ganisations- und Rechenzen-trum) wurden durch Einzel- oder Groß-Rechentechnik dominiert, die zentral bedient und gewartet wurde. Für die nur sehr vereinzelt existieren-de Büro-Computer-Technik wurde von Seiten des ORZ Hilfe bei der Inbetriebnahme und technischen Wartung gegeben, aber dezentrale Dienste, wie wir sie heute verstehen (wie Vernetzung, Mail, Backup), gab es über-haupt nicht. Erst das Ende der DDR, der Neustart ins RZ und die damit verbun-denen Erstbeschaffungsmittel ermöglichten den Aufbau einer vernetzten, dezentralen Rechnerumgebung. Und die Betonung liegt auf „Netz“ – ohne den Aufbau eines uni- versitätsweiten LAN und spä-ter SAN ist die Explosion von Diensten, wie wir sie heute um uns haben, schlicht un-möglich. Mit der Vernetzung und dem Einzug der Arbeits-platzrechner ergab sich der Bedarf nach Unterstützung dieser Systeme durch das RZ. Stück für Stück wurden universitätsweite Dienste etabliert. Der Fileservice ver-stand sich im Rahmen dieser Entwicklung als ein Dienst, der den Angehörigen der Uni-versität einen sicheren Ort anbietet, an dem sie ihre Da-teien ablegen, wiederfinden und diese im Desaster-Fall auch restaurieren können.Backup-Server und -Library (1999-2010)55Ahnung, wo sie tatsächlich landen würden und trotzdem die Hoffnung, sie zurückzu-bekommen. In den folgenden 10 Jahren war VINES so erfolg- reich, dass es zu seinen bes- ten Zeiten auf 102 Servern knapp 50 Organisationen mit 8000 Nutzern beherbergte.„Street Talk“ von VINES. Das  dreistufige Namenskonzept  war genial einfach und intuitiv: objekt@gruppe@organisation, wobei Objekte sowohl Nutzer als auch Dienste und Listen sein durften. An den Diensten wurden die Berechtigungen verwaltet. Der Ruf nach der Disk sah dann so aus:C:\>  setdrive  t:   „Temp Disk@A4@HUB-RZ“Und dieser Zugriff funktio-nierte von jedem PC, auf dem ein VINES-Client installiert war – egal wo er stand und wie er hieß – unterstützt wurden  DOS, Windows, OS/2 und Apple Macintosh. Die Street-Talk-Struktur hinter diesem Zugriff sieht in etwa so aus, wie in der folgenden Abbil-dung dargestellt.Auf diese Art wurden die Nut- zer daran gewöhnt, ihre wich-tigen Daten auf VINES-Lauf-werke abzulegen. Dort wurden sie nämlich gesichert – naja, in der Anfangszeit wurden sie einmal pro Woche auf ein Tape geschrieben. Nichtsdes- totrotz war dies der Anfang eines wirklichen Fileservice. Die Nutzer vertrauten dem VINES ihre Daten an und hat- ten meistens nicht die geringste Banyan VINES ab 1990Im Herbst des Jahres 1990 wurden einige PCs beschafft, eine Handvoll BNC-Kabel durch die Räume des RZ ge-zogen und in einer Kammer neben dem Rechnerraum zwei Tower-Rechner aufge-stellt, auf denen ein Stapel Disketten mit der Aufschrift „Banyan/VINES“ eingespielt  wurde und schon war die Humboldt-Universität im Besitz des ersten Netzwerk- Dienstes, der darauf ausge- richtet war, eine gemeinsame  Nutzung von Platten, Dru- ckern, Gateways und Servern zu ermöglichen. Das Hervor-stechende an VINES (VIrtual NEtwork System) war, dass es sich dabei um ein service- und nicht serverorientiertes System handelte, d. h. ein Nutzer am PC musste über-haupt nicht wissen, wo sein Platten lagen, wo der Drucker angeschlossen war und wie er an seine Mail kam – er rief  einfach „Her mit der Temp-Disk der Abteilung 4“ und schon kam sie durch das Netz- werk angeflogen! Ermöglicht wurde dies durch den ersten Verzeichnis-Dienst der HU  in einer Zeit, in der noch nie- mand ahnte, was Verzeichnis- Dienste überhaupt sind –  Street-Talk-Struktur56zierten Wert, dann werden alte und große Dateien gelöscht, bleiben aber in der File-System- Ansicht erhalten. Greift man auf gelöschte Dateien zu, dann werden sie vom Band zurück auf den Cache kopiert und man kann sie stark verzögert benutzen. Der besondere Witz  unserer HSM-Lösung bestand aber darin, dass sich der Tape- Server nicht nur mit einem, sondern mit beliebig vielen  Disk-Caches verbinden konnte.Das führte 1993 zur Beschaf-fung von acht Sun-Servern mit Disk-Arrays, die wir in die In-stitute verteilten (Wirtschafts- wissenschaften, Physik, Che- mie, Mathematik ...). Jeder von diesen Servern hatte neben einem „normalen“ Disk-Be-reich von 5–10 GB, der per NFS verteilt wurde, einen zusätz-lichen Disk-Cache für Unitree und dieser konnte so lange be- schrieben werden, wie es die Tape-Library hergab – es ging  also „unendlich“ viel hinein.  Zudem hatten wir eine Backup- Lösung der Firma „Software Mogul“ mit dem Namen SM-arch im Einsatz, die nicht mit der Tape-Library kommuni-zierte, sondern mit dem HSM von Unitree. Damit hatten  wir für den Unix-Bereich erst- mals eine umfassende File- 1 TB passte – zu dieser Zeit  war Terabyte noch ein Synonym für unendlich. Das Bestechende an diesem Ungetüm (Convex + Library) war die Software, die das alles zusammenhielt: Unitree. Es war unsere erste Begegnung mit einem automatischen HSM-System (Hierarchical Storage Management) und dieses System hatte es in sich. Unitree reserviert einen Disk-Bereich (Cache) für sich, in dem man lokal, per NFS oder FTP Dateien einspielen kann. Diese Dateien werden nach einer vorgegebenen Zeit über einen Tape-Server-Pro-zess in die Library kopiert. Füllt sich dieser Disk-Bereich bis zu einem vorher spezifi-Unix-Fileservice  1993 – 1999Anfang der 90er Jahre waren  Unix-Workstation auf RISC- Basis sehr populär, da sie in Prozessor- und Grafikleistung den PCs noch deutlich überle-gen waren. Die Anzahl wuchs vor allem in den naturwissen-schaftlichen Instituten und Ba-nyan VINES hatte für Unix als Klient nichts übrig. So wurde Ende 1992 schon in Hinblick auf diese zukünftigen Klienten ein zentraler Compute- und Fileserver Convex C3820 be- schafft, ein Vektorrechner mit zwei riesigen Vektor-CPUs und Anschluss an eine Tape- Library. Diese Library hatte  zwei Laufwerke und 48 VHS- Bänder, auf die etwas mehr als Datenfluß des UniTree (dezentral – zentral)57Backup und HSM mit TSM seit 1999Eines der Dinge, die wir aus dem Unitree/SM-arch-Zeiten gelernt haben, war, dass die Nutzer HSM zwar ganz nett fanden, aber eigentlich viel dringender eine gute Backup- Lösung suchten. Da SM-arch auf Unitree nicht wirklich gut  skalierte, sahen wir uns nach  einer leistungsfähigen Back-up-Lösung um, die zudem auch eine HSM-Komponente  besaß. Wir fanden sie im Tivoli Storage Manager (TSM) von IBM, der außer Backup-  auch HSM- und Archivie-rungskomponenten besaß. Der eigentliche Reiz von TSM besteht im Backup-Verfahren  „incremental forever“, was bedeutet, dass es einen Full- Backup nur ein einziges Mal gibt – beim Start. Danach Deutlich schlechter sah es  mit unserem Unix-Fileservice aus. Vor allem HSM und der  Backup-Dienst drohten, völlig auszufallen. In einer Hau-ruck-Aktion wurden nicht nur Mittel bewilligt und eine Ausschreibung vorbereitet, sondern wir erhielten zudem  die Chance, den Fileservice neu auszurichten. Zwei Neu- linge hielten Ende 1999 Ein- zug ins RZ: das Backup-Sys- tem TSM von IBM und das SAN.Das Jahr 1999Das Jahr 1999 war in der Öf-fentlichkeit vor allem durch  Katastrophen-Szenarien ge-prägt, was wohl zur Jahrtau-sendwende so alles passieren könnte. Uns ereilten zwei wirkliche Katastrophen. Die Firma Hewlett-Packard, die 1995 Convex übernommen hatte, gab uns am Anfang des Jahres die Garantie, dass sowohl die Convex C3820  als auch die angeschlossene  Tape-Library den Jahreswech-sel nicht überstehen würden. Das zweite Desaster passierte im Herbst – die Firma Banyan kündigte ihre Produktpalette auf (vor allem VINES) und benannte sich in ePresence  um, die dann nur noch Kun- den beraten wollte, wie sie aus VINES herauskommen können. Zumindest hat sie kurz vor ihrem Zusammen-bruch noch die letzte Versi-on 8.5 und Jahr-2000-Patche herausgereicht, so dass an dieser Front kein sofortiger Handlungsdruck bestand. Der größte Teil der VINES-Server lief noch bis 2003 und dann kam es zu einem sukzes-siven Wechsel in Richtung Windows-Fileservice unter dem Active-Directory-Service. service-Lösung mit realem Plattenplatz per NFS für Home- Directorys, ein langsames, aber sehr großes HSM und ein Backup-System. Aus einem  Vortrag stammte die Veran-schaulichung unseres HSMs.Was uns dieses dezentrale Server-System außerdem  nahebrachte, war, dass die Festplatten nicht im selben Gehäuse wie der Server un-tergebracht werden mussten. Die „SPARC Storage Arrays“ waren Stand-Alone-Geräte, die mit Glasfaser-Leitungen hunderte von Metern entfernt von den eigentlichen Servern stehen konnten, was wir in einem Fall tatsächlich auch so benutzt haben. Außerdem war auf den Leitungen die irr- sinnige Transfer-Leistung von  200 MBit/s – das war doppelt so schnell wie FDDI. Die Er- fahrung aus dieser Zeit min- derte unsere Berührungsangst  mit dem SAN im Jahre 2000 deutlich.Verkabelung an einem Fiber-Channel-Switch58werden nur noch die geänder- ten Daten gesichert. Außer-dem gehörte es ab sofort zu unseren Design-Prinzipien, alle wichtigen Daten (und alle Daten sind wichtig) doppelt an zwei Standorten zu halten. So wurden zwei Backup-Ser-ver und -Librarys für die Stand- orte Mitte Hauptgebäude und  Adlershof Informatik beschafft.  In den Anfangsjahren wurden aus Kapazitätsgründen nur die Archiv-Daten auf den je- weilig anderen Standort ge- doppelt – heute auch alle Backup-Daten. Die 1999 be- schafften Backup-Systeme waren von der Struktur her Produkte des letzten Jahrtau- sends – monolithische Blöcke: IBM-Server mit per SCSI direkt angeschlossenen Tape- Librarys und lokalen Platten- arrays. Das wurde 2003 auf- gebrochen, als die StorageTek- über den Umweg von zwei SCSI-FC-Routern mit einer Kapazität von 6,5 TB ans SAN brachte. Einen Produk-tions-„Test“ bestand dieses System erfolgreich und so wurden in den folgenden drei Jahren weitere Türme des Selbst-Bau-Typs installiert. Schon 2001 wurde klar, dass eine direkte Zuweisung von Speicher an unsere Klienten (die Server der Universität) mit wachsender Speicher- und Klienten-Zahl ein expo-nentiell wachsendes Manage-ment-Problem darstellt. So begannen wir 2002, verschie-dene Management-Lösungen zu untersuchen. Pünktlich 2003 – zum Umzug des CMS ins Erwin Schrödinger-Zen-trum – konnte die Grund-struktur unseres SANs dank der Erstbeschaffungsmittel für dieses Gebäude realisiert werden, wie sie qualitativ noch heute Bestand hat: zwei unabhängige FC-Netzwerke, Verbindung der Standorte Mitte und Adlershof per WDM, Einsatz von hochverfügbaren Core-Switchen, Virtualisie- rung des Speichers als Ma- nagement-Mittel, Gebäude- und Standort-Vernetzung in Ring-Topologien usw. In diesem System ist alles Das SAN ab 2000Einer der wesentlichen Grün-de, ein SAN (Storage Area Network) aufzubauen, ist, die Datensicherheit deutlich zu erhöhen. Durch ein Netzwerk wird es erst möglich, im groß-en Stil Duplikate der Daten  über Gebäudegrenzen hinweg zu erstellen. Doch zuerst mussten die technischen Voraussetzungen geschaffen werden. Angefangen haben wir zu Beginn des Jahres 2000 mit zwei IBM-Speicher-türmen, die 60 SCSI-Platten fassten, je 1,5 TB Plattenvolu- men lieferten und mit zwei-mal 1-GBit an die Switche an- geschlossen waren, mit zwei 16-Port-1-GBit-FC-Switchen der Firma Brocade und einer Handvoll Servern, die die Sun- Server ersetzten. Da war noch nicht viel mit Redundanz – 2000 haben wir vor allem die Technologie geübt und diverse Tests durchgeführt. Eines wurde bald klar – ein bezahlbarer Ausbau der Spei-cherkapazitäten im SAN war mit FC- oder SCSI-Platten nicht möglich. So haben wir schon 2000 probiert, ob und wie IDE (oder PATA) Arrays verwendet werden können. Bald war der erste Selbst-Bau-Turm fertig, der 12 IDE-Arrays  Library in Adlershof durch eine von Quantum ersetzt wurde, deren Laufwerke nun über das SAN angesprochen wurden. Der neue TSM-Server  erreichte auch seine Cache- Arrays nur noch über Fiber- Channel-Verbindungen. Bei der Umrüstung 2009 hatten dann alle Laufwerke an beiden Standorten FC-An-schlüsse und die Server grif-fen auf im SAN befindliche SAS-Arrays als TSM-Cache zu. 1999 hatte die beiden Librarys eine Kapazität von 40 TB – heute von 4 PB .Der Computer- und  Medienservice der Humboldt-Univer- sität atmet den freien und toleranten Geist  des universitären Lebens, er bildet im Campus ein Stück Heimat. Das ist nicht selbstverständlich  für eine solche Einrichtung.Peter Zelt Wirtschaftswissenschaftliche Fakultät59sität werden ohne Beanspru-chung der Server und des LANs auf separaten Maschi-nen gesichert. Da im SAN der Zugriff von mehreren Sys-temen auf eine Speicher-Res-source möglich ist, können damit Cluster-Filesysteme zum Einsatz kommen, wie im Compute-Cluster und in den PC-Saal-Clustern.Das SAN ist der vorläufige Höhepunkt im Bestreben, Dateien einen sicheren Ort  zu bieten und zudem ein äußerst stabiler und wichtiger Dienst des CMS geworden. In den Folgejahren bis 2009 wurden neue Arrays mit SATA-Platten bestückt und die Netzwerk-Geschwindig-keit erhöhte sich auf 4 GBit/s. Mit den Startmitteln beim Einzug ins Grimm-Zentrum im Jahre 2009 konnte die Geschwindigkeit im Netzwerk auf 8 GBit/s erhöht werden, es wurde die Anzahl der Vir- tualisierungsserver-Cluster auf vier und der verfügbare Speicher auf 1 PB erhöht. Damit waren die Grundlagen gelegt, statt einiger Dutzend  nun hunderte von Servern zu unterstützen (derzeit 370).Es gibt eine ganze Reihe von  Möglichkeiten, die aus dem  Einsatz unseres SANs erwach- sen. So werden weiträumige Clusterungen von Servern ermöglicht. Im Windows-File-service, der seit 2003 die VINES-Server ersetzt, sind alle Cluster über die Stand-orte Adlershof und Mitte ge- spreizt. Beteiligt sind daran 31 Windows-Server mit 55 TB zugewiesenem Speicher für  31000 Nutzer. Außerdem er- lauben die Virtualisierungs- Server mit ihren Snapshot- Mechanismen Server- und LAN-free Backup. Alle zen- tralen Mail-Server der Univer-doppelt vorhanden, wie die Prinzip-Skizze aus einem älteren Vortrag zeigt.Jede fehlerhafte Komponente  kann in diesem System um- gangen werden. Alle redundan- ten Komponenten sind über insgesamt fünf Standorte ver- teilt. Die Virtualisierung spie- gelt alle Daten und hält die Kopien in verschiedenen Ge- bäuden. Das Gesamtsystem SAN ist so ausgelegt, dass alle Daten ohne Verlust auch dann zugreifbar bleiben, wenn ein zentraler Standort vollständig ausfällt (z. B. abbrennt).SAN-Struktur

https://edoc.hu-berlin.de/bitstream/18452/5647/1/54.pdf

Überblick zum Fileservice ab 1990

Abstract

Similar works

Full text

Available Versions

edoc Publication server

Dokumenten-Publikationsserver der Humboldt-Universität zu Berlin