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.

SnapMirror S3 Übersicht

Beitragende
PDFs

Ab ONTAP 9.10.1 können Buckets in ONTAP S3 Objektspeichern mithilfe von SnapMirror Spiegelungs- und Backup-Funktion gesichert werden. Im Gegensatz zu Standard-SnapMirror ermöglicht SnapMirror S3 Spiegelung und Backups an nicht-NetApp-Ziele wie AWS S3.

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

Ziel Unterstützt aktive Spiegelungen und Takeover? Unterstützung für Backup und Restore?

ONTAP S3

  • Buckets in derselben SVM

  • Buckets in verschiedenen SVMs im selben 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 vorhandene Buckets auf ONTAP S3 Servern sichern oder neue Buckets erstellen, wobei die Datensicherung sofort aktiviert ist.

Anforderungen für SnapMirror S3

  • ONTAP-Version

    ONTAP 9.10.1 oder höher muss auf Quell- und Ziel-Clustern ausgeführt werden.

    Hinweis SnapMirror S3 wird in MetroCluster-Konfigurationen nicht unterstützt.

  • Lizenzierung

    Die folgenden Lizenzen sind in der "ONTAP One" Softwaresuite verfügbar, die auf den Quell- und Zielsystemen von ONTAP erforderlich sind, um Zugriff auf:

    • ONTAP S3 Protokoll und Storage

    • SnapMirror S3 als Ziel für andere NetApp Objektspeicher-Ziele (ONTAP S3, StorageGRID und Cloud Volumes ONTAP)

    • SnapMirror S3 für Objektspeicher von Drittanbietern, einschließlich AWS S3 (verfügbar im "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 Quell- und Ziel-SVMs ausführen.

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

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

      • Sie können ein selbstsigniertes CA-Zertifikat oder ein Zertifikat verwenden, das von einem externen CA-Anbieter signiert wurde.

      • Wenn die Quell- oder Ziel-Storage-VMs nicht HTTPS zuhören, ist es nicht erforderlich, CA-Zertifikate zu installieren.

  • Peering (für ONTAP S3 Ziele)

    • Intercluster LIFs müssen konfiguriert werden (für Remote ONTAP Ziele). Die Intercluster LIFs des Quell- und Ziel-Clusters können mit den S3-Daten-LIFs des Quell- und Ziel-Servers verbunden werden.

    • Quell- und Ziel-Cluster werden (für Remote-ONTAP-Ziele) per Peering durchgeführt.

    • Quell- und Ziel-Storage VMs werden (für alle ONTAP Ziele) Peered.

  • SnapMirror-Richtlinie

    • Eine S3-spezifische SnapMirror-Richtlinie ist für alle SnapMirror S3-Beziehungen erforderlich, Sie können jedoch für mehrere Beziehungen dieselbe Richtlinie verwenden.

    • Sie können Ihre eigene Richtlinie erstellen oder die standardmäßige Continuous-Richtlinie akzeptieren, die die folgenden Werte enthält:

      • Drosselklappe (oberer Grenzwert für Durchsatz/Bandbreite) – unbegrenzt.

      • Zeit für Recovery-Zeitpunkt: 1 Stunde (3600 Sekunden).

Hinweis Sie sollten beachten, dass wenn sich zwei S3-Buckets in einer SnapMirror Beziehung befinden und Lifecycle-Richtlinien so konfiguriert sind, dass die aktuelle Version eines Objekts abläuft (gelöscht wird), wird dieselbe Aktion auch in den Partner-Bucket repliziert. Dies gilt selbst dann, wenn der Partner-Bucket schreibgeschützt oder passiv ist.

  • Root-Benutzerschlüssel Storage VM Root-Benutzerzugriffsschlüssel sind für SnapMirror S3-Beziehungen erforderlich; ONTAP weist diese standardmäßig nicht zu. Wenn Sie zum ersten Mal eine SnapMirror S3-Beziehung erstellen, müssen Sie überprüfen, ob die Schlüssel sowohl auf Quell- als auch auf den Ziel-Storage-VMs vorhanden sind, und sie erneut erstellen, wenn dies nicht der Fall ist. Wenn Sie sie neu generieren müssen, müssen Sie sicherstellen, dass alle Clients und alle SnapMirror Objektspeicher-Konfigurationen unter Verwendung des Zugriffs- und geheimen Schlüsselpaars mit den neuen Schlüsseln aktualisiert werden.

Informationen zur S3-Serverkonfiguration finden Sie unter den folgenden Themen:

Informationen über Cluster und Storage VM Peering finden Sie unter folgendem Thema:

Unterstützte SnapMirror Beziehungen

SnapMirror S3 unterstützt Fan-out- und Kaskadenbeziehungen. Eine Übersicht finden Sie unter"Fan-out- und kaskadierende Datensicherungsimplementierungen".

SnapMirror S3 unterstützt keine Fan-in-Implementierungen (Datensicherungsbeziehungen zwischen mehreren Quell-Buckets und einem einzelnen Ziel-Bucket). SnapMirror S3 kann mehrere Bucket-Spiegelungen von mehreren Clustern auf ein einzelnes sekundäres Cluster unterstützen, aber jeder Quell-Bucket muss auf dem sekundären Cluster über einen eigenen Ziel-Bucket verfügen.

Steuerung des Zugriffs auf S3 Buckets

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

Obwohl SnapMirror S3 Objekte aus dem Quell-Bucket auf einen Ziel-Bucket repliziert, werden Gruppen- und Bucket-Richtlinien nicht aus dem Quell-Objektspeicher auf den Ziel-Objektspeicher repliziert.

Benutzer, Gruppenrichtlinien, Berechtigungen und ähnliche Komponenten müssen auf dem Ziel-Objektspeicher konfiguriert werden, damit Clients bei einem Failover auf den Ziel-Bucket zugreifen können.

Weitere Informationen finden Sie in den folgenden Themen:

S3 Objektsperre und Versionierung mit SnapMirror S3 verwenden

Sie können SnapMirror S3 für Objektsperre und Versionierung von aktivierten ONTAP Buckets verwenden. Es gibt einige Überlegungen:

  • Um einen Quell-Bucket mit aktivierter Objektsperre zu replizieren, muss für den Ziel-Bucket auch die Objektsperre aktiviert sein. Darüber hinaus muss sowohl für die Quelle als auch für das Ziel die Versionierung aktiviert sein. Dadurch werden Probleme beim Spiegeln von Löschungen zum Ziel-Bucket vermieden, wenn beide Buckets über unterschiedliche standardmäßige Aufbewahrungsrichtlinien verfügen.

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

Werden Objekte, für die ein Objekt gesperrt ist, auf einen Ziel-Bucket gespiegelt, bleibt die ursprüngliche Aufbewahrungszeit erhalten. Wenn entsperrte Objekte repliziert werden, übernehmen sie den Standardaufbewahrungszeitraum 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 auf Bucket B repliziert wurden, behalten ihre 30-tägige Aufbewahrungsfrist bei, obwohl sie kleiner als die Standardaufbewahrungsfrist von Bucket B ist

  • Bucket A verfügt nicht über eine Standardaufbewahrungsdauer und Bucket B hat eine Standardaufbewahrungsdauer von 60 Tagen. Wenn entsperrte Objekte von Bucket A auf Bucket B repliziert werden, übernehmen sie die 60-Tage-Aufbewahrungsfrist. Wenn ein Objekt manuell in Bucket A gesperrt wird, behält es beim Replizieren in Bucket B seinen ursprünglichen Aufbewahrungszeitraum bei

  • Bucket A hat eine Standardaufbewahrungsdauer von 30 Tagen und Bucket B hat keine Standardaufbewahrungsdauer. Von Bucket A nach Bucket B replizierte Objekte behalten die Aufbewahrungsfrist von 30 Tagen bei.