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

À propos de la réplication SnapMirror SVM

Contributeurs
PDF

Vous pouvez utiliser SnapMirror pour créer une relation de protection des données entre les SVM. Dans ce type de relation de protection des données, tout ou partie de la configuration du SVM, depuis les exportations NFS et les partages SMB jusqu'au RBAC, est répliquée, ainsi que les données des volumes que le SVM possède.

Types de relations pris en charge

Seuls les SVM servant les données peuvent être répliqués. Les types de relations de protection des données suivants sont pris en charge :

  • Reprise sur incident SnapMirror, dans laquelle la destination contient généralement uniquement les copies Snapshot actuellement sur la source.

    À partir de ONTAP 9.9.1, ce comportement change lorsque vous utilisez la stratégie de coffre-fort miroir. Depuis la version ONTAP 9.9.1, vous pouvez créer différentes règles Snapshot sur la source et la destination, et les copies Snapshot de la destination ne sont pas écrasées par les copies Snapshot de la source :

    • Elles ne sont pas remplacées de la source vers la destination pendant les opérations, les mises à jour et les synchronisations standard

    • Ils ne sont pas supprimés pendant les opérations de pause.

    • Elles ne sont pas supprimées lors des opérations de bascule et resynchronisation. Lorsque vous configurez une relation de SVM Disaster à l'aide de la règle mirror-vault à l'aide de ONTAP 9.9.1 et versions ultérieures, la règle se comporte comme suit :

    • Les règles de copie Snapshot définies par l'utilisateur au niveau de la source ne sont pas copiées vers la destination.

    • Les règles de copie Snapshot définies par le système ne sont pas copiées vers la destination.

    • L'association de volumes aux règles Snapshot définies par l'utilisateur et par le système ne sont pas copiées vers la destination.
      SVM.

  • Depuis ONTAP 9.2, la réplication unifiée SnapMirror, dans laquelle la destination est configurée pour la reprise après incident et la conservation à long terme.

Vous trouverez des détails sur ces types de relations ici : "Présentation de la réplication de volume SnapMirror".

Le policy type de la règle de réplication détermine le type de relation qu'elle prend en charge. Le tableau suivant présente les types de politiques disponibles.

Type de règle

Type de relation

mise en miroir asynchrone

Reprise sur incident SnapMirror

coffre-fort

Réplication unifiée

XDP remplace DP en tant que valeur par défaut de réplication SVM dans ONTAP 9.4

Depuis ONTAP 9.4, les relations de protection des données du SVM sont définies par défaut en mode XDP Les relations de protection des données de SVM continuent à être par défaut en mode DP dans ONTAP 9.3 et versions antérieures.

Les relations existantes ne sont pas affectées par la nouvelle valeur par défaut. Si une relation est déjà de type DP, elle continuera d'être de type DP. Le tableau suivant montre le comportement auquel vous pouvez vous attendre.

Si vous spécifiez…​

Le type est…​

La stratégie par défaut (si vous ne spécifiez pas de règle) est…​

DP

XDP

MirrorAllsnapshots (reprise après incident SnapMirror)

Rien

XDP

MirrorAllsnapshots (reprise après incident SnapMirror)

XDP

XDP

MirrorAndVault (réplication unifiée)

Vous trouverez ici des informations sur les modifications apportées par défaut : "XDP remplace DP par défaut SnapMirror".

Remarque

L'indépendance de version n'est pas prise en charge pour la réplication des SVM. En configuration de reprise d'activité d'un SVM, le SVM de destination doit se trouver sur un cluster exécutant la même version ONTAP que le cluster SVM source pour prendre en charge les opérations de basculement et de retour arrière.

"Compatibilité des versions ONTAP pour les relations SnapMirror"

Réplication des configurations SVM

Le contenu d'une relation de réplication SVM est déterminé par l'interaction des champs suivants :

  • Le -identity-preserve true de la snapmirror create La commande réplique l'ensemble de la configuration du SVM.

    Le -identity-preserve false Option réplique uniquement les volumes et les configurations d'authentification et d'autorisation du SVM, ainsi que les paramètres de protocole et de service de nom répertoriés dans "Configurations répliquées dans des relations SVM DR".

  • Le -discard-configs network de la snapmirror policy create La commande n'exclut pas les LIFs et les paramètres réseau associés de la réplication SVM, pour les cas où les SVM source et de destination se trouvent dans différents sous-réseaux.

  • Le -vserver-dr-protection unprotected de la volume modify La commande exclut le volume spécifié de la réplication SVM.

