Installez un MetroCluster connecté à un fabric
Fin de la restauration
Suggérer des modifications
PDF
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.
-
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".
-
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é.
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.
|
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. |
-
Identifiez les licences sur le nœud :
license showL'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. -
Vérifiez que les licences sont bonnes pour le nœud après le rétablissement :
metrocluster check license showL'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
-
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.
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." -
Installer chaque clé de licence :
system license add -license-code license-key, license-key…+ -
Supprimez les anciennes licences, si nécessaire :
-
Vérifier si les licences ne sont pas utilisées :
license clean-up -unused -simulate -
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.
-
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 syncPour plus d'informations, voir "Restauration des clés de chiffrement intégrées de gestion des clés".
Gestion externe des clés
security key-manager key query -node node-namePour plus d'informations, voir "Restauration des clés de chiffrement externes de gestion des clés".
-
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.
-
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.
-
Vérifiez que tous les nœuds sont en état activé :
metrocluster node showL'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. -
Confirmer que la resynchronisation est terminée sur tous les SVM :
metrocluster vserver show -
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 -
Exécutez le rétablissement
metrocluster switchbackutilisez une commande à partir d'un nœud du cluster survivant. -
Vérifier la progression de l'opération de rétablissement :
metrocluster showL'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 -
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.
-
Vérifier que les agrégats de données basculée sont basculée :
storage aggregate showDans 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_1Si 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."
-
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-sourcenode_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_b2Les agrégats de destination de synchronisation dans la configuration MetroCluster ont automatiquement ajouté le suffixe « -mc » à leur nom pour les identifier.
-
Vérifiez que les opérations de rétablissement ont abouti en utilisant le
metrocluster operation showcommande.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.
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.
-
Sur le site de secours, identifiez les agrégats qui ne sont pas mis en miroir :
storage aggregate showcluster_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::> -
Mettre en miroir l'un des agrégats racine :
storage aggregate mirror -aggregate root-aggregateL'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::> -
Vérifier que la mise en miroir de l'agrégat racine est terminée :
storage aggregate showL'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::> -
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.
-
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.
-
Supprimez la configuration du médiateur ONTAP existante :
metrocluster configuration-settings mediator remove -
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.
-
Vérifier que la MetroCluster est configurée et en mode normal sur chaque cluster :
metrocluster showcluster_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 -
Vérifier que la mise en miroir est activée sur chaque nœud :
metrocluster node showcluster_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. -
Vérifier que les composants MetroCluster sont sains :
metrocluster check runcluster_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.
-
Vérifier qu'il n'y a pas d'alerte de santé :
system health alert show -
Simuler une opération de basculement :
-
Depuis l'invite de n'importe quel nœud, passez au niveau de privilège avancé :
set -privilege advanced
Vous devez répondre avec
ylorsque vous êtes invité à passer en mode avancé et à afficher l'invite du mode avancé (*).-
Effectuer le basculement avec le
-simulateparamètre :metrocluster switchover -simulate -
Retour au niveau de privilège admin :
set -privilege admin
-
-
Pour les configurations IP MetroCluster utilisant le service ONTAP Mediator, vérifiez que le service Mediator est opérationnel.
-
Vérifiez que les disques du médiateur sont visibles par le système :
storage failover mailbox-disk showL'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. -
Changement au niveau de privilège avancé :
set -privilege advanced -
Vérifier que les LUN de la boîte aux lettres sont visibles pour le système :
storage iscsi-initiator showLe 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.-
Revenir au niveau de privilège administratif :
set -privilege admin
-