DE69907709T2 - Prozessüberwachung in einem rechnersystem - Google Patents

Prozessüberwachung in einem rechnersystem Download PDF

Info

Publication number
DE69907709T2
DE69907709T2 DE69907709T DE69907709T DE69907709T2 DE 69907709 T2 DE69907709 T2 DE 69907709T2 DE 69907709 T DE69907709 T DE 69907709T DE 69907709 T DE69907709 T DE 69907709T DE 69907709 T2 DE69907709 T2 DE 69907709T2
Authority
DE
Germany
Prior art keywords
monitored
monitor
computer system
cmsd
monitored process
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69907709T
Other languages
English (en)
Other versions
DE69907709D1 (de
Inventor
S. Roger BROWN
C. Karen ROLES
G. Simon APPLEBAUM
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=26314491&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE69907709(T2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from GBGB9822129.4A external-priority patent/GB9822129D0/en
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Application granted granted Critical
Publication of DE69907709D1 publication Critical patent/DE69907709D1/de
Publication of DE69907709T2 publication Critical patent/DE69907709T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0715Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1438Restarting or rejuvenating
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/28Error detection; Error correction; Monitoring by checking the correct order of processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/1629Error detection by comparing the output of redundant processing systems
    • G06F11/1641Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3495Performance evaluation by tracing or monitoring for systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/845Systems in which the redundancy can be transformed in increased performance

Description

  • 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.

Claims (52)

  1. Verfahren zum Überwachen eines Vorganges bzw. Prozesses in einem Computersystem (10) unter Verwendung eines Prozeßmonitors (460), wobei der überwachte Prozeß (400) kein Teil (keine "Tochter") des Prozeßmonitors (460) ist und wobei das Verfahren die Schritte aufweist:
  2. Eindeutiges Bestimmen der Identität eines überwachten Prozesses (400) und Verifizieren des korrekten Ablaufes des überwachten Prozesses (400),
  3. bei fehlender Verifizierung der korrekten Arbeitsweise des überwachten Prozesses (400) Bewirken, daß der überwachte Prozeß (400) erneut gestartet wird und c) wobei der überwachte Prozeß (400) beim erfolgreichen Neustart sich gegenüber dem Computersystem (10) in eindeutiger Weise selbst identifiziert.
  4. Verfahren nach Anspruch 1, wobei der Schritt (a) den Versuch eines Zugriffs auf eine vorbestimmte Stelle für eine Identifizierungsinformation des Prozesses aufweist, welche einen überwachten Prozeß (400) eindeutig identifiziert.
  5. Verfahren nach Anspruch 1 oder 2, wobei der Schritt (a) das Verwenden der eindeutigen Identität des überwachten Prozesses (400) aufweist, um eine korrekte Betriebsweise des überwachten Prozesses (400) zu verifizieren.
  6. Verfahren nach Anspruch 3, wobei der Schritt (a) das Abfragen des Betriebssystems des Computersystems (10) aufweist, um eine korrekte Betriebsweise des überwachten Prozesses (400) zu verifizieren.
  7. Verfahren nach Anspruch 3 oder 4, wobei der Schritt (a) das Anfordern eines Dienstes von dem überwachten Prozeß (400) aufweist, um dessen korrekte Betriebsweise zu verifizieren.
  8. Verfahren nach einem der Ansprüche 1 bis 5, wobei der Schritt (b) aufweist:
  9. der neu gestartete, überwachte Prozeß (400) überprüft anfänglich, daß er betriebsbereit ist, und
  10. der neu gestartete, überwachte Prozeß (400) zeigt, wenn er betriebsbereit ist, dem Prozeßmonitor (460) an, daß er betriebsbereit ist, und geht von sich aus in den Hintergrund.
  11. Verfahren nach Anspruch 6, wobei der Schritt (b)(ii) weiterhin aufweist, daß der neu gestartete überwachte Prozeß (400) Prozeßidentifizierungsinformation, durch welche er sich eindeutig identifiziert, an eine vorbestimmte Stelle schreibt.
  12. Verfahren nach Anspruch 6 oder 7, wobei Schritt (b) weiterhin aufweist:
  13. Bei Abwesenheit einer Anzeige der Betriebsbereitschaft von dem neu gestarteten überwachten Prozeß (400) gibt der Prozeßmonitor (460) eine Fehlermeldung aus und verhindert weitere Versuche, den überwachten Prozeß (400) erneut zu starten.
  14. Verfahren nach Anspruch 2 oder Anspruch 7, wobei die vorbestimmte Stelle eine vorbestimmte Datei ist.
  15. Verfahren nach einem der vorstehenden Ansprüche, wobei der Prozeßmonitor (60) ein Überwachungsprozeß (Monitorprozeß) ist.
  16. Verfahren nach einem der vorstehenden Ansprüche, wobei der überwachte Prozeß (400) ein Daemonprozeß ist.
  17. Verfahren nach einem der vorstehenden Ansprüche, wobei der überwachte Prozeß (400) ein Daemon (Hintergrunddienstprogramm) des Konfigurationsmanagementsystems ist.
  18. Verfahren nach Anspruch 12, wobei der Daemon des Konfigurationsmanagementsysterns auf Objektdefinitionen reagiert.
  19. Verfahren zum Neustarten eines Prozesses (400), der gemäß dem Verfahren zum Überwachen eines Prozesses nach einem der vorstehenden Ansprüche überwacht wird, wobei das Verfahren zum erneuten Starten eines Prozesses, welcher zu überwachen ist, aufweist: Erzeugen eines neuen Prozesses (400), und Überprüfen des neuen Prozesses, daß er betriebsbereit ist, und in Reaktion auf ein positives Ergebnis auf die Überprüfungen: sein eindeutiges Identifizieren gegenüber dem Computersystem (10), und Bewirken, daß ein existierender überwachter Prozeß (400) abgeschlossen wird, wodurch der neue Prozeß zu dem überwachten Prozeß (400) wird.
  20. Verfahren nach Anspruch 14, welches das Aufzeichnen eindeutiger Prozeßidentifikationsinformation für den neuen Prozeß an einer vorbestimmten Stelle für das eindeutige Identifizieren des neuen Prozesses aufweist.
  21. Verfahren nach Anspruch 14 oder Anspruch 15, wobei der existierende überwachte Prozeß (400) ein erster Aufruf eines Daemons eines Konflgurationsmanagementsystems ist, der mit einem ersten Satz von Objektdefinitionen zu betreiben ist, und der neue Prozeß ein zweiter Aufruf eines Daemons eines Konfigurationsmanagementsystems ist, der mit einem zweiten Satz von Objektdefinitionen betriebsbereit ist.
  22. Verfahren nach einem der vorstehenden Ansprüche, wobei der neu gestartete überwachte Prozeß (400) ausgewählt wird aus: einem neuen Prozeß, einer überarbeiteten Version (Upgrade) eines Prozesses, oder einem existierenden Prozeß.
  23. Computersystem (10), welches einen zu überwachenden Prozeß aufweist, wobei der zu überwachende Prozeß im Falle seiner erfolgreichen Auslösung sich eindeutig gegenüber dem System (10) identifiziert und ein Prozeßmonitor (460) folgendermaßen ausgestaltet ist: zum eindeutigen Bestimmen der Identität eines überwachten Prozesses (400), zum Verifizieren einer korrekten Betriebsweise des überwachten Prozesses (400), und, für den Fall, daß er nicht in der Lage sein sollte, eine korrekte Betriebsweise des überwachten Prozesses (400) zu verifizieren, zur Veranlassung, daß der überwachte Prozeß (400) erneut gestartet wird, wobei der überwachte Prozeß (400) kein Teil (keine Tochter) des Prozeßmonitors (460) ist, und der überwachte Prozeß beim erfolgreichen Neustart sich eindeutig selbst gegenüber dem System identifiziert.
  24. Computersystem nach Anspruch 18, wobei der Prozeßmonitor (460) so ausgelegt ist, daß er für eine Prozeßidentifizierungsinformation, welche eindeutig einen überwachten Prozeß (400) identifiziert, einen Zugriff auf eine vorbestimmte Speicherstelle des Computersystems (10) versucht.
  25. Computersystem nach Anspruch 18 oder 19, wobei der Prozeßmonitor (460) so ausgelegt ist, daß er die eindeutige Identifizierung des überwachten Prozesses (400) verwendet, um eine korrekte Betriebsweise des überwachten Prozesses (400) zu verifizieren.
  26. Computersystem nach Anspruch 20, wobei der Prozeßmonitor (460) so konfiguriert ist, daß er ein Betriebssystem des Computersystems (10) daraufhin abfragt, daß es eine korrekte Betriebsweise des überwachten Prozesses (400) verifiziert.
  27. Computersystem nach Anspruch 20 oder 21, wobei der Prozeßmonitor (460) so konfiguriert ist, daß er einen Dienst von dem überwachten Prozeß (400) anfordert, um dessen korrekte Betriebsweise zu bestimmen.
  28. Computersystem nach einem der Ansprüche 18 bis 22, wobei der neu gestartete Prozeß, der zu überwachen ist, so konfiguriert ist, daß er, wenn er initiiert worden ist, überprüft, daß er betriebsbereit ist, und, wenn dies der Fall ist, eine Anzeige hierfür für den Prozeßmonitor (460) bereitstellt, bevor er sich selbst in den Hintergrund begibt.
  29. Computersystem nach Anspruch 23, wobei der neu gestartete Prozeß, der zu überwachen ist, Prozeßidentifizierungsinformation, durch welche er sich eindeutig selbst identifiziert, an eine vorbestimmte Stelle schreibt, nachdem er verifiziert hat, daß er in der Lage ist, erfolgreich zu funktionieren.
  30. Computersystem nach Anspruch 24, wobei der Prozeßmonitor (460) so konfiguriert ist, daß er eine Fehlermeldung ausgibt und weitere Versuche zum erneuten Starten des überwachten Prozesses (400) bei Abwesenheit einer Anzeige von dem erneut gestarteten überwachten Prozeß (400), daß dieser betriebsbereit ist, verhindert.
  31. Computersystem nach Anspruch 19 oder Anspruch 23, wobei die vorbestimmte Stelle eine in einem Computerspeicher gehaltene Datei ist.
  32. Computersystem nach einem der Ansprüche 18 bis 26, wobei der Prozeßmonitor (460) ein Monitorprozeß (Überwachungsprozeß) ist.
  33. Computersystem nach einem der Ansprüche 18 bis 27, wobei der überwachte Prozeß (400) ein Daemonprozeß ist.
  34. Computersystem nach einem der Ansprüche 18 bis 28, wobei der überwachte Prozeß (400) ein Daemon eines Konfigurationsmanagementsystems ist.
  35. Computersystem nach Anspruch 29, wobei der Daemon des Konfigurationsmanagementsystems auf Objektdefinitionen reagiert.
  36. Computersystem nach einem der Ansprüche 18 bis 30, welches zumindest einen Prozessorsatz (14, 16) für die Ausführung des Prozeßmonitors (460) und des überwachten Prozesses (400) sowie einen Speicher, der den Speicherplatz bildet, aufweist.
  37. Computersystem nach Anspruch 30, wobei das Computersystem (10) ein fehlertolerantes Computersystem ist, welches eine Mehrzahl von Verarbeitungssätzen (14, 16) umfaßt, die im Verriegelungsschritt (Lockstep) betreibbar sind, wobei der überwachte Prozeß (400) ein Daemon eines Konfigurationsmanagementsystems ist, der auf Systemdefinitionen der Konfiguration reagiert, die für Elemente des fehlertoleranten Computersystems repräsentativ sind.
  38. Computersystem nach einem der Ansprüche 18 bis 32, wobei der erneut gestartete überwachte Prozeß ausgewählt wird aus: einem neuen Prozeß, einer überarbeiteten Version (Upgrade) eines Prozesses, oder einem existierenden Prozeß.
  39. Computerprogramm für ein Computersystem nach einem der Ansprüche 18 bis 33, wobei das Computerprogramm einen Prozeßmonitor (460) bildet, der Programmcode umfaßt, welcher so ausgestaltet ist, daß er in eindeutiger Weise die Identität eines überwachten Prozesses (400) bestimmt, um eine korrekte Betriebsweise des überwachten Prozesses (400) zu verifizieren, und, für den Fall, daß er nicht in der Lage ist, eine korrekte Betriebsweise des überwachten Prozesses (400) zu verifizieren, zu veranlassen, daß der überwachte Prozeß (400) erneut gestartet wird, so daß der überwachte Prozeß (400) kein Teil (bzw. Tochterprozeß) des Prozeßmonitors (460) ist, wobei ein erneut gestarteter, überwachter Prozeß (400) beim erfolgreichen Neustart sich in eindeutiger Weise gegenüber dem Computersystem (10) identifiziert.
  40. Computerprogramm nach Anspruch 34, wobei der Prozeßmonitor (460) so konfiguriert ist, daß er einen Zugriff auf eine vorbestimmte Speicherstelle des Computersystems (10) für die Prozeßidentifizierungsinformation versucht, welche in eindeutiger Weise einen überwchten Prozeß (400) identifiziert.
  41. Computerprogramm nach Anspruch 34 oder 35, wobei der Prozeßmonitor (460) so konfiguriert ist, daß er die eindeutige Identität des überwachten Prozesses (400) verwendet, um die korrekte Betriebsweise des überwachten Prozesses (400) zu verifizieren.
  42. Computerprogramm nach Anspruch 36, wobei der Prozeßmonitor (460) so konfiguriert ist, daß er ein Betriebssystem des Computersystems (10) abfragt, damit es die korrekte Betriebsweise des überwachten Prozesses (400) verifiziert.
  43. Computerprogramm nach Anspruch 36 oder 37, wobei der Prozeßmonitor so konfiguriert ist, daß er einen Dienst von dem überwachten Prozeß (400) anfordert, um dessen korrekte Betriebsweise festzustellen.
  44. Computerprogramm nach einem der Ansprüche 34 bis 38, wobei der Prozeßmonitor (460) so konfiguriert ist, daß er eine Fehlermeldung ausgibt und weitere Versuche eines erneuten Startes des überwachten Prozesses (400) verhindert, wenn eine Anzeige des erneut gestarteten überwachten Prozesses (400) fehlt, daß er betriebsbereit ist.
  45. Computerprogramm nach einem der Ansprüche 34 bis 39, wobei der Prozeßmonitor (460) ein auf einem Trägermedium getragenes bzw. gespeichertes Monitorprogramm ist.
  46. Computerprogramm nach einem der Ansprüche 34 bis 40, wobei der Prozeßmonitor (460) ein Monitorprogramm ist, welches auf einem Trägermedium gespeichert ist.
  47. Computerprogramm für ein Computersystem nach einem der Ansprüche 18 bis 33, wobei das Computerprogramm ein Konfigurationsmanagementsystem bildet, welches Programmcode aufweist, der so konfiguriert ist, daß er, wenn er durch einen Prozeßmonitor (460) ausgelöst wird, überprüft, daß er betriebsbereit ist, und, wenn dies der Fall ist, sich eindeutig gegenüber dem Computersystem (10) selbst identifiziert und eine Anzeige seiner Betriebsbereitschaft für den Prozeßmonitor (460) bereitstellt, bevor er sich selbst von dem Prozeßmonitor (460) abkoppelt, so daß er kein Teil- bzw. Tochterprozeß des Prozeßmonitors (460) ist.
  48. Computerprogramm nach Anspruch 42, welches weiterhin so konfiguriert ist, daß es sich gegenüber dem Systemspeicher selbst identifiziert, nachdem es verifiziert hat, daß es betriebsbereit ist.
  49. Computerprogramm nach Anspruch 43, welches weiterhin so konfiguriert ist, daß es Prozeßidentifikationsinformation, durch welche es sich eindeutig selbst identifiziert, an einer vorbestimmten Speicherstelle aufzeichnet, um sich selbst für das System in eindeutiger Weise zu identifizieren.
  50. Computerprogramm nach einem der Ansprüche 42 bis 44, welches einen Daemon eines Konfigurationsmanagementsystems aufweist.
  51. Computerprogramm nach einem der Ansprüche 42 bis 45, welches Programmcode aufweist, der einen Daemon eines Konfigurationsmanagementsystems bildet, welcher auf Definitionen des Konfigurationsmanagementsystems anspricht, die für Computersystemressourcen repräsentativ sind.
  52. Trägermedium, welches ein Computerprogramm nach einem der Ansprüche 42 bis 46 trägt.
DE69907709T 1998-10-09 1999-10-08 Prozessüberwachung in einem rechnersystem Expired - Fee Related DE69907709T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GBGB9822129.4A GB9822129D0 (en) 1998-10-09 1998-10-09 Process monitoring in a computer system
GB9822129 1998-10-09
GB9828202A GB2342472B (en) 1998-10-09 1998-10-09 Process monitoring in a computer system
GB9828202 1998-12-21
PCT/GB1999/003342 WO2000022527A1 (en) 1998-10-09 1999-10-08 Process monitoring in a computer system

Publications (2)

Publication Number Publication Date
DE69907709D1 DE69907709D1 (de) 2003-06-12
DE69907709T2 true DE69907709T2 (de) 2004-03-25

Family

ID=26314491

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69907709T Expired - Fee Related DE69907709T2 (de) 1998-10-09 1999-10-08 Prozessüberwachung in einem rechnersystem

Country Status (4)

Country Link
US (1) US6640203B2 (de)
EP (1) EP1119809B1 (de)
DE (1) DE69907709T2 (de)
WO (1) WO2000022527A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9286244B2 (en) 2005-06-23 2016-03-15 Bayerische Motoren Werke Aktiengesellschaft Method and device for monitoring an unauthorized memory access of a computing device, in particular in a motor vehicle

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7360121B2 (en) * 2002-02-22 2008-04-15 Bea Systems, Inc. System for monitoring a subsystem health
FI20031340A0 (fi) * 2003-09-18 2003-09-18 Nokia Corp Menetelmä ja järjestelmä yhteyksien seurantaan ja seurantaprotokolla
US20050174443A1 (en) * 2004-02-09 2005-08-11 Ikuo Niimura Image sensing apparatus and method of controlling same
US20060004737A1 (en) * 2004-07-02 2006-01-05 Grzonka Michael T Computer virus protection for automated pharmaceutical processes
US7716660B2 (en) * 2004-12-14 2010-05-11 Microsoft Corporation Method and system for downloading updates
US7669073B2 (en) * 2005-08-19 2010-02-23 Stratus Technologies Bermuda Ltd. Systems and methods for split mode operation of fault-tolerant computer systems
US20070130324A1 (en) * 2005-12-05 2007-06-07 Jieming Wang Method for detecting non-responsive applications in a TCP-based network
US8291093B2 (en) * 2005-12-08 2012-10-16 Microsoft Corporation Peer-to-peer remediation
US8521864B1 (en) 2006-01-10 2013-08-27 Crimson Corporation Systems and methods for managing the impact of monitoring processes
US7827531B2 (en) * 2007-01-05 2010-11-02 Microsoft Corporation Software testing techniques for stack-based environments
US8578364B2 (en) * 2008-04-25 2013-11-05 Microsoft Corporation Dynamic management of operating system resources
US20100005342A1 (en) * 2008-07-01 2010-01-07 Dambra Joseph J Redundant Error Detection in a Clinical Diagnostic Analyzer
US9098555B2 (en) * 2008-11-25 2015-08-04 Dell Products L.P. Method and system for health scoring information systems, users, and updates
US7886196B2 (en) * 2008-12-01 2011-02-08 International Business Machines Corporation Fast detection of process outages
US9240937B2 (en) 2011-03-31 2016-01-19 Microsoft Technology Licensing, Llc Fault detection and recovery as a service
SG2011031804A (en) * 2011-05-03 2015-03-30 Eutech Cybernetics Pte Ltd Computer implemented method and system for analyzing business processes
US8543543B2 (en) * 2011-09-13 2013-09-24 Microsoft Corporation Hash-based file comparison
US8893222B2 (en) * 2012-11-13 2014-11-18 Auckland Uniservices Ltd. Security system and method for the android operating system
US9720869B1 (en) * 2016-01-31 2017-08-01 Ncr Corporation Coupled device deployment location classification
US10394619B2 (en) 2016-08-22 2019-08-27 Western Digital Technologies, Inc Signature-based service manager with dependency checking
CN107819640B (zh) * 2016-09-14 2019-06-28 北京百度网讯科技有限公司 用于机器人操作系统的监控方法和装置
CN106775980B (zh) * 2016-12-15 2020-04-14 北京奇虎科技有限公司 一种进程id管理方法、装置及计算机可读介质
US10499525B1 (en) * 2018-10-22 2019-12-03 Severcube, Inc. Computing server apparatus
CN109634787B (zh) * 2018-12-17 2022-04-26 浪潮电子信息产业股份有限公司 分布式文件系统监控器切换方法、装置、设备及存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5410703A (en) * 1992-07-01 1995-04-25 Telefonaktiebolaget L M Ericsson System for changing software during computer operation
CA2106280C (en) * 1992-09-30 2000-01-18 Yennun Huang Apparatus and methods for fault-tolerant computing employing a daemon monitoring process and fault-tolerant library to provide varying degrees of fault tolerance
JPH08241279A (ja) * 1995-03-03 1996-09-17 Hitachi Ltd Dbms制御システム
US5805798A (en) * 1996-10-29 1998-09-08 Electronic Data Systems Corporation Fail-safe event driven transaction processing system and method
US5964831A (en) * 1996-10-29 1999-10-12 Electronic Data Systems Corporation Distributed on-line data communications system and method
CA2200010A1 (en) * 1997-03-14 1998-09-14 Crosskeys Systems Corporation Process management infrastructure
US6453430B1 (en) * 1999-05-06 2002-09-17 Cisco Technology, Inc. Apparatus and methods for controlling restart conditions of a faulted process

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9286244B2 (en) 2005-06-23 2016-03-15 Bayerische Motoren Werke Aktiengesellschaft Method and device for monitoring an unauthorized memory access of a computing device, in particular in a motor vehicle

Also Published As

Publication number Publication date
US6640203B2 (en) 2003-10-28
EP1119809A1 (de) 2001-08-01
WO2000022527A1 (en) 2000-04-20
EP1119809B1 (de) 2003-05-07
US20020116151A1 (en) 2002-08-22
DE69907709D1 (de) 2003-06-12

Similar Documents

Publication Publication Date Title
DE69907709T2 (de) Prozessüberwachung in einem rechnersystem
DE69913553T2 (de) Konfigurierung von systemeinheiten
DE69435090T2 (de) Rechnersystem mit Steuereinheiten und Rechnerelementen
DE60016371T2 (de) Vorrichtung und verfahren um die übereinstimmung der daten in einer gruppe von einspiegelungseinrichtungen gespeichert zu behalten
DE60025488T2 (de) Vorrichtung und verfahren zur allgemeinen koordination und verwaltung von mehrfachen schnappschussanbietern
DE102005053727B4 (de) Verteilte Verriegelung
DE4435751B4 (de) Dateiname- und Verzeichnis- Erfassungsverfahren zur Verwendung mit einem Betriebssystem
DE10085374B4 (de) Systemmanagementspeicher für die Systemmanagement-Interrupt-Behandler wird in die Speichersteuereinrichtung integriert, unabhängig vom BIOS und Betriebssystem
DE102007048920B4 (de) System und Verfahren zum Kommunizieren von Informationen zwischen einer Mehrzahl von Informationsverarbeitungssystemen
DE69907818T2 (de) Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmter Replikationsart für verteilte Anwendungen in einem Netzwerk
DE69930846T2 (de) Mehrkonfiguration-rückwand
DE19525013C2 (de) Multiprozessorsystem
DE69907824T2 (de) Verfahren und Vorrichtung zur Fehlererkennung und Wiederherstellung mit vorbestimmtem Replikationsgrad für verteilte Anwendungen in einem Netzwerk
DE60212922T2 (de) Umkehr eines Kommunikationspfades zwischen Speichergeräten
DE69811148T2 (de) Mitgliedschaft in einem unzuverlässigen verteilten Rechnersystem
DE69629444T2 (de) Datenverarbeitungsgerät und Verfahren zur Ersetzung von ausgefallenen Speichereinheiten
DE112020005786T5 (de) Systeme und verfahren zum ermöglichen eines hochverfügbaren verwalteten ausfallsicherungsdienstes
DE102004013113A1 (de) Plattenarraysystem und Fehlerinformations-Steuerungsverfahren
DE2611907A1 (de) Dv-system mit einer prioritaets- unterbrechungs-anordnung
DE69911199T2 (de) Bussteuerung mit mehreren systemwirtsrechnern
DE102012100738A1 (de) Verfahren zur Konfiguration eines BIOS in einem Computersystem sowie Computerprogrammprodukt
DE602004007884T2 (de) Speichersteuerungssystem und -Verfahren
DE60224438T2 (de) Aggregation von hardwareereignissen in mehrfach knotensystemen
DE112004000334T5 (de) Auf Richtlinien basierende Reaktion auf Systemfehler, die während der Betriebssystemlaufzeit eintreten
DE69914568T2 (de) Vorrichtung, Verfahren und System zur Dateisynchronisierung in einem Fehlertoleranten Netzwerk

Legal Events

Date Code Title Description
8363 Opposition against the patent
8365 Fully valid after opposition proceedings
8339 Ceased/non-payment of the annual fee