Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Mise à niveau manuelle des ONTAP sans interruption via l'interface de ligne de commandes (configurations standard)

Contributeurs
PDF

La mise à niveau automatisée à l'aide de System Manager est la méthode de mise à niveau préférée. Si System Manager ne prend pas en charge votre configuration, vous pouvez effectuer une mise à niveau manuelle sans interruption à l'aide de l'interface de ligne de commandes ONTAP. Pour mettre à niveau un cluster de deux nœuds ou plus à l'aide de la méthode manuelle sans interruption, vous devez lancer une opération de basculement sur chaque nœud d'une paire haute disponibilité, mettre à jour le nœud « en échec », lancer un rétablissement, puis répéter le processus pour chaque paire haute disponibilité du cluster.

Avant de commencer

Vous devez avoir satisfait la mise à niveau "préparation" conditions requises.

Mise à jour du premier nœud d'une paire HA

Vous pouvez mettre à jour le premier nœud d'une paire haute disponibilité en initiant un basculement par le partenaire du nœud. Le partenaire service des données du nœud pendant la mise à niveau du premier nœud.

Si vous effectuez une mise à niveau majeure, le premier nœud à mettre à niveau doit être le même nœud sur lequel vous avez configuré les LIFs de données pour la connectivité externe et installé la première image ONTAP.

Après la mise à niveau du premier nœud, il est conseillé de mettre à niveau le nœud partenaire aussi rapidement que possible. Ne laissez pas les deux nœuds dans un "version mixte" indiquer plus longtemps que nécessaire.

Étapes

  1. Mettre à jour le premier nœud du cluster en invoquant un message AutoSupport :

    autosupport invoke -node * -type all -message "Starting_NDU"

    Cette notification AutoSupport inclut un enregistrement de l'état du système juste avant la mise à jour. Il enregistre des informations de dépannage utiles en cas de problème avec le processus de mise à jour.

    Si le cluster n'est pas configuré pour envoyer des messages AutoSupport, une copie de la notification est enregistrée localement.

  2. Définissez le niveau de privilège sur avancé, en entrant y lorsque vous êtes invité à continuer :

    set -privilege advanced

    L'invite avancée (*>) s'affiche.

  3. Définissez la nouvelle image du logiciel ONTAP comme image par défaut :

    system image modify {-node nodenameA -iscurrent false} -isdefault true

    La commande system image modify utilise une requête étendue pour remplacer la nouvelle image logicielle ONTAP (qui est installée comme image alternative) par l'image par défaut du nœud.

  4. Surveiller la progression de la mise à jour :

    system node upgrade-revert show

  5. Vérifiez que la nouvelle image du logiciel ONTAP est définie comme image par défaut :

    system image show

    Dans l'exemple suivant, image2 est la nouvelle version de ONTAP et est définie en tant qu'image par défaut sur le noeud 0 :

    cluster1::*> system image show
                 Is      Is                Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- --------- -------------------
node0
         image1  false   true    X.X.X     MM/DD/YYYY TIME
         image2  true    false   Y.Y.Y     MM/DD/YYYY TIME
node1
         image1  true    true    X.X.X     MM/DD/YYYY TIME
         image2  false   false   Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

  6. Désactiver le rétablissement automatique sur le nœud partenaire s'il est activé :

    storage failover modify -node nodenameB -auto-giveback false

    Si le cluster est un cluster à deux nœuds, un message s'affiche vous informant que la désactivation du rétablissement automatique empêche la mise en ligne des services du cluster de gestion en cas de défaillance alternée. Entrez y pour continuer.

  7. Vérifier que le rétablissement automatique est désactivé pour le partenaire du nœud :

    storage failover show -node nodenameB -fields auto-giveback
    cluster1::> storage failover show -node node1 -fields auto-giveback
