Verwaltung des Objektlebenszyklus

Zu den Beispielen

Über die Verwaltung des Objektlebenszyklus unterstützt Cloud Storage gängige Anwendungsfälle wie das Festlegen einer Gültigkeitsdauer (TTL) für Objekte, die Aufbewahrung nicht aktueller Objektversionen oder das Downgrade der Speicherklassen von Objekten zur Kostensenkung.

Auf dieser Seite werden das Feature und die verfügbaren Optionen beschrieben. Informationen zum allgemeinen Format einer Lebenszyklus-Konfigurationsdatei finden Sie unter Bucket-Ressourcendarstellung für JSON und Lebenszyklus-Konfigurationsformat für XML.

Einführung

Sie können einem Bucket eine Konfiguration für die Lebenszyklusverwaltung zuweisen. Die Konfiguration enthält eine Reihe von Regeln, die für aktuelle und zukünftige Objekte im Bucket gelten. Wenn ein Objekt die Kriterien einer der Regeln erfüllt, führt Cloud Storage automatisch eine bestimmte Aktion für das Objekt aus. Hier ein paar Anwendungsbeispiele:

  • Ausführen eines Downgrades der Speicherklasse von Objekten, die älter als 365 Tage sind, auf Coldline Storage
  • Löschen von Objekten, die vor dem 1. Januar 2013 erstellt wurden
  • Aufbewahren nur der drei neuesten Versionen jedes Objekts in einem Bucket mit aktivierter Versionierung

Lebenszykluskonfiguration

Jede Konfiguration für die Lebenszyklusverwaltung enthält eine Reihe von Regeln. Beim Definieren einer Regel können Sie einen beliebigen Satz von Bedingungen für eine beliebige Aktion festlegen. Wenn Sie in einer Regel mehrere Bedingungen angeben, muss ein Objekt alle Bedingungen erfüllen, damit die Aktion ausgeführt wird. Bei Angabe mehrerer Regeln mit derselben Aktion wird die Aktion ausgeführt, wenn ein Objekt die Bedingungen einer der Regeln erfüllt. Jede Regel sollte nur eine Aktion enthalten.

Wenn die Bedingungen für ein einzelnes Objekt bei mehreren Regeln gleichzeitig erfüllt sind, führt Cloud Storage die Aktion aus, die nur einer der Regeln zugeordnet ist, wobei außerdem folgende Kriterien angewandt werden:

  • Die Aktion Delete hat Vorrang vor jeder SetStorageClass-Aktion.
  • Die Aktion SetStorageClass, die zur kostengünstigsten Speicherklasse für inaktive Objekte führt, hat Vorrang.

Sobald eine Aktion erfolgt, wird das Objekt noch einmal überprüft, bevor weitere Aktionen ausgeführt werden.

Beispiel: Wenn mit einer Regel ein Objekt gelöscht und mit einer anderen Regel dessen Speicherklasse geändert wird und beide Regeln dieselbe Bedingung verwenden, wird bei Erfüllen der Bedingung immer die Löschaktion ausgeführt. Wenn die Speicherklasse des Objekts mit einer Regel in Nearline Storage und mit einer anderen Regel in Coldline Storage geändert wird und beide Regeln dieselbe Bedingung enthalten, ändert sich die Speicherklasse des Objekts bei Erfüllen der Bedingung immer zu Coldline Storage.

Beispiele zur Verwendung von Lebenszykluskonfigurationen finden Sie unter Objektlebenszyklen verwalten.

Lebenszyklusaktionen

Eine Lebenszyklusregel gibt entweder eine Delete-Aktion oder eine SetStorageClass-Aktion an.

Delete

Über die Aktion Delete wird ein Objekt gelöscht, wenn das Objekt alle in der Lebenszyklusregel angegebenen Bedingungen erfüllt.

