Die BVG ist gewissermaßen ein gebranntes Kind. Holger Seedorf, Abteilungsleiter im Zentralbereich Information und Kommunikation, weiß davon ein Lied zu singen: "Auch die BVG folgte Anfang der 90er Jahre den Entwicklungen des Client-Server-Zeitalters und so sah das dann auch aus : Dezentrale Verantwortlichkeiten, veraltete Hardware, Systemvielfalt, Schnittstellenprobleme zwischen der Datenverarbeitung, den Fachabteilungen und der Kommunikationstechnik: gab es alles in unserer heterogenen DV-Landschaft." Das Ergebnis kann man heute noch mit einigem Grauen auf Charts begutachten: Hunderte von Servern, die über ganz Berlin auf 50 Standorte verteilt waren.

Da sollte man lieber nicht fragen, wie diese Rechnerstruktur noch zu handhaben und zu warten war. Dieser vor acht, zehn Jahren IT-politisch korrekte C/S-Flickerlteppich bereitete den BVG-Verantwortlichen auch wegen Fragen der Datensicherheit und -verfügbarkeit einige schlaflose Nächte. Denn immerhin: Steht bei der BVG beispielsweise "Berta" still, das zentrale Betriebssteuerungs- und Einsatzplanungssystem und damit das Herzstück aller BVG-Anwendungen, geht auch bei U- und Tram-Bahnen oder Bussen nichts mehr reibungslos.

Fragen des Personalaufwands, Probleme bei Betrieb und Support und Wirtschaftlichkeitsaspekte führten den Leuten um Seedorf den dringenden Handlungsbedarf vor Augen: "Letztlich gab unser Vorstand den Anstoß, unsere IT komplett umzukrempeln, und zwar nicht nur organisatorisch, sondern auch physikalisch", sagt Seedorf, der bei der BVG schon seit vielen Jahren zur IT-Management-Riege zählt.

Die BVG entschied 1997 zunächst, die bis dahin in unterschiedlichen Organisationseinheiten angesiedelten Bereiche "Kommunikationstechnik" und "Datenverarbeitung" in einem Zentralbereich "Information und Kommunikation (IuK)" zusammenzufassen. Außerdem engagierte man für diese Geschäftseinheit mit Detlev Kruse einen IT-Direktor. Dieser berichtet seitdem direkt an den Vorstand. Eine Entscheidung, die ebenfalls mit Bedacht gefällt wurde, "der Vorstand wollte künftig den obersten IT-Verantwortlichen in seiner unmittelbaren Nähe wissen", sagt Seedorf. Denn auch diese Erkenntnis hatte Platz gegriffen: Nur mit einer wohl organisierten und kompetenten IT sind erfolgreiche Geschäftsmodelle denkbar.

Zunächst aber erlebte IT-Direktor Kruse 1998 einen heißen Sommer. Alle im Lauf der Client-Server-Jahre entstandenen dezentralen DV-Bereiche und Fürstentümer mussten überzeugt werden, dass die IT-Zeichen bei der BVG ab sofort auf Zentralisierung standen: "Das ging nicht ohne Kämpfe und Überzeugungsarbeit, hatten sich doch viele Fachabteilungen Pfründe aufgebaut, die ihnen nun weggenommen wurden", erinnert sich Jörg Gruda.

Nimm zwei: Ausfallsicherheit "leicht" gemacht

Nach den unausweichlichen zwischenmenschlichen Turbulenzen, die eine Einschmelzung von 50 Server-Standorten mit deren zunehmend eigenverantwortlich aufspielenden Fachabteilungen auf ein doppelt ausgelegtes Rechenzentrum mit sich bringt, entwarf die BVG im Herbst 1998 das Grobkonzept des Projekts "Serverkonsolidierung und Datenverfügbarkeit im Rechenzentrum (Servekon)" mit dem Projektleiter Gruda. Was unprätentiös daherkommt, warf in Wahrheit die komplette IT der Verkehrsbetriebe über den Haufen. Wie ein Masernausschlag verteilten sich bis dato 90 NT- und 60 AIX-Server, deren Innenleben zu allem Überfluss auch noch völlig heterogen und damit oft inkompatibel war, über die mit Abstand flächengrößte deutsche Großstadt.