node     auto-giveback
-------- -------------
node1    false
1 entry was displayed.

  8. Exécutez la commande suivante deux fois pour déterminer si le nœud à mettre à jour diffuse actuellement des clients

    system node run -node nodenameA -command uptime

    La commande UpTime affiche le nombre total d'opérations effectuées par le nœud pour les clients NFS, SMB, FC et iSCSI depuis le dernier démarrage du nœud. Pour chaque protocole, vous devez exécuter la commande deux fois afin de déterminer si le nombre d'opérations augmente. S'ils augmentent, le nœud diffuse actuellement des clients pour ce protocole. Si ce n'est pas le cas, le nœud ne diffuse actuellement pas les clients pour ce protocole.

    Remarque Vous devez noter chaque protocole dont les opérations client augmentent, de sorte qu'après la mise à jour du nœud, vous pouvez vérifier que le trafic client a repris.

    L'exemple suivant montre un nœud avec des opérations NFS, SMB, FC et iSCSI. Toutefois, le nœud dessert actuellement uniquement les clients NFS et iSCSI.

    cluster1::> system node run -node node0 -command uptime
  2:58pm up  7 days, 19:16 800000260 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32810 iSCSI ops

cluster1::> system node run -node node0 -command uptime
  2:58pm up  7 days, 19:17 800001573 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32815 iSCSI ops

  9. Migrer tous les LIFs de données loin du nœud :

    network interface migrate-all -node nodenameA

  10. Vérifiez toutes les LIFs que vous avez migrées :

    network interface show

    Pour plus d'informations sur les paramètres que vous pouvez utiliser pour vérifier l'état des LIF, reportez-vous à la page man de l'interface réseau.

    L'exemple suivant montre que les LIF de données du nœud 0 ont migré correctement. Pour chaque LIF, les champs inclus dans cet exemple vous permettent de vérifier le nœud et le port d'accueil de la LIF, le nœud et le port actuels vers lesquels la LIF a migré, ainsi que le statut opérationnel et administratif de la LIF.

    cluster1::> network interface show -data-protocol nfs|cifs -role data -home-node node0 -fields home-node,curr-node,curr-port,home-port,status-admin,status-oper
vserver lif     home-node home-port curr-node curr-port status-oper status-admin
------- ------- --------- --------- --------- --------- ----------- ------------
vs0     data001 node0     e0a       node1     e0a       up          up
vs0     data002 node0     e0b       node1     e0b       up          up
vs0     data003 node0     e0b       node1     e0b       up          up
vs0     data004 node0     e0a       node1     e0a       up          up
4 entries were displayed.

  11. Lancement d'un basculement :

    storage failover takeover -ofnode nodenameA

    Ne spécifiez pas le paramètre -option immédiate, car un basculement normal est nécessaire pour le nœud en cours de basculement pour démarrer sur la nouvelle image logicielle. Si vous n'avez pas migré manuellement les LIF en dehors du nœud, elles migrent automatiquement vers le partenaire de haute disponibilité du nœud afin d'assurer l'absence d'interruption du service.

    Le premier nœud démarre jusqu'à l'état d'attente de rétablissement.

    Remarque Si AutoSupport est activé, un message AutoSupport est envoyé, indiquant que le nœud n'a pas le quorum du cluster. Vous pouvez ignorer cette notification et poursuivre la mise à jour.

  12. Vérifiez que le basculement est réussi :

    storage failover show

    Des messages d'erreur indiquant des problèmes de non-concordance de version et de format de boîte aux lettres peuvent s'afficher. Ce comportement est attendu, il s'agit d'un état temporaire lors d'une mise à niveau sans interruption majeure et ne présente aucun danger.

    L'exemple suivant montre que le basculement a réussi. Le nœud node0 est en attente de rétablissement et son partenaire est à l'état en attente.

    cluster1::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------------