Sinon, la réplication SVM est quasiment identique à la réplication de volume. Vous pouvez utiliser quasiment le même workflow pour la réplication SVM que celui utilisé pour la réplication de volume.

Détails du support

Le tableau suivant présente les détails de prise en charge de la réplication de SVM SnapMirror.

Ressource ou fonctionnalité

Détails du support

Types de déploiement

  • D'une source unique vers une destination unique

  • Depuis la version ONTAP 9.4, « Fan-Out ». Vous ne pouvez effectuer un « fan-out » que vers deux destinations.

    Par défaut, une seule relation -Identity-preserve true est autorisée par SVM source.

Types de relations

  • Reprise sur incident SnapMirror

  • La réplication unifiée SnapMirror est à partir de ONTAP 9.2

Étendue de la réplication

Intercluster uniquement. Vous ne pouvez pas répliquer de SVM au sein du même cluster.

Protection autonome contre les ransomwares

Prise en charge asynchrone des groupes de cohérence

Depuis la version ONTAP 9.14.1, un maximum de 32 relations de reprise d'activité SVM sont prises en charge lorsque des groupes de cohérence existent. Voir "Protéger un groupe de cohérence" et "Limites des groupes de cohérence" pour en savoir plus.

FabricPool

Depuis ONTAP 9.6, la réplication des SVM SnapMirror est prise en charge par FabricPool.

MetroCluster

Depuis la version ONTAP 9.11.1, les deux côtés d'une relation de reprise d'activité de SVM dans une configuration MetroCluster peuvent servir de source pour des configurations supplémentaires de reprise d'activité de SVM.

Depuis ONTAP 9.5, la réplication de SnapMirror SVM est prise en charge dans les configurations MetroCluster.

  • Dans les versions antérieures à ONTAP 9.10.X, une configuration MetroCluster ne peut pas être la destination d'une relation de SVM DR.

  • Dans ONTAP 9.10.1 et versions ultérieures, une configuration MetroCluster peut faire l'objet d'une relation de reprise d'activité de SVM à des fins de migration uniquement et elle doit répondre à toutes les exigences nécessaires décrites dans "Tr-4966 : migration d'une SVM vers une solution MetroCluster".

  • Seul un SVM actif au sein d'une configuration MetroCluster peut être à l'origine d'une relation de reprise d'activité de SVM.

    Une source peut être un SVM source synchrone avant le basculement ou un SVM de destination synchrone après le basculement.

  • Lorsqu'une configuration MetroCluster est dans un état stable, le SVM MetroCluster destination ne peut pas être à l'origine d'une relation de reprise d'activité SVM, car les volumes ne sont pas en ligne.

  • Lorsque le SVM source est la source d'une relation de SVM DR, les informations de la relation de SVM DR source sont répliquées vers le partenaire MetroCluster.

  • Lors des processus de basculement et de rétablissement, la réplication vers la destination de reprise d'activité du SVM peut échouer.

    Cependant, une fois le processus de basculement ou de rétablissement terminé, les mises à jour planifiées de reprise d'activité du SVM suivant réussiront.

Groupe de cohérence

Pris en charge à partir de ONTAP 9.14.1. Pour plus d'informations, voir Protéger un groupe de cohérence.

ONTAP S3

Non pris en charge avec la reprise d'activité SVM.

SnapMirror synchrone

Non pris en charge avec la reprise d'activité SVM.

Indépendance des versions

Non pris en charge.

Chiffrement de volume

  • Les volumes chiffrés de la source sont chiffrés sur la destination.

  • Les serveurs KMIP ou Key Manager intégrés doivent être configurés sur le système de destination.

  • De nouvelles clés de chiffrement sont générées au niveau de la destination.

  • Si la destination ne contient pas de noeud qui prend en charge le cryptage de volume, la réplication réussit, mais les volumes de destination ne sont pas chiffrés.

