Schlußbemerkung und Ausblick

Diese abschließende Kapitel faßt die Ausgangssituation und die Aktivitäten, die zum Entwurf und zur Implementierung der Managementszenarien erforderlich waren, kurz zusammen und beschreibt, in welcher Hinsicht Möglichkeiten der Erweiterung der in der vorliegenden Arbeit behandelten Thematik bestehen.

Zu Beginn wurde analysiert, weshalb allgemein ein Management verteilter Anwendungen notwendig ist; im Brennpunkt der Untersuchungen stand fortan die verteilte Kommunikationsanwendung NWP.
Verschiedene Ansätze für das Management verteilter Anwendungen wurden anschließend beschrieben und nach Kriterien der praktischen Anwendbarkeit bei der Erstellung eines Managementkonzeptes bewertet.

Da das Aufstellen eines tragfähigen Managementkonzeptes Detailkenntnisse des zu managenden Systems erfordert, wurden in Kapitel 4 die technischen Eigenschaften des NetzWerk-Programms eingehend geschildert sowie die derzeit verfügbaren Möglichkeiten, NWP-Managementinformationen zu akquirieren.

Für die Entwicklung der Managementszenarien und die Akzeptanz der aufzustellenden Managementlösung war es von grundlegender Bedeutung, sich Klarheit darüber zu verschaffen, welche Probleme beim Betrieb von NWP auftreten und welche Anforderungen die davon hauptsächlich betroffenen Benutzergruppen an ein NWP-Management richten.
In mehrstündigen Diskussionen und Gesprächen mit dem Personal des Netzwerkleitstands sowie der NWP-Gruppe konnten wertvolle Informationen gewonnen werden, die prägenden Einfluß auf den Entwurf der Managementszenarien hatten.

Schließlich stand die technische Realisierung der Szenarien d.h. deren prototypische Implementierung auf der kommerziellen Netzmanagementplattform SPECTRUM im Blickpunkt, die aufgrund des hohen Maßes an Komplexität den zeitlich bei weitem größten Anteil beanspruchte.
Als Ausgangsbasis für die Implementierung wurden das Inference Handler Application Programming Interface, da es als einziges Toolkit die für die vorliegende Arbeit dringend benötigte Funktionalität bot, und das Managementmodul MaestroVision gewählt, bei deren Benutzung jedoch ungeahnte Schwierigkeiten auftraten:

• Von MaestroVision lag bis zuletzt lediglich eine Demonstrations-Version vor, der, bis auf eine Produktankündigung im Umfang weniger Seiten, keinerlei Dokumentation beilag. Obgleich unmittelbar nach dem Eintreffen der Demo-Version Bemühungen eingeleitet wurden, eine vollständige Lizenz (und damit adäquate Dokumentations- und Supportmöglichkeiten) zu erhalten, gelang dies binnen 14 Wochen nicht.

  Die Folge war, daß sämtliche Informationen bezüglich MaestroVision mühsam in langwierigen Terminalsitzungen herausgefunden werden mußten; letztendlich war jedoch der Modellierung von NWP in SPECTRUM Erfolg beschieden.

• Die Probleme mit der SPECTRUM Inference Handler API lagen in einem anderen Bereich:
  Aufgrund der Tatsache, daß es sich bei der Inference Handler API um ein neues Produkt handelte, für das bis zum Beginn dieser Arbeit noch keine Erfahrungen vorlagen, geriet die vorliegende Arbeit unter anderem zu einer Nagelprobe der Stabilität der Inference Handler API.

  Das Ergebnis war unbefriedigend, da Probleme beim Link-Vorgang des SpectroSERVERs auftraten und es trotz intensiven Nachrichtenaustauschs während 12 Wochen mit Cabletron England nicht gelang, den Fehler zu beheben.
  Als Fehlerursache wurden uns mutmaßliche Inkonsistenzen zwischen den Compilerversionen genannt, da der (von Cabletron) zum Erstellen der C++-Libraries verwendete Compiler eine andere Version aufwies als derjenige, der uns vorlag (und der laut Cabletron zur Entwicklung verwendet werden sollte).
  Die Marktreife einer neuen SPECTRUM-Version, die für Februar 1993 angekündigt war und bei der der erwähnte Fehler (angeblich) nicht mehr aufgetreten wäre, wurde inzwischen auf August 1993 verschoben (zu spät, um für die vorliegende Arbeit noch relevant zu sein).

  Die Support- und Versionenproblematik--eine unendliche Geschichte...
  Das Münchner Netzmanagement Team hat die Notwendigkeit eines Kooperationsabkommens mit Cabletron erkannt und entsprechende Schritte hierzu eingeleitet, um in Zukunft sicherstellen zu können, daß aufgetretene Fehler in einer akzeptablen Zeitspanne behoben werden.

Wegen der obengenannten Gründe konnten die implementierten Szenarien daher nicht in der Praxis erprobt werden. Nichtsdestoweniger lassen die erarbeiteten Lösungen eine Beurteilung der Möglichkeiten eines NWP-Managements zu.

Obwohl sich sie entwickelten Managementszenarien primär auf UNIX-Systeme beziehen, lassen sie sich größtenteils auch auf DEC- oder SNA-Systeme, die als NWP-Knoten fungieren, übertragen.
Anpassungen müssen insbesondere an Großrechner innerhalb der SNA-Welt erfolgen, da bereits deren Hardwarevoraussetzungen von denen herkömmlicher Workstations differieren.
In diesem Zusammenhang leistet das Managementmodul BlueVision gute Dienste, da es SPECTRUM um die NetView/6000-Funktionalität erweitert und somit erlaubt, SNA Hard- und Softwarekomponenten zu managen.
Für das NWP-Management essentielle Modelltypen wie ,,Application`` oder ,,Process`` sind dadurch verfügbar.

