Plattform-Hinweise: Sun Enterprise 250 Server

Automatische Systemwiederherstellung (ASR)

Dank der automatischen Systemwiederherstellung (ASR) kann der Enterprise 250-Server 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 IEEE 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 Möglichkeit, DIMMs mit unterschiedlicher Kapazität innerhalb der gleichen Speicherbank zu installieren. Dabei muß allerdings jede Speicherbank vier DIMMs gleicher Kapazität enthalten. Bei einer defekten Hauptspeicherkomponente dekonfiguriert die Firmware die gesamte Speicherbank, in der der Fehler aufgetreten ist.

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

In den meisten Fällen wird der Server 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@1f,2000 /pci@1f,4000/scsi@3,1

Anhand dieser Informationen weist das Enterprise 250-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 eine Liste der gültigen Parameter für asr-disable und asr-enable abrufen, indem Sie den gewünschten Befehl ohne Parameter eingeben.

ok asr-disable
? Invalid subsystem name: 
Known 'enable/disable' subsystem components are: 
bank*         bank3         bank2         bank1         bank0 
dimm15        dimm14        dimm13        dimm12        dimm11
dimm10        dimm9         dimm8         dimm7         dimm6
dimm5         dimm4         dimm3         dimm2         dimm1
dimm0         cpu*          cpu1          cpu0 
ok

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	
SC-MP:	Enabled	
Psycho@1f:	Enabled	
Cheerio:	Enabled	
SCSI:	Enabled	
Mem Bank0:	Enabled	
Mem Bank1:	Enabled	
Mem Bank2:	Enabled	
Mem Bank3:	Disabled	
PROM:	Enabled	
NVRAM:	Enabled	
TTY:	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 Enterprise 250-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 manuelles Überschreiben seitens des Benutzers.

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 Enterprise 250-Servern 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 Enterprise 250-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 1-4 Einstellungen und Auswirkungen der Variablen zum Auslösen der Diagnose beim Zurücksetzen


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