Object Storage - Gestion intelligente du stockage avec des règles lifecycle

Objectif

Découvrez comment optimiser vos coûts de stockage avec les règles lifecycle d'OVHcloud.

Introduction

Qu'est-ce qu'un lifecycle ?

Le bucket lifecycle dans OVHcloud Object Storage est une fonctionnalité qui vous permet d'optimiser vos coûts de stockage en gérant vos objets tout au long de leur cycle de vie (lifecycle). En téléversant une configuration de lifecycle vers un bucket, vous définissez un ensemble de règles que la solution Object Storage applique aux objets du bucket pour effectuer des actions spécifiques.

Il y a 2 types d'actions qu'OVHcloud Object Storage effectue sur vos objets :

• expiration : ces actions déterminent la date d'expiration de vos objets. Les objets expirés sont alors automatiquement supprimés.
• transition : ces actions déterminent le moment où vos objets sont transférés vers un niveau de stockage moins coûteux. Par exemple, vous pourriez vouloir transférer vos objets stockés dans le niveau Haute performance vers le niveau Standard après 30 jours.

Exemples de cas d'usage

La configuration du lifecycle vous permet de demander à OVHcloud Object Storage de :

• nettoyer les téléversements multi-parties incomplets : supposons que vous ayez téléversé un grand nombre d'objets volumineux (>5GB) en utilisant des téléversements multi-parties, mais que pour certaines raisons, pour de nombreux objets, le téléversement multi-parties ne s'est pas terminé avec succès. Dans ce cas, même si vous n'avez pas téléversé toutes les parties d'un objet, vous devez quand même payer le coût de stockage des parties téléversées. Dans ce cas, vous pourriez vouloir nettoyer les parties de tous les téléversements multi-parties incomplets afin d'économiser de l'argent.
• nettoyer les anciennes données inutilisées : supposons que vous ayez une application qui stocke ses logs dans un bucket. Votre organisation peut définir une politique de conservation des logs de 30 jours. Passé ce délai, les logs ne sont plus nécessaires et vous voudrez peut-être les supprimer pour économiser de l'argent.
• optimiser les coûts de stockage en transférant les données rarement consultées vers un niveau de stockage moins coûteux : supposons que vous ayez certains fichiers qui sont souvent utilisés pendant une brève période avant d'être à peine réutilisés. Vous n'aurez peut-être plus besoin d'y accéder immédiatement, mais votre organisation ou la législation peut vous obliger à les conserver pendant un certain temps. Une fois ce délai écoulé, vous pouvez les supprimer pour économiser de l'argent.

Considérations particulières

Lorsqu'un objet atteint la fin de sa durée de vie selon la configuration de son lifecycle, le résultat des actions de transition ou d'expiration effectuées par OVHcloud Object Storage varie en fonction de l'état de versioning du bucket :

• non versionné : il n'existe qu'une seule version de l'objet, la version courante, et elle est supprimée définitivement.
• versionné : un marqueur de suppression est créé et devient la version courante. Vous pouvez également choisir le nombre d'anciennes versions que vous souhaitez conserver. Si la version courante de l'objet est la seule version de l'objet et qu'il s'agit également d'un marqueur de suppression, ce dernier sera supprimé.
• versioning suspendu : actuellement, nous ne permettons pas la suspension du versioning si vous avez une configuration de lifecycle en vigueur. De la même manière, nous ne permettons pas le téléversement d'une configuration de lifecycle si le versioning est suspendu sur le bucket.

Expiration

Les règles de lifecycle sont traitées de manière asynchrone et dans la mesure du possible. La plupart des règles sont appliquées dans les 24 heures, mais cela peut prendre plus de temps dans le cas d'un très grand nombre d'objets ou lors du traitement de nombreux objets. Pendant ce délai, vous continuez à être facturé pour le niveau de stockage actuel de l'objet, même si la règle (par exemple, l'expiration ou la transition) a déjà été déclenchée mais n'est pas encore terminée. Par exemple, si un objet doit être supprimé le 30e jour, mais qu'il n'est traité que le 32e jour, vous pouvez être facturé pour deux jours supplémentaires.

Dates d'expiration conflictuelles

En règle générale, la fonction lifecycle est conçue pour vous aider à optimiser vos coûts de stockage. Par exemple, si deux règles d'expiration se chevauchent, c'est-à-dire qu'elles ciblent le même ensemble d'objets mais avec des dates d'expiration différentes, la règle avec la durée la plus courte est appliquée, garantissant que les données ne sont pas conservées au-delà du délai prévu : OVHcloud Object Storage essaie toujours de choisir la voie la plus rentable pour vous.

En règle générale, lorsque plusieurs règles s'appliquent au même ensemble d'objets dans une configuration de bucket lifecycle :

