Notes sur les plates-formes : serveur Sun Enterprise 250

Reprise automatique du système

La fonctionnalité de reprise automatique du système (ASR, Automatic System Recovery) permet aux serveurs Enterprise 250 de recommencer à fonctionner après certaines pannes ou défaillances matérielles. L'autotest effectué à la mise sous-tension (POST, Power-on selftest) et les diagnostics OpenBoot (OBDiag) sont en mesure de détecter automatiquement les composants matériels défectueux, tandis qu'une fonctionnalité de configuration automatique intégrée aux micro-programmes OBP permet au système de déconfigurer les composants défectueux et de reprendre son fonctionnement Tant que le système est en mesure de fonctionner sans le composant défectueux, les fonctionnalités ASR permettent au système de se réinitialiser automatiquement sans l'intervention de l'opérateur. Cette "initialisation dégradée" permet au système de continuer à fonctionner jusqu'à ce que vous appeliez le service après-vente pour remplacer la pièce défectueuse.

Si un composant défectueux est détecté pendant la séquence de mise sous tension, il est déconfiguré et, si le système peut continuer à fonctionner sans, la séquence d'initialisation se poursuit. Dans un système en fonctionnement, certains types de pannes (par exemple une panne de processeur) peuvent entraîner une réinitialisation automatique du système. Si cela se produit, la fonctionnalité ASR permet au système de se réinitialiser immédiatement du moment qu'il est en mesure de fonctionner sans le composant défectueux. Cela évite qu'un simple composant matériel défectueux empêche le système de fonctionner ou le bloque de nouveau.

Déconfiguration "douce" au moyen de la propriété d'état

Pour supporter une fonctionnalité d'initialisation dégradée, l'OBP utilise l'interface client IEEE 1275 (via l'arborescence des périphériques) pour "marquer" les périphériques comme étant failed (défectueux) ou disabled (désactivés). Pour ce faire, OBP crée une propriété d'état appropriée dans le nud correspondant de l'arborescence des périphériques. Par convention, UNIX n'activera pas de gestionnaire pour les sous-systèmes marqués de la sorte.