Ausnahme: In Buckets mit aktivierter Objektversionsverwaltung wird durch das Löschen der Live-Version eines Objekts eine nicht aktuelle Version erstellt, während beim Löschen einer nicht aktuellen Version diese dauerhaft gelöscht wird. In der Konfiguration zum Löschen von Objekten finden Sie ein Beispiel für die Verwendung der Aktion Delete zusammen mit der Objektversionsverwaltung.

SetStorageClass

Über die Aktion SetStorageClass wird die Speicherklasse eines Objekts geändert, wenn das Objekt alle in der Lebenszyklusregel angegebenen Bedingungen erfüllt.

SetStorageClass unterstützt die folgenden Speicherklassenumstellungen:

Ursprüngliche Speicherklasse Neue Storage-Klasse
Durable Reduced Availability (DRA) Storage Nearline Storage
Coldline Storage
Archive Storage
Multi-Regional Storage/Regional Storage1
Standard Storage, Multi-Regional Storage oder Regional Storage Nearline Storage
Coldline Storage
Archive Storage
Nearline Storage Coldline Storage
Archive Storage
Coldline Storage Archive Storage

1 Für Buckets in einer Region kann die neue Speicherklasse nicht Multi-Regional Storage sein. Für Buckets an einem Standort mit zwei oder mehr Regionen kann die neue Speicherklasse nicht Regional Storage sein.

Cloud Storage überprüft nicht die Richtigkeit der Speicherklassenumstellung. Das bedeutet, dass Sie eine Speicherklassenumstellung angeben können, die in der obigen Tabelle nicht aufgeführt ist. Die Umstellung findet jedoch nicht statt. Sie sollten prüfen, ob Ihre Lebenszyklusregeln eine der aufgeführten Speicherklassenumstellungen verwenden.

Lebenszyklusbedingungen

Eine Lebenszyklusregel enthält Bedingungen, die ein Objekt erfüllen muss, bevor die in der Regel definierte Aktion für das Objekt ausgeführt wird. Lebenszyklusregeln unterstützen die folgenden Bedingungen:

Alle Bedingungen sind optional, aber mindestens eine Bedingung ist erforderlich. Wenn Sie beispielsweise mit einer nicht vorhandenen Aktion oder Bedingung versuchen, eine ungültige Lebenszykluskonfiguration festzulegen, wird die Fehlermeldung 400 Bad request angezeigt und vorhandene Lebenszykluskonfigurationen bleiben bestehen.

Age

Die Bedingung Age ist erfüllt, wenn ein Objekt das angegebene Alter (in Tagen) erreicht. Das Alter wird anhand der Erstellungszeit des Objekts angegeben. Beispiel: Wenn das Objekt am 10.01.2019 um 10:00 Uhr (UTC) erstellt und die Bedingung Age auf 10 Tage festgelegt wurde, ist die Bedingung ab dem 20.01.2019 um 10:00 Uhr (UTC) erfüllt. Dies gilt auch dann, wenn das Objekt nach der Erstellung infolge der Objektversionsverwaltung nicht mehr aktuell ist.

CreatedBefore

Die Bedingung CreatedBefore ist erfüllt, wenn ein Objekt vor Mitternacht des angegebenen Datums in UTC erstellt wurde.

CustomTimeBefore

Die Bedingung CustomTimeBefore ist erfüllt, wenn der Datumsabschnitt der Custom-Time-Metadaten eines Objekts vor dem in dieser Bedingung angegebenen Datum liegt. Diese Bedingung wird mit dem Datumsformat YYYY-MM-DD festgelegt. CustomTimeBefore ist nie für ein Objekt ohne Custom-Time-Metadatensatz erfüllt.

DaysSinceCustomTime

Die Bedingung DaysSinceCustomTime ist erfüllt, wenn seit dem im Metadatenfeld Custom-Time eines Objekts angegebenen Datum und der angegebenen Uhrzeit die angegebene Anzahl von Tagen vergangen ist. Wenn beispielsweise die Custom-Time eines Objekts 2020-05-16T10:00:00Z ist und die Bedingung DaysSinceCustomTime 10 Tage beträgt, ist die Bedingung für das Objekt ab dem 26.05.2020 um 10:00 Uhr (UTC) erfüllt.