• La suppression permanente a la priorité sur la transition.
• La transition a la priorité sur la création de marqueurs de suppression.
• La date d'expiration/de transition la plus courte a la priorité sur la plus longue.

Versions courantes et versions non courantes

Dans un bucket versionné, chaque objet a une version courante et zéro ou plusieurs versions non courantes. Lorsque vous supprimez un objet :

• Si vous ne spécifiez pas d'identifiant de version dans votre demande de suppression, un marqueur de suppression est créé au lieu de supprimer l'objet. La version courante de l'objet devient non courante et le marqueur de suppression devient la version courante.
• Si vous spécifiez un ID de version dans votre demande de suppression, la version de l'objet spécifiée est définitivement supprimée (aucun marqueur de suppression n'est créé).
• Un marqueur de suppression avec zéro version non courante est appelé marqueur de suppression d'objet expiré.

Configuration

Voici la structure de base d'une configuration JSON pour un lifecycle contenant des règles d'expiration

{
  "Rules": [
    {
      "ID": "string",
      "Status": "Enabled"|"Disabled",
      "Filter": {
        "Prefix": "string",
        "Tag": {
          "Key": "string",
          "Value": "string"
        },
        "ObjectSizeGreaterThan": long,
        "ObjectSizeLessThan": long,
        "And": {
          "Prefix": "string",
          "Tags": [
            {
              "Key": "string",
              "Value": "string"
            }
          ],
          "ObjectSizeGreaterThan": long,
          "ObjectSizeLessThan": long
        }
      },
      "Expiration": {
        "Date": timestamp,
        "Days": integer,
        "ExpiredObjectDeleteMarker": "true"|"false"
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": integer,
        "NewerNoncurrentVersions": integer
      },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": integer
      }
    }
  ]
}

Comprendre le paramètre NoncurrentDays

Le paramètre NoncurrentDays définit le nombre minimum de jours écoulés depuis qu'une version n'est plus la version courante. Ce paramètre ne doit pas être confondu avec l'âge de l'objet mais indique plutôt l'âge minimum d'une version non-courante.

Exemple 1:

Supposons que vous avez un objet A avec 10 versions :

• A v10 (version courante, date de création: 2024-10-23).
• A v9 (version non-courante, date de création: 2024-10-22).
• A v8 (version non-courante, date de création: 2024-10-21).
• A v7 (version non-courante, date de création: 2024-10-20).
• A v6 (version non-courante, date de création: 2024-10-19).
• A v5 (version non-courante, date de création: 2024-10-18).
• A v4 (version non-courante, date de création: 2024-10-17).
• A v3 (version non-courante, date de création: 2024-10-16).
• A v2 (version non-courante, date de création: 2024-10-15).
• A v1 (version non-courante, date de création: 2024-10-14).

Si la date actuelle est 2024-10-23 et NoncurrentDays=5, la règle de lifecycle supprimera les versions non-courantes de plus de 5 jours : v1, v2, v3 et v4, car :

• A v1 est non-courante depuis 2024-10-15 (quand A v2 a été créée) : son âge en tant que version non-courante est 8 jours.
• A v2 est non-courante depuis 2024-10-16 (quand A v3 a été créée) : son âge en tant que version non-courante est 7 jours.
• A v3 est non-courante depuis 2024-10-17 (quand A v4 a été créée) : son âge en tant que version non-courante est 6 jours.
• A v4 est non-courante depuis 2024-10-18 (quand A v5 a été créée) : son âge en tant que version non-courante est 5 jours.

Exemple 2:

Supposons que vous avez un objet B avec 5 versions :

• B v5 (version courante, date de création: 2024-10-28).
• B v4 (version non-courante, date de création: 2024-10-27).
• B v3 (version non-courante, date de création: 2024-10-20).
• B v2 (version non-courante, date de création: 2024-10-15).
• B v1 (version non-courante, date de création: 2024-10-14).

Si la date actuelle est 2024-10-29 et NoncurrentDays=5, la règle de lifecycle supprimera les versions non-courantes de plus de 5 jours : uniquement v1 et v2, car :

• B v1 est non-courante depuis 2024-10-15 (quand B v2 a été créée) : son âge en tant que version non-courante est 14 jours.
• B v2 est non-courante depuis 2024-10-20 (quand B v3 a été créée) : son âge en tant que version non-courante est 9 jours.

Obtenir la date d'expiration programmée

Si un objet est programmé pour être supprimé, un appel HEAD-OBJECT renvoie un en-tête de réponse http spécial x-amz-expiration qui contient un timestamp indiquant sa date d'expiration et un identifiant de la règle du lifecycle qui a été appliquée.

Le format de l'en-tête est le suivant : x-amz-expiration: expiry-date=<timestamp>, rule-id=<rule_id>

• expiry-date : obtenue en additionnant la date de création et le délai d'expiration
• rule-id : l'identifiant de la règle correspondante qui déclenche la suppression

