Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Erfahren Sie mehr über die ONTAP SnapMirror SVM-Replizierung

Beitragende netapp-lenida netapp-aaron-holt netapp-aherbin netapp-ahibbard netapp-barbe netapp-dbagwell johnlantz netapp-thomi
PDFs

Mit SnapMirror können Sie eine Datensicherungsbeziehung zwischen SVMs erstellen. In dieser Art der Datensicherungsbeziehung wird die gesamte Konfiguration oder Teile der SVM, von NFS-Exporten und SMB-Freigaben bis hin zur rollenbasierten Zugriffssteuerung, repliziert sowie die Daten in den Volumes, die die SVM besitzt.

Unterstützte Beziehungstypen

Es können nur SVMs mit Datenbereitungsdaten repliziert werden. Die folgenden Typen von Datensicherungsbeziehungen werden unterstützt:

  • SnapMirror DR, in dem das Ziel normalerweise nur die Snapshots enthält, die derzeit auf der Quelle vorhanden sind.

    Ab ONTAP 9.9 ändert sich dieses Verhalten, wenn Sie die Mirror-Vault-Richtlinie verwenden. Ab ONTAP 9.9 können Sie verschiedene Snapshot-Richtlinien auf der Quelle und dem Ziel erstellen. Die Snapshots auf dem Ziel werden dabei nicht durch Snapshots auf der Quelle überschrieben:

    • Sie werden während normaler geplanter Vorgänge, Updates und Neusynchronisierung nicht vom Quell- zum Ziel überschrieben

    • Sie werden während der Pausen nicht gelöscht.

    • Sie werden während der Flip-Resynchronisierung nicht gelöscht. Wenn Sie eine SVM-Disaster-Beziehung mithilfe der Mirror-Vault-Richtlinie über ONTAP 9.9.1 und höher konfigurieren, verhält sich die Richtlinie wie folgt:

    • Benutzerdefinierte Snapshot-Richtlinien an der Quelle werden nicht auf das Ziel kopiert.

    • Systemdefinierte Snapshot-Richtlinien werden nicht auf das Ziel kopiert.

    • Die Volume-Zuordnung zu Benutzer- und systemdefinierten Snapshot-Richtlinien wird nicht auf das Ziel kopiert. + SVM.

  • SnapMirror Unified Replication, bei der das Ziel sowohl für DR als auch für die langfristige Aufbewahrung konfiguriert ist.

Weitere Informationen zur einheitlichen Replikation von SnapMirror finden Sie unter "Grundlagen der SnapMirror Unified Replication".

Der Typ_Policy_ der Replikationsrichtlinie bestimmt die Art der von ihr unterstützten Beziehung. In der folgenden Tabelle sind die verfügbaren Richtlinientypen aufgeführt.

Richtlinientyp

Beziehungstyp

Asynchrone Spiegelung

SnapMirror DR

Mirror-Vault

Einheitliche Replizierung

XDP ersetzt DP als Standardvorgabe für die SVM-Replizierung in ONTAP 9.4

Seit ONTAP 9.4 ist bei den SVM-Datensicherungsbeziehungen standardmäßig der XDP-Modus aktiviert. Beziehungen für die SVM-Datensicherung setzen weiterhin in ONTAP 9.3 und früher den DP-Modus ein.

Vorhandene Beziehungen werden vom XDP-Standard nicht beeinflusst. Wenn bereits eine Beziehung vom Typ DP verwendet wird, ist diese weiterhin vom Typ DP. Die folgende Tabelle zeigt das Verhalten, das Sie erwarten können.

Wenn Sie angeben…​

Der Typ ist…​

Die Standardrichtlinie (wenn Sie keine Richtlinie angeben) lautet…​

DATENSICHERUNG

XDP

MirrorAllSnapshots (SnapMirror DR)

Nichts

XDP

MirrorAllSnapshots (SnapMirror DR)

XDP

XDP

MirrorAndVault (einheitliche Replizierung)

Informationen zum Konvertieren von DP-Beziehungen in XDP-Beziehungen und andere Details finden Sie hier: "Konvertieren einer vorhandenen ONTAP-DP-Beziehung in XDP".

Hinweis

Die Versionsunabhängigkeit wird bei der SVM-Replizierung nicht unterstützt. Bei einer SVM-Konfiguration für Disaster Recovery muss sich die Ziel-SVM auf einem Cluster befinden, auf dem dieselbe ONTAP-Version wie das SVM-Quell-Cluster ausgeführt wird, um Failover- und Failback-Vorgänge zu unterstützen.

"Kompatible ONTAP Versionen für SnapMirror Beziehungen"

Replizierung von SVM-Konfigurationen

