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
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 zur Konfiguration der Grid-übergreifenden 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 Federation connection verwenden hat, um eine oder mehrere zu verwenden "Netzverbundverbindungen", Ein Mandantenbenutzer mit Root-Zugriffsberechtigung kann identische Buckets in den entsprechenden Mandantenkonten in jedem Grid erstellen. Diese Buckets:

  • Muss denselben Namen und dieselbe Region haben

  • Versionierung muss aktiviert sein

  • S3-Objektsperre muss deaktiviert 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

Die Grid-übergreifende Replizierung kann so konfiguriert werden, dass sie in eine Richtung oder in beide Richtungen erfolgt.

Replikation in eine Richtung

Wenn Sie die Grid-übergreifende Replizierung für einen Bucket nur in einem Grid aktivieren, werden die diesem Bucket (Quell-Bucket) hinzugefügten Objekte in den entsprechenden Bucket auf dem anderen Grid (dem Ziel-Bucket) repliziert. Zum Ziel-Bucket hinzugefügte Objekte werden jedoch nicht zurück in die Quelle repliziert. In der Abbildung ist die Grid-übergreifende Replizierung für aktiviert my-bucket Von Raster 1 bis Raster 2, aber nicht in die andere Richtung 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 aktiviert my-bucket In beide Richtungen.

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 durch Ausgabe einer GET Object- oder HEAD Object-Anforderung überprüfen. Die Antwort bezieht sich auf ein StorageGRID-spezifisches x-ntap-sg-cgr-replication-status Antwortheader, der einen der folgenden Werte hat: Der S3-Client kann den Replikationsstatus eines Objekts überprüfen, indem er eine GET Object- oder HEAD Object-Anforderung ausgibt. Die Antwort bezieht sich auf ein StorageGRID-spezifisches x-ntap-sg-cgr-replication-status Antwortheader, der einen der folgenden Werte enthält:

    Raster Replikationsstatus

    Quelle

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

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

    • FAILURE: Die Replikation steht nicht für eine Netzverbindung aus und mindestens eine ist mit einem dauerhaften Fehler ausgefallen. Ein Benutzer muss den Fehler beheben.

    Ziel

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

  2. StorageGRID verwendet die aktiven ILM-Richtlinien der einzelnen Grids für das Management der Objekte 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", StorageGRID kann ein Objekt aus einem der folgenden Gründe löschen:

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

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

  • 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öschanfrage ausstellt, 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 wirkt, als ob das Objekt gelöscht wurde:

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

    • Eine GET-Anforderung mit einer gültigen Versions-ID wird erfolgreich ausgeführt und die angeforderte Objektversion zurückgegeben.

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 optional die Löschmarkierung replizieren, je nachdem, wie die Grid-übergreifende Replizierung 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 Löschmarkierungen nicht replizieren möchten, wird dem Quell-Bucket eine Löschmarkierung hinzugefügt, aber nicht zum Ziel-Bucket repliziert. Objekte, die im Quellraster gelöscht werden, werden im Zielraster nicht gelöscht.

In der Abbildung wurde replicate delete Markers auf Yes gesetzt, wenn "Die Grid-übergreifende Replizierung wurde aktiviert". Löschanforderungen für den Quell-Bucket, der eine Versions-ID enthält, löschen keine Objekte aus dem Ziel-Bucket. Löschanforderungen für den Quell-Bucket, die keine Versions-ID enthalten, werden angezeigt, um Objekte im Ziel-Bucket zu löschen.

Abbildung zeigt, wie der Replikate-Client auf beiden Rastern gelöscht wird

Hinweis Wenn Sie Objektlöschungen zwischen den Rastern synchron halten möchten, erstellen Sie entsprechende "S3 Lifecycle-Konfigurationen" Für die Eimer auf beiden Rastern.

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 die x-amz-server-side-encryption Kopfzeile anfordern und angeben AES256. Siehe "Serverseitige Verschlüsselung".

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

Um die Standardverschlüsselung für einen Bucket zu verwenden, verwenden Sie eine PUT-Bucket-Verschlüsselungsanforderung und legen Sie die fest SSEAlgorithm Parameter an AES256. Die Verschlüsselung auf Bucket-Ebene gilt für alle Objekte, die ohne den aufgenommen wurden x-amz-server-side-encryption Kopfzeile der Anfrage. 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 aufgenommen werden x-amz-server-side-encryption Kopfzeile der Anfrage. Siehe "Konfigurieren Sie Netzwerk- und Objektoptionen".

Hinweis SSE unterstützt AES-128 nicht. Wenn die Option Stored Object Encryption 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 Verschlüsselungseinstellung für den Standard-Bucket oder die Grid-Ebene des Ziels, sofern verfügbar.

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

  1. Verwenden Sie die x-amz-server-side-encryption Aufnahme-Header, falls vorhanden.

  2. Wenn kein Ingest Header vorhanden ist, verwenden Sie gegebenenfalls die Standardeinstellung für die Bucket-Verschlüsselung.

  3. Wenn keine Bucket-Einstellung konfiguriert ist, verwenden Sie, sofern konfiguriert, die Verschlüsselungseinstellung für das gesamte Grid.

  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 wird, verwenden Sie, sofern konfiguriert, die Standardeinstellung für die Verschlüsselung des Ziel-Buckets.

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

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

PUT Objekt-Tagging und DELETE Objekt-Tagging werden nicht unterstützt

PUT-Anforderungen für Objekt-Tagging und DELETE Objekt-Tagging werden nicht für Objekte in Buckets unterstützt, für die die Grid-übergreifende Replizierung aktiviert ist.

Wenn ein S3-Client eine PUT-Objekt-Tagging- oder DELETE Objekt-Tagging-Anfrage ausstellt, 501 Not Implemented Wird zurückgegeben. Die Meldung lautet Put(Delete) ObjectTagging is not available for buckets that have cross-grid replication configured.

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 Grids 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. Sie wird auch als zwei 1-GB-Segmente in das Zielraster repliziert, obwohl die maximale Segmentgröße dieses Grids 50 MB beträgt.