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

Actualisation d'une configuration IP MetroCluster à quatre ou huit nœuds (ONTAP 9.8 et versions ultérieures)

Contributeurs
PDF

Vous pouvez utiliser cette procédure pour mettre à niveau les contrôleurs et le stockage dans des configurations à quatre ou huit nœuds.

À partir de ONTAP 9.13.1, vous pouvez mettre à niveau les contrôleurs et le stockage dans une configuration IP MetroCluster à huit nœuds en développant la configuration pour devenir une configuration temporaire à douze nœuds, puis en supprimant les anciens groupes de reprise après incident.

À partir de ONTAP 9.8, vous pouvez mettre à niveau les contrôleurs et le stockage d'une configuration IP MetroCluster à quatre nœuds en développant la configuration pour devenir une configuration temporaire à huit nœuds, puis en supprimant l'ancien groupe DR.

Description de la tâche

  • Si vous avez une configuration à huit nœuds, votre système doit exécuter ONTAP 9.13.1 ou une version ultérieure.

  • Si vous avez une configuration à quatre nœuds, votre système doit exécuter ONTAP 9.8 ou une version ultérieure.

  • Si vous mettez également à niveau les commutateurs IP, vous devez les mettre à niveau avant d'effectuer cette procédure d'actualisation.

  • Cette procédure décrit les étapes requises pour actualiser un groupe DR à quatre nœuds. Si vous avez une configuration à huit nœuds (deux groupes DR), vous pouvez actualiser l'un des groupes DR, ou les deux.

    Si vous actualisez les deux groupes DR, vous devez actualiser un groupe DR à la fois.

  • Les références aux « anciens nœuds » désignent les nœuds que vous souhaitez remplacer.

  • Pour les configurations à huit nœuds, la combinaison de plateformes MetroCluster à huit nœuds source et cible doit être prise en charge.

    Remarque Si vous actualisez les deux groupes DR, il se peut que la combinaison de plateformes ne soit pas prise en charge après l'actualisation du premier groupe DR. Vous devez actualiser les deux groupes DR pour obtenir une configuration à huit nœuds prise en charge.

  • Vous ne pouvez actualiser que des modèles de plate-forme spécifiques en suivant cette procédure dans une configuration MetroCluster IP.

  • Les limites inférieures des plates-formes source et cible s'appliquent. Si vous passez à une plateforme supérieure, les limites de la nouvelle plateforme ne s'appliquent qu'à la fin de la mise à jour technologique de tous les groupes de reprise après incident.

  • Si vous effectuez une mise à jour technologique sur une plateforme dont les limites sont inférieures à celles de la plateforme source, vous devez ajuster et réduire les limites à atteindre ou à une valeur inférieure aux limites de la plateforme cible avant d'effectuer cette procédure.

Étapes

  1. Vérifiez qu'un domaine de diffusion par défaut est créé sur les anciens nœuds.

    Lorsque vous ajoutez de nouveaux nœuds à un cluster existant sans broadcast domain par défaut, les LIFs de node-management sont créées pour les nouveaux nœuds à l'aide d'UUID (Universal unique identifier) à la place des noms attendus. Pour plus d'informations, consultez l'article de la base de connaissances "Les LIF de gestion de nœuds sur les nouveaux nœuds ajoutés sont générées avec des noms UUID".

  2. Collecte des informations des anciens nœuds.

    À ce stade, la configuration à quatre nœuds apparaît comme illustré sur l'image suivante :

    mcc dr groupe a

    La configuration à huit nœuds s'affiche comme illustré dans l'image suivante :

    mcc dr groups

  3. Pour éviter la génération automatique de dossiers de demande de support, envoyez un message AutoSupport pour indiquer que la mise à niveau est en cours.

    1. Lancer la commande suivante :
      system node autosupport invoke -node * -type all -message "MAINT=10h Upgrading old-model to new-model"

      L'exemple suivant spécifie une fenêtre de maintenance de 10 heures. Selon votre plan, il est possible que vous souhaitiez accorder plus de temps.

      Si la maintenance est terminée avant le temps écoulé, vous pouvez appeler un message AutoSupport indiquant la fin de la période de maintenance :

    system node autosupport invoke -node * -type all -message MAINT=end

    1. Répétez la commande sur le cluster partenaire.

  4. Supprimez la configuration MetroCluster existante du logiciel disjoncteur d'attache, du médiateur ou d'autres logiciels pouvant initier le basculement.

    Si vous utilisez…​

    Utilisez cette procédure…​

    Disjoncteur d'attache

    1. Utiliser l'interface de ligne de commande Tiebreaker monitor remove Commande permettant de supprimer la configuration MetroCluster.

      Dans l'exemple suivant, « cluster_A » est supprimé du logiciel :

      NetApp MetroCluster Tiebreaker :> monitor remove -monitor-name cluster_A