Was es braucht an Daten, um den öffentlichen Verkehr in der Bundeshauptstadt am Leben zu erhalten, rauscht heute auf den Leitungen zwischen zwei identisch aufgebauten Rechenzentren. 25 standardisierte Server, jeweils als Cluster mit Primär- und Sekundärrechner konzipiert, korrespondieren gespiegelt mit ihren 25 Pendants im 150 Meter Luftlinie entfernten zweiten RZ. Je nach den Anwendungen arbeiten sie unter IBM-AIX, HP-UX oder Windows NT. "Berta" etwa läuft heute auf IBM-Parallelrechnern der RS/6000-SP-Linie.

Damit die remote gespiegelten Datenbestände, etwa im Falle eines Totalausfalles nach dem Brand in einem Rechenzentrum, trotzdem noch von den Anwendungs-Servern genutzt werden können, achtete die BVG auf eine verteilte Aufstellung der Server eben als Cluster. Die NT-Systeme sind über Microsofts Software "MS Cluster Service" gekoppelt, die AIX-Maschinen über IBMs "HACMP"-Werkzeug. Nur so ließ sich die geforderte Verfügbarkeit der einzelnen Anwendungssysteme erfüllen.

Nur wer SANiert, kann sich auch sicher fühlen

Eine weitere wichtige Innovationsleistung des BVG-Projektes bestand in der Zusammenführung aller Unternehmensdaten des Berliner Verkehrsbetriebs auf einem zentralen Massenspeichersystem. Netto rund 3 TB Informationen zu konsolidieren war nur möglich, sagt Seedorf, weil man sich im Haus für den Einsatz eines hochleistungsfähigen Storage Area Networks (SAN) entschied. Realisiert mit einer Fibre-Channel-Switch-Technik, erlaubt es den Anschluss verschiedener Server-Plattformen (HP-UX, IBM AIX und Windows NT 4.0) an den zentralen Datensilo.

Um die Funktionalität des SAN nutzen zu können, baute ein Team um Ralph Gurbicz, dem für dieses Teilprojekt Verantwortlichen, ein unabhängiges Netz auf. Dieses ist ausschließlich für die Speicherung aller Daten und deren nochmalige Sicherung (Backup) ausgelegt und besitzt somit gegenüber der herkömmlichen Datensicherung einen gravierenden Vorteil: Speichern Netz-Administratoren die Unternehmensdaten über das LAN ab, müssen sie wegen des ausufernden Datenverkehrs mit großen Einbußen beim Durchsatz rechnen. Die von der BVG realisierte Speichertopologie löst diesen Engpass auf.

Früher dockte an jeden der 150 Server ein eigener SCSI-Raid-Speicher mit einem zusätzlichen Backup-System an - oder die Server wurden über das Netz gesichert. "Das führte dazu, dass wir unser Netz manchmal dicht gemacht haben", sagt Gruda, ein Vorgehen, das bei einem 24-Stunden-Betrieb wie bei der BVG "nicht gerade sehr prickelnd ist."

Als zentralen Massenspeicher nutzen die Berliner zwei "HP-Surestore-XP256"-Systeme. EMC war als Lieferant auch im Gespräch, insbesondere, weil die BVG bereits zwei Systeme des Massenspeicherherstellers betreibt: "Aber die Konditionen waren nicht so attraktiv. Heute bereiten wir die Integration der EMC-Speicher in den SAN vor," sagt Seedorf. Eine kleine, aber durchaus brisante Information lässt Gruda eher beiläufig fallen: Die gesamte Umstellung habe man immer live und mit produktiven Daten - Gruda-O-Ton: "Quasi am offenen Herzen" - vorgenommen. So auch etwa die Umstellung von der SCSI- auf die SAN-Verkabelung. Eingedenk der Tatsache, dass die BVG zuallererst einmal dafür verantwortlich ist, Tag für Tag Millionen von Menschen durch Berlin zu karriolen und die Männer und Frauen um IT-Direktor Kruse und seinen obersten Projektverantwortlichen Seedorf dies IT-technisch unterstützen müssen, glaubt man Gruda gern, wenn er sagt, das sei immer sehr spannend gewesen. Heute tut er sich da etwas leichter, wenn er sich entspannt zurücklehnt: "Wir haben viel gewagt, aber dann auch viel gewonnen."

Das SAN als Basis aller Server-Systeme

Daten, die für die BVG große Relevanz besitzen und die ständig verfügbar sein müssen, sichern die Hauptstädter nicht nur intern (also im betreffenden Rechenzentrum) über Raid-5-Mechanismen. Vielmehr spiegeln sie diese Daten auch noch mit der "Continuous-Access"-Software im jeweils anderen RZ. Fällt ein Massenspeicher aus, kann so trotzdem über das Ausfallsystem auf die Unternehmensdaten zugegriffen werden.

