Verwaltung des Objektlebenszyklus

Über die Verwaltung des Objektlebenszyklus unterstützt Cloud Storage gängige Anwendungsfälle wie das Festlegen einer Gültigkeitsdauer (TTL) für Objekte, das Archivieren älterer Objektversionen oder das Downgrade der Speicherklassen von Objekten zur Kostensenkung. Auf dieser Seite werden die Funktion und die verfügbaren Optionen beschrieben. Unter Lebenszyklen verwalten erhalten Sie eine Anleitung zum Aktivieren der Objektlebenszyklusverwaltung sowie Beispiele zu Lebenszyklusrichtlinien.

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 an dem Objekt aus. Hier einige Anwendungsbeispiele:

  • Ausführen eines Downgrades der Speicherklasse von Objekten, die älter als 365 Tage sind, auf die Coldline Storage-Klasse
  • 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 Versionsverwaltung

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 mehrere Aktionen auf ein Objekt zutreffen, führt Cloud Storage nur eine der Aktionen aus. Anschließend erfolgt eine Neubewertung des Objekts, bevor weitere Aktionen ausgeführt werden. Eine Delete-Aktion hat Vorrang vor einer SetStorageClass-Aktion. Wenn mehrere SetStorageClass-Aktionen angegeben sind, wird die Aktion ausgewählt, die zur kostengünstigsten Storage-Klasse für inaktive Objekte führt.

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

Lebenszyklusaktionen

Die folgenden Aktionen werden für eine Lebenszyklusregel unterstützt:

  • Delete: Löscht Live- und/oder archivierte Objekte. (Ein Liveobjekt ist ein nicht archiviertes Objekt. Weitere Informationen finden Sie im Abschnitt Objektversionsverwaltung.) Diese Aktion kann sowohl auf versionierte als auch auf nicht versionierte Objekte angewendet werden. Wenn ein Liveobjekt in einem Bucket mit aktivierter Verwaltung gelöscht wird, entsteht ein archiviertes Objekt. Dauerhaft entfernt wird das Objekt erst durch Löschen des archivierten Objekts.

  • SetStorageClass: Ändert die Speicherklasse von Liveobjekten und/oder archivierten Objekten. Diese Aktion kann sowohl auf versionierte als auch auf nicht versionierte Objekte angewendet werden. Diese Aktion ermöglicht die folgenden Wechsel der Speicherklasse:

    Ursprüngliche Speicherklasse Neue Speicherklasse
    Durable Reduced Availability (DRA) Storage Nearline Storage
    Coldline StorageMulti-Regional Storage/Regional Storage1
    Multi-Regional Storage Nearline Storage
    Coldline Storage
    Regional Storage Nearline Storage
    Coldline Storage
    Standard Storage Nearline Storage
    Coldline Storage
    Nearline Storage Coldline 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.

Lebenszyklusbedingungen

Die folgenden Bedingungen werden für eine Lebenszyklusregel unterstützt:

  • Age: Diese Bedingung wird 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.2017 um 10:00 Uhr (UTC) erstellt und die Bedingung Age auf 10 Tage festgelegt wurde, ist die Bedingung ab dem 20.01.2017 um 10:00 Uhr (UTC) erfüllt. Dies gilt auch dann, wenn das Objekt nach der Erstellung infolge der Objektversionsverwaltung archiviert wurde.

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

  • IsLive: Wenn der Wert true ist, gilt diese Lebenszyklusbedingung nur für Liveobjekte. Wenn der Wert false ist, gilt sie nur für archivierte Objekte. Für diese Bedingung werden Objekte in nicht versionierten Buckets als Liveobjekte betrachtet.

  • MatchStorageClass: Diese Bedingung 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, 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 sicherstellen, dass die Lebenszyklusregel ältere Objekte in Ihren Buckets abdeckt, die möglicherweise auf ältere Speicherklassen festgelegt wurden. Beziehen Sie dazu diese zusätzlichen Klassen mit ein.

  • NumberOfNewerVersions: Nur für versionierte Objekte relevant. Wenn der Wert dieser Bedingung auf N festgelegt ist, erfüllt ein Objekt die Bedingung, wenn mindestens N Versionen (einschließlich der Live-Version) neuer als diese sind. Bei Liveobjekten wird von 0 neueren Versionen ausgegangen. Für die neueste archivierte Version wird von einer neueren Version bzw. von 0 neueren Versionen ausgegangen, wenn kein Liveobjekt vorhanden ist, usw.

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.

