Procédures OLAR des cartes PCI : généralités et concepts

Introduction

OLAR est l'acronyme de On Line Addition [and] Replacement (ajout et remplacement en-ligne). Il traduit la possibilité, sur les ordinateurs HP-UX conçus à cet effet, de remplacer, c'est à dire d'ajouter ou de retirer, des cartes E/S PCI sans qu'il soit nécessaire de fermer complètement puis de réamorcer le système, ni de gêner inutilement le fonctionnement des autres composants du système. Sur l'appareil, l'alimentation des logements est contrôlée individuellement, et le système d'exploitation supporte cette fonction.

Dans les premiers temps, toutes les cartes à ajouter ne posséderont pas nécessairement cette fonction ; toutefois, les utilisateurs devraient progressivement voir se généraliser les cartes qui ajouteront cette option à l'ensemble de leurs fonctions.




	IMPORTANT : Certaines « Classes » de matériel ne sont pas prévues pour que les utilisateurs puissent y accéder, comme, actuellement, les systèmes Classe V et Superdome. HP recommande de ne laisser personne d'autre qu'un ingénieur agréé HP ouvrir ces systèmes. A défaut, le propriétaire de ces appareils pourrait perdre tout droit au support technique ou aux garanties prévus.

Termes et concepts importants

Tableau 2-1 Termes utilisés dans cette section

Terme	Définition
OLAR	Tous les aspects de la fonction OLAR, y compris les fonctions d'ajout en ligne (OLA) et de remplacement en-ligne (OLR).
Domaine d'alimentation	Un ensemble composé d'un ou de plusieurs logements pour cartes d'interface et qui sont mis ensemble sous tension ou hors tension. Les systèmes actuels ne disposent que d'un logement par domaine d'alimentation.
Carte cible / logement de carte cible	La carte d'interface qui doit être ajoutée ou remplacée à l'aide des procédures OLAR, et le logement de carte correspondant.
Carte concernée / logement de carte concernée	Les cartes d'interface et les logements de carte correspondants qui appartiennent au même domaine d'alimentation que le logement cible. Actuellement, il n'existe pas de domaine d'alimentation à logements multiples.




	IMPORTANT : Dans de nombreux cas, d'autres cartes d'interface et d'autres logements du système dépendent de la carte cible. Exemple : Lorsque la carte cible est une carte multifonctions (CMF), la neutralisation des pilotes correspondants au logement de carte cible neutralisent également les pilotes individuels pour les multiples chemins physiques de cette carte. Si la carte cible possède plusieurs ports, chacun d'eux sera neutralisé, puis réactivé lorsque la carte sera remise en place. Sur les systèmes actuellement livrés, un domaine d'alimentation se compose d'un unique logement de carte. A l'avenir, toutefois, les systèmes pourront disposer de domaines d'alimentation multi-cartes. Si vous mettez provisoirement hors tension le logement de la carte cible alors qu'il appartient à un domaine d'alimentation multi-cartes, vous couperez également l'alimentation de tous les autres logements de carte (logements de cartes concernées) de ce même domaine d'alimentation.

Lorsque vous remplacez une carte, SAM effectue une Analyse des ressources critiques, c'est à dire qu'il recherche sur tous les ports de la carte cible si certaines ressources critiques risquent d'être provisoirement indisponibles lorsque la carte sera mise hors tension.

Planification et préparation

Dans la plupart des cas, SAM vous empêche d'effectuer des procédures OLAR susceptibles d'affecter d'autres zones du serveur. Vous trouverez dans cette section d'importantes informations capables de vous aider à réduire au minimum les erreurs et les problèmes en exécutant les procédures OLAR.

Compatibilité de la carte avec le système

Ajout en-ligne (OLA)

Avant d'ajouter en-ligne une carte d'interface, le premier travail consiste à déterminer la compatibilité de la nouvelle carte avec le système. Chaque logement PCI compatible OLAR peut fournir une quantité donnée de courant électrique. La carte de remplacement ne doit donc pas exiger plus de courant que le logement ne peut lui en fournir. Les systèmes actuels ne possèdent qu'un seul logement par bus disposant de l'alimentation nécessaire.

