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.

Informationen zu ONTAP SnapMirror S3

Beitragende netapp-lenida netapp-dbagwell netapp-aherbin netapp-forry netapp-bhouser netapp-ahibbard netapp-barbe netapp-mwallis netapp-mdavidson johnlantz
Änderungen vorschlagen
PDFs

Ab ONTAP 9.10.1 ist der Schutz von Buckets in ONTAP S3 Objektspeichern mithilfe der SnapMirror Spiegelungs- und Sicherungsfunktionen möglich. Im Gegensatz zum Standard SnapMirror ermöglicht SnapMirror S3 die Spiegelung und Sicherung zu Nicht-NetApp-Zielen wie AWS S3.

SnapMirror S3 unterstützt aktive Spiegelungen und Backup-Ebenen von ONTAP S3-Buckets zu den folgenden Zielen:

Ziel Unterstützt aktive Spiegel und Übernahme? Unterstützt Backup und Wiederherstellung?

ONTAP S3

  • Buckets in derselben SVM

  • Buckets in verschiedenen SVMs auf demselben Cluster

  • Buckets in SVMs auf verschiedenen Clustern

Ja

Ja

StorageGRID

Nein

Ja

AWS S3

Nein

Ja

Cloud Volumes ONTAP für Azure

Ja

Ja

Cloud Volumes ONTAP für AWS

Ja

Ja

Cloud Volumes ONTAP für Google Cloud

Ja

Ja

Sie können bestehende Buckets auf ONTAP S3 Servern schützen oder neue Buckets erstellen, bei denen die Datensicherung sofort aktiviert ist.

SnapMirror S3-Anforderungen

  • ONTAP Version

    Auf dem Quell- und dem Ziel-Cluster muss ONTAP 9.10.1 oder höher ausgeführt werden.

    Hinweis SnapMirror S3 wird auf MetroCluster Konfigurationen nicht unterstützt.

  • Lizenzierung

    Die folgenden Lizenzen sind in der "ONTAP One" Software-Suite verfügbar und werden auf ONTAP Quell- und Zielsystemen benötigt, um Zugriff zu ermöglichen:

    • ONTAP S3 Protokoll und Speicher

    • SnapMirror S3 zur Ansprache anderer NetApp Objektspeicher (ONTAP S3, StorageGRID und Cloud Volumes ONTAP)

    • SnapMirror S3 zur Ansprache von Objektspeichern von Drittanbietern, einschließlich AWS S3 (verfügbar in der "ONTAP One Kompatibilitätspaket")

    • Wenn auf Ihrem Cluster ONTAP 9.10.1 ausgeführt wird, ist ein "FabricPool Lizenz" erforderlich.

  • ONTAP S3

    • ONTAP S3-Server müssen auf Quell- und Ziel-SVMs ausgeführt werden.

    • Es wird empfohlen, aber nicht vorausgesetzt, dass CA-Zertifikate für den TLS-Zugriff auf Systemen installiert sind, die S3-Server hosten.

      • Die CA-Zertifikate, die zum Signieren der Zertifikate der S3-Server verwendet werden, müssen auf der Admin-Speicher-VM der Cluster installiert sein, die die S3-Server hosten.

      • Sie können ein selbstsigniertes CA-Zertifikat oder ein von einem externen CA-Anbieter signiertes Zertifikat verwenden.

      • Wenn die Quell- oder Ziel-Storage-VMs nicht auf HTTPS lauschen, ist die Installation von CA-Zertifikaten nicht erforderlich.

  • Peering (für ONTAP S3-Ziele)

    • Intercluster-LIFs müssen konfiguriert werden (für entfernte ONTAP Ziele), und die Intercluster-LIFs des Quell- und Ziel-Cluster können eine Verbindung zu den Daten-LIFs des Quell- und Ziel-S3-Server herstellen.

    • Quell- und Ziel-Cluster sind per Peering verbunden (für entfernte ONTAP Ziele).

    • Quell- und Ziel-Storage-VMs sind per Peering verbunden (für alle ONTAP Ziele).

  • SnapMirror Richtlinie

    • Eine S3-spezifische SnapMirror Richtlinie ist für alle SnapMirror S3-Beziehungen erforderlich, jedoch kann dieselbe Richtlinie für mehrere Beziehungen verwendet werden.

    • Sie können eine eigene Richtlinie erstellen oder die Standardrichtlinie Continuous akzeptieren, die die folgenden Werte enthält:

      • Drosselung (Obergrenze für Durchsatz/Bandbreite), unbegrenzt.

      • Zeit für Recovery Point Objective: 1 Stunde (3600 Sekunden).