node0          node1          -        Waiting for giveback (HA mailboxes)
node1          node0          false    In takeover
2 entries were displayed.

  13. Attendre au moins huit minutes pour que les conditions suivantes prennent effet :

    • Les chemins d'accès multiples du client (si déployés) sont stabilisés.

    • Les clients sont récupérés à partir de la pause lors d'une opération d'E/S qui se produit pendant le basculement.

      Le temps de restauration est spécifique au client et peut prendre plus de huit minutes, selon les caractéristiques des applications client.

  14. Renvoyer les agrégats vers le premier nœud :

    storage failover giveback -ofnode nodenameA

    Le rétablissement renvoie tout d'abord l'agrégat racine sur le nœud partenaire, puis, une fois le démarrage terminé, renvoie les agrégats non-root et toutes les LIF définies pour rétablir automatiquement ces agrégats. Le nœud qui vient d'être démarré commence à transmettre les données aux clients de chaque agrégat dès que l'agrégat est renvoyé.

  15. Vérifier que tous les agrégats ont été renvoyés :

    storage failover show-giveback

    Si le champ État de rétablissement indique qu'il n'y a pas d'agrégats à renvoyer, tous les agrégats ont été renvoyés. Si le retour est vetoté, la commande affiche la progression du rétablissement et le sous-système qui a mis son veto au rétablissement.

  16. Si un agrégat n'a pas été renvoyé, effectuez les opérations suivantes :

    1. Examinez la solution de contournement du veto pour déterminer si vous voulez répondre à la condition "verto" ou remplacer le veto.

    2. Si nécessaire, répondez à la condition "verto" décrite dans le message d'erreur, en veillant à ce que toutes les opérations identifiées soient arrêtées de manière normale.

    3. Exécutez à nouveau la commande Storage failover giveback.

      Si vous décidez de remplacer la condition "verto", définissez le paramètre -override-vetos sur true.

  17. Attendre au moins huit minutes pour que les conditions suivantes prennent effet :

    • Les chemins d'accès multiples du client (si déployés) sont stabilisés.

    • Les clients sont récupérés à partir de la pause dans une opération d'E/S qui se produit au cours du rétablissement.

      Le temps de restauration est spécifique au client et peut prendre plus de huit minutes, selon les caractéristiques des applications client.

  18. Vérifiez que la mise à jour a bien été effectuée pour le nœud :

    1. Accéder au niveau de privilège avancé :

      set -privilege advanced

    2. Vérifiez que la mise à jour de l'état est terminée pour le nœud :

      system node upgrade-revert show -node nodenameA

      L'état doit être indiqué comme étant terminé.

    Si le statut n'est pas terminé, contactez le support technique.

    1. Retour au niveau de privilège admin :

      set -privilege admin

  19. Vérifier que les ports du nœud sont bien :

    network port show -node nodenameA

    Vous devez exécuter cette commande sur un nœud mis à niveau vers la version supérieure de ONTAP 9.

    L'exemple suivant indique que tous les ports du nœud sont up :

    cluster1::> network port show -node node0
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
node0
       e0M       Default      -                up       1500  auto/100
       e0a       Default      -                up       1500  auto/1000
       e0b       Default      -                up       1500  auto/1000
       e1a       Cluster      Cluster          up       9000  auto/10000
       e1b       Cluster      Cluster          up       9000  auto/10000
5 entries were displayed.

  20. Rerestaurez les LIF sur le nœud :

    network interface revert *

    Cette commande renvoie les LIFs qui ont été migrées à l'écart du nœud.

    cluster1::> network interface revert *
8 entries were acted on.

  21. Vérifiez que les LIF de données du nœud sont bien rétablies sur le nœud et qu'elles utilisent :

    network interface show

    L'exemple suivant montre que toutes les LIF de données hébergées par le nœud ont été rétablies au niveau du nœud et que leur état opérationnel est actif :

    cluster1::> network interface show
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
vs0
            data001      up/up    192.0.2.120/24     node0         e0a     true
            data002      up/up    192.0.2.121/24     node0         e0b     true
            data003      up/up    192.0.2.122/24     node0         e0b     true
            data004      up/up    192.0.2.123/24     node0         e0a     true
4 entries were displayed.

  22. Si vous avez auparavant déterminé que ce nœud diffuse les clients, vérifiez que le nœud fournit un service à chaque protocole qu'il était auparavant en service :

    system node run -node nodenameA -command uptime

    L'opération compte à zéro pendant la mise à jour.

    L'exemple suivant montre que le nœud mis à jour a repris le service de ses clients NFS et iSCSI :

    cluster1::> system node run -node node0 -command uptime
  3:15pm up  0 days, 0:16 129 NFS ops, 0 CIFS ops, 0 HTTP ops, 0 FCP ops, 2 iSCSI ops

  23. Réactiver le rétablissement automatique sur le nœud partenaire s'il a été précédemment désactivé :

    storage failover modify -node nodenameB -auto-giveback true

