Das DB-Cockpit weiß stets, welcher Switch den Verkehr blockieren kann Virtuelle Konfigurations-Datenbank sorgt für zügige Bahn-IT

Konfigurationsdatenbanken (CMDB) dienen dem Mapping von Geschäftsprozessen und IT-Infrastruktur. Die Deutsche Bahn setzt auf ein virtuelles CMDB-System mittels „Tivoli Netcool“. Der Effekt: Störungen im IT-Ablauf lassen sich frühzeitig erkennen und nach ihrer Bedeutung für den Prozess einordnen, eskalieren oder auch beheben. Servicetechniker müssen viel seltener vor Ort.

Anbieter zum Thema

IBM Deutschland GmbH

Vogel IT-Medien GmbH

Lenovo Global Technology Germany GmbH

Paessler AG

Rund 40 Mitarbeiter zählt eine Schicht des „Cockpit“, des Monitoring-Leitstands von DB Systems in Berlin und Frankfurt, der rund um die Uhr die IT-Systeme der Deutschen Bahn AG überwacht: 2.500 Server, 300 Datenbanken, rund 300 IT-gestützte Prozesse und 10.000 aktive Netzkomponenten wie Router, Switches und Firewalls.

Seit 2001 sind die IT-gestützten Prozesse, im Sprachgebrauch der Bahn, Verfahren, nach der IT Infrastructure Library (ITIL) implementiert und nach ISO 9000 zertifiziert. Damit hätte alles so schön sein können. „Doch das zentrale Systemmonitoring mittels „Zis“ von Leutek war Host-basiert, benötigte fette Clients und jeder Dienst musste modelliert werden. Mit anderen Worten: Das Tool war unflexibel und hatte sich überlebt,“ sagt Jeanette Fürst, Director Sales bei Openadvice IT Services.

Bei der Ausschreibung kegelte das IBM-Werkzeug „Tivoli Netcool“, das Ende 2005 mit dem Aufkauf von Micromuse zu Tivoli stieß, unter anderem Wettbewerbslösungen von BMC und Computer Associates aus dem Feld. „Entscheidend war“, erläutert Fürst, „dass das Produkt offene Schnittstellen besitzt und auf den vorhandenen Datensammlungen und Management-Systemen aufsetzen konnte.“ Der IT-Dienstleister hatte bereits viel Erfahrung im Umgang mit der Software und wurde von DB Systems ins Projekt geholt.

Eine Abstraktionsschicht braucht Schnittstellen

Konkret muss das System Tickets mit „HP Service Center“ bidirektional austauschen und Informationen aus Plattformen wie Sun MC, MOM (Microsoft) und Nagios (Open Source) übernehmen können. Die Daten aus den diversen Netzwerk- und System-Management-Tools – Events, Syslogs und Performance-Informationen – werden mit Hilfe von Agenten und Adapter zunächst gesammelt und grob miteinander abgeglichen, so dass etwa Dubletten herausgefiltert und diverse Informationen, identischen Störungen zugeordnet werden können (siehe: Abbildung 1) Das Werkzeug dafür trägt die Bezeichnung „Netcool Omnibus“.

Die normierten Events wandern dann in eine höhere Ebene. Auf dieser werden sie mit den erfassten Services abgeglichen, beziehungsweise diesen zugeordnet. Die Service-Informationen entstammen existenten Asset-Datenbanken beziehungsweise Service Level Agreements, Prozessbeschreibungen und Netztopologien. Das Service-Inventar wird in Baumstrukturen geordnet und derart gegliedert an eine Korrelations-Engine übergeben.

Was gehört zu wem?

Hier findet mit Hilfe des „Tivoli Business Systems Manager (TBSM, ursprünglich netcool RAD) das eigentliche Mapping statt. Die realen Netz-Events werden immer mit der letzten Service-Instanz verbunden. „Dadurch kann man sehen, welche Auswirkungen eine Störung auf den gesamten Prozess haben kann“, erläutert Fürst das technische Vorgehen. Wenn etwa in einem Datenbank-Cluster eine Komponente ausfällt, dürfte die Einhaltung des SLA weiterhin gewährleistet sein.

Mit den Informationen über Lokation und Zeitpunkt des Events erhalten die Cockpit-Mitarbeiter jeweils eine Art Ckeckliste, die dabei hilft, Fehler näher einzugrenzen, gegebenenfalls zu beheben oder an eine höhere Eskalationsstufe weiterzureichen. Der Korrelator reichert die Alarme mit diesen Informationen an.

Sowohl das Cockpit als auch die Prozessverantwortlichen haben über eine Browser-Oberfläche Zugriff auf die Event-Informationen. Das Monitoring-System entscheidet auf der Basis von Schwellenwerten, ob der Event zu einer Statusveränderung in der Ckockpit-Anzeige führt und welche Handlungsdirektive an den Mitarbeiter, der das System überwacht, gesendet wird. Während der Leitstand jedoch das gesamte Geschehen im Blick haben kann, sieht der Verfahrensverantwortliche nur seinen Prozess.

Das User-Interface

Das grafische Interface basiert auf „Netcool Webtop“. Eine Herausforderung war die Maßgabe, dass die Cockpit-Mitarbeiter mit spätestens drei Klicks alle relevanten Informationen auf dem Bildschirm haben, und zwar bis hin zu den exakten Details (siehe: Abbildung 2).

Die Entscheidung für Die Netcool-Tools fiel im Dezember 2005. Ein halbes Jahr später mussten fünf Referenz-Services implementiert sein. Im Mai dieses Jahres waren schließlich alle Dienste erfasst und die Mitarbeiter geschult.

Nach Aussagen von Fürst bestand die technische Schwierigkeit im richtigen Sizing. Immerhin arbeiten jetzt mit rund 65 concurrent User doppelt so viele Anwender mit dem System, wie ursprünglich vorgesehen. So ging zunächst einmal die Performance in den Keller.

Doch das sei nun kein Thema mehr. Derzeit kommen pro Tag bis zu 20.000 Events vor, die das Monitoring verarbeitet. Diese Events werden im Sekundentakt mit Informationen aus den verschiedenen Datenbanken angereichert.

Hindernisse und Erfolge

Vergessen ist auch das größte Problem, das darin bestand, „die internen Prozesse zum Laufen zu bringen“, wie Fürst sagt. Zum einen habe die virtuelle CMDB für mehr Transparenz gesorgt als manchem zu Beginn lieb war. Zum anderen habe es gedauert, bis jeder Prozessverantwortliche die Funktionen durchschaut und verstanden hatte, was sich damit anfangen lässt.

Zudem machte die Pflege der Asset-Datenbanken anfangs Sorgen; die Inhalte waren nicht immer aktuell. Doch dank des Mappings lässt sich schnell feststellen, wo Informationen über ein neues Device oder einen geänderten Service fehlen, so dass das Monitoring erzieherische Qualitäten entfaltete.

Heute ist es gar so, dass die DB-Systems-Verantwortlichen gar nicht genug bekommen von der Lösung. Fürst tüftelt schon an Möglichkeiten, das Facility-Management ähnlich aufzubauen. Hier geht es um Klima- und Brandschutzanlagen, Einbruchsicherung und Aufzüge. „Die Bahnhofsuhren sind schon in unserem Monitoring-System“, schmunzelt die Bahndienstleisterin.

(ID:2006312)