Exemple : Obtenir la date d'expiration via un appel API http direct

HEAD /{key}
Host: {bucket}.s3.{region}.io.cloud.ovh.net
...

HTTP/1.1 200 OK
...
x-amz-expiration: expiry-date="Fri, 21 Dec 2024 00:00:00 GMT", rule-id="123456789"

Exemple : Obtenir la date d'expiration via le CLI

aws s3api head-object --bucket <bucket_name> --key <object_key>
{
  ...
  "Expiration" : "expiry-date=\"Fri, 21 Dec 2024 00:00:00 GMT\", rule-id=\"123456789\"",
  ...
}

Exemples de configurations d'expiration

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": { },
      "Expiration": {
        "Days": 1
      }
    }
  ]
}

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "/mpus"
      },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    }
  ]
}

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "/old"
      },
      "Expiration": {
        "Days": 30
      }
    },
    {
      "ID": "456789",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "/old/logs"
      },
      "Expiration": {
        "Days": 65
      }
    }
  ]
}

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": {
        "Tag": {
           "Key": "age",
           "Value": "old"
        }
      },
      "Expiration": {
        "Days": 30
      }
    },
    {
      "ID": "456789",
      "Status": "Enabled",
      "Filter": {        
        "Tag": {
           "Key": "type",
           "Value": "logs"
        }
      },
      "Expiration": {
        "Days": 65
      }
    }
  ]
}

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": { },
      "Expiration": {
        "Days": 1
      }
    },
    {
      "ID": "78910",
      "Status": "Enabled",
      "Filter": { },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 1
      }
    }
  ]
}

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": { },
      "Expiration": {
        "Days": 1
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 1
      }
    },
    {
      "ID": "654789",
      "Status": "Enabled",
      "Filter": { },
      "Expiration": {
        "ExpiredObjectDeleteMarker": true
      }
    },
    {
      "ID": "963852",
      "Status": "Enabled",
      "Filter": { },
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 1
      }
    }
  ]
}

Transition

Transitions supportées

Les transitions actuellement prises en charge sont les suivantes :

Taille minimale de l'objet

OVHcloud Object Storage empêchera toute transition vers un autre niveau de stockage pour les objets inférieurs à 128Ko. Cependant, vous pouvez autoriser les transitions et les expirations pour les objets plus petits en utilisant les paramètres ObjectSizeGreaterThan ou ObjectSizeLessThan pour filtrer avec une taille minimale ou maximale. Dans l'exemple suivant, les objets de moins de 128 Ko sont également autorisés à passer à la classe Standard.

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": {
        "And":{
            "ObjectSizeGreaterThan": 1
        }
      },      
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD"
        }
      ]
     }
  ]
}

Délai de transition minimal

La durée minimale des règles de transition est de 30 jours, ce qui signifie que votre configuration de lifecycle ne sera pas valide et que vous obtiendrez une erreur si le nombre de jours pour votre règle de transition est inférieur à 30 jours. En pratique, cela signifie que la fonction de lifecycle ne prendra en compte que les objets datant de plus de 30 jours. Par exemple, supposons que vous téléversez un objet dans le niveau de stockage High Performance et que vous souhaitez le faire passer au niveau de stockage Standard après un certain temps, puis de Standard à Standard Infrequent Access après un autre laps de temps. Cela signifierait que: - votre objet ne pourra passer de High Performance à Standard qu'après 30 jours - votre objet ne pourra passer de Standard à Standard Infrequent Access qu'après 60 jours (30 jours après la précédente transition)

Expiration vs transitions

Comme nous l'avons déjà mentionné, lorsque vous avez plusieurs règles dans une configuration de bucket lifecycle qui s'appliquent au même ensemble d'objets :

• La suppression permanente a la priorité sur la transition.
• La transition est prioritaire sur la création de marqueurs de suppression.
• La date d'expiration/de transition la plus courte est prioritaire sur la plus longue.

Configuration

Voici la structure de base d'une configuration d'un lifecycle JSON contenant des règles de transition :

{
  "Rules": [
    {   
       ...

       "Transitions": [
           {
             "Date": timestamp,
             "Days": integer,
             "StorageClass": "STANDARD"
           }
        ],
       "NoncurrentVersionTransitions": [
          {
              "NoncurrentDays": integer,
              "StorageClass": "STANDARD",
              "NewerNoncurrentVersions": integer
          }
       ]
    }
  ]
}

Exemples de configurations de transition

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "old/"
      },      
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD"
        }
      ]
     }
  ]
}

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": { },      
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD"
        }
      ],
      "NoncurrentVersionTransitions": [
        {
          "NoncurrentDays": 30,
          "StorageClass": "STANDARD"
        }
       ]
     }
  ]
}

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": {
        "And": {
            "Prefix": "old/",
            "Tag": {
              "Key": "type",
              "Value": "logs"
            }
        }
      },
      "Expiration": {
        "Days": 90,
      },      
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD"
        }
      ]
    }
  ]
}

