Die unterschiedliche Komplexität der Netze stellt immer höhere Anforderungen an das Netzwerk-Management. Die Verwaltung zentral orientierter, relativ homogener Terminalnetze basiert heute auf weiterentwickelten Konzepten und Produkten. Für die Zukunft stoßen diese jedoch wegen der zunehmenden Heterogenität der Systeme an ihre Grenzen. Der erste Beitrag einer Serie von Franz-Joachim Kauffels* präzisiert die Aufgaben des zukünftigen Netz-Managements und behandelt als Beispiel die Entwicklung des Netz-Management-Systems NMA von IBM.

Nur wenige Teilgebiete der Informatik und Rechnertechnik haben in den letzten Jahren eine derart starke Entwicklung vollzogen wie die Techniken des Rechner- und Systemverbundes. Das Zusammenwirken von Informatik, Telekommunikation und Nachrichtentechnik ermöglicht neue Formen der Kommunikation zwischen Geräten der digitalen Informationsverarbeitung, etwa den Hochgeschwindigkeits-Datentransfer über lokale Netze und Fernverbund über Satellitenkanäle.

Die Anforderungen an Netzwerke wachsen zumindest in zwei Dimensionen:

- die Anzahl der Stationen pro Netz steigt permanent,

- die logische Komplexität beziehungsweise funktionale Ebene der durch das Netzwerk zu leistenden Funktionen wird angehoben.

Darüber hinaus ergeben sich zusätzliche Probleme durch den Verbund von - meist heterogenen - Netzwerken.

Während die übertragungstechnische Seite der Netzwerke im wesentlichen klar ist, gibt es im Bereich der betriebsunterstützenden Funktionen ähnliche Unsicherheiten wie bei einer allgemeineren Formulierung der anwendungsorientierten Aspekte der Rechnernetze.

Die logische Komplexität von Netzsystemen ist unterschiedlich und reicht vom Terminalnetz über Server-konzeptorientierte Netze und offene Systeme hin zu verteilten Systemen. In vielen Fällen findet man eine bunte Mischung von unterschiedlich organisierten Teilnetzen vor. Demgemäß sind die Anforderungen an das Management dieser Netzsysteme unterschiedlicher Natur. Es lassen sich jedoch auch Gemeinsamkeiten erkennen.

Zunächst müssen also die Aufgaben des Netz-Managements näher präzisiert werden. Betrachten wir das Management eines vernetzten Systems global, so ergibt sich eine Zweiteilung in äußere und innere Funktionen. Die äußeren Funktionen sind solche, die vom System selbst nicht vollständig ausgeführt werden können und von natürlichen Personen, wie "Administratoren" oder "Repairmen" erledigt werden müssen, wobei das System selbst höchstens unterstützend wirkt. Die inneren Funktionen werden durch das System selbst ausgeführt, um seine Leistungsfähigkeit im Hinblick auf Funktionalität, Reaktionsfähigkeit und Zuverlässigkeit sicherzustellen.

Terplan (Ter 87) spricht in diesem Zusammenhang auch davon, daß es drei kritische Erfolgsfaktoren für das Management von Kommunikationsnetzen gibt: Methoden, Werkzeuge und menschliche Ressourcen.

Alle drei müssen angemessen gewertet werden. Die Methoden für das Netz- Management hängen sehr stark vom Netz und seiner Struktur ab. Sie sollten jedoch nicht unmittelbar von der Größe des Netzes bestimmt werden, weil der Netz-Manager eventuell Probleme bekommt, wenn das Netz wächst.

In der Bundesrepublik sind die Netze zwar vergleichsweise klein, wachsen aber proportional zum allgemeinen Trend. Wir können davon profitieren, daß andere, zum Beispiel in den Vereinigten Staaten, schon früher größere Netze zu verwalten hatten. Dennoch sollte man sich heute nicht falschen Illusionen hingeben: Durch den Vormarsch der PCs muß innerhalb der nächsten fünf Jahre mit einer Verzehnfachung der vernetzten Computer gerechnet werden. Im Rahmen dieses Zehnerpotenzsprunges kann ein Netz nicht mehr "von Hand" gemanagt werden, wie viele heute noch glauben.

