Note sulla piattaforma: server Sun Enterprise 250

Automatic System Recovery

La funzione Automatic System Recovery (ASR) permette al server Enterprise 250 di riprendere il funzionamento automaticamente dopo determinati guasti o errori hardware. Il test di avvio POST e la diagnostica OpenBoot Diagnostics (OBDiag) possono rilevare automaticamente i componenti hardware difettosi, mentre la capacità di auto-configurazione integrata nel firmware della OBP permette al sistema di deconfigurare i componenti guasti e di ripristinare il funzionamento del server. Se il sistema è in grado di operare anche senza il componente guasto, la funzione ASR lo riavvia automaticamente, senza bisogno che intervenga l'operatore. Questo "boot degradato" permette al sistema di continuare a operare mentre viene generata una chiamata di assistenza per la sostituzione della parte guasta.

Se viene rilevato il malfunzionamento di un componente durante la sequenza di accensione, il componente viene deconfigurato e, se il sistema può funzionare anche senza quell'elemento, la procedura di boot continua. Nei sistemi in funzione, alcuni tipi di guasti (come un errore di un processore) possono causare un ripristino automatico del sistema. In questo caso, la funzionalità ASR permette al sistema di riavviarsi immediatamente, a condizione che possa operare senza il componente guasto. Questo impedisce che un problema a un componente hardware blocchi l'intero sistema o causi un ulteriore crash.

Deconfigurazione "transitoria" mediante le proprietà di stato

Per supportare il boot degradato, la OBP utilizza l'interfaccia client IEEE 1275 (attraverso la gerarchia dei dispositivi) per "contrassegnare" i dispositivi come failed (guasti) o disabled (disabilitati), creando cioè una proprietà di "stato" appropriata nel nodo corrispondente della gerarchia dei dispositivi. Per convenzione, UNIX non attiva nessun driver per i sottosistemi contrassegnati in questo modo.

Fino a quando il componente difettoso rimane elettricamente inattivo (cioè non può causare errori di bus o disturbi di segnale casuali, ecc.), il sistema può riavviarsi automaticamente e riprendere a funzionare mentre viene generata una chiamata di assistenza.

Deconfigurazione "attiva"

Quando la deconfigurazione riguarda i sottosistemi della CPU e della memoria, la OBP non si limita a creare una proprietà di "stato" appropriata nella gerarchia dei dispositivi, ma esegue una vera e propria azione. Subito dopo il ripristino, la OBP deve inizializzare e configurare (o escludere) funzionalmente queste funzioni per far sì che il resto del sistema possa operare correttamente. Queste azioni vengono eseguite in base allo stato di due variabili di configurazione della NVRAM, post-status e asr-status, che contengono informazioni prioritarie provenienti dal POST o da un'operazione manuale dell'utente (vedere "Priorità dell'utente sulla funzione ASR").

Deconfigurazione della CPU

Se una CPU non supera i test POST, o se l'utente sceglie di disabilitare una CPU, la OBP configura il bit Master Disable di quella CPU, sostanzialmente disattivandola come dispositivo UPA fino al successivo ciclo di accensione del sistema.

Deconfigurazione della memoria

L'identificazione e l'isolamento dei problemi di memoria sono tra le operazioni diagnostiche più difficili. Il problema è complicato ulteriormente dalla possibilità di installare DIMM di capacità differente nello stesso banco di memoria. (Ogni banco di memoria deve contenere quattro DIMM di uguale capacità.) In caso di guasto di un componente della memoria, il firmware deconfigura l'intero banco associato all'errore.

Priorità dell'utente sulla funzione ASR

Anche se, nella maggior parte dei casi, le impostazioni predefinite configurano e deconfigurano il server in modo corretto, è utile fornire agli utenti avanzati una capacità di intervento manuale. Data la diversità tra la deconfigurazione "transitoria" e quella "attiva", è necessario disporre di due meccanismi di intervento, correlati ma differenti.

Deconfigurazione "transitoria" manuale

Ogni sottosistema rappresentato da un nodo distinto nella gerarchia dei dispositivi può essere disabilitato dall'utente attraverso la variabile della NVRAM asr-disable-list, che è un semplice elenco di percorsi di dispositivi separati da spazi.

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

La OBP Enterprise 250 userà queste informazioni per creare la proprietà di stato "disabled" per ogni nodo elencato nella variabile asr-disable-list.

