Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Vergleichen Sie Grid-Replizierung und CloudMirror Replizierung

Beitragende

Überprüfen Sie während der Nutzung von Grid Federation die Ähnlichkeiten und Unterschiede zwischen "Grid-übergreifende Replizierung" Und das "StorageGRID CloudMirror Replikationsservice".

Grid-übergreifende Replizierung CloudMirror Replikationsservice

Was ist der primäre Zweck?

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

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

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

Wie ist es eingerichtet?

  1. Konfigurieren Sie eine Grid Federation-Verbindung zwischen zwei Grids.

  2. Fügen Sie neue Mandantenkonten hinzu, die automatisch in der anderen Tabelle geklont werden.

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

  4. Erstellen Sie entsprechende Buckets in jedem Grid und ermöglichen Sie die Grid-übergreifende Replizierung in eine oder beide Richtungen.

  1. Ein Mandantenbenutzer konfiguriert die CloudMirror-Replizierung mithilfe des Tenant Manager oder der S3-API durch Definition eines CloudMirror-Endpunkts (IP-Adresse, Anmeldeinformationen usw.).

  2. Jeder Bucket dieses Mandantenkontos kann so konfiguriert werden, dass er auf den CloudMirror-Endpunkt verweisen kann.

Wer ist für die Einrichtung zuständig?

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

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

Normalerweise wird ein Mandantenbenutzer verwendet.

Was ist das Ziel?

Ein entsprechender und identischer S3-Bucket auf dem anderen StorageGRID-System in der Grid-Federation-Verbindung.

  • Kompatible S3-Infrastruktur (einschließlich Amazon S3)

  • Google Cloud Platform (GCP)

Ist eine Objektversionierung erforderlich?

Ja, sowohl in den Quell- als auch in den Ziel-Buckets muss die Objektversionierung aktiviert sein.

Nein, die CloudMirror Replizierung unterstützt beliebige Kombinationen aus unversionierten und versionierten Buckets sowohl am Quell- als auch am Zielsystem.

Was bewirkt, dass Objekte zum Ziel verschoben werden?

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

Objekte werden automatisch repliziert, wenn sie zu einem Bucket hinzugefügt werden, der mit einem CloudMirror-Endpunkt konfiguriert wurde. Objekte, die sich im Quell-Bucket befanden, bevor der Bucket mit dem CloudMirror-Endpunkt konfiguriert wurde, werden nur repliziert, wenn sie geändert wurden.

Wie werden Objekte repliziert?

Grid-übergreifende Replizierung erstellt versionierte Objekte und repliziert die Versions-ID vom Quell-Bucket auf den Ziel-Bucket. Dadurch kann die Versionsreihenfolge über beide Raster hinweg beibehalten werden.

Bei der CloudMirror Replizierung sind keine Buckets mit Versionierung erforderlich – CloudMirror kann also nur die Bestellung für einen Schlüssel innerhalb eines Standorts aufrechterhalten. Es gibt keine Garantie, dass die Bestellung für Anfragen an ein Objekt an einem anderen Standort aufrechterhalten wird.

Was ist, wenn ein Objekt nicht repliziert werden kann?

Das Objekt befindet sich in der Warteschlange zur Replizierung, vorbehaltlich der Speichergrenzen für Metadaten.

Das Objekt wird zur Replikation in die Warteschlange eingereiht, vorbehaltlich der Beschränkungen für Plattformdienste (siehe "Empfehlungen für die Nutzung von Plattform-Services").

Werden die System-Metadaten des Objekts repliziert?

Ja, wenn ein Objekt in das andere Grid repliziert wird, werden auch die Systemmetadaten repliziert. Die Metadaten sind auf beiden Grids identisch.

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

Wie werden Objekte abgerufen?

Applikationen können Objekte abrufen oder lesen, indem sie an den Bucket auf beiden Grid eine Anfrage stellen.

Applikationen können Objekte abrufen oder lesen, indem sie eine Anfrage entweder an StorageGRID oder am S3-Ziel stellen. Angenommen, Sie verwenden CloudMirror Replizierung, um Objekte auf eine Partnerorganisation zu spiegeln. Der Partner kann mithilfe eigener Applikationen Objekte direkt vom S3-Ziel lesen oder 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, die keine Versions-ID enthalten, fügen dem Quell-Bucket eine Löschmarkierung hinzu, die optional in das Zielraster repliziert werden kann.

  • Wenn die Grid-übergreifende Replizierung nur für eine Richtung konfiguriert ist, können Objekte im Ziel-Bucket gelöscht werden, ohne die Quelle zu beeinträchtigen.

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 Standorten eine Löschmarkierung hinzugefügt.

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

  • Wenn kein Bucket versioniert ist, wird das Objekt durch eine Löschanforderung aus der Quelle, aber nicht aus dem Ziel gelöscht.

Ebenso können Objekte im Ziel-Bucket gelöscht werden, ohne dass die Quelle beeinträchtigt wird.