Condividi tramite

Politiche di gestione del ciclo di vita che effettuano la transizione dei blob tra i livelli

È possibile utilizzare i criteri di gestione del ciclo di vita per trasferire i BLOB a livelli di accesso più convenienti dal punto di vista economico, in base ai loro modelli di utilizzo. Questo articolo contiene esempi di definizioni di criteri che effettuano la transizione dei blob tra livelli.

Per informazioni generali sui criteri di gestione del ciclo di vita di Azure Storage, vedere la panoramica della gestione del ciclo di vita di Azure Blob Storage.

Spostare i dati a un livello di archiviazione ad accesso più sporadico

Questo esempio illustra la transizione di BLOB in blocchi con prefisso sample-container/blob1 o container2/blob2. Il criterio sposta i BLOB che non sono stati modificati da oltre 30 giorni a un livello di archiviazione ad accesso sporadico e i BLOB non modificati da 90 giorni a un livello di archiviazione archivio:

{
  "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 }
          }
        }
      }
    }
  ]
}

Annotazioni

L'elemento baseBlob nei criteri di gestione del ciclo di vita fa riferimento alla versione corrente di un BLOB.

Spostare i dati in base all'ora dell'ultimo accesso

Nell'esempio seguente i BLOB vengono spostati nell'archivio ad accesso sporadico se non vi si è acceduto per 30 giorni. La proprietà enableAutoTierToHotFromCool è un valore booleano che indica se un BLOB deve essere automaticamente riportato da un livello di accesso sporadico a uno frequente se si accede di nuovo dopo essere stato riportato all'accesso sporadico.

Suggerimento

Se un BLOB viene spostato nel livello ad accesso sporadico e quindi viene automaticamente riportato al precedente prima della scadenza di 30 giorni, viene addebitata una tariffa per l'eliminazione anticipata. Prima di impostare la proprietà enableAutoTierToHotFromCool, assicurarsi di analizzare i modelli di accesso dei dati in modo da ridurre gli addebiti imprevisti. La suddivisione automatica in livelli da freddo a caldo all'accesso al BLOB è limitata a una volta ogni 30 giorni. Questa misura di sicurezza è disponibile per aiutarti a evitare più multe per l'eliminazione anticipata dal livello a accesso sporadico. Se l'oggetto torna al livello ad accesso sporadico a causa dei criteri, tutte le transazioni sul blob vengono addebitate ai prezzi del livello ad accesso sporadico. È conveniente mantenere il BLOB a caldo se deve essere spostato a un livello superiore automaticamente più di una volta in un periodo di 30 giorni.

L'abilitazione di una regola con enableAutoTierToHotFromCool si applica solo agli oggetti che sono stati ricollocati a un livello inferiore con questa regola. La enableAutoTierToHotFromCool proprietà non può essere abilitata per i BLOB già presenti nel livello Cool. Di conseguenza, il livello di accesso di tali BLOB non cambierà automaticamente a caldo anche se viene effettuato l'accesso.

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

Archiviazione dei dati dopo l'inserimento

Alcuni dati rimangono inattivi sul cloud e gli utenti vi accedono raramente, se non mai. I seguenti criteri relativi al ciclo di vita sono configurati per archiviare i dati poco dopo l'inserimento. Questo esempio esegue la transizione dei BLOB in blocchi in un contenitore denominato archivecontainer in un livello archivio. La transizione avviene agendo sui BLOB 0 giorni dopo la data dell'ultima modifica.

Importante

Se un set di dati deve essere leggibile, non impostare criteri per spostare i BLOB nel livello archivio. I BLOB nel livello archivio non possono essere letti a meno che non vengano prima riattivati, un processo che potrebbe richiedere molto tempo ed essere costoso. Per altre informazioni, vedere Panoramica di riattivazione di un BLOB dal livello archivio. Se un set di dati deve essere letto spesso, non impostare criteri per spostare i BLOB nei livelli ad accesso sporadico o saltuario, perché ciò potrebbe comportare costi di transazione più elevati.

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

Annotazioni

Microsoft consiglia di caricare i BLOB direttamente nel livello di archiviazione per una maggiore efficienza. È possibile specificare il livello archivio nell'intestazione x-ms-access-tier nell'operazione Put BLOB o Put Block List. L'intestazione x-ms-access-tier è supportata con REST versione 2018-11-09 e successive o con le librerie client di archiviazione BLOB più recenti.

Gestione delle versioni precedenti

Per i dati modificati e a cui si accede regolarmente per tutta la durata, è possibile abilitare il controllo delle versioni dell'archivio BLOB per mantenere automaticamente le versioni precedenti di un oggetto. È possibile creare un criterio per la suddivisione in livelli delle versioni precedenti. L'età della versione viene determinata valutando la sua data/ora di creazione. Questa regola dei criteri sposta le versioni precedenti all'interno del contenitore activedata che hanno 90 giorni o più dopo la creazione della versione nel livello ad accesso ridotto.

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

Annotazioni

L'elemento version in un criterio di gestione del ciclo di vita fa riferimento a una versione precedente.

Vedere anche

  • Last updated on