Plattform-Hinweise: Sun Ultra 450 Workstation und Ultra Enterprise 450 Server

Automatische Systemwiederherstellung (ASR)

Dank der automatischen Systemwiederherstellung (ASR) kann ein Ultra 450-System den Betrieb auch nach bestimmten Ausfällen oder Fehlfunktionen der Hardware fortsetzen. Beim Systemtest nach dem Einschalten (POST = Power-On Self-Test) und bei der OpenBoot-Diagnose (OBDiag) werden defekte Hardware-Komponenten automatisch erkannt, und eine automatische Konfigurationsfunktion in der OBP-Firmware ermöglicht die Dekonfiguration defekter Komponenten und die Wiederherstellung des Systembetriebs. Sofern das System ohne die defekte Komponente funktionieren kann, ermöglicht die ASR-Funktion einen automatischen Neustart des Systems, und zwar ohne Benutzereingriff. Ein solcher "eingeschränkter Neustart" erlaubt eine Fortsetzung des Systembetriebs, während ein Wartungsaufruf generiert wird, der den Austausch der defekten Komponente anfordert.

Wird bei der Einschaltsequenz eine defekte Komponente erkannt, wird diese Komponente dekonfiguriert, und die Boot-Sequenz wird fortgesetzt, sofern das System ohne diese Komponente funktionsfähig ist. Bei einem laufenden System können bestimmte Fehlertypen, zum Beispiel ein Prozessorfehler, bewirken, daß das System automatisch zurückgesetzt wird. In diesem Fall kann das System dank der ASR-Funktion sofort neu starten, sofern es ohne die ausgefallene Komponente funktionsfähig ist. Auf diese Weise wird verhindert, daß eine defekte Hardware-Komponente ein Einschalten des Systems unmöglich macht oder sofort zu einem erneuten Systemabsturz führt.

"Software"-Dekonfiguration mittels Statuseigenschaft

Damit ein eingeschränkter Neustart möglich ist, "markiert" das OBP über die 1275 Client-Schnittstelle (via Gerätebaumstruktur) Geräte als failed (ausgefallen) oder disabled (deaktiviert), indem im zugehörigen Knoten der Gerätebaumstruktur eine entsprechende "Statuseigenschaft" angelegt wird. Für diesen Fall gilt die Konvention, daß UNIX für ein so markiertes Subsystem keinen Treiber aktiviert.

Solange sich die ausgefallene Komponente in einem elektrischen Ruhezustand befindet, also keine willkürlichen Busfehler oder Signalrauschen usw. verursacht, startet das System automatisch neu und nimmt den Betrieb wieder auf, während ein Wartungsaufruf generiert wird.

"Hardware"-Dekonfiguration

In zwei Sonderfällen der Dekonfiguration eines Subsystems (bei CPUs und dem Hauptspeicher) geht das OBP über das Anlegen einer entsprechenden "Statuseigenschaft" in der Gerätebaumstruktur hinaus. In den ersten Momenten nach dem Zurücksetzen muß das OBP die entsprechenden Komponenten initialisieren und funktionell konfigurieren (oder umgehen), damit das restliche System ordnungsgemäß funktionieren kann. Die entsprechenden Aktionen werden auf der Grundlage des Status der beiden NVRAM-Konfigurationsvariablen post-status und asr-status durchgeführt, die die Informationen zum Überschreiben enthalten. Diese Informationen werden entweder über den POST oder über manuelles Überschreiben durch den Benutzer zur Verfügung gestellt (siehe "Manuelles Überschreiben durch den Benutzer bei der automatischen Systemwiederherstellung (ASR)").

CPU-Dekonfiguration

Wenn eine CPU beim Systemtest nach dem Einschalten als defekt markiert wird oder ein Benutzer eine CPU deaktiviert, setzt das OBP das "Master Disable"-Bit für die betreffende CPU. So wird diese CPU bis zum nächsten Zurücksetzen des Systems beim Einschalten effektiv als aktives UPA-Gerät ausgeschaltet.

Speicher-Dekonfiguration