Einmal abgesehen von der Anbindung der verschiedenen Server mit ihren Platten-Pools an das Storage Area Network, nutzt die BVG das SAN auch für die zentrale Datenarchivierung (Backup). Dazu wurde in jedem der beiden Rechenzentren eine Digital-Linear-Tape-(DLT-)Bibliothek aufgebaut. Die DLT-Laufwerke der Libraries lassen sich von den zu sichernden Servern direkt über das SAN ansprechen (so genanntes Library Sharing). Auch durch diese Konstruktion reduziert sich die Netzbelastung - anders als beim klassischen Ansatz, bei dem die Datensicherung eben über das LAN läuft. Letztere Option nutzt die BVG aus wirtschaftlichen Gründen allerdings nur für die Server, bei denen das zu sichernde Datenvolumen relativ gering ist.

Das aufgebaute SAN mit seiner integrierten Datensicherungsarchitektur bildet die Basis für die angeschlossenen Server-Systeme. Um die Komplexität überschaubar zu halten, so Seedorf, koppelte die BVG zunächst folgende Rechner mit ihren Anwendungen an das Speichersystem an:

-Das Berta-System läuft auf IBMs RS/6000-SP-Maschinen unter AIX 4.3.2.

-Sowohl die Druck- und Dateiservices als auch die Kommunikationanwendung "Exchange" und die Oracle-Datenbank werden auf HPs Intel-basierten "Netservern" unter NT 4.0 bedient.

-SAP R/3 und das Archivierungssystem "David" kommen auf HP-9000-Maschinen unter HPs UX-Unix-Derivat zum Einsatz.

Die Kunst, mit einer Klappe viel zu erschlagen

Mit der drastischen Re-Zentralisierung der gesamten IT-Struktur schlugen die Mannen um IT-Direktor Kruse und IuK-Abteilungsleiter Seedorf gleich mehrere Fliegen mit einer Klappe: Nicht nur, dass die dezentralen DV-Bereiche in einem einzigen IT-Zentralbereich integriert beziehungsweise aufgelöst wurden. Sie reduzierten auch die Anzahl der Server, deren Ausstattung bei der Gelegenheit standardisiert wurde. Durch die Auslegung der IT-Topologie in zwei ausfallsicher gestaltete Rechenzentren ist die BVG-IT nunmehr jahrein, jahraus ständig verfügbar. Die physikalische Zusammenführung der Gesamt-IT erleichtert zudem fast selbstredend deren System-Management.

Im Zuge des Konsolidierungsvorhabens musste die BVG zwei weitere Teilprojekte erledigen: Die gesamte "Microsoft-Exchange"-Infrastruktur (MS Exchange Server 5.5 Enterprise Edition inklusive Service Pack 2) lagerte Seedorfs Mannschaft auf vier NT-Cluster-Server (je zwei in einem Rechenzentrum) und ein Testsystem um. Auch bei diesem Teilprojekt galt es, Begehrlichkeiten zu bedienen: So soll das neue Unternehmenskommunikationssystem sicherstellen, dass bei Softwarefehlern das System innerhalb von zwei Stunden wieder verfügbar ist, bei Hardwareproblemen räumt man den Wartungstrupps doppelt so viel Zeit ein. Außerdem galt es, die Exchange-Infrastruktur in das unternehmensweite, zentrale Backup-System zu integrieren.

Anwenderdateien? Kein kleines Problem!

Eine ziemlich unterschätzte Herausforderung stellte die auf den ersten Blick marginal anmutende Umstellung der Datei- und Druckservices für die vernetzten Arbeitsplätze dar. 16 Windows-NT-Server wurden als Basissysteme mittels "MS Cluster Services" jeweils paarweise zu acht Cluster-Systemen angeordnet.

Jeder Dienst hat so im Cluster einen primären und einen so genannten Failover-Knoten. Um die Hardwareplattformen optimal zu nutzen, installierten die Berliner die Services so, dass kein Cluster-Knoten dediziert nur für die Ausfallsicherheit eines Dienstes bereitsteht. Vielmehr sind auf jedem Knoten auch primäre Dienste installiert. Die Datei- und Druckdienste wurden auf insgesamt sechs Cluster verteilt, auf zwei Clustern liegen die Home-Verzeichnisse, zwei bearbeiten die Ablageverzeichnisse, und zwei bedienen die Druckerschlangen.

