"New kids in town." Eine Offerte, die Steuerung eines Systems sukzessive über die Netzschichten hinaus bis zur Anwendungsschicht auszudehnen, kommt aus der Ecke des klassischen Netzwerk-Managements und heißt Remote Monitoring (RMON). Spätestens seitdem im zweiten Quartal dieses Jahres der RMON-2-Standard verabschiedet wurde, treiben Hersteller wie Bay Networks, 3Com, Cabletron und Cisco Systems diesen Management-Ansatz voran.

"Zum ersten Mal können Ende-zu-Ende-Verbindungen über Router und Ebene-3-Switch-Systeme hinaus betrachtet werden", schwärmt Mathias Hein, Marketing-Manager bei Bay Networks in Wiesbaden. Ähnlich sieht auch Dieter Orth, Marketing-Manager von 3Com in München, diesen Ansatz: "Vor allem erlaubt es RMON-2, auf Anwendungsebene die Datenströme der einzelnen Applikationen transparent an die Konsole zu rücken und damit einen wesentlichen Beitrag zur effizienten Plazierung von Systemressourcen zu leisten."

Gleichwohl fordert das von den Herstellern hochgelobte RMON-2-System als Überwachungs-, Statistik- und vermeintlicher Analyseansatz seinen Tribut. In der Regel schicken die RMON-Agenten alle vor Ort an Hubs, Brücken, Routern und Switch-Systemen gesammelten Daten an die zentrale Konsole. Erst hier werden sie mittels RMON Management Informa- tion Base (MIB) ausgewertet.

"Dieser Ansatz kann schon beim Einsatz von RMON-1-Systemen mit einer Funktionalität nur bis auf die Ebene Medium Access Control zu Durchsatzproblemen auf den Verbindungen führen. Mit RMON-2-Agenten verschärft sich dieses Problem noch", bringt Volker Ackermann, IT-Manager bei Eutelis Consult in Ratingen, eine der maßgeblichen Schwächen des RMON2-Agenten-Dienstes auf den Punkt.

Der Anwender kann dieses Durchsatzproblem einigermaßen entschärfen, indem er vor Ort intelligente RMON-Agenten mit eigenem Prozessor einsetzt. Diese übernehmen eine Vorverarbeitung und Komprimierung der erfaßten Rohdaten. Doch spätestens mit RMON2 und der damit einhergehenden Verkehrslast auf vielen Netzebenen holt ihn das Durchsatzproblem wieder ein. Es bleibt nichts anderes übrig, als RMON-2-Agenten nur an wenigen ausgesuchten Netzwerkkomponenten zu plazieren und ansonsten offene Überwachungs- und Verwaltungsflanken in den lokalen Netzwerken ungedeckt zu lassen.

Lücken bestehen mit dem RMON-2-Tool darüber hinaus bei der Analyse von Systemen und Verbindungen. Denn obwohl die Hersteller und Anbieter ihre Software durchgehend auch als Analysewerkzeug anbieten, ist letztlich der Administrator gefordert, in langen Listen und Tabellen nach der vermeintlichen Fehlerursache zu suchen.

Mit Komponentensteuerung ist es nicht getan

Es bleibt viel Arbeit für teure Spezialisten, wie Heiko Rössel, Geschäftsführer von Röwaplan Ingenieurbüro für Daten- und Kommunikationsnetze im schwäbischen Abtsgmünd, hervorhebt: "Denn RMON-Systeme bieten kaum künstliche Intelligenz zur Interpretation der Daten, so daß sich die richtigen Schlußfolgerungen nicht ziehen lassen." Ohne langwierige Auswertungen kann der Administrator weder exakte Schwellenwerte definieren und komplexen Fehlern auf die Spur kommen noch für das Netzdesign wichtige Orientierungshilfen geben.

Mit der bloßen Steuerung der Netzkomponenten, etwa Hubs, Brücken, Routern und Switch-Systemen, ist es allein nicht getan. In dem Maße, wie im Netz Daten und Applikationen verteilt werden, rückt zusehends das Management des kompletten Informationssystems inklusive der Anwendungen, Datenbanken, Betriebssysteme und Middleware-Prozeduren in den Fokus eines umfassenden Überwachungs- und Verwaltungskonzepts.

Hersteller wie CA Computer Associates und IBM/Tivoli locken bereits offensiv mit ihren Frameworks "Unicenter TNG" beziehungsweise "Tivoli Management Framework" (TMF), um darunter "alles" abzuwickeln.

