Verwaltung des Objektlebenszyklus

Einrichtung Konfigurationsbeispiele

Ü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

Zur Verwendung der Verwaltung des Objektlebenszyklus definieren Sie eine Lebenszykluskonfiguration, die für einen Bucket festgelegt werden muss. 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 Storage-Klasse von Objekten, die älter als 365 Tage sind, auf die Coldline Storage-Klasse
  • Löschen von Objekten, die vor dem 1. Januar 2019 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. Jede Regel enthält eine Aktion und eine oder mehrere Bedingungen.

  • Ein Objekt muss alle Bedingungen erfüllen, die in einer Regel angegeben sind, damit die Aktion in der Regel ausgeführt wird.

  • Bei Angabe mehrerer Regeln mit derselben Aktion wird die Aktion für ein Objekt ausgeführt, wenn dieses Objekt die Bedingungen einer der Regeln erfüllt.

  • 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:

    Beispiel: 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.

  • Sie sollten die Lebenszyklusregeln vor dem Einsatz in der Produktion an Entwicklungsdaten testen, um sicherzustellen, dass die Regeln keine Aktionen unter unbeabsichtigten Bedingungssätzen ausführen. Wenn dies nicht möglich ist, sollten Sie eine kleine Teilmenge Ihrer Produktionsdaten mit den Bedingungen matchesPrefix oder matchesSuffix in Ihren Regeln testen.

  • Es kann bis zu 24 Stunden dauern, bis Änderungen an der Lebenszykluskonfiguration eines Buckets wirksam werden. Die Verwaltung des Objektlebenszyklus kann während dieser Zeit weiterhin Aktionen auf der Grundlage der alten Konfiguration ausführen.

    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.

Anwendungsfälle finden Sie unter Konfigurationsbeispiele für die Verwaltung des Objektlebenszyklus.

Lebenszyklusaktionen

Eine Lebenszyklusregel gibt genau eine der folgenden Aktionen an:

Löschen

Über die Aktion Delete wird ein Objekt gelöscht, wenn das Objekt alle in der Lebenszyklusregel angegebenen Bedingungen erfüllt. Standardmäßig wird ein Liveobjekt beim Löschen vorläufig gelöscht und Cloud Storage speichert es sieben Tage lang. Sie können dieses vorläufig gelöschte Objekt innerhalb der Aufbewahrungsdauer für das vorläufige Löschen wiederherstellen.

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 aus dem Bucket 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.

Die Aktion Delete wird nicht für ein Objekt ausgeführt, das entweder mit einem Objekt-Hold versehen oder einer Aufbewahrungsrichtlinie zugewiesen ist, die noch nicht erfüllt wurde. Wenn die Bedingungen in der Aktion Delete für das Objekt erfüllt sind, erfolgt die Aktion Delete, sobald der Objekt-Hold entfernt wurde und die Aufbewahrungsrichtlinie erfüllt ist.

SetStorageClass

Mit der Aktion SetStorageClass wird die Speicherklasse eines Objekts geändert und die Änderungszeit eines Objekts aktualisiert, 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.

Unvollständige mehrteilige Uploads abbrechen

Die Aktion AbortIncompleteMultipartUpload bricht einen unvollständigen mehrteiligen Upload ab und löscht die zugehörigen Teile, wenn der mehrteilige Upload die in der Lebenszyklusregel angegebenen Bedingungen erfüllt.

Für diese Aktion können nur die folgenden Lebenszyklusbedingungen verwendet werden:

Der Versuch, eine Regel zu erstellen, die die Aktion AbortIncompleteMultipartUpload in Kombination mit anderen Bedingungen verwendet, führt zu einem Fehler.

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 eine Ressource das angegebene Alter (in Tagen) erreicht. Das Alter wird anhand der Erstellungszeit der Ressource angegeben.

  • Bei Objekten ist die Erstellungszeit die Zeit, zu der das Objekt erfolgreich in den Bucket geschrieben wurde, z. B. wenn ein Upload abgeschlossen ist.

    • Das Alter eines Objekts ist davon nicht betroffen, da das Objekt zu einer nicht aktuellen Version wird.

  • Bei mehrteiligen Uploads ist die Erstellungszeit der Zeitpunkt, zu dem der Upload initiiert wird.

Wenn eine Ressource beispielsweise am 10.01.2022 um 10:00 Uhr (UTC) erstellt wird und die Bedingung age 10 Tage beträgt, ist die Bedingung für die Ressource ab dem 20.01.2022 um 10:00  Uhr UTC erfüllt.

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.

matchesPrefix und matchesSuffix