Configurations répliquées dans des relations SVM DR

Le tableau suivant montre l'interaction du snapmirror create -identity-preserve et le snapmirror policy create -discard-configs network option :

Réplication de la configuration

‑identity‑preserve true

‑identity‑preserve false

Police sans -discard-configs network réglage

Police avec -discard-configs network réglage

Le réseau

LIF NAS

Oui.

Non

Non

Configuration Kerberos de la LIF

Oui.

Non

Non

LIF SAN

Non

Non

Non

Politiques de pare-feu

Oui.

Oui.

Non

Stratégies de service

Oui.

Oui.

Non

Itinéraires

Oui.

Non

Non

Broadcast-Domain

Non

Non

Non

Sous-réseau

Non

Non

Non

IPspace

Non

Non

Non

PME

Serveur SMB

Oui.

Oui.

Non

Groupes locaux et utilisateur local

Oui.

Oui.

Oui.

Privilège

Oui.

Oui.

Oui.

Copie en double

Oui.

Oui.

Oui.

BranchCache

Oui.

Oui.

Oui.

Options du serveur

Oui.

Oui.

Oui.

Sécurité des serveurs

Oui.

Oui.

Non

Répertoire personnel, partager

Oui.

Oui.

Oui.

Symlink

Oui.

Oui.

Oui.

Politique de FPolicy, politique de FSecurity et NTFS de FSecurity

Oui.

Oui.

Oui.

Mapping de noms et de groupes

Oui.

Oui.

Oui.

Informations d'audit

Oui.

Oui.

Oui.

NFS

Export-policies

Oui.

Oui.

Non

Règles des export-policy

Oui.

Oui.

Non

Serveur NFS

Oui.

Oui.

Non

RBAC

Certificats de sécurité

Oui.

Oui.

Non

Configuration de l'utilisateur de connexion, de la clé publique, du rôle et du rôle

Oui.

Oui.

Oui.

SSL

Oui.

Oui.

Non

Nommer les services

Hôtes DNS et DNS

Oui.

Oui.

Non

Utilisateur UNIX et groupe UNIX

Oui.

Oui.

Oui.

Domaine Kerberos et blocs de clés Kerberos

Oui.

Oui.

Non

Client LDAP et LDAP

Oui.

Oui.

Non

Groupe réseau

Oui.

Oui.

Non

NIS

Oui.

Oui.

Non

Accès Web et Web

Oui.

Oui.

Non

Volumétrie

Objet

Oui.

Oui.

Oui.

Les copies Snapshot, la règle Snapshot et la règle de suppression automatique

Oui.

Oui.

Oui.

Règle d'efficacité

Oui.

Oui.

Oui.

Règle des quotas et règle de politique des quotas

Oui.

Oui.

Oui.

File d'attente de récupération

Oui.

Oui.

Oui.

Volume racine

Espace de noms

Oui.

Oui.

Oui.

Données utilisateur

Non

Non

Non

Qtrees

Non

Non

Non

Quotas

Non

Non

Non

QoS au niveau des fichiers

Non

Non

Non

Attributs : état du volume racine, garantie d'espace, taille, taille automatique et nombre total de fichiers

Non

Non

Non

QoS du stockage

Groupe de règles de QoS

Oui.

Oui.

Oui.

Fibre Channel (FC)

Non

Non

Non

ISCSI

Non

Non

Non

LUN

Objet

Oui.

Oui.

Oui.

igroups

Non

Non

Non

ensembles de ports

Non

Non

Non

Numéros de série

Non

Non

Non

SNMP

v3 utilisateurs

Oui.

Limites du stockage de reprise d'activité SVM

Le tableau ci-dessous présente le nombre maximal recommandé de volumes et de relations de reprise d'activité SVM pris en charge par objet de stockage. Notez que les limites dépendent souvent de la plateforme. Reportez-vous à la "Hardware Universe" pour connaître les limites de votre configuration spécifique.

Objet de stockage

Limite

SVM

300 volumes flexibles

Paire HA

1,000 volumes flexibles

Cluster

128 relations SVM DR