Deconfigurazione "attiva" manuale

Per intervenire sui sottosistemi che richiedono una deconfigurazione "attiva" (CPU e memoria), si utilizzano i comandi della OBP asr-enable e asr-disable per abilitare o disabilitare selettivamente ogni sottosistema.

Nota -

Le deconfigurazioni manuali di tipo transitorio e attivo si possono sovrapporre. Se possibile, si dovrebbero usare i comandi della deconfigurazione "attiva", asr-enable e asr-disable.

È possibile generare una lista di parametri validi per asr-disable e asr-enable definendo entrambi i comandi senza parametri.

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

Per controllare lo stato delle operazioni manuali, è disponibile un nuovo comando, .asr, che riassume le impostazioni correnti.

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

Opzioni per il boot automatico

OpenBoot dispone di uno switch controllato dalla NVRAM denominato auto-boot?, che indica se la OBP debba avviare automaticamente il sistema operativo dopo ogni ripristino. L'impostazione predefinita di questo switch per le piattaforme Sun è true.

Se il sistema non supera i test diagnostici di accensione, lo switch auto-boot? viene ignorato e il sistema può essere avviato solo con un comando manuale dell'utente. Questo comportamento non è accettabile per i casi di boot degradato, perciò la OBP Enterprise 250 dispone di un secondo switch controllato dalla NVRAM, denominato auto-boot-on-error?. Questo switch determina se il sistema debba cercare di eseguire un boot degradato in caso di malfunzionamento di un sottosistema. Per consentire l'esecuzione di un boot degradato, entrambi gli switch auto-boot? e auto-boot-on-error? devono essere configurati come true.

ok setenv auto-boot-on-error? true

Nota -

La configurazione predefinita per auto-boot-on-error? è false. Il sistema non cercherà di eseguire un boot degradato, a meno che questa impostazione non venga modificata in true. Inoltre, il sistema non cercherà di eseguire un boot degradato in risposta ad errori fatali non correggibili, anche se il boot degradato è abilitato. Un esempio di errore fatale non correggibile si ha quando entrambe le CPU del sistema sono state disabilitate, per mancato superamento del POST o in seguito a un intervento manuale dell'utente.

Scenari di ripristino

Il protocollo standard per il ripristino del sistema esclude completamente la diagnostica del firmware. Per abilitarla, è necessario cambiare da false a true la configurazione della variabile della NVRAM diag-switch?.

Per supportare la funzione ASR sui server Enterprise 250, è opportuno poter eseguire la diagnostica del firmware (POST/OBDiag) in tutti gli eventi di ripristino. Invece di cambiare semplicemente l'impostazione predefinita di diag-switch? in true, un'operazione che produce altri effetti collaterali (vedere il documento OpenBoot 3.x Command Reference Manual), la OBP Enterprise 250 dispone di una nuova variabile della NVRAM, denominata diag-trigger, che permette di scegliere quali eventi di ripristino debbano attivare automaticamente un ciclo di POST/OBDiag. La tabella seguente descrive la variabile diag-trigger e le sue possibili impostazioni.

Nota -

diag-trigger ha effetto solo se la variabile diag-switch? è impostata su true.

Tabella 1-4 Effetti dell'impostazione di diag-trigger sul reset


Impostazione	Funzione
`power-reset` (valore predefinito)	Esegue le funzioni diagnostiche solo nei cicli di accensione.
`error-reset`	Esegue le funzioni diagnostiche solo nei cicli di accensione, in caso di errori hardware fatali e in risposta ad eventi di ripristino watchdog.
`soft-reset`	Esegue le funzioni diagnostiche in tutti gli eventi di ripristino (ad eccezione di XIR), inclusi quelli provocati dai comandi UNIX `init` `6` o `reboot`.
`none`	Disabilita l'attivazione automatica delle funzioni diagnostiche in caso di eventi di ripristino. L'utente può comunque attivare la diagnostica manualmente premendo i tasti Stop e d durante l'accensione del sistema, oppure spostando l'interruttore del pannello frontale in posizione Diagnostics all'accensione del sistema.

Nell'esempio seguente, la variabile diag-trigger è configurata per attivare le funzioni diagnostiche POST e OpenBoot in tutte le operazioni di ripristino ad eccezione degli eventi XIR

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