Successfully removed monitor from NetApp MetroCluster Tiebreaker
software.

    2. Vérifiez que la configuration MetroCluster a été supprimée correctement à l'aide de l'interface de ligne de commande de Tiebreaker monitor show -status commande.

      NetApp MetroCluster Tiebreaker :> monitor show -status

    Médiateur

    Exécutez la commande suivante depuis l'invite ONTAP :

    metrocluster configuration-settings mediator remove

    Applications tierces

    Reportez-vous à la documentation du produit.

  5. Effectuez toutes les étapes de la section "Développement d'une configuration IP MetroCluster" pour ajouter les nouveaux nœuds et stockage à la configuration.

    Une fois la procédure d'extension terminée, la configuration temporaire s'affiche comme illustré dans les images suivantes :

    mcc dr groupe b
    Figure 1. Configuration temporaire à huit nœuds
    mcc dr groupe c4
    Figure 2. Configuration temporaire à douze nœuds

  6. Vérifier que le basculement est possible et que les nœuds sont connectés en exécutant la commande suivante sur les deux clusters :

    storage failover show

    cluster_A::> storage failover show
                                    Takeover
Node           Partner              Possible    State Description
-------------- -------------------- ---------   ------------------
Node_FC_1      Node_FC_2              true      Connected to Node_FC_2
Node_FC_2      Node_FC_1              true      Connected to Node_FC_1
Node_IP_1      Node_IP_2              true      Connected to Node_IP_2
Node_IP_2      Node_IP_1              true      Connected to Node_IP_1

  7. Déplacez les volumes CRS.

    Suivez les étapes de la section "Déplacement d'un volume de métadonnées dans les configurations MetroCluster".

  8. Déplacez les données des anciens nœuds vers les nouveaux nœuds en procédant comme suit :

    1. Effectuez toutes les étapes de la section "Création d'un agrégat et déplacement des volumes vers les nouveaux nœuds".

      Remarque Vous pouvez choisir de mettre en miroir l'agrégat lors de sa création ou après sa création.

    2. Effectuez toutes les étapes de la section "Déplacez les LIF de données non-SAN et les LIF de cluster-management vers les nouveaux nœuds".

  9. Modifiez l'adresse IP de l'homologue de cluster des nœuds transférés pour chaque cluster :

    1. Identifiez l'homologue cluster_A à l'aide de cluster peer show commande :

      cluster_A::> cluster peer show
Peer Cluster Name         Cluster Serial Number Availability   Authentication
------------------------- --------------------- -------------- --------------
cluster_B         1-80-000011           Unavailable    absent

      1. Modifiez l'adresse IP du poste cluster_A :

        cluster peer modify -cluster cluster_A -peer-addrs node_A_3_IP -address-family ipv4

    2. Identifiez l'homologue cluster_B à l'aide de cluster peer show commande :

      cluster_B::> cluster peer show
Peer Cluster Name         Cluster Serial Number Availability   Authentication
------------------------- --------------------- -------------- --------------
cluster_A         1-80-000011           Unavailable    absent

      1. Modifiez l'adresse IP de l'homologue cluster_B :

        cluster peer modify -cluster cluster_B -peer-addrs node_B_3_IP -address-family ipv4

    3. Vérifiez que l'adresse IP de l'homologue de cluster est mise à jour pour chaque cluster :

      1. Vérifiez que l'adresse IP est mise à jour pour chaque cluster à l'aide de cluster peer show -instance commande.

        Le Remote Intercluster Addresses Dans les exemples suivants, le champ affiche l'adresse IP mise à jour.

        Exemple pour cluster_A :

      cluster_A::> cluster peer show -instance

