Wie die Aufbewahrung von Objekten bestimmt wird
StorageGRID bietet sowohl Grid-Administratoren als auch einzelnen Mandantenbenutzer Optionen, um die Speicherdauer von Objekten festzulegen. Im Allgemeinen haben alle von einem Mandantenbenutzer bereitgestellten Aufbewahrungsanweisungen Vorrang vor den Aufbewahrungsanweisungen, die vom Grid-Administrator bereitgestellt werden.
Wie Mandantenbenutzer die Aufbewahrung von Objekten steuern
Mandantenbenutzer haben drei primäre Möglichkeiten, um zu steuern, wie lange ihre Objekte in StorageGRID gespeichert sind:
-
Wenn die globale S3-Objektsperreneinstellung für das Grid aktiviert ist, können Nutzer von S3-Mandanten Buckets erstellen, deren S3-Objektsperre aktiviert ist. Anschließend können sie über die S3-REST-API Aufbewahrungseinstellungen für jede zu diesem Bucket hinzugefügte Objektversion festlegen.
-
Eine Objektversion, die sich unter einer gesetzlichen Aufbewahrungspflichten befindet, kann nicht mit irgendeiner Methode gelöscht werden.
-
Bevor das Aufbewahrungsdatum einer Objektversion erreicht ist, kann diese Version nicht mit einer Methode gelöscht werden.
-
Objekte in Buckets mit aktivierter S3-Objektsperre werden durch ILM „
Forever
“ beibehalten. Nachdem jedoch eine Aufbewahrungsfrist erreicht ist, kann eine Objektversion durch eine Client-Anfrage oder den Ablauf des Bucket-Lebenszyklus gelöscht werden.
-
-
Benutzer von S3-Mandanten können ihren Buckets eine Lifecycle-Konfiguration hinzufügen, für die eine Ablaufaktion festgelegt ist. Wenn ein Bucket-Lebenszyklus vorhanden ist, speichert StorageGRID ein Objekt, bis das Datum oder die Anzahl der Tage, die im Verfallsvorgang angegeben sind, erreicht ist, es sei denn, der Client löscht das Objekt zuerst.
-
Ein S3- oder Swift-Client kann eine delete-Objektanforderung ausgeben. StorageGRID priorisiert Löschanfragen von Clients immer über den S3-Bucket-Lebenszyklus oder ILM, wenn sie bestimmen, ob ein Objekt gelöscht oder aufbewahrt werden soll.
Grid-Administratoren steuern die Objektaufbewahrung
Grid-Administratoren steuern mithilfe von ILM-Speicheranweisungen, wie lange Objekte gespeichert werden. Wenn Objekte mit einer ILM-Regel abgeglichen werden, speichert StorageGRID diese Objekte bis zum letzten Zeitraum der ILM-Regel verstrichen ist. Objekte werden unbefristet aufbewahrt, wenn „forever
“ für die Platzierungsanweisungen angegeben ist.
Unabhängig davon, wer die Aufbewahrung von Objekten steuert, steuern ILM-Einstellungen, welche Arten von Objektkopien (repliziert oder Erasure Coding) gespeichert werden und wo sich die Kopien befinden (Storage-Nodes, Cloud Storage Pools oder Archiv-Nodes).
Interaktion von S3-Bucket-Lebenszyklus und ILM
Die Aktion „Ablaufdatum“ in einem S3-Bucket-Lebenszyklus überschreibt immer die ILM-Einstellungen. Aus diesem Grund kann ein Objekt auch dann im Grid verbleiben, wenn ILM-Anweisungen zum Auflegen des Objekts verfallen sind.
Beispiele für die Aufbewahrung von Objekten
Die folgenden Beispiele sollten zur besseren Übersicht über die Interaktionen zwischen S3 Objektsperre, Bucket-Lebenszykluseinstellungen, Clientlöschanforderungen und ILM verwendet werden.
Beispiel 1: S3-Bucket-Lebenszyklus hält Objekte länger als ILM
- ILM
-
Speichern von zwei Kopien für 1 Jahr (365 Tage)
- Bucket-Lebenszyklus
-
Verfalle Objekte in 2 Jahren (730 Tage)
- Ergebnis
-
StorageGRID speichert das Objekt 730 Tage lang. StorageGRID verwendet die Bucket-Lifecycle-Einstellungen, um zu bestimmen, ob ein Objekt gelöscht oder aufbewahrt werden soll.
Wenn im Bucket-Lebenszyklus angegeben wird, dass Objekte länger aufbewahrt werden sollen als durch ILM angegeben, verwendet StorageGRID beim Bestimmen der Anzahl und des Typs der zu speichernden Kopien weiterhin die Anweisungen zur ILM-Platzierung. In diesem Beispiel werden zwei Kopien des Objekts von 366 bis 730 Tagen im StorageGRID gespeichert. |
Beispiel 2: S3-Bucket-Lebenszyklus läuft Objekte vor ILM ab
- ILM
-
Speichern von zwei Kopien für 2 Jahre (730 Tage)
- Bucket-Lebenszyklus
-
Verfalle Objekte in 1 Jahr (365 Tage)
- Ergebnis
-
StorageGRID löscht beide Kopien des Objekts nach Tag 365.
Beispiel 3: Beim Löschen von Clients wird der Bucket-Lebenszyklus und ILM überschrieben
- ILM
-
Speichern von zwei Kopien auf Storage-Nodes „
Forever
“ - Bucket-Lebenszyklus
-
Verfalle Objekte in 2 Jahren (730 Tage)
- Anforderung zum Löschen des Clients
-
Ausgestellt am 400. Tag
- Ergebnis
-
StorageGRID löscht beide Kopien des Objekts am Tag 400 als Antwort auf die Anforderung zum Löschen des Clients.
Beispiel 4: S3 Object Lock überschreibt die Anforderung zum Löschen des Clients
- S3-Objektsperre
-
Aufbewahrung bis zum Datum für eine Objektversion ist 2026-03-31. Eine gesetzliche Aufbewahrungspflichten sind nicht in Kraft.
- Kompatible ILM-Regel
-
Speichern Sie zwei Kopien auf Storage-Nodes „
Forever.
“ - Anforderung zum Löschen des Clients
-
Ausgestellt am 2024-03-31.
- Ergebnis
-
StorageGRID wird die Objektversion nicht löschen, da die Aufbewahrung bis zum Datum noch zwei Jahre entfernt ist.