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 sans interruption d'une configuration MetroCluster à quatre ou huit nœuds via l'interface de ligne de commande ONTAP

Contributeurs
PDF

La mise à niveau manuelle d'une configuration MetroCluster à quatre ou huit nœuds implique de préparer la mise à jour, de mettre à jour les paires DR dans chacun des deux groupes DR simultanément et d'effectuer des tâches post-mise à niveau.

  • Cette tâche s'applique aux configurations suivantes :

    • Configurations FC ou IP MetroCluster à quatre nœuds exécutant ONTAP 9.2 ou une version antérieure

    • Configurations FC à 8 nœuds MetroCluster, quelle que soit la version d'ONTAP utilisée

  • Si vous disposez d'une configuration MetroCluster à deux nœuds, n'utilisez pas cette procédure.

  • Les tâches suivantes font référence à l'ancienne et à la nouvelle version de ONTAP.

    • Lors de la mise à niveau, l'ancienne version est une version précédente de ONTAP, avec un numéro de version inférieur à celui de la nouvelle version de ONTAP.

    • Lors de la restauration, l'ancienne version est une version plus récente de ONTAP, avec un numéro de version plus élevé que la nouvelle version de ONTAP.

  • Cette tâche utilise le flux de travail de haut niveau suivant :

    Processus de décision pour la mise à niveau de la configuration MetroCluster

Différences lors de la mise à jour du logiciel ONTAP sur une configuration MetroCluster à huit ou quatre nœuds

La procédure de mise à niveau du logiciel MetroCluster diffère selon qu'il y a huit ou quatre nœuds dans la configuration MetroCluster.

Une configuration MetroCluster se compose d'un ou deux groupes de reprise sur incident. Chaque groupe de reprise après incident est constitué de deux paires haute disponibilité, une paire haute disponibilité sur chaque cluster MetroCluster. Un MetroCluster à 8 nœuds inclut deux groupes de reprise après incident :

Diagramme de configuration MetroCluster à huit nœuds.

Vous mettez à niveau un groupe de reprise après incident à la fois.

Pour les configurations MetroCluster à quatre nœuds :

  1. Mettre à niveau le groupe de reprise sur incident un :

    1. Mettre à niveau les nœuds_A_1 et node_B_1.

    2. Mettre à niveau node_A_2 et node_B_2.

Pour les configurations à 8 nœuds MetroCluster, vous effectuez deux fois la procédure de mise à niveau du groupe de reprise après incident :

  1. Mettre à niveau le groupe de reprise sur incident un :

    1. Mettre à niveau les nœuds_A_1 et node_B_1.

    2. Mettre à niveau node_A_2 et node_B_2.

  2. Mettre à niveau le DR Groupe deux :

    1. Mettre à niveau les nœuds_A_3 et node_B_3.

    2. Mettre à niveau les nœuds_A_4 et node_B_4.

Préparation de la mise à niveau d'un groupe DR MetroCluster

Avant de mettre à niveau le logiciel ONTAP sur les nœuds, vous devez identifier les relations de DR entre les nœuds, envoyer un message AutoSupport indiquant que vous initiez une mise à niveau et confirmer la version de ONTAP exécutée sur chaque nœud.

Vous devez avoir "téléchargé" et "installé" les images du logiciel.

Cette tâche doit être répétée sur chaque groupe de reprise sur incident. Si la configuration MetroCluster comprend huit nœuds, il y a deux groupes de reprise sur incident. Cette tâche doit donc être répétée sur chaque groupe de reprise sur incident.

Les exemples fournis dans cette tâche utilisent les noms illustrés dans l'illustration suivante pour identifier les clusters et les nœuds :