DaysSinceCustomTime ist nie für ein Objekt ohne Custom-Time-Metadatensatz festgelegt.

DaysSinceNoncurrentTime

Die Bedingung DaysSinceNoncurrentTime wird normalerweise nur in Verbindung mit der Objektversionsverwaltung verwendet. Die Bedingung ist erfüllt, wenn die angegebene Anzahl von Tagen verstrichen ist, seit das Objekt nicht mehr aktuell ist, weil die Live-Version entweder gelöscht oder ersetzt wurde. Wenn beispielsweise ein Objekt am 08.07.2020 um 15:00 Uhr (UTC) nicht mehr aktuell ist und die Bedingung DaysSinceNoncurrentTime 10 Tage beträgt, ist die Bedingung für das Objekt ab dem 18.07.2020 um 15:00 Uhr (UTC) erfüllt.

IsLive

Die Bedingung IsLive wird normalerweise nur in Verbindung mit der Objektversionsverwaltung verwendet. Wenn dieser Wert auf false gesetzt ist, ist diese Bedingung für alle nicht aktuellen Versionen eines Objekts erfüllt. Wenn dieser Wert auf true gesetzt ist, ist diese Bedingung für die Live-Version eines Objekts erfüllt. Wenn Sie keine Versionsverwaltung verwenden, werden alle Ihre Objekte als live betrachtet und stimmen überein, wenn IsLive auf true gesetzt ist.

MatchesStorageClass

Die Bedingung MatchesStorageClass wird erfüllt, wenn ein Objekt im Bucket in der angegebenen Speicherklasse gespeichert wird. Sie können die folgenden Werte für MatchesStorageClass verwenden: STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL und DURABLE_REDUCED_AVAILABILITY.

Grundsätzlich sollten Sie außerdem Folgendes beachten, wenn Sie die Bedingung MatchesStorageClass für Standard Storage-Objekte verwenden:

  • Wenn sich der Bucket in einer Region befindet, schließen Sie REGIONAL und DURABLE_REDUCED_AVAILABILITY in die Bedingung ein.

  • Wenn sich der Bucket an einem Standort mit zwei oder mehr Regionen befindet, schließen Sie MULTI_REGIONAL und DURABLE_REDUCED_AVAILABILITY in die Bedingung ein.

Sie können dafür sorgen, dass die Lebenszyklusregel ältere Objekte in Ihren Buckets abdeckt, die unter Umständen auf ältere Speicherklassen festgelegt wurden. Beziehen Sie dazu diese zusätzlichen Klassen mit ein.

NoncurrentTimeBefore

Die Bedingung NoncurrentTimeBefore wird normalerweise nur in Verbindung mit der Objektversionsverwaltung verwendet. Die Bedingung ist für Objekte erfüllt, die zu einem Zeitpunkt vor dem in dieser Bedingung angegebenen Datum nicht mehr aktuell waren. Die Bedingung wird im Datumsformat YYYY-MM-DD angegeben. NoncurrentTimeBefore ist nie für ein Live-Objekt erfüllt.

NumberOfNewerVersions

Die Bedingung NumberOfNewerVersions wird normalerweise nur in Verbindung mit der Objektversionsverwaltung verwendet. Wenn der Wert dieser Bedingung auf N festgelegt ist, erfüllt eine Objektversion die Bedingung, wenn mindestens N Versionen (einschließlich der Live-Version) neuer als diese Version sind. Bei einer Live-Objektversion wird von 0 neueren Versionen ausgegangen. Für die neueste nicht aktuelle Version wird von einer neueren Version bzw. von 0 neueren Versionen ausgegangen, wenn keine Live-Objektversion vorhanden ist, usw.