La carte doit également être compatible avec la fréquence de bus du logement. Une carte PCI doit être capable de travailler à n'importe quelle fréquence inférieure à sa fréquence maximale, mais une carte qui ne peut travailler qu'à 33 MHz ne peut pas fonctionner sur un bus à 66 MHz. rad fournit des informations sur les logements : fréquence de bus, quantité d'électricité disponible, etc.

Lorsque la carte de remplacement est ajoutée au système, le pilote correspondant à cette carte doit être configuré dans le noyau avant de commencer l'opération. (Dans la plupart des cas, la carte de remplacement est du même type que la carte déjà installée dans le système, et le pilote se trouvera dans le noyau.) Si vous doutez de la présence du pilote dans le noyau, utilisez la zone « Kernel Configuration » de SAM pour identifier les pilotes chargés dans le noyau. Si le pilote cherché est à chargement dynamique et ne se trouve pas dans le noyau, il devra être chargé dans cette zone de SAM avant de lancer l'opération OLA. Si le pilote n'est pas à chargement dynamique et n'est pas présent dans le noyau, vous devrez réamorcer le système pour le charger. Vous pourrez profiter de la mise hors tension du système pour installer la carte ou l'ajouter en-ligne après le réamorçage.

Si le pilote est un module de noyau à chargement dynamique (DLKM) mais n'est pas présent dans le noyau, vous pourrez le charger manuellement. Pour plus de détails sur le sujet, consultez la section « Modules de noyau à chargement dynamique (DLKM : Dynamically Loadable Kernel Modules) ».
Si le pilote est statique mais pas configuré dans le noyau, la carte ne peut pas être ajoutée en en-ligne (OLA) : bien qu'elle puisse être physiquement insérée en-ligne, aucun pilote ne la reconnaîtrait.

Pour les utilisateurs qui souhaitent mettre en ouvre les fonctionnalités OLAR, il peut s'avérer nécessaire de mettre à jour le firmware. Pour de plus amples renseignements, consultez le document Informations importantes à lire avant l’installation ou la mise à jour de HP-UX 11i livré avec le produit HP.

Remplacement en-ligne (OLR)

