Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

18.06.1999 - 

Dasa schickt Clients und Server ins Tivoli

Airbus-Bauherr verpaßt seiner DV einen Rahmen

Die Daimler-Chrysler Aerospace Airbus GmbH (Dasa), Hamburg, wollte eine einheitliche Management-Infrastruktur für ihre Client-Server-Installationen. Nach der Evaluation von 50 Produkten setzt das Unternehmen nun das Framework der IBM-Tochter Tivoli ein. Arno Laxy* berichtet, welche Funktionen der Rahmen abdeckt.

Die Anforderungen an die gesuchte Lösung standen fest: Sie sollte mehr als 100 Server und etwa 5000 Arbeitsplätze unterschiedlicher Herstellerprovenienz unter einen Hut bringen, verteilte Systeme zentral sichern sowie GB-große Datenbanken verwalten und reorganisieren können. Außerdem sollten Störungen zentral behoben werden und die verteilten Server in eine Produktionssteuerung etwa für den Massendruck eingebunden werden können.

Ohne Eingriff in den Betriebssystem-Kern

Darüber hinaus mußte das in Frage kommende Produkt mindestens 80 Prozent der geforderten Funktionen abdecken, eine hohe Skalierbarkeit aufweisen und alle Plattformen bedienen können, mit der Option auf eine Integration der MVS-Host-Welt. Das Airbus-Unternehmen wollte das Produkt implementieren, ohne Eingriffe in den Betriebssystem-Kern vornehmen zu müssen. Außerdem sollte die Server-Hardware weiterhin dem betriebseigenen Standard entsprechen und der Anbieter einen europaweiten Support gewährleisten.

Die Systemlandschaft des Flugzeugbauers bietet über 5000 PCs im Zusammenspiel mit 50 Novell-Netware-Servern, Version 4.1, die vor allem Druck- und Dateidienste verwalten. Sie stehen unter der Verantwortung der zentralen Informationsverarbeitung in Hamburg. Hinzu kommen rund 400 Workstations und 30 Applikations-Server unterschiedlicher Unix-Varianten. Darauf laufen etwa SAP-R/3-Anwendungen, aber auch Applikationen für die 3D-Konstruktion, für das Produktdaten-Management und für die zentrale Archivierung von Bauunterlagen sowie das Computer Aided Engineering (CAE). Weitere 20 Unix-Server sind für infrastrukturelle Aufgaben zuständig und werden vor allem für das Netzwerk- und System-Management sowie Firewall- und Web-Dienste benötigt.

Die Unix-Welt ist für einen wechselseitigen Zugriff mit Netware-PCs verbunden. Die Interaktion nutzt das Protokoll TCP/IP. Eigenentwickelte Anwendungen, etwa zur Produktionssteuerung und zur Erstellung von Fertigungsunterlagen, laufen auf MVS-Großrechnern. Die Host-Daten werden sowohl von den PCs als auch von den Unix-Rechnern angezapft.

Generalunternehmer bei der dreistufigen Einführung des Frameworks war die IBM. In der ersten Phase, die im Juli 1996 begann und im März 1997 endete, wurden Verantwortungsbereiche, Administratorrollen und die damit verbundenen Tätigkeiten festgelegt. Zudem konzentrierte sich das Projektteam auf das zentrale Rechenzentrum in Hamburg und band zunächst die R/3-, einige Infrastruktur-Server sowie Server für das Produktdaten-Management in den Administrationsrahmen ein.

Danach folgte die Implementierung von "Tivoli Sentry". Dieses Modul ist für das Überwachen von Parametern und die Definition von Schwellenwerten zuständig, um darüber Meldungen an die Konsole schicken zu können. Die Konsole überwacht die Logdateien, die Regeln für automatisierte Reaktionen auf Events und definiert die Korrelationen von Ereignissen.

Außerdem suchte das Projektteam in dieser Etappe Lösungen für die Einbindung der Oracle-Datenbanken; es entschied sich für "TS-Reorg" von Platinum, "SQL-Backtrack" von BMC und für "Tivoli Database Management".

In der zweiten Phase bis März 1998 wurden diese Werkzeuge sowie das Netz-Management-System "Polycenter" von DEC in das Framework eingebunden. Außerdem ging es darum, die Implementierung auf die übrigen Anwendungen auszudehnen sowie alle weiteren Unix-Server und -Workstations in das Framework einzubinden. Parallel dazu füllte sich die Inventardatenbank des Frameworks. Zugleich mit den ersten beiden Phasen bauten die Entwickler die Framework-Module für das Tivoli-Speicher-Management sowie für die Helpdesk-Software "Service Center" von Peregrine ein.

Derzeit steckt das Projektteam in der letzten Arbeitsphase. Das Framework nimmt nun die Gestalt eines plattformübergreifenden Anwendungs-Managements an. Externer Beistand ist kaum noch notwendig, nachdem in der ersten Phase noch zu 70 Prozent und in der zweiten Phase zu 30 Prozent auf externe Dienstleistungen zurückgegriffen werden mußte.

Parallel werden die Großrechner sowie die Netware-PCs mit dem Framework verbunden. Das heißt, daß die in Remote Access Control Facility (RACF) - ein MVS-Utility, das eine zentrale Authentifizierung ermöglicht - registrierten Host-Benutzer an die Tivoli-Administration übermittelt werden. Der Vorteil: Die Benutzer brauchen netzweit nur einmal erfaßt zu werden. Eine weitergehende Integration der Hosts ist nicht vorgesehen - auch deshalb, weil die Großrechner unter der Verantwortung der Daimler-Benz-Konzern-Schwester Debis stehen.

Von einer Integration der Netware-Clients hält Wolfgang Scheele, Leiter IV-Service PC-PC LAN in der Hamburger Zentrale, wenig: "Die Netware-Clients können mit Hilfe des Produkts Managewise effizienter verwaltet werden als mit dem Framework." Das Novell-Tool biete mächtigere System-Management-Funktionen. So binden die Projektmitarbeiter derzeit lediglich die Netware-Server an. Sie nutzen dabei das Compaq-Produkt "Inside Manager".

Der Leiter des IV-Betriebs Infrastruktur bei dem Airbus-Betrieb, Michael Umbreit, zieht kurz vor dem Projektabschluß ein positives Resümee, wenn es auch ein paar Abstriche gibt: "Das Projekt hat länger gedauert und ist kostspieliger ausgefallen als geplant." Es hing seiner Ansicht nach mit dem hohen Programmieraufwand zusammen. Das habe vieler Spezialisten bedurft, die sowohl die Erstellung von Scripts als auch von Regeln beherrschen mußten. Die Definition von Regeln ist aufwendig, weil dafür eine spezifische Sprache - ähnlich "Prolog" - notwendig ist. Es fehlten Metastrukturen, über die die Management-Anwendungen einfacher konzipiert und entwickelt hätten werden können.

Zweifel äußern die Dasa-Manager auch daran, daß sich mit dem Tivoli-Rahmen Einsparungen erzielen lassen. Das Framework sei vielmehr die logische Folge der zunehmend heterogenen Systemwelt. Damit die Informations- und Geschäftsprozesse nicht aus dem Ruder liefen, müßten sie zentral kontrolliert werden können.

*Arno Laxy ist freier Journalist in München.