Hinzu kommt, daß die Tools heute immer mächtiger werden. Mußte sich ein Netz-Manager bislang mit einigen Terminals und Konsolen zufriedengeben, stehen ihm heute leistungsfähigste Systeme zur Verfügung.

In einer ersten Näherung er geben sich für heute existierende Kommunikationsnetze mit klassischer Baumstruktur folgende fünf Gruppen von Netz-Management-Funktionen (zum Beispiel nach Slo 84):

1. Die Netzsteuerung (Operational Management) beschreibt die Gruppe der Funktionen, die im laufenden Betrieb dazu benutzt werden, die Netzwerk-Betriebsmittel bereitzustellen und zu verwalten.

2. Das Fehlermanagement (Maintenance) faßt alle Funktionen zusammen, die zur Fehlerprophylaxe, -erkennung und -behebung im Netz benutzt werden können.

3. Die Konfigurationsverwaltung (Configuration Management) enthält Hilfsmittel und Funktionen zur Planung, Erweiterung und Änderung der Konfiguration sowie zur Pflege der Konfigurationsinformationen .

4. Netz-Tuning (Performance Management), -Hilfsmittel und -Werkzeuge werden zur Messung und Verbesserung des Leistungsverhaltens des Netzes eingesetzt.

5. Die Benutzerverwaltung (User Administration) enthält Mittel zur ordnungsgemäßen Abwicklung der Benutzung des Netzes wie Zugangsverwaltung, Nutzungskontrolle und Abrechnungshilfen sowie nach (Heg 86) auch Informationsdienste.

Bei der generellen Konstruktion von Netzsystemen sind das ISO-Referenzmodell (DIN 82, Eff 86, Bey 88) und die aus diesem resultierenden Standards ein Anhaltspunkt für den Stand der Technik und einen Teil der Entwicklungen.

Da jedoch nach diesem nur die Protokolle, die dazu benötigt werden, den Informationsaustausch zwischen Systemen zu steuern, Kandidaten für eine Standardisierung sind, werden lediglich diejenigen Management-Aktivitäten als zum Rahmen der Architektur gehörig angesehen, die einen tatsächlichen Informationsaustausch zwischen Systemen implizieren. Andere Management-Aktivitäten, die lokal zu einem System sind, werden in diesem Zusammenhang nicht betrachtet.

Da eine solche Trennung nicht immer eindeutig vollzogen werden kann (zum Beispiel ist die Durchsetzung einer Benutzerautorisierung je nach Typ des Netzwerks und Anwendung systemlokal oder netzweit vorzunehmen), ist dieser Standpunkt für eine geschlossene Betrachtung der Gesamtproblematik in vielen Fällen unangemessen.

Über die grundsätzlichen Aufgaben des Netz-Managements, nämlich Planung, Implementierung und Kontrolle der diversen physischen und logischen Elemente eines Netzes hinaus muß man, wie bereits durch die vorigen Kapitel klar geworden ist, weitere Anforderungen an ein Management-System stellen.

Dies betrifft vor allem das Zusammenspiel zwischen Informationen aus dem System und den Entscheidungsträgern, den Netz-Administratoren. Sie müssen die geeigneten Daten geliefert, formatiert und präsentiert bekommen. Sie brauchen eine Möglichkeit, Informationen untereinander und mit dem Gesamtsystem auszutauschen. Dabei kann man voraussetzen, daß die Administratoren räumlich voneinander getrennt sind.

Die Informationsaufbereitung und -ausbreitung sollte in höchstem Maße verfügbar und schnell sein. Als Beispiel für die Evolution eines Netz-Management-Konzepts diene an dieser Stelle IBM-CNM (Computer Network Management).

Das Management großer Netze verlangt heute mehr als Intuition der Administratoren, besonders, wenn es sich um IBM-SNA-Netze handelt. SNA-Netze haben sich von zentralistisch orientierten Systemen mit einem Host von einem Anbieter zu verteilten Datenverarbeitungsumgebungen mit vielen Hosts und Geräten von unterschiedlichen Herstellern gewandelt. Damit hat auch das Management-Problem für SNA-Netze neue Dimensionen gewonnen.

IBM hat seine Netz-Management-Architektur NMA (auch unter CNM Computer Network Management oder MSA Management Services Architecture bekannt) laufend weiterentwickeln müssen, um dem Fortschritt bei SNA-Netzen zu entsprechen.