Die Bedingungen matchesPrefix und matchesSuffix werden erfüllt, wenn der Anfang oder das Ende des Objektnamens eine genaue Übereinstimmung mit dem angegebenen Präfix oder Suffix ist, bei der Groß- und Kleinschreibung berücksichtigt wird. Sie können mehrere Strings als Liste angeben (z. B. "matchesSuffix": [".jpg", ".png"]).

Wenn Sie matchesPrefix verwenden, geben Sie den Bucket-Namen und das /-Element nicht an, das in den meisten Anfragepfaden Objektnamen vorangestellt ist. In der Google Cloud CLI hat der Pfad zu einem Objekt in einem Bucket namens my_bucketbeispielsweise ein Format wie gs://my_bucket/pictures/paris_2022.jpg. Zum Abgleichen des Objekts verwenden Sie eine Bedingung wie "matchesPrefix":["pictures/paris_"].

Sie können für alle Regeln bis zu 50 Präfixe und 50 Suffixe angeben. Ein Präfix oder Suffix kann nicht zweimal in einer einzelnen Bedingung verwendet werden.

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.

numNewerVersions

Die Bedingung numNewerVersions 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. Ihre Anwendungen sollten nicht auf Lebenszyklusaktionen basieren, die innerhalb eines bestimmten Zeitraums nach dem Erfüllen einer Lebenszyklusbedingung ausgeführt werden.

Beispiel: Wenn ein Objekt die Löschbedingungen erfüllt, wird das Objekt möglicherweise nicht sofort gelöscht und Sie sehen das Objekt so lange, bis die Lebenszyklusaktion für das Objekt ausgeführt wird. In Buckets mit aktivierter Objektversionsverwaltung bedeutet dies, dass ein Liveobjekt für einen bestimmten Zeitraum in einem nicht aktuellen Zustand vorhanden ist, auch wenn die nicht aktuelle Version des Objekts ebenfalls die Bedingungen der Löschregel erfüllt.

Solange das Objekt in seinem ursprünglichen Zustand verbleibt, fallen weiterhin entsprechende Gebühren an, mit einer Ausnahme: Speicherkosten im Ruhezustand entfallen, wenn das Objekt alle folgenden Kriterien erfüllt:

  • Das Objekt befindet sich in einem Bucket, in dem vorläufiges Löschen deaktiviert ist
  • Das Objekt unterliegt einer Regel mit der Aktion Delete.
  • Die einzige Bedingung für die Regel ist eine age-Bedingung
  • Die Bedingung age ist für das Objekt erfüllt.

SetStorageClass Kostengesichtspunkte

Ähnlich wie die manuelle Änderung der Speicherklasse eines Objekts zählt die Verwendung von SetStorageClass als Vorgang der Klasse A und wird zu dem Preis abgerechnet, der durch die Zielspeicherklasse bestimmt wird.

Im Gegensatz zur manuellen Änderung der Speicherklasse eines Objekts wird mit SetStorageClass kein Objekt neu geschrieben. Dies bietet der Verwaltung des Objektlebenszyklus bestimmte Preisvorteile:

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.

In beiden Beispielen werden die Speichergebühren erhöht, wenn für den Bucket vorläufiges Löschen aktiviert ist, aber die Gebühren für vorzeitiges Löschen sinken je nach Länge des Aufbewahrungszeitraums für das vorläufige Löschen.

Zeitpunkt der Objekterstellung

In vielen Fällen wird der Upload eines Objekts kurz nach dessen Beginn abgeschlossen. Bei Uploads über mehrere Anfragen, z. B. für fortsetzbare Uploads, können jedoch zwischen dem Zeitpunkt der ersten Uploadanfrage und dem Abschluss der letzten Uploadanfrage Tage liegen. Beachten Sie in solchen Fällen Folgendes:

  • Ein Objekt unterliegt keinen Lebenszyklusregeln, bis der Upload abgeschlossen ist.
  • Der Erstellungszeitpunkt eines Objekts richtet sich nach dem Abschluss des Uploads. Dies wirkt sich auf die Lebenszyklusbedingungen age und createdBefore aus.
  • Wenn Sie eine Custom-Time für das Objekt festlegen, geschieht dies zu Beginn des Uploads. Wenn Sie eine Custom-Time basierend auf dem Zeitpunkt der Anfrage festlegen, kann die Custom-Time viel früher als die Erstellungszeit des Objekts sein. Dies wirkt sich auf die Lebenszyklusbedingungen customTimeBefore und daysSinceCustomTime aus.

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.

  • Vorläufiges Löschen ist für Ihren Bucket aktiviert.

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.

Nächste Schritte