Gelingt es, ein Managementmodul für die DECnet-Welt mit ähnlich gelagerter Funktionalität zu entwickeln, steht einer umfassenden, integrierten Managementlösung für das NetzWerk-Programm nichts mehr im Wege, da die drei großen Systemwelten UNIX, SNA und DEC in eine einheitliche Managementplattform eingebettet sind.

Eine weitere wichtige Frage, die in Abschnitt 4.3 angesprochen wurde, bezieht sich auf die Anbindung von relationalen Datenbanksystemen an SPECTRUM.
Im konkreten Fall NWP bedeutet dies die Integration der (bis jetzt) statischen Netzdatenbank ISYKON. Gelingt es, die Integration unter Beachtung der Konsistenz- und Integritätsbedingungen zu vollziehen d.h. ist es möglich, auf die SPECTRUM-Daten mit Hilfe der Abfragesprache SQL und auf ISYKON-Daten mit dem Model Type Editor zuzugreifen, ist die Erweiterung von ISYKON um dynamische Daten nur noch eine Frage der Zeit.
Im Endausbau wäre ISYKON demnach eine dynamische, NWP-spezifische Wissensbasis, die neben laufend aktualisierten Hardwarebeschreibungen auch momentan ausgefallene Knoten und zum Abfragezeitpunkt gültige Routen beinhaltet. Dies impliziert dynamisches Routing.

Mit der Integration von immer zahlreicheren Komponenten, Systemen und Anwendungen steigt jedoch auch die Anzahl der anfallenden Daten. Hierzu sind zwei Anmerkungen zu machen:

1.

Die Netzlast, verursacht durch das Netzmanagement, erhöht sich durch die Verfügbarkeit immer größerer Datenmengen, selbst bei Verwendung intelligenter Agenten.
Es stellt sich zwangsläufig die Frage, ob es Sinn macht, daß alle Systeme von einer zentralen Managementstation verwaltet werden, oder ob es nicht besser ist, eine hierarchische Managementarchitektur einzusetzen; auf SPECTRUM angewandt, hieße das, die Virtual Network Machine verteilt zu betreiben d.h. an ausgezeichneten Punkten des Netzes bereits frühzeitig unterschwellige Alarme zu verarbeiten, bevor diese zu ernsthaften Problemen für den Betrieb des gesamten Netzes werden.
Tatsächlich sind bereits heute intelligente Sternkoppler, sogenannte Multi Media Access Center, erhältlich, die eine auf einem Einschub untergebrachte vollwertige Workstation aufnehmen können. Es ist durchaus vorstellbar, daß eine auf das jeweils zu überwachende Netzsegment zugeschnittene VNM auf dem Workstation-Board innerhalb eines Hubs Managementinformation vorverarbeitet.

2.

Die derzeit unter SPECTRUM verfügbaren Sichten reichen im Falle großer Datenvolumina mit Sicherheit nicht aus, um alle benötigten Attribute darzustellen:
Momentan kann man sich damit behelfen, einzelne besonders wichtige Attribute in eine Sicht zu integrieren; dies geht jedoch nur, solange nur eine beschränkte Anzahl von Netzdaten verfügbar ist.
Im Zuge weitergehender Integrationsbemühungen gelangt man jedoch bald an eine kritische Grenze, wobei die Daten aufgrund ihrer Fülle nicht mehr in übersichtlicher Form darstellbar sind.

Hier könnte eine Einteilung der Views anhand der Systematik des ISO-OSI-Referenzmodells erfolgversprechend sein.
Eine Realisierung der OSI-Views für einen NWP-Knoten würde gestatten, schichtenspezifische Analysen des Kommunikationssystems zu ermöglichen.
Der konkrete Fall eines ,,abgestürzten`` NWP-Prozesses, ohne daß ein Fehler in den darunterliegenden Schichten aufgetreten ist, ließe sich problemlos diagnostizieren, da die graphische Darstellung der Schicht, in der der Prozeß sich befindet, eine andere Farbe annimmt, während die Farbe der Icon-Bestandteile, die die darunterliegenden Schichten repräsentieren, unverändert bliebe.

Im wesentlichen lassen sich die Erkenntnisse für das Management der verteilten Kommunikationsanwendung NWP auch auf verteilte Anwendungen im allgemeinen Sinne übertragen: Im Zuge der Datenintegration sind Fragestellungen wie die Anbindung relationaler Datenbanksysteme an Anwendungen von großem Interesse; die Überwachung des Zustands einer verteilten Anwendung sowie das Lesen und Modifizieren von Konfigurationsinformation und Systemdateien hat auch in der ,,Nicht-NWP-Welt`` seine Berechtigung. Die entwickelten Managementszenarien lassen sich prinzipiell, bis auf wenige Ausnahmen, nicht nur bei Filetransfersystemen, sondern auch bei diversen anderen verteilten Anwendungen einsetzen.

Insgesamt wurde eine Basis geschaffen, die unter Verwendung der Programmiersprache C++ und der Inductive Modeling Technology eine flexible Weiterentwicklung im Hinblick auf eine integrierte Managementlösung für das NetzWerk-Programm erlaubt. Die Erstellung einer graphischen Benutzeroberfläche, die die beschriebenen Sichten beinhaltet, die vollständige Integration vorhandener Datenbestände sowie die Ausdehnung des Managementkonzepts auf weitere Systemwelten sollten die Schwerpunkte bei der Weiterentwicklung der in der vorliegenden Arbeit entworfenen Konzepte bilden.