Go to main content
Manuel d'entretien client des systèmes Oracle® ZFS Storage Appliance

Quitter la vue de l'impression

Mis à jour : Décembre 2016
 
 

Utilisation des mises à jour de microprogrammes

Après l'application d'une mise à jour logicielle, tout matériel pour lequel une version de microprogramme plus récente est comprise dans la mise à jour est lui aussi mis à niveau. Avant la période de mise à niveau, il est recommandé d'exécuter un nettoyage comme indiqué dans la section Nettoyage d’un pool de stockage (BUI) du manuel Guide d’administration des systèmes Oracle ZFS Storage Appliance, version OS8.6.x.

Il existe plusieurs types de périphériques pour lesquels des mises à jour de microprogrammes peuvent être proposées, chacun présentant des caractéristiques propres. Les disques, les boîtiers de stockage et certains périphériques SAS internes sont mis à niveau en arrière-plan. Lors de cette mise à niveau, la progression de la mise à jour des microprogrammes s'affiche dans le panneau de gauche de la vue Maintenance > Système de la BUI ou dans le contexte maintenance system updates de la CLI. Ces mises à jour de microprogrammes sont presque toujours liées au matériel, mais quelques mises à jour non appliquées peuvent apparaître brièvement lors de l'application de certaines mises à jour différées à des composants autres que matériels.

A partir de la version 2010Q3.4, lorsqu'il existe des mises à jour non appliquées, une icône d'information ou d'avertissement s'affiche en regard du nombre de mises à jour restantes. Lorsque vous cliquez sur cette icône, la boîte de dialogue Mise à jour du microprogramme affiche la liste des mises à jour actuelles restantes. La version actuelle du composant, l'heure de la dernière tentative de mise à jour et la raison de l'échec de celle-ci s'affichent également pour chaque mise à jour.

Chaque mise à jour non appliquée peut être dans l'un des trois états suivants : Pending (En attente), In Progress (En cours) ou Failed (Echec). Une mise à jour commence par l'état En attente et un essai est régulièrement retenté ; à ce moment, elle passe à l'état En cours. En cas d'échec de mise à niveau en raison de conditions transitoires, la mise à jour revient à l'état En attente, sinon, elle passe à l'état Echec.

En général, seules les situations suivantes dénotent un problème :

  • Des mises à jour présentent l'état Failed.

  • Des mises à jour conservent l'état Pending (ou alternent entre les états Pending et In Progress) pendant une période prolongée (plus d'une demi-heure) sans que le nombre de mises à jour restantes ne diminue.

La condition suivante n'indique pas un problème :

  • Plusieurs châssis sont mis à niveau ; la mise à jour progresse (le nombre de mises à jour restantes diminue), mais certains châssis présentent brièvement l'état Pending, avec affichage d'un message de statut indiquant que certains disques ne possèdent qu'un chemin d'accès. Cette situation est également normale car la mise à niveau d'un châssis peut éventuellement s'accompagner d'une réinitialisation de l'un de ses expandeurs. Dans ce cas, le nombre de chemins d'accès de certains disques peut temporairement être réduit à un chemin ; les mises à jour de l'autre châssis sont alors suspendues jusqu'à ce que la poursuite de la mise à niveau soit considérée comme sûre.

Notez que la boîte de dialogue Mises à jour du microprogramme ne s'actualise pas automatiquement ; vous devez donc la fermer et la rouvrir pour actualiser l'affichage.

L'application de mises à jour matérielles se fait toujours dans des conditions de parfaite sécurité. En d'autres termes, il peut arriver que le système présente un état rendant impossible l'application de mises à jour matérielles. C'est le cas tout particulièrement pour les configurations en cluster. Lors d'opérations de reprise et de rétablissement, toutes les mises à jour de microprogrammes en cours sont terminées, mais les mises à jour de microprogrammes en attente sont suspendues jusqu'à l'achèvement de la reprise ou du rétablissement. Une fois la reprise ou le rétablissement terminé, le système réévalue les restrictions décrites ci-dessous sur la base du nouvel état du cluster, et, si possible, les mises à jour de microprogrammes reprennent.


Caution

Mise en garde  -  Sauf en cas de nécessité absolue, il faut éviter de réaliser des opérations de reprise et de rétablissement pendant la mise à jour de microprogrammes.


La procédure de mise à jour non simultanée présentée ci-après satisfait toutes les règles de bonne pratique évoquées précédemment et tient compte des restrictions applicables aux différentes classes de périphériques décrites plus loin. Nous recommandons de toujours suivre cette procédure lors des mises à jour effectuées dans un environnement en cluster. Dans les environnements en cluster et autonomes, les critères évoqués sont également réévalués à chaque réinitialisation ou redémarrage du logiciel système à des fins de diagnostic, ce qui peut entraîner la reprise de mises à jour de microprogrammes précédemment suspendues ou inachevées.

  • Les composants internes du contrôleur de stockage (HBA et périphériques réseau par exemple) autres que les disques ou certains périphériques SAS sont généralement mis à niveau automatiquement lors de l'initialisation. Ces mises à jour ne sont pas visibles et sont terminées lorsque les interfaces de gestion deviennent disponibles.

  • La mise à niveau de microprogrammes de disques ou de périphériques Flash nécessite la mise hors ligne des périphériques pendant la durée du processus. Si la redondance est insuffisante dans le pool de stockage conteneur pour permettre cette opération, la mise à jour du microprogramme ne se termine pas et peut apparaître "bloquée". En revanche, si les pools de stockage sont en état exporté, les disques seront mis à jour normalement. Les disques et périphériques Flash faisant partie d'un pool de stockage actuellement utilisé par le pair de cluster (s'il existe) ne sont pas mis à niveau.

  • La mise à niveau des microprogrammes d'une étagère de disques nécessite que les deux chemins de stockage d'arrière-plan de tous les disques dans tous les boîtiers soient actifs et que le stockage soit configuré sur toutes les étagères à mettre à niveau. Pour les clusters avec au moins un pool actif sur chaque contrôleur, ces restrictions signifient que la mise à jour des microprogrammes de l'étagère de disques peut uniquement être effectuée par un contrôleur qui est dans l'état "owner".

Lors du processus de mise à jour des microprogrammes, le matériel peut apparaître comme étant retiré et inséré, ou comme étant mis hors ligne et en ligne. Tandis que les alertes liées à ces actions ne sont pas affichées, les effets de ces mises à jour sont visibles sous la forme de périphériques manquants ou hors ligne dans l'écran Maintenance > Matériel ou l'écran Configuration > Stockage de l'interface utilisateur. Il n'y a pas lieu de s'inquiéter. Cependant, si un périphérique reste hors ligne ou manquant pendant une période prolongée (quelques minutes ou plus), et ce même après l'actualisation de la vue du matériel, il peut y avoir un problème avec le périphérique. Consultez la vue Maintenance > Problèmes pour repérer les pannes identifiées qui peuvent avoir un rapport avec le problème. En outre, les contrôleurs des étagères de disques peuvent, dans certains cas, rester hors ligne lors de la mise à jour des microprogrammes. Si cela se produit, aucun autre contrôleur n'est mis à niveau tant que le problème n'a pas été résolu. Si un boîtier est répertorié comme ayant un chemin unique pendant un laps de temps prolongé, contrôlez le boîtier physique et vérifiez si les voyants de liaison verts à l'arrière du module SIM ou IOM sont actifs. Si ce n'est pas le cas, retirez et réinsérez le module SIM ou IOM pour rétablir la connexion. Vérifiez que tous les boîtiers sont accessibles via deux chemins.