Hauptspeicherfehler zu erkennen und zu isolieren, ist eine der schwierigeren Diagnoseaufgaben. Noch komplizierter wird das Problem durch die verschiedenen Speicher-Interleaving-Modi des Systems und durch die Möglichkeit, DIMMs mit unterschiedlicher Kapazität innerhalb der gleichen Speicherbank zu installieren.

Bei einer defekten Hauptspeicherkomponente dekonfiguriert die Firmware die gesamte Speicherbank, in der der Fehler aufgetreten ist. Dies bedeutet jedoch auch, daß nach einem eingeschränkten Neustart der Interleave-Faktor geringer ist oder die Kapazität der restlichen Speicherbänke nicht zu 1000 % genutzt wird. Je nach Interleave-Faktor kann auch beides der Fall sein.

Manuelles Überschreiben durch den Benutzer bei der automatischen Systemwiederherstellung (ASR)

In den meisten Fällen wird das Ultra 450-System mittels der Standardeinstellungen ordnungsgemäß konfiguriert oder dekonfiguriert. Dennoch empfiehlt es sich, erfahrenen Benutzern eine Möglichkeit des manuellen Überschreibens zur Verfügung zu stellen. Und wegen der Unterschiede zwischen einer "Software-" und einer "Hardware"-Dekonfiguration sind dazu zwei verwandte, aber unterschiedliche Überschreibmechanismen erforderlich.

Überschreiben bei der "Software"-Dekonfiguration

Ein Subsystem, das durch einen bestimmten Knoten in der Gerätebaumstruktur dargestellt wird, kann vom Benutzer über die NVRAM-Variable asr-disable-list deaktiviert werden. Der Wert dieser Variablen besteht einfach aus einer Liste von Pfaden in der Gerätebaumstruktur, die durch Leerzeichen getrennt sind.

ok setenv asr-disable-list /pci/ebus/ecpp /pci@1f,4000/scsi@3

Anhand dieser Informationen weist das Ultra 450-OBP allen Knoten, die in der Variablen asr-disable-list aufgelistet sind, als Eigenschaft den deaktivierten Status ("disabled") zu.

Überschreiben bei der "Hardware"-Dekonfiguration

Bei Subsystemen, die eine "Hardware"-Dekonfiguration erfordern (CPU und Hauptspeicher), dienen die OBP-Befehle asr-enable und asr-disable zur selektiven Aktivierung oder Deaktivierung.

Hinweis -

Es gibt Überschneidungen zwischen dem Überschreiben bei Software- und Hardware-Dekonfiguration. Wenn möglich, sollten die Hardware-Überschreibbefehle asr-enable und asr-disable verwendet werden.

Sie können den Status aller manuell überschriebenen Subsysteme abrufen. Dazu dient ein neuer Benutzerbefehl, nämlich .asr. Dieser erzeugt eine Übersicht über die aktuellen Einstellungen

ok asr-disable cpu1 bank3
ok .asr
CPU0:	Enabled	
CPU1:	Disabled	
CPU2:	Enabled	
CPU3:	Enabled	
SC-Marvin:	Enabled	
Psycho@1f:	Enabled	
Psycho@4:	Enabled	
Psycho@6:	Enabled	
Cheerio:	Enabled	
SCSI:	Enabled	
Mem Bank0:	Enabled	
Mem Bank1:	Enabled	
Mem Bank2:	Enabled	
Mem Bank3:	Disabled	
PROM:	Enabled	
NVRAM:	Enabled	
TTY:	Enabled	
Audio:	Enabled	
SuperIO:	Enabled	
PCI Slots:	Enabled

Optionen für den automatischen Systemstart

OpenBoot stellt einen NVRAM-gesteuerten Schalter mit der Bezeichnung auto-boot? zur Verfügung. Dieser legt fest, ob das OBP das Betriebssystem nach dem Zurücksetzen jedesmal automatisch neu startet. Der Standardwert bei Sun-Plattformen lautet true.

