-
GEBIET DER ERFINDUNG
-
Ausführungsformen
der vorliegenden Erfindung betreffen das Systemmanagement. Insbesondere
betreffen Ausführungsformen
der vorliegenden Erfindung ein Verhandlungsprotokoll zur Bestimmung
des Betriebsmodus von Systemmanagementcontrollern.
-
STAND DER TECHNIK
-
Computer
und andere elektronische Systeme enthalten verschiedene Komponenten,
die während
ihrer Lebensdauer versagen können.
Um solche Funktionsstörungen
zu reduzieren und/oder zu beheben, umfassen einige Systeme integrierte
Merkmale, wie zum Beispiel die Fähigkeit,
die "Gesundheit" oder Leistungsfähigkeit
der Systemhardware zu überwachen
und zu steuern. Solche Merkmale werden manchmal als Systemmanagement
bezeichnet, können
aber auch mit anderen Namen angegeben werden, wie zum Beispiel Management,
Hardwaremanagement, Plattformmanagement usw. Systemmanagementmerkmale
können
zum Beispiel die Überwachung
von Elementen umfassen, wie zum Beispiel Temperaturen, Spannungen,
Lüfter, Stromversorgungen,
Busfehler, physische Systemsicherheit usw. Außerdem können Systemmanagementmerkmale
auch das Bestimmen von Informationen, die bei der Identifizierung
einer ausgefallenen Hardwarekomponente helfen, und die Ausgabe einer
Warnung umfassen, die angibt, daß eine Komponente ausgefallen ist.
Eine der Komponenten, die zur Handhabung von Systemmanagementfunktionen
verwendet werden können,
ist der Systemmanagementcontroller (der hierin auch als "Controller" bezeichnet wird).
Ein Systemmanagementcontroller kann ein Mikroprozessor, Mikrocontroller,
anwendungsspezifische integrierte Schaltung (ASIC) oder eine andere
Art von Verarbeitungseinheit sein, die die Systemmanagementaufgaben
kontrolliert. Eine Systemmanagementcontroller kann Aufgaben ausführen, wie
zum Beispiel das Empfangen von Systemmanagementinformationen, Sendung
von Mitteilungen zur Steuerung der Systemleistung, Aufzeichnung
von Systemmanagementinformationen usw. Ein Systemmanagementcontroller
kann zum Beispiel eine Anzeige von einem Temperatursensor empfangen,
daß die
Systemtemperatur gerade ansteigt, kann eine Anweisung zur Erhöhung der
Lüftergeschwindigkeit
senden und kann den Temperaturablesewert aufzeichnen.
-
Einer
der Systemmanagementcontroller in einem System kann die Rolle des
zentralen Systemmanagementcontrollers ausfüllen und zentrale Managementfunktionen
ausführen,
wie zum Beispiel das Aufzeichnen von Ereignissen, Sammeln von Bestandsinformationen
der austauschbaren Baueinheit (FRU), Nutzerschnittstelle, Wirts-CPU-Schnittstelle
usw. Der zentrale Managementcontroller für ein System kann als Grundplatten-Managementcontroller
(BMC) des Systems bezeichnet werden. Andere nichtzentrale Managementcontroller
können
als Satelliten-Managementcontroller (SMCs) bezeichnet werden. Ein
SMC kann Systemmanagement für
einen bestimmten Teil oder ein Merkmal eines Systems ausführen. Ein
Computersystem kann zum Beispiel eine Reihe von Leiterplatten und
anderen Komponenten enthalten, die durch Busse verbunden sind, wobei
ein Bus einen BMC für
dieses System enthält
und andere Leiterplatten SMCs enthalten, die andere Systemmanagementfunktionen
ausführen.
-
Einige
Systemmanagementcontroller besitzen die Fähigkeit, in einem BMC-Modus
oder in einem SMC-Modus zu arbeiten (d. h. die Rolle eines BMC oder
eines SMC auszufüllen).
In einigen Systemen nach dem Stand der Technik kann ein Systemmanagementcontroller,
der an einer Leiterplatte befestigt ist, seine Funktionalität auf der
Grundlage des Steckplatzes anpassen, in den die Leiterplatte eingesteckt
ist. In solch einem System kann ein spezieller Steckplatz in einem
Systemchassis für
eine Leiterplatte reserviert werden, die die BMC-Funktionalität für dieses
System ausfüllt,
und kann einen Stift haben, der so für eine Anzeige für das systemeigene
Modul sorgt. In diesem Fall kann ein Systemmanagementcontroller
beim Reset feststellen, ob er sich im BMC-Steckplatz befindet, und
wenn ja, kann er sich selbst darauf einstellen, als BMC zu wirken (d.
h. sich selbst in den BMC-Modus zu versetzen). In solchen Systemen
muß möglicherweise
eine Person, die das System montiert oder Leiterplatten wechselt,
feststellen, welcher Steckplatz der BMC-Steckplatz ist und sicherstellen,
daß eine
Leiterplatte mit gewünschten
BMC-Fähigkeiten
in den richtigen BMC-Steckplatz eingeführt wird.
-
Das
US-Patent 5,644,700 offenbart
ein Verfahren zum Betreiben von redundanten Master-E/A-Controllern. Das
Verfahren wird zum Initialisieren und Überwachen von Operationen mehrerer
peripherer Gerätecontroller
in einem peripheren Computerkontrollsystem bereitgestellt und umfaßt die Schritte
des Speicherns, in Registern der Mastercontroller, eines Anfangssatzes
von Parametern zum Betrieb des Kontrollsystems, Ausführen eines
Selbsttests von jedem der Mastercontroller, um festzustellen, ob
Fehler aufgetreten sind, und wenn ja, Kontrollieren zur Überprüfung des
Vorhandenseins eines redundanten Mastercontrollers. Es umfaßt ferner
das Feststellen, ob der redundante Mastercontroller die Kontrolle
hat oder nicht; wenn nicht, Setzen von busaktiven Kontrollsignalen;
Freigeben von aktiven Taktausgabesignalen; Initialisieren des Statusbusadressenzeigers;
Abfragen eines ausgewählten
der peripheren Gerätecontroller;
Prüfung
auf das Ende der Schrankadresse; schrittweises Erhöhen des
Statusbusadressenzeigers; und Wiederholen der Schritte des Initialisierens
durch schrittweises Erhöhen.
-
BESCHREIBUNG DER ZEICHNUNGEN
-
1 ist
ein Blockdiagramm eines Systems mit Managementcontrollern, die dafür ausgelegt
sind, ein Betriebsartenverhandlungsprotokoll gemäß einer Ausführungsform
der vorliegenden Erfindung auszuführen.
-
2 ist
ein Blockdiagramm eines Systems mit Managementcontrollern beim Prozeß des Ausführens eines
Betriebsartenverhandlungsprotokolls gemäß einer Ausführungsform
der vorliegenden Erfindung.
-
3 ist
ein Flußdiagramm
eines Verfahrens zur Bestimmung der Anfangsbetriebsart eines Managementcontrollers
gemäß einer
Ausführungsform
der vorliegenden Erfindung.
-
4 ist
ein Flußdiagramm
eines Verfahrens zum Reagieren auf eine Controller-Modusanforderung gemäß einer
Ausführungsform
der vorliegenden Erfindung.
-
5 ist
ein Blockdiagramm einer Controller-Modusanforderung und einer Reaktion
gemäß einer Ausführungsform
der vorliegenden Erfindung.
-
6 ist
ein Zustandsdiagramm, das die Zustände und Zustandsübergänge für ein Betriebsartenverhandlungsprotokoll
gemäß einer
Ausführungsform
der vorliegenden Erfindung illustriert.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Gemäß Ausführungsformen
der vorliegenden Erfindung verhandelt ein Systemmanagementcontroller mit
anderen Systemmanagementcontrollern, um eine Anfangsbetriebsart
zu bestimmen (d. h. die Betriebsart nach einem Reset oder einem
anderen Beginn). Solch eine Verhandlung kann zum Beispiel durch
Senden von Mitteilungen zwischen Systemmanagementcontrollern bewerkstelligt
werden. In einer Ausführungsform
stellt ein Systemmanagementcontroller nach einem Reset fest, daß seine
Anfangsbetriebsart der zentrale Managementcontrollermodus (z. B.
der BMC-Modus) ist, was auf dem Fehlen einer Reaktion auf eine oder
mehrere Controllermodusanforderungen beruht, die von diesem Systemmanagementcontroller
gesendet wurden. In einer weiteren Ausführungsform kann der Anfangsmodus
für den
Systemmanagementcontroller auf dem Inhalt einer Reaktion beruhen,
die von diesem Systemmanagementcontroller empfangen wurde.
-
Ausführungsformen
der vorliegenden Erfindung stellen ein Controllermodusverhandlungsprotokoll
bereit. In einer Ausführungsform
wird jeder Systemmanagementcontroller im System dafür ausgelegt,
das Verhandlungsprotokoll auszuführen.
Das Verhandlungsprotokoll kann für
Ereignisse ausgeführt
werden, wie zum Beispiel eine Systeminitiierung oder wenn ein einzelner
Systemmanagementcontroller ein Reset ausführt. Wenn zum Beispiel ein
System hochgefahren wird, kann jeder Systemmanagementcontroller
im System eine Controllermodusanforderung an andere Systemmanagementcontroller
gemäß dem Verhandlungsprotokoll senden
und kann auf einen Anfangsmodus auf der Basis einer Reaktion auf
die Controllermodusanforderung übergehen.
Das Verhandlungsprotokoll kann auch das Protokoll für einen
Systemmanagementcontroller zum Reagieren auf eine Modusanforderung,
die er empfängt,
definieren. In Ausführungsformen
der vorliegenden Erfindung wechseln Controller durch eine Reihe
von Verhandlungszuständen,
die folgende umfassen können: Anforderung,
Warten, SMC, Standby-BMC und aktiver BMC. In Ausführungsformen
kann die Verhandlung zumindest teilweise auf Kriterien beruhen,
wie zum Beispiel Controller-Fähigkeiten,
vom Nutzer konfigurierte Präferenzen,
Modulart und geographische (physische) Adresse.
-
1 ist
ein Blockdiagramm eines Systems mit Managementcontrollern, die dafür ausgelegt
sind, ein Betriebsartenverhandlungsprotokoll gemäß einer Ausführungsform
der vorliegenden Erfindung auszuführen. 1 zeigt
ein System 100, das eine beliebige Art von elektronischem
System sein kann, wie zum Beispiel ein Mehrzweck-Computersystem,
Spezialcomputersystem usw. System 100 enthält vier
Module 110, 120, 130 und 140,
die zum Beispiel Leiterplatten sein können, die in Steckplätze eines
Systemchassis eingeführt
werden. Natürlich
kann das System in anderen Ausführungsformen
mehr oder weniger Module enthalten. Jedes der Module 110, 120, 130 und 140 kann
eine Stromversorgung, Lüfterwanne,
CPU-Platine oder eine andere Art von Komponente sein. Die Controller
in System 100 können
jeweils durch einen Eingabe-/Ausgabeport mit einem Systemmanagementbus 150 verbunden
sein, der von einer beliebigen Art von Bus sein kann, der Managementinformationen überträgt. Beispiele
für einen
Systemmanagementbus 150 sind ein Inter-IC-Bus (I2C), der der I2C-Busspezifikation
entspricht, die von der Philips Semiconductor Corporation entwickelt
wurde, ein Systemmanagementbus (SMBus), der der SMBus-Spezifikation
(Ver. 2.0, Aug. 2000) des SBS Implementers Forum entspricht, oder
ein Intelligent Platform Management Bus (IPMB), der der Intelligent
Platform Management Bus Communications Protocol Specification (Intel
Corp. et al., v1.0) entspricht. Der Systemmanagementbus kann in
jeder Art von Topologie konfiguriert werden, wie zum Beispiel einer
Einzelbus-, Stern-, Doppelbus- oder einer Hybridtopologie. Wenn
eine Doppelbustopologie verwendet wird, kann der Systemmanagementcontroller
einen zweiten Eingangs-/Ausgangsport zum Senden eines Duplikats
von Systemmanagementmitteilungen an die anderen Systemmanagementcontroller
haben. Ein Systemmanagementcontroller kann mit anderen Systemkomponenten
unter Verwendung verschiedener Arten von Mitteilungsformaten kommunizieren, wie
zum Beispiel dem, welches in der Intelligent Platform Management
Interface Specification (Intel Corp. et al., v1.5, rev. 1, 21. Feb.
2001) (hierin nachstehend als IPMI bezeichnet) definiert ist.
-
Jedes
Modul, das in System 100 gezeigt wird, enthält einen
Systemmanagementcontroller (113, 123, 133, 143)
und ein computerlesbares Medium (115, 125, 135, 145).
Jeder Systemmanagementcontroller kann ein Prozessor sein, der Systemmanagementfunktionen
ausführen
kann, wie oben diskutiert. Jedes computerlesbare Medium kann eine
beliebige Art von Medium sein, die in der Lage ist, Anweisungen
zu speichern, wie zum Beispiel ein Nur-Lese-Speicher (ROM), ein programmierbarer
Nur-Lese-Speicher (PROM) oder ein löschbarer programmierbarer Nur-Lese-Speicher
(EPROM). In einer Ausführungsform
ist das computerlesbare Medium ein nichtflüchtiger Speicher. Jedes computerlesbare
Medium in 1 wird gezeigt, wie es Anweisungen (117, 127, 137, 147)
zum Modusverhandlungsprotokoll speichert. Die Anweisungen zum Modusverhandlungsprotokoll
können
zum Beispiel Software-Anweisungen, Firmware-Anweisungen, Mikrocode
oder eine andere Art von Anweisungen sein, die vom zugehörigen Systemmanagementcontroller
ausgeführt
werden können, um
mit anderen Systemmanagementcontrollern zu verhandeln, um eine Anfangsbetriebsart
für die
Systemmanagementcontroller zu bestimmen. Andere Anweisungen, wie
zum Beispiel Anweisungen zur Ausführung von Systemmanagementfunktionen,
können
auch auf einem oder mehreren der computerlesbaren Medien gespeichert
werden und können
von einem Systemmanagementcontroller ausgeführt werden. In anderen Ausführungsformen
können
der Systemmanagementcontroller und das Modus verhandlungsprotokoll
als ASIC, programmierbares logisches Feld (PLA) oder eine andere
Art von Verarbeitungsanordnung zur Ausführung von Systemmanagementfunktionen
implementiert werden.
-
In
einem Beispiel für
die Operation einer Ausführungsform
der vorliegenden Erfindung kann der Systemmanagementcontroller 113 Anweisungen 117 des
Modusverhandlungsprotokolls zum Verhandeln mit Systemmanagementcontrollern 123, 133 und 143 ausführen, um
den anfänglichen
Systemmanagementmodus für einen
oder mehrere der Systemmanagementcontroller 113, 123, 133 und 143 zu
bestimmen. In einer Ausführungsform
können
mögliche
Systemmanagementmodi für
einen Controller der aktive BMC-Modus, Standby-BMC-Modus und der
SMC-Modus sein. In dieser Ausführungsform
kann der aktive BMC-Modus die BMC-Funktionen für das System ausführen, während der
Standby-BMC-Modus
verfügbar
ist, um im Fall des Ausfalls des aktuellen Aktiv-BMC zum Aktiv-BMC
zu werden (kann z. B. dieselben Managementinformationen wie der
Aktiv-BMC empfangen und aufzeichnen). In anderen Ausführungsformen
kann es mehr oder weniger mögliche
Managementmodi geben.
-
In
der einfachsten Ausführungsform,
die mit Bezug auf 2 diskutiert wird, haben alle
Systemmanagementcontroller außer
einem bereits einen Betriebsmodus angenommen. In diesem Fall kann
der nicht-initialisierte Managementcontroller eine Modusanforderung
gemäß dem Verhandlungsprotokoll
senden, und die anderen Managementcontroller können gemäß dem Verhandlungsprotokoll
antworten. In einer weiteren Ausführungsform hat das ganze System
eine Initialisierung oder ein Reset erfahren, und alle Systemmanagementcontroller
können
im wesentlichen zur selben Zeit Modusanforderungen aneinander senden.
-
2 ist
ein Blockdiagramm eines Computersystems 200 mit Managementcontrollern
beim Prozeß des
Ausführens
eines Betriebsmodusverhandlungsprotokolls gemäß einer Ausführungsform
der vorliegenden Erfindung. Computersystem 200 wird so
gezeigt, daß es
eine Leiterplatte 210, Leiterplatte 220, Leistungsmodul 230,
Lüfterwannenmodul 240 und
Managementbus 250 umfaßt,
die dieselben wie die Module 110–140 und Managementbus 150 von 1 sein
können.
In der Ausführungsform,
die in 2 gezeigt wird, umfaßt die Leiterplatte 210 einen
Grundplattenmanagementcontroller 215; Leiterplatte 220 umfaßt den Standby-Managementcontroller 225,
und das Leistungsmodul 230 enthält den Satelliten-Managementcontroller 235.
Zum Zweck der Erläuterung
haben in dieser Ausführungsform
die Managementcontroller 215, 225 und 235 bereits einen
Betriebsmodus angenommen. BMC 215 kann zum Beispiel der
aktive zentrale Managementcontroller für System 200 sein;
der Standby-BMC 225 kann
in Bereitschaft sein, als aktiver zentraler Managementcontroller
für System 200 einzuspringen,
falls der BMC 215 ausfallen sollte, und SMC 235 kann
den Betrieb des Leistungsmoduls 230 überwachen und steuern.
-
Managementcontroller,
wie zum Beispiel die in System 200 gezeigten, sind möglicherweise
in der Lage, in einem, einigen oder allen aus BMC-Modus, Standby-BMC-Modus
oder SMC-Modus zu
arbeiten. BMC 215 kann zum Beispiel auch fähig sein,
als Standby-BMC oder als SMC zu arbeiten; Standby-BMC 225 kann auch
fähig sein,
als BMC oder SMC zu arbeiten; und SMC 235 kann möglicherweise
nur fähig
sein, als SMC zu arbeiten. In anderen Ausführungsformen kann SMC 235 zum
Beispiel fähig
sein, als BMC zu arbeiten, und/oder BMC 215 nicht fähig sein,
als SMC zu arbeiten.
-
Das
Lüfterwannenmodul 240 wird
so gezeigt, daß es
einen neuen Systemmanagementcontroller 245 umfaßt. Dieser
Controller wurde zu Zwecken der Erläuterung als "neu" bezeichnet, um einen
Fall zu zeigen, bei dem einer der Systemmanagementcontroller gerade
initialisiert wird, während
die anderen Systemmanagementcontroller bereits einen Betriebsmodus
angenommen haben. Ein Managementcontroller kann zum Beispiel initialisiert
werden, wenn das ganze System eingeschaltet oder zurückgesetzt
wird oder (im Fall von 2) wenn das bestimmte Modul,
das den Managementcontroller umfaßt, eingeschaltet oder zurückgesetzt wird. 2 kann
den Fall illustrieren, wo zum Beispiel das Lüfterwannenmodul 240 in
System 200 als Teil einer Hot Swap-Operation installiert
wurde.
-
Wie
in 2 gezeigt, kann während oder nach dem Reset der
neue Systemmanagementcontroller 245 eine Controller-Modusanforderung 260 über den
Systemmanagementbus 250 an die anderen Managementcontroller 215, 225 und 235 senden.
Die Controller-Modusanforderung 260 kann zum Beispiel eine
Anweisung sein, die der IPMI-Spezifikation
genügt.
In dieser Ausführungsform
reagiert der Aktiv-BMC 215 auf die Controller-Modusanforderung
durch Senden einer GoToSMC-Reaktion 261, und der Standby-BMC 225 reagiert
durch Senden einer Warte-Reaktion. In einer Ausführungsform sendet SMC 235 keine
Reaktion auf die Controller-Modusanforderung 260. In einer
Ausführungsform
und wie unten diskutiert, kann die Reaktion, die auf die Modusanforderungsmitteilung
gesendet wird, durch das Modusverhandlungsprotokoll bestimmt werden.
Das Protokoll kann zum Beispiel dafür sorgen, daß beim Empfang
einer Modusanforderung durch den aktiven BMC von einem Managementcontroller,
der die gleiche oder eine niedrigere Priorität hat, der aktive BMC mit einer
GoToSMC-Reaktion antwortet. Das Protokoll kann zum Beispiel dafür sorgen,
daß beim
Empfang einer Modusanforderung durch den Standby-BMC von einem Managementcontroller,
der eine höhere
Priorität
hat, der Standby-BMC mit einer Warte-Reaktion antwortet. Außerdem kann
das Protokoll vorsehen, daß ein
SMC ungeachtet der relativen Prioritäten nicht auf eine Modusanforderung
antwortet. Wie unten diskutiert, können Faktoren, die zum Bestimmen
der relativen Priorität
von zwei Managementcontrollern verwendet werden, die Controllerfähigkeiten,
nutzerkonfigurierte Präferenzen,
Modulart und geographische Adresse umfassen.
-
Das
Verhandlungsprotokoll kann auch die Aktion festlegen, die beim Empfang
einer Modusanforderung (oder beim ausbleibenden Empfang einer Modusanforderung)
ergriffen wird. Das Protokoll kann zum Beispiel dafür sorgen,
daß ein
Controller beim Empfang einer GoToSMC-Anweisung in den SMC-Status
wechselt. Als weiteres Beispiel, das mit Bezug auf 3 diskutiert
wird, kann das Protokoll dafür
sorgen, daß ein
Managementcontroller in den aktiven BMC-Status wechselt, wenn er
eine Modusanforderung aussendet und innerhalb einer Zeitablaufdauer
(d. h. eines Schwellzeitwerts) keine Reaktion empfängt.
-
3 ist
ein Flußdiagramm
eines Verfahrens zur Bestimmung der Anfangsbetriebsart eines Managementcontrollers
gemäß einer
Ausführungsform
der vorliegenden Erfindung. Dieses Verfahren kann zum Beispiel von
einem Systemmanagementcontroller (wie zum Beispiel einem neuen Systemmanagementcontroller 245 von 2)
beim Reset oder einem anderen Start des Systemmanagementcontrollers
ausgeführt
werden. Der neue Systemmanagementcontroller 245 kann zum
Beispiel das Verfahren, das in 3 gezeigt
wird, als Teil seiner Startroutine ausführen. In der Ausführungsform,
die in 3 (und 6) gezeigt wird, hat der Systemmanagementcontroller
zusätzlich
zu den BMC-, Standby-BMC- und SMC-Modi, die oben diskutiert werden, eine
Reihe von Nichtbetriebszuständen. 3 zeigt
insbesondere den Controller, der in den Anforderungszustand (302)
eintritt. In einer Ausführungsform
ist das Verfahren, das in 3 illustriert
wird, Teil eines Controller-Modusverhandlungsprotokolls, und das
Verfahren kann zum Beispiel durch Anweisungen des Modusverhandlungsprotokolls,
das in 1 gezeigt wird, ausgeführt werden.
-
In
der Ausführungsform,
die in 3 gezeigt wird, wird der Systemmanagementcontroller
zuerst zurückgesetzt
(301). Als nächstes
tritt das System in den Anforderungszustand (302) ein.
Ein neuer Systemmanagementcontroller 245 kann zum Beispiel
eine Controllerstartroutine ausführen,
die mit dem Rücksetzen
des Controllers beginnt und in den Anforderungszustand eintritt.
Während
des Anforderungszustandes sendet der Controller eine Controller-Modusanforderungsmeldung
(wie zum Beispiel die Controllermodusanforderung 260 von 2)
(303). In einer Ausführungsform
kann das einzige Merkmal des Anforderungszustandes das Senden der
Controllermodusanforderung sein. Als nächstes kann der Controller
auf eine Reaktion auf die Modusanforderung warten (304).
Wenn eine Reaktion innerhalb der Zeitablauffrist (z. B. 100 ms)
empfangen wird, dann kann der Controller in den Zustand treten,
der in der Reaktion festgelegt ist (305). Der neue Systemmanagementcontroller 245 kann
zum Beispiel eine GoToSMC-Reaktion von einem anderen Managementcontroller
im System empfangen. Nach dem Einnehmen des festgelegten Zustandes
kann der Systemmanagementcontroller dann zusätzlich zu der Ausführung der
Funktionen des Betriebsmodus, der angenommen wurde, Anforderungen
von anderen Controller verarbeiten (309).
-
Wenn
eine Reaktion innerhalb der Zeitablauffrist (z. B. 100 ms) nicht
empfangen wird (304 und 306), dann kann der Controller
feststellen, ob ein Wiederholungsgrenzwert erreicht worden ist (307).
Wenn der Wiederholungsgrenzwert noch nicht erreicht worden ist,
kann der Controller zurück
in den Anforderungszustand wechseln, kann eine weitere Controllermodusanforderung
senden und kann warten, wie oben diskutiert. In einer Ausführungsform
kann der Wiederholungsgrenzwert gleich drei Wiederholungen sein.
Natürlich
können andere
Zeitablauffristen und Wiederholungsgrenzwerte verwendet werden.
Wenn der Wiederholungsgrenzwert erreicht worden ist, kann der Controller
sich selbst in den Aktiv-BMC-Modus versetzen (308). Nach
dem Annehmen des BMC-Modus kann der Controller dann, zusätzlich zur
Ausführung
der BMC-Funktionen, Anforderungen von anderen Controller verarbeiten
(309). Wenn also in dieser Ausführungsform ein Controller keine Reaktion
auf eine Controllermodusanforderung erhält, kann er den BMC-Modus annehmen.
Die Priorität
kann auf beliebigen unterschiedlichen Faktoren beruhen, wie zum
Beispiel denjenigen, die mit Bezug auf 5 unten
diskutiert werden. In anderen Ausführungsformen kann das Protokoll
möglicherweise
nicht jeden der Zustände
erfordern, die gezeigt werden, oder kann zusätzliche Zustände umfassen.
Der Controller hat zum Beispiel möglicherweise keinen Reset-Zustand. Außerdem braucht
das Annehmen eines Zustands, wie oben diskutiert, nicht zu erfordern,
daß der
Controller eine positive Rückmeldung
liefert.
-
In
dem Beispiel, das oben diskutiert wird, haben alle Controller außer einem
vorher einen Betriebsmodus angenommen. Das Verfahren, das in 3 gezeigt
wird, ist jedoch auch in anderen Situationen anwendbar, wie zum
Beispiel wenn das ganze System rückgesetzt
wurde und alle Controller im wesentlichen zur selben Zeit initialisiert
werden. Wenn alle Controller initialisiert werden, können sie
gemäß einer
Ausführungsform im
wesentlichen zur selben Zeit jeweils ein Verfahren ausführen, wie
zum Beispiel in 3 gezeigt. Daher kann eine Reihe
von Managementcontrollern im System jeweils eine Modusanforderung
an die anderen Managementcontroller senden. Jeder dieser Controller
kann dann auf jede Modusanforderung, die empfangen wurde, Reaktionen
(oder nicht Reaktionen), zum Beispiel durch Senden einer Reaktionsmitteilung
an den Controller, der die Anforderung gesendet hat. In einer Ausführungsform
wird bestimmt, daß einer
der Controller zu Anfang der zentrale Managementcontroller für das System
ist, was auf dem Fehlen einer Reaktion auf die Modusanforderung
beruht, die von diesem Controller gesendet wurde.
-
In
einer weiteren Ausführungsform
fehlt eine Reaktion auf eine Modusanforderung, wenn eine Schwellwertzahl
von Anforderungen vom Controller gesendet worden ist, ohne daß innerhalb
einer Zeitüberwachungsdauer
eine Reaktion erhalten wurde.
-
4 ist
ein Flußdiagramm
eines Verfahrens zur Reaktion auf eine Controller-Modusanforderung
gemäß einer
Ausführungsform
der vorliegenden Erfindung. Dieses Verfahren kann zum Beispiel von
einem Systemmanagementcontroller beim Empfang einer Controllermodusanforderung
(wie zum Beispiel die Controllermodusanforderung 260 von 2 oder
die Controllermodusanforderung 510 von 5)
ausgeführt
werden. In einer Ausführungsform
ist das Verfahren, das in 4 illustriert
wird, Teil eines Controller-Modusverhandlungsprotokolls,
und das Verfahren kann zum Beispiel durch Anweisungen des Modusverhandlungsprotokolls, das
in 1 gezeigt wird, ausgeführt werden. Dieses Verfahren
kann von einem Controller vor, nach oder parallel zum Senden einer
Modusanforderung durch diesen Controller ausgeführt werden (wie zum Beispiel
im Verfahren von 3 gezeigt).
-
Gemäß der Ausführungsform,
die in 4 gezeigt wird, empfängt ein erster Systemmanagementcontroller
(der als Empfänger
bezeichnet werden kann) eine Controllermodusanforderung von einem
zweiten Systemmanagementcontroller (der als Anforderer bezeichnet
werden kann) (401). Der Empfänger kann dann seinen aktuellen
Verhandlungsprotokollstatus bestimmen (402). Der Empfänger kann
zum Beispiel feststellen, daß er
aktuell im SMC-Modus ist. Der Empfänger kann dann feststellen,
ob das Modusverhandlungsprotokoll festlegt, daß in diesem Fall die Reaktion
auf der relativen Priorität
beruhen soll (403), und wenn ja, kann er die relative Priorität des Anfordernden
und des Empfängers
bestimmen (404). Der Empfänger kann dann feststellen,
ob das Modusverhandlungsprotokoll festlegt, daß in diesem Fall eine Reaktion
gesendet werden soll (405), und wenn ja, kann er eine Reaktion
an den zweiten Systemmanagementcontroller senden (406).
Die Reaktion kann einen Zustand festlegen, in den der zweite Systemmanagementcontroller
eintreten soll. Wenn keine Reaktion gesendet werden soll, kann der
Empfänger
feststellen, ob das Modusverhandlungsprotokoll festlegt, daß der Empfänger in
diesem Fall in einen Wartezustand wechseln soll (407),
und wenn ja, so kann der Empfänger
sich selbst in einen Wartezustand versetzen (408). Die
relative Priorität
kann bestimmt werden, wie unten mit Bezug auf 5 diskutiert,
und ein Beispiel für
eine Ausführungsform
eines Modusverhandlungsprotokolls für verschiedene Fälle wird
in 6 und in Tabelle I unten angeführt.
-
Gemäß einer
Ausführungsform
der Erfindung kann also eine Reaktion, die zurück an den Absender der Controllermodusanforderung
gesendet wird, zumindest teilweise auf dem aktuellen Status des
Empfängers
beruhen. Die Reaktion kann zumindest teilweise auf den Controllermodusfähigkeiten
des Empfängers
beruhen und kann zumindest teilweise auf einer nutzerkonfigurierten
Moduspräferenz
beruhen. Das Verfahren, das in 3 und in 4 gezeigt
wird, kann als Teil eines Controllerstartprozesses ausgeführt werden.
Obwohl die Schritte des Verfahrens, die in 3 und in 4 gezeigt
werden, in der Reihenfolge diskutiert werden, wie sie gezeigt werden,
in anderen Ausführungsformen
können
einige der Schritte in anderen Reihenfolgen ausgeführt werden.
Ein Systemmanagementcontroller kann zum Beispiel eine Controllermodusanforderung
senden und im wesentlichen zur selben Zeit auf eine oder mehrere
Anforderungen reagieren, die er empfangen hat.
-
5 ist
ein Blockdiagramm einer Controllermodusanforderung 510 und
einer Reaktion 520 gemäß einer
Ausführungsform
der vorliegenden Erfindung. Die Controllermodusanforderung 510 kann
zum Beispiel die Controllermodusanforderung 260 von 2 sein,
und die Reaktion 520 kann zum Beispiel die GoToSMC-Reaktion 261 oder
die Warte-Reaktion 262 von 2 sein.
In einer Ausführungsform
sind die Controllermodusanforderung 510 und die Reaktion 520 Mitteilungen,
die die IPMI-Spezifikation erfüllen,
in diesem Fall können
sie als Anweisungen bezeichnet werden. In einer Ausführungsform
können
die Controllermodusanforderung 510 und die Reaktion 520 die
Gruppenerweiterungsnetzfunktion (z. B. die Netzfunktion = 2Ch/2Dh)
verwenden, die in der IPMI-Spezifikation definiert ist. Wie oben
diskutiert, können
die Controllermodusanforderung 510 und die Reaktion 520 für die Modusverhandlung
verwendet werden. In einer Ausführungsform
können
die Controller die Controllermodusanforderung 510 senden,
wenn sie sich im Anforderungszustand befinden, und können nach
dem Senden der Controllermodusanforderung auf den Empfang der Reaktionen
warten.
-
Wie
in 5 gezeigt, umfaßt die Controllermodusanforderung 510 die
Felder Kopfteil (Header) 511, Leistungsfähigkeit 512,
Nutzerpräferenz 513,
Modulart 514 und geographische Adresse 515. In
einer Ausführungsform
können
die Informationen in der Controllermodusanforderung 510 zum
Bestimmen der relativen Controllerprioritäten verwendet werden. In einer
Ausführungsform
ist der Fähigkeitssatz
die schnelle Prioritätskontrolle.
Wenn in einer weiteren Ausführungsform
der Fähigkeitssatz
gleich ist, wird die nutzerkonfigurierte Präferenz als sekundäre Prioritätskontrolle
verwendet. Wenn in einer weiteren Ausführungsform sowohl der Fähigkeitssatz
wie auch die Nutzerpräferenz
gleich sind, wird die Modulart als tertiäre Prioritätskontrolle verwendet. In einer
weiteren Ausführungsform
wird die geographische Adresse verwendet, wenn die anderen Kriterien
gleich sind. Natürlich
sind Controllermodusanforderung 510 und Reaktion 520 nur
Beispiele für
mögliche Formate.
Den Feldern können
andere Prioritätsordnungen
zum Bestimmen der relativen Controllerpriorität zugewiesen werden, und es
können
andere Felder verwendet werden.
-
In
einer Ausführungsform
kann das Fähigkeitsfeld 512 die
Systemmanagementmodusfähigkeiten
des Controllers anzeigen, der die Controllermodusanforderung 510 sendet.
In einer Ausführungsform
sind verfügbare
Fähigkeitssätze Nur-BMC,
BMC/SMC und Nur-SMC. In einer weiteren Ausführungsform ist Nur-BMC die höchste Priorität, und Nur-SMC
ist die niedrigste Priorität.
In einer Ausführungsform
ist das einzige Modul, das Nur-BMC sein kann, ein Modul, das zum
zentralen Managementagenten für
das Chassis bestimmt ist, das als "Chassismanagementmodul" (CMM) bezeichnet
werden kann und das für
Stern- oder Hybridtopologien ausgelegt ist. In einer Ausführungsform
können
Controller mit dem BMC/SMC-Fähigkeitssatz
(d. h. Controller, die entweder als BMC oder als SMC fungieren können) optional
ein Nutzerkonfigurationsmerkmal implementieren, das einem Nutzer
ermöglicht,
eine Präferenz
für BMC,
SMC oder keine Präferenz
festzulegen. Ein Nutzer kann eine solche Präferenz unter Verwendung zum
Beispiel einer BIOS-Einstelloption, einer Softwareeinstellung, eines
DIP-Schalters, einer Kurzschlußbrückeneinstellung
oder Betreiben oder Laden von Software eingeben. Diese Informationen
können
im Nutzerpräferenzfeld 513 der
Controllermodusanforderung 510 enthalten sein. In einer
Ausführungsform
können
Module, die kein Nutzerpräferenzmerkmal
implementieren, einschließlich Nur-BMC-
und Nur-SMC-Modulen,
keine Präferenz
anführen.
In einer Ausführungsform
ist Nur-BMC die höchste
Priorität,
keine Präferenz
ist mittlere Priorität,
und Nur-SMC ist die niedrigste Priorität. Da unterschiedliche Modularten
unterschiedliche geographische Adreßdomänen haben können, kann in Ausführungsformen die
Modulart bei der Bestimmung der Priorität verwendet werden. In einer
Ausführungsform
sind unterschiedliche verfügbare
Werte für
das Modulartfeld 514, in der Reihenfolge von der niedrigsten
zur höchsten
Priorität, Leistungsmodul,
andere chassisspezifische Arten, Lüfterwanne, Knotenplatine, Schaltfeld
und anwendungsspezifisches CMM. Natürlich können andere Modularten und
andere Prioritätsordnungen
verwendet werden.
-
Das
geographische Adreßfeld 515 kann
die geographische Adresse (z. B. Steckplatzadresse) für das Modul
enthalten, von dem der Controller ein Teil ist. Wenn in einer Ausführungsform
ein Vergleich anderer Kriterien zu einem Gleichstand führt, wird
festgelegt, daß der
Controller mit der niedrigeren geographischen Adresse die höhere Priorität hat. In
einer weiteren Ausführungsform
können
Controller in den BMC-Zuständen ebenfalls
die geographische Adresse für
die Entscheidung verwenden, wie zu reagieren ist. BMCs können zum Beispiel
die geographische Adresse zur Bestimmung verwenden, welches Modul
nach einem ersten Hochfahren aktiv sein soll.
-
Wie
oben diskutiert, können
Controller, die eine Controllermodusanforderung empfangen, auf der
Basis ihres aktuellen Status und der Priorität des Anfordernden relativ
zu ihren eigenen reagieren. 5 zeigt Reaktion 520,
die ein Kopffeld 521 und ein Datenfeld 523 enthält. In einer
Ausführungsform
enthält
der Kopfteil 520 einen Abschlußcode. In einer Ausführungsform
kann das Datenfeld 521 eine Warte-Reaktion (die anzeigt, daß der Empfänger der
Reaktion in den Wartezustand eintreten soll) oder eine GoToSMC-Reaktion
(die anzeigt, daß der
Empfänger
der Reaktion in den SMC-Zustand übergehen
soll) enthalten. In einer weiteren Ausführungsform kann das Datenfeld
auch andere Reaktionen enthalten, wie zum Beispiel Standby-BMC. Natürlich können in
anderen Ausführungsformen
die Art und das Format der Mitteilungen sich von der unterscheiden,
die in 5 gezeigt wird. Zusätzliche Mitteilungen können zum
Beispiel auch vom Modusverhandlungsprotokoll verwendet werden.
-
6 ist
ein Zustandsdiagramm, das die Zustände und Zustandsübergänge für ein Betriebsartenverhandlungsprotokoll
gemäß einer
Ausführungsform
der vorliegenden Erfindung illustriert. Gemäß einer Ausführungsform
kann ein Systemmanagementcontroller, der das Verhandlungsprotokoll
ausführt,
sich in einem der folgenden Verhandlungszustände befinden, die in 6 gezeigt
werden: Anforderung 620, Warten 630, SMC 640,
Standby-SMC 650 und Aktiv-BMC 660. In dieser Ausführungsform
kann ein Controller im SMC-Zustand sich in einem SMC-Modus befinden,
ein Controller im Standby-BMC-Zustand kann sich im Standby-BMC-Modus befinden,
und ein Controller im Aktiv-BMC-Zustand kann sich im Aktiv-BMC-Modus befinden. In
einer Ausführungsform
unterstützen
einige Controller alle fünf
von diesen Zuständen,
während
andere nur eine Teilmenge der Zustände unterstützen. Der Nur-SMC-Zustand kann der
einzige Zustand sein, der für
einen Controller verfügbar
ist, der nur im Nur-SMC-Modus
arbeiten kann; der Nur-BMC-Zustand kann der einzige Zustand sein, der
für einen
Controller verfügbar
ist, der nur im Nur-BMC-Modus arbeiten kann; und alle fünf Zustände können für einen
Controller verfügbar
sein, der entweder im SMC- oder im BMC-Modus arbeiten kann. In 6 kann der
Reset 610 bedeuten, daß der
Controller einen Rücksetzzustand
erfahren hat (d. h. der Zustand bei einem Controller-Reset oder
-Start).
-
Wenn
in einer Ausführungsform
ein Controller den Reset verläßt, tritt
er in den Anforderungszustand 620 ein. Im Anforderungszustand
kann der Controller eine Controllermodusanforderung senden und auf
Reaktionen warten. Andere Controller, die die Controllermodusanforderung
empfangen, können
gemäß ihrem
aktuellen Status und der relativen Priorität zum Anfordernden reagieren.
Gemäß einer
Ausführungsform
unterstützt
das Verhandlungsprotokoll die Priorisierung, daher übernehmen
Module, die nicht als SMCs fungieren können, die Priorität als BMC
gegenüber
Modulen, die als SMCs fungieren können. Die BMC-Priorität kann auf den
Fähigkeiten,
Präferenzeinstellungen,
Modulart und geographischer Adresse beruhen. Wenn in einer Ausführungsform
keine Reaktion auf die Controllermodusanforderung (nach wiederholten
Versuchen) empfangen wird, kann der Anfordernde sich selbst in den
Aktiv-BMC-Modus versetzen. Anderenfalls kann dem Anfordernden über eine
GoToSMC-Reaktion mitgeteilt werden, in welchem Modus er arbeiten
soll. In einer Ausführungsform
kann der Controller auch eine unverlangte Mitteilung empfangen, die
nicht als Reaktion auf eine bestimmte Controllermodusanforderung
gesendet wurde und die fordert, daß der Controller einen bestimmten
Modus annimmt. Solch eine unverlangte Mitteilung kann als Moduseinstellanweisung
bezeichnet werden. In einer Ausführungsform
werden Moduseinstellanweisungen von einem BMC während der Operation des Systems gesendet,
um Änderungen
an den Controllermodi vorzunehmen, nachdem Anfangsmodi angenommen
worden sind.
-
Die
verschiedenen Zustandswechsel gemäß den Ausführungsformen der Erfindung
werden nun detaillierter beschrieben. Nachdem ein Controller im
Anforderungszustand eine Controllermodusanforderung sendet, kann
er ein oder mehrere Reaktionen empfangen, wie zum Beispiel eine
GoToSMC-Reaktion (622) oder eine Warte-Reaktion (621).
Wenn eine GoToSMC-Reaktion empfangen wird, kann der Controller in
den SMC-Zustand überwechseln
(640). Wenn eine Warte-Reaktion empfangen wird, kann der
Controller in den Warte-Zustand überwechseln
(630). Wenn nach Zeitablauf und wiederholten Versuchen
keine Reaktion empfangen wird, kann der Controller in den Aktiv-BMC-Zustand überwechseln
(624). Außerdem
kann ein Controller im Anforderungszustand eine oder mehrere Moduseinstellanweisungen
empfangen, die den Controller anweisen, in den Standby-BMC-Modus zu wechseln
(623), oder die den Controller anweisen können, in
den SMC-Modus zu wechseln (622).
-
In
der Ausführungsform,
die gezeigt wird, kann ein Controller, der sich im Wartezustand 630 befindet, darauf
warten, eine Moduseinstellanweisung oder eine GoToSMC-Reaktion zu
empfangen. Wenn eine GoToSMC-Reaktion empfangen wird, kann der Controller
in den SMC-Zustand überwechseln
(632). Wenn eine Moduseinstellanweisung empfangen wird,
kann der Controller in den entsprechenden Zustand wechseln, der
in der Moduseinstellanweisung festgelegt ist (z. B. Übergänge in den
Standby-BMC-Zustand 633 oder Übergänge in den SMC-Zustand 632).
Wenn in dieser Ausführungsform
weder eine GoToSMC-Reaktion noch eine Moduseinstellanweisung innerhalb
der Zeitüberwachungsdauer
empfangen wird, kann der Controller zurück in den Anforderungszustand
(631) wechseln, in dem er die Controllermodusanforderung
erneut senden kann.
-
Ein
Controller im SMC-Zustand kann als Satelliten-Managementcontroller
fungieren. Wenn, wie in 6 gezeigt, eine Moduseinstellanweisung
von einem Controller im SMC-Zustand empfangen wird, kann der Controller
in den entsprechenden Zustand wechseln, der in der Moduseinstellanweisung
festgelegt ist (z. B. Übergang
in den Standby-SMC-Zustand 641).
-
Ein
Controller im Standby-BMC-Zustand kann als Standby-BMC fungieren.
Wie oben diskutiert, kann in einer Ausführungsform ein Controller im
Standby-BMC-Zustand synchronisierte Statusinformationen beim aktiven
BMC bewahren und kann eine Überwachungsfunktion
für den
aktiven BMC ausführen.
In einer weiteren Ausführungsform
muß der
Standby-BMC in den aktiven BMC-Zustand (652) wechseln,
wenn der aktive BMC ausfällt.
Je nach der Managementtopologie und den installierten Modulen, kann
ein neuer Standby-BMC beim Ausfallen des aktiven BMC ausgewählt werden.
Wenn, wie in 6 gezeigt, eine Moduseinstellanweisung
von einem Controller im Standby-BMC-Zustand empfangen wird, kann
der Controller in den entsprechenden Zustand wechseln, der in der
Moduseinstellanweisung festgelegt ist (z. B. Übergang in den SMC-Zustand 651 oder Übergang
in den aktiven BMC-Zustand 652).
-
Im
Aktiv-BMC-Zustand kann der Controller normale BMC-Funktionen ausführen. In
einer Ausführungsform
kann der aktive BMC einen Standby-BMC wählen, der für die Topologie geeignet ist,
und kann die Statusinformationen beim Standby-BMC synchronisieren.
In der Ausführungsform,
die oben diskutiert wird, sind die BMC(s) letztendlich verantwortlich
für die
Aufforderung an die anderen verhandelnden Controller, in den SMC-Zustand
zu gehen. In einer Ausführungsform,
zum Beispiel dort, wo Doppelbustopologie verwendet wird, können die
Controller erst von einem BMC aufgefordert werden, in den SMC-Modus
zu gehen, nachdem ein Standby-BMC eingerichtet wurde. In dieser
Ausführungsform
werden Controller daran gehindert, den SMC-Zustand zu erreichen,
bevor ein Standby-BMC eingerichtet ist. Sollte der aktive BMC ausfallen,
bevor ein Standby eingerichtet ist und alle anderen Controller den
SMC-Zustand erreicht
haben, kann das System ohne BMC gelassen werden. In einer Ausführungsform
können
CMMs, die speziell für
die Stern- und Hybridtopologie ausgelegt sind, andere Nicht-CMM-Module vor dem
Einrichten eines Standby-CMM auffordern, in den SMC-Zustand zu gehen,
weil nur ein weiteres Stern- oder Hybrid-CMM das Standby-BMC sein
kann. In einer Ausführungsform
kann das aktive BMC beim Empfang einer Moduseinstellanweisung (662)
in den Standby-BMC-Zustand wechseln, was zum Beispiel passieren
kann, wenn es eine vom Nutzer ausgelöste Umschaltung vom Standby-BMC-
zum Aktiv-BMC-Modus gibt (die als "Failover" bekannt sein kann), falls ein Controller mit
einer Priorität,
die höher
als die des Standby-BMC ist, durch Hot Swapping eingeschaltet wird,
oder aus anderen Gründen.
-
Gemäß einer
Ausführungsform
können
Controller, die eine Controllermodusanforderung empfangen (d. h.
der Empfänger),
dem Anfordernden (d. h. dem Controller, der die Anforderung gesendet
hat) antworten, wie in der folgenden Tabelle I gezeigt. Diese Tabelle
zeigt 15 verschiedene Fälle.
Wie unten gezeigt, kann die Reaktion auf dem Status des Empfängers und
der relativen Priorität
des Anfordernden beruhen. In einigen Fällen hängt die Reaktion von der relativen
geographischen Priorität
des Anfordernden ab, und in einigen Fällen hängt die Reaktion davon ab,
ob ein Standby-BMC bereits eingerichtet wurde. In Tabelle I zeigt
die Bezeichnung "X" an, daß in diesem
Fall der Inhalt der Reaktion nicht auf diesen Kriterien beruht.
Relative Controller-Prioritäten
können
auf der Basis von Fähigkeiten,
Nutzerpräferenz,
Modulart und geographischer Adresse (GA) bestimmt werden, wie diskutiert,
zum Beispiel mit Bezug auf
5.
| Fall | Empfängerstatus | Priorität des Anfordernden ohne
GA | GA-Priorität des Anfordernden | Einen
Standby einrichten | Reaktion |
| 1 | Aktiv-BMC | höher | X | X | Warten |
| 2 | Aktiv-BMC | gleich
oder niedriger | X | ja | Warten
oder GoToSMC |
| 3 | Aktiv-BMC | gleich
oder niedriger | X | nein | Warten
(oder GoToSMC)[1] |
| 4 | Standby-BMC | höher | X | ja | Warten |
| 5 | Standby-BMC | niedriger | X | ja | Warten
oder GoToSMC |
| 6 | Standby-BMC | niedriger | X | ja | GoToSMC |
| 7 | SMC | X | X | X | keine
Reaktion |
| 8 | Warten | höher | X | X | keine
Reaktion |
| 9 | Warten | gleich | höher | X | keine
Reaktion |
| 10 | Warten | gleich | niedriger | X | Warten |
| 11 | Warten | niedriger | X | X | Warten |
| 12 | Anforderung | höher | X | X | keine
Reaktion und selbst auf Warten gesetzt |
| 13 | Anforderung | gleich | höher | X | keine
Reaktion und selbst auf Warten gesetzt |
| 14 | Anforderung | gleich | niedriger | X | Warten |
| 15 | Anforderung | niedriger | X | X | Warten |
-
In
den ersten drei Fällen
in Tabelle I ist der Empfänger
der Controllermodusanforderung der Aktiv-BMC. Wenn die Priorität des Anfordernden
(ohne geographische Adresse) höher
als die Priorität
des Empfängers
ist, dann kann eine Warte-Reaktion gesendet werden. Beispiele für Situationen,
in denen der Anfordernde eine höhere
Priorität
als der Aktiv-BMC haben kann, treten auf, wenn der Anfordernde durch
Hot Swapping angeschlossen wurde, oder wo der Anfordernde eine relativ
lange Zeit benötigt
hat, um die Ruhephase zu verlassen. Ein Anfordernder mit einer höheren Priorität als der
aktive BMC kann in den Wartezustand geschickt werden, statt zum
aktiven BMC zu werden, so daß synchronisiert
werden kann, bevor er zum Aktiv-BMC wird. Wenn die Priorität des Anfordernden
(ohne geographische Adresse) kleiner oder gleich der Priorität des Empfängers ist
und ein Standby-BMC schon eingerichtet wurde, dann kann eine Warte-Reaktion oder
eine GoToSMC-Reaktion gesendet werden. Die Warte-Reaktion kann ausgegeben
werden, wenn der Anfordernde zum neuen Standby-BMC werden soll.
Wenn ein Standby-BMC noch nicht eingerichtet wurde, dann kann in
einer Ausführungsform
der Empfänger
nur eine GoToSMC-Reaktion ausgeben, wenn der aktive SMC ein CMM
ist, das speziell für
eine Stern- oder Hybridtopologie ausgelegt wurde und der Anfordernde
kein CMM ist; anderenfalls kann der Empfänger eine Warte-Reaktion ausgeben.
-
In
den Fällen
4–6 von
Tabelle I ist der Empfänger
im Standby-BMC-Zustand (was definitionsgemäß bedeutet, daß ein Standby-BMC
eingerichtet wurde). In der Ausführungsform, die
gezeigt wird, kann eine Warte-Reaktion gesendet werden, wenn die
Priorität
des Anfordernden höher
als die Priorität
des Empfängers
ist, und eine GoToSMC-Reaktion kann gesendet werden, falls die Priorität des Anfordernden
(ohne geographische Adresse) niedriger als die Priorität des Empfängers ist.
Eine GoToSMC-Reaktion wird im allgemeinen gesendet, wenn die Priorität des Anfordernden
(ohne geographische Adresse) gleich der Priorität des Empfängers ist; eine Warte-Reaktion
kann in diesem Fall aber gesendet werden, wenn es zum Beispiel eine
Entscheidung gegeben hat, den Standby-BMC zu ändern.
-
In
den übrigen
Fällen
7–15 in
Tabelle I hängt
die Reaktion nicht davon ab, ob ein Standby eingerichtet wurde.
In Fall 7 ist der Empfänger
im SMC-Zustand und es wird ungeachtet der relativen Priorität keine
Reaktion gesendet. Daher reagiert in dieser Ausführungsform ein Controller im
SMC-Zustand nicht auf eine Controllermodusanforderung. In den Fällen 8–11 ist
der Empfänger
im Warte-Zustand, und mit der geographischen Priorität wird die
Gleichheit aufgelöst.
In diesen Fällen
wird keine Reaktion gesendet, wenn der Anfordernde eine höhere Priorität hat, und
eine Warte-Reaktion wird gesendet, wenn der Anfordernde eine niedrigere
Priorität
hat. Und schließlich
ist in den Fällen
12–15
der Empfänger
im Anforderungszustand, und mit der geographischen Priorität wird die
Gleichheit aufgelöst.
Wenn in diesen Fällen
der Anfordernde eine höhere
Priorität hat,
wird keine Reaktion gesendet, und der Empfänger versetzt sich selbst in
den Warte-Zustand. Wenn der Empfänger
sich im Anforderungszustand befindet und der Anfordernde eine niedrigere
Priorität
hat, wird eine Warte-Reaktion gesendet.
-
Tabelle
I repräsentiert
nur eine Ausführungsform
eines Verhandlungsprotokolls gemäß der vorliegenden
Erfindung. In anderen Ausführungsformen
können
andere Empfängerzustände verfügbar sein,
und die Reaktionen können
sich in einem oder mehreren Fällen
unterscheiden.
-
In
Ausführungsformen,
die oben offenbart werden, kann ein Controller, der keine Reaktionen
auf die Controllermodusanforderung und Wiederholungsversuche empfängt (und
sich nicht selbst in den Warte-Zustand versetzt hat), sich selbst
in den aktiven BMC-Zustand versetzen. In der Ausführungsform,
die gezeigt wird, werden Controller nur von einem BMC aufgefordert,
in den SMC-Modus zu wechseln, wenn es einen eingerichteten Standby-BMC
gibt, um die Controller daran zu hindern, den SMC-Zustand zu erreichen,
bevor ein Standby-BMC eingerichtet werden kann. Sollte der aktive
BMC ausfallen, bevor ein Standby eingerichtet ist, und alle anderen
Controller den SMC-Zustand erreicht haben, kann das System ohne
BMC gelassen werden. Durch die Verwendung des Modusverhandlungsprotokolls,
das in den Ausführungsformen
der vorliegenden Erfindung offenbart wird, kann automatisch festgestellt
werden, welche Controller die aktiven und Standby-BMC sein werden,
wobei gleichzeitig Konflikte zwischen Controller vermieden werden.
-
Mehrere
Beispiele für
Ausführungsformen
der vorliegenden Erfindung werden hierin speziell erläutert und/oder
beschrieben. Es ist jedoch zu erkennen, daß Modifizierungen und Variationen
der vorliegenden Erfindung von den obigen Lehren erfaßt werden
und innerhalb des Anwendungsbereichs der angehängten Ansprüche liegen, ohne vom Geltungsbereich
der Erfindung abzuweichen. Die Bestimmung der Priorität und das Protokoll
zum Reagieren auf eine Anforderung können beispielsweise von dem
abweichen, was oben gezeigt wird. Als weiteres Beispiel kann das
Systemmanagementverhandlungsprotokoll in Hardware oder Software verkörpert werden.