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.

Was ist Grid-übergreifende Replizierung?

Beitragende netapp-pcarriga netapp-lhalbert
PDFs

Grid-übergreifende Replizierung ist die automatische Replizierung von Objekten zwischen ausgewählten S3 Buckets in zwei StorageGRID-Systemen, die in einem verbunden sind"Netzverbundverbindung". "Konto-Klon" Ist für die Grid-übergreifende Replizierung erforderlich.

Workflow für Grid-übergreifende Replizierung

Das Workflow-Diagramm fasst die Schritte zum Konfigurieren der Cross-Grid-Replikation zwischen Buckets auf zwei Grids zusammen.

Workflow für Grid-übergreifende Replizierung

Anforderungen für die Grid-übergreifende Replizierung

Wenn ein Mandantenkonto die Berechtigung Grid-Föderationsverbindung verwenden hat, um eine oder mehrere"Netzverbundverbindungen" , ein Mandantenbenutzer mit Root-Zugriffsberechtigung kann Buckets in den entsprechenden Mandantenkonten auf jedem Raster erstellen. Diese Eimer:

  • Können unterschiedliche Namen haben

  • Kann verschiedene Regionen haben

  • Versionierung muss aktiviert sein

  • Muss leer sein

Nachdem beide Buckets erstellt wurden, kann die Grid-übergreifende Replizierung für einen oder beide Buckets konfiguriert werden.

Weitere Informationen .

"Grid-übergreifende Replizierung managen"

Funktionsweise der Grid-übergreifenden Replizierung

Sie können die Cross-Grid-Replikation so konfigurieren, dass sie in eine oder in beide Richtungen erfolgt.

Replikation in eine Richtung

Wenn Sie die Cross-Grid-Replikation für einen Bucket nur auf einem Grid aktivieren, werden die diesem Bucket (dem Quell-Bucket) hinzugefügten Objekte in den entsprechenden Bucket auf dem anderen Grid (dem Ziel-Bucket) repliziert. Dem Ziel-Bucket hinzugefügte Objekte werden jedoch nicht zurück zur Quelle repliziert. In der Abbildung ist die Cross-Grid-Replikation aktiviert für my-bucket von Raster 1 zu Raster 2, aber in die andere Richtung ist es nicht aktiviert.

Abbildung zeigt die Verbindung mit dem Grid Federation in eine Richtung

Replikation in beide Richtungen

Wenn Sie auf beiden Grids die Grid-übergreifende Replizierung für denselben Bucket aktivieren, werden die zu einem Bucket hinzugefügten Objekte in das andere Grid repliziert. In der Abbildung ist die Grid-übergreifende Replizierung für in beide Richtungen aktiviert my-bucket.

Bild zeigt Replikation in eine Richtung im Vergleich zur Replikation in beide Richtungen

Was passiert, wenn Objekte aufgenommen werden?

Wenn ein S3-Client einem Bucket ein Objekt hinzufügt, für das die Grid-übergreifende Replizierung aktiviert ist, geschieht Folgendes:

  1. StorageGRID repliziert das Objekt automatisch aus dem Quell-Bucket in den Ziel-Bucket. Die Dauer dieses Hintergrundreplizierungsvorgangs hängt von verschiedenen Faktoren ab, darunter von der Anzahl der weiteren ausstehenden Replikationsvorgänge.

    Der S3-Client kann den Replikationsstatus eines Objekts überprüfen, indem er eine GetObject- oder HeadObject-Anforderung ausgibt. Die Antwort enthält eine StorageGRID-spezifische x-ntap-sg-cgr-replication-status Antwortheader, der einen der folgenden Werte hat:

    Raster Replikationsstatus

    Quelle

    • ABGESCHLOSSEN: Die Replikation war für alle Grid-Verbindungen erfolgreich.

    • AUSSTEHEND: Das Objekt wurde nicht auf mindestens eine Grid-Verbindung repliziert.

    • FEHLER: Für keine Netzverbindung steht eine Replikation aus und mindestens eine ist mit einem dauerhaften Fehler fehlgeschlagen. Der Fehler muss von einem Benutzer behoben werden.

    Ziel

    REPLIKAT: Das Objekt wurde aus dem Quellraster repliziert.
    Hinweis StorageGRID unterstützt nicht die x-amz-replication-status Kopfzeile.

  2. StorageGRID verwendet die aktiven ILM-Richtlinien der einzelnen Grids für die Objektverwaltung, wie bei jedem anderen Objekt. Objekt A in Tabelle 1 kann beispielsweise als zwei replizierte Kopien gespeichert und für immer aufbewahrt werden, während die Kopie von Objekt A, das in Tabelle 2 repliziert wurde, unter Verwendung von 2+1 Erasure Coding gespeichert und nach drei Jahren gelöscht werden kann.