SNA und die im Rahmen der System-Anwendungs-Architektur SAA gebildeten Erweiterungen mögen als Beispiel für die Entwicklung einer Familie von Hard-, Soft- und Firmware zur Steuerung von Terminals hin zu einer Basis für die Realisierung verteilter Anwendungen in einer vielseitigen Umgebung vom Arbeitsplatzrechner bis zum Großsystem gelten.

Die Weiterentwicklung von SNA ist durch zwei Charakteristika gekennzeichnet:

- Ausbau der Grundarchitektur im Hinblick auf eine hohe Transparenz im Sinne von SAA, - Öffnung der Architektur für die Belange heterogener Kommunikation und internationaler Standards.

Die Grundstruktur eines "traditionellen" SNA-Netzes ist ein Baum. Die gesamte Steuerungsgewalt liegt beim SSCP (System Services Control Point, auch CP abgekürzt). Jedes Zusammenwirken zwischen Terminals und Anwendungen wird durch die Zugriffsmethode, die Datenbank- und Kommunikationssoftware im Host gesteuert. Die Kontrollelemente werden teilweise logisch vom Host aus in die Cluster- und Kommunikations-Controller heruntergebrochen.

Jeder Nachrichtenfluß bezieht sich auf den Host. Aus diesem Grunde kann man auch Nachrichtengrößen, Gesamtumfang der Nachrichten und Zwischenankunftsverteilungen mit großer Sicherheit voraussagen. Die Zwischenankunftszeit ist die Zeit, die zwischen dem Beginn der Übertragung einer Nachricht und dem Beginn der Übertragung der darauffolgenden Nachricht vergeht.

Kennt man die durchschnittliche Nachrichtenlänge (zum Beispiel in Zeiteinheiten: Eine Nachricht des Umfangs 12 000 Bytes ist auf einem Übertragungskanal mit 9600 Bit/s Übertragungsleistung etwa zehn Sekunden "lang") und die Verteilung der Zwischenankunftszeiten, so kann man leicht die durchschnittliche Belastung sowie die Leerzeiten ausrechnen. Für die Planung ist dies eine große Hilfe.

Ein IBM-SNA-Netz alter Struktur ist also aufgrund seines beschränkten Sicht- und Wirkungsbereiches sowie aufgrund seines in höchstem Maße vorhersehbaren Verhaltens sehr leicht zu managen.

Die Abbildung zeigt ein Beispiel für ein hochverzweigtes, komplexes, aus mehreren Teilnetzen bestehendes SNA- Multidomänen-Netz mit Geräten verschiedener Hersteller. In der oberen Hälfte der Abbildung sieht man ein SNA-Internetz-Verbindungs-Gateway (SNA Network Interconnection SNI). Hier werden zwei Multidomänen-SNA-Netze durch den Gateway-SSCP und das Gateway-Netzwerk-Kontroll-Programm (Gateway-NCP) miteinander verbunden.

Ein CP kontrolliert die Funktionen der Betriebsmittel eines Knotens. Jeder SNA-Host ist lokal oder remote an verschiedene Kommunikations- und Cluster-Controller angeschlossen, wobei gleichermaßen Punkt-zu-Punkt- wie auch Punkt-zu-Mehrpunkt-(multidropped-) Verbindungen zu finden sind.

Hosts können darüber hinaus durch paketvermittelnde WANs, Nebenstellenanlagen oder Token-Ring-Netze miteinander verbunden werden. Schließlich werden in vielen Fällen Verbindungen zwischen Nicht-IBM-Subnetzen, zum Beispiel von DEC, HP, Tandem, Wang oder Siemens, durch SNA-Netze hergestellt. Dies hat seine Historie im wesentlichen darin, daß SNA heute, solange die Palette für Vernetzungsprodukte nach ISO-Standards immer noch sehr klein ist, einer der ganz wenigen gemeinsamen Nenner zwischen unterschiedlichen Subnetzen ist. "Jeder kann ein bißchen SNA", vom PC bis zum Host.