Das offensive Betreten dieses Marktes kommt nicht von ungefähr, wittern die Hersteller doch in diesem Bereich das große Geschäft. So sieht das Analystenhaus IDC diesen Markt, der 1995 weltweit ein Umsatzvolumen von 6,7 Milliarden Dollar erreichte, um jährlich 13,7 Prozent wachsen. Für die Jahrtausendwende liegen die Prognosen bei 12,7 Milliarden Dollar.

"Im Zuge der Verteilung von Daten und Anwendungen und der gleichzeitigen Integration der verschiedenen betrieblichen DV-Systeme steigt die Abhängigkeit der Unternehmen von der Funktionsfähigkeit dieser Systeme. Diese sind wiederum auf das Netz angewiesen." Für Matthias Frank, Produkt Marketing Manager bei CA Computer Associates in Darmstadt, ist das die Triebfeder für den Einsatz eines "All-in-one"-Werkzeugs.

CA Computer Associates stellt dazu mit Unicenter TNG nur die Basisfunktionen bereit. Dazu gehören die automatische Erkennung aller IP-Komponenten im Netz, die anschließend in einer Inventar-Datenbank eingestellt werden, sowie ein automatischer Virenscanner für alle hinzuzufügenden Objekte. Zur Basisfunktionalität gehören außerdem SNMP- und RMON-Agenten für allgemeine Administrationsaufgaben sowie Module zum Speicher-Management, zur Softwareverteilung und zur gesicherten Benutzerverwaltung. Für die eigentlichen Netzwerk- und Systemsteuerungsaufgaben unterhalb des Framework tragen hingegen CA-Partner mit ihren Produkten bei.

Anders sieht die Architektur des Tivoli Management Frameworks aus. Hier bildet eine weitgehend objektorientierte Struktur den Kern, ergänzt um eine zweite Schicht aus Grundfunktionalitäten, die allen Administrationsanwendungen gemeinsam sind. Zu diesen zählen Inventarisierung, Softwareverteilung, Benutzerverwaltung, Sicherheits-Management, Remote Control und Funktionen zur Überwachung von Systemen im Netz. "Diese Basisausstattung wird dann durch IBM/Tivoli und andere Hersteller um Produkte mit spezifischen Funktionalitäten erweitert", verweist Harald Schmidt, Tivoli-Channel-Manager bei IBM Deutschland, auf die mehrstufige Anwendungsarchitektur.

Eines ist beiden Management-Ansätzen gemeinsam: Sie leben - wenn auch auf verschiedenen Ebenen - von den spezifischen Netzwerk- und System-Management-Produkten, mit denen sich andere Hersteller in das jeweilige Rahmenwerk einklinken. CA nennt bereits mehr als 200, IBM sogar über 300 solcher Partner.

Diese breit angelegten Offensiven können jedoch kaum über den aktuellen Stand der Technik hinwegtäuschen. IT-Manager Ackermann von Eutelis Consult macht hier insbesondere Defizite im PC-Bereich aus: "Die Verteilung der Programme auf PCs ist in der Praxis mit einem immensen Nachbearbeitungsaufwand verbunden. Der Grund ist einfach: Kein Unternehmen setzt netzweit auf denselben Rechnertyp und schon gar nicht auf eine identische Software-Ausstattung."

Unternehmen bleibt in dieser Situation nichts anderes übrig, als zeitaufwendig Skripte für unterschiedliche Rechnerkonfigurationen zu entwickeln. Der Aufwand sei, so Ackermann, "meist höher als der Einspareffekt durch die Softwareverteilung".

Wolfgang Waibel, neben Rössel Geschäftsführer von Röwaplan, warnt die Unternehmen darüber hinaus davor, die Modellierung der Kommunikationsprozesse innerhalb des System-Managements zu unterschätzen. "Solche Kommunikationsprozesse sind so individuell wie das Unternehmen selbst und bedürfen einer zeit- und damit kostenaufwendigen Anpassung."

Hinzu käme noch die herstellerspezifische Prägung der einzelnen System-Management-Werkzeuge, deren Integration in das Framework häufig ebenfalls mit Zeit und Kosten verbunden ist. "Mit dem Aufwand muß das Unternehmen zudem permanent leben", so Waibel. "Denn die Systemimplementierung ist immer im Fluß, weil im Unternehmen stets neue Systeme und Verfahren hinzukommen."

Mit solchen Unannehmlichkeiten muß der Framework-Anwender schon aus marktstrategischen Gründen rechnen. Denn in der jetzigen Vermarktungsphase gehört nicht primär ihm die volle Aufmerksamkeit der Framework-Verfechter, sondern deren Ziel, in kurzer Zeit so viele Partner wie möglich unter ihrem Konzept zu vereinen und eine starke Marktpräsenz zu zeigen.

