Seit der Übernahme der innovativen Softwareschmiede Tivoli durch die IBM können die ungleichen Partner erste Resultate vorweisen, die sich nicht auf die Umbenennung der Tivoli-Lösung TME 3.0 in "TME 10" beschränken. So wurden inzwischen einige Funktionen - längst nicht alle - auf die IBM-Betriebssysteme OS/2 und OS/390 ausgedehnt.
Auf OS/2-PCs sind derzeit in eingeschränktem Maße TME-Applikationen anwendbar. Zu den System-Management-Features, die in die IBM-Desktop-Welt portiert wurden, zählen die Softwareverteilung und das Software-Management. Damit sind OS/2-Systeme jedoch weder vollwertige Management-Clients noch -Server. Erst wenn das TME-Framework, die Basis des Management-Systems, und weitere Applikationen OS/2-fähig gemacht wurden, dürfen sich die Ingenieure zufrieden zurücklehnen.
Für das Großrechner-Betriebssystem OS/390 schlagen die Tivoli- und IBM-Entwickler einen anderen Weg ein. "OS/390 ist eine Plattform, die die System-Manager längst gut im Griff haben. Daher gibt es zunächst mehr Handlungsbedarf, das Betriebssystem mit Unix und Windows NT zu verbinden", gibt Janos Wieland, Chefdesigner in der Stuttgarter IBM-Zentrale, die Richtung der Arbeiten vor. Dazu kündigte das Unternehmen den "Global Enterprise Manager" an, mit dem die Entwickler die zweite Phase des dreistufigen Planes zur Integration der zwei unterschiedlichen Netz- und System-Management-Umgebungen beginnen werden (siehe Kasten auf Seite 32).
Doch das Produkt wird erst ab Dezember ausgeliefert. Die Leistung der derzeit verfügbaren System-Management-Lösung TME 10 ist noch auf die Verteilung und das Management der Software in dezentralen Umgebungen zugeschnitten und umfaßt noch nicht die Verwaltungskomponenten der IBM-Welt. Auch steht noch ein Verfahren zur Distribution von Betriebssystemen aus, wie es im bisherigen "Distribution Manager" enthalten ist. "Im Zeitalter der Diskussionen um den Netzwerk-Computer ist das ein überlebenswichtiges Feature", wertet etwa Jürgen Suppan, Geschäftsführer der Comconsult Kommunikationstechnik GmbH, Aachen.
Außerdem vermißt der Fachmann noch die von IBMs Netz-Management-Produkt "Netview for AIX" bekannte Mapping-Funktionalität sowie alle Host-basierten Management-Möglichkeiten. "Im Moment fehlen noch wichtige Funktionen für ein integriertes Netzwerk- und System-Management", faßt der Aachener Spezialist sein Urteil zusammen.
Derzeit stellt sich TME 10 als Plattform dar, deren Framework Tivoli auf Basis des Corba-Standards entwickelte. Darauf setzen insgesamt vier Applikationsklassen auf (siehe Abbildung auf Seite 31). Viele dieser Anwendungen wurden von Drittanbietern geschrieben und angeboten, einige stammen aber auch von Tivoli.
Zur Klasse "Inbetriebnahme" zählen die TME-Entwickler die Inventarisierung und Verteilung der Software. Die Applikationskategorie "Betrieb und Verwaltung" umfaßt Lösungen für die Job-Zuordnung und den Advanced Distributed Storage Manager (ADSM), ein Werkzeug zur Datensicherung und -rettung. Allen gemeinsam ist die Verwendung einer einheitlichen grafischen Benutzeroberfläche und des Frameworks. Letzteres verwendet den Object Request Broker, eine Art Software-Bus, über den die Applikationen objektorientiert kommunizieren. Das Framework ist zugleich die Heimstatt der allgemeinen TME-Services, die alle Applikationen für die eigenen Aufgaben benötigen. Zu diesen Koordinationsdiensten zählen etwa das Scheduling, die Objektdatenbank für TME-interne Informationen sowie die User-Registrierung.
Mit all diesen Funktionen stellt das Framework eine Middleware dar, die zwischen Management-Applikationen und den zu verwaltenden Ressourcen aus Netzwerken, Internet oder Benutzerapplikationen liegt.
Architektonisch gliedert sich die TME-Struktur in drei Komponenten. Der TME-Server enthält die Verwaltungsapplikationen. Gewöhnlich läuft auf diesen Geräten ein Betriebssystem aus dem Unix-Umfeld oder Windows NT. Seit der Übernahme des System-Management-Spezialisten durch die IBM wurden zudem Entwicklungsarbeiten forciert, TME auch auf OS/2 und MVS zu portieren.
Da der Administrator nicht immer direkt am Unix-Rechner oder Mainframe sitzt, unterstützt das Tivoli-Konzept einen Management-Desktop. Hier werden die Verwaltungsaufgaben visualisiert und Applikationen, die auf dem Server residieren, zu Aktionen angestoßen. Dazu kann der Verwalter beispielsweise Windows-, Windows-95- und Motif-Umgebungen nutzen. Noch in der ersten Hälfte 1997 plant IBM, den Anwendern diese Möglichkeiten auch unter OS/2 zu Verfügung zu stellen. Die am Management-Desktop ausgelösten Befehle werden auf dem Server ausgeführt. TME hält für den "Managed Client" Schnittstellen zu den Betriebssystemen Unix, Windows NT, Netware und Windows 3.1 vor. Weil hier die Ausführung stattfindet, ist zur Verwaltung der Geräte das TME-Framework erforderlich.
"Die Architektur von Tivoli hat gegenüber der Konkurrenz einige Vorteile", zollt Suppan dem Konzept der IBM Anerkennung. "Sie könnte sich durchaus als Basis eignen, die angekündigten Vorhaben umzusetzen." Konkurrenzprodukte beruhten teilweise auf einer Strategie, die nicht die TME-Breite biete, andere Lösungen beständen aus vielen nicht integrierten Einzelkomponenten. Allerdings, so der Consultant, sei die Konkurrenz hellwach. Sie überarbeite ihre Produkte derzeit grundlegend. Erst die neuen Versionen der Tivoli-Wettbewerber könnten zeigen, wo TME wirklich steht.
Neben der großen Aufgabe, die zwei unterschiedlichen Konzepte des zentralistischen Systemview und des für verteilte Umgebungen konzipierten TME in eine Produktlinie zu überführen, haben Teilnehmer eines von IBM veranstalteten Seminars zum Thema TME den Verantwortlichen auch einige Fleißarbeiten auf den Weg gegeben. So wurde etwa kritisiert, daß TME kein schlüssiges Backup-Konzept vorweise.
Diese Aufgabe erfüllen zum Teil die TMR-Server (TMR = Tivoli Management Region). Diese Systeme verantworten den Betrieb von regional verteilten Management-Inseln, in denen sich bis zu 256 Managed Nodes verwalten lassen. Die TMR-Server haben den Überblick über die Objekte der jeweiligen Management-Regionen und tauschen mit anderen entfernten TME-Servern Objektressourcen aus. Nur durch diese nicht dynamische Kommunikation werden Redundanzen angelegt.
Diese Vorgehensweise führt unmittelbar zum nächsten Schwachpunkt des aktuellen Tivoli-Produktes. Der Datenaustausch von objektorientierten Informationen erfordert hohe Bandbreiten. Da die TMR-Server meistens geografisch verteilt sind, folglich über eine WAN-Strecke miteinander verbunden werden müssen, scheint das TME-Konzept die Realität des deutschen Weitverkehrsmarktes zu ignorieren.
Selbst wenn die Tivoli-Entwickler die objektorientierte Datenlast reduzieren könnten, wären sie vom Ziel einer vollständig verteilten System-Management-Lösung noch entfernt. Denn TME fehlt ein Regelwerk zur Abstimmung von Inkonsistenzen zwischen den verteilten TMR-Servern, die es wiederum in anderen System-Management-Lösungen gibt. Werden etwa verteilte Systemapplikationen von zwei entfernten und gleichberechtigten Administratoren geändert, existiert keine programmierte Logik, die beim Austausch und Abgleich der Objekte eigenständig Schlüsse aus Inkonsistenten zieht und selbsttätig die sinnvollere Änderung akzeptiert. Auftretende Inkonsistenten müssen immer manuell bearbeitet werden.
Alles im allem betrachten Fachleute wie Suppan die TME-Lösung als schlüssiges und tragfähiges Konzept. "Man muß Tivoli bescheinigen, daß ihre Vorhaben glaubwürdig sind", bewertet etwa Suppan das System-Management-Haus, das sich mit seinen Ankündigungen selbst in Zugzwang brachte: "Die Firma hat sich so weit aus dem Fenster gelehnt, daß sie Probleme bekäme, wenn die Ankündigungen nicht realisiert würden", kommentiert der Consultant abschließend..
Global Enterprise Manager (GEM)
Bei der MVS- oder OS/390-Integration mit TME haben Tivoli und IBM, deren Systemview-Entwickler seit der Übernahme zur neuen Unternehmenstochter gehören, zwei von drei Hürden genommen. Das Ergebnis der zweiten Phase wurde kürzlich als Produkt vorgestellt (siehe CW Nr. 43 vom 25. Oktober 1996, Seite 16: "Tivoli schlägt Brücke zwischen Systemview und TME 10"). Der Global Enterprise Manager (GEM) integriert erste Systemdienste wie etwa das Netzwerk-, Sicherheits- und Problem-Management. Diese Applikationen sind mit GEM-Hilfe sowohl in OS/390- als auch in Unix- und NT-Umgebungen einheitlich in TME darstellbar und nutzbar.
GEM besteht im wesentlichen aus dem Application Policy Manager (APC) und den Management Integration Services (MIS). Letztere beinhalten die Dienste für die Integration von Host- und dezentralen Umgebungen, wogegen der APC Regeln für die automatisierte Konfiguration, Verteilung und Nutzung sämtlicher Unternehmensapplikationen inklusive der Management-Anwendungen enthält.
Doch GEM wird erst im Laufe des Dezembers ausgeliefert, so daß es bis dato keine Erfahrungen damit gibt. "Man sollte zwischen dem Konzept und der Realität trennen", formuliert Jürgen Suppan, Geschäftsführer der Comconsult Kommunikationstechnik GmbH, Aachen, seine Vorsicht gegenüber dem ambitionierten Vorhaben, Systemview und die Tivoli-Lösung zusammenzuführen. "Zur Zeit ist die Integration noch nicht vollzogen."