Hinweis Es ist zu beachten, dass wenn zwei S3-Buckets in einer SnapMirror Beziehung stehen und Lebenszyklusrichtlinien so konfiguriert sind, dass die aktuelle Version eines Objekts abläuft (gelöscht wird), die gleiche Aktion auf den Partner-Bucket repliziert wird. Dies gilt auch, wenn der Partner-Bucket schreibgeschützt oder passiv ist.

  • Root-Benutzerzugriffsschlüssel für Storage-VMs sind für SnapMirror S3-Beziehungen erforderlich; ONTAP weist diese nicht standardmäßig zu. Beim erstmaligen Erstellen einer SnapMirror S3-Beziehung ist zu überprüfen, ob die Schlüssel sowohl auf der Quell- als auch auf der Ziel-Storage-VM vorhanden sind, und sie sind neu zu generieren, falls sie fehlen. Falls eine Neugenerierung erforderlich ist, muss sichergestellt werden, dass alle Clients und alle SnapMirror Objektspeicherkonfigurationen, die das Zugriffsschlüssel- und geheime Schlüsselpaar verwenden, mit den neuen Schlüsseln aktualisiert werden.

Informationen zur S3-Serverkonfiguration sind in den folgenden Abschnitten verfügbar:

Informationen zu Cluster- und Storage-VM-Peering sind im folgenden Thema verfügbar:

Unterstützte SnapMirror Beziehungen

SnapMirror S3 unterstützt Fan-Out- und Kaskadenbeziehungen. Eine Übersicht ist unter "Verzweigte und kaskadierte Datensicherungsbereitstellungen" zu finden.

SnapMirror S3 unterstützt keine Fan-In-Bereitstellungen (Datensicherungsbeziehungen zwischen mehreren Quell-Buckets und einem einzelnen Ziel-Bucket). SnapMirror S3 kann mehrere Bucket-Spiegelungen von mehreren Clustern auf einen einzelnen sekundären Cluster unterstützen, jedoch muss jeder Quell-Bucket einen eigenen Ziel-Bucket auf dem sekundären Cluster haben.

SnapMirror S3 wird in MetroCluster Umgebungen nicht unterstützt.

Zugriff auf S3-Buckets steuern

Beim Erstellen neuer Buckets können Sie den Zugriff durch das Erstellen von Benutzern und Gruppen steuern.

Obwohl SnapMirror S3 Objekte vom Quell-Bucket in einen Ziel-Bucket repliziert, werden Benutzer, Gruppen und Richtlinien nicht vom Quell-Objektspeicher in den Ziel-Objektspeicher repliziert.

Benutzer, Gruppenrichtlinien, Berechtigungen und ähnliche Komponenten müssen im Ziel-Objektspeicher konfiguriert werden, damit Clients während eines Failover-Ereignisses auf den Ziel-Bucket zugreifen können.

Quell- und Zielbenutzer können dieselben Zugriffs- und geheimen Schlüssel verwenden, sofern die Quellschlüssel bei der Erstellung des Benutzers im Ziel-Cluster manuell angegeben werden. Beispiel:

vserver object-store-server user create -vserver svm1 -user user1 -access-key "20-characters" -secret-key "40-characters"

Weitere Informationen sind in den folgenden Abschnitten zu finden:

S3 Object Lock und Versionierung mit SnapMirror S3

Sie können SnapMirror S3 auf ONTAP Buckets mit aktivierter Objektsperre und Versionsverwaltung verwenden, wobei einige Punkte zu beachten sind:

  • Um einen Quell-Bucket mit aktivierter Objektsperre zu replizieren, muss die Objektsperre auch im Ziel-Bucket aktiviert sein. Zusätzlich muss sowohl im Quell- als auch im Ziel-Bucket die Versionierung aktiviert sein. So werden Probleme beim Spiegeln von Löschvorgängen auf den Ziel-Bucket vermieden, wenn beide Buckets unterschiedliche Standard-Aufbewahrungsrichtlinien haben.

  • S3 SnapMirror repliziert keine historischen Versionen von Objekten. Nur die aktuelle Version eines Objekts wird repliziert.

Wenn Object Locked-Objekte in einen Ziel-Bucket gespiegelt werden, behalten sie ihre ursprüngliche Aufbewahrungsdauer bei. Wenn entsperrte Objekte repliziert werden, übernehmen sie die Standardaufbewahrungsdauer des Ziel-Buckets. Beispiel:

  • Bucket A hat eine Standardaufbewahrungsdauer von 30 Tagen und Bucket B hat eine Standardaufbewahrungsdauer von 60 Tagen. Objekte, die von Bucket A nach Bucket B repliziert werden, behalten ihre 30-tägige Aufbewahrungsdauer bei, auch wenn diese kürzer ist als die Standardaufbewahrungsdauer von Bucket B.

  • Bucket A hat keine Standardaufbewahrungsfrist und Bucket B hat eine Standardaufbewahrungsfrist von 60 Tagen. Wenn nicht gesperrte Objekte von Bucket A nach Bucket B repliziert werden, übernehmen sie die 60-tägige Aufbewahrungsfrist. Wenn ein Objekt in Bucket A manuell gesperrt wird, behält es beim Replizieren nach Bucket B seine ursprüngliche Aufbewahrungsfrist bei.

  • Bucket A hat eine standardmäßige Aufbewahrungsfrist von 30 Tagen und Bucket B hat keine standardmäßige Aufbewahrungsfrist. Objekte, die von Bucket A nach Bucket B repliziert werden, behalten ihre 30-tägige Aufbewahrungsfrist bei.