Bis zum September 1998 arbeitete die dvs mit zwei getrennten Rechenzentren an den Standorten Leipzig und Berlin. Weil der Eigentümer die Immobilie in der Hauptstadt zurückforderte, war ein Umzug unvermeidlich geworden. Die Berliner machten aus der Not eine Tugend: Die beiden Rechenzentren wurden am Standort Leipzig konsolidiert und in ein Hochverfügbarkeitskonzept mit einem ATM-Netz eingebunden.
Neben der Verlagerung des Berliner RZs mußte die dvs, auch als Verbandsrechenzentrum für die Sparkassen der neuen Bundesländer außer Berlin bezeichnet, noch drei weitere Umzüge schultern: Der Druckbetrieb wurde in den Berliner Stadtteil Marienfelde verlegt, die Abteilung MDR-Clearing zum Spittelmarkt und der SNA-Betrieb nach Leipzig.
Besonders kritisch bei diesem Vorhaben war die Anforderung, während des Umzugs einen unterbrechungsfreien Betrieb der Anwendungen zu gewährleisten. Ein Großteil der Geldinstitute in den Ländern Brandenburg, Mecklenburg-Vorpommern, Sachsen, Sachsen-Anhalt und Thüringen hängt am Netz der dvs. Jeder der dort installierten Geldautomaten und Terminals ist über Escon-Kanalverlängerungen mit den Mainframes in den Rechenzentren verbunden. Bei einem Netzausfall würden auch diese Endgeräte stillstehen.
Um die Verfügbarkeit der Netzinfrastruktur sicherzustellen, griff die dvs auf die Hilfe der Münchner Inrange Technologies zurück, die auch die zusätzlich benötigten Kanalverlängerungen lieferte. An jedem der neuen Standorte wurden jeweils zwei Systeme zur Verlängerung der Escon-Kanäle (VMC 8250) installiert (siehe Grafik). Die Projektverantwortlichen verknüpften die Standorte dergestalt, daß die Verbindung zwischen Berlin und Leipzig zu jedem Zeitpunkt über zwei voneinander unabhängige Leitungen im ATM-Backbone möglich war. Dieser hochverfügbaren Netzarchitektur steht auf der Rechnerseite ein Failover-Konzept für den Mainframe-Betrieb gegenüber. Die Hosts sichern sich dabei gegenseitig ab.
In der alten Konfiguration war dies wegen der zu großen Entfernung zwischen Berlin und Leipzig nicht möglich. Die maximale Distanz zwischen zwei Rechnern mit Failover-Mechanismen ist, bedingt durch die Escon-Kanaltechnik, auf 32 Kilometer begrenzt.
Im Rahmen des Umzugs baute die dvs das RZ in Leipzig komplett neu auf. Alle Anlagen sind aus Katastrophenschutzgründen unterirdisch installiert, berichtet Karsten Sauer, Leiter Systemservice. Der Bunker sei so konzipiert, daß er selbst den Absturz eines Jumbos überstehen würde: "Wenn oberirdisch alle Gebäude weg sind, können wir im Rechenzentrum trotzdem weiterarbeiten."
Bis zum Zeitpunkt des Umzugs liefen alle Anwendungen unverändert weiter, beschreibt Sauer die kritische Phase des Projekts. Am Tag X mußte unter anderem ein Datenbestand von zirka 3 TB, gespeichert auf 500 Long-Tape-Kassetten, nach Leipzig transportiert werden. "Das war schon eine kitzlige Angelegenheit", sagt Sauer. "Wir hätten auch einfach die Platten auf einen LKW laden können. Aber das wäre viel zu riskant gewesen." Auch die Alternative, die Daten synchron an den neuen Standort zu spiegeln, schied wegen der zu großen Entfernung aus.
Die Rechner in den Leipziger RZs arbeiten vollständig autark, also beispielsweise jeweils mit eigener Notstromversorgung. Am Standort Leipzig sind je zwei Mainframes über ein Parallel-Sysplex-Cluster verbunden. Es gibt auch Sysplex-übergreifende Funktionen. Die Daten auf den Hosts sind sowohl innerhalb eines RZs als auch über die Cluster-Grenzen hinweg über Kreuz gespiegelt. Das heißt, jeder Host kann im Notfall auf die Daten der anderen Rechner zugreifen.
Die dvs hat die zwei Sysplex-Verbünde nach funktionalen Gesichtspunkten getrennt. So laufen in einem Cluster vor allem Online-Applikationen, also transaktionsintensive Anwendungen im Zusammenhang mit dem Tagesgeschäft der angeschlossenen Geldinstitute. Im zweiten Rechnerverbund fahren die Leipziger weniger zeitkritische Anwendungen wie Batch-Jobs. "Wir brauchen die maximale Last am Tage", erläutert Sauer. Deshalb entlastet das zweite Cluster tagsüber auch die Rechner für die Transaktionsverarbeitung (zur RZ-Installation siehe Kasten).
Eine entscheidende Rolle in puncto Datensicherheit und -verfügbarkeit spielt das "K-Archiv" der dvs. Das K steht für Katastrophenvorsorge. In dem außerhalb Leipzigs angelegten Archiv lagern die Berliner dvs-Mitarbeiter den gesamten K-relevanten Datenbestand. Zweimal pro Jahr übe man das sogenannte K-Verfahren, so Sauer. Mit Hilfe eines eigenentwickelten Backup-Systems werden die kompletten Daten eines RZs wiederhergestellt (Restore) und mit den Daten des K-Archivs an einem anderen Standort zurückgespielt. Mit diesem Datenbestand werde das RZ neu aufgebaut und hochgefahren.
Im Leipziger Rechenzentrum sind unter anderem auch noch mehrere SP/2-Maschinen von IBM unter AIX installiert. Diese werden unter einem HACMP-Cluster als Hochverfügbarkeitsvariante für Anwendungen eingesetzt, die 24 Stunden am Tag laufen müssen (HACMP = High Availability Cluster Multiprocessing).
Im nächsten Jahr will die dvs im Leipziger RZ eine neue IT-Ebene mit Web-Servern unter dem Betriebssystem Sun Solaris aufbauen. Die Mainframes sollen dann die IMS- und DB2-Daten zu den Solaris-Servern schicken. Anwender in den Sparkassen würden per Browser auf die Daten zugreifen. Entsprechende Pilotprojekte liefen bereits.
Mit den angeschlossenen Sparkassen haben die RZ-Betreiber Service-Level-Agreements vereinbart, die jeweils ein bestimmtes Verfügbarkeitsniveau für die Anwendungen garantieren. Mit der Verfügbarkeit der Mainframe- Installation zeigt sich Sauer zufrieden. In der neuen Installation seien "verschwindend geringe ungeplante Ausfälle" zu verzeichnen. Geplante Standzeiten treten beispielsweise dann auf, wenn die Rechner aufgerüstet werden.
Von den hohen Verfügbarkeitswerten der Mainframes könnten die Zweigstellen leider nicht immer profitieren, kritisiert der Systemverantwortliche: "Die höchsten Ausfallraten haben wir im Netz." Die Verbindung zwischen den Standorten Leipzig und Berlin mit Druckzentren, K-Archiv und Clearing-Stellen sei zwar durch ein ausfallsicheres Backbone geschützt. Die Anbindung der Zweigstellen über territoriale Netzwerkrechner oder Router laufe dann über ein Netz der Telekom. Sauer: "Je nach Region gibt es da schon immer wieder Schwierigkeiten."
In der Verfügbarkeit der komplexen Netzstrukturen sieht Sauer denn auch den schwierigsten Teil der Konsolidierung. "Es dauerte länger als angenommen, bis alle Verbindungen standen und die Leitungen so funktionierten, wie sie bestellt waren." Die Vielzahl von Geräten für den Aufbau redundanter Netzstrukturen - Router, Switches, Hubs etc. - funktionierten oft nicht so, wie von den Verkäufern angegeben: "Die Theorie ist gut, aber die Praxis ist halt anders.
RZ-Installation
Am dvs-Standort Leipzig arbeiten zwei voneinander getrennte Rechenzentren mit jeweils zwei IBM-Mainframes der fünften Generation. Die Rechenkapazität liegt pro Host bei 1069 MIPS. Vor dem Umzug hatte die dvs auch noch ältere IBM-Großrechner und ein Comparex-System vom Typ M2000 im Einsatz. Doch selbst mit diesem eine Zeitlang leistungsstärksten Mainframe in Bipolar-Technik sei man an Kapazitätsgrenzen gestoßen, so Sauer. "Eigentlich haben wir jedes Jahr die Maschine gekauft, die am meisten MIPS gebracht hat."
Bei Großrechnerinvestitionen greife man stets auf die jeweils neueste Technik zurück, berichtet der Systemverantwortliche. Der Übergang auf IBMs jüngste Großrechnergeneration G6 sei geplant. Die Gründe für den laufenden Ausbau der Rechenleistung liegen in den steigenden Anforderungen an die Qualität und Quantität der von den angeschlossenen Sparkassen nachgefragten Daten. Bereits in der Vergangenheit sei der Bedarf an zentraler Rechenleistung jährlich um dreißig Prozent gestiegen. Faktoren wie die verstärkte Nutzung von Electronic-Banking-Funktionen würden mittelfristig zu einer Zunahme der zu verarbeitenden Transaktionen führen.
Die Plattenkapazität in den RZs beträgt zirka 8 TB. Die Berliner verwenden Disk-Arrays von IBM und Comparex. Gesicherte Daten liegen auf Bandrobotern von Storagetek. Für die laufende Datensicherung bedient sich die dvs der "ADSM"-Software von IBM. Diese wird auf allen Ebenen eingesetzt, das heißt nicht nur für die Großrechner-DV, sondern auch für Unix-Server und weitere dezentrale Systeme.
Die Datenhaltung organisiert der RZ-Betreiber überwiegend mit IMS-Datenbanken von IBM. In Verbindung mit neueren Applikationen kommt auch DB2 zum Einsatz. Jüngere Anwendungen sind in der Regel in C geschrieben; zudem laufen noch Cobol- und Assembler-Programme.