{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": {
        "And":{
            "Prefix": "old/",
            "Tag": {
              "Key": "type",
              "Value": "logs"
            }
        }
      },
      "Expiration": {
        "Days": 90,
      }
    },
    {
      "ID": "456789",
      "Status": "Enabled",
      "Filter": {
        "And":{
            "Prefix": "old/",
            "Tag": {
              "Key": "type",
              "Value": "logs"
            }
        }
      },
      "Transitions": [
        {
          "Days": 90,
          "StorageClass": "STANDARD"
        }
      ]
    }
  ]
}

En pratique

Via le CLI

Comme prérequis, vous devez avoir un bucket contenant des données sur lesquelles vous voulez appliquer la configuration du lifecycle et avoir les permissions nécessaires (par défaut le propriétaire du bucket ou la permission s3:putLifecycleConfiguration donnée via une politique d'accès utilisateur) pour le faire.

cat lifecycle.json
{
  "Rules": [
    {
      "ID": "123456",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "old/"
      },
      "Expiration": {
        "Days": 45
      },
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 15,
        "NewerNoncurrentVersions": 3
      }
    }
  ]
}

aws s3api put-bucket-lifecycle-configuration --bucket my-bucket --lifecycle-configuration file://lifecycle.json

Via l'espace client OVHcloud (à venir)

FAQ

Pourquoi mes objets n'ont-ils pas encore expiré alors que j'ai mis en place des règles de cycle de vie ?

Les règles de cycle de vie sont traitées de manière asynchrone et dans la mesure du possible. La plupart des règles sont appliquées dans les 24 heures, mais cela peut prendre plus de temps dans le cas d'un très grand nombre d'objets. Pendant ce délai, vous continuez à être facturé pour la classe de stockage actuelle de l'objet, même si la règle (par exemple, l'expiration ou la transition) a déjà été déclenchée mais n'est pas encore terminée.

Pourquoi le nombre d'objets de mon bucket versionné continue-t-il d'augmenter alors que j'ai mis en place des règles de cycle de vie ?

Lorsqu'une opération de suppression (expiration) d'un objet est effectuée dans un bucket versionné, l'objet n'est pas directement supprimé. Un marqueur de suppression est créé sur l'objet. Ce marqueur de suppression devient la version la plus récente de l'objet avec un nouvel identifiant de version, ce qui augmente le nombre d'objets dans le bucket.

Une configuration supplémentaire est nécessaire pour supprimer définitivement les objets, y compris les téléversements en plusieurs parties (multipart uploads) incomplets, les marqueurs de suppression expirés et les versions antérieures des objets.

Comment vider mon bucket S3¹ à l'aide des règles de cycle de vie ?

Pour vider un bucket S3, vous devez prendre en compte les éléments suivants :

• expirer les versions actuelles des objets
• supprimer les versions précédentes des objets
• supprimer les marqueurs de suppression expirés
• supprimer les multipart uploads incomplets

Comment puis-je contrôler les actions entreprises par mes règles de cycle de vie ?

Vous pouvez utiliser la fonctionnalité Server Access Logging pour surveiller les actions effectuées par vos règles de cycle de vie sur votre bucket S3. La journalisation des accès serveur fournit des journaux détaillés des requêtes effectuées sur un bucket, y compris les opérations d'expiration, les transitions d'objets vers une autre classe de stockage, etc.

Comment puis-je récupérer des objets supprimés par mes règles de cycle de vie ?

Le versioning est le seul moyen de récupérer des objets qui ont été expirés. Il doit être activé sur votre bucket avant que vous ne configuriez vos règles de cycle de vie. Cependant, les objets qui sont définitivement supprimés par les règles de cycle de vie ne peuvent pas être récupérés.

Comment exclure des préfixes de mes règles de cycle de vie ?

L'exclusion de préfixes n'est pas prise en charge.

J'ai mis en place des règles de réplication entre 2 buckets S3 : pourquoi les objets supprimés dans mon bucket source par mes règles de cycle de vie ne sont-ils pas supprimés dans le bucket de destination ?

Les opérations de suppression résultant de l'application des règles de cycle de vie ne sont pas répliquées. Voir la documentation sur la réplication asynchrone pour plus de détails sur ce qui est répliqué et ce qui ne l'est pas.

Aller plus loin

Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur ce lien pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services.

Échangez avec notre communauté d'utilisateurs.

¹ : S3 est une marque déposée appartenant à Amazon Technologies, Inc. Les services de OVHcloud ne sont pas sponsorisés, approuvés, ou affiliés de quelque manière que ce soit.