Das Management eines modernen SNA-Netzes entspricht also der Navigation durch einen Komplex logischer und hybrid vernetzter Umgebungen. Die Aufgabe von SNA ist die Verwaltung von logischen Ende-zu-Ende-Verbindungen auf der Session-Schicht (entspricht in etwa der Kommunikations-Steuerungsschicht im ISO-Modell) und der physischen Verwaltung der Wege im Netz und der Datenverbindungen. Dies war in der ursprünglichen Umgebung eines Klasse-1-Netzes relativ einfach. In einer verteilten Umgebung ist dies alles jedoch um ein Vielfaches schwieriger:

- Nachrichtengrößen und -umfang sowie Ankunftszeitpunkte von Nachrichten in Puffern sind in einer verteilten Umgebung nicht so schön vorhersehbar wie in klassischen Terminalnetzen.

- Kleinsysteme wie PCs, PS/2, /36, AS/400 und /6000 können als eigenständige informationsverarbeitende Einheiten arbeiten, 3270-Terminals emulieren oder Dateien übertragen. Sie sorgen damit für noch mehr unvorhersehbares Verkehrsaufkommen und stellen somit zusätzliche Unsicherheitsfaktoren für die Netzleistung dar.

- Die Traces von LU-LU-Ende-zu-Ende-Sessions, die für die Diagnose und andere Zwecke benutzt werden, müssen gegebenenfalls über Gateways laufen. Ob diese Operation sinnvoll, erfolgreich und effizient ist, hängt davon ab, inwieweit die Administratoren verschiedener Teilnetze und Benutzer-Organisationen kooperationsfähig sind.

- Die Leistung eines paketvermittelnden WANs kann üblicherweise nicht durch die äußeren Nutzer kontrolliert werden.

- Das Management der Host-Domänen und Controller-Subareas hört normalerweise am Knotentyp PU 2.0 auf.

- Nicht-IBM-Geräte und Umgebungen können lokal sehr viele aktuelle Management-Informationen sammeln. Sie sind jedoch für den SNA-Host nicht notwendigerweise verständlich, falls er sie überhaupt erhält.

Management schaltet Fehler durch Bypass aus

Die Network Management Architecture (NMA) spezifiziert im Rahmen der IBM-Welt die Management-Services, die dazu gebraucht werden, die Funktionen innerhalb eines SNA-Netzes zu planen, zu organisieren und zu kontrollieren.

Das Problem-Management ist der Prozeß der Handhabung von Schwierigkeiten im Netz von der Entdeckung bis zur Lösung. Im Rahmen der Problembestimmung werden Fehlerquellen in Hard-, Soft- und Firmware durch einen automatisierten Prozeß oder "von Hand" entdeckt. Die Diagnose stellt die Ursache des Problems fest. In vielen Fällen wird man die Ursache nicht sofort beseitigen können, sondern muß versuchen das Problem zunächst einmal einfach zu umgehen (Problem Bypass) und danach wiederaufzusetzen (Problem Recovery).

Leistungs- und Abrechnungs-Management ist der Teil von NMA, der die Nutzung von Netzkomponenten quantifiziert, aufzeichnet, kontrolliert und saldiert. Die Beobachtung von Antwortzeitmessungen erzeugt Problemmeldungen wenn vorbestimmte Schwellwerte überschritten werden.

Das Konfigurations-Management kontrolliert die Information, die dazu benötigt wird, vernetzte Betriebsmittel und deren Abhängigkeiten und Wechselwirkungen jederzeit zu identifizieren. Dies betrifft gleichermaßen physische und logische Netzbetriebsmittel wie Hosts, Kommunikationsvorrechner, Cluster-Controller, Modems, Multiplexer, Konzentratoren und Protokollkonverter sowie deren Soft- und Firmware.

Änderungs-Management ist der Prozeß der Planung und Kontrolle von Änderungen (Hinzufügen und Entfernen sowie Modifikation von vernetzter Hardware, Microcode und Software). Die Software-Änderungskontrolle achtet auf Softwarebewegungen wie Installation, Entfernung, Modifikationen und Modulen, die nur vorübergehend installiert werden. Die Microcode- und Hardware-Änderungskontrollen führen über Installation, Entfernung, konstruktive, funktionelle oder andere Änderungen in Microcode beziehungsweise Hardware Buch.

