Condividi tramite

Struttura dei criteri di gestione del ciclo di vita di Archiviazione BLOB di Azure

È possibile usare i criteri di gestione del ciclo di vita per eseguire la transizione dei BLOB ai livelli di accesso convenienti in base ai modelli di utilizzo. È anche possibile eliminare completamente i BLOB alla fine del ciclo di vita. I criteri possono operare su versioni correnti, versioni precedenti e snapshot, ma un criterio non funziona sui BLOB nei contenitori di sistema, ad esempio i contenitori $logs o $web . Per informazioni generali, vedere la Panoramica sulla gestione del ciclo di vita di Azure Blob Storage.

Questo articolo descrive gli elementi di un criterio di gestione del ciclo di vita. Per esempi di criteri, vedere gli articoli seguenti:

Suggerimento

Anche se la gestione del ciclo di vita consente di ottimizzare i costi per un singolo account, è possibile usare Azioni di archiviazione di Azure per eseguire più operazioni sui dati su larga scala tra più account.

Regole

I criteri di gestione del ciclo di vita sono una raccolta di regole in un documento JSON. L'esempio JSON seguente mostra la definizione completa di una regola:

{
  "rules": [
    {
      "name": "rule1",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {...}
    },
    {
      "name": "rule2",
      "type": "Lifecycle",
      "definition": {...}
    }
  ]
}
Nome del parametro Tipo di parametro Note
norme Una matrice di oggetti regola Un criterio deve contenere almeno una regola. È possibile definire fino a 100 regole in un criterio.

Ogni regola all'interno dei criteri ha diversi parametri, descritti nella tabella seguente:

Nome del parametro TIPO Note Obbligatorio
nome Stringa Un nome di regola può contenere fino a 256 caratteri alfanumerici. Il nome della regola fa distinzione tra maiuscole e minuscole. Il nome deve essere univoco nel criterio. Sì
abilitato Booleano Un valore booleano facoltativo per consentire la disabilitazione temporanea della regola. Il valore predefinito è true. NO
tipo Un valore di enumerazione Il tipo valido corrente è Lifecycle. Sì
definizione Un oggetto che definisce la regola del ciclo di vita Ogni definizione è composta da un set di filtri e un set di azioni. Sì

Filtri

I filtri limitano le azioni a un sottoinsieme di BLOB all'interno dell'account di archiviazione. È possibile usare un filtro per specificare i BLOB da includere. Un filtro non consente di specificare i BLOB da escludere. Se vengono definiti più filtri, viene applicato un AND logico a tutti i filtri. Nella tabella seguente viene descritto ogni parametro.

Nome filtro TIPO Descrizione Obbligatorio
blobTypes Matrice di valori di enumerazione predefiniti Tipo di BLOB ( blockblob o appendBlob) Sì
prefixMatch Matrice di stringhe Queste stringhe sono prefissi da associare. NO
blobIndexMatch Matrice di valori del dizionario Questi valori consistono di condizioni da soddisfare per le chiavi e i valori dei tag dell'indice BLOB. NO

Filtro di corrispondenza del prefisso

Se si applica il filtro prefixMatch , ogni regola può definire fino a 10 prefissi con distinzione tra maiuscole e minuscole. Una stringa di prefisso deve iniziare con un nome di contenitore. Ad esempio, se si vuole trovare la corrispondenza con tutti i blob nel percorso https://myaccount.blob.core.windows.net/sample-container/blob1/..., specificare il prefixMatch come sample-container/blob1.

Questo filtro corrisponderà a tutti i BLOB in sample-container cui i nomi iniziano con blob1. Se non si definisce una corrispondenza di prefisso, allora la regola si applica a tutti i BLOB all'interno dell'account di archiviazione. Le stringhe di prefisso non supportano la corrispondenza con caratteri jolly. I caratteri come * e ? vengono considerati come valori letterali stringa.

Filtro di corrispondenza dell'indice BLOB

