Comportement des volumes lors du basculement et du rétablissement
-
Un fichier PDF de toute la documentation
-
Installez Unified Manager sur les systèmes Linux
-
Réaliser les tâches de configuration et d'administration
-
Surveillance et gestion du stockage
-
Contrôle et gestion des performances du cluster
-
Contrôlez et gérez l'état du cluster
-
![](https://docs.netapp.com/common/images/pdf-zip.png)
Plusieurs fichiers PDF
Creating your file...
Les événements qui déclenchent un basculement ou un rétablissement entraînent le déplacement des volumes actifs d'un cluster vers l'autre cluster du groupe de reprise sur incident. Les volumes du cluster qui étaient actifs et devaient transmettre des données aux clients sont arrêtés, et les volumes de l'autre cluster sont activés et commencent à transmettre les données. Unified Manager surveille uniquement les volumes actifs et en cours d'exécution.
Comme les volumes sont déplacés d'un cluster à l'autre, il est recommandé de contrôler les deux clusters. Une seule instance de Unified Manager peut contrôler les deux clusters dans une configuration MetroCluster, mais parfois la distance entre les deux sites nécessite l'utilisation de deux instances Unified Manager pour surveiller les deux clusters. La figure suivante présente une seule instance de Unified Manager :
![basculement opm mcc](../media/opm_mcc_switchover.gif)
Les volumes portant la référence p indiquent les volumes primaires, et les volumes dont l'noms est b sont des volumes de sauvegarde en miroir créés par SnapMirror.
En fonctionnement normal :
-
Le cluster A a deux volumes actifs : Vol1p et Vol2p.
-
Le cluster B a deux volumes actifs : Vol3p et Vol4p.
-
Cluster A comporte deux volumes inactifs : Vol3b et Vol4b.
-
Le cluster B a deux volumes inactifs : Vol1b et Vol2b.
Les informations relatives à chacun des volumes actifs (statistiques, événements, etc.) sont collectées par Unified Manager. Les statistiques Vol1p et Vol2p sont collectées par le Cluster A et les statistiques Vol3p et Vol4p sont recueillies par le Cluster B.
Après une défaillance majeure, entraîne le basculement des volumes actifs du Cluster B vers le Cluster A :
-
Cluster A contient quatre volumes actifs : Vol1p, Vol2p, Vol3b et Vol4b.
-
Le cluster B a quatre volumes inactifs : Vol3p, Vol4p, Vol1b et Vol2b.
Comme pendant le fonctionnement normal, les informations relatives à chacun des volumes actifs sont collectées par Unified Manager. Mais dans ce cas, les statistiques Vol1p et Vol2p sont recueillies par le Cluster A, et les statistiques Vol3b et Vol4b sont également recueillies par le Cluster A.
Notez que Vol3p et Vol3b ne sont pas les mêmes volumes, car ils se trouvent sur des clusters différents. Les informations contenues dans Unified Manager pour Vol3p ne sont pas les mêmes que Vol3b :
-
Lors du basculement vers le Cluster A, les statistiques et les événements Vol3p ne sont pas visibles.
-
Lors du premier basculement, Vol3b ressemble à un nouveau volume sans informations historiques.
Lorsque le Cluster B est réparé et qu'un rétablissement est effectué, Vol3p est de nouveau actif sur le Cluster B, avec les statistiques historiques et un intervalle de statistiques correspondant à la période de basculement. Vol3b n'est pas visible depuis le Cluster A tant qu'un autre basculement se produit :
![volumes opm mcc](../media/opm_mcc_volumes.gif)
|
|