Die vier Hauptelemente von NMA werden durch einen Netz-Operator ausgeführt. Dies kann ein Programm oder ein Mensch sein. Hiermit hält sich IBM die Verlagerung der Management-Konstruktion in Richtung Artificial Intelligence sehr schön offen. Der Operator muß einen Zugriff zu einem SNA-Knoten haben, der Kontrollpunkt-Management-Services (CPMS) und Physical Unit Management Services (PUMS) besitzt.

Wir nehmen zur weiteren Erklärung der Funktionsweise an, daß CPMS in einem PU5-Host residiert. Dann verwaltet er alle PUs seiner Domäne durch SSCP-PU-Kontroll-Sessions. CPMS leitet Anfragen vom Netzwerk-Operator an die PUs weiter, um den jeweiligen Status aufzunehmen. CPMS setzt Parameter und testet entfernte Betriebsmittel. Es fordert Management-Service-Daten, wie Testergebnisse, Antwortzeiten, Fehler- und Leistungsstatistiken an. Zusätzlich werden unaufgeforderte Meldungen, wie Alarme aus physischen oder logischen Einheiten, gesammelt und aufgezeichnet. Diese Daten werden für die Weiterverarbeitung in den vier Hauptbereichen von NMA vorverarbeitet.

NMA unterscheidet konstruktiv zwischen Focal Point, Entry Point und Service Point. Üblicherweise residiert der Focal Point in einem System /370-Host. Er stellt von zentralen Netzwerk-Management-Anwendungen vorbereitete und bereinigte Netzwerk-Management-Daten zur Verfügung. Entry Points sind Stellen, die Netzwerk-Management-Services für sich selbst und für die an sie angeschlossenen SNA-Betriebsmittel und -Geräte anbieten. Service Points liefern Management-Services zur Unterstützung des Zugriffs von Nicht-SNA-Einheiten (von IBM hergestellt oder auch nicht) in SNA. Sie sind sozusagen Netzwerk-Management-Server: Sie sammeln Netzwerk-Management-Daten von Nicht-SNA-Einheiten, konvertieren diese Daten in SNA-Netz-Management-Service-Daten und leiten die Information zu einem Focal Point weiter. Die Kommunikation zwischen den Nicht-SNA-Betriebsmitteln und den Service-Points werden nicht durch SNA-Protokolle verwaltet.

Netview

Release 1

Das Mitte 1986 angekündigte Netview, L1 Release ist die strategische Implementierung eines Focal Points innerhalb SNA. Es faßte Elemente der wichtigsten bisherigen IBM-Produkte zum Netz-Management zusammen. Mitte 1987 kam Release 2 für die wichtigsten /370-Betriebssysteme MVS/XA, MVS/370, VM und VSE. Release 3 aus dem Jahr 1989 umfaßt weitere Elemente der IBM-Netzumgebung, wie Token-Ring-Subsysteme und LAN.

Die Basiskomponente in Netview ist die Command Facility. Sie ist aus NCCF, der Network Communications Control Facility, hervorgegangen. NCCF wurde praktisch um die Fähigkeit erweitert, mit anderen, neuen Netview-Komponenten zusammenzuarbeiten und neue Netzprodukte, wie IBM 586X/38XX-Modems, 3710-Netz-Controller und Token-Ring-Netze zu unterstützen. Ein Element der Command Facility, die Terminal Access Facility TAF, unterstützt verschiedene Bildschirmgrößen für Terminals von 1920 bis zu 65 025 Zeichen pro Bildschirmseite. Die Command Facility hilft bei der Konfiguration zum Beispiel von Modems und beim Lastausgleich.

Eine weitere wesentliche Kernkomponente von Netview ist der Session Monitor. Wie fast alle anderen wichtigen Komponenten ist auch er eine Weiterentwicklung eines bestehenden Produkts, nämlich des Network Logical Data Managers NLDM. Auch er läuft unter der Command Facility. Der Session-Monitor ist dazu gedacht, Software-Problembestimmung, Konfigurations- und Leistungs-Management mit Hilfe der Beobachtungs- und Aufzeichnungsmechanismen für SNA-LU-zu-LU-Verbindungen durchzuführen. Der Monitor beobachtet Sessions sowohl in isolierten SNA-Netzen als auch durch Gateways.

