-
HINTERGRUND
DER ERFINDUNG
-
Die Erfindung bezieht sich auf das Überwachen
von Vorgängen
in einem Computersystem. Genauer gesagt bezieht die Erfindung sich
auf ein Verfahren zum Überwachen
eines Computervorganges bzw. -prozesses, auf eine Überwachungseinrichtung
zum Überwachen
eines ComputervorS1 ganges, auf ein Verwaltungssystem für die Konfiguration
eines Computersystems und auf ein Computersystem, welches einen
Computersystemprozeß und/oder
einen verwalteten Prozeß bzw.
Vorgang beinhaltet.
-
Die Erfindung hat ihre besondere,
jedoch nicht ausschließliche
Anwendung in der Überwachung
eines Vorgangs bzw. Prozesses, der Daemon (CMSD) eines Konfigurationsverwaltungssystems
(CMS) genannt wird. Ein Daemon stellt eine Hintergrunddienstleistung
in einem Computersystem bereit. Ein CMSD verwaltet verschiedene
Systemeinheiten oder bjekte, die physikalische Geräte oder
auch Softwareeinheiten sein könnten.
In einem speziellen Beispiel ist ein CMSD über eine UNIX-Buchse über eine
Anwendungsprogrammschnittstelle (API) mit Anwendungsprogrammen verbunden
(UNIX ist eine registrierte Marke in den Vereinigten Staaten und
anderen Ländern,
die ausschließlich
durch die X/Open Company Ltd. lizenziert wird). Das Verhalten des
CMSD wird unter Verwrendung von CMS-Definitionen (CMSDEFs) spezifiziert.
Eine CMSDEF enthält Erklärungen für Objekte
bzw. Gegenstände,
die durch den CMSD verwaltet werden, Zustandsauswertungen (Feststellungen
bzw. Aussagen zum Auswerten der Zustände von Objekten) und Übergangscode,
der ausgeführt
wird, wenn zwischen Zuständen
eines Objektes ein Übergang
erfolgt.
-
Die CMSDEFs kann man sich ähnlich wie
einen Satz von Zustandsmaschinen für die zu verwaltenden Objekte
vorstellen und der CMSD handhabt bzw. steuert die Zustandsmaschinen
(bzw. führt
diese aus).
-
Wie schon erwähnt, arbeitet ein Beispiel
eines CMS als ein Daemon (d. h. es führt eine Verwaltungsdienstleistung
im Hintergrund zu). Wenn der CMSD-Dienst nicht mehr verfügbar ist,
so können
zumindest bestimmte Teile der Betriebsweise des Computersystems
möglicherweise
beeinträchtigt
sein. Wenn beispielsweise in einem bestimmten Beispiel eines CMSD
für die
Verwendung in einem fehlertoleranten Computersystem der CMSD-Dienst
nicht mehr verfügbar
ist, so kann die Fehlertoleranz gefährdet bzw. beeinträchtigt sein. Dementsprechend
ist es erforderlich, den CMSD zu überwachen, um sicherzustellen,
daß im
Falle seines "Todes" bzw. Ausfalls während des
Betriebs irgendeine Korrekturaktion eingeleitet wird.
-
In einem früheren Beispiel eines CMSD für ein fehlertolerantes
Computersystem, welches unter dem Betriebssystem UNIX lief, wurde
eine einfache Überwachungseinrichtung
bereitgestellt. Diese Überwachungseinrichtung
war so ausgestaltet, daß sie
in einer UNIX-Prozeßtabelle
nach dem Namen des CMSD-Prozesses gesucht hat. Wenn die Prozeßtabelle
keinen Prozeß mit
diesem Namen mehr enthielt, so erzeugte die Überwachungseinrichtung eine
Fehlernachricht. Selbstverständlich
würde ein
Vorgang, der als ein CMSD maskiert ist oder ein Tochterprozeß eines
CMSD oder selbst ein nicht funktionierender CMSD, der noch nicht
aus der Prozeßtabelle
herausgelöscht
worden ist, eine solche Überwachungseinrichtung
zufriedenstellen. Zusätzlich bestand
bei dem früheren
Beispiel einer CMSD-Überwachungseinrichtung
die einzige angebotene Einrichtung in der Anzeige des "Todes" bzw. Ausfalls des
CMSD, ohne daß irgendeine
Wiederherstellung bewirkt wurde. Im Ergebnis war es für den Benutzer
bzw. eine Bedienperson erforderlich, den CMSD manuell erneut zu
starten.
-
Ein Ansatz für die Prozeßüberwachung könnte auf
einem System beruhen, das einen Mutter-Tochter-Ansatz für die Pnozeßerzeugung
implementiert, beispielsweise nach Art eines Betriebssystems im UNIX-Stil.
Mit einem solchen Ansatz würde
ein überwachter
Prozeß durch
eine Prozeßübenwachungseinrichtung
in Form eines weiteren Prozesses erzeugt werden, der immer als Mutter
des überwachten
Prozesses agiert. Dies würde
dem Überwachungsprozeß einen
direkten Zugriff auf Information über den überwachten Prozeß gewähren und
würde üblicherweise
beinhalten, daß es
durch das Betriebssystem von dem Tod des überwachten Prozesses informiert
wird. Die Zuverlässigkeit
einer direkten Mutter-Tochter-Beziehung legt jedoch dem ganzen System
Beschränkungen
auf. Außerdem
könnte
der überwachte
Prozeß auf
eine Art und Weise versagen, die durch das Betriebssystem seiner
Mutter nicht mitgeteilt werden würde.
Ein System, welches nach diesem Schema entwickelt wurde, wird durch
Koved L. et al. beschrieben in "Improving
Availability of Software Subsystems Through On-Line Error Detection", IBS Systems Journal,
IBM Corp. Armonk, US, Band 25, Nr. 1, 1986 S. 105–114. In
dem Text "Operating
Systems: Design and Information",
Prentice-Hall, 1987,
von A. Tannenbaum, in Abschnitt 1.4 "System Calls", S. 21–36, werden Einzelheiten des
Erzeugens und Beendens von Systemprozessen bzw. -vorgängen beschrieben.
-
Dementsprechend besteht ein Ziel
der Erfindung darin, eine Prozeßübenwachung
mit einem höheren Maß an Zuverlässigkeit
bereitzustellen, als es mit früheren
Ansätzen
erreichbar ist, während
dennoch eine flexible Betriebsweise und, soweit möglich, ein
automatischer Neustart eines überwachten
Prozesses gewährleistet
wird, der ausgefallen bzw. fehlerhaft ist.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Besondere und bevorzugte Gesichtspunkte
der Erfindung sind in den beigefügten
unabhängigen
und abhängigen
Ansprüchen
dargelegt.
-
Gemäß einem Aspekt der Endung wird
ein Verfahren zum Überwachen
eines Prozesses in einem Computersystem unter Verwendung einer Prozeßüberwachungseinrichtung
(in den Ansprüchen
als Prozeßmonitor
bezeichnet) bereitgestellt, bei welchem der überwachte Prozeß nicht
eine Tochter der Prozeßüberwachungseinnichtung
ist; das Verfahren weist die Schritte auf: eindeutiges Bestimmen
der Identität
eines überwachten
Prozesses und Verifizieren des korrekten Betriebes des überwachten
Prozesses; bei Abwesenheit einer Verifizierung des korrekten Betriebes
des überwachten
Prozesses Bewirken, daß der überwachte
Prozeß erneut
startet, und eindeutige Selbstidentifizierung des überwachten
Systems gegenüber
dem Computersystem beim erfolgreichen Neustart.
-
Gemäß einem weiteren Aspekt der
Erfindung wird ein Computersystem bereitgestellt, welches einen zu überwachenden
Prozeß aufweist,
wobei der zu überwachende
Prozeß nach
seiner erfolgreichen Initiierung so ausgestaltet ist, daß er sich
gegenüber
dem System eindeutig selbst identifiziert, und es wird eine Prozeßüberwachungseinrichtung
bereitgestellt, welche so ausgestaltet ist, daß sie in eindeutiger Weise
die Identität eines überwachten
Prozesses bestimmt, um die korrekte Arbeitsweise des überwachten
Prozesses zu verifizieren, und, für den Fall, daß sie nicht
in der Lage ist, einen korrekten Betrieb eines überwachten Prozesses zu verifizieren,
zu bewirken, daß der überwachte
Prozeß erneut
startet, wobei der überwachte
Prozeß keine Tochter
der Prozeßüberwachungseinrichtung
ist, und wobei der überwachte
Prozeß beim
erfolgreichen Neustart sich gegenüber dem System eindeutig selbst
identifiziert.
-
Es versteht sich, daß, soweit
auf den Neustart eines Prozesses Bezug genommen wird, dieses sich auf
das Starten eines neuen Prozesses oder einer aktualisierten bzw.
verbesserten Version eines Prozesses oder auf das erneute Starten
eines existierenden Prozesses beziehen kann, je nachdem, was passend
bzw. angemessen ist. Das Überwachen
von Prozessen nach Art einer Ausführungsform der Erfindung bedeutet, daß es nicht
erforderlich ist, sich auf eine Mutter-Tochter-Beziehung zu stützen. Dies ermöglicht den
Verzicht bzw. das Abdanken durch einen Prozeß gegenüber einer verbesserten Version
dieses Prozesses, während dennoch
eine Kontinuität
und eine zuverlässige Überwachung
bereitgestellt wird.
-
Gemäß einem weiteren Aspekt der
Erfindung wird ein Computerprogramm bereitgestellt, das eine Prozeßübennrachungseinrichtung
(einen Prozeßmonitor)
für ein
solches Computersystem bildet, wobei die Prozeßüberwachungseinrichtung Programmcode
aufweist, der dafür
ausgelegt ist, in eindeutiger Weise die Identität eines überwachten Prozesses zu identifizieren,
den korrekten Betrieb bzw. Ablauf des überwachten Prozesses zu verifizieren,
und für
den Fall, daß er
nicht in der Lage ist, die korrekte Betriebsweise eines überwachten
Prozesses zu verifizieren, bewirkt, daß der überwachte Prozeß erneut
startet, so daß der überwachte
Prozeß keine
Tochter der Prozeßüberwachungseinrichtung
ist, wobei ein neugestarteter überwachter
Prozeß beim
erfolgreichen Neustart sich in eindeutiger Weise gegenüber dem
Computersystem selbst identifiziert.
-
Gemäß noch einem weiteren Aspekt
der Erfindung wird ein Computerprogramm bereitgestellt, welches
ein Konfigurationsverwaltungssystem für ein solches Computersystem
bildet, wobei das Computerprogramm Programmcode aufweist, der so
ausgestaltet ist, daß er
nach Initiierung durch eine Prozeßüberwachungseinrichtung überprüft, daß er betriebsbereit
ist und, wenn dies der Fall ist, sich in eindeutiger Weise gegenüber dem
Computersystem selbst identifiziert und eine Anzeige seiner Betriebsbereitschaft
an die Prozeßüberwachungseinrichtung
liefert, bevor er sich selbst von der Prozeßüberwachungseinrichtung abtrennt,
um keine Tochter der Prozeßüberwachungseinrichtung
zu sein.
-
Eine Ausführungsform der Erfindung strebt
daher an, eine Lösung
für die
Einschränkungen
der früheren
Ansätze
bereitzustellen, indem eine Prozeßübennrachungseinrichtung bereitgestellt
wird, die eine gesunde (oder erfolgreiche) Betriebsweise eines oder
mehrerer überwachter
Prozesse, die keine Töchter
der Prozeßüberwachungseinrichtung
sind, zu überwachen.
Die Prozeßüber wachungseinrichtung
versucht, einen überwachten
Prozeß in
eindeutiger Weise zu identifizieren. Falls sie damit erfolgreich
ist, so führt
sie Überprüfungen mit
dem Prozeß aus,
um sicherzustellen, daß der
Prozeß weiterhin
arbeitet. Für
den Fall, daß der
Prozeß abgestorben
bzw. ausgefallen ist, startet die Prozeßüberwachungseinrichtung den überwachten
Prozeß erneut. Überprüfungen werden
mit dem überwachten
Prozeß vorgenommen
(beispielsweise kann der überwachte
Prozeß Selbsttests
ausführen),
um sicherzustellen, daß er
fortfahren kann, bevor er gegenüber
dem Überwachungsprozeß anzeigt,
daß er
erfolgreich gestartet ist. Eine Ausführungsform der Erfindung ermöglicht das Überwachen
von Prozessen, ohne sich auf eine Mutter-Tochter-Beziehung zu stützen, und
ermöglicht,
daß neue
oder verbesserte Versionen von Prozessen gestartet werden und für eine Kontrolle
bzw. Steuerung in zuverlässiger
Weise von einem alten Prozeß zu
einem neuen oder verbesserten Prozeß geleitet bzw. übergeleitet
werden.
-
Der Schritt des Bestimmens der Identität eines überwachten
Prozesses kann das Zugreifen auf eine vorbestimmte Datei oder eine
andere Stelle beinhalten, welche die Information über die
Prozeßidentifizierung enthält, welche
für den überwachten
Prozeß eindeutig
ist. Jeder überwachte
Prozeß kann
dafür ausgelegt sein,
daß er
bei bzw. nach seiner Initüerung
seine Information über
die Prozeßidentifizierung
(PID) in die Datei schreibt, so daß sie dann für den Zugriff
durch die Prozeßüberwachungseinrichtung
zugänglich
ist. Wenn die Prozeßüberwachungseinrichtung
nicht in der Lage ist, auf die Datei zuzugreifen oder auf die Datei
zugreift und keine PID für
einen Prozeß vorfindet,
die sie dort vorzufinden erwartet, so hat das keine Information,
die sich auf diese PID bezieht und bewirkt dann, daß der überwachte
Prozeß initiiert
(gestartet) wird.
-
Das Neustarten des überwachten
Prozesses wird vorzugsweise in zwei Schritten bewirkt.
-
Der erste Schritt bewirkt, daß der überwachte
Prozeß mit
dem Start beginnt und Überprüfungen ausführt, um
sicherzustellen, daß er
betriebsbereit ist (d. h. in der Lage ist, erfolgreich ausgeführt zu werden
oder zu funktionieren). Dieses kann beispielsweise beinhalten, daß verifiziert
wird, daß er
in korrekter Weise eine Datenbank bereitstellen kann, die für das Ausführen seiner
verschiedenen Funktionen erforderlich ist. Der überwachte Prozeß kann hinsichtlich
seiner Funktionsfähigkeit
in dieser Stufe sehr kritisch sein, so daß er nicht fortfährt, wenn
es irgendwelche potentiellen Fehler gibt.
-
Wenn der überwachte Prozeß nicht
in der Lage ist, erfolgreich abzulaufen, so können Vortreffungen für einen "handshake" mit der Prozeßüberwachungseinrichtung
getroffen sein, was anzeigt, daß er
nicht ausgeführt
werden kann. Die Prozeßüberwachungseinrichtung
kann so ausgelegt sein, daß sie
für den
Benutzer eine Fehlernachricht ausgibt, welche anzeigt, daß irgendeine
Art von manueller Intervention erforderlich ist, um das Problem
zu beheben, welches bewirkt, daß der überwachte
Prozeß versagt.
Es werden keine weiteren Versuche vorgenommen, den überwachten
Prozeß zu
starten, bis die manuelle Intervention abgeschlossen ist.
-
Alternativ erfolgt, wenn der überwachte
Prozeß in
der Lage war, erfolgreich abzulaufen, der zweite Schritte beim Neustart
des überwachten
Prozesses. Der überwachte
Prozeß schreibt
seine PID in die vorbestimmte Datei und führt dann einen "handshake" mit der Prozeßüberwachungsein richtung
aus, wodurch angezeigt wird, daß er
in der Lage ist, erfolgreich abzulaufen. Die Prozeßüberwachungseinrichtung
fährt dann
fort, den neuen überwachten
Prozeß zu überwachen.
-
Dieser Mechanismus stellt sicher,
daß der Überwachungsprozeß nicht
gewaltsam versucht, einen fehlerhaften überwachten Prozeß zum Laufen
zu bringen. Wenn beispielsweise der überwachte Prozeß ein CMSD
ist und er versucht, mit fehlerhaften CMSDEFs zu arbeiten, so würde der
anfänglich überwachte
Prozeß (CMSD)
mit einer Fehlernachricht an die Prozeßüberwachungseinrichtung abschließen. Die
Prozeßüberwachungseinrichtung
wäre dann
so ausgelegt, daß sie
eine Fehlernachricht ausgibt, um einen Benutzer auf die Tatsache
aufmerksam zu machen, daß der überwachte
Prozeß nicht
läuft.
Ohne den zweistufigen Prozeß könnte der überwachte
Prozeß während des
wiederholten Versuchs, einen CMSD zu starten, der sofort beim Starten
versagt hat, beispielsweise infolge eines Konfigurationsproblems,
zusammenbrechen. Der zweistufige Prozeß vermeidet, daß die Prozeßüberwachungseinrichtung
zwischen einem CMSD, der zufällig
ausgefallen ist, und einem, der immer versagen würde, zu unterscheiden. Es versteht
sich, daß die
Erfindung ihre besondere, jedoch nicht ausschließliche Anwendung auf den Betrieb
eines CMSD als dem überwachten
Prozeß findet.
-
Gemäß einem anderen Aspekt der
Erfindung wird ein ähnlicher
Prozeß wie
bei Beginn eines neuen Prozesses realisiert, wenn ein Prozeß einen
anderen hervorbringt, beispielsweise um Systemveränderungen zu
berücksichtigen.
Ein Beispiel hierfür
ist die Aktualisierung einer Version eines überwachten Prozesses (ein Aktualisierungs-
bzw. Upgradeprozeß),
der einen neuen CMSD initiiert, um Anpassungen an die Veränderungen
der CMSDs anzunehmen. Der alte CMSD und der neue CMSD führen Überprüfungen aus,
um sicherzustellen, daß der
neue CMSD in stabiler Weise laufen kann. Nur wenn dies bestätigt worden
ist, schreibt der neue CMSD seine PID in die PID-Datei und fordert
den alten CMSD auf, aufzuhören
bzw. abzuschließen.
-
In einer besonderen Ausführungsform
der Erfindung schreibt ein CMSD (der überwachte Prozeß) seine
PID in eine Datei, die der Prozeßübennrachungseinrichtung bekannt
ist. Die Prozeßüberwachungseinrichtung
liest diese dann, um in regelmäßigen Abständen auf
die CMSD-Prozeßinformation
aus dem Prozessordateisystem zuzugreifen. Sollte die Prozeßinformation
anzeigen, daß ein
CMSD nicht länger
lebt bzw. aktiv ist, so wird ein Alarm vorgebracht und es wird versucht,
einen neuen CMSD zu erzeugen. Der CMSD bringt sich immer selbst
in den Hintergrund (d. h. er verzweigt und dann endet die Mutter
bzw. der Mutterprozeß),
so daß die Überwachungseinrichtung
nach wie vor nicht die Mutter ist. Um ein Zusammenbrechen des Systems
zu vermeiden (d. h. kontinuierliches Neustarten eines CMSD, der
beispielsweise wegen seiner Konfiguration oder Umgebung nicht in
der Lage ist, zu laufen), führt
der neugestartete CMSD Selbsttests vor, bevor er sich selbst in
den Hintergrund begibt. Mit "sich
selbst in den Hintergrund begeben" ist gemeint, daß er sich von anderen Vorgängen bzw.
Prozessen löst,
um unabhängig
im Hintergrund zu arbeiten. Der Erfolg oder das sonstige Ergebnis
dieser Tests wird an die Überwachungseinrichtung
unter Verwendung des Ausgangscodes der Mutter zurückgegeben
und weitere Neustarts werden unterdrückt, falls diese Tests fehlgeschlagen
sind. Wenn ein erfolgreicher CMSD installiert ist (entweder durch
externen Eingriff oder weil der CMSD durch die Überwachungseinrichtung erfolgreich
neugestartet wurde), wird der Alarm aufgehoben und die Überwachung
wird fortgesetzt. Wenn der CMSD erneuert bzw. aktualisiert werden
muß, so
existiert ein Protokoll, um es einem neuen CMSD zu ermöglichen,
die Übernahme
bzw. den Übergang
von dem alten CMSD ohne Unterbrechung des Dienstes auszuführen. Wenn
dies geschieht, muß die Überwachungseinrichtung
von der Überwachung
des alten CMSD zu der Überwachung
des neuen CMSD in sicherer Weise umschalten. Dies wird erreicht,
indem der neue CMSD seine PID nur dann in die Datei schreibt (zum
Nutzen der Überwachungseinrichtung),
wenn er den Dienst erfolgreich übernommen
hat, und unmittelbar bevor er dem alten CMSD die Anweisung gegeben hat,
abzuschalten.
-
Die Prozeßüberwachungseinrichtung kann
das Betriebssystem abfragen, um einen korrekten Betrieb des CMSD
zu verifizieren. Alternativ könnte
die Prozeßüberwachungseinrichtung
testen, ob der CMSD funktioniert, indem er Dienstleistungsanfragen
an den CMSD richtet. Während
ein solcher Ansatz ein höheres
Maß an
Sicherheit bieten würde
als das Abfragen des Betriebssystems, beinhaltet er auch eine größere Zusatzlast (Overhead)
aufgrund der zusätzlichen
Verarbeitung durch den CMSD.
-
Die Prozeßüberwachungseinrichtung und/oder
der überwachte
Prozeß können in
Form von Computerprogrammen vorliegen, die Computercode oder -anweisungen
aufweisen, welche die Funktionalität der Prozeßüberwachungseinrichtung und/oder
des überwachten
Prozesses definieren.
-
Dementsprechend sieht ein Aspekt
der Erfindung außerdem
ein Trägermedium
vor, welches eine Prozeßeinrichtung
zum Steuern eines für
einen Computer zu überwachenden
Prozesses trägt
bzw. enthält,
wobei die Prozeßeinrichtung
dafür ausgelegt
ist, daß sie,
wenn sie durch eine Prozeßüberwachungseinrichtung
ausgelöst
wird, überprüft, daß sie in
der Lage ist, erfolgreich zu arbeiten und, wenn dies der Fall ist,
eine Anzeige hierüber
an die Prozeßüberwachungseinrichtung
bereitzustellen, bevor sie selbst wieder in den Hintergrund geht.
-
Ein Aspekt der vorliegenden Erfindung
sieht auch ein Trägermedium
für das
Tragen einer Prozeßeinrichtung
vor, um einen zu überwachenden
Prozeß für einen
Computer auszulösen,
wobei die Prozeßeinrichtung
so ausgestaltet ist, daß sie,
wenn sie durch einen existierenden überwachten Prozeß erzeugt
wird, überprüft, daß sie in
der Lage ist, korrekt zu funktionieren und in Reaktion auf ein positives
Ergebnis der Tests sich in eindeutiger Weise für das System selbst identifiziert
und den existierenden überwachten
Prozeß abschließt, wodurch
der neue Prozeß der überwachte
Prozeß wird.
-
Ein Gesichtspunkt der vorliegenden
Erfindung stellt weiterhin ein Trägermedium für das Tragen einer Prozeßeinrichtung
vor, welche dafür
ausgelegt ist, eine Prozeßüberwachungseinrichtung
für einen
Computer zu definieren, wobei die Prozeßüberwachungseinrichtung so konfiguriert
ist, daß sie
in eindeutiger Weise die Identität
eines überwachten
Prozesses bestimmt, um einen korrekten Betrieb des Überwachungsprozesses
zu verifizieren, und um zu bewirken, daß der Prozeß (neu) initiiert wird, falls
sie nicht in der Lage ist, die korrekte Betriebsweise eines überwachten
Prozesses zu verifizieren.
-
Das Trägermedium kann irgendeiner
Art eines Trägermediums
zum Tragen bzw. Übertragen
von Computerprogrammcode sein, sei es magnetisch, optisch oder in
Form eines Datenspeichers, wie z. B. eines Bandes, einer Festplatte,
eines massiven Festkörpers
oder in anderer Form eines Speichermediums, das irgendeinen beliebigen
oder auch einen Nur-Lese- oder eine andere Form eines Zugriffs gewährt, oder
ein Übertragungsmedium,
wie z. B. ein Telefondraht, Radiowellen etc.
-
KURZE BESCHREIBUNG DER
FIGUREN
-
Beispielhafte Ausführungsformen
der vorliegenden Erfindung werden nachstehend lediglich anhand eines
Beispiels beschrieben, wobei auf die begleitenden Zeichnungen Bezug
genommen wird, in welchen gleiche Bezugszeichen sich auf gleiche
Elemente beziehen, und in welchen:
-
1 eine
schematische Übersicht
eines fehlertoleranten Computersystems ist, welches eine Ausführungsform
der Erfindung umfaßt,
-
2 eine
schematische Übersicht
einer speziellen Implementierung eines Systems ist, welche auf demjenigen
gemäß 1 beruht,
-
3 und 4 schematische Darstellungen
von Beispielen von Verarbeitungssätzen sind, 5 ein schematisches Blockdiagramm einer
Ausführungsform
einer Brücke
für das
System nach 1 ist,
-
6 eine
schematische Wiedergabe einer physikalischen Konfiguration eines
Computersystemaufbaus mit austauschbaren Feldeinheiten ist, die
in entsprechenden Steckplätzen
bzw. "Slots" aufgenommen sind,
-
7 eine
schematische Wiedergabe des Konfigurationsverwaltungssystems ist,
welches eine Wiedergabe des physikalischen Aufbaus nach 6 ist,
-
8 ein
Gerätehierarchiemodell
und 9 ein Dienstleistungshierarchiemodell
ist,
-
10 die
Beziehungen zwischen einem Konfigurationsverwaltungssystemdaemon
und weiteren Komponenten des Computersystems zeigt,
-
11, 12 und 13 verschiedene Stufen beim Initiieren
eines Konfigurationssystemdaemons zeigen,
-
14 ein
Flußdiagramm
ist, welches die Betriebsweise einer Prozeßüberwachungseinrichtung zeigt,
-
15 Einzelheiten
des Betriebes der Prozeßübeiwachungseinrichtung
zeigt,
-
16 ein
Flußdiagramm
ist, welches die Übergabe
von einem Prozeß zu
einem anderen veranschaulicht,
-
17 eine
schematische Wiedergabe eines FRU in einem Gehäusesteckplatz (Slot) ist, 18 eine Konfigurationsdatei
wiedergibt,
-
19 ein
Beispiel von CMSDEFs und zugehöriger
Instanzen und Eigenschaften repräsentiert,
und
-
20 ein
Flußdiagramm
ist, welche den Vorgang der Konfigurierung einer FRU zeigt.
-
BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
-
1 ist
eine schematische Übersicht über ein
fehlertolerantes Computersystem 10, welches eine Mehrzahl
von CPU-Sätzen
(Verarbeitungssätzen) 14 und 15 sowie
eine Brücke 12 aufweist.
Wie in 1 dargestellt,
gibt es zwei Verarbeitungssätze 14 und 16,
auch wenn in anderen Ausführungsformen
drei oder mehr Verarbeitungssätze
vorhanden sein können.
Die Brücke 12 bildet
eine Schnittstelle zwischen den Verarbeitungssätzen und I/O-Einrichtungen,
wie z. B. den Einrichtungen 28, 29, 30, 31 und 32.
In der vorliegenden Schrift wird der Begriff "Verarbeitungssatz" verwendet, um eine Gruppe aus einem
oder mehreren Prozessoren zu bezeichnen, die womöglich einen Speicher umfassen,
und die gemeinsame Ausgangsgrößen und
Eingangsgrößen ausgeben
und empfangen. Es sei angemerkt, daß der oben erwähnte Alternativbegriff "CPU-Satz" stattdessen auch
verwendet werden könnte
und daß diese
Begriffe im Rahmen der vorliegenden Schrift austauschbar verwendet
werden können.
Weiterhin sei angemerkt, daß der
Begriff "Brücke" verwendet wird,
um irgendein Gerät,
eine Vorrichtung oder Anordnung zu bezeichnen, die geeignet ist,
zwei oder mehr Busse desselben Typs oder unterschiedlicher Typen
miteinander zu verbinden.
-
Der erste Verarbeitungssatz 14 ist
mit der Brücke 12 über einen
ersten I/O-Bus des Verarbeitungssatzes (PA-Bus) 24 verbunden,
im vorliegenden Fall ein Verbindungsbus für periphere Komponenten (PCI-Bus). Der
zweite Verarbeitungssatz 16 ist mit der Brücke 12 über einen
zweiten I/O-Bus des Verarbeitungssatzes (PB-Bus) 26 desselben
Typs wie der PA-Bus 24 (d. h. hier ein PCI-Bus) verbunden. Die
I/O-Einrichtungen sind mit der Brücke 12 über einen
Geräte-I/O-Bus
(D-Bus) 22 verbunden, im vorliegenden Fall ebenfalls ein PCI-Bus.
-
Auch wenn in dem speziell beschriebenen
Beispiel die Busse 22, 24 und 26 allesamt
PCI-Busse sind, ist
dies lediglich ein Beispiel und es könnten in anderen Ausführungsformen
andere Busprotokolle verwendet werden und der D-Bus 22 könnte ein
gegenüber
dem PA-Bus und dem PB-Bus (P-Bussen) 24 und 26 ein
anderes Protokoll haben.
-
Die Verarbeitungssätze 14 und 16 und
die Brücke 12 sind
synchron unter Steuerung einer gemeinsamen Taktgebung 20 betreibbar,
die mit diesen über
Taktsignalleitungen 21 verbunden ist.
-
Einige der Einrchtungen, welche eine
Ethernet- (E-Net-) Schnittstelle 28 und eine Kleincomputersystemschnittstelle
(SCSI) 29 aufweisen, sind dauerhaft mit dem Gerätebus 22 verbunden,
jedoch könnten
auch andere I/0-Einrichtungen, wie z. B. I/0-Einrichtungen 30, 31 und 32 in
die individuell geschalteten Steckplätze 33, 34 und 35 in
heißem
Zustand (d. h. während
des laufenden Betriebs) einsetzbar sein. Eine dynamische Feldeffekttransistor-
(FET-) Umschaltung kann für
die Steckplätze 33, 34 und 35 vorgesehen
sein, um die Fähigkeit
des Einsteckens der Geräte,
wie z. B. der Geräte 30, 31 und 32,
im "heißen Zustand" zu ermöglichen. Die
Bereitstellung der FETs ermöglicht
eine Steigerung der Länge
des D-Busses 22, da nur diejenigen Geräte, welche aktiv sind, zugeschaltet
sind, was die effektive Gesamtbuslänge reduziert. Es versteht
sich, daß die Anzahl
von I/O-Geräten,
die mit dem D-Bus 22 verbunden werden können, sowie die Anzahl der
Steckplätze (Slots),
die für
sie vorgesehen sind, gemäß einer
bestimmten Implementierung entsprechend den besonderen Modellerfordernissen
eingestellt werden können.
-
2 ist
eine schematische Übersicht
einer bestimmten Implementierung eines fehlertoleranten Computersystems,
welches eine Brückenstruktur
des in 1 dargestellten
Typs verwendet. In 2 umfaßt das fehlertolerante
Computersystem eine Mehrzahl (hier vier) von Brücken 12 auf ersten
und zweiten I/0-Hauptplatinen (Motherboards) (MB40 und MB42), um
die Anzahl von I/O-Geräten, die
angeschlossen werden können,
zu erhöhen,
und um auch die Zuverlässigkeit
und Redundanz zu verbessern. Demnach sind in der in 2 dargestellten Ausführungsform jeweils zwei Verarbeitungssätze 14 und 16 auf
einer entsprechenden Verarbeitungssatzplatine 44 und 46 vorgesehen,
wobei die Verarbeitungssatzplatinen 44 und 46 die
I/0-Hauptplatinen MB40 und MB42 "überbrücken". Eine erste Haupttaktquelle 20A ist
auf der ersten Hauptplatine 40 montiert und eine zweite,
abhängige
Taktquelle 20B ist auf der zweiten Hauptplatine 42 montiert.
Taktsignale werden für
die Verarbeitungssatzplatinen 44 und 46 über entsprechende
Verbindungen (in 2 nicht
dargestellt) zugeführt.
-
Erste und zweite Brücken 12.1 und 12.2 sind
auf der ersten I/O-Hauptplatine montiert. Die erste Brücke 12.1 ist
mit den Verarbeitungssätzen 14 und 16 über P-Busse 24.1 bzw. 26.1 verbunden.
In ähnlicher
Weise ist die zweite Brücke 12.2 über P-Busse 24.2 bzw. 26.2 mit
den Verarbeitungssätzen 14 bzw. 16 verbunden. Die
Brücke 12.1 ist
mit einem I/O-Datenbus (D-Bus) 22.1 verbunden und die Brücke 12.2 ist
mit einem I/O-Datenbus (D-Bus) 22.2 verbunden. Dritte und
vierte Brücken 12.3 und 12.4 sind
auf der zweiten I/O-Hauptplatine 42 montiert. Die Brücke 12.3 ist
mit den Verarbeitungssätzen 14 bzw. 16 durch
P-Busse 24.3 bzw. 26.3 verbunden. In ähnlicher
Weise ist die Brücke 4 mit
den Verarbeitungssätzen 14 bzw. 16 durch
P-Busse 24.4 bzw. 26.4 verbunden. Die Brücke 12.3 ist
mit einem I/O-Datenbus (D-Bus) 22.3 verbunden und die Brücke 12.4 ist mit
einem I/O-Datenbus (D-Bus) 22.4 verbunden.
-
Man kann erkennen, daß die in 2 dargestellte Anordnung
es ermöglicht,
daß eine
große
Anzahl von I/O-Geräten
mit den beiden Verarbeitungssätzen 14 und 16 über die
D-Busse 22.1, 22.2, 22.3 und 22.4 verbunden
werden kann, um entweder den Bereich von verfügbaren I/O-Geräten
zu steigern, oder um ein höheres
Maß an
Redundanz bereitzustellen, oder für beides.
-
3 ist
eine schematische Übersicht
einer möglichen
Konfiguration eines Verarbeitungssatzes, wie z. B. des Verarbeitungssatzes 14 aus 1. Der Verarbeitungssatz 16 könnte dieselbe
Konfiguration haben. In 3 sind
eine Mehrzahl von Prozessoren (hier vier) 52 über einen
oder mehrere Busse 54 mit einer Verarbeitungssatzbussteuerung 50 verbunden.
Wie in 3 dargestellt,
sind einer oder mehrere Verarbeitungssatzausgangsbusse 24 mit
der Verarbeitungssatzbussteuerung 50 verbunden, wobei jeder
Verarbeitungssatz der Ausgangsbusse 24 mit einer entsprechenden
Brücke 12 verbunden
ist. Beispielsweise wäre
in der Anordnung nach 1 nur
ein Verarbeitungssatz-I/O-Bus (P-Bus) 24 vorgesehen, während in
der Anordnung nach 2 vier
derartige Verarbeitungssatz-I/O-Busse (P-Busse) 24 vorgesehen
wären.
In dem in 3 dargestellten
Verarbeitungssatz 14 arbeiten individuelle Prozessoren
unter Verwendung des gemeinsamen Speichers 56 und empfangen
Eingangsgrößen und
stellen Ausgangsgrößen auf
dem bzw. den gemeinsamen P-Bus(sen) 24 bereit.
-
4 veranschaulicht
eine alternative Ausgestaltung eines Verarbeitungssatzes, wie z.
B. des Verarbeitungssatzes 14 nach 1. Hier umfaßt ein einfacher Verarbeitungssatz
einen einzelnen Prozessor 72 und einen zugehörigen Speicher 76,
die über
einen gemeinsamen Bus 74 mit einer Verarbeitungssatzbussteuerung 70 verbunden
sind. Die Verarbeitungssatzbussteuerung 70 stellt eine
Schnittstelle zwischen dem internen Bus 74 und dem bzw.
den Verarbeitungssatz-I/O-Bus(sen)
(P-Busse) 24 für
die Verbindung mit der bzw. den Brücke(n) 12 bereit.
-
Dementsprechend versteht es sich
gemäß den 3 und 4, daß der Verarbeitungssatz unterschiedliche
Formen annehmen kann und daß die
spezielle Wahl eines bestimmten Verarbeitungssatzaufbaus auf der Basis
der Verarbeitungserfordernisse einer bestimmten Anwendung und des
Ausmaßes
der erforderlichen Redundanz erfolgen kann. In der folgenden Beschreibung
sei angenommen, daß die
Verarbeitungssätze 14 und 16,
auf die Bezug genommen wurde, eine Struktur haben, wie sie in 3 dargestellt ist, auch
wenn es sich versteht, daß auch
eine andere Form eines Verarbeitungssatzes bereitgestellt werden
könnte.
-
Die Brücke(n) 12 ist bzw.
sind in einer Anzahl von Betriebszuständen betreibbar. In einem ersten
kombinierten Betriebszustand ist eine Brücke 12 so betreibbar,
daß sie
Adressen und Daten zwischen den Verarbeitungssätzen 14 und 16 (über die
PA- bzw. PB-Busse 24 bzw. 26) und den Geräten (über den
D-Bus 22) leitet. In diesem kombinierten Betriebszustand
werden I/O-Zyklen, die durch die Verarbeitungssätze 14 und 16 erzeugt
werden, miteinander verglichen, um sicherzustellen, daß beide
Verarbeitungssätze
korrekt arbeiten. Vergleichsfehler bringen die Brücke 12 zwangsweise
in einen Fehlerbegrenzungszustand (E-Zustand), in welchem eine Geräte-I/O (Eingabe/Ausgabe)
verhindert wird und Diagnoseinformation gesammelt bzw. erfaßt wird.
In einem zweiten, aufgespaltenen Betriebszustand leitet und vermittelt
die Brücke 12 Adressen
und Daten von einem der Verarbeitungssätze 14 und 16 auf
den D-Bus 22 und/oder auf den anderen der Verarbeitungssätze 16 bzw. 14.
In diesem Betriebszustand sind die Verarbeitungssätze 14 und 16 nicht
synchronisiert und es werden keine I/O-Vergleiche vorgenommen. DMA-Vorgänge sind
in beiden Betriebszuständen
ebenfalls zulässig.
-
5 ist
eine schematische Funktionsübersicht über die
Brücke 12 nach 1.
-
Erste und zweite Verarbeitungssatz-I/O-Busschnittstellen,
die PA-Busschnittstelle 84 und die PB-Busschnittstelle 86,
sind mit den PA- bzw. PB-Bussen 24 bzw. 26 verbunden.
Eine Geräte-I/O-Busschnittstelle,
die D-Busschnittstelle 82, ist mit dem D-Bus 22 verbunden.
Es sei angemerkt, daß die
PA-, PB- und D-Busschnittstellen nicht als getrennte Elemente konfigunert
sein müßten, sondern
daß sie
in andere Elemente der Brücke integriert
sein könnten.
Dementsprechend erfordert im Kontext dieser Schrift die Bezugnahme
auf eine Busschnittstelle nicht notwendigerweise das Vorhandensein
eines speziellen, getrennten Bauteils, sondern stattdessen die Fähigkeit
der Brücke,
den betreffenden Bus beispielsweise mit Hilfe von physikalischen
oder logischen Brückenverbindungen
für die
betreffenden Busleitungen anzuschließen.
-
Die Routing-Einrichtung (nachfolgend
als Routingmatrix bezeichnet) 80 ist über einen ersten internen Pfad 94 mit
der PA-Busschnittstelle 84 und über einen zweiten internen
Pfad 96 mit der PB-Busschnittstelle 86 verbunden.
Die Routingmatrix 80 ist weiterhin über einen dritten internen
Pfad 92 mit der D-Busschnittstelle 82 verbunden.
Die Routingmatrix 80 ist dadurch in der Lage, das Routing
bzw. die Vermittlung von I/O-Bustransaktionen in beiden Richtungen
zwischen den PA- und PB-Busschnittstellen 84 und 86 zu
gewährleisten.
Sie ist auch in der Lage, ein Routing bzw. eine Vermittlung in beiden
Richtungen zwischen einer oder beiden der PA- und PB-Busschnittstellen
und der D-Busschnittstelle 82 bereitzustellen. Die Routingmatrix 80 ist über einen weiteren
internen Pfad 100 mit der Speichersteuerlogik 90 verbunden.
Die Speichersteuerlogik 90 regelt den Zugriff auf Brükkenregister 110 und
auf einen Speicher mit wahlweisem Zugriff (SRAM) 126. Die
Routingmatrix 80 ist daher auch so betreibbar, daß sie ein
Routing in beiden Richtungen zwischen den PA-, PB- und D-Busschnittstellen 84, 86 und 82 und
der Speichersteuerlogik 90 bereitstellt. Die Routingmatrix 80 wird
durch die Brückensteuerlogik 88 über Steuerpfade 98 und 99 gesteuert.
Die Brückensteuerlogik 88 reagiert
auf Steuersignale, Daten und Adressen auf den internen Pfaden 93, 95 und 97 und
auch auf Taktsignale auf der bzw. den Taktleitung(en) 21.
-
In der Ausführungsform gemäß der Erfindung
arbeitet jeder der P-Busse (PA-Bus 24 und PB-Bus 26) unter
einem PCI-Protokoll. Die Bussteuerungen 50 der Verarbeitungssätze (siehe 3) arbeiten ebenfalls unter
PCI-Protokoll. Dementsprechend stellen die PA- und PB-Busschnittstellen 84 und 86 jeweils
die gesamte Funktionalität
bereit, die für
eine kompatible Schnittstelle erforderlich ist, welche sowohl einen
Master- als auch einen Slave-Betrieb für Daten bereitstellt, die zu
und von dem D-Bus 22 oder internen Speichern und Registern der
Brücke
in das Speicherteilsystem 90 übertragen werden. Die Busschnittstellen 84 und 86 können Diagnoseinformation
beim Übergang
der Brücke
in einen Fehlerzustand (E-Zustand) oder bei Erfassung eines I/O-Fehlers für interne
Brückenzustandsregister
in dem Speicherteilsystem 90 bereitstellen.
-
Die Gerätebusschnittstelle 82 führt die
gesamte Funktionalität
aus, die für
eine PCI-gerechte Master- und Slave-Schnittstelle erforderlich ist,
um Daten zu und von einem der PB-Busse 84 und 86 zu übertragen. Der
D-Bus 82 ist während Übertragungen
mit direktem Speicherzugriff (DMA) so betreibbar, daß er beim Übergang
der Brücke
in einen E-Zustand oder beim Erfassen eines I/O-Fehlers Diagnoseinformation für interne
Zustandsregister in dem Speicherteilsystem 90 der Brücke bereitstellt.
-
6 ist
eine schematische Übersicht
eines Gestells bzw. Gehäuses 200 mit
verschiedenen Steckplätzen
(Slots) für
die Aufnahme von austauschbaren Feldeinheiten (FRUs), die Bauteile
oder Geräte
des fehlertoleranten Computersystems 10 enthalten, die
unter Bezug auf die 1 bis 5 beschrieben wurden. Jede FRU
kann ein oder mehrere Geräte
enthalten.
-
Beispiele der austauschbaren Feldeinheiten
für die
Verwendung in dem System umfassen die beiden Hauptplatinen 40 und 42.
Diese sind an Positionen 201 und 203 in den oberen
und unteren Bereichen des Gehäuses 200 montiert,
wie man es in 6 sehen
kann. Die ersten und zweiten Verarbeitungssätze 44 und 46, die
ebenfalls FRUs bilden, sind an Positionen 45 und 47 montiert,
welche die Hauptplatinen 40 und 42 überbrücken.
-
Andere austauschbare Feldeinheiten,
die in 6 dargestellt
sind, sind FRUs 210 eines herausnehmbaren Medienmoduls
(RMM), die in Steckplätzen 211 montiert
sind. FRUs 212 mit Festplattenlaufwerkgehäuse sind
in Steckplätzen 213 montiert.
Die Festplattenlaufwerke in den Festplattenlaufwerkgehäusen 212 sind
typischerweise als FRUs ausgestaltet. Konsolen- und Gebläse- (CAF-)
FRUs 214, die Schalter, Anschlüsse, Warnelemente und LEDs
enthalten, sind in Steckplätzen 215 montiert.
PCI-Frame-FRUs 216 sind in den Slots 217 montiert.
Die PCI-Karten in dem PCI-Frame bzw. PCI-Rahmen sind ebenfalls als
FRUs ausgestaltet. Stromversorgungs-FRUs 218 sind in weiteren
Steckplätzen 219 montiert.
Teilaufbauten (nicht dargestellt) der Stromversorgungs-FRUs könnten ebenfalls
als FRUs bereitgestellt und ausgestaltet sein.
-
Die FRUs für das Einsetzen in den verschiedenen
Steckplätzen
bzw. Slots sind mit einem Identifizierungsetikett (beispielsweise
DSK) 232 versehen. Ein entsprechendes Etikett (beispielsweise
A-DSK) 234 gehört
zu jedem Steckplatz, um dem Benutzer anzuzeigen, wo die jeweilige
FRU anzuordnen ist. In einer Ausführungsform der Erfindung weist
eine FRU einen Speicher 230 auf (beispielsweise einen nicht
flüchtigen
Speicher wie ein EEPROM), der Information enthält, die sich auf die FRU und
die Einrichtung(en), die sie trägt,
bezieht. Wie später
noch beschrieben wird, umfaßt
diese Information Klasseninformation über das Konfigurationsverwaltungssystem
für die
FRU für
die Verwendung durch das Konfigurationsverwaltungssystem (CMS) 400 (in 6 nicht dargestellt), um
die FRU in dem System zu konfigurieren. Es sei angemerkt, daß eine Ausführungsform
der Erfindung zusätzlich
zu FRUs, welche einen Speicher 230 enthalten, einige Einheiten
enthalten kann, die in dem Feld austauschbar sind, beispielsweise
ein Festplattenlaufwerk, welches mit einem Speicher 230 versehen
sein könnte
oder nicht. Dies kann dort wünschenswert
sein; wo aus Gründen
der Ökonomie
eine konventionelle austauschbare Feldeinheit verwendet wird.
-
7 ist
die schematische Wiedergabe der Art und Weise, in welcher das CMS
die physikalische Struktur des Systems modelliert. Das CMS liefert
kein Modell für
das Systemgehäuse
bzw. -gestell. Das CMS modelliert jedoch die FRUs und die darin
vorhandenen Geräte.
Das CMS modelliert eine Inhaltshierarchie der FRUs. Das Modell zeigt
die physikalische Abhängigkeit
der jeweiligen Elemente. Das Modell zeigt die Abhängigkeit
der FRUs von einer der Hauptplatinen an. Es zeigt nicht die Abhängigkeit
der Hauptplatinen von den Stromversorgungseinheiten. Die Abhängigkeit
des Systems von den Prozessorsätzen
ist in Form der Dienstleistungshierarchie für das Prozessorsatz-Teilsystem dargestellt.
Wie in 7 gezeigt, modelliert
das CMS den Verarbeitungssatz-Einrichtungen 52, 56 etc.
(siehe 3-5) als von der ersten Hauptplatine 42 abhängig. Ebenfalls
als abhängig
von der ersten Hauptplatine 42 ist ein erstes Festplattengehäuse 240 mit
zugehörigen Festplattenlaufwerken 244 modellhaft
wiedergegeben. CAF-FRUs 250 mit zugehörigen CAF-Einrichtungen 254 sind ebenfalls
als von der ersten Hauptplatine 42 abhängig modelliert, ebenso wie
PCI-Adapter 260 und die zugehörigen PCI-Geräte 264.
Eine FRU für
abnehmbare Medien (RMM) 270 und zugehörige Mediengeräte (die
beispielsweise ein Bandlaufwerk und ein CD-ROM-Laufwerk umfassen) 274 sind ebenfalls
modellhaft als abhängig
von der ersten Hauptplatine 42 angegeben, ebenso wie die
Stromversorgungseinheiten 280 (möglicherweise auch mit Stromversorgungsteilsystemen 84).
Die verschiedenen Hauptplatineneinrichtungen 292 der ersten
Hauptplatine 42 sind ebenfalls modellhaft durch das CMS
wiedergegeben.
-
Das CMS modelliert den Verarbeitungssatz 16 mit
den zugehörgen
Verarbeitungssätzen 52, 56 etc. (siehe 3-5) als von der zweiten Hauptplatine 44 abhängig. Ebenso
als abhängig
von der zweiten Hauptplatine 44 ist ein zweites Festplattengehäuse 242 mit
zugehörigen
Festplattenlaufwerken 246 modellhaft wiedergegeben. CAF-FRUs 252 mit
zugehörigen
CAF-Einrichtungen 256 sind ebenfalls als von der zweiten Hauptplatine 44 abhängig modelliert.
Ebenso wie auch die PCI-Adapter 262 und
die zugehörigen
PCI-Geräte 266.
Eine FRU für
abnehmbare Medien (RMM) 272 und zugehörige Mediengeräte (einschließlich Bandlaufwerk
und CD-ROM-Laufwerk) 276 sind weiterhin modellhaft als
von der zweiten Hauptplatine 44 abhängig wiedergegeben, ebenso
wie die Stromversorgungseinheiten 282 (möglicherweise
auch mit Stromversorgungsteilsystemen 286). Die verschiedenen
Hauptplatinen-Einrichtungen 294 der ersten Hauptplatine 44 werden
ebenfalls durch das CMS modellhaft wiedergegeben.
-
In 7 veranschaulichen
die durchgezogenen Linien (beispielsweise 296) die Abhängigkeiten
der FRU-Bestandteile auf den Hauptplatinen 42 und 44 (wobei
daran zu erinnern ist, daß die
Hauptplatinen ebenfalls FRUs sind). Die gestrichelten Linien (beispielsweise 298)
zeigen die Abhängigkeiten
der Gerätebestandteile
von den FRU-Bestandteilen.
-
8 ist
eine schematische Wiedergabe der Modellierung bzw. modellhaften
Darstellung einer Gerätehierarchie
durch das CMS. Die Gerätehierarchie
ist von der in Bezug auf 7 beschriebenen
FRU-Hierarchie unabhängig
und ist auch von der physikalischen Anordnung der FRUs unabhängig, da
sich verschiedene Einrichtungen auf unterschiedlichen FRUs befinden
können.
Das CMS erzeugt diese Gerätehierarchie
aus der Klasseninformation und möglicherweise
auch anderer Information, die aus nicht flüchtigem Speicher aus den FRUs
gelesen wird.
-
Das CMS modelliert Teile des Gerätebaums,
wobei die verschiedenen Elemente als Knoten oder Objekte in dem
Baum wiedergegeben sind. Demnach ist ein erster Knoten oder Objekt 300,
welches die Brücke repräsentiert,
mit einzelnen Knoten oder Objekten 302, die Steckplatzsteuerungen
repräsentieren,
verknüpft. In ähnlicher
Weise sind individuelle Einrichtungen, wie z. B. die Geräte DO, D1,
D2 und D3, durch Knoten oder Objekte 304 wiedergegeben,
die mit einem Steckplatzobjekt 302 verbunden sind. Das
CMS ist in der Lage, diesen Baum zu vennrenden, um mit den einzelnen
Gerätetreibern
zu kommunizieren, und ermöglicht
es, daß das
CMS Abhängigkeiten
zwischen den Geräten
modelliert.
-
9 veranschaulicht
eine Dienstleistungshierarchie. Dienstleistungshierarchien können definiert werden,
indem eine Dienstleistung 310 als ein Knoten oder Objekt
innerhalb der Dienstleistungshierarchie wiedergegeben wird. Eine
Dienstleistung kann beispielsweise ein Teilsystem, wie z. B. einen
fehlertoleranten Kerndienst, definieren. Diese Dienstleistungen
definieren Systemverfügbarkeit
und sind von den Geräten
bzw. Einrichtungen des Systems abhängig. Geräte können in der Source-Hierarchie
auch durch Knoten oder Objekte 312 in der Dienstleistungshierarchie
definiert werden. Wie in 9 dargestellt,
werden Abhängigkeiten zwischen
individuellen Einrichtungen 312, wie z. B. den Einrichtungen
D0 und D1, und der Dienstleistung 310 wiedergegeben. Die
Dienstleistungshierarchie könnten
automatisch abgeleitet werden, könnte
jedoch manuell abgeleitet werden.
-
Die Kombination der in den 7, 8 und 9 dargestellten Hierarchien
bildet das Modell des Konfigurationsvennraltungssystems (CMS), welches
verwendet wird, um den Betrieb dieses Sy stems zu steuern. Das Modell
kann in Form einer Datenbank in einer Konfigurationsdatei gespeichert
werden. Das CMS verwendet dieses Modell, um in der Lage zu sein,
eine Fehlertoleranz auf hohem Niveau zu unterstützen. Es ermöglicht den
Benutzern, die verschiedenen Komponenten des Systems zu konfigurieren,
so daß sie
die gewünschten Funktionen
ausführen,
und die Funktionsweise des Systems zu überblicken.
-
10 veranschaulicht
die Beziehung zwischen einem Daemon des Konfigurationsverwaltungssystems
CMSD 400 und verschiedenen Komponenten des Systems. Der
CMSD 400 ist ein Daemon zum Implementieren des Steuerverwaltungssystems
bzw. Organisationssteuersystems des Computersystems, welches in
vorherigen Figuren dargestellt wurde. Ein Daemon ist ein Verwaltungsprozeß im Hintergrund.
Ein solcher Prozeß kann
zu irgendeinem beliebigen Zeitpunkt, beginnend bei der Systeminitialisierung
bis zum Abschalten, verfügbar
sein.
-
Der CMSD 400 verwaltet verschiedene
Systemeinheiten (Objekte), die physikalische Geräte und/oder Softwaregegenstände sein
können.
Der CMSD 400 ist über
einen UNIX-Stecker angeschlossen, der eine Anwendungsprogrammschnittstelle
(API) 446 für
eines oder mehrere Anwendungsprogramme 440 bildet. Im vorliegenden
Fall sind zwei Anwendungsprogramme 442 und 444 dargestellt.
-
Das Verhalten des CMSD 400 wird
unter Verwendung von CMS-Definitionen (CMSDEFs) 410 spezifiziert.
Die CMSDEFs umfassen Erklärungen
für Objekte,
die durch den CMSD 400 verwaltet werden, Zustandsauswertungen
(Aussagen für
die Auswertung der Zustände
der Objekte), und Übertragungscode,
der ausgeführt
wird, wenn eine Übertragung
bzw. ein Übergang
zwischen den Zuständen
eines Objektes stattfindet. Die CMSDEFs 410 kann man sich ähnlich wie
einen Satz von Zustandsmaschinen für die durch den CMSD 400 verwalteten
Objekte vorstellen, wobei der CMSD 400 die Zustandsmaschinen
ausführt.
-
Eine Initialisierungskomponente 402 des
CMS ist bei einer ersten Initialisierung des CMS so betreibbar,
daß sie
ein Modell des Systems erzeugt, wie es unter Bezug auf die 7, 8 und 9 beschrieben wird, und speichert
dieses in einer Konfigurationsdatei 404. Die Konfigurationsdatei 404 bildet
eine dauerhafte Kopie des Modells, welche durch den aktuellen Aufruf
des CMSD und bei einem späteren
Neustart oder einer Neuinitialisierung des Systems verwendet werden
kann, unter der Annahme, daß die
Konfiguration sich nicht verändert hat
oder die Konfigurationsdatei weder verloren gegangen ist noch beschädigt wurde.
Die Speicherung des Modells in einer solchen dauerhaften Weise kann
Initialisierungszeiten einsparen, da es nicht notwendig ist, den
Vorgang des Wiedererzeugens des Modells neu zu durchlaufen. Es kann
auch eine Konsistenz zwischen Systeminitialisierungen bereitstellen.
Im Ergebnis kann es in einem fehlertoleranten System eine bessere
Erfassung von Fehlern ermöglichen,
wenn Systemelemente zwischen Systeminitialisierungen versagt haben oder
verändert
wurden.
-
Der CMSD 400 ist mit verschiedenen
Systemeinheiten, die durch den CMSD 400 verwaltet werden, wirksam
verbunden. Diese Einheiten bzw. Entitäten können physikalische Geräte 420 (beispielsweise
Plattenlaufwerke 422 und 424) oder Softwareeinheiten
(beispielsweise Datenbanken 432 und 434) umfassen.
Wie nachstehend noch beschrieben wird, ist einem CMSD 400 eine
ein deutige Prozessoridentifikation (PID) 450 zugeordnet,
welche der CMSD an einer Speicherstelle oder Datei 452 speichert,
die einem Überwachungsvorgang
bekannt ist, wenn der CMSD erfolgreich initiiert wird. Die Betriebsweise
des CMSD 400 wird durch eine Prozeßübeiwachungseinrichtung 460 überwacht,
welche die durch den CMSD 400 in der Datei 452 gespeicherte
PID 450 verwendet. Die Prozeßüberwachungseinrichtung 460 ist
als ein Überwachungsprozeß (Programm)
ausgestaltet, welches auf dem Computersystem laufen kann. Der Überwachungsprozeß 460 und
der CMSD 400 sind in dem Systemspeicher der Verarbeitungssätze gespeichert
und werden durch den bzw. die Prozessoren der Verarbeitungssätze des
Systems ausgeführt.
Die Datei für
die PID 450 kann auch in einem Systemregister oder in dem
Speicher bzw. Hauptspeicher gehalten werden.
-
Die Prozeßüberwachungseinrichtung 460 ist
in der Lage, auf die Datei 452 zuzugreifen, um die eindeutige
PID 450 für
den CMSD 400 zu bestimmen. Die PID 450 ist für den aktuellen
Aufruf des CMSD 400 wirklich einzigartig bzw. eindeutig
und sie kann nicht mit einem einfachen Namen verwechselt werden,
der verschiedenen Versionen des CMSD 400 zugeordnet sein
könnte,
oder auch nicht mit einem anderen Prozeß oder einem Programm, die
unter der Maske des CMSD 400 auftreten. Die Prozeßüberwachungseinrichtung 460 verwendet
dann die PID 450 aus der Datei 452, um auf Zustandsinformation
zuzugreifen, die durch den PID 450 (bei 472) in
einer Prozeßtabelle
(/prog) 470 identifiziert wird. Die Prozeßtabelle 470 kann
in einem Systemregister oder in dem Speicher gehalten werden. Die
Prozeßtabelle
bildet einen Teil der Ressourcen des Betriebssystems 475 des
Computersystems. Die Zustandsinformation an der Position 472 in
der Prozeßtabelle 470 definiert
den aktuellen Zustand des CMSD 400 und zeigt insbesondere
an, ob er gerade aktiv und gesund ist, oder ob er gestorben ist.
-
Der CMSD 400 wird normalerweise
in derselben Art und Weise gestartet wie irgendein Systemdaemon,
und zwar durch einen Systemvorgang bei dem Systemstart. Im Anschluß daran
wird die Prozeßüberwachungseinrichtung 460 gestartet.
Die Prozeßüberwachungseinrichtung
ist dann in der Lage, den CMSD 400 auf einen Ausfall des
CMSD 400 zu überwachen.
Wenn die Prozeßüberwachungseinrichtung 460 einen
Ausfall bzw. ein Versagen des CMSD 400 erfaßt, so löst sie einen
Neustart des CMSD 400 aus.
-
Die 11-13 veranschaulichen verschiedene
Schritte für
den Neustart des CMSD 400. In einem ersten Schritt, der
in 11 wiedergegeben
ist, und der auf die Erfassung des CMSD-Versagens folgt, startet
die Prozeßüberwachungseinrichtung 460 den
CMSD 400, der dann weiter damit fortschreitet, zu überprüfen, daß er betriebsbereit
ist (in der Lage ist, erfolgreich ausgeführt zu werden oder zu funktionieren).
Dies kann die Überprüfung umfassen,
daß die
verschiedenen Daten, auf welchen er beruht, verfügbar sind, und kann in einer Datenbank
installiert werden (falls dies nicht schon geschehen ist). Der neue
CMSD ist dann kritisch bezüglich seines
eigenen Betriebs in dieser Stufe und zeigt einen Fehler an, wenn
irgendwelche Inkonsistenzen oder Auslassungen bzw. Fehlstellen erfaßt worden
sind. Auf dieser Stufe des Prozesses erfolgt ein Handschlagaustausch 480 zwischen
dem CMSD 400 und der Prozeßüberwachungseinrichtung 460,
um zu testen, ob der CMSD 400 erfolgreich abläuft bzw.
ausgeführt
wird oder nicht.
-
12 zeigt
eine zweite Stufe in der Initialisierung des CMSD 400.
Diese Stufe ist erreicht, wenn der CMSD feststellt, daß er betriebsbereit
ist. Der CMSD 400 schreibt dann seine eindeutige Prozeßidentifikation (PID) 450 an
die vorbestimmte Stelle oder Datei 452 und informiert (bei 485)
auch die Prozeßüberwachungseinrichtung 460,
daß er
betriebsbereit ist. Die vorbestimmte Stelle oder Datei 452 ist
eine Speicherstelle oder Datei, welche die Prozeßüberwachungseinrichtung 64 kennt.
-
13 veranschaulicht
den betriebsbereiten Zustand der Prozeßüberwachungseinrichtung 460 und des
CMSD 400 im Anschluß an
die Initialisierung des CMSD 400. Die Prozeßüberwachungseinrichtung 460 ist
so betreibbar, daß sie
auf die PID 450 in der Datei 452 zugreift bzw.
zugreifen kann und die PID 450 aus der Datei 452 benutzt,
um auf die Prozeßzustandsinformation 472 zuzugreifen,
die durch die CMSD-PID in der Prozeßtabelle 470 des Betriebssystems
des Gesamtsystems wiedergegeben ist.
-
Wie oben beschrieben, wird der CMSD 400 durch
einen standardmäßigen CMSD-Startvorgang gestartet,
bevor die Prozeßüberwachungseinrichtung 460 gestartet
wird. Es wäre
jedoch auch möglich,
die Prozeßüberwachungseinrichtung
zuerst zu starten und dann es der Prozeßüberwachungseinrichtung 460 zu
ermöglichen,
das Fehlen eines CMSD zu entdecken und den CMSD wie oben unter Bezug
auf die 11-13 beschrieben zu starten.
-
14 zeigt
die Prozeßüberwachungseinrichtung 460 zum
Verifizieren des korrekten Betriebs des CMSD 400.
-
Die Prozeßüberwachungseinrichtung 460 ist
zu vorbestimmten Zeitpunkten (wie in Schritt S1 wiedergegeben)
betriebsbereit, um den aktuellen Zustand des CMSD zu testen. Dieser
Test könnte
nach einem vorbestimmten Zeitintervall und/oder nach dem Auftreten
von spezifizierten Systemereignissen ausgeführt werden.
-
In Schritt S2 versucht der Überwachungsprozeß 460,
die PID 450 für
den CMSD 400 aus der vorbestimmten Speicherstelle 452 wiederzugewinnen.
Wenn der überwachte
Prozeß 400 aus
irgendeinem Grund nicht in der Lage ist, die PID 450 wiederzugewinnen,
so wird in Schritt S5 ein Alarm A vorgebracht und es wird versucht,
in Schritt S6 den CMSD 400 neu zu starten.
-
Wenn die PID 450 aus der
Speicherstele 452 wiedergewonnen wird, wird in Schritt S3 die
Gültigkeit der
PID 450 getestet. Wenn der Gültigkeitstest der PID negativ
ist, so wird in Schritt S5 ein Alarm vorgebracht und es
wird in Schritt S6 der Versuch vorgenommen, den CMSD 400 neu
zu starten.
-
Wenn der Gültigkeitstest mit der PID 450 positiv
ist, so schreitet die Prozeßüberwachungseinrichtung 460 dann
fort, die PID 450 in Schritt S4 zu verwenden,
um den Zustand des CMSD 400 zu testen, indem sie auf Zustandsinformation
für den
CMSD 400 an der Stelle 472 zugreift, welche durch
die PID 450 in der Prozeßtabelle 470 des Betriebssystems
identifiziert bzw. wiedergegeben wird.
-
Die Prozeßüberwachungseinrichtung
460 ist
in der Lage, verschiedene Zustände
für den
CMSD
400 zu erkennen. Diese umfassen die Zustände:
CMSDok | CMSD
läuft korrekt |
CMSDunknown | CMSD-Zustand
kann nicht bestimmt werden |
CMSDdead | CMSD
ist gestorben (existiert nicht mehr) |
CMSDslow | CMSD
scheint noch zu leben, reagiert jedoch nicht |
Systemerror | Es
gibt einen Systemfehler, welcher CMSD-Tests beeinflußt. |
CMSDrestart | Ein
Neustart-Fehler ist aufgetreten. |
-
Wenn die Prozeßüberwachungseinrichtung 460 feststellt,
daß der
CMSD korrekt läuft,
geht die Kontrolle bzw. Steuerung von Schritt S4 zurück zu Schritt S1,
wo die Prozeßüberwachungseinrichtung 460 wartet, bis
der nächste
Test der Betriebsweise des CMSD 400 ausgeführt werden
muß.
-
Wenn die Prozeßüberwachungseinrichtung 460 in
Schritt S4 festgestellt hat, daß der CMSD anscheinend tot
ist, so wird in Schritt S5 ein Alarm A vorgebracht und
es wird in Schritt S6 ein Versuch unternommen, den CMSD 400 neu
zu starten. Als Option kann die Prozeßüberwachungseinrichtung 460 so
betreibbar sein, daß sie
einen Alarm setzt und eine Warnnachricht in Schritt S5 aussendet.
Die Prozeßüberwachungseinrichtung
ist dann so betreibbar, daß sie
in Schritt S6 versucht, den CMSD 400 neu zu starten,
wobei der CMSD-Zustand als irgendein anderer als der des korrekten
Betriebsablaufs des CMSD 400 erkannt bzw. gekennzeichnet wird.
-
15 veranschaulicht
den Schritt S6 nach 14 im
einzelnen. Dies entspricht im wesentlichen dem in den 11, 12 und 13 wiedergegebenen
Vorgang.
-
In Schritt S6.1 startet
die Prozeßüberwachungseinrichtung 460 den
CMSD 400. In Schritt S6.2 führt der CMSD 400 Selbsttests
aus, wie sie oben unter Bezug auf 11 beschrieben
wurden. Wenn der CMSD 400 nicht betriebsbereit ist, so
schaltet der CMSD 400 in Schritt S6.3 ab (exit)
und es wird eine Anzeige über einen
Fehlschlag (d. h. ein Wert, der nicht Null ist) an die Überwachungseinrichtung
zurückgegeben.
Alternativ verzweigt in Schritt S6.4 der CMSD 400,
wenn er betriebsbereit ist. Der Tochter-CMSD 400 läuft dann
gemäß Schritt S6.5 ab
und liefert die angemessenen CMSD-Dienstleistungen. In Schritt S6.6 schreibt
der Mutter-CMSD 400 die PID des Tochter-CMSD in die PID-Datei. Dann schaltet
die Mutter-CMSD 400 in Schritt S6.7 ab und liefert
eine Erfolgsanzeige (d. h. einen Wert Null) an die Prozeßüberwachungseinrichtung 460,
daß sie korrekt
arbeiten kann. In Schritt S6.8 löscht die Prozeßüberwachungseinrichtung 460 den
Alarm und sendet eine Nachricht über
einen erfolgreichen Neustart. Ansonsten wird der Alarm nicht gelöscht und
es wird eine Fehlermeldung erzeugt, um den Eingriff durch einen
Systembetreiber anzufordern. Man erkennt, daß als Ergebnis des obigen Verfahrens
der CMSD "von selbst
in den Hintergrund tritt" (d.
h. er verzweigt und dann schaltet der Mutterprozeß ab), so
daß die Überwachungseinrichtung
nicht die Mutter ist.
-
In dem in 14 dargestellten Vorgang wird ein einfacher
Test bezüglich
des aktuellen Zustandes des CMSD 400 in Schritt S4 ausgeführt mit
Hilfe der Prozeßüberwachungseinrichtung 460,
welche auf die Prozeßtabelle 470 Bezug
nimmt. Alternativ kann dieser Test durch einen Test ersetzt werden,
bei welchem die Prozeßüberwachungseinrichtung 460 versucht,
eine Verbindung zu dem CMSD 400 herzustellen und auf einen zurückgelieferten
Wert reagiert, welcher anzeigt, ob der CMSD aktiv ist oder nicht.
Auch wenn dieser direktere Ansatz ein höheres Maß an Sicherheit liefert, ob
der CMSD 400 korrekt arbeitet oder nicht, so schließt er jedoch
eine höhere
Systemzusatzlast (Overhead) ein, als der einfachere Test des Überprüfens der
Prozeßtabelle 470 des
Betriebssystems. Dementsprechend ist der einfache Test, der eine
ausreichende Zuverlässigkeit bietet,
in der vorliegenden Ausführungsform
der Erfindung bevorzugt.
-
Es sei angemerkt, daß der CMSD 400 einen
Prozeß verwendet,
der ähnlich
dem in 15 dargestellten
ist, um in einer Situation, in welcher beispielsweise die CMSDEFs 410 verändert wurden,
die Steuerung an einen neuen CMSD 400 zu übergeben.
Der durch den CMSD 400 verwendete Prozeß, der in 16 dargestellt ist, stellt sicher, daß die Prozeßüberwachungseinrichtung 460 zuverlässig über die Übergabe
der Kontrolle bzw. Steuerung von dem alten CMSD 400 auf
den neuen CMSD 400 informiert werden kann.
-
16 veranschaulicht
verschiedene Vorgänge
für einen
alten CMSD-Prozeß in
der linken Spalte, für einen
neuen CMSD-Prozeß in
der mittleren Spalte und für
den Überwachungsprozeß bzw. -vorgang
in der rechten Spalte. Die Zeit nimmt in 16 von oben nach unten zu.
-
In 16 ist
angenommen, daß ein
existierender (alter) CMSD 400 bei S11 arbeitet,
wenn bei S21 neue CMSDEFs 410 verfügbar werden.
Zu diesem Zeitpunkt findet der Überwachungsprozeß 400,
wenn er die PID-Datei 452 liest, die PID 450.0 für den alten
CMSD 400 und prüft,
daß der
alte CMSD korrekt arbeitet.
-
Ein Aufruf des CMSD 400 ist
mit einem bestimmten Satz von CMSDEFs 410 verknüpft, um
einen Schutz gegenüber
Fehlern in den CMSDEFs 410 zu bieten. Demnach ist es für die Bereitstellung
eines neuen CMSD 400 erforderlich, die neuen CMSDEFs 410 zu
handhaben. Dementsprechend wird in Schritt S22 ein neuer
CMSD 400 erzeugt.
-
Der neue CMSD 400 führt dann
bei Schritt S23 wie zuvor Selbsttests aus. Wenn der neue
CMSD nicht betriebsbereit ist, so schaltet der neue CMSD in S24 ab.
Beispiele von Situationen, in welchen ein neuer Aufruf des CMSD 400 möglicherweise
nicht in der Lage ist, korrekt abzulaufen, liegen vor, wenn es einen
Fehler in den neuen CMSDEFs 410 gibt oder möglicherweise
dann, wenn ein Fehler in einer neuen Version des CMSD 400 vorliegt.
Alternativ führt,
wenn der neue CMSD betriebsbereit ist, der neue CMSD 400 einen
Handschlag S12/S25 mit dem alten CMSD 400 aus.
Der neue CMSD schreibt dann seine PID 450.1 in Schritt S26 in
die PID-Datei.
-
In Schritt S27 teilt der
neue CMSD dem alten CMSD mit, daß er übernimmt und in Schritt S13 schaltet der
alte CMSD ab. In Schritt S28 ist es daher der neue CMSD,
welcher läuft.
-
Wenn nach Schritt S26 der Überwachungsprozeß 460 die
PID aus der PID-Datei liest, so findet er die PID 450.1 für den neuen
CMSD und prüft
dann, daß der
neue CMSD korrekt arbeitet. Aus dem oben beschriebenen Verfahren
erkennt man auch, daß der
neue CMSD sich effektiv in den Hintergrund begeben hat und daß die Überwachungseinrichtung
nicht die Mutter desselben ist.
-
Wie oben erwähnt, ist der CMSD 400 verantwortlich
dafür und
auch so betreibbar, daß er
CMSDEFs 410 ausführt
für die
aktuelle Konfiguration des zu verwaltenden Systems. Die CMSD-Definitionen 410 können von
einer Festplatte oder einem anderen Speichermedium bereitgestellt werden,
welches Teil des Systems bildet, oder sie können von einer entfernten Quelle
zugeführt
werden. Konfigurationssoftware in Form von Skripten kann ebenfalls
verwendet werden, um Konfigurationsaussagen bzw. -feststellungen
für die
Konfigurierung des CMSD 400 zu erzeugen. Die Konfigurationsskripts
können
auch von einer Diskette oder einem anderen Speichermedium bereitgestellt
werden, welches Teil des Systems bildet, oder sie können von
einer ferngelegenen Quelle zugeführt
werden. Die CMSDEFs und Skripts könnten auch von einem nicht
flüchtigen
Speicher in den FRUs bereitgestellt werden, welche in den Buchsen
des Gehäuses
des Systems eingesteckt sind.
-
Die Prozeßüberwachungseinrichtung und/oder
der überwachte
Prozeß (CMSD)
können
in Form von Computerprogrammen vorliegen, die Computercode oder
-befehle aufweisen, welche die Funktionalität der Prozeßüberwachungseinrichtung und/oder
des überwachten
Prozesses definieren. Die Prozeßüberwachungseinrichtung
und/oder der CMSD können
auf einem Trägermedium
bereitgestellt werden. Das Trägermedium
kann irgendeine Form eines Trägermediums
zum Tragen von Computerprogrammcode haben, sei es magnetisch, optisch
oder in einer anderen Form von Datenspeicherung, wie z. B. in Form
eines Bandes, einer Festplatte, eines Festkörperspeichers oder irgendeiner
anderen Art der Speicherung, die einen wahlweisen Zugriff oder einen
Nur-Lese-Zugriff oder irgendeine andere Form des Zugriffs gewährt, oder
ein Übertragungsmedium,
wie z. B. ein Telefondraht, Radiowellen etc.
-
Es folgt nun eine Beschreibung der
Art und Weise, in welcher das System automatisch konfiguriert werden
kann, um die FRUs mit ihren zugehörigen Geräten zu berücksichtigen, die in die Buchsen
bzw. Steckplätze
des Gehäuses
bzw. Gestells 200 des Systems eingesetzt sind.
-
Wie zuvor bereits erwähnt, dient
das Konfigurationsverwaltungssystems der vorliegenden Ausführungsform
dazu, die Überwachung
von Fehlertoleranz auf hohem Niveau für das fehlertolerante Computersystem
bereitzustellen, indem es die Wechselwirkungen zwischen den Elementen
des Systems modelliert bzw. modellhaft wiedergibt und in der Tat
die Konfiguration des Systems in Reaktion auf Benutzeranforderungen verwaltet.
Um in der Lage zu sein, dies in effizienter Weise zu tun, müssen die
Komponenteneinheiten und die Geräte,
aus welchen sie bestehen, ihrerseits konfiguriert werden und das
Computersystem muß als
Ganzes bezüglich
beispielsweise der Wechselwirkungen zwischen den Einheiten und/oder
den Geräten
konfiguriert werden.
-
Ein vorteilhaftes Verfahren der automatischen
Konfiguration solcher Komponenten wird nachstehend beschrieben.
-
17 zeigt
eine FRU 214, die in einen Steckplatz bzw. Slot 215 in
dem Gehäuse
oder Gestell 200 eingesetzt ist. Man erkennt, daß die FRU 214 ein
Etikett 234 trägt,
welches zu einem Etikett 232 neben dem Steckplatz 215 passend
gemacht sein kann, um eine Identifizierung des richtigen Steckplatzes 215 für die FRU 214 zu
unterstützen.
Wie in 17 dargestellt,
ist die FRU 214 eine RMM-FRU, die ein Bandlaufwerk 236 und ein
CD-ROM-Laufwerk 238 enthält. Die FRU 214 umfaßt auch
einen nicht flüchtigen
Speicher 230, der Konfigurierungsinformation enthält, die
durch die CMSD 400 verwendet werden soll, um die FRU 214 und
deren zugeordnete Geräte 236 und 238 korrekt
zu konfigurieren. In dem vorliegenden Beispiel der Erfindung umfaßt der nicht
flüchtige
Speicher die folgende Information:
EE.GEN.ID.PARTNO = 5431
EE.GEN.ID.SERIALNO
= 9991
EE.MSP.FRUNAME = RMM
EE.MSP.DEVO.NAME = CDROM
EE.MSP.DEVO.SCSIID
= 0
EE.MSP.DEV1.NAME = TAPE
EE.MSP.DEV1.SCSIID = 1
-
Bei einer FRU nach dem Stand der
Technik wäre
nur eine Teilzahl der oben angezeigten Information vorhanden gewesen.
In dieser Ausführungsform
enthält
jedoch der nicht flüchtige
Speicher zusätzlich
zu der Teilzahl auch Klasseninformation für die FRU, nämlich den
FRUNAME:RMM. Andere Information wird ebenfalls bereitgestellt, wie
nachstehend noch beschriebe wird.
-
Ein Computer des CMSD, der einen
Konfigurations- (Initialisierungs-) Mechanismus in Form eines Programms
(CMSINITIALIZE) bildet, ist so betreibbar, daß er jeden Steckplatz oder
jede Stelle, welcher eine FRU aufnimmt, des Gerätes abtastet und nach den nicht
flüchtigen
Speichern 230 sucht. Die Klasseninformation für die FRU
(hier der FRU-Klassenname RMM) wird durch die Initialisierungskomponente
verwendet, um einen Pfad zu den CMS-Objektdefinitionen (CMSDEFs)
für diese
Klasse von FRU (hier die RMM-Klasse) abzuleiten. Die CMSDEFs können Initialisierngscodes
(Inititalisierungsskripts) umfassen, die für die Klasse von FRU spezifisch
sind und die nach Empfang der FRU-Klasse und einer Fallnummer, die
durch die Initialisierungskomponente erzeugt wurde, so betreibbar
sind, daß sie
Konfigurierungsinformation (Konfigurationsskripte) erzeugt, die
dann in der CMS-Konfigurationsdatei 404 gespeichert werden,
welche in dem Systemspeicher aufbewahrt wird. Falls erforderlich,
kann der Initialisierungscode weiterhin auf den FRU-Speicher für weitere Information
zugreifen, die erforderlich ist, um die anfängliche Konfigurierungsinformation
zu erzeugen. Die Konfigurations-Aussagen bzw. -Feststellungen weisen
typischerweise eine Objektklasse (z. B. RMM) und Fallzahl (beispielsweise 1),
ein Attribut (beispielsweise eine Aktion) und einen Wert (beispielsweise
Freigeben) auf. Ein Beispiel von Einträgen in einer CMS-Konfigurationsdatei
für die
FRU 214 gemäß 17 ist in 18 wiedergegeben.
-
Wenn die CMS-Konfigurationstabelle
bereitgestellt worden ist und die anfänglichen Überprüfungen abgeschlossen sind,
so ist der CMSD dann in der Lage, aus der in der CMS-Konfigurationsdatei
gespeicherten Information zu bestimmen bzw. festzustellen, welche
FRUs existieren. Um die Geräteinstanzen
für das
Band (Tape) und die CD-ROM korrekt einzustellen, fragen die CMS "CMSDEFs" die RMM-FRU weiterhin
ab. Das CMS-Modell der FRU und seine Geräte werden dynamisch aus der
Information in dem nicht flüchtigen
Speicher 230 erzeugt. 19 veranschaulicht
ein Beispiel der CMSDEFs-Instanzen und -Attribute für das in 17 dargestellte FRU-Beispiel.
-
20 ist
ein Flußdiagramm
für die
Zusammenfassung der Betriebsweisen einer CMS-Initialisierungskomponente 402 für das anfängliche
Konfigurieren der FRU in dem System, wie es unter Bezug auf die 17-19 beschrieben wurde. In einer Ausführungsform
der Erfindung ist dies nur bei der ersten Initialisierung des Systems
betriebsbereit, wobei die Konfigurationsdatei bei nachfolgenden
Initialisierungen die erforderliche Information bereitstellt. Die
Verwendung einer Konfigurationsdatei ist bei dem vorliegenden fehlertoleranten System
bevorzugt, da sie eine Kontinuität
zwischen Initialisierungen gewährleistet
und bei der Identifizierung von Fehlern hilft. Es versteht sich,
daß in
anderen Systemen es jedoch wünschenswert
sein kann, diesen Vorgang während
anderer Zeiten auszuführen.
-
In Schritt S41 tastet die
CMS-Initialisierungskomponente 500 die FRUs aufnehmenden
Stellen ab und sucht nach nicht flüchtigen Speicherelementen 320.
Im Ergebnis ist die CMS-Initialisierungskomponente, wenn
eine FRU in einer solchen Aufnahmestelle eingesetzt ist und bevor
die FRU in das System integriert ist, in der Lage, das Vorhandensein
der FRU zu erfassen.
-
In Schritt S42 extrahiert
die CMS-Initialisierungskomponente, wenn sie ein nicht flüchtiges
Speicherelement in der FRU an der Aufnahmestelle identifiziert hat,
die Information über
die FRU-Klasse (beispielsweise den
FRU-Klassennamen), der darin bereitgestellt wird.
-
Diese Information über die
FRU-Klasse wird dann in Schritt S43 von der CMS-Initialisierungskomponente
verwendet, um auf den Initialisierungscode (Skripts) für die durch
die Klasseninformation identifizierte Klasse zuzugreifen. Wie angezeigt,
können
die Initialisierungssknpts den CMSDEFs für diese FRU-Klasse zugeordnet
sein.
-
In Schritt S44 erzeugen
die Initialisierungsskripts die Konfigurationsanweisungen für die FRU,
wie es unter Bezug auf 18 beschrieben
wurde. Falls erforderlich, kann dieser Schritt das Zugreifen des
Initialisierungscodes auf den nicht flüchtigen Speicher in der FRU
umfassen.
-
Die Konfigurationsanweisungen, die
durch die Initialisierungsskripts ausgegeben werden, werden in Schritt S45 durch
die Initialisierungskomponente verifiziert (dies könnte durch
eine getrennte Komponente des CMS bewirkt werden).
-
Wenn die Initialisierungskomponente
während
dieser Überprüfung Fehler
feststellt, so verwirft sie alle Codezeilen, die zu der tretreffenden
FRU gehören.
Dies erfolgt, um sicherzustellen, daß der CMSD starten kann, so
daß nachfolgend
Korrekturmaßnahmen
getroffen werden können.
Ansonsten werden die Konfigurationsanweisungen, falls sie die Überprüfung bestehen,
in Schritt S46 in die Konfigurationsdatei 404 geschrieben.
Wenn alle Konfigurationsanweisungen in der CMS-Konfigurationsdatei gespeichert worden
sind und dies alles die Überprüfung besteht,
so kann die Steuerung an den Daemon des Konfigurationssystems weitergegeben
werden.
-
Der CMSD schließt dann in Schritt S47 die
Konfiguration des Systems ab, einschließlich der Konfiguration der
FRU-Geräte,
wie es in 19 dargestellt
ist. Als Teil des Prozesses greift er auf den FRU-Speicher zu, falls
erforderlich, um Klasseninformation über Geräte und weitere Geräteinformation
zu extrahieren. Der CMSD ist dann in der Lage, die FRU-Geräte entsprechend
den CMSDEFs und/oder Skripts zu konfigurieren. Der CMSD ist so betreibbar,
daß er
automatisch zumindest die physikalischen und Gerätehierarchien erzeugt, auf
die in den 7 und 8 Bezug genommen wurde, indem zwischen
verschiedenen Objekten entsprechend der Information in den CMSDEFs
Links bereitgestellt werden, wobei die Informationen in den CMSDEFs
Erklärungen
für die
durch den CMSD verwalteten Objekte, Zustandsauswertungen (Anweisungen
für die
Auswertung des Zustandes von Objekten) und Übergangscode enthalten, der
ausgeführt
wird, wenn ein Übergang zwischen
den Zuständen
eines Objektes auftritt. Die Service- bzw. Dienstleistungshierarchie
kann teilweise unter Eingriff eines Benutzers konfiguriert werden
(beispielsweise, um spezielle Dienste anzugeben, wie dies durch
den Benutzer angefordert wird).
-
Dieser zweistufige Prozeß ermöglicht die
Erzeugung einer Datenbank für
die Bereitstellung eines repräsentativen
Zustandes für
das Starten des CMSD.
-
Demzufolge ist ein Konfigurationsverwaltungssystem
beschrieben worden, welches eine automatische Konfiguration von
FRUs und ihren zugehörigen
Einrichtungen ermöglichen
kann.
-
Der Speicher in den FRUs kann verwendet
werden, um zusätzliche
Daten zu speichern, die sich von denen, welche spezifisch für die beschriebenen
Konfigurationsprozesse verwendet werden, unterscheiden. Beispielsweise
kann er zusätzlich
vennrendet werden, um gewisse Statusinformation zu speichern, die
sich auf den Systembetrieb beziehen, damit der Zustand des Systems
während
Neustarts konsistent sein kann. Auch kann er verwendet werden, um
eine Historie für
die Einheit zu speichern. Diese Information könnte dann auf irgendeiner späteren Stufe
offline verwendet werden (beispielsweise bei der Rückgabe einer
vermeintlich fehlerhaften FRU), um festzustellen, ob die FRU oder
möglicherweise
der Steckplatz, in welchen diese eingesetzt wurde, fehlerhaft sind.
-
Es ist ein Konfigurationsverwaltungssystem
mit einem Daemon des Konfigurationsverwaltungssystems (CMSD) beschrieben
worden. Das fortgesetzte korrekte Funktionieren des CMSD kann sichergestellt werden
durch Erfassung des Ausfalls des CMSD und Neustart des CMSD, wie
es angemessen erscheint. Ein Zusammenbrechen bzw. Überlasten
des Systems, welches durch andauernde schnelle Versuche für das Neustarten
eines CMSDs bewirkt wird, welcher niemals erfolgreich ausgeführt werden
kann, kann vermieden werden. Es versteht sich, daß, auch
wenn besondere Ausführungsformen
der Erfindung beschrieben worden sind, viele Modifikationen/Hinzufügungen und/oder
Austausche innerhalb des Rahmens der beanspruchten Erfindung vorgenommen
werden können.
-
Beispielsweise ist, auch wenn ein
Beispiel der Erfindung im Kontext mit einem fehlertoleranten Computersystem
beschrieben worden ist, diese in ihrer Anwendung nicht auf ein solches
System beschränkt.
In der Tat könnte
sie auch Anwendung bei einem anderen System finden, wo es wünschenswert
ist, den Betrieb eines möglicherweise
kritischen Prozesses zu überwachen,
beispielsweise eines Prozesses, der durch ein Daemon-Programm gesteuert
wird. Auch versteht es sich, daß,
obwohl in den bevorzugten Ausführungsformen
die Prozeßüberwachungseinrichtung
und der überwachte
Prozeß (CMSD)
durch Programmcode implementiert worden sind, daß diese zumindest teilweise
auch durch eine spezielle Hardware implementiert sein könnten, beispielsweise
unter Verwendung einer oder mehrerer Schaltkreise für einen
speziellen Zweck, wie z. B. von anwendungsspezifischen integrierten
Schaltkreisen (ASICs).
-
Dementsprechend soll das speziell
beschriebene Beispiel lediglich veranschaulichend und nicht beschränkend sein.