Gestion du cycle de vie des objets

Cloud Storage offre une fonctionnalité de gestion du cycle de vie des objets disponible pour les cas d'utilisation courants, tels que la définition d'une valeur TTL (Time To Live) pour les objets, l'archivage d'anciennes versions d'objets ou la "rétrogradation" des classes de stockage d'objets pour vous aider à gérer les coûts. Cette page présente cette fonctionnalité et ses options. Pour savoir comment activer la gestion du cycle de vie des objets et obtenir des exemples de règles de cycle de vie, consultez la section relative à la gestion des cycles de vie.

Présentation

Vous pouvez attribuer à un bucket une configuration de gestion du cycle de vie. La configuration intègre un ensemble de règles qui s'appliquent aux objets actuels et futurs du bucket. Lorsqu'un objet répond aux critères de l'une des règles, Cloud Storage exécute automatiquement l'action spécifiée sur l'objet. Voici quelques exemples d'utilisation :

  • Rétrograder la classe de stockage des objets datant de plus de 365 jours à la classe de stockage Coldline
  • Supprimer les objets créés avant le 1er janvier 2013
  • Conserver seulement les trois versions les plus récentes de chaque objet d'un bucket en activant la gestion des versions

Configuration du cycle de vie

Chaque configuration de gestion du cycle de vie contient un ensemble de règles. Lorsque vous définissez une règle, vous pouvez spécifier un ensemble de conditions valable pour toute opération. Si vous spécifiez plusieurs conditions dans une règle, un objet doit satisfaire toutes les conditions pour que l'opération aboutisse. Si vous spécifiez plusieurs règles pour une même opération, celle-ci est exécutée lorsqu'un objet satisfait la ou les conditions de l'une des règles. Chaque règle doit porter sur une seule opération.

Si un seul objet est soumis à plusieurs opérations, Cloud Storage n'exécute qu'une seule de ces opérations et l'objet sera réévalué avant toute autre opération. Une opération de suppression a priorité sur une opération de définition de classe de stockage. Si plusieurs opérations de définition de classe de stockage sont spécifiées, c'est l'opération basculant sur la classe de stockage avec le prix de stockage au repos le plus bas qui est choisie.

Ainsi, si l'une des règles supprime un objet et qu'une autre règle modifie la classe de stockage de l'objet, mais que les deux règles utilisent exactement la même condition, l'opération de suppression s'exécute toujours lorsque la condition est remplie. Si l'une des règles fait passer la classe de l'objet au stockage Nearline et qu'une autre règle fait passer la classe de l'objet au stockage Coldline, mais que les deux règles utilisent exactement la même condition, la classe de l'objet passe toujours au stockage Coldline lorsque la condition est remplie.

Opérations du cycle de vie