Netview, Release 3, bildet die Basis für die Behandlung aller Netzwerk-Alarme in VM/SP-, VM/XA-, MVS/370- und MVS/ESA-Umgebungen. Es erlaubt einem Focal Point, Alarme der eigenen oder einer verbundenen Domäne aufzuzeichnen Release 3 unterstützt Sprach-Support für PL/1, C und Schnittstellen zu Werkzeugen der Wissensverarbeitung. Der IBM-LAN-Manager, der in einer Token-Ring-Umgebung für Management-Aufgaben zuständig ist, wird ebenfalls unterstützt. Netview-Release 3-Kommandolisten können in der SAA-kompatiblen prozeduralen Hochsprache REXX formuliert werden.

Weitere Einzelheiten zu Funktion und Aufbau von Netview können (Ter 87) oder (Kau 90) entnommen werden.

Netview/PC ist eine strategische NMA-Service-Punkt-Implementierung. Es ist eine Erweiterung der Netview-Services und dazu gedacht, das Netview-Netz-Management über IBM LANs und Rolm Nebenstellenanlagen (demnächst vielleicht auch Siemens-Nebenstellenanlagen ?) sowie Nicht-SNA- und Nicht-IBM-Kommunikationseinrichtungen hinweg auszudehnen. Bei Token-Ringen kann Netview/PC zum Beispiel ein LAN über einen Gateway-PC mit dem Netview verbinden.

Der Token-Ring-Netzwerk-Manager (LAN-Manager) ist eine Netview-PC-LAN-Anwendung. Bei Fehlern im Token-Ring, der Überschreitung eines Fehlerlimits, dem Selbstheilen des Token-Rings und weiteren Ereignissen informiert der LAN-Manager das Netview. Der IBM LAN-Manager unterstützt darüber hinaus auch PC-LAN-Breitband-Installationen und das Brückenprogramm hilft beim Management zusammengeschalteter LANs.

Netview-Utilities sind nur schwer überschaubar

Netview ist ein wesentliches Instrument zur Steuerung großer Netze. Sein zentralistischer Ansatz ist der Struktur eines modernen SNA-Netzes angemessen, sofern es genügend Komponenten gibt, die entsprechend ausgelagert werden können.

Neben Grundfunktionen besteht es aber aus einer Sammlung unterschiedlichster Utilities, deren Einsatzmöglichkeiten stark von der jeweiligen Host-Umgebung geprägt werden. Dies führt letztlich zu einer unübersichtlichen Systemvielfalt.

Netview wird sich sicherlich in Richtung verteilte Datenverarbeitung weiterentwickeln und auch im SAA-Spektrum einen angemessenen Platz bekommen.

Problematisch ist es heute daß Netview viel zu viel Information erzeugt, die von den meisten Operatoren nicht mehr sinnvoll ausgewertet werden kann. Die Fortentwicklung des Systems muß im Hinblick auf eine weitere Automatisierung der gesamten Funktionen vorgenommen werden, wenn es Aussicht auf Erfolg haben soll.

Alternativen zu Netview

Je nach Anwendungsfall gibt es Alternativen zu Netview, von denen nur einige genannt werden sollen:

NET/Master von Cincom arbeitet unmittelbar mit VTAM, so daß weder Netview noch NCCF benutzt werden. Nach Ansicht von Experten und Anwendern hat Net/Master zwei wesentliche Vorteile gegenüber Netview: leichteres Management von Ressourcen und eine 4GL-Sprache als Benutzerschnittstelle.

Der NET/Master wird in (Mel 90) genauestens erläutert, so daß wir uns an dieser Stelle nicht weiter mit ihm befassen wollen. Eine äußerst interessante Gegenüberstellung macht (Ter 90).

Andere Produkte veredeln die Oberfläche von Netview, wie zum Beispiel NET/Center von US-West. Alles in allem ist der Einsatz von Alternativen immer mit einem gewissen Restrisiko behaftet, was die Reaktion auf Erweiterungen des IBM-SNA-Konzeptes betrifft.

Im nächsten Teil der Reihe werden Konzepte für offene Systemumgebungen betrachtet. Die wichtigsten offenen Netz-Systemumgebungen sind OSI und TCP/IP, dementsprechend wird das OSI-Netzwerk-Management Framework und SNMP, das Simple Network Management Protocol im Rahmen von TCP/IP vorgestellt.