Diagramme de configuration MetroCluster à huit nœuds.

  1. Identifier les paires de reprise sur incident dans la configuration :

    metrocluster node show -fields dr-partner
     cluster_A::> metrocluster node show -fields dr-partner
   (metrocluster node show)
 dr-group-id cluster     node       dr-partner
 ----------- -------     --------   ----------
 1           cluster_A   node_A_1   node_B_1
 1           cluster_A   node_A_2   node_B_2
 1           cluster_B   node_B_1   node_A_1
 1           cluster_B   node_B_2   node_A_2
 4 entries were displayed.

 cluster_A::>

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

    set -privilege advanced

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

  3. Confirmer la version de ONTAP sur cluster_A :

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

 cluster_A::>

  4. Vérifier la version du cluster_B :

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

 cluster_B::>

  5. Déclencher une notification AutoSupport :

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

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

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

  6. Pour chaque nœud du premier jeu, définissez l'image logicielle ONTAP cible sur l'image par défaut :

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

    Cette commande utilise une requête étendue pour modifier l'image du logiciel cible, qui est installée comme image secondaire, comme image par défaut pour le nœud.

  7. Vérifiez que l'image du logiciel ONTAP cible est définie comme image par défaut sur cluster_A :

    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 chacun des nœuds du premier ensemble :

     cluster_A::*> system image show
                  Is      Is              Install
 Node     Image   Default Current Version Date
 -------- ------- ------- ------- ------- -------------------
 node_A_1
          image1  false   true    X.X.X   MM/DD/YYYY TIME
          image2  true    false   Y.Y.Y   MM/DD/YYYY TIME
 node_A_2
          image1  false   true    X.X.X   MM/DD/YYYY TIME
          image2  true   false   Y.Y.Y   MM/DD/YYYY TIME

 2 entries were displayed.

    1. Vérifiez que l'image du logiciel ONTAP cible est définie comme image par défaut sur cluster_B :

      system image show

      L'exemple suivant montre que la version cible est définie en tant qu'image par défaut sur chacun des nœuds du premier jeu :

     cluster_B::*> system image show
                  Is      Is              Install
 Node     Image   Default Current Version Date
 -------- ------- ------- ------- ------- -------------------
 node_A_1
          image1  false   true    X.X.X   MM/DD/YYYY TIME
          image2  true    false   Y.Y.Y   MM/YY/YYYY TIME
 node_A_2
          image1  false   true    X.X.X   MM/DD/YYYY TIME
          image2  true    false   Y.Y.Y   MM/DD/YYYY TIME

 2 entries were displayed.

  8. Déterminer si les nœuds à mettre à niveau servent actuellement des clients deux fois pour chaque nœud :

    system node run -node target-node -command uptime

    La commande UpTime affiche le nombre total d'opérations que le nœud a effectuées pour les clients NFS, CIFS, 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 à niveau du nœud, vous pouvez vérifier que le trafic client a repris.

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

     cluster_x::> 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

 cluster_x::> 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

Mise à jour de la première paire DR dans un groupe MetroCluster DR

Vous devez effectuer un basculement et un retour des nœuds afin de faire de la nouvelle version d'ONTAP la version actuelle du nœud.

Tous les nœuds doivent exécuter l'ancienne version de ONTAP.

Dans cette tâche, les nœuds_A_1 et node_B_1 sont mis à niveau.