Der Inhalt einer SVM-Replizierungsbeziehung wird durch die Interaktion der folgenden Felder bestimmt:

  • Mit der -identity-preserve true Option des snapmirror create Befehls wird die gesamte SVM-Konfiguration repliziert.

    Die -identity-preserve false Option repliziert nur die Volumes und Authentifizierungs- und Autorisierungskonfigurationen der SVM sowie die in aufgeführten Protokoll- und Namensservice-Einstellungen"Konfigurationen, die in SVM-Disaster-Recovery-Beziehungen repliziert werden".

  • -discard-configs network`Bei der Option des `snapmirror policy create Befehls sind LIFs und zugehörige Netzwerkeinstellungen von der SVM-Replizierung ausgeschlossen, und zwar für Anwendungsfälle, in denen sich Quell- und Ziel-SVMs in unterschiedlichen Subnetzen befinden.

  • Die -vserver-dr-protection unprotected Option des volume modify Befehls schließt das angegebene Volume von der SVM-Replikation aus.

Andernfalls ist die SVM-Replizierung nahezu identisch mit der Volume-Replizierung. Sie können nahezu denselben Workflow für die SVM-Replizierung einsetzen wie bei der Volume-Replizierung.

Support-Details

Die folgende Tabelle enthält Support-Details zur SnapMirror SVM-Replizierung.

Ressource oder Funktion

Support-Details

Bereitstellungstypen

  • Von einer einzelnen Quelle zu einem einzigen Ziel

  • Ab ONTAP 9.4 Fan-out: Sie können nur an zwei Zielorten Fan-out.

    Standardmäßig ist pro Quell-SVM nur eine -Identity-Preserve True Relationship zulässig.

Beziehungstypen

  • SnapMirror Disaster Recovery

  • Einheitliche SnapMirror -Replikation

Replizierungsumfang

Nur Intercluster. Sie können SVMs nicht in demselben Cluster replizieren.

Autonomer Schutz Durch Ransomware

Asynchrone Unterstützung von Konsistenzgruppen

Ab ONTAP 9.14.1 werden maximal 32 Disaster-Recovery-Beziehungen für SVMs unterstützt, wenn Konsistenzgruppen vorhanden sind. Weitere Informationen finden Sie unter "Sichern einer Konsistenzgruppe" und "Einschränkungen für Konsistenzgruppen" .

FabricPool

Ab ONTAP 9.6 wird die SnapMirror SVM-Replizierung mit FabricPool unterstützt. In einer SVM-DR-Beziehung müssen Quell- und Ziel-Volumes keine FabricPool-Aggregate verwenden, sondern sie müssen dieselbe Tiering-Richtlinie verwenden.

Ab ONTAP 9.12.1 wird die SnapMirror SVM Replizierung mit gemeinsamen FabricPool und FlexGroup Volumes unterstützt. Vor 9.12.1 konnten zwei dieser Funktionen miteinander kombiniert werden, aber nicht alle drei.

MetroCluster

Ab ONTAP 9.11.1 können beide Seiten der Disaster-Recovery-Beziehung einer SVM innerhalb einer MetroCluster Konfiguration als Quelle für zusätzliche SVM-Disaster-Recovery-Konfigurationen fungieren.

Ab ONTAP 9.5 wird die SnapMirror SVM-Replizierung auf MetroCluster Konfigurationen unterstützt.

  • Bei älteren Versionen als ONTAP 9.10.X kann eine MetroCluster-Konfiguration nicht Ziel einer SVM-Disaster-Recovery-Beziehung sein.

  • In Versionen ab ONTAP 9.10.1 kann eine MetroCluster-Konfiguration lediglich zu Migrationszwecken als Ziel einer SVM-Disaster-Recovery-Beziehung dienen. Zudem muss sie alle in beschriebenen Anforderungen erfüllen "TR-4966: Migration einer SVM in eine MetroCluster Lösung".

  • Nur eine aktive SVM innerhalb einer MetroCluster-Konfiguration kann als Quelle einer SVM Disaster-Recovery-Beziehung verwendet werden.

    Eine Quelle kann eine synchrone Quell-SVM vor der Umschaltung oder eine synchrone Ziel-SVM nach der Umschaltung sein.

  • Wenn eine MetroCluster-Konfiguration sich in einem stabilen Zustand befindet, kann die MetroCluster SVM, die synchrone Ziel-SVM, nicht als Quelle für eine SVM Disaster-Recovery-Beziehung dienen, da die Volumes nicht online sind.

  • Wenn die SVM für die synchrone Quelle die Quelle der SVM für die Disaster-Recovery-Beziehung ist, werden die SVM für die Quell-Disaster-Recovery-Beziehung zum MetroCluster-Partner repliziert.

  • Während der Umschaltungs- und Switchback-Prozesse schlägt die Replizierung auf das Disaster-Recovery-Ziel der SVM möglicherweise fehl.

    Nach Abschluss des Switchover- oder Switchback-Prozesses werden jedoch die nächsten geplanten Aktualisierungen für die SVM-Disaster Recovery erfolgreich durchgeführt.

Konsistenzgruppe

Unterstützt ab ONTAP 9.14.1. Weitere Informationen finden Sie unter Sichern einer Konsistenzgruppe.

ONTAP S3

Nicht unterstützt durch SVM Disaster Recovery.

SnapMirror Synchronous

Nicht unterstützt durch SVM Disaster Recovery.

Versionsunabhängigkeit

Nicht unterstützt.