Objektlebenszyklusverhalten

  • Cloud Storage überprüft regelmäßig alle Objekte in Buckets mit konfigurierter Verwaltung des Objektlebenszyklus. Dabei werden alle gemäß den Bucket-Regeln anwendbaren Aktionen ausgeführt. Da Cloud Storage eine Aktion asynchron ausführt, kann sich deren Ausführung nach Erfüllen der Bedingungen verzögern.

    Beispiel: Wenn ein Objekt die Löschbedingungen erfüllt, wird das Objekt möglicherweise nicht sofort gelöscht. Sie sehen das Objekt daher bis zur Ausführung der Lebenszyklusaktion. Solange das Objekt vorhanden ist, gelten weiterhin entsprechende Gebühren, mit einer Ausnahme: Speicherkosten im Ruhezustand entfallen, wenn mit dem Objekt aufgrund einer Regel, die nur eine Age-Bedingung hat, eine Delete-Aktion ausgeführt wird.

  • Es kann bis zu 24 Stunden dauern, bis Aktualisierungen Ihrer Lebenszykluskonfiguration wirksam werden. Wenn Sie die Lebenszykluskonfiguration ändern, können daher im Rahmen der Verwaltung des Objektlebenszyklus bis zu 24 Stunden lang weiterhin Aktionen gemäß der alten Konfiguration ausgeführt werden.

    Wenn Sie beispielsweise die Bedingung Age von 10 Tage auf 20 Tage ändern, kann ein 11 Tage altes Objekt aufgrund der Kriterien der alten Konfiguration bis zu 24 Stunden später von der Verwaltung des Objektlebenszyklus gelöscht werden.

  • Eine Delete-Aktion des Objektlebenszyklus wird in Bezug auf ein Objekt nicht wirksam, während das Objekt entweder mit Objekt-Hold markiert ist oder eine zugewiesene Aufbewahrungsrichtlinie noch nicht erfüllt hat. Jede Delete-Aktion, die auftreten würde, während für ein Objekt eine Einschränkung in Form eines Holds oder einer Aufbewahrungsrichtlinie gilt, erfolgt stattdessen, nachdem die Einschränkungen nicht mehr für das Objekt gelten.

  • Eine SetStorageClass-Aktion eines Objektlebenszyklus wird nicht durch das Vorhandensein von Objekt-Holds oder Aufbewahrungsrichtlinien beeinflusst.

Kostenvorteile von SetStorageClass

Anders als beim manuellen Ändern der Speicherklasse eines Objekts schreibt die Verwaltung des Objektlebenszyklus ein Objekt nicht neu, wenn es die Speicherklasse des Objekts ändert. Dies bietet der Verwaltung des Objektlebenszyklus bestimmte Preisvorteile:

  • Mit der Änderung der Speicherklasse sind keine Abrufgebühren oder Gebühren für vorzeitiges Löschen verbunden, selbst wenn das Objekt ursprünglich auf Nearline Storage oder Coldline Storage eingestellt war.

  • Die in der ursprünglichen Speicherklasse festgelegte Zeit des Objekts wird auf die minimale Speicherdauer angerechnet, die für die neue Speicherklasse gilt.

Angenommen, Sie laden ein Objekt als Nearline Storage hoch, und 20 Tage später ändert Ihre Lebenszykluskonfiguration die Speicherklasse des Objekts in Coldline Storage. Für diese Änderung fallen keine Gebühren für das Abrufen oder das vorzeitige Löschen an. Wenn Sie das Objekt dann 60 Tage nach der Änderung der Speicherklasse löschen, wird nur eine Gebühr von 10 Tagen für das vorzeitige Löschen erhoben, da Coldline Storage eine Mindestspeicherdauer von 90 Tagen hat und das Objekt insgesamt 80 Tage lang vorhanden war.

Ein weiteres Beispiel: Sie laden ein Objekt als Nearline Storage hoch und nach 20 Tagen ändern Sie die Speicherklasse durch Umschreiben in Coldline Storage. Für diese Änderung fallen sowohl eine Abrufgebühr als auch eine Gebühr für das vorzeitige Löschen für 10 Tage an. Wenn Sie das Objekt 60 Tage nach dem Umschreiben löschen, wird eine Gebühr für vorzeitiges Löschen für 30 Tage berechnet.

