-
Die vorliegende Erfindung betrifft eine
Datenverarbeitungsvorrichtung, die in einem Datenverarbeitungs-Betriebsmittel
implantiert ist, um über ein bestimmtes
Standard-Managementprotokoll und über ein Netz den Dialog zwischen einem System
für das Management von Objekten und dem Datenverarbeitungs-
Betriebsmittel zu ermöglichen.
-
Gewöhnlich hat ein System für das Management von Objekten zur
Aufgabe, verschiedene Datenverarbeitungs-Betriebsmittel wie
beispielsweise ein Datenverarbeitungssystem, ein Netzelement
oder ganz einfach eine Anwendungssoftware zu managen. Dazu
wird nach einem bestimmten Standard-Managementprotokoll über
das Netz mittels Anforderungen, die vom Managementsystem an
die Datenverarbeitungs-Betriebsmittel gesendet werden, und
mittels Antworten auf diese Anforderungen, die von den
entsprechenden Datenverarbeitungs-Betriebsmitteln zum Management-
System zurückgegeben werden, ein Dialog eingerichtet. Um
diesen Dialog zu erlauben, ist in jedem Datenverarbeitungs-
Betriebsmittel eine Datenverarbeitungsvorrichtung implantiert,
die speziell dazu vorgesehen ist, die Ausführung dieser
Aufgabe zu vereinfachen. Diese Vorrichtung ist nämlich der
Dialogpartner des Management-Systems in der Anlage, der das zu
managende Datenverarbeitungs-Betriebsmittel unterstützt. Diese
Vorrichtungen sind verschiedener Natur je nach dem Modell der
zu verwaltenden Objekte, die sie unterstützen, und je nach dem
Management-Protokoll, das sie für die Kommunikation mit dem
Managementsystem verwenden. Ein Beispiel einer solchen
Vorrichtung ist mit dem SNMP-Agenten (Simple Network
Management Protocol) gegeben, der im Dokument "Simple Network
Management Protocol. Internet Working Group Request for Comments
1157. May 1990" beschrieben ist und das von der IETF (Internet
Engineering Task Force) definierte Objektmodell und
Management-Protokoll benutzt. Die SNMP-Agenten unterstützen nach
IETF standardisierte Managementobjekte und/ oder sogenannte
individuelle Objekte, die von den Lieferanten der zu
managenden Betriebsmittel (Gerätehersteller, Softwareentwickler, usw.
...) charakterisiert werden. Da ein und dieselbe Anlage,
insbesondere ein Datenverarbeitungssystem, verschiedene zu
managende Betriebsmittel unterstützen kann, ist es
unabdingbar, modulare Agenten zu haben, die imstande sind,
verschiedene Gesamtheiten von Objekten, die
Management-Informationsbasen oder MIB (Management Information Base) genannt werden, zu
berücksichtigen, wobei diese die verschiedenen zu managenden
Betriebsmittel der Anlage repräsentieren.
-
Am Anfang wurden die Agenten ganz in Abhängigkeit von den in
jeder Anlage zu unterstützenden Objekten entwickelt und die
Steuerung eines neuen Betriebsmittels war ein schwieriges
Unterfangen, das dazu verpflichtete, eine neue MIB
hinzuzufügen, und folglich eine Neuentwicklung erforderte, um den
entsprechenden Agenten zu erweitern.
-
In der Absicht, solche Erweiterungen zu vereinfachen, wurden
in jüngster Zeit verschiedene Mechanismen definiert. In einem
ersten Schritt bestand die Vereinfachung in der Definition von
Software-Schnittstellen in den Agenten, um den Dialog zwischen
dem Kern (gemeinsamer unabhängiger Teil der Objekte, dessen
Aufgabe der Dialog mit dem Management-System, die
Fehlerverwaltung, die Datenformatierung usw. ist) und verschiedenen
MIBs der Vorrichtung zu ermöglichen, was erlaubt hat, die
Entwicklung neuer Objekte zu vereinfachen. Wenn also ein neues
Betriebsmittel mit einem gegebenen Agenten nach einem
gegebenen Protokoll verwaltet werden soll, muß ein Modell dieses
Betriebsmittels erstellt werden, was in einer Gesamtheit von
Objekten oder einer MIB Ausdruck findet, die unter Verwendung
der in den Standards empfohlenen Definitionsmodi zu
charakterisieren ist. Bei dieser Herangehensweise, wie sie z. B. im
Dokument "CISCO MIB, CISCO Systems Inc., November 1989"
beschrieben ist, sind die Objekte nach den Standardmethoden oder
dem Standardformalismus definiert, jedoch sind die Objekte
selbst keine Standards, was dazu führt, daß jeder Hersteller
eine ihm eigene Gesamtheit von Objekten entwickelt. Unter
diesen Bedingungen ist es unmöglich, daß sich der Dialog
zwischen einem Management-System und mehreren Betriebsmitteln
verschiedener Hersteller automatisch gestaltet, wobei er die
Nutzung mehrerer Managementsysteme erfordert, wovon jedes eine
Gesamtheit von Betriebsmitteln eines Herstellers verwaltet,
indem eine möglicherweise lange dauernde und teuere
Entwicklung zusätzlicher Software erforderlich ist, die
ermöglicht, gleichsam die gesamte Agenten betreibende
Datenverarbeitungsvorrichtung zu bearbeiten und zu
rekonfigurieren.
-
Zudem zeigen Hersteller und Anwender eine rege Neigung zur
Entwicklung einer immer größeren Zahl an MIBs bei
gleichzeitiger Integration aller existierender MIBs, was unter
Berücksichtigung der Ungleichartigkeit der verschiedenen
Betriebsmittel die Aufgabe ungemein erschwert. Mit dem Ziel, dieses
wachsende Problem wenigstens teilweise zu lösen, wurde in
einem zweiten Schritt die Implantation der MIBs in Unter-
Agenten vorgesehen, die den Dialog mit einem Auswahlagenten
(agent générique) nach einem festgelegten Protokoll führen.
Die Implantation neuer Objekte erfordert in diesem Fall nur
die Entwicklung eines Unter-Agenten. Eine solche Architektur,
wie sie beispielsweise von IBM genutzt wird, ist im Dokument
"SNMP MUX Protocol and MIB, Marshall T. Rose, May 1991"
beschrieben; dabei wird ein "SMUX"-Protokoll für den Dialog
zwischen dem Kern und den Unter-Agenten der Vorrichtung
benutzt. Das "SMUX"-Protokoll wurde gewählt, weil es einfach zu
erstellen ist; es weist jedoch den beträchtlichen Nachteil
auf, daß es nicht neben anderen Agenten-Strukturen bestehen
kann und die Nutzung dieser Technik und folglich die
Entwicklung anderer Unter-Agenten (die den Dialog nach dem "SMUX"-
Protokoll führen) erfordert, um die Verarbeitung von
Informationen zu gestatten, die von Betriebsmitteln anderer
Hersteller stammen.
-
Also bleibt bis heute das Problem der Durchschaubarkeit des
Managements von Datenverarbeitungs-Betriebsmitteln
verschiedener Herkunft ungelöst.
-
Die vorliegende Erfindung hat zum Ziel, die obengenannten
Nachteile dadurch zu beheben, daß sie eine
Datenverarbeitungsvorrichtung vorschlägt, die dem Management-System ermöglicht,
eine globale, einheitliche Betrachtungsweise mehrerer
ungleichartiger Betriebsmittel zu erlangen und damit eine
vollständige Durchschaubarkeit bezüglich der Nutzung der
ungleichartigen, den Dialog nach einem festgelegten
Management-Protokoll führenden Betriebsmittel zu erreichen.
-
Deshalb ist die im Oberbegriff erwähnte
Datenverarbeitungsvorrichtung insofern bemerkenswert, als daß sie einerseits aus
Mitteln zur Lenkung und Steuerung des Dialogs, die unter
anderem eine Konfigurationsdatei enthalten, und andererseits
aus einer Gesamtheit von Standard-Agenten gebildet ist, die
für das bestimmte Management-Protokoll spezifisch sind, das
auch in der vorliegenden Vorrichtung verwendet wird, wobei
jeder Agent eine Gesamtheit von Objekten unterstützt, wobei
die Mittel zur Lenkung und Steuerung des Dialogs Anforderungen
vom Management-System empfangen und sie nach dem Lesen der
Konfigurationsdatei in Abhängigkeit vom Objekt, auf das sie
sich beziehen, an einen oder mehrere geeignete Agenten lenken
und dann die Antworten auf die Anforderungen von dem oder den
geeigneten Agenten empfangen und sie an das Management-System
übertragen.
-
Der Erfindungsgedanke besteht demnach einerseits darin, in der
Datenverarbeitungsvorrichtung das gleiche Management-Protokoll
zu verwenden, das für den Dialog zwischen dem Management-
System und der Vorrichtung benutzt wird, und andererseits
Mittel zur Lenkung und Steuerung des Dialogs vorzusehen, die
durch Lesen der Konfigurationsdatei ermöglichen, die
Anforderungen eindeutig an die betreffenden Agenten zu richten, wobei
jeder der Agenten eine Gesamtheit spezifischer Objekte
gebraucht. Auf diese Art und Weise kann das Management-System
eine globale, einheitliche Betrachtungsweise der Gesamtheit
der verschiedenen Datenverarbeitungs-Betriebsmittel haben. Ein
Anwender kann, ohne auf Schwierigkeiten zu treffen,
automatisch einen Park verschiedenartiger Betriebsmittel nutzen,
denn die Mittel zur Lenkung und Steuerung des Dialogs
verhal
ten sich für das Management-System in vollständig
durchschaubarer Weise. Folglich wäre es z. B. in bestimmten Anwendungen
nicht vorteilhaft, die Herkunft verarbeiteter Elemente zu
kennen, wobei es sich bei diesen Elementen um verschiedene
Netze wie TCP/IP, OSI, DAS usw. handeln kann.
-
Zudem sei bemerkt, daß der Gedanke, in der
Datenverarbeitungsvorrichtung das gleiche Protokoll wie das
Standard-Managementprotokoll zu benutzen, das per definitionem komplex ist, einem
technischen Vorurteil widerspricht. Dieses Vorurteil
rechtfertigte in früheren Verfahrensweisen beispielsweise die
Verwendung eines Protokolls wie "SMUX", das a priori wesentlich
einfacher umzusetzen ist, bezüglich einer Agentenstruktur
jedoch spezifisch und zudem kein Standard ist. Verschiedene
bezeichnende, unerwartete Vorteile ergeben sich hingegen aus
der Tatsache, dieses Vorurteil überwunden und eine
Datenverarbeitungsvorrichtung nach der beanspruchten Architektur
entworfen zu haben. Eine solche Architektur erlaubt nämlich, dem in
ausführbarer, folglich binärer Form Rechnung zu tragen und
einen vorhandenen Standard-Agenten in ein Betriebsmittel zu
integrieren, ohne in irgendeiner Weise den Code des Agenten
modifizieren zu müssen. Die einzige Operation, die auszuführen
ist, besteht darin, die von diesem Agenten unterstützten
Objekte in der Konfigurationsdatei der Mittel zur Lenkung und
Steuerung des Dialogs zu beschreiben. Wenn die Objekte eine
baumförmige Struktur haben, was im allgemeinen der Fall ist,
genügt zur Beschreibung dieser Objekte eine Zeile in dieser
Datei. Die Vorrichtung gemäß der Erfindung kann folglich
vorteilhafterweise Agenten verwerten, die von Herstellern von
Plattformen oder Anlagen entwickelt sind, wobei alle Agenten
in einer für das Management-System durchschaubaren Weise in
der gleichen Anlage nebeneinander vorliegen. Darüber hinaus
ist es möglich, Gesamtheiten von Objekten oder MIBs in
modularer Ausführung in unabhängigen Agenten zu entwickeln. Ebenso
kann ein Anwender eine neue Gesamtheit von Objekten oder MIB
der Vorrichtung gemäß der Erfindung hinzufügen, indem er
selbst einen Agenten entwickelt, wobei er eine beliebige
Technologie nutzen kann, solange nur der entwickelte Agent den
Spezifikationen des benutzten Standard-Protokolls entspricht.
-
Die betreffenden Objekte können folglich Anwendungen,
beispielsweise Mailing, E-Commerce, Datenbanken usw.
repräsentieren. Schließlich kann die vorliegende Erfindung in
vorteilhafter Weise die Anforderungen asynchron verarbeiten: Wenn die
Mittel zur Lenkung und Steuerung des Dialogs die Übertragung
einer Anforderung an einen Agenten vollzogen haben,
verarbeitet sie letzterer, während die Mittel eine weitere Anforderung
an einen weiteren Agenten leiten können, der dann seine
Verarbeitung parallel zum ersten Agenten ausführt. Aus Sicht des
Management-Systems verarbeitet die Vorrichtung gemäß der
Erfindung mehrere Anforderungen simultan. Dieser letztgenannte
Vorteil ist vor allem dann bedeutsam, wenn sich die
Verarbeitung der Anforderungen für bestimmte Objekte als lang erweist.
-
Die nachfolgende Beschreibung, die auf die beigefügte
Zeichnung Bezug nimmt, die beispielhaft und nicht erschöpfend
gegeben ist, macht deutlich, wie die Erfindung ausgeführt sein
kann.
-
Fig. 1 zeigt schematisch ein Ausführungsbeispiel der
Datenverarbeitungsvorrichtung gemäß der Erfindung.
-
Fig. 2 zeigt ein Beispiel eines komplexen Netzes, das von
einem einzigen Management-System gesteuert wird.
-
In Fig. 1 wurde ein Beispiel einer Architektur der Vorrichtung
zur Informationverarbeitung IPD gemäß der Erfindung
vorgeschlagen. Im allgemeinen basieren die Vorrichtungen IPD, die
vom Fachmann auch Agenten genannt werden, wie auch die
Management-Systeme auf einem Modell von Verwaltungsobjekten, das
erlaubt, die reale Welt (Systeme, Kommunikationssoftware usw.)
mittels abstrakter Objekte darzustellen, die in einer
Management-Informationsdatenbank, gewöhnlich MIB genannt,
organisiert sind. In einem bevorzugten Anwendungsbeispiel der
vorliegenden Erfindung ist das Management-System von einer
Gruppe von Anwendungen gebildet, die Operationen nach dem OSI-
CMSI-Modell (Common Management Information Service) nutzen, um
die Objekte der MIBs zu bearbeiten, die von verschiedenen
Arten von Agenten wie z. B. DSAC-Agenten (Modell, das
entsprechend der durch die Firma BULL verbreiteten Architektur
ausgearbeitet wurde), SNMP-Agenten und CMIP-Agenten (Common
Management Information Protocol) unterstützt werden.
-
Diese verschiedenen Agenten sind auf verschiedene Modelle von
Objekten aufgesetzt, folglich muß das Management-System mit
Hilfe von Komponenten, die Integrations-Agenten genannt
werden, eine Konvertierung zwischen dem Objektmodell ISO und dem
für das betreffende Netz spezifischen Objektmodell vornehmen.
-
Wie dies zuvor dargelegt wurde, nutzen die SNMP-Agenten ein
von der IETF definiertes Management-Protokoll. Dieses
Protokoll ist entworfen worden, um lediglich grundlegende
Management-Mittel bereitzustellen, wobei es einerseits auf einem
begrenzten Management-Service, der nur vier einfache
Funktionen (GET, SET, GET-NEXT, TRAP) benutzt, und andererseits auf
einem einfachen Objektmodell beruht.
-
Um die Steuerung des TCP/IP-Protokolls zu ermöglichen, wurde
in gleicher Weise eine Standard-MIB definiert, die jedoch auf
experimentelle und/oder individuelle Weise erweitert werden
kann. Die gebräuchliche Version dieser MIB wurde MIB II
getauft.
-
Die benutzten Erweiterungsmechanismen haben die Definition und
den Betrieb verschiedener eigener MIBs, die typischerweise
Netzvorrichtungen wie Gateways, Router, Zentralrechner,
Verdichter usw. betreffen, zum Gegenstand.
-
Gegenwärtig verleitet die stetig wachsende Anzahl von
Ausführungen von Management-Systemen und SNMP-Agenten die Anwender
des SNMP-Managements zur Ausweitung komplexerer Bereiche wie
des Systemmanagements, ja sogar der Anwendungen.
-
Wie dies zuvor in verallgemeinerter Form erwähnt worden ist,
kommunizieren im vorliegenden Beispiel die SNMP-Agenten mit
dem Management-System über den Integrations-Agenten, hier vom
Typ SNMP, der das Objekt und die SNMP-spezifische Operationen
in ein Objektmodell oder CMIS-Standard-Operationen
konver
tiert. Auf diese Weise werden die CMIS-Operationen, die zur
Ausführung von Anforderungen, die von Anwendungen gesendet
wurden, notwendig sind, in SNMP-Operationen konvertiert und zu
dem betreffenden Agenten geschickt. Genauso wird, wenn eine
Antwort erhalten wird, diese ebenfalls in eine Antwort auf
eine entsprechende CMIS-Operation konvertiert und zur
betreffenden Anwendung zurückgeschickt. Zudem werden Funktionen vom
Typ Meldung (TRAP-Funktionen) in Warnungen konvertiert und an
die Kommunikationsinfrastruktur übertragen.
-
SNMP-Objekte werden im Management-System durch eine MIB nach
einem OSI-Standard dargestellt. Das bekannte "mappage"-Prinzip
besteht darin, Klassen von verwaltenten Objekten zu
definieren, um Gruppen, Tabellen und Tabellen-Eingaben zu
charakterisieren, wobei die übrigen SNMP-Objekte Attribute
dieser Klassen gemanagter Objekte sind.
-
Die Vorrichtung IPD ist demnach in einem Datenverarbeitungs-
Betriebsmittel RES implantiert, um über ein
Standard-Managementprotokoll SNMP und über das Netz TCP/IP den Dialog
zwischen dem System für das Management von Objekten MAN (mit
Fig. 2 genauer beschrieben) und dem Betriebsmittel RES zu
gestatten. Gemäß dem Erfindungsgedanken zeichnet sich die
Vorrichtung IPD dadurch aus, daß sie einerseits aus Mitteln
zur Lenkung und Steuerung des Dialogs DIS, die unter anderem
eine Konfigurationsdatei CF enthalten, und andererseits aus
einer Gesamtheit von Standard-Agenten A1, A2, ..., An gebildet
ist, die für das Management-Protokoll SNMP spezifisch sind,
das auch in der Vorrichtung IPD verwendet wird, wobei jeder
Agent A1, A2, ..., An eine Gesamtheit von Objekten
unterstützt, wobei die Mittel DIS Anforderungen SNMP. REQ vom
Management-System MAN empfangen und sie nach dem Lesen der
Konfigurationsdatei CF in Abhängigkeit vom Objekt, auf das sie sich
beziehen, an einen oder mehrere geeignete Agenten (A1,
A2, ..., An) lenken und dann die Antworten SNMP. RES auf die
Anforderungen von dem oder den geeigneten Agenten (A1,
A2, ..., An) empfangen und sie an das System MAN übermitteln.
-
Eine solche Architektur der Vorrichtung IPD hat zur Folge, daß
das Management-System MAN die Mittel DIS wie einen
SNMP-Standard-Agenten sieht und die Existenz verschiedener Agenten A1,
A2, ..., An vollständig außer Acht lassen kann. Nur die Mittel
DIS kennen die Agenten A1, A2, ..., An und übermitteln ihnen
selektiv die Anfragen, indem sie jede von ihnen an den (oder
die) betreffenden Agenten lenken. Die Mittel DIS nutzen dazu
die Konfigurationsdatei CF, die vorteilhafterweise eine
Tabelle enthält, die die verschiedenen Objekte beschreibt, die
in den Agenten mit ihren entsprechenden Adressen unterstützt
werden. Diese Tabelle wird beim Hochfahren der Mittel DIS
aufgebaut. Zudem kann jeder Agent unter Nutzung der Funktion
TRAP eine Warnung SNMP.TR übermitteln.
-
Gemäß einem Merkmal der Erfindung enthält die
Konfigurationsdatei CF außerdem einen Zeitgeber, dessen Dauer für jeden
Agenten einstellbar und an die Objekte angepaßt ist, auf die
sich die Anforderungen beziehen. In der Tat kann, wenn das
System MAN eine Anforderung an einen oder mehrere betreffende,
das betreffende Objekt oder die betreffenden Objekte
unterstützenden Agenten sendet, die Zeit, um die Antwort zu
erhalten, variabel in Abhängigkeit vom Objekt oder von den Objekten
sein, auf die sich die Anforderung bezieht. Ebenso ist die
Verarbeitung dann, wenn ein Agent eine Anforderung empfängt,
wobei er sich z. B. unter Nutzung eines anderen Protokolls an
andere Geräte wenden und folglich einen Netzzugang verlangen
muß, komplizierter, ferner ist die Zeit bis zur Antwort auf
diesen Anforderungstyp offensichtlich viel länger. Deswegen
ist die Zeitüberwachung, die einstellbar sein muß, in der
Konfigurationsdatei für jeden Agententyp festgelegt.
-
Die Vorrichtung gemäß der Erfindung ermöglicht darüber hinaus,
verschiedene spezifische Probleme zu lösen. So kann eine
Anforderung, die vom System MAN stammt, im einfachsten Fall
ein Objekt oder mehrere Objekte betreffen, die vom selben
Agenten unterstützt werden; diese Anforderung wird dann nach
dem Lesen der Konfigurationsdatei CF zu dem betreffenden
Objekt oder zu den betreffenden Objekten gelenkt. Die
Anforderung des Systems MAN kann jedoch auch mehrere Objekte
betref
fen, die von verschiedenen Agenten unterstützt werden. Der
Fall ist demnach schwieriger zu behandeln, da es notwendig
ist, die Anforderungen an verschiedene betreffende Agenten zu
schicken und sich die verschiedenen Antworten zurückzuholen,
um daraus eine Antwort zu bilden und diese an das System MAN
zu übermitteln. Durch die Struktur der Vorrichtung gemäß der
Erfindung wurde das Problem vorteilhaft gelöst, so daß die
Vorrichtung IPD ermöglicht, eine Anforderung vom System MAN,
die sich auf mehrere von verschiedenen Agenten unterstützte
Objekte bezieht, wie folgt zu bearbeiten: Die Mittel DIS
lenken die Anforderung an das erste betreffenden Objekt am
ersten betreffenden Agenten und dann nacheinander an die
übrigen betreffenden Objekte, die in den übrigen Agenten
gehalten werden, wobei sie, nachdem sie die verschiedenen
Antworten von mehreren von verschiedenen Agenten gehaltenen
Objekten empfangen hat, diese Antworten in einer einzigen
Antwort auf die Anforderung des Management-Systems vereinigt,
die dann als einzige Antwort an das Management-System MAN
übermittelt wird.
-
Ein anderes Problem tritt auf, wenn das System MAN eine
Anforderung sendet, die sich auf die Suche des folgenden Objekts
bezieht, z. B. mit Hilfe der Grundfunktion GET NEXT, und wenn
dieses folgende Objekt das erste ist, das vom folgenden
Agenten gehalten wird, da die Gesamtheit der vom vorhergehenden
Agenten gehaltenen Objekte bereits durchlaufen ist. In diesem
speziellen Fall erlaubt die außerordentliche Struktur der
Vorrichtung IPD ebenfalls, dieses Problem der automatischen
Suche vorteilhaft zu lösen, denn das Lesen der
Konfigurationsdatei CF gibt unmittelbar darüber Auskunft, wohin die
Anforderung zu richten ist, und erlaubt, sie zu dem entsprechenden
Agenten, der das betreffende Objekt unterstützt, zu lenken.
-
Die Vorrichtung IPD ist demzufolge aus zwei verschiedenen
Teilen gebildet. Der erste Teil setzt sich aus von den Agenten
A1, A2, ..., An vollkommen unabhängigen Mitteln DIS zusammen,
deren Hauptfunktionen darin bestehen, das Codieren und
Decodieren der Anforderungen nach dem SNMP-Protokoll, die
Zugangsoperationen für die Übertragung der Anforderungen und die
Haupt-Programmschleife, die den Empfang der Anforderungen
ermöglicht, auszuführen. Der zweite Teil entspricht
verschiedenen MIBs, die von den Agenten A1, A2, ..., An gehalten
werden und deren Betrieb in der Fachsprache Objekt-Methode
genannt wird.
-
Eine solche ihrer Struktur nach modulare Architektur erlaubt
ohne Schwierigkeiten, neue Agenten und folglich neue MIBs zu
entwickeln oder bereits existierende MIBs gleich welcher
benutzten Technologie leicht zu integrieren, wenn der
entwickelte oder integrierte Agent den Spezifikationen des SNMP-
Protokolls entspricht.
-
Um die Entwicklung und das Betreiben von MIBs zu vereinfachen,
um ihre Integration in ein beliebiges verwaltetes
Betriebsmittel zu ermöglichen und um faktisch die Fähigkeit zur
Zusammenarbeit mit dem Management-System zu sichern, wird
vorteilhafterweise ein Verfahren zum Betreiben von Agenten der
Vorrichtung IPD genutzt.
-
Nach diesem Betriebsverfahren wird in einem ersten Schritt die
Gesamtheit von zu unterstützenden verwalteten Objekten
definiert, in einem zweiten Schritt wird diese Gesamtheit von
Objekten auf das betreffende Datenverarbeitungs-Betriebsmittel
bezogen, in einem dritten Schritt wird die Gesamtheit von
Objekten entworfen und gestartet, in einem vierten Schritt
wird die Gesamtheit von Objekten lokal getestet, in einem
fünften Schritt wird die Gesamtheit von Objekten in Dienst
genommen und daher vom Management-System unterstützt, in einem
sechsten Schritt wird der die Gesamtheit von Objekten haltende
Agent in die Gesamtheit der übrigen Agenten der
Datenverarbeitungsvorrichtung integriert, nachdem in der
Konfigurationsdatei Mittel zur Lenkung und Steuerung des Dialogs beschrieben
worden sind, in einem siebenten Schritt wird die Fähigkeit zur
Zusammenarbeit zwischen dem Management-System und dem in
dieser Weise integrierten Agenten getestet, während der letzte
Schritt die Validierung dieses so entworfenen und getesteten
Agenten ermöglicht.
-
Demnach besteht der erste Schritt darin, den neuen Agenten
oder die neue MIB, die in die Gesamtheit der existierenden
Agenten integriert werden soll, zu definieren. In dem vorn der
IETF definierten Standard deckt eine MIB nur das Management
von TC/IP-Protokoll-Schichten und ihrer nahen Umgebung ab,
außerdem ist es, damit das Management anderer Funktionen
übernommen werden kann, im allgemeinen notwendig, neue Gruppen
von Objekten zu definieren, die dann entweder als
"individuelle" MIBs oder als "experimentelle" MIBs betrachtet
werden. Da jedoch eine große Anzahl von Rechnerherstellern und
Lieferanten von Netzausrüstungen selbst solche MIBs
definieren, um das Management ähnlicher Produkte zu ermöglichen, ist
es mitunter möglich, ihre Integration ausgehend von
veröffentlichten MIBs zu realisieren und sie in einer Schlußphase so zu
bearbeiten, daß sie die Forderungen und folglich die
Spezifikationen des benutzten Protokolls vollkommen erfüllen. In
jedem Fall muß das zu verwaltende Betriebsmittel analysiert
werden, um die typischen und treffenden Merkmale zu bestimmen,
von denen ein Modell erstellt werden kann, das konform zu dem
für das benutzte Protokoll aufgestellte Objektmodell ist, so
daß eine genaue Funktionssicht aus der Perspektive des
Managements geboten wird.
-
Der Schritt der Definition der MIB, der im wesentlichen die
funktionale Analyse des zu modellierenden Betriebsmittels und
die Prüfung der auszuführenden Verarbeitung betrifft, sollte
vorzugsweise von der Gruppe abgesichert werden, die mit dem
Management des Betriebsmittels beauftragt ist, insbesondere
sollte die Beschreibung der MIB in einem dem Protokoll
entsprechenden Format durchgeführt werden, um die Übereinstimmung
mit der Verarbeitung zu verifizieren.
-
Der zweite Schritt dieses Verfahrens bezieht sich auf die
Berührungsstelle, also auf die Anpassung des Agenten an das zu
verwaltende Betriebsmittel. Die praktische Umsetzung der MIB
in dem Betriebsmittel setzt allerdings die Existenz einer
Vorrichtung IPD voraus.
-
Der dritte Schritt betrifft die Konzeption und die
Inbetriebnahme der Objektmethoden.
-
Der vierte Schritt besteht in einem lokalen Test des Agenten
mit Hilfe von Befehlen, die die Übertragung von Anforderungen
nach dem vorgesehenem Protokoll gestatten, wobei diese Befehle
entweder vom Betriebsmittel selbst oder vom Management-System
über Auswahlanwendungen ausgesendet werden können, wenn die
MIB erst einmal in dem entsprechenden Format beschrieben
worden ist (in diesem Fall nach dem fünften Schritt).
-
Der fünfte Schritt betrifft die Inbetriebnahme der MIB durch
das Management-System, wofür die Objekte der MIB in dem
entsprechenden Format beschrieben sein müssen, damit sie von den
Anwendungen des Management-Systems gehandhabt werden können.
Eines der Werkzeuge des Management-Systems ermöglicht, die MIB
in eine entsprechende MIB im Standardformat zu konvertieren.
-
Nachdem lokal getestet und validiert worden ist, wird der die
Gesamtheit von Objekten haltende Agent und demzufolge die MIB
in einem sechsten Schritt in die übrigen Agenten der
Vorrichtung IPD integriert. Die einzige zur Ausführung dieser
Integration erforderliche Operation besteht darin, die von dem
Agenten gehaltene MIB in der Konfigurationsdatei CF der Mittel
DIS zu beschreiben.
-
Der siebente Schritt ermöglicht, die Fähigkeit zur
Zusammenarbeit zwischen dem Management-System und dem Agenten zu testen,
wobei für diesen Test Informationen in beiden Richtungen
ausgetauscht werden, während im achten und letzten Schritt der
so entworfene und getestete Agent nicht nur lokal, sondern
global in einer Umgebung, die das
Datenverarbeitungs-Betriebsmittel und das Management-System enthält, validiert wird.
-
Ein Beispiel eines komplexen Netzes, das von einem einzigen
Management-System MAN gesteuert wird, wurde mit Fig. 2
vorgeschlagen. Vorzugsweise wird das Management-System MAN in einer
Umgebung des verteilten Managements genutzt, die das
Manage
ment von Systemen, Netzen und Nutzeranwendungen integriert. In
diesem Beispiel ist das System MAN eine ISM-Plattform
(Integrated System Management), die eine zentralisierte
Managersicht über alle Betriebsmittel des Netzes und Aktivitäten
oder Bewegungen im Netz, d. h. einerseits die
Netzinfrastruktur bezüglich der Ausrüstung und der Software und andererseits
die Datenverarbeitungssysteme bezüglich der Hardware, der
Betriebssysteme und der Anwendungen, liefert.
-
Im allgemeinen schlägt das integrierte Management der ISM-
Systeme Management-Anwendungen vor, die die Analyse und
Kontrolle dieser Betriebsmittel und Funktionen, die erforderlich
sind, um sie an die Bedürfnisse der Anwender anzupassen,
ermöglichen und auf Management-Informationen beruhen, die von
spezifischen, Agenten genannten Managementeinheiten der
Betriebsmittel erarbeitet und unterstützt werden. Die Agenten
kommunizieren mit der ISM-Plattform und folglich mit dem
System MAN über Standard-Managementprotokolle.
-
Im Beispiel der Fig. 2 sind die durch ISM unterstützten
Management-Protokolle das SNMP-, das CMIP- und das DSAC-Protokoll
(wegen der Kompatibilität zu früheren Produkten und der
verteilten Architektur von BULL).
-
Wenn also im allgemeinen eine Managementkomponente genutzt
werden soll, ist es notwendig, einen Agenten zu entwerfen und
in Betrieb zu nehmen, um die Managementobjekte zu
unterstützen, die er enthält, wobei dieser Agent entweder das SNMP-
Protokoll oder das CMIP-Protokoll benutzt, um mit der ISM-
Plattform und folglich mit dem Management-System MAN zu
kommunizieren.
-
Viele Betriebsmittel können in der vorliegenden Anwendung des
integrierten Managements von ISM-Systemen über ein
SNMP-Protokoll gesteuert werden, so z. B. die TCP/IP-Dateien, die durch
die Gesamtheit von Objekten, die nach dem von der IETF
definiertem Standard MIB II bezeichnet wurde, repräsentiert
werden, verschiedene Systemen wie GCOS7 oder GCOS8 oder Systeme
unter UNIX (geschützte Marke von UNIX System Laboratories
Inc.), Arbeitsgruppenserver, Datenbanken wie ORACLE (Marke der
ORACLE Corporation) usw.
-
Gemäß der vorliegenden Erfindung können Betriebsmittel, die
ohne Beziehung zur spezifischen Architektur des integrierten
System-Management ISM sind, ebenfalls gesteuert werden, sobald
sie den Spezifikationsanforderungen des benutzten Standard-
Protokolls, wie hier SNMP, nachkommen. So steuert die ISM-
Plattform, d. h. das System MAN alle steuerbaren
Betriebsmittel, die sich an das SNMP-Protokoll halten, etwa Rechner oder
Einrichtungen wie Router, Gateways usw., die entweder
Standardobjekte oder individuelle Objekte, also eigene MIBs,
nutzen. In dem vorliegenden Beispiel werden folglich "ISM-
Agenten" oder "Nicht-ISM-Agenten" gesteuert, die beide
gleichzeitig vorhanden sind und in das gleiche Betriebsmittel
integriert werden können, wenn sie konform zum SNMP-Protokoll
sind. Darüber hinaus muß jeder Anwender individuelle MIBs
entwerfen und betreiben können, um z. B. seine eigenen
Anwendungen zu verwalten, ohne insoweit den "ISM-Agenten",
wenigstens in bezug auf den Quellcode, ändern zu müssen.
-
Das Verfahren zum Betreiben eines Agenten trägt den
Anforderungen bezüglich der Verarbeitung Rechnung, um einerseits
Entwicklungen zu unterstützen, die autonom durchgeführt
wurden, jedoch sich entsprechende MIBs betreffen, und
andererseits die Integration von verschiedenen SNMP-Agenten zu
ermöglichen, die aus auf dem gleichen Betriebsmittel getrennt
erfolgten Entwicklungen hervorgehen.
-
Das in Fig. 2 dargestellte Management-System MAN verwaltet
eine Gesamtheit von Betriebsmitteln RES1, RES2, ..., RES6 in
verschiedenen Netzen und nach verschiedenen Protokollen. Das
System MAN hat eine einheitliche Betrachtungsweise der
Gesamtheit der Betriebsmittel und/oder Anwendungen des komplexen
Netzes, da jedoch die verschiedenen Vorrichtungen IPD und die
verschiedenen Agenten auf der Basis verschiedener
Objektmodelle entworfen sind, muß das System MAN mit Hilfe von
Integrations-Agenten eine Konvertierung zwischen dem
ISO-Objektmodell und den für die betreffenden Netze spezifischen
Objektmodellen ausführen. So führt in unserem Beispiel der
Integrationsagent CMIP AI eine Konvertierung des Objektmodells nach dem
CMIP-Protokoll über das OSI-Netz aus; der Integrations-Agent
SNMP AI ermöglicht die Konvertierung des Objektmodells nach
SNMP über das TCP/IP-Netz und der Integrationsagent DSAC A1
erlaubt die Konvertierung des Objektmodells nach dem DSAC-
Protokoll über das DSA-Netz. Auf diese Weise wird das
Betriebsmittel RES1, z. B. eine Brücke, über das TCP/IP-Netz
nach dem SNMP-Protokoll verwaltet, wobei der Dialog mit dem
System MAN gemäß dem Erfindungsgedanken über die
Datenverarbeitungsvorrichtung SNMP IPD ermöglicht wird. Das
Betriebsmittel RES2, beispielsweise ein System unter UNIX, das
jedoch nicht das in den Dienstprogrammen ISM integrierte
Management benutzt, enthält ebenfalls eine Vorrichtung
SNMP IPD, die die Dialogführung mit dem System MAN über das
Netz TCP/IP nach dem SNMP-Protokoll ermöglicht. Das
Betriebsmittel RES3 kann ein System unter UNIX sein, das das
in den ISM-Systemen integrierte Management benutzt und
einerseits eine Vorrichtung SNMP IPD für die Dialogführung mit
dem System MAN über das TCP ITP-Netz nach SNMP-Protokoll und
andererseits eine Vorrichtung CMIP IPD für die Dialogführung
mit dem System MAN über das OSI-Netz nach CMIP-Protokoll
besitzt. Das Betriebsmittel RES4 ist beispielsweise ein
beliebiges Datenverarbeitungssystem, das die CMIS-Dienste
nutzt und eine Vorrichtung CMIP IPD für den Dialog mit dem
System MAN über das Netz OSI nach dem CMIP-Protokoll besitzt.
Das Betriebsmittel RES5 kann einem DSA-Knoten wie DATANET
entsprechen, es besitzt für die Dialogführung mit dem System
MAN über das DSA-Netz nach DSAC-Protokoll eine Vorrichtung
DSAC IPD. Schließlich kann in Fig. 2 das Betriebsmittel RES6
ein Host-System, beispielsweise ein DPS7, sein, das einerseits
eine Vorrichtung DSAC IPD für die Dialogführung mit dem System
MAN über das Netz DSA nach dem DSAC-Protokoll und andererseits
eine Vorrichtung SNMP IPD für die Dialogführung mit dem System
MAN über das Netz TCP/IP nach dem SNMP-Protokoll nutzt.
-
Abzuschließend sei angemerkt, daß die
Datenverarbeitungsvorrichtung IPD wie auch das Verfahren zum Betreiben der Agenten
zur Integration in die Vorrichtung, so wie sie beschrieben und
beansprucht wurden, in direkter und vorteilhafter Weise
nutzbar sind. Die Implantation der Vorrichtung gemäß der Erfindung
in jedes zu managende Betriebsmittel ermöglicht dem Anwender
des Management-Systems eine einheitliche Darstellung der
komplizierten zu managenden Umgebung. Auf diese Weise könnte
z. B. ein Anwender von einem Bildschirm aus verschiedene
Elemente bearbeiten, ohne selbst zu wissen, ob diese ein
TCP/IP-Netz, ein OSI-Netz oder ein DSA-Netz betreffen.
Folglich ist ein einziges Management-System notwendig, wobei die
einheitliche Gestaltung des Netzes dadurch erfolgen kann, daß
Agenten nach dem vorliegenden Verfahren zum Betreiben
entwickelt und mühelos in die Vorrichtung gemäß der Erfindung
integriert werden, ohne dazu an eine bestimmte Verfahrensweise
gebunden zu sein.