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.

Fin de la restauration

Contributeurs

Exécutez les tâches requises pour effectuer la restauration en cas de défaillance du stockage ou d'un multicontrôleur.

Rétablir les magasins d'objets pour les configurations FabricPool

Si l'un des magasins d'objets d'un miroir FabricPool était en colocation avec le site de secours MetroCluster et qu'il a été détruit, vous devez rétablir le magasin d'objets et le miroir FabricPool.

Description de la tâche
  • Si les magasins d'objets sont distants et qu'un site MetroCluster est détruit, vous n'avez pas besoin de reconstruire le magasin d'objets. En outre, les configurations de magasin d'objets d'origine ainsi que le contenu des données inactives sont conservés.

  • Pour plus d'informations sur les configurations FabricPool, consultez le "Gestion des disques et des agrégats".

Étape
  1. Suivre la procédure "Remplacement d'un miroir FabricPool sur une configuration MetroCluster" dans "Gestion des disques et des agrégats".

Vérification des licences sur les nœuds remplacés

Vous devez installer de nouvelles licences pour les nœuds de remplacement si les nœuds douteux utilisent les fonctionnalités ONTAP qui nécessitent une licence standard (nœud verrouillé). Pour les fonctionnalités avec licences standard, chaque nœud du cluster doit avoir sa propre clé pour cette fonctionnalité.

Description de la tâche

Tant que vous n'avez pas installé de clés de licence, les fonctionnalités nécessitant une licence standard restent disponibles pour le nœud de remplacement. Cependant, si le nœud douteux était le seul nœud du cluster avec une licence pour la fonction, aucune modification de configuration de la fonction n'est autorisée. Par ailleurs, si vous utilisez des fonctionnalités sans licence sur le nœud, vous risquez de vous conformer à votre contrat de licence. Vous devez donc installer la ou les clés de licence de remplacement sur le nœud de remplacement dès que possible.

Les clés de licence doivent être au format à 28 caractères.

Vous disposez d'une période de grâce de 90 jours pour installer les clés de licence. Après la période de grâce, toutes les anciennes licences sont invalidés. Après l'installation d'une clé de licence valide, vous disposez de 24 heures pour installer toutes les clés avant la fin du délai de grâce.

