Datenhaltung und Storage

Als sensitiver Bereich ist die Haltung, Speicherung und Langzeitsicherung von Daten im Rahmen der umfangreicher werdenden Kooperation mit dem Deutschen Archäologischen Institut in letzter Zeit immer mehr in das Zentrum des Interesses gerückt. Die zunehmende Bedeutung von Storage und Langzeitsicherung für alle Teile der Gesellschaft hat zwar zu einer weitgreifenden Sensibilisierung geführt, die allerdings nicht immer von einer proportional adäquaten Wissenszunahme begleitet ist.

Nachfragen haben uns in letzter Zeit die Diskrepanz bisheriger Diskussionsversuche zu diesem Thema deutlich gemacht. Weil die in Rechenzentren wie dem Kölner gegebenen Ressourcen und Methoden außerhalb des Vorstellungsbereiches der meisten herkömmlichen Anwender liegen, wird deren eigener Erlebnishorizont schnell zum verfehlten Maßstab für alle Fragen von Massendatenspeicherung und Langzeitsicherheit: jedoch ersetzen berechtigte Zweifel an der Haltbarkeit von nur auf einem Medium gespeicherten Daten noch kein Reflektionsniveau. Um die Zahl solcher Diskussionen in Zukunft zu reduzieren und ihren Charakter möglichst auch zu modifizieren, haben wir uns entschlossen, in unsere an sich dem internen Bereich vorbehaltene Praxis auf diesem Gebiet wenigstens teilweise Einblick zu geben.

Wie auch in den Bereichen Digitalfotografie und Softwareentwicklung können sich das Forschungsarchiv (FA) und das Deutsche Archäologische Institut (DAI) glücklich schätzen, an den derzeit höchstmöglichen Standards zu partizipieren: in diesem Fall Dank der großzügigen Kooperationsbereitschaft des Leiters des RRZK, Prof. Dr. U. Lang, des Leiters der Abteilung Systeme Claus Kalle und des Systembetreuers Stephan Wonczak. Das Regionale Rechenzentrum der Universität zu Köln hat einen seiner ausgeprägten Schwerpunkte im Bereich Storage. Nur als ein Beispiel sei die im Jahre 2004 vorgenommene, weltweit erste Installation einer switchbasierten Storage-Virtualisierungs-Lösung angeführt, die im Rahmen eines Kooperationsabkommens von IBM unterstützt wird. Zu neueren Entwicklungen s. besonders das Kolloquium des Lehrstuhls von Prof. Dr. Ulrich Lang im WS 2005/06, insbesondere den Vortrag von Claus Kalle.

Der Storage-Schwerpunkt am RRZK sowie der wachsende Speicherbedarf des FA und des DAI ergeben somit eine Konstellation wechselseitiger Interessenlagen und gegenseitigen Nutzens. Wäre es für geisteswissenschaftliche Datenproduzenten außerhalb von Rechenzentren wie dem in Köln undenkbar, an massiven Hardware-Ressourcen im zweistelligen Millionenbereich zu partizipieren, so kann es für die Storage-Betreiber interessant sein, Testbeds für Storage-Workflows eines großen und konsistent strukturierten Datenbestandes zu haben, etwa in Hinsicht:

  1. auf zielgenaue Auffindbarkeit von derzeit ca. 150.000 von Objektordnern im Scanarchiv nach nur 3 Navigationsebenen und in relativ kleinen Unterverzeichnissen,
  2. auf weltweite, durch Usermanagement geregelte Zugänglichkeit von archivierten Daten im Bereich von bald 10 TB,
  3. auf langfristige Sicherheit. Die Funktionsweise der einzelnen Systeme soll und kann hier nicht eingehend beschrieben werden. Es soll lediglich die Art der Verwendung für die Datenhaltung des FA/DAI beschrieben werden.



Ebene 1: Internes Filesharing des FA
Generell ist zu betonen, daß das FA seine Inhouse-Datenhaltung stark verflacht hat und dort zunehmend nur noch Client-Rechner im Einsatz sind. Die erste Stufe der Datenhaltung betrifft diejenigen Daten, an denen konkret und zeitnah gearbeitet wird. Diese werden, wie allgemein üblich, in einer Fileserverstruktur gehostet. Um dem auch hier ständig wachsenden Platzbedarf Rechnung zu tragen, wurde dafür jüngst ein Apple XServe beschafft und in einem Fileserverschrank des Maschinensaals des RRZK eingebaut,

FSR1
(Abb. 1 von links: Prof. Dr. Reinhard Förtsch, Systembetreuer Dr. Stephan Wonczak, Arachne-Programmierer Florian Willems, M. A.; im Hintergrund ein Fileserver-Rack des RRZK mit (u. a.) AFS- und XServe-Fileserver des FA und des DAI)

um von dort aus auf Speicher des SAN zugreifen zu können. Der Firma Apple Computer danken wir besonders für eine nicht unerhebliche Förderung zum Erwerb der leistungsfähigsten Konfiguration dieses Modells:

XServe
(Abb.2: Der XServe und der Arachne-Programmierer Florian Willems, M. A.)



Ebene 2: Weltweites und plattformunabhängiges Filesharing via SAN/AFS
Die zweite Ebene der Datenhaltung betrifft Datenbereiche, die weitgehender konsolidiert sind und nur noch seltener bearbeitet werden. Dies betrifft etwa das Objektscanarchiv von Arachne oder eine Gruppe von DAI-Grabungen, die an einem Pilotpojekt zur modularisierten Grabungsverwaltung teilnehmen. Diese Datenarchive im derzeitigen Umfang von ca. 8 Terabyte werden ebenfalls auf dem SAN gehostet,

SAN1
(Abb. 3 von links: Prof. Dr. Reinhard Förtsch, Systembetreuer Dr. Stephan Wonczak, Arachne-Programmierer Florian Willems, M. A.; im Hintergrund das SAN mit (u. a.) den über AFS-verwalteten Daten des FA und des DAI)


SAN3
(Abb. 4: das SAN mit (u. a.) den über AFS-verwalteten Daten des FA und des DAI)


allerdings nicht verwaltet über einen XServe, sondern über einen AFS-Server des RRZK (s. o. Abb. 1). Das AFS (Andrew File System) ist ein verteiltes Dateisystem. Es bietet das eine Client-Server-Architektur für File Sharing, die ortsunabhängig, durch Usermanagement abgesichert, skalierbar und plattformunabhängig ist. Damit ist das AFS die ideale Anwendung für eine zukünftige, abteilungsübergreifende Datenhaltung im DAI und seinen einzelnen Auslandsinstituten und -abteilungen. Die Berliner Zentrale sowie die Institute in Istanbul und Rom nehmen derzeit an solchen Versuchen Teil.


Ebene 3: Langzeitdatensicherung via IBM Tivoli-System
Die dritte Ebene der Datenhaltung betrifft die Langzeitsicherung von Daten, die im Kölner RRZ über das Tivoli-System von IBM vorgenommen wird.

Tivoli1
(Abb. 5 von links: Prof. Dr. Reinhard Förtsch, der Storage-Systembetreuer Dr. Stephan Wonczak, Arachne-Programmierer Florian Willems, M. A.; im Hintergrund ein Tivoli-Server des RRZK mit Blick in den Roboterschrank auf die Magnetbandkassetten mit gesicherten Daten.)

Tivoli2
(Abb. 6: einer der zahlreichen Tivoli-Server des RRZK. Rechts vier Roboterschränke mit den Magnetbandkassetten, links etwas abgesetzt davon die Servereinheit)

Tivoli2
(Abb. 7: die Herzkammer der Datensicherung oder die Essenz des FA. Ein Blick in einen Roboterschrank auf Magnetbandkassetten mit gesicherten Daten.)

Grundsätzlich hat sich auf diesem nicht unumstrittenen Gebiet das FA der mit überzeugenden Gründen vertretenen Auffassung angeschlossen, daß überhaupt nur die digitalisierte Form eine Langzeitsicherung von Informationen ermöglicht - redundante, geräte- und ortsunabhängige Speicherung und regelmäßige Migration vorausgesetzt. Diese werden oft als illusorisch bezeichnet, sind im RRZK aber definitiv gegeben. Das an vielen industriellen und einigen universitären Standorten in Deutschland vorhandene Tivoli-System stellt, was die Langzeitsicherung digitaler Daten mittels Magnetbändern angeht, die derzeitige ultima ratio dar. Im RRZK werden zwei workflows angeboten und für die Daten des FA und des DAI genutzt: tägliche Datensicherung (Backup) und langfristige Zustandsarchivierungen (Archive). Sie werden jeweils auf verschiedenen, in Köln lokal weit getrennten Tivoli-Einheiten durchgeführt. Redundanz entsteht durch jeweils einen Spiegelserver, der demjenigen Backup- bzw. Archive-Server zugeordnet ist, mit dem ein User kommuniziert. Somit sind Daten im Extremfall viermal oder, durch Mehrfacharchivierung von Zustandsverläufen, sogar noch öfter langzeitgesichert. Selbst ein Abbrennen eines Serverraumes würde die Daten nicht zerstören. Durch ausgelagerte Bandkopien des Datenbestandes könnten sogar eine gleichzeitige Zerstörung aller Kölner Tivolieinheiten dem Datenbestand nichts anhaben, da er an anderen Tivolistandorten problemlos wieder eingespielt werden könnte.

Es sei an dieser Stelle der Vollständigkeit halber erwähnt, daß selbst das mit extrem hoher Datensicherheit (RAID Level 5) arbeitende SAN, auf dem die Daten des FA und des DAI liegen, seinerseits im Tivoli-System gesichert wird.

Reinhard Foertsch