DE69913553T2

DE69913553T2 - Konfigurierung von systemeinheiten

Info

Publication number: DE69913553T2
Application number: DE1999613553
Authority: DE
Inventors: S. Roger BROWN; Karen C. Send ROLES; Simon G. Eton Wick APPLEBAUM
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1998-10-09
Filing date: 1999-10-08
Publication date: 2004-11-18
Anticipated expiration: 2019-10-09
Also published as: DE69913553D1; EP1119806B1; US6970948B2; US20020023181A1; WO2000022520A1; EP1119806A1

Description

HINTERGRUND DER ERFINDUNG
Die vorliegende Erfindung bezieht sich auf die Integration einer Einheit in eine Vorrichtung, beispielsweise zum Konfigurieren einer austauschbaren Feldeinheit (FRU) in eine Vorrichtung, wie z. B. ein Computersystem.
FRUs können in vielen verschiedenen Systemen verwendet werden. Sie haben ihren Anwendungsbereich insbesondere, jedoch nicht ausschließlich in Computersystemen, beispielsweise in fehlertoleranten Computersystemen, in welchen es wünschenswert ist, in der Lage zu sein, Einheiten einfach auszutauschen, in denen ein Fehler aufgetreten ist oder die durch eine neuere Version abgelöst wurden.
Beispiele für FRUs für ein solches System umfassen beispielsweise eine CPU, eine PCI-Karte, Stromversorgungseinheiten (PSUs), eine Hauptplatine oder irgendwelche sonstigen Systemkomponenten. Ein FRU, beispielsweise eine austauschbare Feldkarte, kann Hardware umfassen, um verschiedene Einrichtungen zu implementieren (beispielsweise einen mehrfachen Ethernet-Adapter oder einen SCSI-Adapter mit einem Ethernet-Adapter).
Es ist bekannt, FRUs mit nicht-flüchtigem Speicher auszurüsten (beispielsweise EEPROMs), der Information enthalten kann, die sich auf die FRU bezieht. In einem bekannten System können FRUs grundlegende Information über die FRU-Identifizierung in dem nicht-flüchtigen Speicher enthalten.
Es ist weiterhin bekannt, einen Systemverwaltungsbereich, der zusammenfassend als Konfigurationsmanagementsystem (CMS) bezeichnet wird, bereitzustellen, welcher die FRUs, andere Einrichtungen und Systemressourcen verwaltet unter Verwendung von Objekten, welche die FRUs, Geräte bzw. Einrichtungen und andere Systemressourcen repräsentieren. Ein Objekt bildet eine bestimmte Instanz einer CMS-Klasse, die durch eine CMS-Definition (CMSDEF) definiert wird.
Beispielsweise definiert eine CAF (Konsole und Gebläseeinheit) CMSDEF die CAF-CMS-Klasse, von welcher das Objekt CAF_1 eine Instanz ist, die eine bestimmte CAF-FRU repräsentiert. Das CAF_1-Objekt kann ein Attribut haben, welches LOCATION genannt wird und den Wert A CAF hat, was anzeigt, daß die FRU, welche durch das CAF_1-Objekt repräsentiert wird, an der Position A CAF in dem Gehäuse bzw. Rahmen des Computersystems eingefügt wurde.
Ein Problem beim Initialisieren eines Systems besteht darin, eine anfängliche Konfiguration für das System bereitzustellen, indem Anfangswerte den Objektattributen zugeführt werden, welche diese Konfiguration repräsentieren.
In dem oben erwähnten bekannten System hat das CMS eine Gehäusetypnummer verwendet, die aus dem EEPROM der FRU der Frontplatte gelesen wurde, um eine Standardkonfiguration für das System bereitzustellen. Dies lieferte jedoch nur eine grobe Konfiguration für das System, da es in der Tat aus der "Feinabstimmung" einer vordefinierten Konfiguration für bestimmte Bedürfnisse eines Systems dieser Art beruhte. Nur "standardmäßige" Teile der Konfiguration (beispielsweise die Boot-Platten und ihre Steuerungen und die CPUs) könnten auf diese Weise bereitgestellt werden, so daß vieles von der komplexeren Konfiguration (beispielsweise serielle Anschlüsse) manuell durchgeführt werden mußte.
Das US-Patent 5,809,329 beschreibt ein System zum Verwalten der Konfiguration von Geräten eines Computersystems. Die Information über Geräte bzw. Einrichtungen erhält man, um jedes Gerät in eindeutiger Weise zu identifizieren und um die Geräteeigenschaften, die mit dem Betrieb des Gerätes verbunden sind, zu beschreiben. Um Geräteinformation zu erhalten, wird ein bestimmtes Gerät auf einem ausgewählten Systembus erfaßt und daraufhin wird ihm ein Identifizierungscode zugeordnet, welcher in eindeutiger Weise das erfaßte Gerät identifiziert. Ein Systembuscode, der den ausgewählten Systembus in eindeutiger Weise identifiziert, wird dem Identifikationscode angehängt und bildet dadurch einen Geräteidentifikationscode, welcher dem betreffenden Gerät zugeordnet ist. Logische Konfigurationsdaten, welche logische Konfigurationsanforderungen für den Gerätebetrieb liefern, erhält man ebenfalls für das erfaßte Gerät. Der Datensammlungsvorgang wird wiederholt, bis man für jedes Gerät, welches mit dem ausgewählten Systembus verbunden ist, Geräteinformation erhalten hat. Ressourcen werden jedem Gerät auf der Basis des Geräteidentifikationscodes und der logischen Konfigurationsdaten zugeordnet. Dieser Vorgang der Ressourcenzuordnung verhindert einen möglicherweise kollidierenden Gebrauch der Ressourcen durch die Geräte. Ein Gerätetreiber, der Kommunikationen zwischen dem entsprechenden Gerät und dem Computersystem ermöglicht, wird identifiziert und in Reaktion auf die Geräteinformation für jedes der Geräte geladen. Wenn das Computersystem mehr als einen Systembus enthält, so werden die Aufgaben des Sammelns der Geräteinformation, der Zuordnung von Ressourcen und des Identifizierens und Ladens von Gerätetreibern für jeden der verbleibenden Systembusse abgeschlossen.
ZUSAMMENFASSUNG DER ERFINDUNG
Verschiedene Aspekte der Erfindung sind in den beigefügten unabhängigen und abhängigen Ansprüchen dargelegt.
Unter einem Gesichtspunkt stellt die Erfindung ein Verfahren zum automatischen Konfigurieren einer Einheit bereit, welche einen Bestandteil einer Vorrichtung bildet, wobei das Verfahren aufweist: Zugreifen auf in der Einheit gehaltene Klasseninformation beim Einsetzen derselben in die Vorrichtung vor dem funktionellen Integrieren der Einheit in die Vorrichtung, wobei die Klasseninformation eine Objektklasse für die Einheit repräsentiert, Verwenden der Klasseninformation, auf welche zugegriffen wurde, um in dem Speicher in der Vorrichtung, welcher von der Einheit getrennt ist, Objektdefinitionen für die Klasse der Einheit aufzurufen, wobei diese Objektdefinitionen Initialisierungscode enthalten, der nach Erhalt der Klasseninformation, auf welche zugegriffen wurde, so betreibbar ist, daß er Objektkonfigurationsaussagen für diese Einheit erzeugt, die zumindest eines der folgenden aufweist: die Objektklasse für die Einheit, eine Objektinstanznummer, einen Attributnamen und einen Wert für das Attribut; und Verifizieren der Gültigkeit der Konfigurationsinformation und, soweit die Konfigurationsinformation gültig ist, Speichern der Konfigurationsinformation in einer Konfigurationsdatei für die Vorrichtung einschließlich einer Position für die Einheit in der Vorrichtung, um die funktionelle Integration der Einheit in der Vorrichtung zu ermöglichen bzw. freizuschalten.
Unter einem weiteren Aspekt liefert die vorliegende Erfindung eine Vorrichtung, welche aufweist: eine Mehrzahl von Einheiten, die jeweils einen Einheitsspeicher für das Bereithalten von Klasseninformation für die Einheit umfassen, welche eine Objektklasse für die Einheit repräsentiert, einen Konfigurationsmechanismus, der so betreibbar ist, daß er beim Einsetzen der Einheit in die Vorrichtung auf Klasseninformation, die in der Einheit gehalten wird, zugreift, bevor die Einheit funktionell in die Vorrichtung integriert wird, wobei die Klasseninformation eine Objektklasse für die Einheit repräsentiert, und die Klasseninformation, auf welche zugegriffen wurde, verwendet, um in dem Speicher in der Vorrichtung getrennt von der Einheit Objektdefinitionen für die Klasse der Einheit aufzurufen, wobei diese Objektdefinitionen Initialisierungscode enthalten, der bei Empfang der erfaßten Klasseninformation so betreibbar ist, daß Objektkonfigurationsaussagen für die Einheit erzeugt werden, die zumindest eines der folgenden aufweisen: die Objektklasse für die Einheit, eine Objektinstanznummer, einen Attributnamen oder einen Wert für das Attribut; und um die Gültigkeit der Konfigurationsinformation zu verifizieren, und, wenn die Konfigurationsinformation gültig ist, die Konfigurationsinformation in einer Konfigurationsdatei für die Vorrichtung zu speichern, einschließlich einer Position der Einheit in der Vorrichtung, um die funktionelle Integration der Einheit in die Vorrichtung zu ermöglichen bzw. freizuschalten.
Ein Konfigurationsmanagementsystemprogramm kann auf dieser Vorrichtung so betreibbar sein, daß es die Schritte dieses Verfahrens ausführt.
Indem anfänglich auf die Klasseninformation für die Einheit zugegriffen wird und anfängliche Konfigurationsinformation (Konfigurationsstatements) aus Klasseninformation abgeleitet wird, bevor die Einheit funktionell integriert wird, kann man eine schnelle und zuverlässige Integration der Einheit erreichen.
Die Klasseninformation kann in einem nicht-flüchtigen Speicher (beispielsweise in einem EEPROM) in der Einheit gehalten werden. Diese Information kann beim Einsetzen der Einheit in das System gelesen werden und kann verwendet werden, um die anfängliche Konfiguration bereitzustellen, bevor die Integration der Einheit in das System erfolgt.
In einer Ausführungsform des Systems enthält eine Einheit Information, welche eine oder mehrere Konfigurationsmanagementsystemklassen (CMS-Klassen) für eine FRU definiert. Eine Managementklasse wird für das Verwalten der FRU gekennzeichnet bzw. identifiziert.
Eine Verifizierung der abgeleiteten Konfigurationsinformation kann verwendet werden, um die Betriebsfähigkeit und Kompatibilität der Einheit gegenüber anderen Einheiten in dem System zu überprüfen, bevor jene integriert wird.
Genauere Information bezüglich der Einheit, welche sich beispielsweise auf die Konfiguration von Geräten in der Einheit bezieht, kann in einer zweiten Stufe erfaßt werden. Beispielsweise enthält in einer Ausführungsform der Erfindung eine FRU Information, welche eine Konfigurationsmanagementsystemklasse (CMS-Klasse) für die Einheit definiert. Die Einheit kann ein oder mehrere Geräte (Ressourcen) enthalten und jedes Gerät kann ebenso seiner eigenen CMS-Klasse zugeord net sein. Die CMS-Klasseninformation für die Einheit kann erfaßt und verwendet werden, um die anfängliche Konfigurationsinformation für die Einheit abzuleiten. Die Klasseninformation für die Geräte kann dann erfaßt und für eine weitere Konfigurierungseinrichtung bzw. -Geräte verwendet werden.
Die CMS-Klasseninformation, die in der Einheit gespeichert ist, kann in Form eines Namens der Klasse der Einheit vorliegen, welcher verwendet wird, um den Konfigurationscode für die Konfigurierung dieser Klasse der Einheit zu identifizieren oder auf diese hinzuweisen. Der Konfigurationscode kann einen Teil der Objektdefinitionen (CMS-Definitionen) bilden, die außerhalb der Einheiten gehalten werden, beispielsweise in dem Computersystemspeicher, auf einer Festplatte oder an einem ferngelegenen Ort über eine Telekommunikationsschnittstelle. Die CMS-Klasseninformation führt effektiv die Funktion des Bereitstellens einer Handhabung für den Zugriff auf die Einrichtungen zum Erzeugen der anfänglichen Konfiguration aus.
Das Halten des Konfigurationscodes und der Definitionen für die Einheiten außerhalb dieser Einheiten gewährleistet eine flexible Konfiguration der Einheiten. Beispielsweise könnte eine Ethernetkarte typischerweise Information, wie z. B. ihre MAC-Adresse, die in ihr schon vorher konfiguriert ist, enthalten. Bei einer Ausführungsform der Erfindung kann diese Information stattdessen als Teil der CMS-Definition für eine Klasse und eine Instanz der Einheit gehalten werden, so daß dann, wenn eine Karte ausgetauscht wird, die Karte in einer zuverlässigen und wiederholbaren Weise unter Verwendung einer Standarddefinition konfiguriert werden kann. Durch Speichern von Konfigurationsinformation als Teil der CMSDEFs, wenn eine Karte anfänglich installiert wird, wird eine nachfolgende Konfiguration ermöglicht, wenn die Karte ausgetauscht wird und die hierfür erforderliche Information demnach bereits in dem System gehalten. Dies ist insbesondere wichtig in einem fehlertoleranten System, in welchem eine Kontinuität über Hardwarefehler, einen Austausch und eine Reparatur hinweg erforderlich ist. Demnach kann eine Ausführungsform der Erfindung eine Fehlertoleranzverwaltung ermöglichen und damit die Verwaltung von in heißem Zustand (im Betrieb) austauschbaren FRUs.
In einer Ausführungsform kennzeichnet die CMS-Klasseninformation von einer Einheit eine von einer Anzahl möglicher Definitionen (CMSDEFs) des Konfigurationsmanagementsystems (CMS), welche verwendet werden kann, um die Verwaltung dieser Einheit zu steuern bzw. zu kontrollieren. Eine CMS-Definition umfaßt Erklärungen, Attribute (einschließlich Beziehungen zu anderen Objekten), Zustandsauswertungen (Aussagen zum Auswerten der Zustände von Objekten) und Übergangscode, der ausgeführt wird, wenn ein Übergang zwischen den Zuständen eines Objekts erfolgt. Optional ist einer CMSDEF auch ein Initialisierungsskript zugeordnet, welches den Konfigurationscode bildet. Dieser Konfigurationscode kann Konfigurationsaussagen für das Objekt ausgeben. Dieses Skript kann berechtigt sein, den nicht-flüchtigen Speicher in der Einheit (beispielsweise eine FRU) abzufragen für weitere Information (beispielsweise Geräteeigenschaften, wie z. B. eine MAC-Adresse) und empfängt als Argumente die Klasse der Einheit und eine Instanz der Einheit. Die Instanznummer wird erzeugt durch eine Initialisierungskomponente des Konfigurationsmanage mentsystems (CMS) (was in der Form eines Programms vorliegen kann, welches CMSINITIALIZE genannt wird).
Um die anfängliche Konfiguration bereitzustellen, sondiert die Initialisierungskomponente jede Stelle bzw. Position in dem Gehäuse bzw. Gestell des Computersystems und liest die Klasseninformation für eine Einheit, wenn die Stelle durch eine Einheit mit einem Speicher für eine Klasseninformation besetzt ist.
Die Initialisierungskomponente leitet einen Pfadnamen für das Initialisierungsskript aus dem CMS-Managementklassennamen für die Einheit ab, welcher darin gespeichert ist. Wenn das Initialisierungsskript vorhanden ist, so wird es dem Klassennamen und der Instanznummer (dies ist eine ganze Zahl pro Klasse, die bei Null beginnt und die jedesmal dann um eins heraufgesetzt wird, wenn das Klasseninitialisierungsskript aufgerufen wird) und der Position der Einheit als Argumente.
Die Ausgangsgröße von dem Skript, die in Form eines Satzes von Objektkonfigurationsdaten für die jeweiligen Einheiten (FRUs) vorliegt, wird durch die Initialisierungskomponente aufgenommen und in einer Konfigurationsdatei gespeichert. Bei nachfolgenden Aufrufen des Systems kann diese Konfigurationsdatei verwendet werden als Quelle für die Konfigurationsinformation.
Ein Konfigurationsmanagementsystemdaemon (CMSD) kann so ausgestaltet sein, daß er auf schlechte Konfigurationsdaten empfindlich ist. Dementsprechend werden Objektkonfigurationsdaten für jedes Objekt (FRU-Gerät) an den CMSD geleitet. Der CMSD wird in einem Testbetrieb so betrieben, daß er die Objektkonfigurationsdaten verifiziert. Die Initialisierungskomponente bewahrt nur dann die Objektkonfigurationsdaten für eine bestimmte Einheit auf, wenn dies für den CMSD annehmbar ist.
Als eine Alternative zu dem Bereitstellen von CMS-Klasseninformation in Form eines Aufrufs (beispielsweise eines Namens oder eines Zeigers) zum Identifizieren von CMSDEFs und Initialisierungsskripten, die nicht in der Einheit gehalten werden, welche integriert werden soll, könnte der Speicher die CMS-DEF und die Initialisierungsskripte unmittelbar enthalten. Dies würde selbstverständlich in der FRU mehr Speicher für diese Information erfordern anstelle des Aufrufs der Information. Es würde auch die gesamte Flexibilität des Systems vermindern.
Das Initialisierungsskript könnte so ausgelegt sein, daß es auf den nicht-flüchtigen Speicher der FRU wegen weiterer Information, wie z. B. einer MAC-Adresse oder anderer FRU-spezifischer Information zugreift, die für die Konfiguration erforderlich sind.
Das Konfigurationsmanagementsystem kann in Form eines oder mehrerer Computerprogramme vorliegen, welche Computercode oder Befehle aufweisen, welche die Funktionalität des Konfigurationsmanagementsystems definieren.
Dementsprechend stellt gemäß einem Aspekt die Erfindung auch ein Trägermedium bereit, welches zumindest eine Initialisierungskomponente eines Konfigurationsmanagementsystems trägt. Die Initialisierungskomponente ist so ausgestaltet, daß sie auf Klasseninformation zugreift, welche in einer Einheit der Vorrichtung gehalten wird, und Klasseninformation verwendet, um eine anfängliche Konfiguration für die Einheit abzuleiten.
Das Trägermedium kann irgendeine Art von Trägermedium sein für das Tragen eines Computerprogrammcodes, sei es magnetisch, optisch oder in irgendeiner anderen Form der Datenspeicherung, wie z. B. als Band, Festplatte, Massivspeicher oder in irgendeiner anderen Form von Speicher, der einen wahlweisen Zugriff oder einen Nur-Lese-Zugriff oder irgendeine andere Art von Zugriff gewährt, oder ein Sendemedium, wie z. B. ein Telefonkabel, Radiowellen etc.
Die oben angegebenen Betriebsweisen werden beim Starten des Systems bewirkt. Sie könnten optional jedoch auch während des Laufs des Systems bewirkt werden, um eine Konfiguration zu ändern.
Der Speicher in der Einheit kann viel mehr Information in jedem flüchtigen Speicher enthalten, als oben beschrieben wurde.
Beispielsweise kann er zusätzlich verwendet werden, um gewisse Zustandsinformation zu speichern, welche sich auf den Systembetrieb bezieht, damit der Zustand des Systems auch über erneute Starts hinweg konsistent bleibt.
Weiterhin kann er verwendet werden, um eine Historie für die Einheit zu speichern. Diese Information könnte dann zu irgendeinem späteren Zeitpunkt offline verwendet werden (beispielsweise bei Rückgabe einer vermeintlich fehlerhaften FRU), um festzustellen, ob es die FRU ist oder möglicherweise ein Steckplatz, in welchen diese eingesetzt wurde, der fehlerhaft ist.
Auch wenn die Erfindung ihre besondere Anwendung in einem Konfigurationsmanagementsystem findet, das auf Definitionen eines Konfigurationsmanagementsystems reagiert, könnte die Erfindung ebensogut auch auf andere Arten der System- und Netzwerkverwaltung Anwendung finden. Beispielsweise könnte in der Umgebung eines Telekommunikationsverwaltungsnetzwerks (TMN) der Speicher einer Einheit (entweder direkt oder über einen Aufruf auf eine Festplattendatei) die GDMO-Definitionen der Einheit und seiner Geräte enthalten und diese könnten an einen lokalen Agenten und einen entfernten Manager bzw. Verwalter geleitet werden, um die Verwaltung der Einheit zu ermöglichen.
KURZE BESCHREIBUNG DER FIGUREN
Beispielhafte Ausführungsformen der vorliegenden Erfindung werden im nachfolgenden nur anhand eines Beispiels beschrieben, und zwar unter Bezug auf die beigefügten Zeichnungen, in welchen gleiche Bezugszeichen sich auf gleiche Elemente beziehen und von denen:
1 eine schematische Übersicht eines fehlertoleranten Computersystems ist, welches eine Ausführungsform der Erfindung verwirklicht,
2 eine schematische Übersicht einer speziellen Implementierung eines Systems ist, welches auf dem nach 1 beruht,
3 und 4 schematische Diagramme 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 Computersystemgehäuses mit austauschbaren Feldeinheiten ist, die in entsprechenden Slots angeordnet werden können,
7 eine schematische Wiedergabe zur Repräsentation eines Konfigurationsmanagementsystems der physikalischen Konfiguration nach 6 ist,
8 ein Modell einer Gerätehierarchie ist und
9 ein Modell einer Diensthierarchie ist,
10 die Beziehungen zwischen einem Konfigurationsmanagementsystemdaemon und weiteren Komponenten des Computersystems veranschaulicht,
11, 12 und 13 verschiedene Stufen beim Starten eines Konfigurationssystemdaemons wiedergeben,
14 ein Flußdiagramm ist, welches die Betriebsweise eines Prozeßmonitors veranschaulicht,
15 Einzelheiten der Betriebsweise des Prozeßmonitors zeigt,
16 ein Flußdiagramm ist, welches die Übergabe eines Prozesses zu einem anderen veranschaulicht,
17 eine schematische Wiedergabe einer FRU in einem Slot eines Gehäuses ist,
18 eine Konfigurationsdatei wiedergibt,
19 ein Beispiel von CMSDEFs und zugehörigen Instanzen und Attributen wiedergibt,
20 ein Flußdiagramm ist, welches den Vorgang der Konfigurierung einer FRU veranschaulicht.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
1 ist eine schematische Übersicht eines fehlertoleranten Computersystems 10, welches eine Mehrzahl von CPU-Sätzen (Verarbeitungssätzen) 14 und 16 und eine Brücke 12 aufweist. Wie in 1 dargestellt, gibt es zwei Verarbeitungs- bzw. Prozessorsätze 14 und 16, auch wenn in anderen Ausführungsformen drei oder mehr Verarbeitungssätze vorhanden sein könnten. Die Brücke 12 bildet eine Schnittstelle zwischen den Verarbeitungssätzen und den I/O-Geräten (Eingabe/Ausgabe-Einrichtungen), wie z. B. den Geräten 28, 29, 30, 31 und 32. In dem vorliegenden Patent wird der Begriff "Verarbeitungssatz" verwendet, um eine Gruppe eines oder mehrerer Prozessoren zu bezeichnen, die möglicherweise einen Speicher enthalten, die gemeinsame Ausgangsgrößen und Eingangsgrößen ausgeben bzw. empfangen. Es versteht sich, daß der oben erwähnte alternative Begriff "CPU-Satz" stattdessen ebenfalls verwendet werden könnte und daß diese Begriffe im Rahmen des vorliegenden Patentes austauschbar verwendet werden können. Weiterhin versteht es sich, daß der Begriff "Brücke" verwendet wird, um irgendein Gerät, eine Vorrichtung oder Anordnung zu bezeichnen, die für das Miteinanderverbinden von zwei oder mehr Bussen derselben oder unterschiedlichen Art geeignet ist.
Der erste Verarbeitungssatz 14 ist über einen I/O-Bus (PA-Bus) 24 des ersten Verarbeitungssatzes mit der Brücke verbunden, im vorliegenden Fall ein peripherer Komponentenverbin dungsbus (PCI-Bus). Der zweite Verarbeitungssatz 16 ist mit der Brücke über einen I/O-Bus (PB-Bus) 26 des zweiten Verarbeitungssatzes von demselben Typ wie der PA-Bus 24 (d. h. in diesem Fall ein PCI-Bus) verbunden. Die I/O-Geräte bzw. -Einrichtungen sind mit der Brücke über einen Geräte-I/O-Bus (D-Bus) 22 verbunden, der im vorliegenden Fall ebenfalls ein PCI-Bus ist.
Auch wenn in dem speziell beschriebenen Beispiel die Busse 22, 24 und 26 alle PCI-Busse sind, ist dies lediglich ein Beispiel und in anderen Ausführungsformen könnten andere Busprotokolle verwendet werden und der D-Bus 22 kann ein anderes Protokoll gegenüber dem PA-Bus und gegenüber dem PE-Bus (P-Busse) 24 und 26 haben.
Die Verarbeitungssätze 14 und 16 und die Brücke 12 sind synchron unter der Steuerung eines gemeinsamen Taktgebers 20 betreibbar, der mit jenen über Taktsignalleitungen 21 verbunden ist.
Einige der Geräte, welche eine Ethernet- (E-Net-) Schnittstelle 28 und eine "Small Computer System Interface"- (SCSI-) Schnittstelle 29 aufweisen, sind dauerhaft mit dem Gerätebus 22 verbunden, jedoch können andere I/O-Geräte, wie z. B. die I/O-Geräte 30, 31 und 32, in individuell geschaltete Slots 33, 34 und 35 heiß einsteckbar (im laufenden Betrieb einsteckbar) sein. Eine Umschaltung mit einem dynamischen Feldeffekttransistor (FET) kann für die Steckplätze 33, 34 und 35 bereitgestellt werden, um die Einsteckbarkeit im aktiven Zustand für die Geräte, wie z. B. die Geräte 30, 31 und 32 zu ermöglichen. Die Bereitstellung der FETs ermöglicht eine Steigerung der Länge des D-Busses 22, da nur diejenigen Geräte, die aktiv sind, eingeschaltet sind, was die effektive gesamte Buslänge vermindert. Es versteht sich, daß die Anzahl von I/O-Geräten, die mit dem D-Bus 22 verbunden sein können, und die Anzahl von für diese bereitgestellten Slots (Steckplätzen) entsprechend einer bestimmten Implementierung gemäß besonderen Modellerfordernissen eingestellt werden können.
2 ist eine schematische Übersicht einer besonderen Implementierung eines fehlertoleranten Computers, der eine Brückenstruktur derart verwendet, wie sie in 1 dargestellt ist. In 2 umfaßt das fehlertolerante Computersystem eine Mehrzahl (hier vier) von Brücken 12 auf ersten und zweiten I/O-Hauptplatinen (Motherboards) (MB40 und MB42), um die Anzahl von I/O-Geräten, die angeschlossen werden können, zu erhöhen, und auch um die Zuverlässigkeit und Redundanz zu verbessern. Demnach sind in der in 2 dargestellten Ausführungsform zwei Verarbeitungssätze 14 und 16 jeweils auf einer entsprechenden Verarbeitungssatzplatine 44 und 46 vorgesehen, wobei die Verarbeitungssatzplatinen 44 und 46 die I/O-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 den 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 40 montiert. Die erste Brücke 12.1 ist mit den Verarbeitungssätzen 14 und 16 durch P-Busse 24.1 bzw. 26.1 verbunden. In ähnlicher Weise ist die zweite Brücke 12.2 mit den Verarbeitungssätzen 14 und 16 durch P-Busse 24.2 bzw. 26.2 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 und 16 durch P-Busse 24.3 bzw. 26.3 verbunden. In ähnlicher Weise ist die Brücke 12.4 mit den Verarbeitungssätzen 14 und 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 über die D-Busse 22.1, 22.2, 22.3 und 22.4 mit den beiden Verarbeitungssätzen 14 und 16 verbunden werden, um entweder den Bereich von verfügbaren I/O-Geräten zu vergrößern oder um ein höheres Maß an Redundanz bereitzustellen, oder beides.
3 ist eine schematische Übersicht einer möglichen Konfiguration eines Verarbeitungssatzes, wie z. B. des Verarbeitungssatzes 14 in 1. Der Verarbeitungssatz 16 könnte dieselbe Konfiguration haben. In 3 ist eine Mehrzahl von Prozessoren (hier vier) 52 durch einen oder mehrere Busse 54 mit einer Bussteuerung 50 des Verarbeitungssatzes verbunden. Wie in 3 dargestellt, sind ein oder mehrere Ausgangsbusse 24 des Verarbeitungssatzes mit der Bussteuerung 50 des Verarbeitungssatzes verbunden, wobei jeder Ausgangsbus 24 eines Verarbeitungssatzes mit einer entsprechenden Brücke 12 verbunden ist. Beispielsweise würde in der Anordnung nach 1 ein I/O-Bus (P-Bus) 24 eines Verarbeitungssatzes vorgesehen werden, während in der Anordnung nach 2 vier derartige I/O-Busse (P-Busse) 24 vorgesehen werden würden. In dem in 3 dargestellten Verarbeitungssatz 14 arbeiten individuelle Prozessoren unter Verwendung des gemeinsamen Speichers 56 und empfangen Eingaben über den bzw. die gemeinsamen P-Bus(se).
4 zeigt eine alternative Konfiguration eines Verarbeitungssatzes, wie z. B. des Verarbeitungssatzes 14 nach 1. Hier enthält ein einfacher Verarbeitungssatz einen einzigen Prozessor 72 und einen zugehörigen Speicher 76, die über einen gemeinsamen Bus 24 mit einer Bussteuerung 70 eines Verarbeitungssatzes verbunden sind. Die Bussteuerung 70 des Verarbeitungssatzes stellt eine Schnittstelle zwischen dem internen Bus 74 und dem bzw. den I/O-Bussen) des Verarbeitungssatzes (P-Bus(se)) 24 für die Verbindung mit der Brücke/den Brücken 12 bereit.
Dementsprechend versteht es sich auf Grundlage der 3 und 4, daß der Verarbeitungssatz viele verschiedene Formen annehmen kann und daß die spezielle Wahl einer bestimmten Verarbeitungssatzstruktur auf Basis der Verarbeitungserfordernisse einer bestimmten Anwendung im Hinblick auf das Maß der erforderlichen Redundanz erfolgen kann. In der folgenden Beschreibung wird angenommen, daß die Verarbeitungssätze 14 und 16, auf welche Bezug genommen wurde, eine Struktur haben, wie sie in 3 dargestellt ist, auch wenn es sich versteht, daß irgendeine andere Form eines Verarbeitungssatzes vorgesehen werden könnte.
Die Brücke(n) 12 kann bzw. können in einer Anzahl von Arbeitsweisen betrieben werden. In einem ersten, kombinierten Betriebszustand ist die Brücke 12 in der Lage, so zu arbeiten, daß sie Adressen und Daten zwischen den Verarbeitungssätzen 14 und 16 (über die PA- und PB-Busse 24 bzw. 26) und die Geräte (über den D-Bus 22) zu leiten. In diesem kombinierten Betrieb werden I/O-Zyklen, die durch die Verarbeitungssätze 14 und 16 erzeugt werden, verglichen, um sicherzustellen, daß beide Verarbeitungssätze korrekt arbeiten. Vergleichsfehler zwingen die Brücke 12 in einen Fehlerbegrenzungszustand (E-Zustand – E-State), in welchem eine Geräte-I/O (Geräte-Eingabe/Ausgabe) verhindert wird und diagnostische Information aufgenommen 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 Betrieb sind die Verarbeitungssätze 14 und 16 nicht synchronisiert und es werden keine I/O-Vergleiche vorgenommen. DMA-Vorgänge sind ebenfalls in beiden Betriebszuständen zulässig.
5 ist eine schematische Funktionsübersicht der Brücke 12 nach 1.
Erste und zweite Verarbeitungssatz-I/O-Busschnittstellen, die PA-Busschnittstelle 84 bzw. 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 versteht sich, daß die PA-, PB- und D-Busschnittstellen nicht als getrennte Elemente ausgestaltet werden müßten, sondern in andere Elemente der Brücke inkorporiert sein könnten. Dementsprechend erfordert, soweit im Kontext des vorliegenden Patentes Bezug genommen wird auf eine Busschnittstelle, dies nicht das Vorhandensein eines speziellen, getrennten Bauteils, sondern stattdessen die Fähigkeit der Brücke, den betreffenden Bus anzuschließen, beispielsweise mit Hilfe von physikalischen oder logischen Brückenverbindungen für die Leitungen der betreffenden Busse.
Eine Routingeinrichtung (im folgenden 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, ein Leiten einer I/O-Bustransaktion in beiden Richtungen zwischen den PA- und PB-Busschnittstellen 84 und 86 bereitzustellen. Sie ist auch in der Lage, ein Leiten bzw. Routing 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 steuert den Zugriff auf Brückenregister 110 und auf einen Speicher (SRAM) 126 mit wahlweisem Zugriff. Die Routingmatrix 80 ist daher auch derart betreibbar, daß sie ein Routing in beiden Richtungen zwischen den PA-, PB- und D-Busschnittstellen 84, 86 und 82 und der Speichersteuerlogik 90 bereitstellen kann. Die Routingmatrix 80 wird durch die Brückensteuerlogik 88 über Kontrollpfade 98 und 99 gesteuert. Die Brückensteuerlogik 88 reagiert auf Steuersignale, Daten und Adressen auf internen Pfaden 93, 95 und 97 und auch auf Taktsignale auf der (bzw. den) Taktleitungen) 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 des Verarbeitungssatzes (siehe 3) arbeiten ebenfalls unter dem 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, die zu und von dem D-Bus 22 oder internen Speichern und Registern in dem Speicherteilsystem 90 übertragen werden, bereitstellt. Die Busschnittstellen 84 und 86 können diagnostische Information für die internen Brückenstatusregister in dem Speicherteilsystem 90 beim Übergang der Brücke in einen Fehlerzustand (E-State) oder bei Erfassung eines I/O-Fehlers bereitstellen.
Die Gerätebusschnittstelle 82 führt die gesamte Funktionalität aus, die für eine PCI-kompatible Master- und Slave-Schnittstelle für das Übertragen von Daten zu und von den PA- und PB-Bussen 84 und 86 erforderlich ist. Der D-Bus 82 ist während Übertragungen mit einem direkten Speicherzugriff (DMA) so betreibbar, daß er diagnostische Information für interne Statusregister in dem Speicherteilsystem 90 der Brücke beim Übergang in einen E-Zustand (E-State) oder bei Erfassung eines I/O-Fehlers bereitstellt.
6 ist eine schematische Übersicht eines Gehäuses 200 mit den verschiedenen Slots bzw. Steckplätzen für die Aufnahme von austauschbaren Feldeinheiten (FRUs) einschließlich Bauteilen oder Geräten des fehlertoleranten Rechnersystems 10, welches unter Bezug auf die 1 bis 5 beschrieben wurde. 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 Stellen 201 und 203 in der Ansicht gemäß 6 in den oberen und unteren Abschnitten des Gehäuses 200 montiert. Die ersten und zweiten Prozessorsätze 44 und 46, welche ebenfalls FRUs bilden, sind an Positionen 45 und 47 montiert, welche die Hauptplatinen bzw. Motherboards 40 und 42 überbrücken.
Andere austauschbare Feldeinheiten, die in 6 dargestellt sind, sind abnehmbare Media-Modul-FRUs 210, die in den Slots 211 montiert sind. FRUs 212 mit Festplattenantriebsgehäuse sind in den Slots 213 montiert. Die Festplattenlaufwerke in dem Gehäuse 212 des Festplattenlaufwerks sind typischerweise als FRUs ausgestaltet. Konsole- und Gebläse- (CAF-) FRUs 214, die Schalter, Anschlüsse, Alarmeinrichtungen und LEDs aufweisen, sind in den Slots 215 montiert. PCI-Rahmen-FRUs 216 sind in den Slots 217 montiert. Die PCI-Karten in dem PCI-Rahmen sind ebenfalls als FRUs konfiguriert. Stromversorgungs-FRUs 218 sind in weiteren Slots 219 montiert. Unteraufbauten (nicht dargestellt) der Stromversorgungs-FRUs 218 könnten ebenfalls vorgesehen und als FRUs ausgestaltet sein.
Die FRUs zum Einsetzen in den verschiedenen Slots sind mit einem Identifikationsetikett (beispielsweise DSK) 232 versehen. Ein entsprechendes Etikett (beispielsweise A-DSK) 234 ist jedem Slot zugeordnet, um dem Benutzer anzuzeigen, wo die jeweilige FRU angeordnet werden soll. In einer Ausführungsform der Erfindung weist eine FRU einen Speicher 230 (beispielsweise einen nicht-flüchtigen Speicher, wie z. B. ein EEPROM) auf, um Information aufzunehmen, die sich auf die FRU und das Gerät/die Geräte bezieht, das bzw. die sie trägt. Wie später noch beschrieben wird, umfaßt diese Information Klasseninformation des Konfigurationsmanagementsystems für die FRU für die Verwendung durch ein Konfigurationsmanagementsystem (CMS) 400 (welches in 6 nicht dargestellt ist), um die FRU in dem System zu konfigurieren. Es versteht sich, daß eine Ausführungsform der Erfindung zusätzlich zu den FRUs, welche einen Speicher 230 enthalten, auch einige Einheiten enthalten kann, die in dem Feld austauschbar sind, z. B. ein Festplattenlaufwerk, welche jedoch möglicherweise nicht mit einem Speicher 230 ausgerüstet sind. Dies kann wünschenswert sein, wenn beispielsweise aus ökonomischen Gründen 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 modelliert nicht das Systemgehäuse. Das CMS modelliert jedoch die FRUs und die Geräte darin. Das CMS gibt modellhaft eine inhaltliche Hierarchie der FRUs wieder. 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 Verarbeitungssätzen wird durch die Systemhierarchie für das Teilsystem des Prozessors angezeigt.
Wie in 7 dargestellt, entwirft das CMS ein Modell des Verarbeitungssatzes 14 mit den zugehörigen Verarbeitungssatzgeräten 52, 56 etc. (siehe 3–5, die von der ersten Hauptplatine 42 abhängig sind). Ebenfalls wird in dem Modell als von der ersten Hauptplatine 42 abhängig ein erstes Festplattengehäuse 240 mit zugehörigen Festplattenlaufwerken 244 wiedergegeben. CAF-FRUs 250 mit zugehörigen CAF-Geräten 254 sind ebenfalls als abhängig von der ersten Hauptplatine 42 abhängig modellhaft wiedergegeben, ebenso wie auch PCI-Adapter 260 und die zugehörigen PCI-Geräte 264. Eine FRU für abnehmbare Medien (RMM) 270 und die zugehörigen Mediengeräte (die beispielsweise ein Band- und CD-ROM-Laufwerke enthalten) 274, werden weiterhin in dem Modell als von der ersten Hauptplatine 42 abhängig wiedergegeben, ebenso wie auch die Stromversorgungseinheiten 280 (möglicherweise auch mit Teilsystemen 284 der Stromversorgung). Die verschiedenen Hauptplatinengeräte 292 der ersten Hauptplatine 42 werden durch das CMS ebenfalls modellhaft wiedergegeben.
Das CMS entwirft ein Modell des Verarbeitungssatzes 16 mit den zugehörigen Verarbeitungssatzgeräten 52, 56 etc. (siehe 3–5) als von der zweiten Hauptplatine 44 abhängig. Ebenfalls ist als von der zweiten Hauptplatine 44 abhängig ein zweites Festplattengehäuse 242 in dem Modell mit zugehörigen Festplattenlaufwerken 246 wiedergegeben. CAF-FRUs 252 mit zugehörigen CAF-Geräten 256 sind in dem Modell ebenfalls als von der zweiten Hauptplatine 44 abhängig wiedergegeben, wie auch die PCI-Adapter 262 und die zugehörigen PCI-Geräte 266. Eine FRU für herausnehmbare Medien (RMM) 272 und zugeordnete Mediengeräte (die beispielsweise ein Bandlaufwerk und ein CD-ROM-Laufwerk umfassen) 276, sind ebenfalls als von der zweiten Hauptplatine 44 abhängig modellhaft wiedergegeben, wie auch die Stromversorgungseinheiten 282 (möglicherweise auch mit Teilsystemen 286 der Stromversorgung). Die verschiedenen Hauptplatinengeräte 294 der zweiten Hauptplatine 44 sind ebenfalls durch das CMS modellhaft wiedergegeben.
In 7 veranschaulichen die durchgezogenen Linien (beispielsweise 296) die Abhängigkeiten der FRU-Bestandteile von den Hauptplatinen 42 und 44, wobei man im Hinterkopf behalten muß, daß die Hauptplatinen ebenfalls FRUs sind. Die gestrichelten Linien (beispielsweise 298) veranschaulichen die Abhängigkeit von Gerätebestandteilen von den FRU-Bestandteilen.
8 ist eine schematische Wiedergabe des Modells bzw. der Modellierung einer Gerätehierarchie durch das CMS. Die Gerätehierarchie ist von der unter Bezug auf 7 beschriebenen FRU-Hierarchie unabhängig und hängt von der physikalischen Anordnung bzw. Auslegung der FRUs ab, da unterschiedliche Geräte von unterschiedlichen FRUs abhängig sein können. Das CMS erzeugt diese Gerätehierarchie aus der Klasseninformation und möglicherweise weiterer Information, die aus dem nicht-flüchtigen Speicher auf den FRUs gelesen wird.
Das CMS gibt modellhaft Teile von einem Teil des Gerätebaums wieder, wobei die verschiedenen Elemente als Knoten oder Objekte in dem Baum dargestellt sind. Demnach ist ein erster Knoten oder Objekt 300, welcher die Brücke repräsentiert, mit individuellen Knoten oder Objekten 302 verbunden, welche Slotsteuerungen repräsentieren. In ähnlicher Weise sind individuelle Geräte, wie z. B. die Geräte D0, D1, D2 und D3, die durch Knoten oder Objekte 304 dargestellt werden, mit einem Slotobjekt 302 verbunden. Das CMS ist in der Lage, diesen Baum zu verwenden, um mit individuellen Gerätetreibern zu kommunizieren und es ermöglicht dem CMS, die Abhängigkeiten zwischen den Geräten im Modell wiederzugeben.
9 zeigt eine Diensthierarchie. Diensthierarchien können definiert werden durch einen Dienst 310, der als ein Knoten oder Objekt innerhalb der Diensthierarchie dargestellt wird. Ein Dienst kann beispielsweise ein Teilsystem, wie z. B. ein fehlertolerantes Kernsystem definieren. Die Dienste definieren eine Systemverfügbarkeit und sind von den Geräten des Systems abhängig. Geräte werden ebenfalls durch Knoten oder Objekte 312 in der Diensthierarchie definiert. Wie in 9 dargestellt, sind Abhängigkeiten zwischen einzelnen Geräten 312, wie z. B. den Geräten D0 und D1 und dem Dienst 310 dargestellt. Die Diensthierarchie könnte automatisch abgeleitet werden, kann aber ebensogut auch manuell abgeleitet werden.
Die Kombination der Hierarchien, die in den 7, 8 und 9 dargestellt sind, bilden das Modell des Konfigurationsmanagementsystems (CMS), welches verwendet wird, um den Betrieb des Systems 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, Fehlertoleranz auf einem hohen Niveau zu unterstützen. Es ermöglicht Benutzern, die verschiedenen Komponenten des Systems so zu konfigurieren, daß sie die gewünschten Funktionen ausführen, und das Funktionieren des Systems zu überblicken.
10 veranschaulicht die Beziehung zwischen einem Daemon eines Konfigurationsmanagementsystems CMSD 400 und verschiedenen Komponenten des Systems. Der CMSD 400 ist ein Daemon für die Implementierung des Control Management Systems (Verwaltungssteuerungssystem) des Computersystems, welches in den früheren Figuren dargestellt wurde. Ein Daemon ist ein Verwaltungsvorgang im Hintergrund. Ein solcher Vorgang bzw. Prozeß kann zu irgendeinem Zeitpunkt, und zwar beginnend mit der Systeminitialisierung, bis zum Abschalten verfügbar sein.
Der CMSD 400 verwaltet verschiedene Systemgrößen (Objekte), die physikalische Geräte und/oder Softwaregrößen sein können. Der CMSD 400 ist über einen UNIX-Anschluß angeschlossen, welcher eine Anwendungsprogrammschnittstelle (API) 446 zu einem oder mehreren Anwen dungsprogrammen 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 angegeben. Die CMSDEFs enthalten Erklärungen für Objekte, die durch den CMSD 400 verwaltet werden, Zustandsauswertungen (Aussagen für das Auswerten der Zustände von Objekten), und Übergangscode, der ausgeführt wird, wenn ein Übergang zwischen den Zuständen eines Objekts erfolgt. Die CMSDEFs 410 kann man sich ähnlich wie einen Satz von Zustandsmaschinen für die Objekte vorstellen, die durch den CMSD 400 verwaltet werden, wobei der CMSD 400 die Zustandsmaschinen ausführt bzw. steuert.
Eine Initialisierungskomponente 402 des CMS arbeitet bei einer ersten Initialisierung des CMS so, daß sie ein Modell des Systems erzeugt, wie es unter Bezug auf die 7, 8 und 9 beschrieben wurde, und es speichert dieses in einer Konfigurationsdatei 404. Die Konfigurationsdatei 404 bildet eine dauerhafte Kopie des Modells, welche durch den aktuellen Aufruf des CMSD und auch bei nachfolgenden Neustarts oder neuer Initialisierung des Systems verwendet werden kann, unter der Annahme, daß die Konfiguration sich nicht geändert hat oder die Konfigurationsdatei nicht verloren gegangen oder beschädigt worden ist.
Die Speicherung des Modells in einer derart dauerhaften Weise kann Initialisierungszeit einsparen, da es nicht notwendig ist, den Vorgang des Neuerzeugens des Modells erneut zu durchlaufen. Es kann auch eine Konsistenz zwischen Systeminitialisierungen gewährleisten. Im Ergebnis kann dies in einem fehlertoleranten System eine bessere Erfassung von Fehlern ermöglichen, wenn zwischen Systeminitialisierungen Systemelemente ausgefallen sind oder sich verändert haben.
Der CMSD 400 ist wirksam mit verschiedenen Systemgrößen verbunden, die durch den CMSD 400 verwaltet werden. Diese Größen bzw. Einheiten können physikalische Geräte 420 (beispielsweise Festplattenlaufwerke 422 und 424) oder Softwaregrößen bzw. -gegenstände (beispielsweise Datenbanken 432 und 434) enthalten. Wie nachstehend beschrieben wird, gehört zu dem CMSD 400 eine eindeutige Prozessoridentifizierung (PID) 450, welche der CMSD an einer Speicherstelle oder Datei 452 speichert, die für einen Überwachungsprozeß bekannt ist, wenn der CMSD erfolgreich startet bzw. initiiert. Die Betriebsweise des CMSD 400 wird durch eine Prozeßüberwachung 460 überwacht, welche die durch den CMSD 400 in der Datei 452 gespeicherte PID 450 verwendet. Der Prozeßmonitor 460 ist als ein Überwachungsprozeß (Programm) ausgestaltet, welches auf dem Computersystem lauffähig ist. 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 ebenso in einem Systemregister oder in einem Speicher gehalten werden.
Die Prozeßüberwachung 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 tatsächlich eindeutig für den aktuellen Aufruf des CMSD 400 und ist nicht zu verwechseln mit einem einfachen Namen, der verschiedenen Versionen des CMSD 400 zugeordnet werden könnte, oder mit irgendeinem anderen Vorgang oder Programm, der sich als der CMSD 400 maskiert. Die Prozeßüberwachung 460 verwendet dann die PID 450 aus der Datei 452, um auf Zustandsinformation zuzugreifen, welche durch die 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 Teil der Ressourcen des Betriebssystems 475 des Computersystems. Die Zustandsinformation an der Stelle 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 gesteuert wie irgendein beliebiger Systemdaemon durch einen Systemvorgang beim Starten bzw. Herauflaufen des Systems. Im Anschluß daran wird die Prozeßüberwachung 460 gestartet. Die Prozeßüberwachung ist dann in der Lage, den CMSD 400 auf Fehler hin zu überwachen. Wenn der Prozeßmonitor 460 einen Fehler oder Ausfall des CMSD 400 feststellt, so löst er einen Neustart des CMSD 400 aus.
Die 11–13 veranschaulichen verschiedene Schritte zum Neustarten des CMSD 400. In einem ersten Schritt, der in 11 dargestellt ist, startet die Prozeßüberwachung 460 CMSD 400 im Anschluß an die Erfassung eines CMSD-Ausfalls bzw. -Fehlers, welcher dann fortfährt, um zu überprüfen, daß er betriebsbereit ist (d. h. daß er in der Lage ist, erfolgreich zu arbeiten oder zu funktionieren). Dies kann die Überprüfung umfassen, daß die verschiedenen Daten, auf welchen er beruht, verfügbar sind, und kann in eine Datenbank eingebaut sein (wenn dies nicht schon geschehen ist). Der neue CMSD ist auf dieser Stufe kritisch bezüglich seines eigenen Betriebs und zeigt einen Fehler an, wenn irgendwelche Inkonsistenzen oder Auslassungen erfaßt werden. An diesem Schritt in dem Prozeß erfolgt ein Austausch 460 eines Handschlags zwischen dem CMSD 400 und der Prozeßüberwachung 460, um zu testen, ob der CMSD 400 erfolgreich arbeitet bzw. ausgeführt wird, oder nicht.
12 veranschaulicht einen zweiten Schritt bei der Initialisierung des CMSD 400. Dieser Schritt wird erreicht, wenn der CMSD festgestellt hat, 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ßüberwachung 460, daß er betriebsbereit ist. An der vorbestimmten Stelle oder Datei 452 befindet sich eine Speicherstelle oder Datei, welche die Prozeßüberwachung 460 kennt.
13 veranschaulicht den Betriebszustand der Prozeßüberwachung 460 und des CMSD 400 im Anschluß an die Initialisierung des CMSD 400. Die Prozeßüberwachung 460 ist so betreibbar, daß sie auf die PID 450 in der Datei 452 zugreift und die PID 450 aus der Datei 452 verwendet, um auf die Zustandsinformation 472 des Prozesses zuzugreifen, welche durch die CMSD-PID in der Prozeßtabelle 470 des Betriebssystems identifiziert wird.
Wie oben beschrieben, wird der CMSD 400 durch einen standardmäßigen Systemstartvorgang gestartet, bevor die Prozeßüberwachung 460 gestartet wird. Es wäre jedoch möglich, die Prozeßüberwachung zuerst zu starten und dann der Prozeßüberwachung 460 zu erlauben, das Fehlen eines CMSD zu entdecken und den CMSD wie oben unter Bezug auf die 11–13 beschrieben, zu starten.
14 veranschaulicht die Betriebsweise der Prozeßüberwachung 460 für das Verifizieren der korrekten Arbeitsweise des CMSD 400.
Die Prozeßüberwachung 460 ist zu vorbestimmten Zeiten betriebsbereit bzw. betreibbar (wie es durch Schritt S1 angegeben wird), um den aktuellen Zustand des CMSD 400 zu testen. Dieser Test könnte ausgeführt werden nach einem vorbestimmten Intervall und/oder nachdem spezifizierte Systemereignisse aufgetreten sind.
In Schritt S2 versucht der Überwachungsvorgang 460, die PID 450 für den CMSD 400 aus der vorbestimmten Dateistelle 452 wiederzugewinnen. Wenn der überwachte Prozeß 400 aus irgendeinem Grund nicht in der Lage ist, die PID 450 zu erhalten, so wird in Schritt S5 ein Alarm vorgebracht und es wird versucht, in Schritt S6 den CMSD 400 erneut zu starten.
Wenn die PID 450 von der Stelle 452 erhalten wird, wird die Gültigkeit der PID 450 in Schritt S3 überprüft. Wenn der Gültigkeitstest mit der PID negativ ist, so wird in Schritt S5 der Alarm A vorgebracht und es wird versucht, den CMSD 400 in Schritt S6 erneut zu starten.
Wenn der Gültigkeitstest mit der PID 450 positiv ist, so geht die Prozeßüberwachung 460 dann weiter in Schritt 4 mit der Verwendung der PID 450, um den Zustand des CMSD 400 zu überprüfen, indem auf Zustandsinformation des CMSD 400 an einer Stelle 472 zugegriffen wird, welche durch die PID 450 in der Prozeßtabelle 470 des Betriebssystems identifiziert wird.

