-
Technisches
Gebiet
-
Diese
Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung zum Überwachen
des Auftretens von Ereignissen, die die Verfügbarkeit von Diensten beeinträchtigen
können
(wie z. B. von elektronischer Post und Druckspulen), die durch ein
Computersystem bereitgestellt werden sollen, und zum Identifizieren
und Implementieren einer korrigierenden Aktion, die erforderlich
sein kann, um Auswirkungen solcher Ereignisse zu beheben. Insbesondere
aber nicht ausschließlich
bezieht sich die vorliegende Erfindung auf ein Verfahren und eine
Vorrichtung zum Überwachen
von Ereignissen und zum Implementieren von erforderlichen Aktionen
im Hinblick auf Dienste, die auf einem Computernetzwerk bereitgestellt
werden.
-
Hintergrund
der Technik
-
Die
Komplexität
von Computersystemen und Netzwerken von Computersystemen hat sich
unerbittlich erhöht,
sodass solche Systeme nun üblicherweise
durch das Vorhandensein und die Wechselwirkung von großen Anzahlen
von Systementitäten
gekennzeichnet sind, die eine Vielzahl von Systemdiensten bereitstellen. Dies
hat wiederum den Systemverwaltungsressourcen eine große Belastung
auferlegt, die erforderlich sind, um eine kontinuierliche Verfügbarkeit
von Systemdiensten beizubehalten, z. B. in Verbindung mit der Erfassung
von Fehlern und der Identifikation und Korrektur ihrer Ursachen.
-
Eines
der frühesten
Expertensysteme, das zu diesem Problempunkt des Erfassens und Diagnostizierens
von Computeropera tionen in einem System adressiert wurde, ist beschrieben
in dem IBM JOURNAL OF RESEARCH AND DEVELOPMENT, Januar 1986, USA,
Bd. 30, Nr. 1, ISSN 0018-8646, Seiten 14–28, ENNIS R L u. a. Ein kontinuierliches
Echtzeit-Expertensystem für
Computeroperationen. Hier übt
ein kontinuierliches Echtzeitexpertensystem eine aktive Steuerung über ein
Rechensystem aus und liefert Anweisungen für Computeroperatoren. Es liefert
Anweisungen über
Routineoperationen und erfasst, diagnostiziert und antwortet auf Probleme
in dem Bereich des Computeroperators.
-
Ein
anderer Beitrag zur Lösung
dieses Problems wurde offenbart in der WO 94/09427, die ein Systemverwaltungsverfahren
und eine -vorrichtung beschreibt, bei der ein entsprechendes deklaratives
Modell für
jeden Systemdienst bereitgestellt wird. Dieses Modell spezifiziert,
unabhängig
von einer bestimmten Aufgabe, die in Verbindung mit diesem System
durchgeführt
werden soll, die Anforderungen oder Ziele, die für diesen Dienst erfüllt werden
müssen,
um verfügbar
zu sein, im Hinblick auf die erforderlichen Entitäten und
ihre Zwischenbeziehungen. Ein jeweiliges Aufgabenprogramm wird für jede Aufgabe
geliefert, wie z. B. Installation, Überwachung und Fehlerdiagnose,
zum Steuern des Verhaltens dieser Aufgabe auf eine Weise unabhängig von
einem bestimmten Modell, im Hinblick auf allgemeine Folgerungsoperationen,
die an einem solchen Modell durchgeführt werden können. Aufgaben
werden im Hinblick auf einen Dienst durchgeführt (z. B. Fehlerfindung im
Hinblick auf einen nicht operativen Druckspuldienst), durch Bewirken
von Folgerungsoperationen an einem deklarativen Modell in Bezug
auf diesen Dienst unter der Steuerung des Aufgabenprogramms für diese Aufgabe.
-
Bei
einer Implementierung der Erfindung, die in der WO 94/09427 offenbart
ist, werden Informationen über
das System verfügbar
gemacht, durch Bezugnahme auf eine Faktenbasis, die Fakten über das
System speichert und die durch eine Wechselwirkung mit dem System
aktualisiert werden kann, um gewünschte
Informationen zu liefern, entweder direkt durch Abfragen, um spezifische
Informationen abzurufen, oder indirekt durch Folgern von diesen
Informationen. Eine Folgerungsmaschine prüft, ob eine Anforderung oder
ein Ziel, das einem Dienst zugeordnet ist, durch das System erfüllt wird,
durch Durchführen
von Folgerungsoperationen an dem relevanten Dienstmodell und durch
Bezugnahme auf die Faktenbasis, und in dem Fall, dass nicht ausreichende
Fakten in der Faktenbasis vorliegen, durch Verursachen einer Wechselwirkung
mit dem System, um weitere Fakten abzurufen.
-
Bei
dem Verfahren und der Vorrichtung, wie in der WO 94/09427 beschrieben
ist, wird die Operation der Folgerungsmaschine ausgelöst durch
eine Anforderung, eine Verwaltungsaufgabe durchzuführen, üblicherweise
auf Anforderung eines Benutzers, um die Dienste des Systems zu modifizieren,
oder um die Ursache eines Dienstausfalls zu identifizieren.
-
Es
ist eine Aufgabe dieser Erfindung, ein Verfahren und eine Vorrichtung
zu schaffen, die ermöglichen, dass
Verwaltungsaufgaben automatisch initiiert werden, z. B. ansprechend
auf eine Erfassung von Ereignissen, die eine mögliche Änderung in dem Systemstatus
anzeigen.
-
Offenbarung
der Erfindung
-
Gemäß einem
Aspekt dieser Erfindung wird ein Systemverwaltungsverfahren zum Überwachen
des Auftretens von und Versuchen des Beseitigens von Auswirkungen
von Ereignissen geschaffen, die einen Dienst beeinträchtigen,
der durch ein Computersystem bereitgestellt werden soll, das aus
zusammenwirkenden physischen und logischen Entitäten besteht, wobei das Verfahren
folgende Schritte aufweist: Bereitstellen eines Vereinbarungsmodells
für den
Dienst, das Anforderungen spezifiziert, die erfüllt werden müssen, damit der
Dienst verfügbar
ist, wobei die Anforderungen im Hinblick auf die Entitäten aufgezeigt
sind, die benötigt werden,
und auf ihre Zwischenbeziehungen; Spezifizieren eines Ziels im Hinblick
auf zumindest einen Aspekt des Dienstes, das durch das System erfüllt werden
soll, und Speichern des Ziels in einem Zielspeicher; Bereitstellen
einer Faktenbasis zum Halten von Fakten, die sich auf das System
beziehen; Identifizieren von zumindest einem Faktum, das sich auf
das System bezieht und von dem das Ziel abhängt, und Einfügen dieses
Faktums in die Faktenbasis; Bestimmen, ob das Ziel erfüllt wird,
und dadurch Einrichten von zumindest einer Verknüpfung, die eine Abhängigkeitsbeziehung
zwischen dem Ziel und dem zumindest einen Faktum anzeigt, und Einfügen der
Verknüpfung
in die Faktenbasis; Definieren von zumindest einem Ereignis, das
in dem System auftreten kann und dessen Auftreten in dem System
die Gültigkeit
des Faktums beeinträchtigen
kann; und Erfassen des Auftretens des Ereignisses, und daraufhin:
Bestimmen, ob das Faktum gültig
oder ungültig
ist; wenn das Faktum ungültig
geworden ist, Bestimmen, ob das Ziel weiterhin erfüllt wird,
durch Durchführen
von Folgerungsoperationen an dem Vereinbarungsmodell durch Bezugnahme
auf die Faktenbasis, um sicher zu stellen, ob eine Anforderung,
die für
das Ziel relevant ist, durch das System erfüllt wird; wenn das Ziel nicht mehr
erfüllt
wird, Suchen einer Operation, die ermöglicht, dass das Ziel wieder
erfüllt
wird; wenn das Ziel wieder erfüllt
wird, Testen, ob die Operation ermöglicht, dass das Ziel wieder
erfüllt
wird, durch temporäres
Aktualisieren der Faktenbasis, um Konsequenzen des Bewirkens dieser
Operation anzuzeigen, und Bestimmen, ob das Ziel erfüllt wird,
durch Bezugnahme auf die Faktenbasis in ihrem temporär aktualisierten
Zustand; und Durchführen
der Operation, wenn das Ziel wieder erfüllt wird.
-
Gemäß einem
anderen Aspekt der Erfindung wird eine Systemverwaltungsvorrichtung
zum Beobachten des Auftretens von und zum Versuchen des Beseitigens
von Auswirkungen von Ereignissen geschaffen, die einen Dienst beeinträchtigen,
der durch ein Computersystem bereitgestellt werden soll, das aus
zusammenwirkenden physischen und logischen Entitäten besteht, wobei die Vorrichtung
folgende Merkmale aufweist: ein Vereinbarungsmodell, das Anforderungen
spezifiziert, die erfüllt
werden sollen, damit der Dienst verfügbar ist, wobei die Anforderungen
im Hinblick auf die Entitäten
aufgezeigt werden, die erforderlich sind, und auf ihre Zwischenbeziehungen;
eine Folgerungsmaschine zum Ausführen
von Folgerungsoperationen in Bezug auf das Vereinbarungsmodell;
einen Zielspeicher, der eine Spezifizierung eines Ziels enthält, das
durch das System erfüllt
werden soll, im Hinblick auf zumindest einen Aspekt des Diensts;
eine Faktenbasis zum Halten von Fakten, die sich auf das System
beziehen; eine Identifizierung von zumindest einem Faktum, das sich auf
das System bezieht und von dem System abhängt, wobei das Faktum in der
Faktenbasis umfasst ist; zumindest eine Verknüpfung, die in der Faktenbasis
umfasst ist, wobei die Verknüpfung
eingerichtet wird, durch Bestimmen, ob das Ziel erfüllt ist,
und Anzeigen einer Abhängigkeitsbeziehung
zwischen dem Ziel und dem zumindest einen Faktum; eine Definition
von zumindest einem Ereignis, das in dem System auftreten kann und dessen
Auftreten in dem System die Gültigkeit
des Faktums beeinträchtigen
kann; und die Folgerungsmaschine, die angeordnet ist, um das Auftreten
des Ereignisses zu erfassen, wobei die Folgerungsmaschine folgende Merkmale
aufweist: eine Bestimmungseinrichtung zum Bestimmen, ob das Faktum
gültig
oder ungültig
ist; eine Verursachungseinrichtung, die angeordnet ist, um zu verursachen,
dass die Folgerungsmaschine Folgerungsoperationen an dem Vereinbarungsmodell
ausführt,
um zu verursachen, dass eine Bezugnahme auf die Faktenbasis durchgeführt wird,
um sicher zu stellen, ob eine Anforderung, die für das Ziel relevant ist, durch
das System erfüllt
wird, und um zu bestimmen, ob das Ziel weiterhin erfüllt wird,
wenn das Faktum ungültig
geworden ist; und eine Ermöglichungseinrichtung,
die angeordnet ist, um eine Operation zu suchen, um zu ermöglichen,
dass das Ziel wieder erfüllt
wird, wenn das Ziel nicht mehr erfüllt wird; wobei die Vorrichtung
ferner eine Ausführungseinrichtung
aufweist, zum Ausführen
der Operation.
-
Kurze Beschreibung
der Zeichnungen
-
Ein
Verfahren und ein System gemäß dieser
Erfindung zum Identifizieren von Ereignissen innerhalb eines Computersystems
und zum Implementieren einer korrigierenden Aktion, die erforderlich
sein kann, um Wirkungen solcher Ergebnisse aufzuheben, wird nun
beispielhaft Bezug nehmend auf die beiliegenden Zeichnungen beschrieben,
in denen:
-
1 ein Übersichtsdiagramm
der Systemverwaltungsvorrichtung ist, die die Erfindung verkörpert;
-
2 ein
Diagramm einer Folgerungsmaschine ist, die einen Teil der Vorrichtung
aus 1 bildet;
-
3 ein
Diagramm ist, das das Format einer Abfrage darstellt, die verwendbar
ist, um Informationen aus dem Computersystem zu erhalten, das verwaltet
wird;
-
4 ein
Suchbaum ist, der eine Operation der Folgerungsmaschine aus 2 im
Hinblick auf ein Beispieldienstmodell darstellt, wobei ein Satz
von vorbestimmten Fakten gegeben ist;
-
5 ein
Suchbaum ist, der eine Operation der Folgerungsmaschine aus 2 darstellt,
im Hinblick auf dasselbe Dienstmodell wie für 4, wo Abfragen
verwendet werden, um Fakten aufzurufen; und
-
6 ein
Diagramm ist, das das Format einer Ereignisdefinition darstellt,
die verwendbar ist, um Ereignisse innerhalb des Computersystems
zu definieren, für
die resultierende Wirkungen und eine mögliche korrigierende Aktion
identifiziert werden sollen.
-
Detaillierte
Beschreibung eines Ausführungsbeispiels
der vorliegenden Erfindung
-
1 stellt
in allgemeiner Form die Systemverwaltungsvorrichtung 10 der
vorliegenden Erfindung dar, in Zuordnung zu einem Teil eines Computersystems 12,
dessen Operation mit der Hilfe der Vorrichtung 10 überwacht
wird. Das System weist Arbeitsstationen 14 und Peripheriegeräte auf,
wie z. B. einen Drucker 16, die über ein Netzwerk verbunden
sind, das LAN-Segmente 18 umfasst, die über Brücken 20 verknüpft sind. Ein
Benutzer an einer Arbeitsstation 14 benötigt üblicherweise das System 12,
um ihm/ihr einen von verschiedenen Diensten bereitzustellen, wie
z. B. das Einloggen in das Computersystem, das Betreiben eines bestimmten
Anwendungsprogramms, Druckspulen, elektronische Post und das Ausloggen.
Für jeden
dieser Dienste muss ein Systemverwalter in der Lage sein, eine der
Arbeitsstationen 14 zu verwenden, um eine Vielzahl von
Systemverwaltungsaufgaben durchzuführen, einschließlich der
Installation des Dienstes, einer Konfiguration des Dienstes, einer
Fehlerdiagnose und einer Fehlerbehebung und einer Entfernung des
Dienstes.
-
Die
Systemverwaltungsvorrichtung 10 umfasst einen Satz von
Aufgabenprogrammen 22 (eines für jede der m Aufgaben, die
ausgeführt
werden sollen), einen Satz von Dienstmodellen 24 (eines
für jeden
der n Dienste, die durch das Computersystem 12 bereitgestellt
werden), und ein Verwaltungssystem 26, das durch die Arbeitsstation 14 des
Systemverwalters und eine geeignete Software aufgebaut ist. Die
Aufgabenprogramme 22, Dienstmodelle 24 und Teile
des Verwaltungssystems 26 werden detailliert in der WO
94/09427 erörtert; dementsprechend
werden sie hierin nur zu dem Ausmaß erörtert, der notwendig ist, um
ein ausreichendes Verständnis
der vorliegenden Erfindung zu unterstützen.
-
Jedes
Dienstmodell 24 ist ein Vereinbarungsmodell des betroffenen
Dienstes und spezifiziert die Anforderungen, die erfüllt werden
müssen,
damit der Dienst verfügbar
ist. Diese Anforderungen werden im Hinblick auf die physischen und
logischen Entitäten
des Dienstes ausgeführt,
die dem Dienst zugeordnet sind (wie z. B. Drucker, Modems und Ganzzahlen,
Dateien und Betriebsmodi), und die Beziehungen zwischen diesen Entitäten. Ein
Dienstmodell enthält
keine Informationen darüber,
wie es für
unterschiedliche Verwaltungsaufgaben verwendet werden soll. Jedem
Dienstmodell sind Abfragen 28 und Aktionen 29 zugeordnet.
Abfragen geben detailliert an, wie Informationen im Hinblick auf
die Anforderungen, die für
den betroffenen Dienst spezifiziert sind, durch eine Wechselwirkung
mit dem Computersystem 12 erhalten werden können. Aktionen
geben detailliert an, wie das Ausführen von Verfahren initiiert
werden kann, die sich auf den modellierten Dienst beziehen, und
die erforderlich sein können,
um bestimmte Aufgaben zu implementieren.
-
Wie
hierin verwendet bezieht sich der Ausdruck „Vereinbarungsmodell" auf eine abstrakte
Beschreibung eines Dienstes, wobei die Bedeutung des Modells unabhängig von
einer Form der Verarbeitung ist, der das Modell unterliegen kann;
die Struktur des Modells und die Art und Weise, auf die es verwendet
wird, basieren nicht auf Schreibweisen von Sequenz, Iteration oder
Auswahl (im Gegensatz dazu, was üblicherweise bei
unbedingten Modellen der Fall ist), und statt dessen verwendet das
Modell logische Operatoren (wie z. B. UND, ODER, NICHT) und Rekursion
nach Bedarf. Konzepte von Sequenz, Iteration und Auswahl können in dem
Modell ohne weiteres dargestellt werden, als Teil der Modellierung
des betroffenen Dienstes, aber dies beeinträchtigt nicht das vereinbarende
Wesen des Modells.
-
Das
Verwaltungssystem 26 umfasst eine Inferenz-Maschine oder
einen -Verwalter 30, eine Faktenbasis 32 und einen
Wechselwirkungsverwalter 34. Wenn eine bestimmte Aufgabe unter
der Steuerung von einem der Aufgabenprogramme 22 ausgeführt wird,
verwendet die Inferenzmaschine 30 das Dienstmodell 24 für den Dienst,
im Hinblick auf den die Aufgabe ausgeführt wird, um die Anforderungen
für den
Dienst zu identifizieren, und verwendet dann Informationen, die
demselben verfügbar
sein könnten,
um bestimmte Folgerungen aus diesen Anforderungen zu treffen (insbesondere,
ob sie erfüllt
wurden oder erfüllt
werden müssen).
Die Faktenbasis 32 speichert Fakten, die dem Verwaltungssystem 26 bereits
bekannt sind, und die daher direkt für die Inferenzmaschine 30 verfügbar sind.
Wenn gewünschte
Fakten nicht in der Faktenbasis 32 sind, ist die Inferenzmaschine 30 wirksam,
um die Abfragen 28 zu verwenden, die dem relevanten Dienstmodell 24 zugeordnet sind,
um zu verursachen, dass der Wechselwirkungsverwalter 34 mit
dem Computersystem 12 in Wechselwirkung tritt, im Hinblick
auf das Erhalten der betroffenen Fakten direkt oder indirekt durch
Erfahrung. Ferner, wenn es notwendig ist, das System 12 zu
modifizieren, das verwaltet wird, um eine Aufgabe abzuschließen (z. B.
Installation oder Entfernung eines Dienstes), ist die Inferenzmaschine
wirksam, um zu verursachen, dass geeignete vordefinierte Aktionen 29,
die dem relevanten Dienstmodell 24 zugeordnet sind, über den
Wechselwirkungsverwalter 34 initiiert werden.
-
Durch
Darstellung und Verwenden einer Pseudonatursprache, kann ein Druckspoolerdienstmodell
im Hinblick auf einen Druckspoolerdienst mit Namen IpSpooler spezifizieren,
dass der Dienst bekannterweise verfügbar ist, wenn drei Anforderungen
erfüllt
werden:
IpSpooler-Dienst ist ok, wenn:
- – ein Drucksteuerprogramm
bezüglich
IpSpooler läuft,
und
- – ein
gültiger
voreingestellter Druckerdienst für
IpSpooler spezifiziert ist, und
- – dieser
voreingestellte Druckerdienst momentan in der Lage ist, zu drucken.
-
Die
Existenz und der Status des Drucksteuerprogramms sind üblicherweise
Fakten, die direkt mit Hilfe einer Abfrage erhalten werden können und
dann in der Faktenbasis 32 gespeichert werden. Die Existenz
eines gültigen
voreingestellten Druckerdienstes für IpSpooler kann sichergestellt
werden, und seine Identität
kann über
eine Variable „pname" wie folgt erhalten
werden:
IpSpooler hat eine gültige voreingestellte Druckervorrichtung,
WENN:
- – IpSpooler
einen zugeordneten voreingestellten Drucker hat [Druckername wird
in „pname" eingegeben], und
- – „pname" ein akzeptabler
Druckername ist.
-
Die
Fähigkeit
einer voreingestellten Druckervorrichtung zum Drucken kann in dem
Fall sichergestellt werden, in dem dieselbe direkt mit einer Arbeitsstation 14 wie
folgt verbunden ist:
Drucker kann drucken, WENN:
- – der
Drucker Druckaufträge
akzeptiert, und
- – der
Drucker freigegeben ist.
-
Die
Fähigkeit
des Druckers, Druckaufträge
zu akzeptieren, und seinen Freigegeben/Gesperrt-Status kann sichergestellt
werden mit Hilfe von geeigneten Abfragen. In dem Fall, in dem der
Drucker mit dem Netzwerk 12 verbunden ist und nicht direkt
mit einer individuellen Arbeitsstation, ist das Modell etwas komplexer; in
diesem Fall ist dem physischen Drucker in der Arbeitsstation 14 ein „fiktiver" Drucker zugeordnet
und das Modell wird zu:
Drucker kann drucken, WENN:
- – „fiktiver" Drucker Druckaufträge empfängt, und
- – „fiktiver" Drucker freigegeben
ist, und
- – „fiktiver" Drucker einen physischen
Drucker aufweist, der ihm zugeordnet ist, und
- – dieser
physische Drucker momentan in der Lage ist, zu drucken.
-
Die
Fähigkeit
des physischen Druckers zu drucken kann sichergestellt werden, durch
Anrufen des Drucker-kann-Drucken-Modells
für diese
Vorrichtung; dieses Verfahren wird wenn nötig rekursiv wiederholt, bis
das Drucker-kann-Drucken-Modell
für einen
direkt angeschlossenen Drucker angerufen wird (z. B. für einen
Drucker, der mit einem Druckserver verbunden ist), wobei an diesem
Punkt der Status des Druckers direkt bestimmt wird.
-
Falls
erwünscht
ist, eine Diagnose des Druckspoolerdienstes für einen bestimmten Druckspooler
auszuführen,
verursacht ein Diagnoseaufgabenprogramm 22, dass die Folgerungsmaschine 30 das
Druckspoolerdienstmodell 24 untersucht und alle Anforderungen
identifiziert, die erfüllt
werden müssen.
Zum Beispiel, wenn ein Drucker nicht unter Verwendung des IpSpooler-Druckspoolers
drucken kann, dann gibt das Modell an, dass ein Drucksteuerungsprogramm
im Hinblick auf IpSpooler abgespielt werden muss, eine gültige voreingestellte
Druckervorrichtung für
IpSpooler spezifiziert werden muss (d. h. IpSpooler muss einen zugeordneten
voreingestellten Drucker mit einem akzeptablen Druckernamen haben)
und dass die voreingestellte Druckervorrichtung momentan in der
Lage zum Drucken sein muss (d. h. sie muss Druckaufträ ge annehmen
und freigegeben sein); die Folgerungsmaschine 30 fährt fort,
unter der Steuerung des Diagnoseaufgabenprogramms 22, um
sicherzustellen, welche dieser Anforderungen momentan nicht erfüllt wird.
-
Sollte
es erwünscht
sein, einen neuen Druckspooler zu dem System hinzuzufügen, verursacht
das Konfigurationsaufgabenprogramm 22, dass die Inferenzmaschine 30 das
Druckspoolerdienstmodell untersucht, um zu identifizieren, welche
Anforderungen erfüllt
werden müssen,
dass der neue Druckspooler von anderswo in dem Computersystem 12 verwendbar
ist; diese Anforderungen können
dann durch geeignete Aktionen an dem System erfüllt werden.
-
Die
Aufgabenprogramme 22, Dienstmodelle 24 und Abfragen 28 und
Aktionen 29 werden alle allgemein in einer Sprache auf
hoher Ebene geschrieben und zu einem Objektcode für eine Ausführung kompiliert.
-
Die
allgemeine Form der Folgerungsmaschine 30 ist in 2 dargestellt.
Konzeptuell weist die Folgerungsmaschine eine Aufgabensteuerungsschicht 40 zum
Steuern der Inferenzmaschine gemäß dem Aufgabenprogramm 22 auf,
das zu derselben geliefert wird; ein Beweissystem, aufgebaut aus
einem Verifizierer 42, einem Kenntnisassimilator 44 und
einem Theorembeweiser 46; und eine Logikunterstützungsschicht 48 (die Unifizierung,
Prädikate
und Variablen liefert), bereitgestellt durch eine geeignete Sprache,
wie z. B. Prolog oder Smalltalk, wobei beide derselben Fachleuten
auf dem Gebiet bekannt sind.
-
Im
Hinblick auf das Beweissystem verwendet der Verifizierer 42 ein
Geschlossene-Welt-Vereinbarungssystem, für das, wenn etwas nicht als
wahr bewiesen werden kann, angenommen wird, dass dies falsch ist;
der Verifizierer 42 initiiert keine neuen Abfragen. Der
Verifizierer 42 ist somit nützlich zum Entdecken, was im
Hinblick auf den momentanen Kenntnisstand wahr sein kann. Der Kenntnisassimilator 44 verwendet eine Form
einer Abduktion, um konsistente Erweiterungen für die Faktenbasis 32 zu
finden, die ausreichend sind, um Beobachtungen zu erklären, die
aus den Ergebnissen der Abfragen 28 entstehen. Der Haupttheorembeweiser 46 ist
ein Offene-Welt-Vereinbarungssystem, das ebenfalls Abfragen berücksichtigt;
es ist der Kern der Inferenzmaschine 30. Die Rolle der
Aufgabensteuerung 40 ist das Integrieren der Operation
der Elemente des Beweissystems auf eine Weise, um die Ergebnisse
zu erzeugen, die für
die Aufgabe erwünscht
sind, die bewirkt wird; im Allgemeinen kann jedoch gesagt werden,
wenn der Theorembeweiser 46 nicht in der Lage ist, ein
bestimmtes Theorem auf der Basis von Fakten zu beweisen, die momentan
in der Faktenbasis 32 verfügbar sind, dann fragt er den
Verifizierer 42, die Abfragen 28 zu betrachten,
um eine zu finden, die die gewünschten
Fakten liefert, und dann, so bald ihre Abfrage durchgeführt wurde,
extrahiert der Kenntnisassimilator 44 so viele Informationen
wie möglich
aus den Ergebnissen der Abfrage und speichert diese neuen Informationen
in der Faktenbasis 32 zur Verwendung durch den Theorembeweiser 46.
-
Der
Satz von Abfragen 28, der jedem Modell 24 zugeordnet
ist, ermöglicht,
dass Informationen von dem System 12 erhalten werden, das
verwaltet wird. Jede Abfrage ist „goodfor" (geeignet für) ein oder mehrere Fakten
(d. h. ermöglicht,
dass ein Faktum oder Fakten garantiert werden), und diese Fakten
werden mit der Abfrage identifiziert, um eine Auswahl der Abfrage
zu ermöglichen,
die für
ein gewünschtes
Faktum geeignet ist.
-
Eine
Abfrage funktioniert durch eine Wechselwirkung mit dem System 12,
das verwaltet wird, und dann durch syntaktisches Analysieren der
resultierenden Antwort in Token, die dann auf die Inhalte des zugeordneten
Dienstmodells 24 bezogen werden. Bei dem vorliegenden Ausführungsbeispiel
ist der Wechselwirkungsverwalter 34 verantwortlich für das Ausführen der
Abfrage, während
eine weitere semantische Analyse der Antwort durch den Kenntnisassimilator 44 ausgeführt wird,
der ebenfalls verantwortlich für
das Aktualisieren der Faktenbasis 32 ist.
-
Drei
Haupttypen einer Interaktion sind möglich. Erstens kann eine Abfrage
existierende Informationslieferdienste des Systems 12 verwenden,
um die erforderlichen Informationen direkt zu liefern (obwohl sie
allgemein mit anderen Informationen gepackt sind und eine syntaktische
Extrahierung erfordern). Zweitens kann eine Abfrage eine bestimmte
Fähigkeit
des Systems 12 ausführen,
die, obwohl sie nicht direkt die erforderlichen Informationen liefert,
dem Kenntnisassimilator 44 ermöglicht, bestimmte Fakten aus
den beobachteten Ergebnissen anzurufen. Drittens ist es möglich, spezifische
Agentenprogramme zu schreiben, die auf bestimmten Maschinen des
Systems laufen, das verwaltet wird, und diese Agenten anzuordnen,
um spezifische Antworten auf bestimmte Abfragen zu liefern. Während solche
Agenten leistungsstarke Analysewerkzeuge liefern könnten, hat
der Bedarf zum Hinzufügen
zu dem System, das verwaltet wird, praktische Nachteile, und dieser
Lösungsansatz
wird daher nicht bevorzugt.
-
Das
allgemeine Format einer Abfrage 28 ist in vereinfachter
Form in 3 dargestellt. Der Abfrage 28 ist
ein eindeutiger Name 60 zugeteilt. Die Aktion, die durch
das verwaltete System 12 durchgeführt werden soll, wird in einer
Befehlszeile 62 spezifiziert, die die „commandSpec" (Befehlsspezifikation)
der Abfrage bildet, unter Verwendung einer Syntax, die von dem bestimmten
Befehl oder der Systemverwaltungssprache abhängt, die verwendet wird, die
in einem Präfix
identifiziert ist, gezeigt als [PROTOCOL] in 3. Der verbleibende Teil
der Abfrage ist die „returnSpec" (Antwortspezifikation),
die beschreibt, welche Antwort erwartet werden kann, die aus der
Aktion resultiert, die durch die Befehlszeile 62 initiiert
wird, und wie sich diese Antwort auf die relevanten Inhalte des
zugeordneten Dienstmodells 24 bezieht. Die „returnSpec" gibt die allgemeine
Form der Antwort („returnline" 64) (Antwortzeile) teilweise
von einer Erzeugung genannt RETURN (Antwort) an, die ebenfalls eine
Liste 66 enthält
(bezeichnet als das „completenessPart") (Vollständigkeitsteil),
die die Artikel spezifiziert, für
die vollständige
Informationen verfügbar
sind. Die „returnline" 64 wird
dann syntaktisch spezifiziert (Referenz 68), um eine Anzahl
von „returnParts" (Antwortteilen)
herzuleiten, die dann auf die Inhalte des Dienstmodells bezogen
werden (Referenz 70). Die Fakten, für die eine Abfrage „goodfor" ist, werden implizit in
Abschnitt 70 der Abfrage identifiziert, und üblicherweise
wird eine explizite Liste dieser Fakten erzeugt, wenn die Abfrage
kompiliert wird.
-
Ein
einfaches Beispiel, wie der Theorembeweiser 46 eine Argumentation
auf der Basis der Regeln führt,
die demselben in einem Dienstmodell 24 gegeben werden,
und im Hinblick auf Tatsachen, die in der Faktenbasis 32 verfügbar sind,
wird nun gegeben.
-
Wie
oben beschrieben ist, enthält
jedes Dienstmodell 24 Angaben in Bezug auf die Entität oder Entitäten, die
relevant für
dieses Modell sind, und diese Angaben werden allgemein verwendet,
um eine Anzahl von konditionalen Beziehungen zwischen diesen Entitäten zu bilden,
die z. B. spezifizieren, dass eine Dienstentität verfügbar ist, wenn bestimmte Bedingungen
erfüllt
werden. Somit, Bezug nehmend auf das Dienstmodell 24 aus 2,
können
wahr bewertete Angaben A–H
in dem Dienstmodell in drei Regeln klassifiziert werden:
A
wenn B oder C
B wenn D und E und F
C wenn G oder H
-
Die
Angabe A stellt dar, dass der betroffene Dienst verfügbar ist,
wenn die Angabe B oder die Angabe C wahr sind. Die zweite oben gegebene
Regel gibt dann die Bedingungen an, die erfüllt werden müssen, damit Angabe
B wahr ist, während die
dritte Regel die Bedingungen angibt, damit die Angabe C wahr ist.
-
Es
wird zuerst die Situation betrachtet, in der die Faktenbasis die
Fakten enthält,
dass D, F und G wahr sind, aber E und H falsch sind. Wenn mit den
obigen Regeln und diesen Fakten gearbeitet wird, kann der Haupttheorembeweiser 46 nun
herleiten, ob der Dienst, der durch das Modell 24 dargestellt
ist, verfügbar
ist oder nicht – d.
h., ob A wahr ist. Dieser Beweis wird wie folgt geführt (siehe 4):
- (1) Da kein Faktum für A vorliegt aber eine Regel
vorliegt, weitet sich die Suche nach einer Lösung in zwei Teillösungsknoten
aus.
- (2) Es wird nun B betrachtet. Es gibt wiederum kein Faktum,
aber es gibt eine relevante Regel, sodass die Suche wieder ausgeweitet
wird.
- (3) Es werden nun D, E, F betrachtet. Es gibt ein Faktum für D, sodass
die nächste
Teillösung
Knoten E, F ist.
- (4) Es wird nun E, F betrachtet. E ist als falsch bekannt, somit
fällt dieser
Zweig aus.
- (5) Zurückverfolgen
zu dem nächsten
nicht ausgeweiteten Teillösungsknoten
(d. h., C), es liegt kein Faktum für C vor, aber es gibt eine
Regel, sodass die Suche ausgeweitet wird.
- (6) Es wird nun G betrachtet. Dies ist als wahr bekannt, sodass
eine Lösung
gefunden wurde.
-
Dieses
Beispiel ist eine einfache Tiefe-Erst-Suche über den Lösungsraum. Andere Suchstrategien sind
natürlich
ebenfalls möglich,
wie z. B. eine Strategie „Bestes
zuerst".
-
Es
wird die nächste
Situation betrachtet, wo keine relevanten Fakten in der Faktenbasis 32 sind.
Es ist jedoch ein Satz von Abfragen dem Modell 24 zugeordnet,
wobei zwei Abfragen Q1 und Q2 geliefert werden; die Abfrage Q1 ist „goodfor" (d. h., ergibt den
Wert von) D und E, und Q2 ist „goodfor" F, G und H. In diesem Fall
wird der Beweis wie folgt geführt
(siehe 5):
- (1) Der Beweis von A
beginnt wie zuvor, bis der Teillösungsknoten
D, E, F erreicht ist. Dieses Mal liegt kein Faktum für D vor,
aber eine Abfrage Q1. So wird die Abfrage Q1 ausgeführt und
dies setzt die Fakten „D
ist wahr" und „E ist
falsch" in die Faktenbasis 32,
wodurch ermöglicht
wird, dass der nächste
Teillösungsknoten erzeugt
wird.
- (2) Es werden nun E, F betrachtet. Es liegt nun ein Faktum für E in der
Faktenbasis vor; dieses Faktum (E ist falsch) verursacht, dass dieser
Zweig ausfällt.
- (3) Durch Zurückverfolgen
zu dem nächsten
nicht ausgeweiteten Teillösungsknoten
(d. h. C) wird die Suche wie zuvor fortgesetzt.
- (4) Wenn G betrachtet wird, gibt es kein Faktum für dasselbe,
aber es gibt eine Abfrage Q2. Wenn dies ausgeführt wird, werden die Fakten „F ist
wahr", „G ist
wahr" und „H ist
falsch" zu der Faktenbasis 32 hinzugefügt, was
zu einer Lösung
führt.
-
Die
Auswahl der geeigneten Abfrage und das Extrahieren der Informationen
aus dem Ergebnis einer Abfrage umfassen den Verifizierer 42 und
den Kenntnisassimilator 44.
-
Aktionen
29,
die durchgeführt
werden müssen,
um zu ermöglichen,
dass eine bestimmte Aufgabe fertig gestellt wird, werden für jedes
Dienstmodell im Wesentlichen auf dieselbe Weise definiert wie eine
Abfrage, aber mit einem einfacheren Basisvorrat:
| ACTION | – Aktionsname |
| COMMAND | – Befehlszeile |
| PRE | – Vorbedingungen
für die
Aktion |
| POST | – Nachbedingungen
(d. h. die Wirkung der Aktion) |
| INVALIDATE | – Variablen,
die durch die Aktion ungültig
gemacht werden |
-
Die
Befehlszeile spezifiziert einen Befehl, der direkt durch das System 12 ausgeführt werden
kann, zusammen mit Identifizierern für die Artikel, die bearbeitet
werden sollen (z. B. kann die Befehlszeile eine Variable eines erklärten Typs
enthalten, zum Spezifizieren der Maschine, auf der die Aktion ausgeführt wird).
Die Vorbedingungen, die in PRE spezifiziert sind, sind die Bedingungen,
die wahr sein müssen,
bevor die Aktion ausgeführt
werden kann. Die Nachbedingungen, die in POST spezifiziert sind,
definieren die Wirkung der Aktion; die Inferenzmaschine 30 wird
die Nachbedingungen suchen, wenn sie versucht, die Aktion 29 zu
identifizieren, die geeignet ist zum Bewirken einer bestimmten Aufgabe
in Bezug auf das Dienstmodell 24, für das die Aktion definiert
ist. INVALIDATE identifiziert die Variablen, die durch die Aktion
ungültig
gemacht werden, wobei diese Informationen verwendet werden, um jegliche
Fakten aus der Faktenbasis 32 zu entfernen, die auf den
ungültig
gemachten Artikeln basieren.
-
Wie
vorangehend erklärt
wurde, ist es die Rolle jedes Aufgabenprogramms 22 (1),
die Operation der Inferenzmaschine 30 an die Aufgabe anzupassen,
die durchgeführt
werden soll. Ein Beispieldiagnoseaufgabenprogramm ist nachfolgend
in einer Pseudonatursprachenform für ein leichteres Verständnis gegeben:
-
-
Das
obige Aufgabenprogramm, das in Verbindung mit einem Dienstmodell
verwendet werden kann, sucht nach einer Lösung, ob der betreffende Dienst
(dargestellt durch eine Entität
des entsprechenden Modells) verfügbar
ist. Diese Suche wird durch alle Bedingungen fortgesetzt, die in
der Beziehung spezifiziert sind, die sich auf die relevante Dienstentität beziehen,
bis entweder bewiesen wird, dass eine erforderliche Bedingung nicht
erfüllt
wird, oder bewiesen wird, dass alle Bedingungen erfüllt sind
und der Dienst verfügbar
ist. Beim Durchführen
der Suche nach einer Lösung
können
Abfragen verwendet werden, um Fakten sicherzustellen.
-
Wird
das Diagnoseaufgabenprogramm detaillierter berücksichtigt, wird der Haupttheorembeweiser 46 (2)
zuerst aufgerufen, um nach einer Lösung zu suchen. Wenn während des
Ablaufs dieser Suche der Theorembeweiser 46 nicht in der
Lage ist fortzufahren, da ein erforderliches Faktum nicht in der
Faktenbasis 32 vorhanden ist, dann wird der Verifizierer 42 verwendet,
um eine Abfrage 28 auszuwählen, die das gewünschte Faktum
aus dem System ruft. Die ausgewählte
Abfrage wird dann ausgeführt
(durch den Wechselwirkungsverwalter 34). Wenn die Abfrage
erfolgreich ausgeführt
wird, werden die Ergebnisse aus der Abfrage in die Faktenbasis 32 durch
den Kenntnisassimilierer 44 assimiliert und das Programm
fährt in
der Schleife mit dem Theorembeweiser 46 fort, um seine
Suche unter Verwendung der neu eingerichteten Fakten fortzusetzen. Wenn
jedoch die Abfrage ausfällt
(d. h. nicht erfolgreich ausgeführt
wird), dann wird die Diagnoseaufgabe rekursiv aufgerufen, um den
Grund für
diesen Ausfall festzustellen.
-
Wenn
ein Problem mit einem Dienst vorliegt, der diagnostiziert wird,
endet das obige Diagnoseaufgabenprogramm, wenn der Theorembeweiser 46 zuerst
ein Faktum findet, das beweist, dass eine Anforderung für den Dienst,
der verfügbar
sein soll, nicht erfüllt
wurde. Da diese Fakten, die in die Faktenbasis 32 assimiliert sind,
allgemein Fakten auf niedriger Ebene sind, ist der Abschluss des
Programms auf dieser Stufe normaler Weise akzeptabel, da der Endpunkt
das Faktum auf niedriger Ebene anzeigt, was zu einer Dienstunverfügbarkeit
führt,
und dieses Faktum allgemein ohne weiteres in den betroffenen Computersystemausfall
(einschließlich
der Abwesenheit einer Ressource) übersetzbar ist. Wenn jedoch
die Faktenbasis 32 Fakten auf hoher Ebene speichert, ist
es wünschenswert,
dass das Diagnoseaufgabenprogramm nicht bei einem Faktum auf hoher Ebene
endet, das eine Dienstunverfügbarkeit
beweist, sondern fortfährt,
dieses Faktum zu zerlegen, um die zugrunde liegende Ursache herzuleiten,
wie in einem Faktum auf niedriger Ebene ausgedrückt ist. Dies kann ohne weiteres
erreicht werden durch Einschließen
des obigen Diagnoseaufgabenprogramm in eine „WHILE"-Schleife (SOLANGE-Schleife) der Form:
SOLANGE
eine Ausfallerklärung
möglich
ist FÜHRE
Diagnoseaufgabe
aus
ENDE
-
In
diesem Fall, immer wenn die Kerndiagnoseaufgabe beim Finden eines
Faktums endet, das eine Dienstunverfügbarkeit liefert, wird sie
gefragt, eine Lösung
zu finden, die das Faktum beweist (und sein Vorhandensein in der
Faktenbasis 32 ignoriert). Dieser Prozess wird wiederholt,
bis keine weitere Erklärung
möglich
ist (wie durch die Abwesenheit einer relevanten Abfrage 28 angezeigt
wird).
-
Wenn
die obige zusätzliche
SOLANGE-Schleife nicht auf eine Fehlererklärung eingeschränkt ist,
sondern verwendet wird, um eine Lösung zu erklären, dann
kann die erweiterte Diagnoseaufgabe ebenfalls verwendet werden,
um eine umfassende Prüfung
aller Bedingungen zu liefern (hohe Ebene und niedrige Ebene), die
für einen
bestimmten Dienst erforderlich sind.
-
Ein
weiteres Beispiel eines Aufgabenprogramms ist nachfolgend in Bezug
auf eine Überwachungsaufgabe
gegeben:
-
-
Wie
ersichtlich ist, verwendet die Überwachungsaufgabe
die Diagnoseaufgabe bei dieser Implementierung.
-
Spezifische
Maßnahmen
werden unternommen, um so weit wie möglich die Gültigkeit von Tatsachen zu garantieren,
die in der Faktenbasis 32 gehalten werden. Zum Beispiel
könnte
jeder Abfrage 28 eine „lifetime" (Lebensdauer) zugeordnet werden, die
die Zeit ist, für
die jegliche Fakten, die durch Ausführen der Abfrage hergeleitet
werden, als gültig
betrachtet werden können.
Bei dem Ablauf der Abfragelebensdauer werden alle Vorhaltefakten
(und weitere Fakten, die auf denselben basieren) aus der Faktenbasis 32 gelöscht. Bei
einer solchen Anordnung kann die Überwachung der Systemelemente
implementiert werden durch Verwenden von Abfra gen 28, um
Fakten von diesen Elementen abzuleiten, wobei diese Abfragen eine
Lebensdauer aufweisen, die dem Überwachungsintervall
entspricht; nachdem eine solche Abfrage das Ende ihres Lebens erreicht,
werden die Fakten von Interesse aus der Faktenbasis 32 entfernt,
und dies kann durch die Überwachungsaufgabe
als ein Auslöser
zum erneuten Initiieren der entsprechenden Abfrage 28 verwendet
werden.
-
Weitere
Details des Systems, das so weit beschrieben wurde, sind gegeben
in der WO 94/09427 (hierin durch Bezugnahme aufgenommen), insbesondere
in Bezug auf den Inhalt von Dienstmodellen 24 und Abfragen 28.
-
Die
Systemverwaltungsvorrichtung, die in der WO 94/09427 beschrieben
ist und oben zusammengefasst ist, ist in der Lage, die Operation
des Computersystems 12 zu analysieren, und z. B. ansprechend
auf einen Eingriff durch den Systemverwalter (durch Aktivieren des
Diagnoseaufgabenprogramms 22) dienstbezogene Anforderungen
zu lokalisieren und identifizieren, deren Abwesenheit einen Ausfall
eines Systemdienstes verursacht.
-
Zusätzlich dazu
ermöglicht
die Einrichtung zum periodischen erneuten Ausführen einer Abfrage 28, wie
oben beschrieben ist, ansprechend auf das Ablaufen der Lebensdauer
der Abfrage und das Löschen
der daraus hergeleiteten Fakten aus der Faktenbasis 32 z.
B., dass der Status der Systemelemente auf einer kontinuierlichen
Basis überwacht
wird, und entweder derart bestätigt
wird, dass er weiterhin verfügbar
ist oder berichtet wird, dass derselbe eine Abhilfeaufmerksamkeit
durch den Systemverwalter benötigt,
wenn eine erneute Ausführung
der Abfrage keine Fakten mehr ergibt, die ermöglichen, dass die Verfügbarkeit
des Dienstes bewiesen wird.
-
Es
hat sich jetzt jedoch als wünschenswert
herausgestellt, zusätzliche
Einrichtungen in der Systemverwaltungsvorrichtung 10 bereitzustellen,
um die Fähigkeit
des Systems zu verbessern, Änderungen
bei dem Status des Systems zu erfassen und die Möglichkeit einer automatischen
Neukonfiguration zu liefern, um gegenteilige Wirkungen solcher Änderungen
aufzuheben.
-
Zu
diesem Zweck, wie in 1 gezeigt ist, umfasst das Verwaltungssystem 26 der
Vorrichtung gemäß dieser
Erfindung ebenfalls einen Residente-Ziele-Speicher 102.
Dieser Speicher enthält
Erklärungen
von Zielen, die das System weiter erreichen sollte, und die das
Verwaltungssystem verifizieren sollte, dass sie weiterhin erreicht
werden können,
nach dem Auftritt von Ereignissen, die diese Ziele beeinträchtigen
könnten.
Die Ziele hängen üblicherweise
von Fakten auf niedriger Ebene in der Faktenbasis 32 ab.
Ein Bericht des Auftretens eines Ereignisses enthält Informationen,
aus denen ein oder mehrere dieser Fakten auf niedrigerer Ebene bestätigt oder
bestritten werden können;
wenn ein Faktum bestritten wird, wird ein darauf folgendes Aktualisieren
der Faktenbasis 32 im Hinblick auf dieses Faktum eine erneute
Bewertung auslösen,
ob ein Ziel, das von diesem Faktum abhängt, erfüllt werden kann.
-
Ein
Beispiel eines residenten Ziels ist die fortgesetzte Verfügbarkeit
des Druckspoolerdienstes IpSpooler, der vorangehend erörtert wurde,
dessen Definition dem Inhalt des Dienstmodells für diesen Dienst entspricht,
d. h. (in Pseudonatursprache):
IpSpooler-Dienst ist ok WENN:
- – ein
Drucksteuerprogramm im Hinblick auf IpSpooler läuft, und
- – eine
gültige
voreingestellte Druckervorrichtung für IpSpooler spezifiziert ist,
und
- – diese
voreingestellte Druckervorrichtung momentan in der Lage zu drucken
ist.
-
Die
Basisfakten, von denen dieses Ziel abhängt, umfassen das fortgesetzte
Abspielen des Drucksteuerprogramms, die fortgesetzte Fähigkeit
der relevanten Druckervorrichtung, Druckaufträge zu akzeptieren und den fortgesetzten
freigegebenen Status dieser Druckervorrichtung. Wenn ein residentes
Ziel erstmals in den Residentes-Ziel-Speicher 102 durch
den Systemverwalter eingegeben wird, unter Verwendung der Arbeitsstation 14,
versucht die Inferenzmaschine 30, zu beweisen, dass das
Ziel erfüllt
werden kann, durch Bezugnahme auf das Dienstmodell 24,
die Faktenbasis 32 und unter Verwendung von Abfragen, wie
oben beschrieben wurde. Im Lauf dieses Beweises werden Verknüpfungen
zwischen dem Ziel in dem Residentes-Ziel-Speicher 102 und
den Basisfakten eingerichtet, von denen derselbe abhängt, in
der Faktenbasis 32; um jedoch Systemressourcen zu bewahren,
müssen
Verknüpfungen
mit jeglichen Zwischenfakten, die die Basisfakten auf das Ziel beziehen
(wie z. B., dass der voreingestellte Drucker in der Lage zu drucken
ist), nicht gespeichert werden.
-
Zusätzlich dazu
wird das relevante Dienstmodell 24 ausgeweitet, um eine
Definition von einem oder mehreren Ereignissen 104 zu enthalten,
deren Auftreten ein Faktum in der Faktenbasis 32 bestätigen oder
bestreiten kann. Diese Ereignisse könnten das Anhalten eines Drucksteuerprogramms
umfassen (falls IpSpooler von dem Steuerprogramm abhängt), und
ein Signal, dass ein Drucker seinen Status auf gesperrt verändert hat (falls
dies der voreingestellte Drucker für IpSpooler ist), und diese
Ereignisse wären
in dem Druckspoolerdienstmodell umfasst.
-
Das
allgemeine Format der Definition eines Ereignisses 104 ist
in 6 dargestellt, und ist in vielerlei Hinsicht ähnlich zu
dem Format einer Abfrage 28. Dem Ereignis wird ein eindeutiger
Name 160 zugeteilt. Das tatsächliche Wesen des Ereignisses
wird in einer Identifikationszeile 162 identifiziert, unter
Verwendung einer Syntax, die von dem bestimmten verwendeten Befehl
oder der Systemverwaltungs sprache abhängt, die selbst in einem Präfix identifiziert
ist, gezeigt als [PROTOCOL] in 6. Somit,
wenn ein SNMP (Simple Network Management Protocol) verwendet wird,
könnte
diese Zeile wie folgt lauten
SNMP ::= '.1.3.6.1.4.1.11.2.3.9.1.1.2.17.0'
wo die Zeichenfolge
der Stellen ein Ereignis gemäß SNMP-Konventionen definiert.
Eine Quellzeile 163 identifiziert die Netzwerkentität (z. B.
eine Druckervorrichtung), der das Ereignis in Frage zugeordnet ist.
Der verbleibende Teil des Ereignisses ist die „returnSpec", die beschreibt,
welche Informationen als verfügbar
in Verbindung mit dem Ereignis erwartet werden können, das in der Identifikationszeile 162 identifiziert
ist, und wie sich diese Informationen auf die relevanten Inhalte
des zugeordneten Dienstmodells 24 beziehen. Die „returnSpec" gibt die allgemeine
Form der Informationen („returnline" 164) teilweise
von einer Produktion genannt RETURN an, die ebenfalls eine Liste 166 enthält (bezeichnet
als der „completenessPart"), die die Artikel
spezifiziert, für
die vollständige
Informationen verfügbar
sind (wie z. B. Anzeigen, dass wenn keine spezifische Anzeige vorliegt,
dass eine Behauptung wahr ist, angenommen werden kann, dass sie
definitiv falsch ist). Die „returnline" 164 wird
dann syntaktisch spezifiziert (Referenz 168), um eine Anzahl
von „returnParts" herzuleiten, die
dann auf die Inhalte des Dienstmodells bezogen werden (Referenz 170).
Die Fakten, die aus den Informationen hergeleitet werden können, die
für das
Ereignis verfügbar
sind, werden implizit in dem Abschnitt 170 der Abfrage
identifiziert und können
extrahiert werden durch Anwendung eines geeigneten Parsers, wie nachfolgend
beschrieben wird.
-
Wenn
Ereignisse spezifiziert werden, zum Überwachen durch den Systemverwalter,
wird der Bedarf des Auftretens dieser Ereignisse, die dem Verwaltungssystem 26 berichtet
werden sollen, aufgezeichnet. In dem Fall einer Vorrichtung oder eines
Dienstes, der das SNMP unterstützt,
kann dies durchgeführt
werden durch Registrieren des Bedarfs zum Berichten des Ereignisses
mit der Vorrichtung oder dem Dienst (z. B. kann der Bedarf zum Berichten
einer Statusänderung
auf gesperrt mit einer Druckervorrichtung registriert werden, die
SNMP unterstützt).
Wenn eine Systementität
selbst nicht die Fähigkeit
hat zum Registrieren des Bedarfs zum Berichten von Ereignissen (z.
B. ein einfacher Desktopcomputer), kann das Ereignis statt dessen
mit einem Systemereignismonitor einer bekannten Art registriert
werden, der das System nach vordefinierten Ereignissen überwacht
und einen Bericht liefert, wenn er ihr Auftreten erfasst.
-
Nach
dem Auftreten eines Ereignisses wird ein Nachrichtenbericht durch
die Vorrichtung oder den Dienst in Frage, oder durch den Systemereignismonitor,
zu dem Wechselwirkungsverwalter 34 gesendet. Diese Nachricht
weist eine Syntax auf, die durch das verwendete Protokoll bestimmt
wird (z. B. SNMP), und wird durch den Wechselwirkungsverwalter 34 inspiziert,
um die Art der umfassten Nachricht zu identifizieren. Diese Informationen
werden dann zu der Inferenzmaschine 30 weitergeleitet.
-
Der
Kenntnisassimilator 44 in der Inferenzmaschine 30 empfängt die
Ereignisnachricht von dem Wechselwirkungsverwalter 34 und
wendet eine semantische Analyse an die Nachricht an, um Fakten in
der Faktenbasis 32 zu identifizieren, auf die sich die
Nachricht bezieht. Zu diesem Zweck enthält der Kenntnisassimilator 44 gespeicherte
Modelle von typischen Nachrichten und Tabellen von Schlüsselwörtern und
Merkmalen, die in diesen Nachrichten auftreten können. Ein Vergleich der empfangenen
Nachricht mit diesen Modellen und Tabellen ermöglicht es dem Kenntnisassimilator,
einen geeigneten Parser auszuwählen,
der der Struktur der Nachricht entspricht, mit dem er die Nachricht
analysiert, um sie in ihre Bestandelemente zu unterteilen und die
Basisfakten zu identifizieren, die sie enthält (z. B. das Faktum, dass
ein Drucker seinen Status auf gesperrt geändert hat).
-
Diese
extrahierten Basisfakten werden zu der Faktenbasis 32 geliefert,
um ihre Inhalte zu aktualisieren. In dem Fall von Fakten, die bestritten
wurden und von denen eines oder mehrere Ziele abhängen, verursachen
Verknüpfungen
zwischen den aktualisierten Fakten und Zielen in dem Residente-Ziele-Speicher 102, dass
die Inferenzmaschine 30 wiederum versucht, zu beweisen,
dass jedes betroffene residente Ziel weiterhin erfüllt wird;
dieser versuchte Beweis umfasst eine Zusammenarbeit des Verifizierers 42,
dem Kenntnisassimilator 44 und dem Haupttheorembeweiser 46,
wenn nötig
unter Verwendung von Abfragen, auf dieselbe Weise, wie oben beschrieben
wurde. Wenn das residente Ziel weiterhin erfüllt wird, wird keine weitere
Aktion benötigt.
-
Wenn
der Versuch durch die Inferenzmaschine 30, die Erfüllung eines
Ziels zu beweisen, nach dem Auftreten eines Ereignisses fehlschlägt, dann
versucht diese Maschine, eine oder mehrere Aktionen 29 zu identifizieren,
die, wenn sie ausgeführt
werden, zu der Erfüllung
des Ziels auf unterschiedliche Weise führen. Somit, wenn sich das
Ereignis z. B. darauf bezieht, dass die voreingestellte Druckervorrichtung
IpSpooler ihren Status auf gesperrt ändert, wobei in diesem Fall
das residente Ziel von IpSpooler nicht erfüllt werden kann, wie offensichtlich
ist, kann es möglich
sein, das Ziel wieder zu erfüllen,
durch Ändern
der voreingestellten Druckervorrichtung, um einen anderen Drucker
auszuwählen,
der freigegeben ist.
-
Zu
diesem Zweck enthält
die Inferenzmaschine 30 ferner einen Planer 50 und
einen Simulator 52. Unter der Koordination der Aufgabensteuerungsschicht 40 untersucht
der Planer 50 die Aktionen 29, die in dem relevanten
Dienstmodell 24 enthalten sind, wobei solche gesucht werden,
deren Wirkung ermöglicht,
dass das residente Ziel erfüllt
wird. Für
jede Aktion prüft
der Planer zuerst seine Vorbedingungen gegenüber den Inhalten der Faktenbasis 32,
um zu prüfen,
dass die notwendigen Bedingungen für diese Aktion, die ausge führt werden
soll, wahr sind. Ist dies der Fall, ändert der Simulator 52 temporär und umkehrbar
die Faktenbasis 32 gemäß den Wirkungen,
die in den Nachbedingungen definiert sind, die der Aktion zugeordnet
sind, um die Bedingungen zu simulieren, die nach der Ausführung dieser
Aktion existieren würden.
Der Verifizierer 42, der Kenntnisassimilator 44 und
der Haupttheorembeweiser 46 testen dann wiederum, ob das
residente Ziel nun erfüllt
werden würde.
Wenn der Test nicht erfolgreich ist, werden die temporären Änderungen
an der Faktenbasis 32 umgekehrt, und eine andere Kandidatenaktion
wird getestet. Wenn eine Kombination von Aktionen gefunden wird,
die potenziell relevant für
das residente Ziel in Frage ist, untersucht die Inferenzmaschine 30 ihre
Vor- und Nach-Bedingungen,
um die wirksamste Sequenz zum Ausführen dieser Aktionen zu bestimmen.
-
Wenn
die Inferenzmaschine 30 erfolgreich eine geeignete Aktion
oder Kombination von Aktionen lokalisiert, verursacht sie, dass
der Wechselwirkungsverwalter 34 diese Aktionen an dem Computersystem 12 ausführt, wodurch
die nötigen
eigentlichen Änderungen
bei der Konfiguration des Systems verursacht werden, um das residente
Ziel wieder zu erfüllen.
Andererseits, wenn keine geeignete Aktion oder Kombination von Aktionen
gefunden werden kann, kann das oben beschriebene Diagnoseaufgabenprogramm
aufgerufen werden, um eine Beschreibung von Gründen zu liefern, warum das
residente Ziel nicht länger
erfüllt
werden kann.