Lorsque vous remplacez une carte d'interface en-ligne, la carte de remplacement doit être identique à l'ancienne (c'est la solution la plus sûre) ou capable d'utiliser le même pilote qu'elle. Ce type de remplacement à l'identique est nettement préférable car l'utilisation d'une carte semblable mais pas identique peut avoir des conséquences imprévisibles. Par exemple, une version plus récente de la carte cible, qui serait identique en termes physiques mais contiendrait une version mise à jour du micrologiciel, pourrait créer un conflit avec le pilote actuel. Si la nouvelle carte ne convient pas, SAM ou rad signaleront que la carte ne peut pas être réactivée.

Pendant le processus de remplacement, l'instance du pilote de chaque port de la carte cible s'exécute en mode neutralisé. Les E/S des ports sont mises en file d'attente ou bien en échec pendant que les pilotes sont en mode neutralisé. Lorsque la carte de remplacement est remise en-ligne, les instances du pilote reprennent leur exécution normale. Chaque instance du pilote doit être capable de reprendre et de contrôler le port correspondant sur la carte de remplacement.

La spécification PCI permet à une même carte d'avoir plusieurs ports. Un adaptateur de bus SCSI mono-port ne peut pas être remplacé par un adaptateur double port, même si le port supplémentaire sur la carte est identique à l'adaptateur de bus SCSI initial. Si la carte de remplacement possède plus de ports que l'ancienne, la prochaine exécution de ioscan, après que l'alimentation du logement sera rétablie, pourra affecter les ports supplémentaires à d'autres pilotes. Pour régler le problème, vous devrez alors réamorcer le système.

Ressources critiques

Le remplacement d'une carte en cours de fonctionnement peut avoir de très lourdes conséquences. Comme le logement doit être mis hors tension pour retirer l'ancienne carte et insérer la nouvelle, il convient de réfléchir aux conséquences de l'interruption des fonctions de la carte.Ceci est particulièrement important s'il n'existe en-ligne aucune autre carte pour prendre ces fonctions en charge. Exemple :

Quelles unités de stockage de masse seront provisoirement déconnectées lorsque la carte sera arrêtée ?
Y a-t'il un risque de perdre une connexion de réseau importante ?

Une ressource critique est une ressource susceptible d'entraîner un incident du système ou d'empêcher l'aboutissement d'une opération si cette ressource est provisoirement neutralisée ou déconnectée. Si, par exemple, l'adaptateur SCSI que vous devez remplacer se connecte à un disque racine ou à un espace de permutation qui n'a pas de miroir, le système tombera en panne lorsque vous arrêterez la carte.Au cours d'une procédure OLAR, il est primordial de vérifier si les fonctions importantes de la carte ciblée - ressources critiques, connexions diverses, etc. - peuvent être prises en charge par une autre carte qui, elle, ne sera pas affectée.

Heureusement, SAM exécute automatiquement une analyse approfondie des ressources critiques et propose des options en fonction de ses résultats. Si la procédure doit affecter certaines ressources critiques, vous pouvez remplacer la carte lorsque le serveur est hors ligne ou vous pouvez utiliser soit radsoit SAM pour ajouter en-ligne une carte « doublure » que vous configurerez en conséquence, et remplacer alors la carte cible.

Remarque : SAM analyse les cartes de la manière suivante :

Les cartes de stockage de masse sont analysées suivant :
- les systèmes de fichiers montés
- leur utilisation par un traitement
- l'utilisation d'un vidage ou d'une permutation
Les cartes d'interface de réseau sont analysées suivant :
- leur utilisation par la session active de SAM

Les actions en cas d'échec, les points de défaillance uniques

Le plus souvent, le système se rabat automatiquement sur une ressource de secours lorsqu'une carte est arrêtée. Toutefois, certains sous-systèmes peuvent exiger une intervention manuelle. Le gestionnaire de volumes logiques (LVM), par exemple, redirige automatiquement les E/S d'une unité disque momentanément déconnectée vers un miroir, et consigne les erreurs tout le temps qu'il gère la situation.

Dans ce cas, et si la ressource reste indisponible pendant trop longtemps, le nombre des entrées dans le journal d'erreurs peut devenir très important.
Si vous pensez en arriver à ce type de situation, il peut être intéressant de commencer par commuter manuellement les E/S vers un miroir. Une fois la procédure OLAR terminée, il suffit de resynchroniser le miroir et le disque.

Si, après avoir neutralisé une carte, sa doublure prend la relève, le système peut contenir un point de défaillance unique. Si la doublure connaît une défaillance avant que la nouvelle carte ait été remise en-ligne, le système risque de tomber en panne. Pour éviter ce problème, essayez de limiter autant que possible la durée de neutralisation, ce qui demande une planification soigneuse et la recherche de toutes les informations possibles avant de neutraliser véritablement le fonctionnement du pilote et de couper l'alimentation du logement de carte.

Lorsque le temps d'intervention est inévitablement long ou quand le système n'a pas le droit de tomber en panne, il est préférable de commencer par configurer une ressource de rechange.

Scripts OLAR

A différentes étapes dans les procédures OLAR, SAM peut démarrer certaines commandes qui avertissent le système de l'ajout ou du remplacement d'une carte d'interface.

Ces commandes sont contenues dans des scripts OLAR développés par des ingénieurs de pilotes logiciels et reposant sur les spécifications d'application ou de système pour la carte d'interface cible.
Chaque périphérique comporte un ou plusieurs scripts (si nécessaire, certains périphériques peuvent posséder plusieurs scripts). Pour plus de détails, consultez les descriptions suivantes.
Les scripts sont exécutés par SAM et, pour la plupart, ne requièrent aucune intervention de l'utilisateur.

Commandes de scripts OLAR

Commandes pref-OLAR (opérations préalables)

SAM exécute des scripts pref-OLAR afin d'identifier et de signaler les conséquences d'une neutralisation ou d'une suppression (par exemple, les applications qui utilisent des ressources) et dans quelle mesure elles peuvent rendre un noeud E/S inopérant. (La tâche qui consiste à neutraliser un noeud E/S est réalisée au cours des scripts prep-OLAR.)

Scripts prep-OLAR (opérations de préparation)

SAM exécute les scripts prep-OLAR juste avant de neutraliser les opérations logicielles du pilote ; ces scripts constituent la première étape du remplacement d'une carte contrôleur PCI, et contiennent les instructions indispensables pour mettre hors service la ressource cible, avant de bloquer véritablement toute activité vers et en provenance du périphérique. Par exemple, un script de préparation au remplacement (prep-replace) peut vérifier la présence d'un anneau à jeton, de fonctions à haute disponibilité, de relais de commutation ou de dispositifs de sauvegarde disponibles.




	REMARQUE : Un script est livré au pilote de la carte et installé dans le répertoire /usr/sbin/olrad.d/. Il effectue tout le travail préparatoire nécessaire avant que le pilote ne neutralise le fonctionnement de la carte. Si aucune commande préparatoire n'est nécessaire, le script ne sera pas exécuté.

Au cours de l'exécution d'un script prep-OLAR, les actions suivantes sont « forcées », ce qui signifie que les commandes qui suivent sont sensées aboutir. Si le script rencontre une erreur, il essaiera de reprendre le cours des opérations depuis le début.

Scripts post-OLAR (après les opérations)

SAM exécute les scripts post-OLAR juste après qu'une carte PCI ait été ajoutée ou remplacée, et initialisée. Ces scripts contiennent les instructions nécessaires pour mettre en service la carte remplacée avant que l'activité vers et en provenance de la carte ne soit véritablement (re)démarrée. Par exemple, un script exécuté après un ajout (post_add) peut créer des fichiers spéciaux pour la nouvelle carte et pour tous les périphériques qu'elle gère.

CONSIDERATIONS AVANCEES

Nous présentons dans cette section d'autres situations que vous pourriez rencontrer en exécutant des procédures OLAR, ainsi que la manière d'y répondre en ce qui concerne :

les domaines d'alimentation
les cartes multiports

Les domaines d'alimentation

Un domaine d'alimentation est un ensemble composé d'un ou de plusieurs logements pour cartes d'interface et qui sont mis ensemble sous tension ou hors tension. Actuellement, il n'existe aucun système capable de supporter plus d'un logement de carte d'interface sur le même domaine d'alimentation. Dans les versions ultérieures, lorsque les systèmes pourront supporter plusieurs cartes sur un même domaine d'alimentation, SAM et rad seront capables de les reconnaître.

SAM n'autorise pas l'exécution d'une commande OLAR d'une carte si l'un quelconque des membres de son domaine d'alimentation est une ressource critique.

Les cartes multiports

Certaines cartes PCI peuvent remplir plusieurs fonctions. Ces cartes multi-ports possèdent des chemins physiques distincts pour chaque port, ainsi que des pilotes différents liés à chaque chemin physique.

SAM et rad reconnaîtront les cartes multi-ports, et pourront neutraliser et réactiver chaque port associé à un logement. SAM tiendra compte de chaque port pendant l'analyse de ressources critiques et exécutera des scripts pour chaque port si nécessaire.

Ports virtuels

La conception de certains pilotes utilise la création de ports « virtuels » qui ne correspondent directement à aucune adresse physique. Les ports virtuels peuvent être normalemet identifiés par le pilote qui les contrôle. Par exemple, les pilotes de carte HP Fibrechannel Mass Storage créent des ports virtuels avec des pilotes appelés « fcp », « fcpdev », « fcparray » et « fcpmux » afin de contrôler divers aspects du réseau de mémoire de masse Fibre Channel auxquels ils sont rattachés.

Ni SAM ni rad n'affichent explicitement les ports virtuels lorsqu'ils gèrent des questions propres aux ports physiques. Toutefois les deux types de ports sont convenablement neutralisés et réactivés.

Les ports virtuels sont identifiés par ioscan et ils apparaissent dans la zone Peripheral Devices -> Cards de SAM avec le même numéro de logement que les ports physiques correspondants.