Volume-Verschlüsselung

  • Verschlüsselte Volumes auf der Quelle werden auf dem Ziel verschlüsselt.

  • Onboard Key Manager oder KMIP-Server müssen auf dem Ziel konfiguriert sein.

  • Neue Verschlüsselungsschlüssel werden am Zielspeicherort generiert.

  • Wenn das Ziel keinen Knoten enthält, der Volume .Encryption unterstützt, ist die Replikation erfolgreich, aber die Ziel-Volumes sind nicht verschlüsselt.

Konfigurationen, die in SVM-Disaster-Recovery-Beziehungen repliziert werden

Die folgende Tabelle zeigt das Zusammenspiel zwischen der snapmirror create -identity-preserve Option und der snapmirror policy create -discard-configs network Option:

Konfiguration repliziert

‑identity‑preserve true

‑identity‑preserve false

Richtlinie ohne -discard-configs network Satz

Richtlinie mit -discard-configs network Set

Netzwerk

NAS-LIFs

Ja.

Nein

Nein

LIF-Kerberos-Konfiguration

Ja.

Nein

Nein

SAN LIFs

Nein

Nein

Nein

Firewallrichtlinien

Ja.

Ja.

Nein

Service-Richtlinien

Ja.

Ja.

Nein

Routen

Ja.

Nein

Nein

Broadcast-Domäne

Nein

Nein

Nein

Subnetz

Nein

Nein

Nein

IP-Bereich

Nein

Nein

Nein

SMB

SMB-Server

Ja.

Ja.

Nein

Lokale Gruppen und lokaler Benutzer

Ja.

Ja.

Ja.

Berechtigung

Ja.

Ja.

Ja.

Schattenkopie

Ja.

Ja.

Ja.

BranchCache

Ja.

Ja.

Ja.

Serveroptionen

Ja.

Ja.

Ja.

Serversicherheit

Ja.

Ja.

Nein

Home Directory damit füllt

Ja.

Ja.

Ja.

Symbolischer Link

Ja.

Ja.

Ja.

FPolicy, Fsicherheitsrichtlinie und Fsicherheitsrichtlinien NTFS

Ja.

Ja.

Ja.

Namenszuweisung und Gruppenzuordnung

Ja.

Ja.

Ja.

Audit-Informationen

Ja.

Ja.

Ja.

NFS

Exportrichtlinien

Ja.

Ja.

Nein

Exportrichtlinien

Ja.

Ja.

Nein

NFS-Server

Ja.

Ja.

Nein

RBAC

Sicherheitszertifikate

Ja.

Ja.

Nein

Benutzer anmelden, öffentlichen Schlüssel, Rolle und Rollenkonfiguration

Ja.

Ja.

Ja.

SSL

Ja.

Ja.

Nein

Name Services

DNS- und DNS-Hosts

Ja.

Ja.

Nein

UNIX-Benutzer und UNIX-Gruppe

Ja.

Ja.

Ja.

Kerberos-Bereich und Kerberos-Keyblockes

Ja.

Ja.

Nein

LDAP- und LDAP-Client

Ja.

Ja.

Nein

Netzgruppe

Ja.

Ja.

Nein

NIS

Ja.

Ja.

Nein

Web- und Webzugriff

Ja.

Ja.

Nein

Datenmenge

Objekt

Ja.

Ja.

Ja.

Snapshots und Snapshot-Richtlinie

Ja.

Ja.

Ja.

Richtlinie für automatisches Löschen

Nein

Nein

Nein

Effizienzrichtlinie

Ja.

Ja.

Ja.

Kontingentrichtlinie und Kontingentrichtlinie

Ja.

Ja.

Ja.

Wiederherstellungswarteschlange

Ja.

Ja.

Ja.

Root-Volume

Namespace

Ja.

Ja.

Ja.

Benutzerdaten

Nein

Nein

Nein

Qtrees

Nein

Nein

Nein

Kontingente

Nein

Nein

Nein

QoS auf Dateiebene

Nein

Nein

Nein

Attribute: Zustand des Root-Volumes, der Platzgarantie, der Größe, der Autosize und der Gesamtzahl der Dateien

Nein

Nein

Nein

Storage-QoS

QoS-Richtliniengruppe

Ja.

Ja.

Ja.

Fibre Channel (FC)

Nein

Nein

Nein

ISCSI

Nein

Nein

Nein

LUNs

Objekt

Ja.

Ja.

Ja.

igroups

Nein

Nein

Nein

Portsätze

Nein

Nein

Nein

Seriennummern

Nein

Nein

Nein

SNMP

v3-Benutzer

Ja.

Ja.

Grenzen des SVM Disaster Recovery Storage

Die folgende Tabelle zeigt die empfohlene maximale Anzahl an Volumes und SVM-Disaster-Recovery-Beziehungen, die pro Storage-Objekt unterstützt werden. Grenzen sollten häufig plattformabhängig sein. Weitere "Hardware Universe"Informationen zu den Einschränkungen für Ihre spezifische Konfiguration finden Sie im.

Storage Objekt

Grenze

SVM

300 flexible Volumes

HA-Paar

1,000 Flexible Volumes

Cluster

128 SVM-Disaster-Beziehungen
Verwandte Informationen