Si vous avez mis à niveau le logiciel ONTAP sur le premier groupe DR et que vous mettez à niveau le deuxième groupe DR dans une configuration MetroCluster à huit nœuds, dans cette tâche, vous mettiez à jour node_A_3 et node_B_3.

  1. Si le logiciel MetroCluster Tiebreaker est activé, désactivez-le.

  2. Pour chaque nœud de la paire HA, désactiver le rétablissement automatique :

    storage failover modify -node target-node -auto-giveback false

    Cette commande doit être répétée pour chaque nœud de la paire HA.

  3. Vérifier que le retour automatique est désactivé :

    storage failover show -fields auto-giveback

    Cet exemple montre que le rétablissement automatique a été désactivé sur les deux nœuds :

     cluster_x::> storage failover show -fields auto-giveback
 node     auto-giveback
 -------- -------------
 node_x_1 false
 node_x_2 false
 2 entries were displayed.

  4. Assurez-vous que les E/S ne dépassent pas ~50 % pour chaque contrôleur et que l'utilisation du CPU ne dépasse pas ~50 % par contrôleur.

  5. Initier un basculement du nœud cible sur cluster_A :

    Ne spécifiez pas le paramètre -option immédiate, car un basculement normal est nécessaire pour les nœuds pris en charge afin de démarrer sur la nouvelle image logicielle.

    1. Reprendre le partenaire de reprise après incident sur cluster_A (node_A_1) :

      storage failover takeover -ofnode node_A_1

      Le nœud démarre à l'état « waiting for giveback ».

      Remarque Si AutoSupport est activé, un message AutoSupport est envoyé pour indiquer que les nœuds sont hors du quorum du cluster. Vous pouvez ignorer cette notification et poursuivre la mise à niveau.

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

      storage failover show

      L'exemple suivant montre que le basculement a réussi. L'état « waiting for giveback » est défini sur node_A_1 et node_A_2 est à l'état « In Takeover ».

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

  6. Reprendre le partenaire de reprise après incident sur le cluster_B (node_B_1) :

    Ne spécifiez pas le paramètre -option immédiate, car un basculement normal est nécessaire pour les nœuds pris en charge afin de démarrer sur la nouvelle image logicielle.

    1. Reprendre le noeud_B_1 :

      storage failover takeover -ofnode node_B_1

      Le nœud démarre à l'état « waiting for giveback ».

      Remarque Si AutoSupport est activé, un message AutoSupport est envoyé pour indiquer que les nœuds sont hors du quorum du cluster. Vous pouvez ignorer cette notification et poursuivre la mise à niveau.

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

      storage failover show

      L'exemple suivant montre que le basculement a réussi. Le nœud_B_1 est dans l'état « waiting for giveback » et le nœud_B_2 est à l'état « In Takeover ».

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

  7. Attendez au moins huit minutes pour vérifier les conditions suivantes :

    • 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.

  8. Renvoyez les agrégats aux nœuds cibles :

    Après la mise à niveau des configurations IP de MetroCluster vers ONTAP 9.5 ou une version ultérieure, les agrégats sont dégradés pendant une courte période avant de resynchroniser et de revenir à un état miroir.

    1. Renvoyer les agrégats au partenaire de reprise après incident sur cluster_A :

      storage failover giveback -ofnode node_A_1

    2. Renvoyer les agrégats au partenaire de reprise après incident sur cluster_B :

      storage failover giveback -ofnode node_B_1

      L'opération de rétablissement renvoie tout d'abord l'agrégat racine sur le nœud, puis, une fois le démarrage du nœud terminé, renvoie les agrégats non-racine.

  9. Vérifiez que tous les agrégats ont été renvoyés en exécutant la commande suivante sur les deux clusters :

    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.

  10. Si un agrégat n'a pas été renvoyé, procédez comme suit :

    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. Saisissez de nouveau la commande Storage failover giveback.

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

  11. Attendez au moins huit minutes pour vérifier les conditions suivantes :

    • 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 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.

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

    set -privilege advanced

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

  13. Vérifier la version du cluster_A :

    system image show

    L'exemple suivant montre que System image2 doit être la version par défaut et la version en cours sur node_A_1 :

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

 cluster_A::>

  14. Vérifier la version du cluster_B :

    system image show

    L'exemple suivant montre que System image2 (ONTAP 9.0.0) est la version par défaut et la version actuelle du noeud_A_1 :

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

 cluster_A::>

Mise à jour de la seconde paire DR dans un groupe MetroCluster DR

Vous devez effectuer un basculement et un retour du nœud afin de faire de la nouvelle version d'ONTAP la version actuelle du nœud.

Vous devez avoir mis à niveau la première paire DR (node_A_1 et node_B_1).

Dans cette tâche, les nœuds_A_2 et node_B_2 sont mis à niveau.