Ablaufzeitmetadaten

Wenn eine Delete-Aktion für einen Bucket mit der Age-Bedingung (und keinen weiteren Bedingungen als matchesStorageClass) angegeben ist, werden Objekte unter Umständen mit Ablaufzeitmetadaten getaggt. Die Ablaufzeit eines Objekts gibt an, ab wann das Objekt im Rahmen der Verwaltung des Objektlebenszyklus gelöscht werden darf bzw. durfte. Die Ablaufzeit kann sich aufgrund von Änderungen der Lebenszykluskonfiguration oder Aufbewahrungsrichtlinie des Buckets ändern.

Hinweis: Das Fehlen von Ablaufzeitmetadaten bedeutet nicht unbedingt, dass das Objekt nicht gelöscht wird. Es stehen lediglich nicht genügend Informationen zur Verfügung, um zu ermitteln, wann oder ob es gelöscht wird. Beispiel: Wenn das Objekt am 10.01.2020 um 10:00 Uhr (UTC) erstellt und die Age-Bedingung auf 10 Tage festgelegt wurde, dann ist die Objektablaufzeit der 20.01.2020 um 10:00 Uhr (UTC). Die Ablaufzeit ist jedoch für das Objekt in folgenden Fällen nicht verfügbar:

  • In der Regel Delete sind weitere Bedingungen mit Ausnahme von matchesStorageClass angegeben.

  • Sie verwenden eine matchesStorageClass-Bedingung, die nicht die Speicherklasse des Objekts enthält.

  • Das Objekt unterliegt einem Hold, da Cloud Storage nicht wissen kann, wann der Hold entfernt wird.

Nach Erreichen der Objektablaufzeit fallen keine weiteren Speicherkosten an, selbst wenn das Objekt nicht sofort gelöscht wird. Sie können bis zum Löschen weiterhin auf das Objekt zugreifen, wobei jedoch Gebühren für Anfragen und die Netzwerkbandbreite entstehen. Wenn keine Ablaufzeit für ein Objekt verfügbar ist, werden bis zum Löschen des Objekts Speicherkosten berechnet.

Beachten Sie Folgendes, wenn Sie mit Ablaufzeiten arbeiten:

  • Wenn der Bucket über eine Aufbewahrungsrichtlinie verfügt, entspricht die Ablaufzeit entweder der Bedingung Age der Verwaltung des Objektlebenszyklus oder dem Zeitpunkt, zu dem das Objekt die in der Aufbewahrungsrichtlinie angegebene Aufbewahrungsdauer aufweist, je nachdem was später ist.

  • Wenn für ein Objekt aufgrund unterschiedlicher Verwaltungsregeln für den Lebenszyklus mehrere in Konflikt stehende Ablaufzeiten gelten, wird die früheste anwendbare Ablaufzeit verwendet.

Optionen zum Verfolgen von Lebenszyklusaktionen

Sie können die von Cloud Storage durchgeführten Aktionen zur Lebenszyklusverwaltung auf folgende Weise verfolgen:

  • Verwenden Sie Cloud Storage-Nutzungslogs. Darin ist neben der Aktion auch der Initiator der Aktion angegeben. Der Wert GCS Lifecycle Management im Feld cs_user_agent des Logeintrags gibt an, dass die Aktion von Cloud Storage gemäß einer Lebenszykluskonfiguration ausgeführt wurde.

  • Durch Aktivieren von Pub/Sub-Benachrichtigungen für Cloud Storage für Ihren Bucket. Dadurch werden bei Ausführung der angegebenen Aktionen Benachrichtigungen an ein Pub/Sub-Thema Ihrer Wahl gesendet. Bei diesem Feature wird der Initiator der Aktionen nicht aufgezeichnet.

Weitere Informationen