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.

08.04.1988 - 

Zahlreiche Tools, aber noch kein integriertes Instrument:

Der Idealfall wäre ein durchgehendes Management

Für das SNA-Netzwerkmanagement bieten sich mehrere Lösungskonzepte und -instrumente an. Kornel Terplan* beschreibt im folgenden den Leistungsumfang der geeigneten Produkte und wertet sie aus. Er diskutiert die unterschiedlichen Konzepte der Zentralisierung und Integration des Netzwerkmanagements, insbesondere die Methode der Communication Management Configuration (CMC), die Einbindung lokaler Netze, ferner von Nebenstellenanlagen und von Nicht-IBM-Komponenten in das zentrale Management.

Als Ergebnis vieler Diskussionen mit Benutzern und der Analyse von zahlreichen Herstellererhebungen können die wichtigsten Anforderungen wie folgt zusammengefaßt werden:

- Aufrechterhaltung der Serviceleistungen, wie Verfügbarkeit und Antwortzeit trotz der überdurchschnittlichen Wachstumsraten im Endbereich (bis zu 30 Prozent) und vieler technologischer Änderungen wie Paketvermittlung, ISDN, private Dienstangebote und lokale Netze;

- Sicherung des Endbenutzerservicegrades, ausgedrückt durch Verfügbarkeit und Antwortzeit;

- Konsole-Management, damit anstelle der eigenständigen Konsolen, die öfters in verschiedenen Räumen aufgestellt sind, eine zentrale Anlaufstelle sämtlicher Netznachrichten implementiert wird;

- Pflege einer Datenbank für Netzwerkmanagement-relevante Informationen, wobei nach Möglichkeit auch die Betriebsführung unterstützt wird;

- durch die sorgfältige Wahl von Instrumenten und Automatismen soll verhindert werden, daß die Anzahl der Auftraggeber im Netzbetrieb unkontrolliert zunimmt;

- Integrierung der physikalischen und logischen Anteile des Netzwerkmanagements zur Unterstützung der Diagnose, Tuning und Netzplanung;

- Koordinierung von mehreren Herstellern, Architekturen und Netzen durch entsprechende Verfahren, Instrumente und Aufgabenträger;

- Überwachung und Optimierung der Performance von Anwendungen, Betriebssystemen und Netzkomponenten.

State of the art

Die oben aufgeführten Anforderungen müssen je nach Netz- und Systemlandschaft gewichtet werden, damit die richtige Reihenfolge der Architektur bestimmt werden kann. Die Hersteller benutzen die eigene Wichtung zur Festlegung der Maßnahmen für die Produktentwicklung. Derzeit scheint das Konsole-Management die höchste Priorität zu haben.

Der derzeitige Stand des Netzwerkmanagements kann durch folgende Fakten charakterisiert werden:

Die existierenden Ansätze und Lösungen beziehen sich auf einzelne Architekturen, Produkte oder Hersteller, zum Beispiel NetView und Net/Master für SNA, TDA und Trasom für Transdata, TNAS und Cenlogs für Unisys, DECnet Mon für DEC. Das Management für physikalische und logische Netzwerkkomponenten, zum Beispiel Module der Kommunikationssoftware (NCCF, Telcom, PDN) beziehungsweise Modem- und Netzmonitore erfolgt getrennt. Es gibt keine Korrelation der Informationen, die aus unterschiedlichen Quellen stammen; es werden höchstens manuelle Korrelationen gemacht, und meistens nicht für das Echtzeitgeschehen. Die unterschiedlichen Architekturen sind noch getrennt, da die Gateways, die Architekturen verbinden, managementrelevante Informationen noch nicht konvertieren können.

Der Servicegrad des Endbenutzers wird nur sporadisch, aber weder periodisch, noch kontinuierlich überwacht. Entweder fehlen die Instrumente, oder sie verursachen sehr viel Overhead. Es werden zu viele Daten im Netz übertragen, die lediglich irrelevante Meldungen beinhalten. Filterungs- und Interpretierungsmöglichkeiten vor Ort fehlen. Es kann Redundanz unter einigen Erfassungsprodukten festgestellt werden. Dadurch werden unnötig viele Daten gesammelt und unnötig viel Overhead verursacht. Das Fehlen einer Datenbasis für Informationen, die für das Netzwerk relevant sind, verhindert die effiziente Betriebsüberwachung und das Weiterreichen von Informationssegmenten an nachgelagerte Verfahren.