Les règles du cycle de vie intègrent les opérations suivantes :

  • Delete : suppression des objets actifs et/ou archivés. (Un objet actif est un objet qui ne constitue pas une génération archivée. Voir la section Gestion des versions d'objets pour plus de détails.) Cette opération peut être appliquée aux objets avec ou sans gestion de versions. Dans un bucket dont la gestion des versions est activée, la suppression d'un objet actif archive l'objet, tandis que la suppression d'un objet archivé supprime définitivement l'objet.

  • SetStorageClass : modifie la classe de stockage des objets actifs et/ou archivés. Cette opération peut être appliquée aux objets avec ou sans gestion de versions. Cette opération permet d'effectuer les transitions de classe de stockage suivantes :

    Classe de stockage d'origine Nouvelle classe de stockage
    Stockage à disponibilité limitée durable Stockage Nearline
    Stockage ColdlineStockage multirégional/Stockage régional1
    Stockage multirégional Stockage Nearline
    Stockage Coldline
    Stockage Régional Stockage Nearline
    Stockage Coldline
    Stockage standard Stockage Nearline
    Stockage Coldline
    Stockage Nearline Stockage Coldline

    1 Pour les buckets appartenant à une [zone régionale], la nouvelle classe de stockage ne peut pas correspondre à un stockage multirégional. Pour les buckets appartenant à une zone multirégionale ou birégionale, la nouvelle classe de stockage ne peut pas correspondre à un stockage régional.

Conditions du cycle de vie

Les règles de cycle de vie peuvent intégrer les conditions suivantes :

  • Age : cette condition est remplie lorsqu'un objet atteint l'âge spécifié (en jours). L'âge est mesuré à partir de l'heure et de la date de création de l'objet. Par exemple, si l'heure de création d'un objet est 2019/01/10 10:00 UTC et que la condition Age est définie à 10 jours, la condition est satisfaite pour l'objet à partir de 2019/01/20 10:00 UTC. Cela s'applique même si l'objet est archivé via la gestion des versions d'objet après sa création.

  • CreatedBefore : cette condition est remplie lorsqu'un objet est créé avant minuit à la date spécifiée au format UTC.

  • IsLive : si la valeur est true, cette condition de cycle de vie ne correspond qu'aux objets actifs. Si la valeur est false, cette condition ne correspond qu'aux objets archivés. Dans le cadre de cette condition, les objets se trouvant dans des buckets sans gestion de versions sont considérés comme actifs.

  • MatchesStorageClass : cette condition est remplie lorsqu'un objet du bucket est stocké en tant que classe de stockage spécifiée. Vous pouvez utiliser les valeurs suivantes pour MatchesStorageClass : STANDARD, NEARLINE, COLDLINE, MULTI_REGIONAL, REGIONAL et DURABLE_REDUCED_AVAILABILITY.

    En règle générale, si vous souhaitez utiliser cette condition MatchesStorageClass sur les objets de stockage standard, vous devez également :

    • si le bucket se trouve dans une zone régionale, inclure REGIONAL et DURABLE_REDUCED_AVAILABILITY dans la condition ;

    • si le bucket se trouve dans une zone multirégionale ou birégionale, inclure MULTI_REGIONAL et DURABLE_REDUCED_AVAILABILITY dans la condition.

    L'inclusion de ces classes supplémentaires garantit que la règle de cycle de vie s'applique également aux objets plus anciens de vos buckets, qui peuvent être définis avec des classes de stockage anciennes.

  • NumberOfNewerVersions : pertinent seulement pour les objets avec gestion de versions. Si la valeur de cette condition est définie sur N, un objet remplit la condition lorsqu'il existe au moins N versions (y compris la version en ligne) plus récentes que celle-ci. Pour les objets actifs, le nombre de versions plus récentes est considéré comme égal à 0. Pour la version archivée la plus récente, le nombre de versions plus récentes est 1 (ou 0 en l'absence d'objet actif), etc.

Toutes les conditions sont facultatives, mais au moins une condition est requise. Si vous tentez de définir une configuration de cycle de vie non valide, en utilisant par exemple une opération ou une condition inexistante, vous recevez une réponse d'erreur 400 Bad request et toute configuration de cycle de vie existante reste en place.

Pour obtenir des exemples d'utilisation de configurations du cycle de vie, consultez la section Gérer les cycles de vie des objets. Pour connaître le format général d'un fichier de configuration de cycle de vie, consultez la page décrivant la représentation des ressources de bucket pour JSON ou le format de configuration de cycle de vie pour XML.

Comportement du cycle de vie d'un objet

  • Cloud Storage inspecte régulièrement tous les objets d'un bucket pour lesquels la gestion du cycle de vie des objets est configurée, et exécute toutes les opérations applicables en fonction des règles du bucket. Cloud Storage exécute les opérations de manière asynchrone. Il peut donc y avoir un décalage entre le moment où les conditions sont remplies et celui où l'opération est exécutée.

    Par exemple, si un objet remplit les conditions de suppression, il se peut qu'il ne soit pas supprimé immédiatement. Par conséquent, vous continuerez à voir l'objet jusqu'à ce que l'opération du cycle de vie soit exécutée. Les frais applicables restent valables tant que l'objet existe, à une exception près : les coûts de stockage au repos sont levés si l'objet est soumis à une opération delete du fait d'une règle ne présentant qu'une condition age.

  • L'application des mises à jour de votre configuration de cycle de vie peut prendre jusqu'à 24 heures. Cela signifie que lorsque vous modifiez votre configuration de cycle de vie, la gestion du cycle de vie des objets peut encore exécuter des opérations basées sur l'ancienne configuration pendant 24 heures maximum.

    Par exemple, si vous modifiez une condition Age de 10 jours pour la passer à 20 jours, un objet de 11 jours pourra être supprimé par la gestion du cycle de vie des objets jusqu'à 24 heures plus tard, sur la base de l'ancienne configuration.

  • Une opération de suppression (Delete) du cycle de vie d'un objet ne prendra pas effet tant que l'objet est mis en attente ou que sa règle de conservation n'est pas encore satisfaite. Si une opération Delete avait lieu alors qu'un objet était soumis à une restriction de mise en attente ou de stratégie de conservation, cette opération serait appliquée une fois les restrictions sur l'objet levées.

  • Une opération de définition de classe de stockage (SetStorageClass) du cycle de vie de l'objet n'est pas affectée par l'existence de stratégies de conservation ou de mise en attente de l'objet.

Suppression anticipée d'objets de stockage Nearline et de stockage Coldline

La gestion du cycle de vie des objets ne réécrit pas d'objet lorsque sa classe de stockage change. Ainsi, lorsqu'un objet est migré vers le stockage Nearline ou le stockage Coldline à l'aide de la fonctionnalité SetStorageClass, toute suppression ultérieure anticipée (et les frais associés) est basée sur l'heure et la date de création initiale de l'objet, peu importe le moment du changement de classe de stockage.

Supposons, par exemple, que vous téléchargiez un objet en tant que stockage standard et que 20 jours plus tard, votre configuration de cycle de vie fasse passer la classe de stockage de l'objet au stockage Nearline. Si vous supprimez alors l'objet immédiatement, des frais de suppression anticipée sont appliqués sur 10 jours, car l'objet a existé pendant 20 jours. Si vous supprimez l'objet 10 jours après la transition de sa classe de stockage au stockage Nearline, aucun frais de suppression anticipée n'est appliqué, car l'objet a existé pendant 30 jours.

Par comparaison, supposons que vous importiez un objet en stockage standard et que 20 jours plus tard, vous modifiez la classe de stockage à l'aide d'une réécriture (à nouveau vers le stockage Nearline). Si vous supprimez alors l'objet immédiatement après, des frais de suppression anticipée de 30 jours vous seront facturés, car le délai de réécriture devient le nouveau délai de création. De même, si vous attendez 10 jours après la réécriture pour supprimer l'objet, des frais de suppression anticipée vous seront facturés sur 20 jours.

Métadonnées de délai d'expiration

Si une opération de suppression (Delete) est spécifiée pour un bucket avec la condition Age (et sans condition NumberOfNewerVersions), certains objets peuvent être étiquetés avec des métadonnées de délai d'expiration. Le délai d'expiration d'un objet indique l'heure et la date à laquelle la gestion du cycle de vie des objets peut (ou pouvait) supprimer l'objet. Le délai d'expiration peut changer en même temps que la configuration du cycle de vie du bucket ou que la stratégie de conservation.

Notez que l'absence de métadonnées de délai d'expiration ne signifie pas nécessairement que l'objet ne sera pas supprimé, mais plutôt que les informations disponibles sont insuffisantes pour déterminer quand et s'il sera supprimé. Par exemple, si l'heure de création d'un objet est 2013/01/10 10:00 UTC et que la condition Age est définie à 10 jours, la condition est satisfaite pour l'objet à partir de 2013/01/20 10:00 UTC. Toutefois, l'heure d'expiration ne sera pas disponible pour l'objet si :

  • la condition NumberOfNewerVersions est également spécifiée. Dans ce cas, les anciennes versions de l'objet peuvent encore être supprimées si de nouvelles versions sont ajoutées ;

  • la condition CreatedBefore est également spécifiée et définie sur "2013-01-01", car l'objet ne satisfait pas cette condition ;

  • l'objet est en attente, car Cloud Storage ne peut pas savoir quand la mise en attente sera supprimée.

Le stockage ne vous est pas facturé après le délai d'expiration de l'objet, même si l'objet n'est pas supprimé immédiatement. Vous pouvez continuer à accéder à l'objet avant sa suppression. Dans ce cas, d'autres frais (requête, bande passante réseau) vous seront facturés. Si le délai d'expiration n'est pas disponible pour un objet, le stockage de cet objet est facturé jusqu'au moment de sa suppression.

Vous pouvez accéder au délai d'expiration d'un objet dans ses métadonnées si elles sont disponibles. L'API REST renvoie l'heure d'expiration de l'objet dans l'en-tête de réponse x-goog-expiration.

Lorsque vous travaillez avec des délais d'expiration, tenez compte des points suivants :

  • Si le bucket dispose d'une stratégie de conservation, le délai d'expiration correspond au dernier de la condition d'âge de la gestion du cycle de vie d'un objet et au délai pendant lequel l'objet respecte la durée de conservation spécifiée par la stratégie de conservation.

  • S'il existe plusieurs délais d'expiration contradictoires applicables pour un objet en raison de règles de gestion du cycle de vie différentes, le délai d'expiration le plus ancien est utilisé.

Options de suivi des opérations du cycle de vie

Pour suivre les opérations de gestion du cycle de vie qu'effectue Cloud Storage, utilisez l'une des options suivantes :

  • Utilisez les journaux d'accès Cloud Storage. Cette fonctionnalité enregistre l'opération et le nom de son auteur. Une valeur de GCS Lifecycle Management dans le champ cs_user_agent de l'entrée de journal indique que l'opération a été exécutée par Cloud Storage conformément à une configuration de cycle de vie.

  • Activez les notifications Cloud Pub/Sub pour Cloud Storage pour votre bucket. Cette fonctionnalité envoie des notifications au sujet Cloud Pub/Sub de votre choix lorsque des opérations spécifiées se produisent. Notez que cette fonctionnalité n'enregistre pas l'auteur des opérations.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.