Se si applica il filtro blobIndexMatch , ogni regola può definire fino a 10 condizioni dei tag di indice BLOB. Ad esempio, se si desidera trovare tutti i BLOB con Project = Contoso in https://myaccount.blob.core.windows.net/, allora il filtro blobIndexMatch è {"name": "Project","op": "==","value": "Contoso"}. Se non si definisce un valore per il filtro blobIndexMatch , la regola si applica a tutti i BLOB all'interno dell'account di archiviazione.

Azioni

È necessario definire almeno un'azione per ogni regola. Le azioni vengono applicate ai BLOB filtrati quando viene soddisfatta la condizione di esecuzione. Per altre informazioni sulle condizioni di esecuzione, vedere la sezione Condizioni di esecuzione delle azioni di questo articolo. La tabella seguente descrive ogni azione disponibile in una definizione di criteri.

Azione Descrizione
TierToCool Impostare un BLOB sul livello di accesso freddo.

Non supportato con blob di accodamento, blob di pagine o blob in un account di archiviazione in blocchi Premium.
TierToCold Impostare un blocco sul livello di accesso freddo.

Non supportato con blob di accodamento, blob di pagine o blob in un account di archiviazione in blocchi Premium.
TierToArchive Impostare un BLOB sul livello di accesso all'archiviazione.

La reidratazione di un BLOB non aggiorna la proprietà dell'ora dell'ultima modifica o dell'ultimo accesso del BLOB. Di conseguenza, questa azione potrebbe spostare nuovamente i BLOB riattivati nel livello di archivio. Per evitare che ciò accada, aggiungere la daysAfterLastTierChangeGreaterThan condizione a questa azione.

Questa azione non è supportata con BLOB di accodamento, BLOB di pagine o BLOB in un account di archiviazione Premium per BLOB in blocchi. Non supportato anche con BLOB che usano un ambito di crittografia o blob negli account configurati per l'archiviazione con ridondanza della zona (ZRS), l'archiviazione con ridondanza geografica della zona (GZRS) o l'archiviazione con ridondanza geografica della zona di accesso in lettura (RA-GZRS).
abilitaLaScalabilitàAutomaticaDaCoolAFredde Se un blob è impostato sul livello "cool", questa azione sposta automaticamente quel blob nel livello "hot" quando viene effettuato l'accesso.

Questa azione è disponibile solo se usata con la condizione di esecuzione daysAfterLastAccessTimeGreaterThan .

Questa azione non ha alcun effetto sui BLOB impostati sul livello freddo prima di abilitare questa azione in una regola.

Questa azione sposta i BLOB da freddo a caldo solo una volta ogni 30 giorni. Questa protezione è messa in atto per proteggere da più penali di eliminazione anticipata addebitate all'account.

Non supportato con versioni precedenti o snapshot.
Elimina Elimina un blob.

Non supportato per blob di pagine o blob in un contenitore non modificabile.

Se si definiscono più azioni sullo stesso BLOB, la gestione del ciclo di vita applica l'azione meno costosa al BLOB. Ad esempio, un'azione di eliminazione è più economica rispetto all'azione tierToArchive e l'azione tierToArchive è più economica rispetto all'azione tierToCool.

Azioni di eliminazione negli account che hanno uno spazio dei nomi gerarchico

Se applicato a un account con uno spazio dei nomi gerarchico abilitato, un'azione di eliminazione rimuove le directory vuote. Se la directory non è vuota, l'azione di eliminazione rimuove gli oggetti che soddisfano le condizioni dei criteri all'interno del primo ciclo di vita di esecuzione dei criteri. Se tale azione restituisce una directory vuota che soddisfa anche le condizioni dei criteri, tale directory verrà rimossa con il ciclo di esecuzione successivo e così via.

Eliminare l'azione sui BLOB con versioni e snapshot

I criteri di gestione del ciclo di vita non elimineranno la versione corrente di un BLOB fino a quando non vengono eliminate versioni o snapshot precedenti associati a tale BLOB. Se i BLOB nell'account di archiviazione hanno versioni o snapshot precedenti, è necessario includere versioni e snapshot precedenti quando si specifica un'azione di eliminazione come parte dei criteri.

Condizioni di esecuzione delle azioni