Peer Cluster Name: cluster_B
           Remote Intercluster Addresses: 172.21.178.204, 172.21.178.212
      Availability of the Remote Cluster: Available
                     Remote Cluster Name: cluster_B
                     Active IP Addresses: 172.21.178.212, 172.21.178.204
                   Cluster Serial Number: 1-80-000011
                    Remote Cluster Nodes: node_B_3-IP,
                                          node_B_4-IP
                   Remote Cluster Health: true
                 Unreachable Local Nodes: -
          Address Family of Relationship: ipv4
    Authentication Status Administrative: use-authentication
       Authentication Status Operational: ok
                        Last Update Time: 4/20/2023 18:23:53
            IPspace for the Relationship: Default
Proposed Setting for Encryption of Inter-Cluster Communication: -
Encryption Protocol For Inter-Cluster Communication: tls-psk
  Algorithm By Which the PSK Was Derived: jpake

cluster_A::>

      + Exemple pour cluster_B.

    cluster_B::> cluster peer show -instance

                       Peer Cluster Name: cluster_A
           Remote Intercluster Addresses: 172.21.178.188, 172.21.178.196 <<<<<<<< Should reflect the modified address
      Availability of the Remote Cluster: Available
                     Remote Cluster Name: cluster_A
                     Active IP Addresses: 172.21.178.196, 172.21.178.188
                   Cluster Serial Number: 1-80-000011
                    Remote Cluster Nodes: node_A_3-IP,
                                          node_A_4-IP
                   Remote Cluster Health: true
                 Unreachable Local Nodes: -
          Address Family of Relationship: ipv4
    Authentication Status Administrative: use-authentication
       Authentication Status Operational: ok
                        Last Update Time: 4/20/2023 18:23:53
            IPspace for the Relationship: Default
Proposed Setting for Encryption of Inter-Cluster Communication: -
Encryption Protocol For Inter-Cluster Communication: tls-psk
  Algorithm By Which the PSK Was Derived: jpake

cluster_B::>

  10. Suivez les étapes de la section "Suppression d'un groupe de reprise après incident" Pour supprimer l'ancien groupe DR.

  11. Si vous souhaitez actualiser les deux groupes DR dans une configuration à huit nœuds, vous devez répéter la procédure complète pour chaque groupe DR.

    Après avoir supprimé l'ancien groupe DR, la configuration s'affiche comme illustré dans les images suivantes :

    groupe dr mcc d
    Figure 3. Configuration à quatre nœuds
    mcc dr groupe c5
    Figure 4. Configuration à huit nœuds

  12. Vérifier le mode opérationnel de la configuration MetroCluster et effectuer un contrôle MetroCluster.

    1. Vérifier la configuration MetroCluster et que le mode opérationnel est normal :

      metrocluster show

    2. Vérifiez que tous les nœuds attendus s'affichent :

      metrocluster node show

    3. Exécutez la commande suivante :

      metrocluster check run

    4. Afficher les résultats de la vérification MetroCluster :

      metrocluster check show

  13. Restaurer la surveillance si nécessaire, en suivant la procédure de configuration.

    Si vous utilisez…​

    Suivre cette procédure

    Disjoncteur d'attache

    "Ajout des configurations MetroCluster" Dans le MetroCluster Tiebreaker installation et configuration.

    Médiateur

    "Configuration du service médiateur ONTAP à partir d'une configuration IP MetroCluster" Dans MetroCluster IP installation and Configuration.

    Applications tierces

    Reportez-vous à la documentation du produit.

  14. Pour reprendre la génération automatique de dossier de support, envoyez un message AutoSupport pour indiquer que la maintenance est terminée.

    1. Exécutez la commande suivante :

      system node autosupport invoke -node * -type all -message MAINT=end

    2. Répétez la commande sur le cluster partenaire.