Partager via

Stratégies de gestion du cycle de vie qui transfèrent les objets blob entre les niveaux

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. Cet article contient des exemples de définitions de stratégie qui transfèrent les objets blob entre les niveaux.

Pour obtenir des informations générales sur les stratégies de gestion du cycle de vie du stockage Blob Azure, consultez la vue d’ensemble de la gestion du cycle de vie du stockage Blob Azure.

Déplacer les données vieillissantes vers un niveau plus froid

Cet exemple montre comment déplacer des objets blob de blocs ayant le préfixe sample-container/blob1 ou container2/blob2. La stratégie déplace les objets blob qui n’ont pas été modifiés depuis plus de 30 jours vers le stockage froid et les objets blob non modifiés depuis 90 jours vers le niveau archive :

{
  "rules": [
    {
      "name": "agingRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
        },
        "actions": {
          "baseBlob": {
            "tierToCool": { "daysAfterModificationGreaterThan": 30 },
            "tierToArchive": { "daysAfterModificationGreaterThan": 90 }
          }
        }
      }
    }
  ]
}

Remarque

L’élément baseBlob dans une stratégie de gestion de cycle de vie fait référence à la version actuelle d’un objet blob.

Déplacer des données en fonction de la dernière heure consultée

Dans l’exemple suivant, les objets BLOB sont déplacés vers le stockage froid s’ils n’ont pas fait l’objet d’accès depuis 30 jours. La propriété enableAutoTierToHotFromCool est une valeur booléenne qui indique si un blob doit être automatiquement reclassé de froid à chaud s’il fait l’objet d’un nouvel accès après avoir été déplacé dans le niveau froid.

Conseil / Astuce

Si un objet blob est déplacé vers le niveau de stockage sporadique, puis qu’il est automatiquement déplacé à nouveau avant l’expiration d’un délai de 30 jours, des frais de suppression anticipée sont facturés. Avant de définir la propriété enableAutoTierToHotFromCool, veillez à analyser les modèles d’accès de vos données afin de réduire les frais inattendus. La hiérarchisation automatique de froid à chaud lors de l’accès aux objets blob est limitée une fois en 30 jours. Ce dispositif de protection est en place pour vous aider à éviter plusieurs pénalités de suppression anticipée au niveau sporadique. Si les niveaux d’objet sont de nouveau sporadiques en raison de la stratégie, toutes les transactions sur l’objet blob sont facturées au niveau sporadique. Il est économique de conserver l’objet blob dans le niveau chaud s’il doit être automatiquement mis à l’échelle plusieurs fois dans une période de 30 jours.

L'activation d'une règle avec enableAutoTierToHotFromCool s'applique uniquement aux objets classés dans une couche inférieure avec cette règle. La propriété enableAutoTierToHotFromCool ne peut pas être activée pour les blobs qui sont déjà dans le niveau froid. Par conséquent, le niveau d’accès de ces objets blob ne passe pas automatiquement à chaud lorsqu’ils sont accessibles.

{
  "enabled": true,
  "name": "last-accessed-thirty-days-ago",
  "type": "Lifecycle",
  "definition": {
    "actions": {
      "baseBlob": {
        "enableAutoTierToHotFromCool": true,
        "tierToCool": {
          "daysAfterLastAccessTimeGreaterThan": 30
        }
      }
    },
    "filters": {
      "blobTypes": [
        "blockBlob"
      ],
      "prefixMatch": [
        "mylifecyclecontainer/log"
      ]
    }
  }
}

Archivage des données après l’ingestion

Certaines données restent inactives dans le cloud et sont rarement, voire jamais, consultées. La stratégie du cycle de vie suivante est configurée pour archiver les données peu après leur ingestion. Cet exemple déplace les objets blob de blocs d’un conteneur nommé archivecontainer à un niveau archive. Le déplacement est accompli en agissant sur les objets blob zéro (0) jour après l’heure de la dernière modification.

Important

Si un jeu de données doit être lisible, ne définissez pas de stratégie pour déplacer les blobs vers le niveau archive. Les blobs du niveau archive ne peuvent pas être lus s’ils ne sont pas d’abord réhydratés, un processus qui peut être long et coûteux. Pour plus d’informations, voir Vue d’ensemble de la réactivation d’objets blob à partir du niveau Archive. Si un ensemble de données doit être lu souvent, ne définissez pas de stratégie pour déplacer les blobs vers les niveaux froid ou froid, car cela pourrait entraîner des coûts de transaction plus élevés.

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { 
                "daysAfterModificationGreaterThan": 0
              }
          }
        }
      }
    }
  ]
}

Remarque

Pour plus d’efficacité, Microsoft vous recommande de charger vos objets blob directement dans le niveau archive. Vous pouvez spécifier le niveau archive dans l’en-tête x-ms-access-tier sur l’opération Put Blob ou Put Block List. L’en-tête x-ms-access-tier est pris en charge avec REST 2018-11-09 et versions ultérieures ou les dernières bibliothèques de client de Stockage Blob.

Gestion des versions précédentes

Pour les données modifiées et consultées régulièrement pendant toute leur durée de vie, vous pouvez activer la gestion de versions du stockage Blob afin de gérer automatiquement les versions précédentes d’un objet. Vous pouvez créer une stratégie pour hiérarchiser les versions précédentes. L’âge de la version est déterminé en regardant l’heure de création de cette dernière. Cette règle de stratégie déplace les versions précédentes au sein du conteneur activedata qui sont de 90 jours ou plus après la création de la version vers le niveau froid.

{
  "rules": [
    {
      "enabled": true,
      "name": "versionrule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 90
            },
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "activedata/"
          ]
        }
      }
    }
  ]
}

Remarque

L’élément de version d’une stratégie de gestion du cycle de vie fait référence à une version précédente.

Voir aussi