Par conséquent, tant que le composant défectueux est dormant électriquement parlant (c'est-à-dire tant qu'il n'est pas à l'origine d'erreurs de bus aléatoires, de sonneries, etc.), le système peut être réinitialisé automatiquement et reprendre son fonctionnement en attendant que vous appeliez le service après-vente.

Déconfiguration "forte"

Il existe deux cas de déconfiguration d'un sous-système (UC et mémoire), où l'OBP va au-delà de la simple création d'une propriété d'état appropriée dans l'arborescence des périphériques. Dans les instants qui suivent la réinitialisation, l'OBP doit initialiser et configurer du point de vue fonctionnel (ou ignorer) ces fonctions pour que le reste du système fonctionne correctement. Les actions entreprises dans ces deux cas de figure le sont sur la base de l'état de deux variables de configuration NVRAM, post-status et asr-status, qui contiennent les informations de neutralisation fournies par le POST ou via une neutralisation manuelle effectuée par l'utilisateur (reportez-vous à la section "Fonctionnalité de neutralisation de l'utilisateur (ASR)").

Déconfiguration de l'unité centrale

Si une UC est marquée comme ayant échoué au POST ou si un utilisateur choisit de désactiver une UC, l'OBP définira le bit Master Disable de l'UC concernée, ce qui revient en fait à la désactiver comme un périphérique UPA actif jusqu'à la réinitialisation du système lors de la prochaine mise sous tension.

Déconfiguration de la mémoire

Détecter et isoler un problème de mémoire système est l'une des tâches de diagnostic les plus ardues. De plus, ce problème est compliqué par la possibilité d'installer des DIMM de capacités différentes au sein d'un même bloc de mémoire (chaque bloc de mémoire doit contenir quatre DIMM de même capacité). En cas de panne d'un composant de mémoire, les micro-programmes déconfigurent l'ensemble du bloc associé à la panne.

Fonctionnalité de neutralisation de l'utilisateur (ASR)

Bien que dans la plupart des cas les paramètres par défaut pourvoient correctement à la configuration ou à la déconfiguration du serveur, il est conseillé de fournir aux utilisateurs avancés une fonctionnalité de neutralisation manuelle. A cause de la nature différente des déconfigurations "douce" et "forte", deux mécanismes de neutralisation différents sont nécessaires.

Neutralisation de la déconfiguration "douce"

Les utilisateurs peuvent, pour tout sous-système représenté par un nud distinct de l'arborescence des périphériques, désactiver cette fonction au moyen de la variable NVRAM asr-disable-list, qui n'est autre qu'une liste des chemins de l'arborescence des périphériques séparés par des espaces.

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

Les commandes OBP de l'Enterprise 250 utiliseront ces informations pour créer des propriétés d'état désactivé pour chacun des nuds figurant dans la variable asr-disable-list.

Neutralisation de la déconfiguration "forte"

Pour ignorer les sous-systèmes qui nécessitent une déconfiguration "forte" (UC et mémoire), les commandes OBP asr-enable et asr-disable sont utilisées pour activer ou désactiver de manière sélective chaque sous-système.

Remarque :

Les neutralisations douce et forte peuvent faire double emploi. Dans la mesure du possible, utilisez de préférence les commandes de neutralisation forte asr-enable et asr-disable.

Vous pouvez générer une liste des paramètres valides pour asr-disable et asr-enable en émettant l'une ou l'autre de ces commandes sans paramètre.

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

Pour garder trace de l'état de toutes les neutralisations manuelles, une nouvelle commande utilisateur, .asr, est fournie pour résumer les paramètres courants.

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

Options d'initialisation automatique

OpenBoot prévoit un commutateur contrôlé par la NVRAM appelé auto-boot?, qui contrôle si OBP doit initialiser automatiquement le système d'exploitation après chaque réinitialisation. Le paramétrage par défaut pour les plates-formes Sun est true.

En cas d'échec des diagnostics à la mise sous tension d'un système, auto-boot? est ignoré et le système n'est pas initialisé à moins que l'utilisateur ne le fasse manuellement. Ce comportement ne pouvant certes pas être accepté en cas d'initialisation dégradée, les commandes OPB du serveur Enterprise 250 prévoient un second commutateur contrôlé par la NVRAM appelé auto-boot-on-error?. Ce commutateur contrôle si le système tentera une initialisation dégradée en cas de détection d'un sous-système défectueux. Les deux commutateurs auto-boot? et auto-boot-on-error? doivent être mis sur true pour permettre une initialisation dégradée.

ok
setenv auto-boot-on-error? true

Remarque :

Le paramétrage par défaut de auto-boot-on-error? est false. Par conséquent, le système ne tentera pas d'initialisation dégradée tant que vous ne mettrez pas ce paramètre sur true. De même, le système ne tentera pas d'initialisation dégradée en réponse à une erreur bloquante irrémédiable, même si l'initialisation dégradée est activée. Un exemple d'erreur bloquante irrémédiable est la désactivation de toutes les UC d'un système, que ce soit suite à l'échec du POST ou à une neutralisation manuelle effectuée par l'utilisateur.

Scénarios de réinitialisation

Le protocole de réinitialisation système standard ignore complètement les diagnostics des micro-programmes sauf si la variable NVRAM diag-switch? est sur true. Le paramétrage par défaut de cette variable est false.

Pour supporter l'ASR dans un serveur Enterprise 250, il est préférable de pouvoir exécuter les diagnostics des micro-programmes (POST/OBDiag) lors de tout événement de réinitialisation. Au lieu de simplement changer le paramétrage par défaut de diag-switch? en le mettant sur true, ce qui a des effets secondaires (cf. OpenBoot 3.x Command Reference Manual), les commandes OBP du serveur Enterprise 250 prévoient une nouvelle variable NVRAM appelée diag-trigger qui vous permet de choisir quels événements de réinitialisation, le cas échéant, engageront automatiquement le POST/OBDiag. La variable diag-trigger et ses différents paramétrages sont décrits dans le tableau suivant.

Remarque :

diag-trigger n'a aucun effet sauf si diag-switch? est sur true.

Tableau 1-4 Paramétrage de déclenchement des diagnostics lors des réinitialisations et effets


Paramétrage	Fonction
`power-reset` (valeur par défaut)	Exécute les diagnostics uniquement lors des réinitialisations à la mise sous-tension.
`error-reset`	Exécute les diagnostics uniquement lors des réinitialisations à la mise sous-tension, en cas d'erreurs matérielles bloquantes et d'événements de réinitialisation du temporisateur de surveillance.
`soft-reset`	Exécute les diagnostics lors de toutes les réinitialisations (à l'exception des réinitialisations XIR), y compris lors de celles déclenchées par les commandes UNIX `init` `6` ou `reboot`.
`none`	Désactive le déclenchement automatique des diagnostics par tout événement de réinitialisation. Les utilisateurs peuvent toujours appeler les diagnostics manuellement en maintenant enfoncées les touches Stop et d lors de la mise sous tension du système, ou en tournant le commutateur à clef du panneau de commande dans la position Diagnostics lors de la mise sous tension du système.

Dans l'exemple suivant, la variable diag-trigger est utilisée pour déclencher les diagnostics POST et OpenBoot lors de toutes les réinitialisations à l'exception des réinitialisations XIR.

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