Die Prozeßüberwachung 460 ist in der Lage, verschiedene Zustände für den CMSD 400 zu erkennen. Diese umfassen die Zustände:

CMSD_ok	CMSD läuft korrekt
CMSD_unknown	CMSD-Zustand kann nicht bestimmt werden
CMSD_dead	CMSD ist "gestorben"
CMSD_slow	CMSD scheint zu leben, reagiert aber nicht
system_error	Es gibt einen Systemfehler, der die CMSD-Tests beeinflußt
CMSD_restart	Es ist ein Neustartfehler aufgetreten

Wenn die Prozeßüberwachung 460 festgestellt hat, daß der CMSD korrekt läuft, geht die Kontrolle zurück von Schritt S4 zu Schritt S1, wo die Prozeßüberwachung 460 wartet, bis der nächste Test bezüglich des Betriebs des CMSD 400 ausgeführt werden muß.
Wenn der Prozeßmonitor 460 in Schritt S4 festgestellt hat, daß der CMSD tot zu sein scheint, so wird in Schritt S5 ein Alarm A vorgebracht und es wird ein Versuch unternommen, den CMSD 400 in Schritt S6 erneut zu starten. Optional kann die Prozeßüberwachung 460 so betreibbar sein, daß sie einen Alarm setzt und in Schritt S5 eine Warnung aussendet. Die Prozeßüberwachung 460 ist dann so betreibbar, daß sie in Schritt S6 versuchen kann, den CMSD 400 erneut zu starten, wenn der CMSD-Status als einer identifiziert wird, der irgendein anderer ist als derjenige, in welchem der CMSD 400 korrekt zu laufen scheint.
15 veranschaulicht den Schritt S6 in 14 genauer. Dies entspricht im wesentlichen dem in den 11, 12 und 13 wiedergegebenen Vorgang.
In Schritt S6.1 startet die Prozeßüberwachung 460 den CMSD 400. In Schritt S6.2 führt der CMSD 400 selbst Tests durch, wie sie unter Bezug auf 11 oben beschrieben wurden. Wenn der CMSD 400 nicht betriebsbereit ist, so geht der CMSD 400 in Schritt S6.3 aus (exit) und dem Monitor bzw. der Überwachung wird die Anzeige eines Fehlers (d. h. ein Wert, der nicht gleich Null ist) übermittelt. Wenn alternativ der CMSD 400 betriebsbereit ist, so verzweigt der CMSD 400 in Schritt S6.4. Der Tochter-CMSD 400 arbeitet dann in Schritt S6.5 und stellt geeignete CMSD-Dienste bereit. In Schritt S6.6 schreibt der Mutter-CMSD 400 die PID des Tochter-CMSD in die PID-Datei. Die Mutter-CMSD 400 geht dann in Schritt S6.7 hinaus (Exit) und liefert eine Erfolgsanzeige (z. B. einen Wert Null), daß sie korrekt mit der Prozeßüberwachung 460 läuft. In Schritt S6.8 löscht die Prozeßüberwachung 460 den Alarm und sendet eine Nachricht über einen erfolgreichen Neustart. Ansonsten wird der Alarm nicht gelöscht und es wird eine Fehlernachricht erzeugt, um eine Intervention durch einen Systemoperator anzufordern. Man erkennt, daß als Ergebnis des obigen Verfahrens der CMSD "selbst in den Hintergrund geht" (d. h. er verzweigt und dann geht die Mutter aus (exit)), so daß die Überwachung nicht die Mutter ist.
In dem in 14 dargestellten Vorgang wird in Schritt S4 ein einfacher Test bezüglich des aktuellen Zustandes des CMSD 400 ausgeführt, in dem die Prozeßüberwachung 460 sich auf eine Prozeßtabelle 470 bezieht. Als Alternative könnte dieser Test ersetzt werden durch einen Test, in welchem die Prozeßüberwachung 460 versucht, eine Verbindung zu dem CMSD 400 herzustellen und auf einen zurückgelieferten Wert, welcher anzeigt, ob der CMSD aktiv ist oder nicht, reagiert. Auch wenn dieser eher direkte Ansatz ein höheres Maß an Sicherheit bezüglich der Frage bietet, ob der CMSD 400 korrekt arbeitet oder nicht, so beinhaltet er doch eine höhere Systemüberlast (Overhead) als der einfachere Test der Überprüfung der Prozeßtabelle 470 des Betriebssystems. Dementsprechend ist in der vorliegenden Ausführungsform der Erfindung der einfache Test, der eine ausreichende Zuverlässigkeit bietet, bevorzugt.
Es versteht sich, daß der CMSD 400 einen Prozeß verwendet, der ähnlich dem in 15 dargestellten ist, um die Steuerung an einen neuen CMSD 400 in einer Situation zu übergeben, in welcher beispielsweise die CMSDEFs 410 verändert werden. Der durch den CMSD 400 verwendete Prozeß, der in 16 dargestellt wird, stellt sicher, daß die Prozeßüberwachung 460 in zuverlässiger Weise über die Übertragung der Steuerung von dem alten CMSD 400 an 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 CMSD-Prozeß in der mittleren Spalte und für den Überwachungsprozeß in der rechten Spalte. Die Zeit schreitet in 16 von oben nach unten voran.
In 16 sei angenommen, daß ein existierender (alter) CMSD bei S11 arbeitet, wenn neue CMSDEFs 410 bei S21 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 überprüft, daß der alte CMSD korrekt arbeitet. Ein Aufruf des CMSD 400 ist mit einem bestimmten Satz von CMSDEFs 410 verbunden, um einen Schutz gegenüber Fehlern in den CMSDEFs 410 zu bieten. Demnach ist es für einen neuen CMSD 400 notwendig, daß er in der Weise bereitgestellt wird, daß er die neuen CMSDEFs 410 handhabt. Entsprechend wird in Schritt S22 ein neuer CMSD 400 angelegt.
Der neue CMSD 400 führt dann in Schritt S23 wie zuvor die Selbsttests aus. Wenn der neue CMSD nicht betriebsbereit ist, so schaltet der neue CMSD bei Schritt S24 sich aus (Exit). Beispiele von Situationen, in welchen ein neuer Aufruf des CMSD 400 möglicherweise nicht korrekt ausgeführt werden kann, liegen dann vor, wenn ein Fehler in den neuen CMSDEFs 410 vorliegt oder möglicherweise dann, wenn ein Fehler in einer neuen Version des CMSD 400 vorliegt.
Alternativ führt der neue CMSD 400, wenn er betriebsbereit ist, gemäß den Schritten S12/S25 mit dem alten CMSD 400 einen Handschlag 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 sich aus (Exit). In Schritt S28 läuft daher der neue CMSD.
Wenn nach Schritt S26 der Überwachungsvorgang 460 die PID aus der PID-Datei liest, so findet er die PID 450.1 für den neuen CMSD und überprüft dann, ob der neue CMSD korrekt arbeitet.
Anhand des vorstehenden Verfahrens kann man auch erkennen, daß der neue CMSD in effektiver Weise "sich im Hintergrund hält" und daß die Überwachung nicht die Mutter ist.
Wie oben erwähnt, reagiert der CMSD 400 auf die CMSDEFs 410 für die aktuelle Konfiguration des zu verwaltenden Systems und kann so betrieben werden, daß er diese ausführt. Die CMSD-Definitionen 410 können von einer Festplatte bereitgestellt werden oder von einem anderen Speichermedium, welches Teil des Systems bildet, oder sie können von einer ferngelegenen Quelle zugeführt werden. Konfigurationssoftware in Form von Skripten kann ebenfalls verwendet werden, um Konfigurationsaussagen für die Konfigurierung des CMSD 400 zu erzeugen. Die Konfigurationsskripte können auch von einer Festplatte oder einem anderen Speichermedium bereitgestellt werden, welches Teil des Systems bildet, oder sie können von einer ferngelegenen Quelle zugeführt werden. Die CMSDEF-Skripte können auch von einem nicht-flüchtigen Speicher in den FRUs bereitgestellt werden, die in die Steckplätze in dem Gehäuse des Systems eingesetzt sind. Die Prozeßüberwachung und/oder der überwachte Prozeß (CMSD) können in Form von Computerprogrammen vorliegen, die Computercode oder -befehle verwenden, welche die Funktionalität der Prozeßüberwachung bzw. des überwachten Prozesses definieren. Die Prozeßüberwachung und/oder der CMSD können auf einem Trägermedium bereitgestellt werden. Das Trägermedium kann irgendeine Form eines Trägermediums sein, um Computerprogrammcode zu tragen, sei es magnetisch, optisch oder in irgendeiner anderen Form von Datenspeicherung, wie z. B. ein Band, eine Festplatte, ein Festkörperspeicher oder irgendeine andere Form von Speicher, der einen wahlfreien Zugriff oder einen Nur-Lese-Zugriff oder irgendeine andere Form des Zugriffs gewährt, oder es kann ein Übertragungsmedium, wie z. B. ein Telefondraht, Radiowellen etc. sein.
Es folgt nunmehr 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 Steckplätze des Gehäuses 200 des Systems eingesteckt sind.
Wie zuvor schon erwähnt, dient das Konfigurationsmanagementsystem der vorliegenden Ausführungsform dazu, eine Fehlertoleranzüberwachung für das fehlertolerante Computersystem auf hohem Niveau bereitzustellen, indem es die Wechselwirkungen zwischen den Elementen des Systems modellhaft darstellt und in der Tat die Konfiguration des Systems in Reaktion auf Benutzererfordernisse 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 als Ganzes muß konfiguriert werden beispielsweise hinsichtlich der Wechselwirkungen zwischen den Einheiten und/oder den Geräten.
Ein vorteilhaftes Verfahren der Autokonfiguration solcher Komponenten wird nachstehend beschrieben.
17 veranschaulicht eine FRU 214, die in einen Steckplatz 215 in dem Gehäuse 200 eingesetzt wird. Man kann erkennen, daß die FRU 214 ein Etikett 234 trägt, welches zu einem Etikett 232 neben dem Steckplatz 215 passend ausgestaltet sein kann, um die 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 Konfigurationsinformation enthält, die durch den CMSD 400 verwendet werden soll, damit er die FRU 214 und ihre zugehörigen Geräte 236 und 238 korrekt konfiguriert. 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.DEV0.NAME = CDROM
EE.MSP.DEV0.SCSIID = 0
EE.MSP.DEV1.NAME = TAPE (BAND)
EE.MSP.DEV1.SCSIID = 1
Bei einer FRU nach dem Stand der Technik wäre nur der Nummernteil aus der oben angezeigten Information vorhanden. In dieser Ausführungsform enthält jedoch der nicht-flüchtige Speicher zusätzlich zu dem Nummernteil Klasseninformation für die FRU, nämlich den FRU-Namen: RMM. Weitere Information wird ebenfalls bereitgestellt, wie später noch beschrieben wird.
Eine Komponente des CMSD, welche einen Konfigurations- (Initialisierungs-) Mechanismus in Form eines Programms (CMSINITIALIZE) bildet, ist so betreibbar, daß sie jeden Steckplatz oder jede eine FRU aufnehmende Stelle des Gehäuses untersucht, um nach nicht-flüchtigen Speichern 230 zu suchen. Die Klasseninformation für die FRU (hier der FRU-Klassenname RMM) wird durch die Initialisierungskomponente verwendet, um einen Pfad von den CMS-Objektdefinitionen (CMSDEFs) für diese Klasse der FRU (hier der RMM-Klasse) abzuleiten. Die CMSDEFs können Initialisierungscode (Initialisierungsskripte) enthalten, welche für die Klasse der FRU spezifisch sind und welche nach Empfang der FRU-Klasse und einer Instanznummer, welche durch die Initialisie rungskomponente erzeugt wurde, so betreibbar sind, daß sie Konfigurationsinformation (Konfigurationsskripte) erzeugen, die dann in der CMS-Konfigurationsdatei 404 gespeichert werden, welche in dem Systemspeicher gehalten wird. Falls erforderlich, kann der Initialisierungscode weiterhin auf den FRU-Speicher für weitere Information zugreifen, die benötigt wird, um die anfängliche Konfigurationsinformation zu erzeugen. Die Konfigurationsaussagen weisen typischerweise eine Objektklasse (z. B. RMM) und eine Instanznummer (beispielsweise 1), ein Attribut (beispielsweise Aktion) und einen Wert (beispielsweise Freigeben) auf. Ein Beispiel von Einträgen in einer CMS-Konfigurationsdatei für die FRU 214 nach 17 ist in 18 dargestellt.
Wenn die CMS-Konfigurationstabelle bereitgestellt worden ist und die anfänglichen Tests abgeschlossen sind, so ist die CMSD in der Lage, aus der in der CMS-Konfigurationsdatei gespeicherten Information festzustellen, welche FRUs existieren. Um die Geräteinstanzen für das Band und die CD-ROM korrekt einzustellen, fragen die CMS "CMSDEFs" die RMM-FRU noch weiter ab. Das CMS-Modell der FRU und seiner Geräte werden dynamisch aus der Information in dem nichtflüchtigen Speicher 230 erzeugt. 19 veranschaulicht ein Beispiel der CMSDEFs-Instanzen und -Attribute für die in 17 dargestellte beispielhafte FRU.
20 ist ein Flußdiagramm für die Zusammenfassung der Betriebsweise 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 durchzuführen, wobei die Konfigurationsdatei die notwendige Information für nachfolgende Initialisierungen bereitstellt. Die Verwendung einer Konfigurationsdatei ist in dem vorliegenden fehlertoleranten System bevorzugt, daß sie eine Kontinuität zwischen Initialisierungen gewährleistet und bei der Identifizierung von Fehlern hilft. Es versteht sich jedoch, daß es in anderen Systemen wünschenswert sein kann, diesen Vorgang zu anderen Zeitpunkten auszuführen.
In Schritt S41 tastet die CMS-Initialisierungskomponente 500 die die FRU aufnehmenden Stellen ab bei der Suche nach nicht-flüchtigen Speicherelementen 230. Im Ergebnis ist, wenn eine FRU in eine solche Aufnahmestelle eingesetzt wird und bevor die FRU-Geräte in das System integriert werden, die CMS-Initialisierungskomponente 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 einer Aufnahmestelle identifiziert, die FRU-Klasseninformation (beispielsweise den FRU-Klassennamen, der darin bereitgestellt wird).
Diese FRU-Klasseninformation wird dann in Schritt S43 durch die CMS-Initialisierungskomponente verwendet, um auf den Initialisierungscode (Skripte) für die durch die Klasseninformation identifizierte Klasse zuzugreifen. Wie angezeigt, können die Initialisierungsskripte den CMSDEFs für diese Klasse der FRU zugeordnet werden.
In Schritt S44 erzeugen die Initialisierungsskripte die Konfigurationsaussagen 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 Konfigurationsaussagen, die durch die Initialisierungsskripte ausgegeben werden, werden durch die Initialisierungskomponente in Schritt S45 verifiziert (dies könnte durch eine getrennte Komponente des CMS bewirkt werden).
Wenn die Initialisierungskomponente während dieses Überprüfens irgendwelche Fehler entdeckt, so verwirft sie alle Codezeilen, die zu der betreffenden FRU gehören. Dies dient dazu, sicherzustellen, daß der CMSD starten kann, und so, daß alle nachfolgenden Korrekturvorgänge vorgenommen werden können. Wenn ansonsten die Konfigurationsaussagen die Überprüfung abgeschlossen haben, so werden die Konfigurationsaussagen in Schritt S46 in die Konfigurationsdatei 404 geschrieben. Sobald alle Konfigurationsaussagen in der CMS-Konfigurationsdatei gespeichert worden sind und dies alles überprüft wurde, kann die Steuerung an den Konfigurationssystemdaemon übergeben werden.
Der CMSD vollendet dann die Konfiguration des Systems in Schritt S47, einschließlich einer Konfiguration der FRU-Geräte, wie in 19 dargestellt. Als Teil des Vorgangs greift er, falls erforderlich, auf den FRU-Speicher zu, um Information über Geräteklassen und weitere Geräteinformation zu extrahieren. Der CMSD ist dann in der Lage, die FRU-Geräte zu konfigurieren, wie sie durch die CMSDEFs und/oder Skripte definiert sind. Der CMSD ist in der Lage, automatisch zumindest die physikalischen Gerätehierarchien zu erzeugen, auf die in den 7 und 8 Bezug genommen wurde, indem Verknüpfungen zwischen den verschiedenen Objekten gemäß der Information in den CMSDEFs bereitgestellt werden, was Erklärungen für die durch den CMSD verwalteten Objekte, Zustandsauswertungen (Aussagen zum Auswerten der Zustände der Objekte) und Übergangscode umfaßt, der ausgeführt wird, wenn ein Übergang zwischen den Zuständen eines Objekts erfolgt. Die Diensthierarchie kann partiell durch Eingriff des Benutzers konfiguriert werden (beispielsweise, um spezielle Dienste zu spezifizieren, wie es durch den Benutzer gefordert wird).
Dieser zweistufige Vorgang ermöglicht die Erzeugung einer Datenbank zum Bereitstellen eines repräsentativen Zustandes für das Starten des CMSD.
Es ist demnach ein Konfigurationsmanagementsystem beschrieben worden, welches eine automatische Konfiguration von FRUs und ihren zugehörigen Geräten ermöglichen kann.
Der Speicher in den FRUs kann verwendet werden, um zusätzliche Daten zu speichern, die über die speziell für die beschriebenen Konfigurationsprozesse verwendeten hinausgehen. Beispielsweise kann er zusätzlich verwendet werden, um gewisse Zustandsinformation zu speichern, die sich auf den Systembetrieb beziehen, damit der Zustand des Systems auch bei Neustarts bzw. über Neustarts hinweg konsistent ist. Außerdem kann er verwendet werden, um eine Historie für die Einheit zu speichern. Diese Information könnte dann zu irgendeinem späteren Zeitpunkt offline verwendet werden (beispielsweise bei Rückgabe einer vermeintlich fehlerhaften FRU), um festzustellen, ob es die FRU war, oder möglicherweise ein Steckplatz, in welchen diese eingesetzt wurde, welcher fehlerhaft war.
Es ist ein Konfigurationsmanagementsystem einschließlich eines Konfigurationsmanagementsystemdaemons (CMSD) beschrieben worden. Das fortgesetzte korrekte Funktionieren des CMSD kann sichergestellt werden durch Erfassen des Ausfalls des CMSD und erneuten Startens des CMSD, wenn es angemessen ist. Ein Zusammenbrechen des Systems, welches durch kontinuierliche, schnelle Versuche zum erneuten Starten des CMSD bewirkt wird, welcher nie erfolgreich arbeitet, kann vermieden werden.
Es versteht sich, daß, obwohl bestimmte Ausführungsformen der Erfindung beschrieben worden sind, viele Modifikationen/Zusätze und/oder Ersetzungen innerhalb des Schutzumfangs der vorliegenden Erfindung vorgenommen werden können, wie er in den anhängenden Ansprüchen definiert ist.
Beispielsweise ist, auch wenn ein Beispiel der Erfindung im Kontext eines fehlertoleranten Computersystems beschrieben wurde, diese in ihrer Anwendung nicht auf ein solches System beschränkt. In der Tat könnte es auch Anwendung in irgendeinem 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ßüberwachung und der überwachte Prozeß (CMSD) durch Programmcode implementiert sind, diese zumindest teilweise mit Hilfe von spezieller Hardware implementiert werden könnten, indem beispielsweise einer oder mehrere spezielle Schaltkreise verwendet werden, wie z. B. anwendungsspezifische, integrierte Schaltkreise (ASICs).
Dementsprechend soll das beschriebene, besondere Beispiel nur veranschaulichend und nicht beschränkend sein.