Vous devez continuer à mettre à jour le partenaire HA du nœud aussi rapidement que possible. Si vous devez interrompre le processus de mise à jour pour une raison quelconque, les deux nœuds de la paire HA doivent exécuter la même version de ONTAP.

Mise à jour du nœud partenaire dans une paire HA

Après la mise à jour du premier nœud d'une paire haute disponibilité, vous mettez à jour son partenaire en lançant un basculement sur incident. Le premier nœud transmet les données du partenaire pendant la mise à niveau du nœud partenaire.

  1. Définissez le niveau de privilège sur avancé, en entrant y lorsque vous êtes invité à continuer :

    set -privilege advanced

    L'invite avancée (*>) s'affiche.

  2. Définissez la nouvelle image du logiciel ONTAP comme image par défaut :

    system image modify {-node nodenameB -iscurrent false} -isdefault true

    La commande system image modify utilise une requête étendue pour modifier la nouvelle image logicielle ONTAP (qui est installée comme image alternative) comme image par défaut du nœud.

  3. Surveiller la progression de la mise à jour :

    system node upgrade-revert show

  4. Vérifiez que la nouvelle image du logiciel ONTAP est définie comme image par défaut :

    system image show

    Dans l'exemple suivant : image2 Est la nouvelle version d'ONTAP, définie en tant qu'image par défaut sur le nœud :

    cluster1::*> system image show
                 Is      Is                Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- --------- -------------------
node0
         image1  false   false   X.X.X     MM/DD/YYYY TIME
         image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
node1
         image1  false   true    X.X.X     MM/DD/YYYY TIME
         image2  true    false   Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

  5. Désactiver le rétablissement automatique sur le nœud partenaire s'il est activé :

    storage failover modify -node nodenameA -auto-giveback false

    Si le cluster est un cluster à deux nœuds, un message s'affiche vous informant que la désactivation du rétablissement automatique empêche la mise en ligne des services du cluster de gestion en cas de défaillance alternée. Entrez y pour continuer.

  6. Vérifier que le rétablissement automatique est désactivé pour le nœud partenaire :

    storage failover show -node nodenameA -fields auto-giveback
    cluster1::> storage failover show -node node0 -fields auto-giveback
node     auto-giveback
-------- -------------
node0    false
1 entry was displayed.

  7. Exécutez la commande suivante deux fois pour déterminer si le nœud à mettre à jour diffuse actuellement des clients :

    system node run -node nodenameB -command uptime

    La commande UpTime affiche le nombre total d'opérations effectuées par le nœud pour les clients NFS, SMB, FC et iSCSI depuis le dernier démarrage du nœud. Pour chaque protocole, vous devez exécuter la commande deux fois afin de déterminer si le nombre d'opérations augmente. S'ils augmentent, le nœud diffuse actuellement des clients pour ce protocole. Si ce n'est pas le cas, le nœud ne diffuse actuellement pas les clients pour ce protocole.

    Remarque Vous devez noter chaque protocole dont les opérations client augmentent, de sorte qu'après la mise à jour du nœud, vous pouvez vérifier que le trafic client a repris.

    L'exemple suivant montre un nœud avec des opérations NFS, SMB, FC et iSCSI. Toutefois, le nœud dessert actuellement uniquement les clients NFS et iSCSI.

    cluster1::> system node run -node node1 -command uptime
  2:58pm up  7 days, 19:16 800000260 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32810 iSCSI ops

cluster1::> system node run -node node1 -command uptime
  2:58pm up  7 days, 19:17 800001573 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32815 iSCSI ops

  8. Migrer tous les LIFs de données loin du nœud :

    network interface migrate-all -node nodenameB

  9. Vérifiez l'état des LIFs que vous avez migrées :

    network interface show

    Pour plus d'informations sur les paramètres que vous pouvez utiliser pour vérifier l'état des LIF, reportez-vous à la page man de l'interface réseau.

    L'exemple suivant montre que les LIF de données du nœud 1 ont migré correctement. Pour chaque LIF, les champs inclus dans cet exemple vous permettent de vérifier le nœud et le port d'accueil de la LIF, le nœud et le port actuels vers lesquels la LIF a migré, ainsi que le statut opérationnel et administratif de la LIF.

    cluster1::> network interface show -data-protocol nfs|cifs -role data -home-node node1 -fields home-node,curr-node,curr-port,home-port,status-admin,status-oper