Wenn sich beim Systemtest nach dem Einschalten ein Problem ergibt, wird auto-boot? ignoriert, und ein Systemneustart erfolgt erst, wenn der Benutzer ihn manuell durchführt. Da ein solches Verhalten für einen eingeschränkten Neustart selbstverständlich nicht in Frage kommt, hält das OBP einen zweiten NVRAM-gesteuerten Schalter bereit. Dieser heißt auto-boot-on-error?. Von diesem Schalter hängt es ab, ob das System einen eingeschränkten Neustart versucht, wenn der Ausfall eines Subsystems erkannt wird. Ein eingeschränkter Neustart ist nur dann möglich, wenn beide Schalter, auto-boot? und auto-boot-on-error?, auf true gesetzt sind.

ok setenv auto-boot-on-error? true

Hinweis -

Die Standardeinstellung für auto-boot-on-error? lautet false. Das heißt, das System versucht keinen eingeschränkten Neustart, es sei denn, Sie ändern diese Einstellung in true.Darüber hinaus versucht das System auch keinen eingeschränkten Neustart, wenn es zu einem schweren und nicht behebbaren Fehler kommt, selbst wenn die Möglichkeit eines eingeschränkten Neustarts aktiviert ist. Ein Beispiel für einen schweren und nicht behebbaren Fehler ist die Deaktivierung beider System-CPUs, entweder durch einen Fehler beim Systemtest nach dem Einschalten oder durch einen Benutzereingriff (manuelles Überschreiben).

Rücksetz-Szenarien

Das Standardprotokoll für das Zurücksetzen des Systems umgeht die Firmware-Diagnose vollständig, es sei denn, die NVRAM-Variable diag-switch? ist auf true gesetzt. Die Standardeinstellung dieser Variablen lautet false.

Um bei Ultra 450-Systemen eine automatische Systemwiederherstellung zu unterstützen, ist eine Firmware-Diagnose (POST/OBDiag) bei einigen oder allen Rücksetz-Ereignissen wünschenswert. Statt nun einfach den Standardwert von diag-switch? in true zu ändern, was eine Reihe von Nebenwirkungen mit sich bringt (siehe das Handbuch OpenBoot 3.x Command Reference Manual), stellt das Ultra 450-OBP eine neue NVRAM-Variable namens diag-trigger zur Verfügung. Mit dieser Variablen können Sie festlegen, welche Rücksetz-Ereignisse (wenn überhaupt) automatisch eine Firmware-Diagnose (POST/OBDiag) auslösen sollen. Die Variable diag-trigger und ihre verschiedenen Einstellungen werden in der folgenden Tabelle erläutert.

Hinweis -

diag-trigger hat nur dann eine Wirkung, wenn diag-switch? auf true gesetzt ist.

Tabelle 2-5 Einstellungen für power-reset, error-reset und soft-reset


Einstellung	Funktion
`power-reset` (Standard)	Eine Diagnose wird nur beim Zurücksetzen beim Einschalten durchgeführt.
`error-reset`	Eine Diagnose wird nur beim Zurücksetzen beim Einschalten, schweren Hardware-Fehlern und Rücksetz-Ereignissen im Zusammenhang mit dem Systemüberwachungsprotokoll (Watchdog) durchgeführt.
`soft-reset`	Eine Diagnose wird beim Zurücksetzen immer durchgeführt (Ausnahme: XIR), auch wenn das Zurücksetzen durch die UNIX-Befehle `init` 6 oder reboot ausgelöst wird.
`none`	Unabhängig von der Art des Rücksetz-Ereignisses wird nie automatisch eine Diagnose durchgeführt. Der Benutzer kann eine Diagnose manuell auslösen, indem er die Tasten Stop und d beim Einschalten des Systems gedrückt hält oder indem er beim Einschalten des Systems den Schlüsselschalter am vorderen Bedienfeld in die Diagnoseposition bringt.

Im folgenden Beispiel bewirkt die Variable diag-trigger, daß jedesmal beim Zurücksetzen (außer beim Zurücksetzen durch XIR) eine POST- und eine OpenBoot-Diagnose durchgeführt werden.

ok setenv diag-switch? true
ok setenv diag-trigger soft-reset