Si vous avez mis à niveau le logiciel ONTAP sur le premier groupe DR et que vous mettez à jour le deuxième groupe DR dans une configuration MetroCluster à huit nœuds, dans cette tâche, vous mettez à jour node_A_4 et node_B_4.

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

    network interface migrate-all -node nodenameA

  2. Initier un basculement du nœud cible sur cluster_A :

    Ne spécifiez pas le paramètre -option immédiate, car un basculement normal est nécessaire pour les nœuds pris en charge afin de démarrer sur la nouvelle image logicielle.

    1. Reprendre le partenaire de reprise après incident sur cluster_A :

      storage failover takeover -ofnode node_A_2 -option allow-version-mismatch
      Remarque Le allow-version-mismatch Aucune option n'est requise pour les mises à niveau de ONTAP 9.0 vers ONTAP 9.1 ou pour les mises à niveau de correctifs.

      Le nœud démarre à l'état « waiting for giveback ».

      Si AutoSupport est activé, un message AutoSupport est envoyé pour indiquer que les nœuds sont hors du quorum du cluster. Vous pouvez ignorer cette notification et poursuivre la mise à niveau.

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

      storage failover show

      L'exemple suivant montre que le basculement a réussi. L'état « waiting for giveback » est défini sur node_A_2 et node_A_1 est à l'état « In Takeover ».

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

  3. Initier un basculement du nœud cible sur cluster_B :

    Ne spécifiez pas le paramètre -option immédiate, car un basculement normal est nécessaire pour les nœuds pris en charge afin de démarrer sur la nouvelle image logicielle.

    1. Reprendre le partenaire de reprise sur incident sur cluster_B (node_B_2) :

      Si vous effectuez une mise à niveau depuis…​ Entrez cette commande…​

      ONTAP 9.2 ou ONTAP 9.1

      		 
      storage failover takeover -ofnode node_B_2

      ONTAP 9.0 ou Data ONTAP 8.3.x

      		 
      storage failover takeover -ofnode node_B_2 -option allow-version-mismatch
      Remarque Le allow-version-mismatch Aucune option n'est requise pour les mises à niveau de ONTAP 9.0 vers ONTAP 9.1 ou pour les mises à niveau de correctifs.

      Le nœud démarre à l'état « waiting for giveback ».

      Remarque Si AutoSupport est activé, un message AutoSupport est envoyé, indiquant que les nœuds ne disposent pas du quorum du cluster. Vous pouvez ignorer cette notification en toute sécurité et poursuivre la mise à niveau.

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

      storage failover show

      L'exemple suivant montre que le basculement a réussi. L'état « waiting for giveback » est défini sur node_B_2 et le nœud_B_1 est à l'état « In Takeover ».

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

  4. Attendez au moins huit minutes pour vérifier les conditions suivantes :

    • 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.

  5. Renvoyez les agrégats aux nœuds cibles :

    Après la mise à niveau des configurations IP de MetroCluster vers ONTAP 9.5, les agrégats seront sur une courte période avant de resynchroniser et de rétablir l'état miroir.

    1. Renvoyer les agrégats au partenaire de reprise après incident sur cluster_A :

      storage failover giveback -ofnode node_A_2

    2. Renvoyer les agrégats au partenaire de reprise après incident sur cluster_B :

      storage failover giveback -ofnode node_B_2

      L'opération de rétablissement renvoie tout d'abord l'agrégat racine sur le nœud, puis, une fois le démarrage du nœud terminé, renvoie les agrégats non-racine.

  6. Vérifiez que tous les agrégats ont été renvoyés en exécutant la commande suivante sur les deux clusters :

    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.

  7. Si un agrégat n'a pas été renvoyé, procédez comme suit :

    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. Saisissez de nouveau la commande Storage failover giveback.

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

  8. Attendez au moins huit minutes pour vérifier les conditions suivantes :

    • 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 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.

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

    set -privilege advanced

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

  10. Vérifier la version du cluster_A :

    system image show

    L'exemple suivant montre que l'image système 2 (image ONTAP cible) est la version par défaut et la version actuelle du noeud_A_2 :

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

cluster_A::>

  11. Vérifier la version du cluster_B :

    system image show

    L'exemple suivant montre que l'image système 2 (image ONTAP cible) est la version par défaut et la version actuelle du noeud_B_2 :

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

cluster_A::>

  12. Pour chaque nœud de la paire HA, activez le rétablissement automatique :

    storage failover modify -node target-node -auto-giveback true

    Cette commande doit être répétée pour chaque nœud de la paire HA.

  13. Vérifier que le rétablissement automatique est activé :

    storage failover show -fields auto-giveback

    Cet exemple montre que le rétablissement automatique a été activé sur les deux nœuds :

    cluster_x::> storage failover show -fields auto-giveback
node     auto-giveback
-------- -------------
node_x_1 true
node_x_2 true
2 entries were displayed.