Was passiert, wenn Objekte gelöscht werden?

Wie in beschrieben"Löschen des Datenflusses", kann StorageGRID ein Objekt aus einem der folgenden Gründe löschen:

  • Der S3-Client stellt eine Löschanfrage aus.

  • Ein Tenant Manager-Benutzer wählt die "Löschen von Objekten in Bucket" Option zum Entfernen aller Objekte aus einem Bucket aus.

  • Der Bucket verfügt über eine Lebenszykluskonfiguration, die abläuft.

  • Der letzte Zeitraum in der ILM-Regel für das Objekt endet, und es sind keine weiteren Platzierungen angegeben.

Wenn StorageGRID ein Objekt aufgrund von Löschobjekten im Bucket-Betrieb, bis zum Ablauf des Bucket-Lebenszyklus oder bis zum Ablauf der ILM-Platzierung löscht, wird das replizierte Objekt niemals aus dem anderen Grid in einer Grid-Federation-Verbindung gelöscht. Löschmarkierungen, die durch S3-Client-Löschungen zum Quell-Bucket hinzugefügt wurden, können jedoch optional in den Ziel-Bucket repliziert werden.

Um nachzuvollziehen, was passiert, wenn ein S3-Client Objekte aus einem Bucket löscht, für den die Grid-übergreifende Replizierung aktiviert ist, überprüfen Sie wie S3-Clients Objekte aus Buckets löschen, für die Versionierung aktiviert ist:

  • Wenn ein S3-Client eine Löschanfrage mit einer Versions-ID ausstellt, wird diese Version des Objekts dauerhaft entfernt. Dem Bucket wurde keine Löschmarkierung hinzugefügt.

  • Wenn ein S3-Client eine Löschanforderung ausgibt, die keine Versions-ID enthält, löscht StorageGRID keine Objektversionen. Stattdessen wird dem Bucket eine Löschmarkierung hinzugefügt. Die Löschmarkierung bewirkt, dass StorageGRID so reagiert, als ob das Objekt gelöscht worden wäre:

    • Eine GetObject-Anforderung ohne Versions-ID schlägt fehl mit 404 No Object Found

    • Eine GetObject-Anforderung mit einer gültigen Versions-ID ist erfolgreich und gibt die angeforderte Objektversion zurück.

Wenn ein S3-Client ein Objekt aus einem Bucket löscht, für den die Grid-übergreifende Replizierung aktiviert ist, bestimmt StorageGRID, ob die Löschanforderung wie folgt auf das Ziel repliziert werden soll:

  • Wenn die Löschanforderung eine Versions-ID enthält, wird diese Objektversion dauerhaft aus dem Quellraster entfernt. StorageGRID repliziert jedoch keine Löschanforderungen, die eine Versions-ID enthalten, sodass dieselbe Objektversion nicht vom Ziel gelöscht wird.

  • Wenn die Löschanforderung keine Versions-ID enthält, kann StorageGRID die Löschmarkierung optional replizieren, je nachdem, wie die Cross-Grid-Replikation für den Bucket konfiguriert ist:

    • Wenn Sie Löschmarkierungen replizieren (Standard), wird dem Quell-Bucket eine Löschmarkierung hinzugefügt und zum Ziel-Bucket repliziert. In der Tat scheint das Objekt auf beiden Rastern gelöscht zu sein.

    • Wenn Sie sich gegen die Replikation von Löschmarkierungen entscheiden, wird dem Quell-Bucket eine Löschmarkierung hinzugefügt, diese wird jedoch nicht in den Ziel-Bucket repliziert. Tatsächlich werden Objekte, die im Quellraster gelöscht werden, nicht im Zielraster gelöscht.