Tutte le condizioni operative sono basate sul tempo. Se il numero di giorni trascorsi supera il numero specificato per la condizione, l'azione associata può essere eseguita. Le condizioni dei criteri vengono valutate in ogni oggetto una sola volta durante un'esecuzione dei criteri. In alcuni casi, un oggetto potrebbe soddisfare la condizione dopo che è già stata valutata da un'esecuzione. Tali oggetti vengono elaborati nelle esecuzioni successive.

Le versioni correnti usano l'ora dell'ultima modifica o l'ora dell'ultimo accesso, le versioni precedenti usano l'ora di creazione della versione e gli snapshot BLOB usano l'ora di creazione dello snapshot per tenere traccia dell'età.

La tabella seguente descrive ogni condizione di esecuzione dell'azione.

Nome condizione TIPO Descrizione
daysAfterModificationGreaterThan Numero intero Età in giorni dall'ultima modifica del BLOB. Si applica alle azioni sulla versione attuale di Blob.
daysAfterCreationGreaterThan Numero intero Età in giorni successivi all'ora di creazione. Si applica alle azioni sulla versione corrente di un BLOB, sulla versione precedente di un BLOB o su uno snapshot di un BLOB.
giorniDopoLultimoAccessoMaggioriDi Numero intero Età in giorni dall'ora dell'ultimo accesso o, in alcuni casi, dalla data in cui la politica è stata abilitata. Per altre informazioni, vedere la sezione Rilevamento tempo di accesso di seguito. Si applica alle azioni nella versione corrente di un BLOB quando il rilevamento degli accessi è abilitato.
giorniDopoUltimaModificaDiLivelloMaggioriDi Numero intero Età in giorni dall'ultima modifica del livello del blob. La durata minima in giorni per cui un BLOB riattivato viene mantenuto in livelli ad accesso frequente, sporadico o saltuario prima di essere restituito al livello archivio. Si applica solo alle azioni tierToArchive .

Rilevamento dell'ora di accesso

È possibile abilitare il rilevamento del tempo di accesso per mantenere un record dell'ultima lettura o scrittura del BLOB e come filtro per gestire la suddivisione in livelli e la conservazione dei dati BLOB.

Quando si abilita il rilevamento dell'ora di accesso, una proprietà BLOB denominata LastAccessTime viene aggiornata quando un BLOB viene letto o scritto. Le operazioni Get BLOB e Put BLOB sono operazioni di accesso e aggiorneranno l'ora di accesso di un BLOB. Tuttavia, le proprietà Get BLOB, Get Blob Metadata e Get BLOB Tags non sono operazioni di accesso. Queste operazioni non aggiornano l'ora di accesso di un blob.

Se si applica la condizione di esecuzione daysAfterLastAccessTimeGreaterThan a un criterio, viene utilizzato LastAccessTime per stabilire se tale condizione è soddisfatta.

Se si applica la condizione di esecuzione daysAfterLastAccessTimeGreaterThan a un criterio, ma non è stato abilitato il rilevamento dell'ora di accesso, allora LastAccessTime non sarà usato. La data in cui è stata abilitata l'ultima verifica dell'accesso viene invece usata. In realtà, la data in cui è stato abilitato l'ultimo rilevamento di accesso viene usata in qualsiasi situazione in cui la LastAccessTime proprietà del BLOB è un valore Null. Ciò può verificarsi anche se è stato abilitato il rilevamento del tempo di accesso nei casi in cui non è stato eseguito l'accesso a un BLOB dopo l'abilitazione del rilevamento.

Annotazioni

Per ridurre al minimo l'effetto sulla latenza di accesso in lettura, solo la prima lettura delle ultime 24 ore aggiorna l'ora dell'ultimo accesso. Le letture successive nello stesso periodo di 24 ore non aggiornano l'ora dell'ultimo accesso. Se un BLOB viene modificato tra le letture, l'ora dell'ultimo accesso è quella più recente dei due valori.

Per informazioni su come abilitare il rilevamento del tempo di accesso, vedere Facoltativamente abilitare il rilevamento dell'ora di accesso.

Passaggi successivi

  • Last updated on