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

Comportement du volume lors du basculement et du retour en arrière

PDF

Les événements qui déclenchent un basculement ou un retour en arrière entraînent le déplacement des volumes actifs d'un cluster vers l'autre cluster du groupe de reprise après sinistre. Les volumes du cluster qui étaient actifs et fournissaient des données aux clients sont arrêtés, et les volumes de l'autre cluster sont activés et commencent à fournir des données. Unified Manager surveille uniquement les volumes actifs et en cours d'exécution.

Étant donné que les volumes sont déplacés d’un cluster à un autre, il est recommandé de surveiller les deux clusters. Une seule instance d'Unified Manager peut surveiller les deux clusters dans une configuration MetroCluster , mais parfois la distance entre les deux emplacements nécessite l'utilisation de deux instances d'Unified Manager pour surveiller les deux clusters. La figure suivante montre une seule instance de Unified Manager :

Une capture d’écran de l’interface utilisateur qui montre une seule instance de Unified Manager.

Les volumes avec p dans leurs noms indiquent les volumes principaux et les volumes avec b dans leurs noms sont des volumes de sauvegarde en miroir créés par SnapMirror.

En fonctionnement normal :

  • Le cluster A possède deux volumes actifs : Vol1p et Vol2p.

  • Le cluster B possède deux volumes actifs : Vol3p et Vol4p.

  • Le cluster A possède deux volumes inactifs : Vol3b et Vol4b.

  • Le cluster B possède 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 collectées par le cluster B.

Après qu'une panne catastrophique provoque un basculement des volumes actifs du cluster B vers le cluster A :

  • Le cluster A possède quatre volumes actifs : Vol1p, Vol2p, Vol3b et Vol4b.

  • Le cluster B possède quatre volumes inactifs : Vol3p, Vol4p, Vol1b et Vol2b.

Comme lors du 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 collectées par le cluster A, et les statistiques Vol3b et Vol4b sont également collectées 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 dans Unified Manager pour Vol3p ne sont pas les mêmes que celles de Vol3b :

  • Lors du passage au cluster A, les statistiques et événements Vol3p ne sont pas visibles.

  • Dès le premier basculement, Vol3b ressemble à un nouveau volume sans aucune information historique.

Lorsque le cluster B est réparé et qu'un basculement est effectué, Vol3p est à nouveau actif sur le cluster B, avec les statistiques historiques et un écart de statistiques pour la période pendant le basculement. Vol3b n'est pas visible depuis le cluster A jusqu'à ce qu'un autre basculement se produise :

Une capture d'écran de l'interface utilisateur qui montre le comportement du volume lors du basculement.
Remarque

  • Les volumes MetroCluster qui sont inactifs, par exemple Vol3b sur le cluster A après un basculement, sont identifiés par le message « Ce volume a été supprimé ». Le volume n'est pas réellement supprimé, mais il n'est actuellement pas surveillé par Unified Manager car il ne s'agit pas du volume actif.

  • Si un seul gestionnaire unifié surveille les deux clusters dans une configuration MetroCluster , la recherche de volume renvoie des informations pour le volume actif à ce moment-là. Par exemple, une recherche pour « Vol3 » renverrait des statistiques et des événements pour Vol3b sur le cluster A si un basculement a eu lieu et que Vol3 est devenu actif sur le cluster A.