Schon kritisieren Partner beider Framework-Aspiranten eine zu laxe Lizenzierung, die der Anwender letztlich mit Integrationsproblemen und unzureichendem Support ausbaden muß. Er darf sich mit der kostspieligen Integration der Element-Manager für eine umfassende IT-Administration auseinandersetzen.

Besonders hart trifft den potentiellen Anwender dabei das Fehlen verläßlicher Standards. Stehen für das Netzwerk-Management zumindest SNMP, RMON und RMON2 als kleinste gemeinsame Nenner für eine allgemeine Verträglichkeit verschiedener Systeme zur Verfügung, sieht sich der Anwender im Bereich des System-Managements mit einer Vielfalt an potentiellen Standards beziehungsweise Pseudostandards konfrontiert.

Dazu gehören die Standardofferte Desktop Management Interface (DMI) der Desktop Management Task Force mit dem Ziel, einheitliche Schnittstellen zwischen PC-Hardware und Management-Anwendungen zu schaffen. Parallel arbeitet die Object Management Group mit den Definitionen der Common Object Broker Architecture (Corba) daran, für ein umfassendes System-Management einen Middleware-Standard zu setzen.

Microsoft ist eine weitere Kraft, die jeden Schritt in Richtung potentiellen Standard mit ihrer eigenen Auffassung eines System-Management konterkariert - sei es beim PC-Management mit dem System Management Server (SMS), bei der Middleware mit dem Distributed Component Object Model (DCOM) oder bei der (Netzwerk-) Betriebssystem-Zugangsschnittstelle mit Active X. Die Zielsetzung dabei: Bindung der Kunden an das eigene Produktportfolio.

Langsam auf dem Weg zur Objektorientierung

Das Fehlen verläßlicher Standards trifft selbst Framework-Anbieter wie CA und IBM/Tivoli. CA beispielsweise hat trotz der vehementen TNG-Unicenter-Offensive - derzeit wird das Framework zur schnellen Plazierung im Markt kostenlos an ausgesuchte Partner weitergereicht - den Weg in Richtung allgemeine Standards noch vor sich.

Bisher arbeitet diese Architektur im Kern noch über traditionelle SQL-Server. Damit sind heute bei der CA-Lösung aufgrund der SQL-Server-Struktur für die Korrelierung von Daten unterschiedlicher Management-Anwendungen unzureichende Voraussetzungen gegeben. In einem nächsten Schritt soll eine Umstellung auf Unix-Server in unterschiedlichen Derivaten im Zusammenspiel mit dem Datenbanksystem Open Ingres 2.0 erfolgen. Erst dann ist eine objektorientierte Middleware im Kern des Framework vorgesehen.

Bereits weiter fortgeschritten ist der Middleware-Ansatz Tivoli beziehungsweise IBM mit TMF. Schließlich kann man schon auf eine objektorientierte Mittelschicht gemäß Corba 1.1 in Object-Request-Broker-Technik verweisen. Lücken auf der mittleren Ebene bleiben aber auch hier: So wird die Inventarisierung als Basis für alle System-Management-Applikationen auch bei der IBM/Tivoli-Lösung immer noch über SQL-Server abgewickelt.

Und die Anwender? - Die meisten werden trotz bestehender Lücken im System-Management auf absehbare Zeit einigermaßen damit leben können. Denn in den Unternehmen erfolgt die Verteilung von Daten und Applikationen längst nicht mehr so schnell, wie viele Hersteller dies gerne sehen würden.

Ganz im Gegenteil: Nachdem übereilte Schritte in die Client-Server-Welt für viele Unternehmen überhöhte Netzbetriebskosten nach sich zogen und zudem bis heute das umfassende System-Management-Tool fehlt, geht der Trend zurück zum Zentrum. Hier wartet in vielen mittleren und großen Unternehmen der Mainframe als Basis für Daten und Applikationen. Dieser ist mittlerweile zum gleichberechtigten Partner im Unternehmensnetz avanciert.

Zudem eröffnen sich dem Anwender von Großrechnern gute Perspektiven, ihre Geräte schrittweise mit einer Zukunftstechnik zu verbinden: dem durch einfache Client-Server-Beziehungen überzeugenden Intranet. Angesichts dieser Entwicklung können viele Unternehmen bald erkennen, daß das ausgereiftere und zeitgemäßere Administrationswerkzeug, inklusive objektorientierter Middleware, nicht in der Client-Server-Welt, sondern wieder auf dem Mainframe zu finden ist.

*Hadi Stiel ist freier Journalist in Bad Camberg.