Utilisez des règles de cycle de vie basées sur la dernière date d'accès pour surveiller automatiquement les modèles d'accès aux données et identifier les données froides. Transférez ensuite ces données vers une classe de stockage différente. Cette approche met en place un stockage hiérarchisé pour les données chaudes et froides, réduisant ainsi vos coûts de stockage.
Scénarios
-
Multimédia
Un site web stocke ses vidéos et images dans OSS. Avec le temps, les données historiques passent progressivement du statut « chaud » au statut « froid ». Vous pouvez transférer les données inutilisées depuis longtemps vers la classe de stockage Infrequent Access. Toutefois, certaines données anciennes restent populaires et doivent rester dans la classe de stockage Standard. Dans ce scénario, utilisez une règle de cycle de vie basée sur la dernière date d'accès pour identifier automatiquement les données chaudes et froides et mettre en place un stockage hiérarchisé, ce qui réduit les coûts de stockage.
-
Albums photo ou lecteurs cloud
Définissez une période de transition personnalisée pour déplacer automatiquement les données froides, inutilisées depuis une période prolongée, vers la classe de stockage Infrequent Access, tout en garantissant un accès en temps réel.
-
Sciences de la vie
Le volume important de données métier générées par le séquençage génétique est souvent classé comme chaud ou froid selon la dernière date d'accès plutôt que la dernière date de modification. Auparavant, les clients ne pouvaient gérer la hiérarchisation des données que manuellement, en analysant les journaux ou via d'autres méthodes. Une règle de cycle de vie basée sur la dernière date d'accès permet au serveur d'identifier automatiquement les données chaudes et froides et de mettre en œuvre un stockage hiérarchisé. Vous pouvez également combiner des politiques basées à la fois sur la dernière date d'accès et la dernière date de modification au sein d'une même règle de cycle de vie pour une gestion plus flexible des données.
Limites
Aucune suppression de données
Les règles de cycle de vie basées sur la dernière date d'accès ne permettent pas de supprimer des données.
Conditions de correspondance
Les règles de cycle de vie prennent uniquement en charge la correspondance basée sur les préfixes et les tags. La correspondance par caractères génériques, par suffixe et par expression régulière n'est pas prise en charge.
Limites d'expiration des parties
Vous ne pouvez pas configurer deux règles de cycle de vie ou plus contenant une politique de cycle de vie pour les parties, si les objets concernés ont des noms avec des préfixes qui se chevauchent. Exemples :
-
Exemple 1
Si vous configurez une règle de cycle de vie contenant une politique de partie pour un bucket, vous ne pouvez pas configurer une autre règle de cycle de vie contenant une politique de partie pour les objets de ce bucket.
-
Exemple 2
Si vous configurez une règle de cycle de vie contenant une politique de partie pour les objets dont les noms contiennent le préfixe dir1 dans un bucket, vous ne pouvez pas configurer une autre règle de cycle de vie contenant une politique de partie pour les objets dont les noms contiennent des préfixes qui se chevauchent, tels que dir1/dir2.
Notes d'utilisation
Limite de règles
Un bucket peut contenir jusqu'à 1 000 règles de cycle de vie. Une règle de cycle de vie peut inclure à la fois des politiques basées sur la dernière date de modification et des politiques basées sur la dernière date d'accès.
Sémantique d'écrasement
L'opération PutBucketLifecycle écrase la configuration existante des règles de cycle de vie d'un bucket. Par exemple, si une règle de cycle de vie nommée Rule1 est configurée pour un bucket et que vous souhaitez ajouter une autre règle nommée Rule2, procédez comme suit :
Appelez l'opération GetBucketLifecycle pour récupérer Rule1.
Ajoutez Rule1 et Rule2 à la configuration des règles de cycle de vie.
Appelez l'opération PutBucketLifecycle pour appliquer Rule1 et Rule2 au bucket.
Heure de prise d'effet
Après la création d'une règle de cycle de vie, OSS la charge sous 24 heures. Une fois chargée, OSS commence à l'exécuter tous les jours à 08:00 (UTC+8).
Durée d'exécution
Une fois la règle active, les opérations de cycle de vie telles que la suppression d'objets, la transition de classe de stockage et l'expiration des parties de téléchargement multipartie sont généralement achevées sous 24 heures pour un maximum de 1 milliard d'objets dans les régions Chine (Hangzhou), Chine (Shanghai), Chine (Pékin), Chine (Zhangjiakou), Chine (Ulanqab), Chine (Shenzhen) et Singapour. Dans les autres régions, ces opérations sont généralement achevées sous 24 heures pour un maximum de 100 millions d'objets.
-
L'exécution peut dépasser 24 heures, voire prendre plusieurs jours ou semaines, en cas de grand nombre d'objets à analyser, d'objets concernés par la règle, de tags, de versions pour un seul objet, ou d'un volume élevé de nouveaux objets écrits pendant l'exécution de la tâche de cycle de vie.
RemarqueSi le versioning est activé pour le bucket, chaque opération sur une version d'un objet compte comme une opération distincte.
Facturation
-
Frais de surveillance et de gestion des objets
L'activation du suivi d'accès entraîne des frais de surveillance et de gestion des objets. Toutefois, OSS ne facture actuellement pas ces frais.
-
Frais liés au non-respect de la durée minimale de stockage pour Infrequent Access
Les objets de la classe de stockage Infrequent Access ont une durée minimale de stockage de 30 jours. Si un objet est stocké moins de 30 jours, vous êtes facturé pour la partie restante de cette durée minimale. Les exemples suivants illustrent le fonctionnement de cette facturation avec les règles de cycle de vie :
Exemple 1 : Une règle de cycle de vie transfère un objet Standard vers la classe de stockage Infrequent Access 10 jours après sa création. Cinq jours plus tard, il revient à la classe de stockage Standard. Dans ce cas, vous êtes facturé pour 15 jours de stockage afin de respecter la durée minimale de stockage requise pour Infrequent Access.
Exemple 2 : Une règle de cycle de vie transfère un objet Standard vers la classe de stockage Infrequent Access 10 jours après sa création. L'objet est supprimé 15 jours plus tard. Dans ce cas, vous êtes facturé pour 5 jours de stockage afin de respecter la durée minimale de stockage requise pour Infrequent Access.
Pour plus d'informations, consultez Frais de stockage.
-
Frais de récupération de données pour Infrequent Access
Les frais d'accès aux fichiers de la classe de stockage Infrequent Access sont calculés selon le volume de données récupérées. Pour plus d'informations, consultez Frais de traitement des données.
-
Frais de requête
Une règle de cycle de vie engendre des frais de requête lors de la transition de classe de stockage d'un objet. Pour plus d'informations, consultez Frais de requête.
Autres considérations
-
Politique de mise à jour de la dernière date d'accès :
Après l'activation du suivi d'accès, OSS met à jour le
LastAccessTimed'un objet selon les règles suivantes :Initialisation : Lors de l'activation du suivi d'accès, OSS définit le LastAccessTime de tous les objets du bucket à l'heure d'activation du suivi.
Règles de mise à jour : Après l'initialisation, des opérations telles que le téléchargement ou l'écrasement d'un objet mettent à jour le
LastAccessTimede l'objet. Pour savoir quelles opérations mettent à jour leLastAccessTimed'un objet, consultez Impact des opérations courantes sur la dernière date d'accès des objets.-
Mécanisme de mise à jour :
La mise à jour du
LastAccessTimeest asynchrone et se termine généralement sous 24 heures.Si le même objet est consulté plusieurs fois sous 24 heures, OSS enregistre l'heure du premier accès comme
LastAccessTimede l'objet. Les accès ultérieurs dans cette période de 24 heures ne déclenchent pas de mise à jour.
-
Classes de stockage des objets pour la transition :
Les règles de cycle de vie basées sur la dernière date d'accès permettent de transférer des objets de la classe de stockage Standard vers la classe de stockage Infrequent Access. Vous pouvez également choisir de retransférer automatiquement un objet vers la classe de stockage Standard lors de son accès.
-
Les règles de cycle de vie basées sur la dernière date d'accès permettent de transférer des objets des classes de stockage Standard ou Infrequent Access vers les classes Archive, Cold Archive ou Deep Cold Archive. Vous pouvez également transférer des objets de la classe Archive vers Cold Archive ou Deep Cold Archive. Pour transférer des objets des classes Standard ou Infrequent Access vers Archive, Cold Archive ou Deep Cold Archive, soumettez un ticket pour demander les autorisations nécessaires. Une fois votre demande approuvée, vous devez spécifier la classe de stockage de destination.
ImportantAprès approbation du ticket, si vous utilisez une politique basée sur la dernière date d'accès pour transférer un objet des classes Standard ou Infrequent Access vers Archive, Cold Archive ou Deep Cold Archive, la dernière date d'accès de l'objet dans la classe de destination correspond par défaut à l'heure d'activation du suivi d'accès pour le bucket.
-
Configurer des règles de cycle de vie dans un bucket avec OSS-HDFS activé :
Pour configurer ou modifier une règle de cycle de vie basée sur la dernière date d'accès afin qu'elle s'applique à tous les objets d'un bucket avec OSS-HDFS activé, utilisez l'élément NOT pour exclure les objets stockés dans le répertoire
.dlsdata/. Cela empêche les actions de suppression d'objets ou de conversion de classe de stockage déclenchées par la règle de s'appliquer aux données OSS-HDFS, évitant ainsi d'affecter les opérations de lecture et d'écriture sur ces données.
Procédure
Console OSS
Connectez-vous à la console OSS.
Dans le volet de navigation de gauche, cliquez sur Buckets. Sur la page qui s'affiche, cliquez sur le nom du bucket cible.
Dans le volet de navigation de gauche, choisissez .
Sur la page Lifecycle, activez l'interrupteur Enable Access Tracking, puis cliquez sur Create Rule.
-
Dans le panneau Create Lifecycle Rule, configurez la règle de cycle de vie selon les descriptions suivantes.
-
Le versioning du bucket est désactivé
Section
Paramètre
Description
Basic Settings
Status
Définissez le statut de la règle de cycle de vie. Vous pouvez sélectionner Enabled ou Disabled.
-
Si vous activez la règle de cycle de vie, OSS modifie les classes de stockage des données selon la règle.
-
Si vous désactivez la règle de cycle de vie, la tâche de cycle de vie est suspendue.
Applied To
Sélectionnez les objets auxquels la règle de cycle de vie s'applique. Vous pouvez sélectionner Objects with Specified Prefix ou Whole Bucket.
Allow Overlapped Prefixes
Par défaut, OSS vérifie si les préfixes des règles de cycle de vie se chevauchent. Par exemple, vous définissez les deux règles de cycle de vie suivantes avec des préfixes qui se chevauchent :
-
Règle 1
Transfère tous les objets avec le préfixe
dir1/du bucket vers la classe de stockage Infrequent Access 180 jours après leur dernière date d'accès. -
Règle 2
Transfère tous les objets avec le préfixe
dir1/dir2/du bucket vers la classe de stockage Archive 30 jours après leur dernière date d'accès.
Si cette option n'est pas sélectionnée, OSS rejette cette configuration car les objets du répertoire
dir1/dir2/correspondraient aux deux règles de transition.Si cette option est sélectionnée, les objets du répertoire
dir1/dir2/sont transférés vers la classe de stockage Archive après 30 jours. Les autres objets du répertoiredir1/sont transférés vers la classe de stockage Infrequent Access après 180 jours.Prefix
Saisissez le préfixe d'objet que la règle doit faire correspondre.
-
Si vous définissez le préfixe sur img, la règle correspond à tous les objets dont les noms commencent par img, tels que imgtest.png et img/example.jpg.
-
Si vous définissez le préfixe sur img/, la règle correspond à tous les objets dont les noms commencent par img/, tels que img/example.jpg et img/test.jpg.
Tag
La règle de cycle de vie s'applique uniquement aux objets portant le tag spécifié. Par exemple, si vous sélectionnez Objects with Specified Prefix, définissez le préfixe sur img et définissez la clé de tag sur a et la valeur sur 1, la règle correspond à tous les objets dont les noms commencent par img et qui ont le tag a=1. Pour plus d'informations sur les tags d'objet, consultez Marquage d'objets.
NOT
Utilisez l'option NOT pour exclure les objets ayant un préfixe et un tag spécifiés de la règle de cycle de vie.
Important-
Si l'option NOT est activée, vous devez spécifier au moins un préfixe ou un tag.
-
La clé définie pour le tag dans la condition NOT ne peut pas être la même que la clé définie dans le paramètre Tag.
-
Si l'option NOT est activée, vous ne pouvez pas configurer de politique d'expiration des parties.
Object Size
Spécifiez la taille d'objet à laquelle la règle de cycle de vie s'applique.
-
Minimum Size : La règle de cycle de vie s'applique aux objets plus grands que cette valeur. La valeur doit être supérieure à 0 o et inférieure à 5 To.
-
Maximum Size : La règle de cycle de vie s'applique aux objets plus petits que cette valeur. La valeur doit être supérieure à 0 o et inférieure ou égale à 5 To.
ImportantSi vous configurez à la fois la Taille minimale et la Taille maximale dans la même règle de cycle de vie, tenez compte des éléments suivants :
-
Assurez-vous que la valeur de la Taille maximale est supérieure à la valeur de la Taille minimale.
-
Vous ne pouvez pas configurer de politique d'expiration des parties.
-
Vous ne pouvez pas configurer de politique pour effacer les marqueurs de suppression.
Policy for Objects
Object Lifecycle
Sélectionnez une politique d'expiration pour les objets. Vous pouvez sélectionner Validity Period (Days), Expiration Date ou Disabled. Si vous sélectionnez Disabled, la politique d'expiration des objets ne prend pas effet.
Lifecycle-based Rules
Configurez la règle pour modifier la classe de stockage des objets. Les données peuvent être transférées vers les classes de stockage suivantes :
-
IA (Data Remains in IA After Access)
-
IA (Data Is Converted to Standard After Access)
-
Archive
-
Cold Archive
-
Deep Cold Archive
Par exemple, si vous sélectionnez la politique Access Time, définissez la Validity Period (Days) sur 30 et spécifiez que les données sont automatiquement transférées vers IA (Data Remains in IA After Access) après la période spécifiée, un objet consulté pour la dernière fois le 1er septembre 2021 est transféré vers cette classe de stockage le 1er octobre 2021.
Policy for Parts
Part Lifecycle
Définissez l'action à effectuer sur les parties expirées. Si vous avez spécifié un Tag, vous ne pouvez pas configurer ce paramètre. Vous pouvez sélectionner Validity Period (Days) ou Expiration Date pour la politique d'expiration des parties, ou sélectionner Disabled. Si vous sélectionnez Disabled, la politique d'expiration des parties ne prend pas effet.
ImportantUne règle de cycle de vie doit inclure au moins une politique d'expiration des objets ou une politique d'expiration des parties.
Rules for Parts
Spécifiez quand les parties expirent en fonction de la période de validité ou de la date d'expiration sélectionnée dans la politique d'expiration des parties. Les parties expirées sont automatiquement supprimées et ne peuvent pas être récupérées.
-
-
Le versioning du bucket est activé
Après avoir activé le versioning, les éléments de configuration dans les sections Basic Settings et Policy for Parts sont configurés de la même manière que lorsque le versioning est désactivé. Le tableau suivant décrit uniquement les différences de configuration lorsque le versioning est activé.
Section
Paramètre
Description
Policy for Current Versions
Clear delete markers
Après l'activation du versioning, l'option Clear Delete Markers est ajoutée à la politique de nettoyage. Les autres options sont identiques à celles lorsque le versioning est désactivé.
Si vous sélectionnez cette option et que la version actuelle d'un objet est la seule version et qu'il s'agit d'un marqueur de suppression, OSS supprime le marqueur de suppression de l'objet expiré. Si l'objet possède plusieurs versions et que la dernière version est un marqueur de suppression, OSS conserve le marqueur de suppression. Pour plus d'informations sur les marqueurs de suppression, consultez Marqueurs de suppression.
Policy for Previous Versions
Object Lifecycle
Définissez la politique d'expiration pour les versions non actuelles des objets. Vous pouvez sélectionner Validity Period (Days) ou Disabled. Si vous sélectionnez Disabled, la politique d'expiration des objets ne prend pas effet.
Lifecycle-based Rules
Définissez une période de N jours. Après qu'une version non actuelle d'un objet a été consultée, elle est transférée vers une classe de stockage différente après N jours. Par exemple, si vous définissez la période sur 30 jours, une version non actuelle consultée le 1er septembre 2021 est transférée vers la classe de stockage spécifiée le 1er octobre 2021.
-
-
Cliquez sur OK.
Après avoir enregistré la règle, elle apparaît dans la liste des politiques.
SDK
Les SDK OSS pour Java, Go, Python et PHP prennent en charge la création de règles de cycle de vie basées sur la dernière date d'accès. Avant de créer une telle règle, vous devez activer le suivi d'accès pour le bucket spécifié. Pour obtenir des exemples de code, consultez Vue d'ensemble des SDK.
Java
import com.aliyun.oss.*;
import com.aliyun.oss.common.auth.*;
import com.aliyun.oss.common.comm.SignVersion;
import com.aliyun.oss.model.*;
import java.util.ArrayList;
import java.util.List;
public class Demo {
public static void main(String[] args) throws Exception {
// In this example, the endpoint of the China (Hangzhou) region is used. Specify your actual endpoint.
String endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
// Obtain access credentials from environment variables. Before you run the sample code, make sure that the OSS_ACCESS_KEY_ID and OSS_ACCESS_KEY_SECRET environment variables are configured.
EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
// Specify the name of the bucket. Example: examplebucket.
String bucketName = "examplebucket";
// Specify the region in which the bucket is located. For example, if the bucket is located in the China (Hangzhou) region, set the region to cn-hangzhou.
String region = "cn-hangzhou";
// Create an OSSClient instance.
// Call the shutdown method to release resources when the OSSClient is no longer in use.
ClientBuilderConfiguration clientBuilderConfiguration = new ClientBuilderConfiguration();
clientBuilderConfiguration.setSignatureVersion(SignVersion.V4);
OSS ossClient = OSSClientBuilder.create()
.endpoint(endpoint)
.credentialsProvider(credentialsProvider)
.clientConfiguration(clientBuilderConfiguration)
.region(region)
.build();
try {
ossClient.putBucketAccessMonitor(bucketName, AccessMonitor.AccessMonitorStatus.Enabled.toString());
// Create a lifecycle rule and set the ID to rule1. Specify that the storage classes of objects whose names contain the logs prefix and whose size is less than or equal to 64 KB are changed to IA 30 days after the objects are last accessed. In addition, specify that the objects whose name contain the logs prefix are still stored as IA objects when the objects are accessed again.
LifecycleRule lifecycleRule = new LifecycleRule("rule1", "logs", LifecycleRule.RuleStatus.Enabled);
List<LifecycleRule> lifecycleRuleList = new ArrayList<LifecycleRule>();
SetBucketLifecycleRequest setBucketLifecycleRequest = new SetBucketLifecycleRequest(bucketName);
LifecycleRule.StorageTransition storageTransition = new LifecycleRule.StorageTransition();
storageTransition.setStorageClass(StorageClass.IA);
storageTransition.setExpirationDays(30);
storageTransition.setIsAccessTime(true);
storageTransition.setReturnToStdWhenVisit(false);
storageTransition.setAllowSmallFile(true);
List<LifecycleRule.StorageTransition> storageTransitionList = new ArrayList<LifecycleRule.StorageTransition>();
storageTransitionList.add(storageTransition);
lifecycleRule.setStorageTransition(storageTransitionList);
lifecycleRuleList.add(lifecycleRule);
// Create a lifecycle rule and set the ID to rule2. Specify that the previous versions of the objects whose names contain the dir prefix and whose size is greater than 64 KB are changed to IA 10 days after the objects are last accessed. In addition, specify that the storage classes of the objects whose names contain the dir prefix are changed to Standard when the objects are accessed again.
LifecycleRule lifecycleRule2 = new LifecycleRule("rule2", "dir", LifecycleRule.RuleStatus.Enabled);
LifecycleRule.NoncurrentVersionStorageTransition noncurrentVersionStorageTransition = new LifecycleRule.NoncurrentVersionStorageTransition();
noncurrentVersionStorageTransition.setStorageClass(StorageClass.IA);
noncurrentVersionStorageTransition.setNoncurrentDays(10);
noncurrentVersionStorageTransition.setIsAccessTime(true);
noncurrentVersionStorageTransition.setReturnToStdWhenVisit(true);
noncurrentVersionStorageTransition.setAllowSmallFile(false);
List<LifecycleRule.NoncurrentVersionStorageTransition> noncurrentVersionStorageTransitionList = new ArrayList<LifecycleRule.NoncurrentVersionStorageTransition>();
noncurrentVersionStorageTransitionList.add(noncurrentVersionStorageTransition);
lifecycleRule2.setNoncurrentVersionStorageTransitions(noncurrentVersionStorageTransitionList);
lifecycleRuleList.add(lifecycleRule2);
setBucketLifecycleRequest.setLifecycleRules(lifecycleRuleList);
// Configure the lifecycle rules.
ossClient.setBucketLifecycle(setBucketLifecycleRequest);
} catch (OSSException oe) {
System.out.println("Caught an OSSException, which means your request made it to OSS, "
+ "but was rejected with an error response for some reason.");
System.out.println("Error Message:" + oe.getErrorMessage());
System.out.println("Error Code:" + oe.getErrorCode());
System.out.println("Request ID:" + oe.getRequestId());
System.out.println("Host ID:" + oe.getHostId());
} catch (ClientException ce) {
System.out.println("Caught an ClientException, which means the client encountered "
+ "a serious internal problem while trying to communicate with OSS, "
+ "such as not being able to access the network.");
System.out.println("Error Message:" + ce.getMessage());
} finally {
if (ossClient != null) {
ossClient.shutdown();
}
}
}
}
Python
import argparse
import datetime
import alibabacloud_oss_v2 as oss
parser = argparse.ArgumentParser(description="put bucket lifecycle sample")
parser.add_argument('--region', help='The region in which the bucket is located.', required=True)
parser.add_argument('--bucket', help='The name of the bucket.', required=True)
parser.add_argument('--endpoint', help='The domain names that other services can use to access OSS')
def main():
args = parser.parse_args()
credentials_provider = oss.credentials.EnvironmentVariableCredentialsProvider()
cfg = oss.config.load_default()
cfg.credentials_provider = credentials_provider
cfg.region = args.region
if args.endpoint is not None:
cfg.endpoint = args.endpoint
client = oss.Client(cfg)
result = client.put_bucket_lifecycle(oss.PutBucketLifecycleRequest(
bucket=args.bucket,
lifecycle_configuration=oss.LifecycleConfiguration(
rules=[
oss.LifecycleRule(
id='rule1',
status='Enabled',
prefix='data/',
transitions=[oss.LifecycleRuleTransition(
days=200,
storage_class=oss.StorageClassType.IA,
is_access_time=True,
return_to_std_when_visit=False
)]
),
oss.LifecycleRule(
id='rule2',
status='Enabled',
prefix='log/',
transitions=[
oss.LifecycleRuleTransition(
days=120,
storage_class=oss.StorageClassType.IA,
is_access_time=True,
return_to_std_when_visit=False
),
oss.LifecycleRuleTransition(
days=250,
storage_class=oss.StorageClassType.ARCHIVE
# If is_access_time is not set, the rule is based on the last modified time by default.
)
]
)
]
)
))
print(f'status code: {result.status_code}, '
f'request id: {result.request_id}')
if __name__ == "__main__":
main()
Go
package main
import (
"context"
"flag"
"log"
"github.com/aliyun/alibabacloud-oss-go-sdk-v2/oss"
"github.com/aliyun/alibabacloud-oss-go-sdk-v2/oss/credentials"
)
// Define global variables.
var (
region string // The region where the bucket is located.
bucketName string // The name of the bucket.
)
// The init function initializes command-line arguments.
func init() {
flag.StringVar(®ion, "region", "", "The region in which the bucket is located.")
flag.StringVar(&bucketName, "bucket", "", "The name of the bucket.")
}
func main() {
// Parse command-line arguments.
flag.Parse()
// Check if the bucket name is provided.
if len(bucketName) == 0 {
flag.PrintDefaults()
log.Fatalf("invalid parameters, bucket name required")
}
// Check if the region is provided.
if len(region) == 0 {
flag.PrintDefaults()
log.Fatalf("invalid parameters, region required")
}
// Load the default configuration, and set the credentials provider and region.
cfg := oss.LoadDefaultConfig().
WithCredentialsProvider(credentials.NewEnvironmentVariableCredentialsProvider()).
WithRegion(region)
// Create an OSS client.
client := oss.NewClient(cfg)
// Create a request to set lifecycle rules for the bucket.
request := &oss.PutBucketLifecycleRequest{
Bucket: oss.Ptr(bucketName), // The name of the bucket.
LifecycleConfiguration: &oss.LifecycleConfiguration{
Rules: []oss.LifecycleRule{
{
// In lifecycle rule "rule1", transition all objects with the prefix "data/"
// to the Infrequent Access (IA) storage class 200 days after they are last accessed.
// When these objects are accessed again, they remain in the IA storage class.
ID: oss.Ptr("rule1"),
Status: oss.Ptr("Enabled"),
Prefix: oss.Ptr("data/"),
Transitions: []oss.LifecycleRuleTransition{
{
Days: oss.Ptr(int32(200)),
StorageClass: oss.StorageClassIA,
IsAccessTime: oss.Ptr(true), // Set to true for a rule based on last access time.
ReturnToStdWhenVisit: oss.Ptr(false),
},
},
},
{
// In lifecycle rule "rule2", transition all objects with the prefix "log/"
// to the Infrequent Access (IA) storage class 120 days after they are last accessed.
// When these objects are accessed again, they remain in the IA storage class.
// A single rule cannot contain more than one IsAccessTime=true Transition.
// The 250-day Archive transition is configured in a separate rule (rule3) below.
ID: oss.Ptr("rule2"),
Status: oss.Ptr("Enabled"),
Prefix: oss.Ptr("log/"),
Transitions: []oss.LifecycleRuleTransition{
{
Days: oss.Ptr(int32(120)),
StorageClass: oss.StorageClassIA,
IsAccessTime: oss.Ptr(true), // Set to true for a rule based on last access time.
ReturnToStdWhenVisit: oss.Ptr(false),
},
},
},
{
// In lifecycle rule "rule3", transition all objects with the prefix "log/"
// to the Archive storage class 250 days after they are last accessed.
// When these objects are accessed again, they remain in the Archive storage class.
// This rule is separate from rule2 because a single rule cannot contain
// more than one IsAccessTime=true Transition.
ID: oss.Ptr("rule3"),
Status: oss.Ptr("Enabled"),
Prefix: oss.Ptr("log/"),
Transitions: []oss.LifecycleRuleTransition{
{
Days: oss.Ptr(int32(250)),
StorageClass: oss.StorageClassArchive,
IsAccessTime: oss.Ptr(true), // Set to true for a rule based on last access time.
ReturnToStdWhenVisit: oss.Ptr(false),
},
},
},
},
},
}
// Set the lifecycle rules for the bucket.
result, err := client.PutBucketLifecycle(context.TODO(), request)
if err != nil {
log.Fatalf("failed to put bucket lifecycle %v", err)
}
// Print the result of setting the lifecycle rules.
log.Printf("put bucket lifecycle result:%#v\n", result)
}
PHP
<?php
// Include the autoload file to load dependencies.
require_once __DIR__ . '/../vendor/autoload.php';
use AlibabaCloud\Oss\V2 as Oss;
use AlibabaCloud\Oss\V2\Models\LifecycleConfiguration;
// Describe command-line parameters.
$optsdesc = [
"region" => ['help' => 'The region in which the bucket is located', 'required' => True], // (Required) Specify the region in which the bucket is located.
"endpoint" => ['help' => 'The domain names that other services can use to access OSS', 'required' => False], // (Optional) Specify the OSS endpoint.
"bucket" => ['help' => 'The name of the bucket', 'required' => True], // (Required) Specify the name of the bucket.
];
// Generate a long options list to parse the command-line parameters.
$longopts = \array_map(function ($key) {
return "$key:"; // Add a colon (:) to the end of each parameter to indicate that a value is required.
}, array_keys($optsdesc));
// Parse the command-line parameters.
$options = getopt("", $longopts);
// Check whether the required parameters are missing.
foreach ($optsdesc as $key => $value) {
if ($value['required'] === True && empty($options[$key])) {
$help = $value['help'];
echo "Error: the following arguments are required: --$key, $help"; // Display the required but missing parameters.
exit(1);
}
}
// Obtain the values of the command-line parameters and assign the values to variables.
$region = $options["region"]; // The region in which the bucket is located.
$bucket = $options["bucket"]; // The name of the bucket.
// Load the AccessKey ID and AccessKey secret from environment variables.
$credentialsProvider = new Oss\Credentials\EnvironmentVariableCredentialsProvider();
// Use the default configuration of the SDK.
$cfg = Oss\Config::loadDefault();
// Specify the credential provider.
$cfg->setCredentialsProvider($credentialsProvider);
// Specify the region.
$cfg->setRegion($region);
// If an endpoint is provided, specify the endpoint.
if (isset($options["endpoint"])) {
$cfg->setEndpoint($options["endpoint"]);
}
// Create an OSS client instance.
$client = new Oss\Client($cfg);
{}
$lifecycleRule = new Oss\Models\LifecycleRule(
prefix: 'log/', // The prefix of object names.
transitions: array(
new Oss\Models\LifecycleRuleTransition(
days: 30, // Specify the days.
storageClass: 'IA', // Change to IA.
isAccessTime: 'true', // Trigger the change based on the last access time.
returnToStdWhenVisit: 'true' // Return to the Standard storage class after they are accessed.
)
),
id: 'rule', // The rule ID.
status: 'Enabled' // Enable the rule.
);
// Create a lifecycle configuration and add lifecycle rules to the configuration.
$lifecycleConfiguration = new LifecycleConfiguration(
rules: array($lifecycleRule)
);
// Create a request to set a lifecycle configuration and pass the lifecycle configuration.
$request = new Oss\Models\PutBucketLifecycleRequest(
bucket: $bucket,
lifecycleConfiguration: $lifecycleConfiguration
);
// Call the putBucketLifecycle method to configure the lifecycle rules.
$result = $client->putBucketLifecycle($request);
// Display the result.
printf(
'status code:' . $result->statusCode . PHP_EOL . // The HTTP response status code.
'request id:' . $result->requestId . PHP_EOL // The request ID.
);
ossutil
Vous pouvez utiliser ossutil pour configurer des règles de cycle de vie. Pour plus d'informations sur l'installation d'ossutil, consultez Installer ossutil.
L'exemple suivant montre comment configurer une règle de cycle de vie pour le bucket examplebucket :
ossutil api put-bucket-lifecycle --bucket examplebucket--lifecycle-configuration "{\"Rule\":{\"ID\":\"rule1\",\"Prefix\":\"tmp/\",\"Status\":\"Enabled\",\"Expiration\":{\"Days\":\"10\"},\"Transition\":{\"Days\":\"5\",\"StorageClass\":\"IA\",\"IsAccessTime\":true,\"ReturnToStdWhenVisit\":true},\"AbortMultipartUpload\":{\"Days\":\"10\"}}}"
Pour plus d'informations sur cette commande, consultez put-bucket-lifecycle.
Référence API
Les opérations précédentes reposent sur des appels API. Si vous avez besoin d'un degré élevé de personnalisation, vous pouvez envoyer directement des requêtes REST API. Cela nécessite d'écrire votre propre code pour calculer les signatures. Pour plus d'informations, consultez PutBucketLifecycle.
FAQ
Que se passe-t-il si je crée deux règles de cycle de vie pour des objets ayant le même préfixe dans un bucket, où l'une est basée sur la dernière date de modification et l'autre sur la dernière date d'accès ?
Par exemple, vous créez deux règles de cycle de vie pour le bucket de destination nommé examplebucket. La règle 1 spécifie que tous les objets avec le préfixe doc sont supprimés 30 jours après leur dernière date de modification. La règle 2 spécifie que tous les objets avec le préfixe doc sont transférés vers la classe de stockage Infrequent Access 30 jours après leur dernière date d'accès.
OSS exécute les règles de cycle de vie selon le principe de minimisation des coûts pour l'utilisateur. Par conséquent, seule la règle 1 prend effet. En effet, la règle 1 spécifie que les objets correspondants sont supprimés après 30 jours, après quoi aucun frais n'est encouru. En revanche, la règle 2 transfère les objets vers la classe de stockage Infrequent Access, ce qui engendre toujours des frais de stockage et des frais de récupération de données.
Quand une modification d'une règle de cycle de vie configurée prend-elle effet, et comment les données correspondant à la règle d'origine sont-elles traitées ?
Par exemple, vous avez configuré une règle de cycle de vie pour les objets avec le préfixe er afin qu'ils soient transférés vers la classe de stockage Infrequent Access 30 jours après le dernier accès, puis qu'ils reviennent à la classe de stockage Standard s'ils sont consultés après 30 jours supplémentaires. Toutefois, 35 jours après le dernier accès, vous modifiez le préfixe dans la règle de cycle de vie de er à re. Dans ce cas, les objets d'origine ne sont transférés que vers la classe de stockage Infrequent Access. Le transfert ultérieur vers la classe de stockage Standard ne se produit pas. La dernière date d'accès pour les objets correspondant à la nouvelle règle est également comptée à partir du moment où le suivi d'accès a été activé pour le bucket.
Si Intelligent Tiering est activé dans un bucket avec versioning activé, comment les niveaux de stockage s'appliquent-ils aux différentes versions d'un objet ?
Chaque objet dans un bucket avec versioning activé possède un ID de version unique, et les objets avec des ID de version différents sont indépendants les uns des autres. Par conséquent, une version non actuelle d'un objet peut se trouver dans la classe de stockage Infrequent Access tandis que la version actuelle se trouve dans la classe de stockage Standard.
Puis-je désactiver le suivi d'accès ?
Oui, à condition qu'aucune règle de cycle de vie basée sur la dernière date d'accès n'existe dans le bucket. Une fois le suivi d'accès désactivé, le système arrête de suivre la dernière date d'accès des objets. La prochaine fois que vous activerez le suivi d'accès, le système actualisera la dernière date d'accès pour tous les objets.
Références
La dernière date d'accès (LastAccessTime) est un attribut important d'un objet et est utilisée dans des scénarios tels que la facturation et les règles de cycle de vie. Une fois le suivi d'accès activé pour un bucket, certaines opérations sur un objet peuvent mettre à jour son LastAccessTime. Pour plus d'informations, consultez Impact des opérations courantes sur la dernière date d'accès des objets.