Netzwerkmanagement bedeutet die Koordination aller Ressourcen, die zum Design, zur Planung, zur Modellierung, zur Steuerung, zur Simulation, zur Generierung, zur Implementation, zur Analyse, zur Überwachung, zur Messung und zum Testen von Kommunikationsnetzwerken notwendig sind, damit der Servicegrad für Endbenutzer mit angemessenen Kosten durch optimale Kapazitätsverteilung garantiert werden kann.

In praktischen Implementierungen kristallisieren sich folgende Funktionsmodelle aus:

- Konfigurationsmanagement: Bestandsführung und Änderungsdienst der statischen Konfigurationsdaten und Schnittstellen zu allen anderen Moduln,

- Problemmanagement: Erkennung, Registration, Bestimmung und Behebung von Funktions- und Performancestörungen,

- Servicemanagement. Verhandlung und Überwachung des Servicegrades mit Hilfe der Indikatoren Verfügbarkeit und Antwortzeit,

- Performancemanagement: Messung, Analyse und Optimierung des Netzverhaltens in bezug auf Service- und Auslastungsindikatoren,

- Anwendungsmanagement: Schätzung des Ressourcenbedarfs von neuen Anwendungen und Pflege bestehender Anwendungen,

- Kapazitätsmanagement: Planung und Bereitstellung der erforderlichen Ressourcen (Prozessoren und Netze) aufgrund von Schätzwerten mit Hilfe von Modellen, Emulatoren und Simulatoren.

Nach den Komponenten die Architekturen

Nach vielen Interviews mit Herstellern, Benutzern und Beratungsfirmen zeichnen sich folgende Lösungs- und Implementierungsalternativen ab:

Die Integration erfolgt in verschiedenen Dimensionen. Erstens werden mehrere Komponenten innerhalb eines Netzes integriert. Danach folgt die Integration über mehrere Architekturen. Zum Schluß wird die Integration über mehrere Kommunikationsformen wie Sprache, Daten, Text und Bild erwartet.

Integration bedeutet, daß über alle physikalischen und logischen Komponenten ein durchgehendes Management implementiert wird. Dabei werden alle Alarmmeldungen gleichrangig behandelt und verarbeitet, Konfigurations- und Verwaltungsbefehle für sämtliche Komponenten angestoßen, und eine einheitliche Benutzerschnittstelle als Lösung des Problems des Konsolmanagements angeboten.

Vorsicht bei der Dezentralisierung

Viele Benutzer sind gern bereit, die Prozessorleistung und sogar die Datenbasis zu verteilen. Aber man ist sehr vorsichtig, wenn es gilt, Aufgaben des Netzwerkmanagements zu dezentralisieren. Viele Gründe mögen für die Zentralisierung sprechen:

- bessere Instrumentierung der Zentrale,

- bessere Konzentration der Aufgabenträger in der Zentrale,

- durch eine globale Übersicht kann die optimale Lösung sowohl im Betrieb als auch bei der Planung erzielt werden.

Die Zentralisierung kann unterschiedlich implementiert werden. Entweder übernimmt ein Netzwerkmanagementprozessor sämtliche Managementaufgaben, wie zum Beispiel Communication Management Configuration (CMC) von IBM, oder es werden mehrere Prozessoren mit dedizierten Aufgaben vorgesehen, die miteinander über ein lokales Netz kommunizieren, wie zum Beispiel INMS-Prozessoren auf Unix-Basis von AT&T.

Bei praktischen Anwendungen geht man oft Kompromisse ein, indem gewisse Funktionen wie Datensammlung, Filterung und Vorverarbeitung vor Ort ausgeführt werden. Auch dezentrale Automatismen zur Unterstützung der Betriebsführung werden häufig implementiert.

Erhöhung der Intelligenz

Es wird erwartet, daß bei operativen, taktischen und strategischen Entscheidungen vor allem Informationen und nicht nur Daten gebraucht werden. Dazu sind Tendenzen bereits heute erkennbar:

- Intelligente Filterung der Daten,

- Implementierung von Prozeduren zur Automatisierung des Betriebsablaufes,

- Generierung von inaktiven Netzkomponenten, wie Knoten und Verbindungen, die im Probefall als Back-up dienen,

- Einsatz von Prototypen für Expertensysteme zur Betriebsüberwachung und Netzoptimierung,

- Implementierung von relationalen Datenbasen, die jegliche Prüfung der Zusammenhänge zwischen Netzkomponenten ermöglichen.

