Remarque
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.
Cet article répond aux questions fréquemment posées sur les politiques de gestion du cycle de vie dans Stockage Blob Azure.
J’ai créé une nouvelle politique. Pourquoi les actions ne se lancent-elles pas immédiatement ?
Une fois une politique configurée, il peut falloir jusqu’à 24 heures pour qu’elle prenne effet. Une fois la politique en vigueur, le temps nécessaire pour que les actions s’exécutent peuvent varier en fonction de la taille du compte de stockage et des opérations effectuées.
Si je mets à jour une politique existante, combien de temps faut-il pour que les actions s’exécutent ?
La politique mise à jour peut prendre jusqu’à 24 heures pour prendre effet. Une fois la politique en vigueur, le temps nécessaire pour que les actions s’exécutent varie en fonction de la taille du compte de stockage et des opérations effectuées. Si la mise à jour vise à désactiver ou à supprimer une règle, et que enableAutoTierToHotFromCool a été utilisé, le placement automatique vers le niveau chaud a toujours lieu. Par exemple, définissez une règle incluant enableAutoTierToHotFromCool en fonction du dernier accès. Si la règle est désactivée ou supprimée et qu’un objet blob se trouve actuellement dans le niveau froid ou froid, puis qu’il est consulté, il revient au niveau chaud, car cette opération est appliquée lors de l’accès en dehors de la gestion du cycle de vie. Le blob ne passe pas de chaud à froid ou froid si la règle de gestion du cycle de vie est désactivée ou supprimée. La seule façon de prévenir autoTierToHotFromCool est de désactiver le suivi du temps d’accès précédent.
L’exécution se termine, mais ne déplace ni ne supprime certains blobs
Selon la taille et le nombre d’objets dans un compte de stockage, il se peut que vous ayez besoin de plusieurs exécutions pour traiter tous les objets. Vous pouvez également vérifier les journaux de ressources de stockage pour déterminer si la stratégie de gestion du cycle de vie effectue les opérations.
Je ne vois pas de modifications de capacité, même si la stratégie s’exécute et supprime les blobs.
Vérifiez si des fonctionnalités de protection des données telles que la suppression douce ou le versionnement sont activées sur le compte de stockage. Même si la politique consiste à supprimer les blobs, ces blobs peuvent toujours exister en état de suppression progressive ou sous forme d’ancienne version selon la configuration de ces fonctionnalités.
J’ai réhydraté un objet blob archivé. Comment puis-je empêcher qu’il soit temporairement replacé dans le palier Archive ?
S’il existe une politique de gestion du cycle de vie pour le compte de stockage, réhydrater un blob en changeant son niveau peut aboutir à un scénario où la politique du cycle de vie déplace le blob vers le niveau d’archive. Cette condition survient si le dernier temps de modification, le temps de création ou le dernier temps d’accès dépasse le seuil fixé pour la politique. Il existe trois façons de prévenir cette condition :
Ajoutez la
daysAfterLastTierChangeGreaterThancondition à l’actiontierToArchivede la stratégie. Voir Utiliser les politiques de gestion du cycle de vie pour archiver les blobs.Désactivez temporairement la règle qui affecte ce blob pour empêcher qu’il soit à nouveau archivé. Réactivez la règle lorsque le blob pourra être déplacé en toute sécurité vers le niveau d’archive.
Si le blob doit rester définitivement dans le niveau chaud, tiède ou froid, copiez le blob vers un autre emplacement où la stratégie de gestion du cycle de vie ne s’applique pas.
La chaîne de correspondance du préfixe de l’objet blob n’a pas appliqué la stratégie aux objets blob attendus
Le champ de correspondance du préfixe de blob d’une politique est un chemin complet ou partiel de blob, que vous utilisez pour faire correspondre les blobs auxquels vous souhaitez que les actions de politique s’appliquent. Le chemin doit commencer par le nom du conteneur. Si vous ne spécifiez pas de correspondance de préfixe, la politique s’applique à tous les blobs du compte de stockage. Le format de la chaîne de correspondance de préfixe est [container name]/[blob name].
Gardez à l’esprit les points suivants concernant la chaîne de correspondance du préfixe :
- Une chaîne de correspondance de préfixe comme
container1/s’applique à toutes les blobs du conteneur nommécontainer1. Une chaîne de correspondance de préfixecontainer1, sans barre oblique finale (/), s’applique à tous les objets blob de tous les conteneurs dont le nom commence par la chaînecontainer1. Le préfixe correspond aux conteneurs nomméscontainer11,container1234,container1ab, et ainsi de suite. - Une chaîne de correspondance préfixe de
container1/sub1/s’applique à toutes les blobs du conteneur nommécontainer1qui commencent par la chaînesub1/. Par exemple, le préfixe correspond à des blobs nomméscontainer1/sub1/test.txtoucontainer1/sub1/sub2/test.txt. - L’astérisque
*est un caractère valide dans un nom de blob. Si vous utilisez le caractère astérisque dans un préfixe, le préfixe correspond aux blobs avec un astérisque dans leur nom. L’astérisque ne fonctionne pas comme caractère générique. - Le caractère
?(point d’interrogation) est un caractère valide dans un nom de blob. Si vous utilisez le caractère point d’interrogation dans un préfixe, le préfixe correspond aux blobs dont le nom contient un point d’interrogation. Le point d’interrogation ne fonctionne pas comme un caractère générique. - La correspondance de préfixe prend uniquement en compte les comparaisons logiques positives (
=). Il ignore les comparaisons logiques négatives (!=). - La correspondance de préfixe respecte la casse.
Existe-t-il un moyen de déterminer à quel moment la stratégie sera exécutée ?
Malheureusement, il n’y a aucun moyen de suivre le délai d’exécution de la politique, car il s’agit d’un processus de planification en arrière-plan. Les politiques de cycle de vie commencent à être exécutées dans les 24 heures suivant la création ou la mise à jour d’une règle. Les stratégies traitent les objets en continu en arrière-plan, selon les besoins. Le système donne la priorité aux requêtes issues des charges de travail. Il n’existe donc aucun moyen de savoir à quel moment une stratégie est susceptible de s’exécuter. Le temps nécessaire pour traiter les objets peut dépendre du taux de requête pour le compte de stockage. Cette période peut être plus longue si le taux de requête pour le compte de stockage approche de la limite du compte de stockage.