Wer nun glaubt, die Installation und Einrichtung dieser 16 NT-Server in den zwei Rechenzentren sei das Kernproblem gewesen, der täuscht sich: "Eine wesentliche Aufgabe, deren Umfang wir unterschätzt haben, da hierbei auch das Berechtigungskonzept angefasst werden musste, ist, Millionen von Word- und Excel-Dateien der rund 4500 betroffenen BVG-Anwender auf die zentralen SAN-Speicher zu schaufeln", sagt Gruda. Eine "Höllenaufgabe", deretwegen sich die Ablösung der dezentralen NT-Server verzögert hat.

jbmeyer@computerwoche.de

Das Unternehmen

-Die Berliner Verkehrsbetriebe befördern mit U-Bahnen, Straßenbahnen und Bussen 787 Millionen Fahrgäste.

-Der Umsatz belief sich im Jahr 1999 auf 989 Millionen Mark.

-Insgesamt beschäftigt die BVG 14400 Mitarbeiter.

- 25 IT-Mitarbeiter stellte die BVG für das Projekt ab - unterstützt von 50 externen Experten.

- GE Compunet zeichnete als Generalunternehmen für das Projekt verantwortlich, Telemation baute das Netzwerk auf.

Chronik der Ereignisse

- Das Vorprojekt und die Grobkonzeption zur Server-Konsolidierung inklusive einer Wirtschaftlichkeitsbetrachtung dauerte von September bis Dezember 1998.

- Die BVG-interne Entscheidung zur Umsetzung des Projektes fiel im Januar 1999. Die Pflichtenhefte erstellten die Verantwortlichen zwischen Januar und April 1999.

- Erste Qualifizierungs- und Ausschreibungsverfahren liefen zwischen Mai bis August 1999.

- Der Ausbau des Notfall/Ausfall-Rechen-zentrums ging zwischen Mai bis September 1999 vonstatten.

- Das Netzwerk wurde zwischen November 1999 und April 2000 ausgebaut.

- Die Umsetzung der Server-Infrastrukturmaßnahmen dauerte von Oktober 1999 bis zum Juni 2000.

- Die fließende Betriebsüberführung nahm die BVG dann zwischen April und September 2000 vor.

Was lernte die BVG?

Wer Neues wagt, muss immer auch Lehrgeld zahlen, macht seine Erfahrungen. IT-Mann Seedorf und seine Mitarbeiter Gruda, Blankenstein und Gurbicz haben einige aus ihrem Projekt zusammengefasst:

- Der Projektleiter benötigt kurze Wege zu Vorgesetzten und schnelle Entscheidungen.

- Einige Projektmitarbeiter sollten für das Projekt zu 100 Prozent freigestellt werden.

- Cluster erfordern sehr viel größeren Aufwand bei der Implementierung und lange Testphasen für die Integration in zentrale Verfahren (beispielsweise SAN, Backup, LAN) als einzelne Server.

- Fachverfahren ließen sich während des laufenden Betriebs nicht in jedem Fall ohne Störungen migrieren, da Fallback-Strategien nicht immer wirtschaftlich sinnvoll vollzogen werden konnten.

- Katastrophenfall-Tests sind bei Projektimplementierungen, die während des laufenden Betriebs vorgenommen werden, sehr schwierig zu realisieren (etwa der Ausfall eines gespiegelten Speichersystems im SAN-Verbund oder gar eines kompletten RZ).

- Abhängigkeiten zwischen den Teilprojekten erschweren Tests und den Probebetrieb.

- Die technische Innovation überholt das Projekt selbst bei Laufzeiten von nur sechs Monaten (so wurde der Fiberchannel-Fabric zweimal getauscht).

- Unbedingt erforderlich ist ein effektives Change-Management.

Anwender-des-Jahres-Wettbewerb

Dass die "Höllenaufgabe" der Server-Konsolidierung mit Bravour erledigt wurde, spiegelt sich in der Bewertung des Projekts durch zwei Juroren wider. Die BVG hatte sich nämlich im vergangenen Jahr an dem Wettbewerb "Anwender des Jahres" beteiligt, den die COMPUTERWOCHE gemeinsam mit den Unternehmensberatern von Gartner veranstaltet und der auch dieses Jahr wieder stattfindet. Gerhard Adler, Geschäftsführer der Diebold Deutschland GmbH, sieht besonders die Zukunftssicherheit der gewählten Lösung in herausragender Weise gewährleistet. Die Unternehmensberater von Gartner bewerteten die Innovationsfähigkeit des Projekts sowohl was seine technische Ausprägung als auch, was die Auswirkungen auf das Geschäftsmodell betrifft, mit den höchsten vergebenen Noten. Genauso überzeugend sei das Projekt-Management einzuschätzen.