-Alle obengenannten Funktionen können in der Zukunft von wissensbasierenden Systemen übernommen werden. Derzeit stehen zahlreiche Instrumente für das Netzmanagement zur Verfügung. Es gibt aber noch kein integriertes, wo Erfassung, Verarbeitung und Modellierung gemeinsam angeboten werden. Bei der Entscheidung für oder gegen ein Instrument müssen folgende Trends beachtet werden:

- Hardwaremonitoren verschwinden,

- Computerhersteller versuchen die Instrumentierung zu vereinfachen (zum Beispiel: NetView als einheitliche Benutzerschnittstelle),

- Hersteller von Softwaremonitoren integrieren die Messungen für Prozessoren und Netzbereiche,

- Hersteller von Netzmonitoren reduzieren die Preise,

- Hersteller von Modemmonitoren erweitern den Funktionsumfang, - Datenbasen für das Netzwerkmanagement werden eingeführt und unterstützt,

- Modellierung wird komplizierter,

- Integrierte Instrumente haben die besten Überlebenschancen,

- unabhängige Netzwerkmanagementsysteme werden konkurrenzfähig (zum Beispiel: Timeplex, Codex, AT&T),

- Unterstützung von NetView/PC ist noch nicht vollständig geklärt,

- Internationale Standards werden eine große Rolle spielen (zum Beispiel: AT&T, DEC und Codex bieten die volle Unterstützung an).

Netview und Netview/PC

NetView integriert die bisher eigenständigen Produkte für ein Netzmanagement, wie NCCF, NPDA, NLDM, VNCA und NLDM. Die Funktionen dieser Produkte werden mit NetView weiterentwickelt und ihre Handhabung vereinfacht. Bild 1 zeigt die Architektur von NetView.

NetView/PC ist ein Gateway-Zugang für die Nicht-IBM-Welt zur zentralen Integration der Netzmanagementinformationen unter NetView. IBM stellt dazu das Application Program Interface (API) bereit. Das Gateway wird in einem IBM/PC implementiert. Dadurch paßt NetView/PC in eine umfassende, integrierte Netzmanagementkonzeption, wie im Bild 2 veranschaulicht. Neben NetView/PC werden Komponenten von öffentlichen Netzen, Serie/1-Rechnern, S/36 und S/38 mit LEN (Low Entry Networking-Funktionen) berücksichtigt.

NetView/PC ist vor allem für folgende unterschiedliche Einsatzfälle gut geeignet:

- Lokale Netze: Der Token-Ring-Manager des IBM-Token-Ringes wird der erste Einsatzfall sein. Hierbei werden automatisch Alert-Meldungen von lokalen oder/und von Remote-Token-Rings NetView übertragen.

- Nebenstellenanlagen: Rolm-Produkte, wie Call Detail Collector, Alert Monitor, Abrechnungsinformationen bedeuten einen ersten Einstieg in die Integration des Netzmanagements.

- Fremdarchitekturen: Mit Hilfe der Communication-Service-Funktionen in NetView/PC können formatierte Management-Informationen zum NetView übertragen werden.

Auch die grundsätzlichen Informationsflüsse werden im Bild 2 dargestellt.

Dialoge, herrührend vom Token-Ring oder von Fremdarchitekturen, wie zum Beispiel DNA, DCA, Transdata, CNA, Sinet, Hicom, Netzmonitoren, Modemmonitoren und Multiplexer werden nach entsprechender Programmierung über API/CS-NetView mit Hilfe von NMVT-s (Network Management Vector Table) im Rahmen des SSCP-PU-Protokolls VTAM übertragen. NetView erhält die Informationen vom VTAM. Auch die Aufforderung zur Übertragung weiterer Informationen benutzt diesen Weg.

Im Falle vom Dateitransfer benutzt API/CS den Host Data Facility zur Übertragung. In diesem Fall wird der Weg über LU6.2-DDM-Anwendungen-CICS benutzt. Diese Alternative wird derzeit ebenfalls zur Übertragung von Abrechnungsdaten von Nebenstellenanlagen benutzt.

NetView bringt auf jeden Fall Vorteile für den homogenen IBM-Benutzer:

- Zentralisierung der Netzüberwachung und -kontrolle, wobei auch die CMC-Konzeption (Comrnunication Management Configuration) leichter realisiert werden kann,

- Verbesserung der VNCA- (VTAM Node Control Application) und TAF- (Terminal Access Facility) Funktionsumfänge,

- Implementation eines sogenannten Mainstream-Konzeptes, wodurch alle Informationen durch Zeitmultiplexverfahren in Produktivkanäle integriert werden,