In der Abbildung wurde Löschmarkierungen replizieren auf Ja gesetzt, als"Die Grid-übergreifende Replizierung wurde aktiviert" . Löschanforderungen für den Quell-Bucket, die eine Versions-ID enthalten, löschen keine Objekte aus dem Ziel-Bucket. Löschanforderungen für den Quell-Bucket, die keine Versions-ID enthalten, scheinen Objekte im Ziel-Bucket zu löschen.

Abbildung zeigt
Hinweis Wenn Sie die Objektlöschungen zwischen den Rastern synchronisieren möchten, erstellen Sie für die Planungsperioden auf beiden Rastern entsprechende Objekte"S3 Lifecycle-Konfigurationen".

Wie verschlüsselte Objekte repliziert werden

Wenn Sie Objekte zwischen Grids mithilfe von Grid-übergreifender Replizierung verschlüsseln, können Sie einzelne Objekte verschlüsseln, die standardmäßige Bucket-Verschlüsselung verwenden oder die Grid-weite Verschlüsselung konfigurieren. Sie können Standard-Bucket- oder Grid-Verschlüsselungseinstellungen vor oder nach der Grid-übergreifenden Replizierung für einen Bucket hinzufügen, ändern oder entfernen.

Um einzelne Objekte zu verschlüsseln, können Sie beim Hinzufügen der Objekte zum Quell-Bucket SSE (Server-seitige Verschlüsselung mit von StorageGRID gemanagten Schlüsseln) verwenden. Verwenden Sie den x-amz-server-side-encryption Anforderungskopf und geben Sie an AES256. Siehe "Serverseitige Verschlüsselung".

Hinweis Die Verwendung von SSE-C (serverseitige Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln) wird für die Cross-Grid-Replikation nicht unterstützt. Der Aufnahmevorgang schlägt fehl.

Um die Standardverschlüsselung für einen Bucket zu verwenden, verwenden Sie eine Anforderung von PutBucketEncryption und setzen Sie den SSEAlgorithm Parameter auf AES256. Die Verschlüsselung auf Bucket-Ebene gilt für alle Objekte, die ohne den Request-Header aufgenommen x-amz-server-side-encryption wurden. Siehe "Operationen auf Buckets".

Um die Verschlüsselung auf Grid-Ebene zu verwenden, setzen Sie die Option gespeicherte Objektverschlüsselung auf AES-256. Die Verschlüsselung auf Grid-Ebene gilt für alle Objekte, die nicht auf Bucket-Ebene verschlüsselt oder ohne Anforderungsheader aufgenommen x-amz-server-side-encryption werden. Siehe "Konfigurieren Sie Netzwerk- und Objektoptionen".

Hinweis SSE unterstützt AES-128 nicht. Wenn die Option Gespeicherte Objektverschlüsselung für das Quellraster mit der Option AES-128 aktiviert ist, wird die Verwendung des AES-128-Algorithmus nicht auf das replizierte Objekt übertragen. Stattdessen verwendet das replizierte Objekt die Standard-Bucket- oder Grid-Level-Verschlüsselungseinstellung des Ziels, sofern verfügbar.

Bei der Festlegung, wie Quellobjekte verschlüsselt werden, wendet StorageGRID folgende Regeln an:

  1. Verwenden Sie ggf. den x-amz-server-side-encryption Ingest Header.

  2. Wenn kein Ingest-Header vorhanden ist, verwenden Sie die Bucket-Standardverschlüsselungseinstellung, sofern konfiguriert.

  3. Wenn keine Bucket-Einstellung konfiguriert ist, verwenden Sie die gitterweite Verschlüsselungseinstellung, sofern konfiguriert.

  4. Wenn keine rasterweite Einstellung vorhanden ist, verschlüsseln Sie das Quellobjekt nicht.