Remarque Si tous les nœuds sur un site ont été remplacés (un nœud unique dans le cas d'une configuration MetroCluster à deux nœuds), les clés de licence doivent être installées sur le ou les nœuds de remplacement avant le rétablissement.
Étapes
  1. Identifiez les licences sur le nœud :

    license show

    L'exemple suivant affiche les informations relatives aux licences dans le système :

    cluster_B::>  license show
             (system license show)
    
    Serial Number: 1-80-00050
    Owner: site1-01
    Package           Type       Description             Expiration
    -------          -------     -------------           -----------
    Base             license     Cluster Base License        -
    NFS              site        NFS License                 -
    CIFS             site        CIFS License                -
    iSCSI            site        iSCSI License               -
    FCP              site        FCP License                 -
    FlexClone        site        FlexClone License           -
    
    6 entries were displayed.
  2. Vérifiez que les licences sont bonnes pour le nœud après le rétablissement :

    metrocluster check license show

    L'exemple suivant présente les licences qui sont bonnes pour le nœud :

    cluster_B::> metrocluster check license show
    
    Cluster           Check                             Result
    -------           -------                           -------------
    Cluster_B         negotiated-switchover-ready       not-applicable
    NFS               switchback-ready                  not-applicable
    CIFS              job-schedules                     ok
    iSCSI             licenses                          ok
    FCP               periodic-check-enabled            ok
  3. Si vous avez besoin de nouvelles clés de licence, obtenez-les sur le site de support NetApp, dans la section My support (mon support), sous licences logicielles.

    Remarque Les nouvelles clés de licence dont vous avez besoin sont générées automatiquement et envoyées à l'adresse électronique du fichier. Si vous ne recevez pas cet e-mail avec les clés de licence dans les 30 jours, consultez la section « qui contacter en cas de problème avec mes licences ? » de l'article de la base de connaissances "Processus de remplacement post-carte mère pour la mise à jour des licences sur un système AFF/FAS."
  4. Installer chaque clé de licence :

    system license add -license-code license-key, license-key…​+

  5. Supprimez les anciennes licences, si nécessaire :

    1. Vérifier si les licences ne sont pas utilisées :

      license clean-up -unused -simulate

    2. Si la liste semble correcte, supprimez les licences inutilisées :

      license clean-up -unused

Restauration de la gestion des clés

Si les volumes de données sont chiffrés, vous devez restaurer la gestion des clés. Si le volume racine est chiffré, vous devez récupérer la gestion des clés.

Étapes
  1. Si les volumes de données sont chiffrés, restaurez les clés à l'aide de la commande appropriée pour votre configuration de gestion des clés.

    Si vous utilisez…​

    Utilisez cette commande…​

    Gestion intégrée des clés

    security key-manager onboard sync

    Gestion externe des clés

    security key-manager key query -node node-name

  2. Si le volume racine est chiffré, utilisez la procédure décrite dans la section "Récupération de la gestion des clés si le volume racine est chiffré".

Exécution d'un rétablissement

Après avoir rétablissement la configuration MetroCluster, vous pouvez exécuter l'opération de rétablissement MetroCluster. L'opération de rétablissement MetroCluster renvoie la configuration à son état de fonctionnement normal, avec les SVM (Storage Virtual machines) source synchrone sur le site de reprise après incident et permettant l'accès aux données depuis les pools de disques locaux.

Avant de commencer
  • Le cluster de secours doit avoir basculé avec succès vers le cluster survivant.

  • La réparation doit avoir été effectuée sur les agrégats racine et de données.

  • Les autres nœuds du cluster ne doivent pas être en état de basculement haute disponibilité (tous les nœuds doivent être opérationnels pour chaque paire haute disponibilité).

  • Les modules du contrôleur du site de secours doivent être complètement démarrés et non en mode basculement HA.

  • L'agrégat racine doit être mis en miroir.

  • Les liens ISL doivent être en ligne.

  • Toutes les licences requises doivent être installées sur le système.

Étapes
  1. Vérifiez que tous les nœuds sont en état activé :

    metrocluster node show

    L'exemple suivant présente les nœuds qui sont actuellement à l'état activé :

    cluster_B::>  metrocluster node show
    
    DR                        Configuration  DR
    Group Cluster Node        State          Mirroring Mode
    ----- ------- ----------- -------------- --------- --------------------
    1     cluster_A
                  node_A_1    configured     enabled   heal roots completed
                  node_A_2    configured     enabled   heal roots completed
          cluster_B
                  node_B_1    configured     enabled   waiting for switchback recovery
                  node_B_2    configured     enabled   waiting for switchback recovery
    4 entries were displayed.
  2. Confirmer que la resynchronisation est terminée sur tous les SVM :

    metrocluster vserver show

  3. Vérifier que toute migration LIF automatique effectuée par les opérations de correction a été réalisée avec succès :

    metrocluster check lif show

  4. Exécutez le rétablissement metrocluster switchback utilisez une commande à partir d'un nœud du cluster survivant.

  5. Vérifier la progression de l'opération de rétablissement :

    metrocluster show

    L'opération de rétablissement est toujours en cours lorsque la sortie affiche « en attente de rétablissement » :

    cluster_B::> metrocluster show
    Cluster                   Entry Name          State
    ------------------------- ------------------- -----------
     Local: cluster_B         Configuration state configured
                              Mode                switchover
                              AUSO Failure Domain -
    Remote: cluster_A         Configuration state configured
                              Mode                waiting-for-switchback
                              AUSO Failure Domain -

    L'opération de rétablissement est terminée lorsque la sortie affiche « normal » :

    cluster_B::> metrocluster show
    Cluster                   Entry Name          State
    ------------------------- ------------------- -----------
     Local: cluster_B         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain -
    Remote: cluster_A         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain -

    Si un rétablissement prend un certain temps, vous pouvez vérifier l'état des lignes de base en cours en utilisant la commande suivante au niveau des privilèges avancés :

    metrocluster config-replication resync-status show

  6. Rétablir toutes les configurations SnapMirror ou SnapVault.

    Dans ONTAP 8.3, vous devez rétablir manuellement une configuration SnapMirror perdue après une opération de rétablissement MetroCluster. Dans ONTAP 9.0 et versions ultérieures, la relation est rétablie automatiquement.

Vérification du rétablissement réussi

Après le rétablissement, il vous faut vérifier que tous les agrégats et les serveurs virtuels de stockage sont basculés et en ligne.

Étapes
  1. Vérifier que les agrégats de données basculée sont basculée :

    storage aggregate show

    Dans l'exemple suivant, aggr_b2 sur le nœud B2 a été remis :

    node_B_1::> storage aggregate show
    Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
    --------- -------- --------- ----- ------- ------ ---------------- ------------
    ...
    aggr_b2    227.1GB   227.1GB    0% online       0 node_B_2   raid_dp,
                                                                       mirrored,
                                                                       normal
    
    node_A_1::> aggr show
    Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
    --------- -------- --------- ----- ------- ------ ---------------- ------------
    ...
    aggr_b2          -         -     - unknown      - node_A_1

    Si le site de secours contenait des agrégats non mis en miroir et que les agrégats non mis en miroir ne sont plus présents, l'agrégat peut afficher un état « inconnu » dans le résultat de la commande Storage aggry show. Contactez le support technique pour supprimer les entrées obsolètes des agrégats non mis en miroir, consultez l'article de la base de connaissances "Comment supprimer des entrées d'agrégats non mis en miroir obsolètes dans un MetroCluster après un incident où le stockage a été perdu."

  2. Assurez-vous que tous les SVM de destination synchrone du cluster survivant sont inactifs (en affichant un état d'administration de « `spart') et que les SVM source de synchronisation sur le cluster de secours sont opérationnels :

    vserver show -subtype sync-source

    node_B_1::> vserver show -subtype sync-source
                                   Admin      Root                       Name    Name
    Vserver     Type    Subtype    State      Volume     Aggregate       Service Mapping
    ----------- ------- ---------- ---------- ---------- ----------      ------- -------
    ...
    vs1a        data    sync-source
                                   running    vs1a_vol   node_B_2        file    file
                                                                         aggr_b2
    
    node_A_1::> vserver show -subtype sync-destination
                                   Admin      Root                         Name    Name
    Vserver            Type    Subtype    State      Volume     Aggregate  Service Mapping
    -----------        ------- ---------- ---------- ---------- ---------- ------- -------
    ...
    cluster_A-vs1a-mc  data    sync-destination
                                          stopped    vs1a_vol   sosb_      file    file
                                                                           aggr_b2

    Les agrégats de destination de synchronisation dans la configuration MetroCluster ont automatiquement ajouté le suffixe « -mc » à leur nom pour les identifier.

  3. Vérifiez que les opérations de rétablissement ont abouti en utilisant le metrocluster operation show commande.

    Si la sortie de la commande affiche…​

    Alors…​

    L'état de l'opération de rétablissement a réussi.

    Le processus de rétablissement est terminé et vous pouvez poursuivre le fonctionnement du système.

    Que l'opération de rétablissement ou de rétablissement-continuation-agent soit partiellement réussie.

    Exécutez la correction suggérée indiquée dans la sortie de la commande MetroCluster opération show.

Une fois que vous avez terminé

Vous devez répéter les sections précédentes pour effectuer le rétablissement dans la direction opposée. Si site_A a effectué un basculement du site_B, demandez à site_B de basculer du site_A.

Mise en miroir des agrégats racine des nœuds de remplacement

Si des disques ont été remplacés, vous devez mettre en miroir les agrégats racine des nouveaux nœuds sur le site de secours.

Étapes
  1. Sur le site de secours, identifiez les agrégats qui ne sont pas mis en miroir :

    storage aggregate show

    cluster_A::> storage aggregate show
    
    Aggregate     Size Available Used% State   #Vols  Nodes            RAID Status
    --------- -------- --------- ----- ------- ------ ---------------- ------------
    node_A_1_aggr0
                1.49TB   74.12GB   95% online       1 node_A_1         raid4,
                                                                       normal
    node_A_2_aggr0
                1.49TB   74.12GB   95% online       1 node_A_2         raid4,
                                                                       normal
    node_A_1_aggr1
                1.49TB   74.12GB   95% online       1 node_A_1         raid 4, normal
                                                                       mirrored
    node_A_2_aggr1
                1.49TB   74.12GB   95% online       1 node_A_2         raid 4, normal
                                                                       mirrored
    4 entries were displayed.
    
    cluster_A::>
  2. Mettre en miroir l'un des agrégats racine :

    storage aggregate mirror -aggregate root-aggregate

    L'exemple suivant montre comment la commande sélectionne des disques et demande une confirmation lors de la mise en miroir de l'agrégat.

    cluster_A::> storage aggregate mirror -aggregate node_A_2_aggr0
    
    Info: Disks would be added to aggregate "node_A_2_aggr0" on node "node_A_2" in
          the following manner:
    
          Second Plex
    
            RAID Group rg0, 3 disks (block checksum, raid4)
              Position   Disk                      Type                  Size
              ---------- ------------------------- ---------- ---------------
              parity     2.10.0                    SSD                      -
              data       1.11.19                   SSD                894.0GB
              data       2.10.2                    SSD                894.0GB
    
          Aggregate capacity available for volume use would be 1.49TB.
    
    Do you want to continue? {y|n}: y
    
    cluster_A::>
  3. Vérifier que la mise en miroir de l'agrégat racine est terminée :

    storage aggregate show

    L'exemple suivant montre que les agrégats racine sont mis en miroir.

    cluster_A::> storage aggregate show
    
    Aggregate     Size Available Used% State   #Vols  Nodes       RAID Status
    --------- -------- --------- ----- ------- ------ ----------- ------------
    node_A_1_aggr0
                1.49TB   74.12GB   95% online       1 node_A_1    raid4,
                                                                  mirrored,
                                                                  normal
    node_A_2_aggr0
                2.24TB   838.5GB   63% online       1 node_A_2    raid4,
                                                                  mirrored,
                                                                  normal
    node_A_1_aggr1
                1.49TB   74.12GB   95% online       1 node_A_1    raid4,
                                                                  mirrored,
                                                                  normal
    node_A_2_aggr1
                1.49TB   74.12GB   95% online       1 node_A_2    raid4
                                                                  mirrored,
                                                                  normal
    4 entries were displayed.
    
    cluster_A::>
  4. Répétez cette procédure pour les autres agrégats racine.

    Tout agrégat racine qui n'est pas à l'état mis en miroir doit être mis en miroir.

Reconfiguration du service ONTAP Mediator (configurations MetroCluster IP)

Si vous disposez d'une configuration IP MetroCluster configurée avec le service médiateur ONTAP, vous devez supprimer et reconfigurer l'association avec le médiateur.

Avant de commencer
  • Vous devez disposer de l'adresse IP, du nom d'utilisateur et du mot de passe pour le service Mediator de ONTAP.

  • Le service Mediator ONTAP doit être configuré et exécuté sur l'hôte Linux.

Étapes
  1. Supprimez la configuration du médiateur ONTAP existante :

    metrocluster configuration-settings mediator remove

  2. Reconfigurez la configuration du médiateur ONTAP :

    metrocluster configuration-settings mediator add -mediator-address mediator-IP-address

Vérification de l'état de santé de la configuration MetroCluster

Vous devez vérifier l'état de santé de la configuration MetroCluster pour vérifier que celle-ci fonctionne correctement.

Étapes
  1. Vérifier que la MetroCluster est configurée et en mode normal sur chaque cluster :

    metrocluster show

    cluster_A::> metrocluster show
    Cluster                   Entry Name          State
    ------------------------- ------------------- -----------
     Local: cluster_A         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain auso-on-cluster-disaster
    Remote: cluster_B         Configuration state configured
                              Mode                normal
                              AUSO Failure Domain auso-on-cluster-disaster
  2. Vérifier que la mise en miroir est activée sur chaque nœud :

    metrocluster node show

    cluster_A::> metrocluster node show
    DR                           Configuration  DR
    Group Cluster Node           State          Mirroring Mode
    ----- ------- -------------- -------------- --------- --------------------
    1     cluster_A
                  node_A_1       configured     enabled   normal
          cluster_B
                  node_B_1       configured     enabled   normal
    2 entries were displayed.
  3. Vérifier que les composants MetroCluster sont sains :

    metrocluster check run

    cluster_A::> metrocluster check run
    
    Last Checked On: 10/1/2014 16:03:37
    
    Component           Result
    ------------------- ---------
    nodes               ok
    lifs                ok
    config-replication  ok
    aggregates          ok
    4 entries were displayed.
    
    Command completed. Use the `metrocluster check show -instance` command or sub-commands in `metrocluster check` directory for detailed results.
    To check if the nodes are ready to do a switchover or switchback operation, run `metrocluster switchover -simulate` or `metrocluster switchback -simulate`, respectively.
  4. Vérifier qu'il n'y a pas d'alerte de santé :

    system health alert show

  5. Simuler une opération de basculement :

    1. Depuis l'invite de n'importe quel nœud, passez au niveau de privilège avancé :

      set -privilege advanced

    Vous devez répondre avec y lorsque vous êtes invité à passer en mode avancé et à afficher l'invite du mode avancé (*).

    1. Effectuer le basculement avec le -simulate paramètre :

      metrocluster switchover -simulate

    2. Retour au niveau de privilège admin :

      set -privilege admin

  6. Pour les configurations IP MetroCluster utilisant le service ONTAP Mediator, vérifiez que le service Mediator est opérationnel.

    1. Vérifiez que les disques du médiateur sont visibles par le système :

      storage failover mailbox-disk show

      L'exemple suivant montre que les disques de boîte aux lettres ont été reconnus.

      node_A_1::*> storage failover mailbox-disk show
                       Mailbox
      Node             Owner     Disk    Name        Disk UUID
      -------------     ------   -----   -----        ----------------
      sti113-vsim-ucs626g
      .
      .
           local     0m.i2.3L26      7BBA77C9:AD702D14:831B3E7E:0B0730EE:00000000:00000000:00000000:00000000:00000000:00000000
           local     0m.i2.3L27      928F79AE:631EA9F9:4DCB5DE6:3402AC48:00000000:00000000:00000000:00000000:00000000:00000000
           local     0m.i1.0L60      B7BCDB3C:297A4459:318C2748:181565A3:00000000:00000000:00000000:00000000:00000000:00000000
      .
      .
      .
           partner   0m.i1.0L14      EA71F260:D4DD5F22:E3422387:61D475B2:00000000:00000000:00000000:00000000:00000000:00000000
           partner   0m.i2.3L64      4460F436:AAE5AB9E:D1ED414E:ABF811F7:00000000:00000000:00000000:00000000:00000000:00000000
      28 entries were displayed.
    2. Changement au niveau de privilège avancé :

      set -privilege advanced

    3. Vérifier que les LUN de la boîte aux lettres sont visibles pour le système :

      storage iscsi-initiator show

      Le résultat indique la présence des LUN de boîte aux lettres :

    Node    Type       Label      Target Portal     Target Name                                 Admin/Op
    ----    ----       --------   ---------    --------- --------------------------------       --------
    .
    .
    .
    .node_A_1
                   mailbox
                         mediator 172.16.254.1    iqn.2012-05.local:mailbox.target.db5f02d6-e3d3    up/up
    .
    .
    .
    17 entries were displayed.
    1. Revenir au niveau de privilège administratif :

      set -privilege admin