Mise à niveau d'un cluster

Dans un système en cluster, vous pouvez effectuer une mise à niveau non simultanée, ce qui permet d'éviter toute indisponibilité pendant l'exécution de la mise à niveau. Cette section suppose que vous êtes familiarisé avec le modèle de clustering Oracle ZFS Storage Appliance : si vous n'êtes pas familiarisé avec les concepts et la terminologie du clustering, lisez d'abord le Chapitre 10, Configuration de cluster du manuel Guide d’administration des systèmes Oracle ZFS Storage Appliance . Dans la procédure de mise à niveau non simultanée décrite ici, les deux contrôleurs sont appelés A et B, A étant le premier contrôleur mis à jour et B le second contrôleur mis à jour. Lors des mises à niveau non simultanées, une règle de bonne pratique essentielle est que chaque contrôleur doit être mis à niveau à un moment où il ne fournit pas de services aux clients. La procédure décrite ici respecte cette règle. En outre, toutes les règles de bonne pratique concernant les mises niveau décrites plus haut s'appliquent également aux mises à niveau non simultanées.

Réalisation d'une mise à niveau de cluster

Important : N'effectuez pas d'opération de reprise lorsqu'une mise à niveau est en cours.

1. Utilisez la CLI ou la BUI pour transférer l'image logicielle de la mise à jour vers les deux contrôleurs de stockage.
2. Sélectionnez le contrôleur à mettre à jour en premier. Si un contrôleur n'a pas de pools de stockage, commencez par mettre ce contrôleur. Dans les étapes suivantes, le contrôleur A est mis à jour en premier, si bien que les clients qui utilisent le(s) pool(s) de stockage du contrôleur A subiront donc les premiers un retard de disponibilité lié à la reprise.
3. Connectez-vous au contrôleur A et utilisez la commande maintenance system reboot de la CLI ou l'icône de la BUI dans le masthead, et sélectionnez l'option de redémarrage pour réinitialiser le contrôleur A. Le contrôleur B récupère les ressources du contrôleur A.
4. Connectez-vous au contrôleur A et utilisez la CLI ou la BUI pour appliquer la mise à jour logicielle au contrôleur A. A la fin de la mise à niveau, le contrôleur A se réinitialise à nouveau et exécute la nouvelle version du logiciel.

   ---

   Remarque -  N'effectuez pas de mise à niveau sur un contrôleur lorsqu'il est en service.

   ---

5. Connectez vous au contrôleur B et utilisez la commande maintenance system reboot de la CLI ou l'icône de la BUI dans le masthead, et sélectionnez l'option de redémarrage pour réinitialiser le contrôleur B. Le contrôleur A récupère toutes les ressources et fournit le service en utilisant la nouvelle version du logiciel.
6. Validez la nouvelle version du logiciel sur le contrôleur A et assurez-vous que tous les services fonctionnent correctement sur les systèmes client.
7. Si un problème sérieux survient, restaurez le contrôleur A. Le contrôleur A se réinitialise et le contrôleur B prend le relais et exécute la version précédente du logiciel. Lorsque le contrôleur A récupère, il exécute également la version précédente du logiciel.
8. Si aucun problème sérieux ne survient, connectez-vous au contrôleur B et utilisez la CLI ou la BUI pour appliquer la mise à jour logicielle au contrôleur B. Le contrôleur B se réinitialise et exécute la nouvelle version du logiciel.
9. Vérifiez que toutes les mises à jour de microprogramme sont terminées.

   ---

   Remarque -  Les mises à jour de microprogramme de contrôleur ne peuvent avoir lieu si les contrôleurs exécutent des versions différentes du logiciel système.

   ---

10. Pour revenir à un fonctionnement normal et rendre les ressources à leurs contrôleurs assignés respectifs, connectez-vous au contrôleur A et utilisez la CLI ou la BUI pour effectuer un rétablissement sur le contrôleur A. Pour des informations sur l'opération de rétablissement, voir la section Reprise et rétablissement du cluster du manuel Guide d’administration des systèmes Oracle ZFS Storage Appliance .

Etats du cluster pendant la mise à niveau

Le tableau suivant décrit l'état du cluster après chaque étape de la procédure précédente.

Le fait d'accéder à la BUI ou de se connecter à la CLI lorsque des contrôleurs exécutent des versions logicielles différentes affiche un avertissement indiquant que les modifications de configuration ne seront pas propagées. Vous pouvez configurer l'appareil de manière à générer des alertes lorsque les contrôleurs du cluster exécutent des versions logicielles différentes (événements "Cluster rejoin mismatch" et "Cluster rejoin mismatch on peer").

Si vous modifiez le mot de passe root pendant une mise à niveau puis effectuez une restauration du cluster, les noeuds ne peuvent pas s'associer à nouveau après la restauration.