- einfacher Zugriff zu vielen durch den Hostrechner unterstützten Datenbasen, wie zum Beispiel VSAM Dateien, DB2, Info/System, MICS und Info-Base,

- Verfügbarkeit von Schnittstellen zur Modellierung und zur Emulation.

In Zusammenarbeit mit NetView/ PC kann auch eine Integration mit anderen Informationsquellen, insbesondere mit lokalen Netzen, Nebenstellenanlagen, sowie beliebigen Fremdarchitekturen durchgeführt werden.

Offene Fragen mit der Produktionskombination sind:

- Wie kann das Overhead in NetView reduziert werden?

- Wie können Anwendungs- und Systemmonitoren in NetView integriert werden?

- In welchen Schritten wird die Benutzerschnittstelle verbessert? - --- Wann wird die Unterstützung mit einer relationalen Datenbasis implementiert?

- In welchen Schritten wird der NetView/PC-Funktionsumfang ausgebaut?

- Wie sollen die SNA-Parameter gesetzt werden, damit ein optimales Verhalten gegenüber NetView/PC und den anderen PUs garantiert werden kann?

- Wann werden die Einschränkungen in bezug auf die Alarmübertragung in Richtung NetView beseitigt?

- Wie schnell wird die Befehlsübertragung in Richtung Nicht-IBM-Hersteller implementiert?

- In welchem Umfang sind Anpassungen im NetView erforderlich?

- Wann werden die Beschränkungen in bezug auf Hardware, Programmierungssprachen und Anzahl von Kommunikationsports eliminiert?

- Wieviele Hersteller - und wie schnell - werden NetView/PC unterstützen?

Die ersten Versuche demonstrierten die Integration von Alarmmeldungen aus Nicht-IBM-Komponenten, wie Timeplex, DCA/Cohesive, Dataswitch and NET (Bild 3). Die steuernden Eingriffe von NetView werden im nächsten Schritt erwartet.

Erwartetes Verhalten anderer Hersteller

IBM betont bewußt die Integration und Zentralisation des Netzwerkmanagements mit NetView und NetView/PC. Das setzt voraus, daß die anderen Hersteller diese Lösung voll akzeptieren und unterstützen. Es gibt derzeit drei Gruppen von Herstellern, die auf die IBM-Lösung unterschiedlich reagieren:

Gruppe 1: Hersteller, die ohne Diskussion NetView/PC unterstützen und ihre Netzkomponenten durch NetView steuern lassen. Beispiele sind N.E.T. und Teleprocessing Products.

Gruppe 2: Hersteller, die NetView/PC unterstützen, aber gleichzeitig eigenständige Lösungen zum Netzmanagement anbieten. Diese Lösungen beinhalten: Zentralisierung, Filterung, Automatisierung des Operatings der eigenen Komponenten, meistens auf der physikalischen Ebene mit Hilfe von intelligenten Workstations. Gleichzeitig wird dieser zentrale Prozessor (zum Beispiel SUN, HP) als Gateway für NetView/PC angeboten. Beispiele sind Timeplex, Infotron, DataSwitch, Avant-Garde und Dynatech.

Gruppe 3: Hersteller, die NetView/PC offiziell ablehnen und eine Peer-zu-Peer-Verbindung zu NetView oder zu Net/Master unterstützen wollen. Beispiele sind AT&T mit Accumaster, Unisys mit Controlnet, Codex, DEC und wahrscheinlich Siemens für die Hicom-Familie.

Zukunftsorientlerung

Durch den kombinierten Einsatz von NetView (oder Net/Master) und NetView/PC kommt der Benutzer der integrierten und zentralisierten Lösung des Netzwerkmanagements einen Schritt näher. Die ersten praktischen Erfahrungen werden bald vorliegen. Die Lösung bildet dann die Basis für benutzerspezifische Erweiterungen in Richtung der Intelligenzerhöhung durch Expertensysteme. Bei Entscheidungen sollte aber immer wieder externer Rat herangezogen werden. Hierbei sollte vor allen Dingen über eine fachkundige Prüfung der existierenden Ansätze für das Netzwerkmanagement die Portabilität und Zukunftsorientiertheit der Lösung in bezug auf internationale Standards bewertet werden.

*Dr.-Ing. Kornel Terplan ist Unternehmensberater in Gröbenzell bei München. Obiger Artikel beruht auf einem Vortrag, der kürzlich auf dem Datacom-Kongress in Köln gehalten wurde.