vserver lif     home-node home-port curr-node curr-port status-oper status-admin
------- ------- --------- --------- --------- --------- ----------- ------------
vs0     data001 node1     e0a       node0     e0a       up          up
vs0     data002 node1     e0b       node0     e0b       up          up
vs0     data003 node1     e0b       node0     e0b       up          up
vs0     data004 node1     e0a       node0     e0a       up          up
4 entries were displayed.

  10. Lancement d'un basculement :

    storage failover takeover -ofnode nodenameB -option allow-version-mismatch

    Ne spécifiez pas le paramètre -option immédiate, car un basculement normal est nécessaire pour le nœud en cours de basculement pour démarrer sur la nouvelle image logicielle. Si vous n'avez pas migré manuellement les LIF en dehors du nœud, elles migrent automatiquement vers le partenaire de haute disponibilité du nœud, afin qu'il n'y ait aucune interruption de service.

    Un avertissement s'affiche. Vous devez entrer y pour continuer.

    Le nœud pris au relais est démarré jusqu'à l'état en attente de rétablissement.

    Remarque Si AutoSupport est activé, un message AutoSupport est envoyé, indiquant que le nœud n'a pas le quorum du cluster. Vous pouvez ignorer cette notification et poursuivre la mise à jour.

  11. Vérifier que le basculement a abouti :

    storage failover show

    L'exemple suivant montre que le basculement a réussi. Le nœud node1 est en attente de rétablissement de l'état, et son partenaire est à l'état en basculement.

    cluster1::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------------
node0          node1          -        In takeover
node1          node0          false    Waiting for giveback (HA mailboxes)
2 entries were displayed.

  12. Attendre au moins huit minutes pour que les conditions suivantes prennent effet :

    + Les chemins d'accès multiples du client (si déployés) sont stabilisés. Les clients sont récupérés à partir de la pause des E/S qui a lieu lors du basculement.

    + Le temps de restauration est spécifique au client et peut prendre plus de huit minutes, selon les caractéristiques des applications client.

  13. Renvoyez les agrégats au nœud partenaire :

    storage failover giveback -ofnode nodenameB

    L'opération de rétablissement renvoie tout d'abord l'agrégat racine sur le nœud partenaire, puis, une fois le démarrage terminé, renvoie les agrégats non-root et les LIF définies pour rétablir automatiquement ces agrégats. Le nœud qui vient d'être démarré commence à transmettre les données aux clients de chaque agrégat dès que l'agrégat est renvoyé.

  14. Vérifier que tous les agrégats sont renvoyés :

    storage failover show-giveback

    Si le champ État de rétablissement indique qu'il n'y a pas d'agrégats à renvoyer, tous les agrégats sont renvoyés. Si le retour est vetoté, la commande affiche la progression du rétablissement et le sous-système qui a opposé son veto à l'opération de rétablissement.

  15. Si un agrégat n'est pas renvoyé, effectuez les opérations suivantes :

    1. Examinez la solution de contournement du veto pour déterminer si vous voulez répondre à la condition "verto" ou remplacer le veto.

    2. Si nécessaire, répondez à la condition "verto" décrite dans le message d'erreur, en veillant à ce que toutes les opérations identifiées soient arrêtées de manière normale.

    3. Exécutez à nouveau la commande Storage failover giveback.

      Si vous décidez de remplacer la condition "verto", définissez le paramètre -override-vetos sur true.

  16. Attendre au moins huit minutes pour que les conditions suivantes prennent effet :

    • Les chemins d'accès multiples du client (si déployés) sont stabilisés.

    • Les clients sont récupérés à partir de la pause dans une opération d'E/S qui se produit au cours du rétablissement.

      Le temps de restauration est spécifique au client et peut prendre plus de huit minutes, selon les caractéristiques des applications client.

  17. Vérifiez que la mise à jour a bien été effectuée pour le nœud :

    1. Accéder au niveau de privilège avancé :

      set -privilege advanced

    2. Vérifiez que la mise à jour de l'état est terminée pour le nœud :

      system node upgrade-revert show -node nodenameB

      L'état doit être indiqué comme étant terminé.

    Si l'état n'est pas complet, exécutez le dans le nœud system node upgrade-revert upgrade commande. Si la commande ne termine pas la mise à jour, contactez le support technique.

    1. Retour au niveau de privilège admin :

      set -privilege admin

  18. Vérifier que les ports du nœud sont bien :

    network port show -node nodenameB

    Vous devez exécuter cette commande sur un nœud mis à niveau vers ONTAP 9.4.

    L'exemple suivant montre que tous les ports de données du nœud up :

    cluster1::> network port show -node node1
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
node1
       e0M       Default      -                up       1500  auto/100
       e0a       Default      -                up       1500  auto/1000
       e0b       Default      -                up       1500  auto/1000
       e1a       Cluster      Cluster          up       9000  auto/10000
       e1b       Cluster      Cluster          up       9000  auto/10000
