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.

Vergleichen Sie Cross-Grid-Replikation und CloudMirror-Replikation

PDFs

Wenn Sie mit der Grid-Föderation beginnen, überprüfen Sie die Ähnlichkeiten und Unterschiede zwischen"Cross-Grid-Replikation" und die"StorageGRID CloudMirror-Replikationsdienst" .

Cross-Grid-Replikation CloudMirror-Replikationsdienst

Was ist der Hauptzweck?

Ein StorageGRID -System fungiert als Notfallwiederherstellungssystem. Objekte in einem Bucket können zwischen den Rastern in eine oder beide Richtungen repliziert werden.

Ermöglicht einem Mandanten, Objekte automatisch aus einem Bucket in StorageGRID (Quelle) in einen externen S3-Bucket (Ziel) zu replizieren.

Die CloudMirror-Replikation erstellt eine unabhängige Kopie eines Objekts in einer unabhängigen S3-Infrastruktur. Diese unabhängige Kopie wird nicht als Backup verwendet, sondern häufig in der Cloud weiterverarbeitet.

Wie ist es eingerichtet?

  1. Konfigurieren Sie eine Grid-Föderationsverbindung zwischen zwei Grids.

  2. Fügen Sie neue Mandantenkonten hinzu, die automatisch in das andere Raster geklont werden.

  3. Fügen Sie neue Mandantengruppen und Benutzer hinzu, die ebenfalls geklont werden.

  4. Erstellen Sie entsprechende Buckets auf jedem Grid und ermöglichen Sie die Cross-Grid-Replikation in eine oder beide Richtungen.

  1. Ein Mandantenbenutzer konfiguriert die CloudMirror-Replikation, indem er mithilfe des Mandantenmanagers oder der S3-API einen CloudMirror-Endpunkt (IP-Adresse, Anmeldeinformationen usw.) definiert.

  2. Jeder Bucket, der diesem Mandantenkonto gehört, kann so konfiguriert werden, dass er auf den CloudMirror-Endpunkt verweist.

Wer ist für die Einrichtung verantwortlich?

  • Ein Grid-Administrator konfiguriert die Verbindung und die Mandanten.

  • Mandantenbenutzer konfigurieren die Gruppen, Benutzer, Schlüssel und Buckets.

Normalerweise ein Mieterbenutzer.

Was ist das Ziel?

Ein entsprechender und identischer S3-Bucket auf dem anderen StorageGRID -System in der Grid-Föderationsverbindung.

  • Jede kompatible S3-Infrastruktur (einschließlich Amazon S3).

  • Google Cloud Platform (GCP)

Ist eine Objektversionierung erforderlich?

Ja, sowohl im Quell- als auch im Ziel-Bucket muss die Objektversionierung aktiviert sein.

Nein, die CloudMirror-Replikation unterstützt jede Kombination aus nicht versionierten und versionierten Buckets sowohl auf der Quelle als auch auf dem Ziel.

Was bewirkt, dass Objekte zum Ziel verschoben werden?

Objekte werden automatisch repliziert, wenn sie zu einem Bucket hinzugefügt werden, für den die Cross-Grid-Replikation aktiviert ist.

Objekte werden automatisch repliziert, wenn sie zu einem Bucket hinzugefügt werden, der mit einem CloudMirror-Endpunkt konfiguriert wurde. Objekte, die im Quell-Bucket vorhanden waren, bevor der Bucket mit dem CloudMirror-Endpunkt konfiguriert wurde, werden nicht repliziert, es sei denn, sie werden geändert.

Wie werden Objekte repliziert?

Bei der Cross-Grid-Replikation werden versionierte Objekte erstellt und die Versions-ID vom Quell-Bucket in den Ziel-Bucket repliziert. Dadurch kann die Versionsreihenfolge über beide Raster hinweg beibehalten werden.

Für die CloudMirror-Replikation sind keine Buckets mit aktivierter Versionierung erforderlich, daher kann CloudMirror nur die Reihenfolge für einen Schlüssel innerhalb einer Site aufrechterhalten. Es gibt keine Garantie dafür, dass die Reihenfolge bei Anfragen an ein Objekt an einem anderen Standort beibehalten wird.

Was passiert, wenn ein Objekt nicht repliziert werden kann?

Das Objekt wird zur Replikation in die Warteschlange gestellt und unterliegt den Speicherbeschränkungen für Metadaten.

Das Objekt wird zur Replikation in die Warteschlange gestellt, vorbehaltlich der Beschränkungen der Plattformdienste (siehe"Empfehlungen zur Nutzung von Plattformdiensten" ).

Werden die Systemmetadaten des Objekts repliziert?

Ja, wenn ein Objekt in das andere Raster repliziert wird, werden auch seine Systemmetadaten repliziert. Die Metadaten sind auf beiden Rastern identisch.

Nein, wenn ein Objekt in den externen Bucket repliziert wird, werden seine Systemmetadaten aktualisiert. Die Metadaten unterscheiden sich je nach Standort, abhängig vom Zeitpunkt der Aufnahme und dem Verhalten der unabhängigen S3-Infrastruktur.

Wie werden Objekte abgerufen?

Anwendungen können Objekte abrufen oder lesen, indem sie eine Anforderung an den Bucket in einem der Raster senden.

Anwendungen können Objekte abrufen oder lesen, indem sie eine Anfrage entweder an StorageGRID oder an das S3-Ziel senden. Angenommen, Sie verwenden die CloudMirror-Replikation, um Objekte in eine Partnerorganisation zu spiegeln. Der Partner kann seine eigenen Anwendungen verwenden, um Objekte direkt vom S3-Ziel zu lesen oder zu aktualisieren. Die Verwendung von StorageGRID ist nicht erforderlich.

Was passiert, wenn ein Objekt gelöscht wird?

  • Löschanforderungen, die eine Versions-ID enthalten, werden nie in das Zielraster repliziert.

  • Löschanforderungen ohne Versions-ID fügen dem Quell-Bucket eine Löschmarkierung hinzu, die optional in das Zielraster repliziert werden kann.

  • Wenn die Cross-Grid-Replikation nur für eine Richtung konfiguriert ist, können Objekte im Ziel-Bucket gelöscht werden, ohne dass dies Auswirkungen auf die Quelle hat.

Die Ergebnisse variieren je nach Versionsstatus der Quell- und Ziel-Buckets (die nicht identisch sein müssen):

  • Wenn beide Buckets versioniert sind, wird bei einer Löschanforderung an beiden Stellen eine Löschmarkierung hinzugefügt.

  • Wenn nur der Quell-Bucket versioniert ist, fügt eine Löschanforderung der Quelle, aber nicht dem Ziel eine Löschmarkierung hinzu.

  • Wenn keiner der Buckets versioniert ist, löscht eine Löschanforderung das Objekt aus der Quelle, aber nicht aus dem Ziel.

Ebenso können Objekte im Ziel-Bucket gelöscht werden, ohne dass dies Auswirkungen auf die Quelle hat.