En savoir plus sur la reprise après incident asynchrone ONTAP SnapMirror
Suggérer des modifications
PDF
SnapMirror est une technologie de reprise après incident conçue pour le basculement du stockage primaire vers le stockage secondaire sur un site distant. Comme son nom l'indique, SnapMirror crée une réplique ou mirror de vos données de travail dans un stockage secondaire à partir duquel vous pouvez continuer à transmettre des données en cas de catastrophe sur le site primaire.
Si le site primaire assure toujours le service des données, il vous suffit de transférer les données requises vers celui-ci et ne transmet plus le tout aux clients depuis le miroir. Comme l'indique le cas de basculement, les contrôleurs du système secondaire doivent être équivalents ou presque équivalents aux contrôleurs du système primaire pour assurer un service efficace des données à partir du stockage en miroir.
Relations de protection des données
Les données sont mises en miroir au niveau du volume. La relation entre le volume source du stockage primaire et le volume de destination du stockage secondaire est appelée « relation de protection des données »._ les clusters dans lesquels résident les volumes et les SVM qui fournissent des données depuis ces volumes doivent être de "touré". Grâce à une relation de pairs, les clusters et les SVM peuvent échanger les données de manière sécurisée.
Cette figure illustre les relations de protection des données SnapMirror :
Portée des relations de protection des données
Vous pouvez créer une relation de protection des données directement entre des volumes ou entre les SVM qui possèdent des volumes. Dans une relation de protection des données de SVM, tout ou partie de la configuration du SVM, depuis les exportations NFS et les partages SMB jusqu'au RBAC, est répliqué, ainsi que les données des volumes que la SVM possède.
Vous pouvez également utiliser SnapMirror pour des applications spéciales de protection des données :
-
Une partage de charge mirror du volume root du SVM permet de garantir que les données restent accessibles en cas de panne ou de basculement du nœud.
-
Une relation de protection des données entre SnapLock volumes vous permet de répliquer des fichiers WORM sur un stockage secondaire.
-
À partir de ONTAP 9.13.1, vous pouvez utiliser SnapMirror asynchrone pour protéger groupes de cohérence. Depuis la version ONTAP 9.14.1, vous pouvez utiliser la réplication asynchrone SnapMirror pour répliquer des snapshots granulaires par volume vers le cluster de destination à l'aide de la relation de groupe de cohérence. Pour plus d'informations, voir Configurer la protection asynchrone SnapMirror.
Comment les relations de protection des données SnapMirror sont initialisées
La première fois que vous appelez SnapMirror, il effectue un transfert de base du volume source vers le volume de destination. La SnapMirror policy pour la relation définit le contenu de la base et toutes les mises à jour.
Transfert de base avec la règle SnapMirror par défaut MirrorAllSnapshots implique les étapes suivantes :
-
Créer un snapshot du volume source.
-
Transférez le snapshot et tous les blocs de données qu'il référence au volume de destination.
-
Transférer les snapshots restants et moins récents sur le volume source vers le volume de destination en vue d'une utilisation en cas de corruption du miroir « actif ».
Mise à jour des relations de protection des données SnapMirror
Les mises à jour sont asynchrones, en fonction du planning que vous configurez. La rétention met en miroir la règle de snapshot sur la source.
À chaque mise à jour de la MirrorAllSnapshots règle, SnapMirror crée un snapshot du volume source et transfère cet instantané ainsi que tous les snapshots effectués depuis la dernière mise à jour. Dans les valeurs de sortie suivantes de snapmirror policy show la commande pour la MirrorAllSnapshots règle, noter ce qui suit :
-
Create SnapshotEst « true », ce qui signifie queMirrorAllSnapshotscrée un snapshot lorsque SnapMirror met à jour la relation. -
MirrorAllSnapshotsPossède des règles «sm_created» et « all_source_snapshots », indiquant que le snapshot créé par SnapMirror et tous les snapshots effectués depuis la dernière mise à jour sont transférés lorsque SnapMirror met à jour la relation.
cluster_dst::> snapmirror policy show -policy MirrorAllSnapshots -instance
Vserver: vs0
SnapMirror Policy Name: MirrorAllSnapshots
SnapMirror Policy Type: async-mirror
Policy Owner: cluster-admin
Tries Limit: 8
Transfer Priority: normal
Ignore accesstime Enabled: false
Transfer Restartability: always
Network Compression Enabled: false
Create Snapshot: true
Comment: SnapMirror asynchronous policy for mirroring all snapshots
and the latest active file system.
Total Number of Rules: 2
Total Keep: 2
Rules: SnapMirror Label Keep Preserve Warn Schedule Prefix
---------------- ---- -------- ---- -------- ------
sm_created 1 false 0 - -
all_source_snapshots 1 false 0 - -
Politique MirrorLatest
La règle préconfigurée MirrorLatest fonctionne exactement de la même manière que MirrorAllSnapshots, sauf que seul le snapshot créé par SnapMirror est transféré à l'initialisation et à la mise à jour.
Rules: SnapMirror Label Keep Preserve Warn Schedule Prefix
---------------- ---- -------- ---- -------- ------
sm_created 1 false 0 - -