Claims

Verfahren zur automatischen Konfigurierung einer Einheit (214), die einen Bestandteil einer Vorrichtung bildet, wobei das Verfahren aufweist: Zugreifen (S42) auf Klasseninformation, die in der Einheit gehalten wird, beim Einsetzen der Einheit in die Vorrichtung, bevor die Einheit funktionell in die Vorrichtung integriert wird, wobei die Klasseninformation eine Objektklasse für die Einheit wiedergibt, Verwenden (S43, S44) der erfaßten Klasseninformation, um in einem Speicher in der Vorrichtung getrennt von der Einheit Objektdefinitionen für die Klasse der Einheit aufzurufen, wobei die Objektdefinitionen einen Initialisierungscode enthalten, der bei Empfang der erfaßten Klasseninformation so betreibbar ist, daß er Objektkonfigurierungsaussagen für die Einheit erzeugt, die zumindest eine der folgenden umfassen, nämlich die Objektklasse für die Einheit, eine Objektinstanznummer, einen Attributnamen oder einen Wert für das Attribut, und Verifizieren (S45) der Gültigkeit der Konfigurierungsinformation und, wenn die Konfigurierungsinformation gültig ist, Speichern (S46) der Konfigurierungsinformation in einer Konfigurationsdatei für die Vorrichtung einschließlich einer Position für die Einheit in der Vorrichtung, um die funktionelle Integration der Einheit in die Vorrichtung zu ermöglichen.
Verfahren nach Anspruch 1, welches weiterhin das Zugreifen auf die Einheit aufweist, wenn sie in die Vorrichtung funktionell integriert ist, für weitere Konfigurierungsdaten, die in dieser gehalten werden.
Verfahren nach Anspruch 2, wobei die weiteren Konfigurierungsdaten eine Geräteobjektklasse und Geräteobjektattribute für ein Gerät der Einheit aufweisen.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Klasseninformation in der Einheit in einem nicht flüchtigen Speicher gehalten wird.
Verfahren nach Anspruch 1 für das Konfigurieren einer Mehrzahl von Einheiten für ein Konfigurierungsverwaltungssystem, wobei die Klasseninformation zumindest eine Konfigurierungsverwaltungssystemklasse für die Einheit identifiziert.
Verfahren nach einem der vorstehenden Ansprüche, wobei jede Stelle in der Vorrichtung für die Aufnahme der Einheit für den Zugriff auf Klasseninformation, die in einer Einheit an der Stelle gehalten wird, untersucht wird.
Verfahren nach Anspruch 6, wobei ein Satz von Objektkonfigurierungsaussagen für entsprechende Einheiten in der Konfigurierungsdatei gespeichert wird.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Einheit eine als Feld bzw. durch ein Feld ersetzbare Einheit ist.
Vorrichtung mit: einer Mehrzahl von Einheiten, die jeweils einen Speicher der Einheit enthalten, um Klasseninformation für die Einheit zu erhalten, welche eine Objektklasse für die Einheit wiedergibt, und mit einem Konfigurierungsmechanismus, der so betreibbar ist, daß er auf Klasseninformation, die in der Einheit gehalten wird, beim Einsetzen der Einheit in die Vorrichtung zugreift (S42), bevor die Einheit funktionell in die Vorrichtung integriert wird, wobei die Klasseninformation eine Objektklasse für die Einheit wiedergibt, die zugegriffene Klasseninformation benutzt (S43, S44), um in einem Speicher in der Vorrichtung getrennt von der Einheit Objektdefinitionen für die Klasse der Einheit aufzurufen, wobei die Objektdefinitionen Initialisierungscode enthalten, der auf den Empfang der zugegriffenen Klasseninformation in der Weise betreibbar ist, daß er Objektkonfigurierungsaussagen für die Einheit erzeugt, welche zumindest eine der folgenden umfassen, nämlich die Objektklasse für die Einheit, eine Objektinstanznummer, einen Attributnamen oder einen Wert für das Attribut, und die Gültigkeit der Konfigurierungsinformation verifiziert (S45), und, falls die Konfigurierungsinformation gültig ist, die Konfigurierungsinformation in einer Konfigurationsdatei für die Vorrichtung einschließlich einer Position der Einheit in der Einrichtung speichert, um eine funktionelle Integration der Einheit in die Vorrichtung zu ermöglichen.
Vorrichtung nach Anspruch 9, wobei der Speicher der Einheit einen nicht flüchtigen Speicher aufweist.
Vorrichtung nach Anspruch 10, wobei der nicht flüchtige Speicher ein EEPROM ist.
Vorrichtung nach einem der Ansprüche 9 bis 11, wobei der Konfigurierungsmechanismus Teil eines Konfigurationsverwaltungssystems ist und die Klasseninformation zumindest eine Klasse eines Konfigurierungsverwaltungssystems für die Einheit identifiziert.
Vorrichtung nach Anspruch 12, welche ein Gestell für eine Mehrzahl von in dem Gestell anzuordnenden Einheiten aufweist.
Vorrichtung nach Anspruch 13, wobei der Konfigurierungsmechanismus jede Stelle in der Vorrichtung für die Aufnahme einer derartigen Einheit für den Zugriff auf Klasseninformation, die in einer derartigen Einheit an der Stelle gehalten wird, untersucht.
Vorrichtung nach Anspruch 14, welche eine Konfigurationsdatei in dem Systemspeicher für eine dauerhafte Speicherung eines Satzes von Objektkonfigurierungsaussagen für entsprechende Einheiten aufweist.
Vorrichtung nach einem der Ansprüche 9 bis 15, wobei eine solche Einheit eine als Feld bzw. in einem Feld austauschbare Einheit ist.
Vorrichtung nach einem der Ansprüche 9 bis 16, welche ein Computersystem bildet.
Vorrichtung nach Anspruch 17, wobei das Computersystem ein fehlertolerantes Computersystem ist.
Konfigurierungsverwaltungssystemprogramm, welches auf einer Vorrichtung gemäß einem der Ansprüche 9 bis 18 lauffähig ist, wobei das Programm für das Konfigurierungsverwaltungssystem einen Initialisierungsbestandteil aufweist und in der Weise betreibbar ist, daß es die Schritte nach einem Verfahren nach einem der Ansprüche 1 bis 8 durchführt.
Programm eines Konfigurierungsverwaltungssystems nach Anspruch 19, wobei die Initialisierungskomponente so ausgestaltet ist, daß sie jede Stelle in der Vorrichtung für die Aufnahme einer Einheit untersucht und, wenn eine Stelle durch eine Einheit besetzt ist, Klasseninformation aus dem Speicher in der Einheit liest.
Programm für ein Konfigurationsverwaltungssystem nach einem der Ansprüche 19 und 20 auf einem Trägermedium.