Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Vous pouvez utiliser des stratégies de gestion du cycle de vie pour migrer des objets blob vers des niveaux d’accès rentables en fonction de leurs modèles d’utilisation. Vous pouvez également supprimer des blobs complètement à la fin de leur cycle de vie. Une stratégie peut fonctionner sur les versions actuelles, les versions précédentes et les instantanés, mais une stratégie ne s'applique pas aux objets blob dans des conteneurs système tels que les conteneurs $logs ou $web. Pour obtenir des informations générales, consultez la vue d’ensemble de la gestion du cycle de vie du Stockage Blob Azure.
Cet article décrit les éléments d’une stratégie de gestion du cycle de vie. Pour obtenir des exemples de stratégie, consultez les articles suivants :
- Stratégies de gestion du cycle de vie qui font passer les blobs d'un niveau à l'autre
- Stratégies de gestion du cycle de vie qui suppriment les blobs
Conseil / Astuce
Bien que la gestion du cycle de vie vous aide à optimiser vos coûts pour un seul compte, vous pouvez utiliser Azure Storage Actions pour effectuer plusieurs opérations de données à grande échelle sur plusieurs comptes.
Règles
Une stratégie de gestion de cycle de vie est une collection de règles dans un document JSON. L’exemple JSON suivant montre une définition de règle complète :
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
Nom du paramètre | Type de paramètre | Remarques |
---|---|---|
règlement | Un ensemble d’objets de règle | Une stratégie requiert au moins une règle. Vous pouvez définir jusqu’à 100 règles dans une stratégie. |
Chaque règle de la stratégie a plusieurs paramètres, décrits dans le tableau suivant :
Nom du paramètre | Catégorie | Remarques | Obligatoire |
---|---|---|---|
nom | Chaîne | Un nom de règle peut compter jusqu’à 256 caractères alphanumériques. Les noms de règle respectent la casse. Ils doivent être uniques dans la stratégie. | Oui |
activé | Booléen | Valeur booléenne facultative pour permettre la désactivation temporaire d’une règle. La valeur par défaut est true. | Non |
type | Une valeur enum | Le type valide actuel est Lifecycle . |
Oui |
définition | Un objet qui définit la règle du cycle de vie | Chaque définition se compose d’un jeu de filtres et d’un jeu d’actions. | Oui |
Filtres
Les filtres limitent les actions à un sous-ensemble d’objets blob dans le compte de stockage. Vous pouvez utiliser un filtre pour spécifier les blobs à inclure. Un filtre ne fournit aucun moyen de spécifier les blobs à exclure. Si plusieurs filtres sont définis, un AND logique est appliqué à tous les filtres. Le tableau suivant décrit chaque paramètre.
Nom du filtre | Catégorie | Descriptif | Obligatoire |
---|---|---|---|
blobTypes | Tableau de valeurs enum prédéfinies | Type d’objet blob ( blockblob ou appendBlob) | Oui |
prefixMatch | Tableau de chaînes | Ces chaînes sont des préfixes à mettre en correspondance. | Non |
blobIndexMatch | Tableau de valeurs de dictionnaire | Ces valeurs se composent de la clé de balise d’index d’objet blob et des conditions de valeur à mettre en correspondance. | Non |
Filtre de correspondance de préfixe
Si vous appliquez le filtre prefixMatch, chaque règle peut définir jusqu’à 10 préfixes sensibles à la casse. Une chaîne de préfixe doit commencer par un nom de conteneur. Par exemple, si vous souhaitez faire correspondre tous les blobs sous le chemin d’accès https://myaccount.blob.core.windows.net/sample-container/blob1/...
, spécifiez le prefixMatch en tant que sample-container/blob1
.
Ce filtre correspondra à tous les blobs dans sample-container
, dont les noms commencent par blob1
. Si vous ne définissez pas prefixMatch, puis, la règle s’applique à tous les objets blob au sein du compte de stockage. Les chaînes de préfixe ne prennent pas en charge la correspondance des caractères génériques. Les caractères tels que *
et ?
sont traités comme des littéraux de chaîne.
Filtre de correspondance d'index de blob
Si vous appliquez le filtre blobIndexMatch, chaque règle peut définir jusqu’à 10 conditions de balise d’index d’objet blob. Par exemple, si vous souhaitez faire correspondre tous les objets blob avec Project = Contoso
sous https://myaccount.blob.core.windows.net/
, le filtre blobIndexMatch est {"name": "Project","op": "==","value": "Contoso"}
. Si vous ne définissez pas de valeur pour le filtre blobIndexMatch , la règle s’applique à tous les objets blob du compte de stockage.
Actions
Vous devez définir au moins une action pour chaque règle. Des actions sont appliquées aux objets blob filtrés lorsque la condition d’exécution est remplie. Pour en savoir plus sur les conditions d’exécution, consultez la section Conditions d’exécution d’action de cet article. Le tableau suivant décrit chaque action disponible dans une définition de stratégie.
Action | Descriptif |
---|---|
TierToCool | Définissez un objet blob sur le niveau d’accès froid. Non pris en charge avec les objets blob d’ajout, les objets blob de pages ou les objets blob dans un compte de stockage d’objets blob de blocs Premium. |
TierToCold | Attribuez un objet blob au niveau d’accès froid. Non pris en charge avec les objets blob d’ajout, les objets blob de pages ou les objets blob dans un compte de stockage d’objets blob de blocs Premium. |
TierToArchive | Placez un objet blob dans le niveau d'accès aux archives. La réhydratage d’un objet blob ne met pas à jour la dernière propriété d’heure d’accès ou de dernière modification de l’objet blob. Par conséquent, cette action peut déplacer des objets blob réhydratés vers le niveau archive. Pour empêcher ce problème, ajoutez la daysAfterLastTierChangeGreaterThan condition à cette action.Cette action n’est pas prise en charge avec les objets blob d’ajout, les objets blob de pages ou les objets blob dans un compte de stockage d’objets blob de blocs Premium. Non plus pris en charge avec les objets blob qui utilisent une étendue de chiffrement ou avec des objets blob dans des comptes configurés pour le stockage redondant interzone (ZRS), le stockage géoredondant interzone (GZRS) / stockage géoredondant avec accès en lecture (RA-GZRS). |
enableAutoTierToHotFromCool | Si un objet blob est défini sur le niveau froid, cette action déplace automatiquement cet objet blob dans le niveau chaud lorsque l’objet blob est accessible. Cette action est disponible uniquement quand elle est utilisée avec la condition d’exécution daysAfterLastAccessTimeGreaterThan . Cette action n’a aucun effet sur les objets blob définis au niveau froid avant l'activation de cette action dans une règle. Cette action déplace les blobs de l'état froid à l'état chaud une seule fois dans un délai de 30 jours. Cette protection est mise en place pour se protéger contre plusieurs pénalités de suppression anticipée facturées au compte. Non pris en charge par les versions précédentes ou les captures instantanées. |
Supprimer | Supprime un blob. Non pris en charge avec les blobs de pages ou les blobs se trouvant dans un conteneur immuable. |
Si vous définissez plusieurs actions sur le même objet blob, la gestion du cycle de vie applique l’action la moins coûteuse à l’objet blob. Par exemple, une action de suppression est moins coûteuse que l’action tierToArchive et l’action tierToArchive est moins coûteuse que l’action tierToCool .
Action de suppression dans les comptes qui ont un espace de noms hiérarchique
Lorsqu’elle est appliquée à un compte avec un espace de noms hiérarchique activé, une action de suppression supprime les répertoires vides. Si le répertoire n’est pas vide, l’action de suppression supprime les objets qui répondent aux conditions de la stratégie au cours du premier cycle d’exécution de la stratégie de cycle de vie. Si cette action entraîne un répertoire vide qui répond également aux conditions de la stratégie, ce répertoire est supprimé pendant le cycle d’exécution suivant, et ainsi de suite.
Action de suppression des objets blob ayant des versions et des captures instantanées
Une stratégie de gestion du cycle de vie ne supprime pas la version actuelle d’un objet blob tant que les versions ou instantanés précédents associés à cet objet blob n’ont pas été supprimés. Si les objets blob de votre compte de stockage ont des versions ou des instantanés antérieurs, vous devez inclure des versions et des instantanés précédents lorsque vous spécifiez une action de suppression dans le cadre de la stratégie.
Conditions d’exécution d’action
Toutes les conditions d’exécution sont basées sur le temps. Si le nombre de jours qui ont transpiré dépasse le nombre spécifié pour la condition, l’action associée peut s’exécuter. Les conditions de stratégie sont évaluées sur chaque objet une seule fois lors d’une exécution de stratégie. Dans certains cas, un objet peut répondre à la condition une fois qu’il a déjà été évalué par une exécution. Ces objets sont traités dans les exécutions suivantes.
Les versions actuelles utilisent l’heure de la dernière modification ou du dernier accès, les versions précédentes utilisent l’heure de création de la version et les instantanés d’objets blob utilisent l’heure de création des instantanés pour suivre l’ancienneté.
Le tableau suivant décrit chaque condition d’exécution d’action.
Nom de la condition | Catégorie | Descriptif |
---|---|---|
daysAfterModificationGreaterThan | Nombre entier | Âge en jours depuis le dernier changement de l’objet blob. S’applique aux actions sur une version actuelle d’un objet blob. |
daysAfterCreationGreaterThan | Nombre entier | L'âge en jours depuis la date de création. S’applique aux actions sur la version actuelle d’un objet blob, à la version précédente d’un objet blob ou à un instantané d’objet blob. |
daysAfterLastAccessTimeGreaterThan | Nombre entier | Âge en jours après le dernier accès ou, dans certains cas, à partir de la date à laquelle la stratégie a été activée. Pour en savoir plus, consultez la section Suivi du temps d’accès ci-dessous. S’applique aux actions sur la version actuelle d’un objet blob lorsque le suivi des accès est activé. |
daysAfterLastTierChangeGreaterThan | Nombre entier | L’âge en jours après la dernière date de modification du niveau d’objet blob. La durée minimale en jours pendant laquelle un objet blob réhydraté est conservé dans des niveaux d’accès chaud, sporadiques ou froids avant d’être retourné au niveau archive. S’applique uniquement aux actions tierToArchive . |
Suivi du temps d’accès
Vous pouvez activer le suivi du temps d’accès pour conserver un enregistrement de la dernière lecture ou de l’écriture de votre objet blob et en tant que filtre pour gérer la hiérarchisation et la rétention de vos données blob.
Lorsque vous activez le suivi du temps d’accès, une propriété d’objet blob appelée LastAccessTime
est mise à jour lorsqu’un objet blob est lu ou écrit. Les opérations Get Blob et Put Blob sont des opérations d’accès et mettent à jour l’heure d’accès d’un objet blob. Toutefois, les propriétés Get Blob, Get Blob Metadata et Get Blob Tags ne sont pas des opérations d’accès. Ces opérations ne mettent pas à jour le temps d'accès d’un objet blob.
Si vous appliquez la condition d’exécution daysAfterLastAccessTimeGreaterThan à une stratégie, alors le critère LastAccessTime
est utilisé pour déterminer si cette condition est remplie.
Si vous appliquez la condition d’exécution daysAfterLastAccessTimeGreaterThan à une stratégie, mais que vous n’avez pas activé le suivi du temps d’accès, il LastAccessTime
n’est pas utilisé. La date à laquelle la stratégie de cycle de vie a été activée est utilisée à la place. En fait, la date à laquelle la stratégie de cycle de vie a été activée est utilisée dans toute situation où la LastAccessTime
propriété de l’objet blob est une valeur Null. Cela peut se produire même si vous avez activé le suivi du temps d'accès, dans le cas où un élément n'a pas été consulté depuis que le suivi est activé.
Remarque
Pour réduire l’effet sur la latence d’accès en lecture, seule la première lecture des dernières 24 heures met à jour l’heure du dernier accès. Les lectures suivantes dans la même période de 24 heures ne mettent pas à jour l’heure du dernier accès. Si un objet blob est modifié entre des lectures, l’heure du dernier accès est la plus récente des deux valeurs.
Pour savoir comment activer le suivi du temps d’accès, consultez Éventuellement activer le suivi du temps d’accès.
Étapes suivantes
- Vue d’ensemble de la gestion du cycle de vie du stockage Blob Azure.
- Configurer une stratégie de gestion de cycle de vie
- Niveaux d’accès pour les données d’objets blob
- Stratégies de gestion du cycle de vie qui font passer les blobs d'un niveau à l'autre
- Stratégies de gestion du cycle de vie qui suppriment les blobs
- Surveillance des stratégies de gestion du cycle de vie
- Gérer et rechercher des données dans Stockage Blob Azure avec un index de blobs
- Bonnes pratiques relatives à l’utilisation des niveaux d’accès aux objets blob