Beispiele zur Verwendung von Lebenszykluskonfigurationen finden Sie unter Objektlebenszyklen verwalten. Informationen zum allgemeinen Format einer Lebenszyklus-Konfigurationsdatei finden Sie unter Bucket-Ressourcendarstellung für JSON und Lebenszyklus-Konfigurationsformat für XML.

Objektlebenszyklusverhalten

  • Cloud Storage überprüft regelmäßig alle Objekte in Buckets mit konfigurierter Objektlebenszyklusverwaltung. 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 für das 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 für 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.

Vorzeitiges Löschen von Nearline Storage- und Coldline Storage-Objekten

Wenn sich die Speicherklasse eines Objekts ändert, erfolgt im Rahmen der Verwaltung des Objektlebenszyklus keine Umschreibung des Objekts. Wenn also ein Objekt mithilfe der Funktion SetStorageClass in Nearline Storage oder Coldline Storage verschoben wird, werden alle nachfolgenden Kosten für vorzeitiges Löschen anhand des ursprünglichen Erstellungszeitpunkts des Objekts berechnet. Das geschieht unabhängig davon, wann die Speicherklasse geändert wurde.

Beispiel: Sie laden ein Objekt in der Standard Storage-Klasse hoch. Die Speicherklasse des Objekts ändert sich 20 Tage später in Ihrer Lebenszykluskonfiguration in Nearline Storage. Wenn Sie das Objekt unmittelbar danach löschen, fällt eine Gebühr für vorzeitiges Löschen für 10 Tage an, da das Objekt 20 Tage lang existiert hat. Wenn Sie das Objekt 10 Tage nach der Änderung in die Nearline Storage-Klasse löschen, fällt keine Gebühr für vorzeitiges Löschen an, da das Objekt 30 Tage lang existiert hat.

Ein weiteres Beispiel: Sie laden ein Objekt in der Standard Storage-Klasse hoch. Nach 20 Tagen ändern Sie die Speicherklasse durch Umschreiben in Nearline Storage. Wenn Sie das Objekt unmittelbar danach löschen, wird die vollständige Gebühr für vorzeitiges Löschen für 30 Tage fällig, da die Umschreibzeit zur neuen Erstellungszeit wird. Wenn Sie das Objekt 10 Tage nach dem Umschreiben löschen, fällt analog dazu eine Gebühr für vorzeitiges Löschen für 20 Tage an.

Ablaufzeitmetadaten

Wenn eine Delete-Aktion für einen Bucket mit der Age-Bedingung (und ohne NumberOfNewerVersions-Bedingung) 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.2013 um 10:00 Uhr (UTC) erstellt und die Age-Bedingung auf 10 Tage festgelegt wurde, dann ist die Objektablaufzeit der 20.01.2013 um 10:00 Uhr (UTC). Die Ablaufzeit ist jedoch für das Objekt in folgenden Fällen nicht verfügbar:

  • Die NumberOfNewerVersions-Bedingung wird ebenfalls angegeben. In diesem Fall können ältere Versionen des Objekts durch Einfügen neuerer Versionen weiterhin gelöscht werden.

  • Es wurde zusätzlich die CreatedBefore-Bedingung angegeben und auf den 01.01.2013 gesetzt. Das Objekt erfüllt in diesem Fall die Bedingung nicht.

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

Sie können die Ablaufzeit eines Objekts in dessen Metadaten einsehen, sofern diese verfügbar sind. Die REST API gibt die Objektablaufzeit im Antwortheader x-goog-expiration zurück.

Beachten Sie Folgendes, wenn Sie mit Ablaufzeiten arbeiten:

  • Wenn der Bucket über eine Aufbewahrungsrichtlinie verfügt, entspricht die Ablaufzeit entweder der Altersbedingung 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:

  • Mithilfe von Cloud Storage-Zugriffslogs. 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 Cloud Pub/Sub-Benachrichtigungen für Cloud Storage für Ihren Bucket. Dadurch werden bei Ausführung der angegebenen Aktionen Benachrichtigungen an ein Cloud Pub/Sub-Thema Ihrer Wahl gesendet. Bei dieser Funktion wird der Initiator der Aktionen nicht aufgezeichnet.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...