Beim Bestimmen, wie replizierte Objekte verschlüsselt werden, wendet StorageGRID die folgenden Regeln in der folgenden Reihenfolge an:

  1. Verwenden Sie dieselbe Verschlüsselung wie das Quellobjekt, es sei denn, dieses Objekt verwendet AES-128-Verschlüsselung.

  2. Wenn das Quellobjekt nicht verschlüsselt ist oder AES-128 verwendet, verwenden Sie die Standardverschlüsselungseinstellung des Ziel-Buckets, sofern konfiguriert.

  3. Wenn der Ziel-Bucket keine Verschlüsselungseinstellung hat, verwenden Sie die gridweite Verschlüsselungseinstellung des Ziels, sofern konfiguriert.

  4. Wenn keine rasterweite Einstellung vorhanden ist, verschlüsseln Sie das Zielobjekt nicht.

Cross-Grid-Replikation mit S3 Object Lock

Sie können die Cross-Grid-Replikation zwischen StorageGRID Buckets mit aktivierter S3-Objektsperre unter den folgenden Umständen konfigurieren.

Wenn die S3-Objektsperre für den Quell-Bucket …​ ist. Und die S3-Objektsperre im Ziel-Bucket ist …

Ermöglicht

Ermöglicht

Deaktiviert

Ermöglicht

Wenn die S3-Objektsperre im Quell-Bucket aktiviert ist:

  • Die Objekte werden mit Aufbewahrungseinstellungen am Ziel in dieser Reihenfolge gesperrt:

    1. Die Aufbewahrungsheaderwerte des Quellobjekts für:

      x-amz-object-lock-mode

      x-amz-object-lock-retain-until-date

    2. Die Standardaufbewahrung des Quell-Buckets, falls festgelegt.

    3. Die Standardaufbewahrung des Ziel-Buckets, falls festgelegt.

    Die Standardaufbewahrung des Ziel-Buckets überschreibt nicht die vom Quellobjekt replizierten Aufbewahrungseinstellungen.

  • Sie können den Legal Hold-Status für das Zielobjekt festlegen, indem Sie x-amz-object-lock-legal-hold beim Hochladen des Objekts.

  • Ein Fehler tritt auf, wenn der Zielmandant oder -Bucket die S3-Objektsperreinstellungen des Quellobjekts nicht unterstützt. Siehe "Warnungen und Fehler bei der Cross-Grid-Replikation."

Wenn die S3-Objektsperre im Quell-Bucket deaktiviert ist:

  • Sie können die Standardaufbewahrung im Ziel-Bucket konfigurieren, um die S3 Object Lock-Aufbewahrungseinstellungen auf das Zielobjekt anzuwenden.

  • Das Zielobjekt kann keinen Legal Hold-Status festlegen.

PutObjectTagging und DeleteObjectTagging werden nicht unterstützt

PutObjectTagging- und DeleteObjectTagging-Anforderungen werden nicht für Objekte in Buckets unterstützt, für die die Grid-übergreifende Replikation aktiviert ist.

Wenn ein S3-Client eine PutObjectTagging- oder DeleteObjectTagging-Anforderung ausgibt, 501 Not Implemented wird zurückgegeben. Die Botschaft ist Put(Delete) ObjectTagging isn't available for buckets that have cross-grid replication configured .

PutObjectRetention und PutObjectLegalHold werden nicht unterstützt

PutObjectRetention- und PutObjectLegalHold-Anfragen werden für Objekte in Buckets, für die die Cross-Grid-Replikation aktiviert ist, nicht vollständig unterstützt.

Wenn ein S3-Client eine PutObjectRetention- oder PutObjectLegalHold-Anforderung ausgibt, werden die Einstellungen des Quellobjekts geändert, die Änderungen werden jedoch nicht auf das Ziel angewendet.

Wie segmentierte Objekte repliziert werden

Die maximale Segmentgröße des Quellrasters gilt für Objekte, die in das Zielraster repliziert werden. Wenn Objekte in ein anderes Raster repliziert werden, wird die Einstellung Maximale Segmentgröße (Konfiguration > System > Speicheroptionen) des Quellrasters auf beiden Rastern verwendet. Angenommen, die maximale Segmentgröße für das Quellraster beträgt 1 GB, während die maximale Segmentgröße des Zielrasters 50 MB beträgt. Wenn Sie ein 2-GB-Objekt in das Quellraster aufnehmen, wird dieses Objekt als zwei 1-GB-Segmente gespeichert. Es wird auch als zwei 1-GB-Segmente in das Zielraster repliziert, obwohl die maximale Segmentgröße dieses Rasters 50 MB beträgt.