5 entries were displayed.

  19. Rerestaurez les LIF sur le nœud :

    network interface revert *

    Cette commande renvoie les LIFs qui ont été migrées à l'écart du nœud.

    cluster1::> network interface revert *
8 entries were acted on.

  20. Vérifiez que les LIF de données du nœud sont bien rétablies sur le nœud et qu'elles utilisent :

    network interface show

    L'exemple suivant montre que toutes les LIFs de données hébergées par le nœud sont rétablies au niveau du nœud et que leur état opérationnel est actif :

    cluster1::> network interface show
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
vs0
            data001      up/up    192.0.2.120/24     node1         e0a     true
            data002      up/up    192.0.2.121/24     node1         e0b     true
            data003      up/up    192.0.2.122/24     node1         e0b     true
            data004      up/up    192.0.2.123/24     node1         e0a     true
4 entries were displayed.

  21. Si vous avez auparavant déterminé que ce nœud diffuse les clients, vérifiez que le nœud fournit un service à chaque protocole qu'il était auparavant en service :

    system node run -node nodenameB -command uptime

    L'opération compte à zéro pendant la mise à jour.

    L'exemple suivant montre que le nœud mis à jour a repris le service de ses clients NFS et iSCSI :

    cluster1::> system node run -node node1 -command uptime
  3:15pm up  0 days, 0:16 129 NFS ops, 0 CIFS ops, 0 HTTP ops, 0 FCP ops, 2 iSCSI ops

  22. Si ce nœud était le dernier nœud du cluster à mettre à jour, déclenchez une notification AutoSupport :

    autosupport invoke -node * -type all -message "Finishing_NDU"

    Cette notification AutoSupport inclut un enregistrement de l'état du système juste avant la mise à jour. Il enregistre des informations de dépannage utiles en cas de problème avec le processus de mise à jour.

    Si le cluster n'est pas configuré pour envoyer des messages AutoSupport, une copie de la notification est enregistrée localement.

  23. Vérifiez que le nouveau logiciel ONTAP s'exécute sur les deux nœuds de la paire HA :

    set -privilege advanced
    system node image show

    Dans l'exemple suivant, image2 est la version mise à jour de ONTAP et il s'agit de la version par défaut sur les deux nœuds :

    cluster1::*> system node image show
                 Is      Is                Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- --------- -------------------
node0
         image1  false   false   X.X.X     MM/DD/YYYY TIME
         image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
node1
         image1  false   false   X.X.X     MM/DD/YYYY TIME
         image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

  24. Réactiver le rétablissement automatique sur le nœud partenaire s'il a été précédemment désactivé :

    storage failover modify -node nodenameA -auto-giveback true

  25. Vérifiez que le cluster est au quorum et que les services sont en cours d'exécution à l'aide du cluster show et cluster ring show commandes (niveau de privilège avancé).

    Vous devez effectuer cette étape avant de mettre à niveau les paires haute disponibilité supplémentaires.

  26. Retour au niveau de privilège admin :

    set -privilege admin

  27. Mettez à niveau les paires haute disponibilité supplémentaires.