Ottimizzare i costi gestendo automaticamente il ciclo di vita dei dati
La gestione del ciclo di vita di Archiviazione BLOB di Azure offre criteri basati su regole che è possibile usare per trasferire i dati BLOB al livello di accesso più appropriato e definirne la scadenza al termine del relativo ciclo di vita.
I criteri di gestione del ciclo di vita consentono di eseguire queste operazioni:
- Eseguire immediatamente la transizione dei BLOB da un accesso sporadico a uno frequente, quando vi si accede per ottimizzare le prestazioni.
- Eseguire la transizione delle versioni correnti di un BLOB, delle versioni precedenti di un BLOB o degli snapshot blob a un livello di archiviazione più sporadico se non si è acceduto a questi oggetti o se non sono stati modificati per un periodo di tempo, per ottimizzare i costi.
- Eliminare le versioni correnti di un BLOB, le versioni precedenti di un BLOB o gli snapshot di BLOB alla fine dei relativi cicli di vita.
- Applicare regole a un intero account di archiviazione, a contenitori selezionati o a un subset di BLOB usando prefissi dei nomi o tag di indici BLOB come filtri.
Suggerimento
Anche se la gestione del ciclo di vita consente di spostare i dati tra livelli in un singolo account, è possibile usare un'attività di archiviazione per eseguire questa attività su larga scala tra più account. Un’attività di archiviazione è una risorsa disponibile in Azioni di archiviazione di Azure; un framework serverless che è possibile usare per eseguire operazioni dei dati comuni su milioni di oggetti in più account di archiviazione. Per altre informazioni, vedere Che cos’è Azioni di Archiviazione di Azure?.
I criteri di gestione del ciclo di vita sono supportati per account di tipo BLOB in blocchi e i BLOB di aggiunta nel livello Utilizzo generico v2, BLOB in blocchi Premium e account di Archiviazione BLOB. La gestione del ciclo di vita non influisce sui contenitori di sistema, ad esempio i contenitori $logs o $web.
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.
Ottimizzazione dei costi gestendo il ciclo di vita dei dati
I set di dati hanno cicli di vita specifici. All'inizio del ciclo di vita, gli utenti accedono ad alcuni dati spesso. Tuttavia, la necessità di accesso spesso si riduce drasticamente con l'invecchiamento dei dati. Alcuni dati rimangono inattivi nel cloud e gli utenti vi accedono raramente dopo l'archiviazione. Alcuni set di dati scadono giorni o mesi dopo la creazione, mentre altri set di dati vengono letti e modificati per l'intero ciclo di vita.
Considerare uno scenario in cui viene spesso effettuato l’accesso ai dati durante le prime fasi del ciclo di vita, ma solo occasionalmente dopo due settimane. Oltre il primo mese, l'accesso al set di dati è raro. In questo scenario è consigliabile l'archiviazione ad accesso frequente durante le fasi iniziali. L'archiviazione ad accesso sporadico è più appropriata per l'accesso occasionale. L'archiviazione archivio è l'opzione di livello migliore dopo che i dati hanno superato il mese di vita. Spostando i dati nel livello di archiviazione appropriato in base all'età con le regole dei criteri di gestione del ciclo di vita, è possibile progettare la soluzione meno costosa per le proprie esigenze.
Definizione dei criteri di gestione del ciclo di vita
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": {...}
}
]
}
I criteri sono una raccolta di regole, come descritto nella tabella seguente:
| Nome parametro | Tipo di parametro | Note |
|---|---|---|
rules |
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 parametro | Tipo di parametro | Note | Richiesto |
|---|---|---|---|
name |
Stringa | Un nome di regola può contenere fino a 256 caratteri alfanumerici. Nel nome della regola viene applicata la distinzione tra maiuscole e minuscole. Il nome deve essere univoco nel criterio. | Vero |
enabled |
Boolean | Un valore booleano facoltativo per consentire la disabilitazione temporanea della regola. Il valore predefinito è true se non viene impostato. | False |
type |
Un valore di enumerazione | Il tipo valido corrente è Lifecycle. |
Vero |
definition |
Un oggetto che definisce la regola del ciclo di vita | Ogni definizione è composta da un set di filtri e un set di azioni. | Vero |
Definizione della regola di gestione del ciclo di vita
Ogni definizione di regola all'interno di un criterio include un set di filtri e un set di azioni. Il set di filtri limita le azioni della regola a un determinato set di oggetti all'interno di un contenitore o di nomi di oggetti. Il set di azioni applica le azioni tier o delete al set filtrato di oggetti.
Regola di esempio
La regola di esempio riportata di seguito filtra l'account per eseguire le azioni sugli oggetti presenti in sample-container e iniziare con blob1.
- Impostare il BLOB sul livello di accesso sporadico 30 giorni dopo l'ultima modifica
- Impostare il BLOB sul livello archivio 90 giorni dopo l'ultima modifica
- Eliminare il BLOB 2.555 giorni (7 anni) dopo l'ultima modifica
- Eliminare le versioni precedenti 90 giorni dopo la creazione
{
"rules": [
{
"enabled": true,
"name": "sample-rule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"delete": {
"daysAfterCreationGreaterThan": 90
}
},
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
},
"tierToArchive": {
"daysAfterModificationGreaterThan": 90,
"daysAfterLastTierChangeGreaterThan": 7
},
"delete": {
"daysAfterModificationGreaterThan": 2555
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"sample-container/blob1"
]
}
}
}
]
}
Nota
L'elemento baseBlob nei criteri di gestione del ciclo di vita fa riferimento alla versione corrente di un BLOB. L'elemento version fa riferimento a una versione precedente.
Filtri della regola
I filtri limitano le azioni della regola a un sottoinsieme di BLOB all'interno dell'account di archiviazione. Se viene definito più di un filtro, viene eseguito un AND logico su tutti i filtri. È possibile usare un filtro per specificare i BLOB da includere. Un filtro non consente di specificare i BLOB da escludere.
I filtri includono:
| Nome filtro | Tipo di filtro | Note | Obbligatorio |
|---|---|---|---|
| blobTypes | Una matrice di valori di enumerazione predefiniti. | La versione corrente supporta blockBlob e appendBlob. Solo l'azione Elimina è supportata per appendBlob; Imposta livello non è supportato. |
Sì |
| prefixMatch | Matrice di stringhe per i prefissi da associare. 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. Se ad esempio si vogliono cercare tutti i BLOB sotto https://myaccount.blob.core.windows.net/sample-container/blob1/..., specificare prefixMatch come sample-container/blob1. Questo filtro corrisponderà a tutti i BLOB in sample-container i cui nomi iniziano con blob1.. |
Se prefixMatch non è definito, 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. |
No |
| blobIndexMatch | Una matrice di valori di dizionario costituiti da chiave di tag indice BLOB e condizioni di valore da associare. Ogni regola può definire fino a 10 condizioni di tag indice BLOB. Se ad esempio si vogliono cercare tutti i BLOB con Project = Contoso sotto https://myaccount.blob.core.windows.net/ per una regola, blobIndexMatch è {"name": "Project","op": "==","value": "Contoso"}. |
Se blobIndexMatch non è definito, la regola si applica a tutti i BLOB all'interno dell'account di archiviazione. | No |
Per altre informazioni su questa funzionalità indice BLOB insieme ai problemi noti e alle limitazioni, vedere Gestire e trovare i dati nell'archiviazione BLOB di Azure con l'indice BLOB.
Azioni della regola
Le azioni vengono applicate ai BLOB filtrati quando viene soddisfatta la condizione di esecuzione.
La gestione del ciclo di vita supporta la suddivisione in livelli e l'eliminazione delle versioni correnti, delle versioni precedenti e degli snapshot BLOB. Definire almeno un'azione per ogni regola.
Nota
La suddivisione in livelli non è ancora supportata in un account di archiviazione BLOB in blocchi Premium. Per tutti gli altri account, la suddivisione in livelli è consentita solo nei BLOB in blocchi e non per i BLOB di accodamento e di pagine.
| Azione | Versione corrente | Snapshot | Versioni precedenti |
|---|---|---|---|
| tierToCool | Supportato per blockBlob |
Supportata | Supportata |
| tierToCold | Supportato per blockBlob |
Supportata | Supportata |
| enableAutoTierToHotFromCool1 | Supportato per blockBlob |
Non supportato | Non supportato |
| tierToArchive4 | Supportato per blockBlob |
Supportata | Supportata |
| delete2,3 | Supportato per blockBlob e appendBlob |
Supportata | Supportata |
1 L'azione enableAutoTierToHotFromCool è disponibile solo se usata con la condizione di esecuzione daysAfterLastAccessTimeGreaterThan. Tale condizione è descritta nella tabella successiva.
2 Se applicata 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.
3 Un criterio di gestione del ciclo di vita non eliminerà la versione corrente di un BLOB fino a quando non vengono eliminati eventuali 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.
4 Solo gli account di archiviazione configurati per l'archiviazione con ridondanza locale, l'archiviazione con ridondanza geografica o l'archiviazione con ridondanza geografica e accesso in lettura supportano lo spostamento dei BLOB nel livello archivio. Il livello archivio non è supportato per gli account con archiviazione con ridondanza della zona, archiviazione con ridondanza geografica della zona o archiviazione con ridondanza geografica della zona e accesso in lettura. Questa azione viene elencata in base alla ridondanza configurata per l'account.
Nota
Se nello stesso BLOB è stata definita più di un'azione, la gestione del ciclo di vita applica al BLOB l'azione meno costosa. Ad esempio, l'azione delete è meno costosa dell'azione tierToArchive. L'azione tierToArchive è meno costosa dell'azione tierToCool.
Le condizioni di esecuzione si basano sulla durata. 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à.
| Condizione di esecuzione dell'azione | Valore della condizione | Descrizione |
|---|---|---|
| daysAfterModificationGreaterThan | Valore intero che indica il tempo trascorso in giorni | Condizione per le azioni in una versione corrente di un BLOB |
| daysAfterCreationGreaterThan | Valore intero che indica il tempo trascorso in giorni | Condizione per le azioni nella versione corrente o nella versione precedente di un BLOB o di uno snapshot BLOB |
| daysAfterLastAccessTimeGreaterThan1 | Valore intero che indica il tempo trascorso in giorni | Condizione per una versione corrente di un BLOB quando è abilitato il rilevamento degli accessi |
| daysAfterLastTierChangeGreaterThan | Valore intero che indica l'età in giorni dopo l'ultima modifica del livello 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. Questa condizione si applica solo alle azioni tierToArchive. |
1 Se il rilevamento dell'ora dell'ultimo accesso non è abilitato, daysAfterLastAccessTimeGreaterThan usa la data in cui i criteri relativi al ciclo di vita sono stati abilitati anziché la proprietà LastAccessTime del BLOB. Questa data viene utilizzata anche quando la proprietà LastAccessTime è un valore null. Per altre informazioni sull'uso del rilevamento dell'ora dell'ultimo accesso, vedere Spostare i dati in base all'ora dell'ultimo accesso.
Esecuzioni dei criteri del ciclo di vita
Quando si configura o si modifica un criterio del ciclo di vita, possono essere necessarie fino a 24 ore prima che le modifiche vengano applicate e che la prima esecuzione venga avviata. Il tempo impiegato per il completamento delle azioni dei criteri dipende dal numero di BLOB valutati e gestiti.
Se si disabilita un criterio, non verranno pianificate nuove esecuzioni di criteri, ma se un'esecuzione è già in corso, tale esecuzione continuerà fino al completamento e verranno addebitate tutte le azioni necessarie per completare l'esecuzione. Vedere Disponibilità e prezzi a livello di area.
Criteri relativi al ciclo di vita: evento completato
L'evento LifecyclePolicyCompleted viene generato quando vengono eseguite le azioni definite da criteri di gestione del ciclo di vita. Viene visualizzata una sezione di riepilogo per ogni azione inclusa nella definizione dei criteri. Il codice JSON seguente mostra un evento di esempio LifecyclePolicyCompleted per un criterio. Poiché la definizione dei criteri include le deleteazioni , tierToCool, tierToColde tierToArchive , viene visualizzata una sezione di riepilogo per ognuna di esse.
{
"topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
"subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
"eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
"eventTime": "2022-05-26T00:00:40.1880331",
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"data": {
"scheduleTime": "2022/05/24 22:57:29.3260160",
"deleteSummary": {
"totalObjectsCount": 16,
"successCount": 14,
"errorList": ""
},
"tierToCoolSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToColdSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToArchiveSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
}
},
"dataVersion": "1",
"metadataVersion": "1"
}
Nella tabella seguente viene descritto lo schema dell'evento LifecyclePolicyCompleted.
| Campo | Tipo | Descrizione |
|---|---|---|
| scheduleTime | string | Ora in cui sono stati pianificati i criteri relativi al ciclo di vita |
| deleteSummary | vector<byte> | Riepilogo dei risultati dei BLOB pianificati per l'operazione di eliminazione |
| tierToCoolSummary | vector<byte> | Riepilogo dei risultati dei BLOB pianificati per l'operazione di passaggio da livello ad accesso sporadico |
| tierToColdSummary | vector<byte> | Riepilogo dei risultati dei BLOB pianificati per l'operazione da livello a freddo |
| tierToArchiveSummary | vector<byte> | Riepilogo dei risultati dei BLOB pianificati per l'operazione di passaggio da livello ad archivio |
Esempi di criteri del ciclo di vita
Gli esempi seguenti illustrano come affrontare scenari comuni relativi alle regole dei criteri del ciclo di vita.
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 }
}
}
}
}
]
}
Spostare i dati in base all'ora dell'ultimo accesso
È possibile abilitare il rilevamento dell'ora dell'ultimo accesso per mantenere un record de momento in cui il BLOB è stato letto o scritto e come filtro per gestire la suddivisione in livelli e la conservazione dei dati BLOB. Per informazioni su come abilitare il rilevamento dell'ora dell'ultimo accesso, vedere Facoltativamente abilitare il rilevamento del momento di accesso.
Quando il rilevamento dell'ora dell'ultimo accesso è abilitato, la proprietà BLOB chiamata LastAccessTime viene aggiornata quando un BLOB viene letto o scritto. Un'operazione di recupero BLOB viene considerata un'operazione di accesso. Recupera proprietà BLOB, Recupera i metadati del BLOB e Recupera tag BLOB non sono operazioni di accesso e quindi non aggiornano l'ora dell'ultimo accesso.
Se il rilevamento dell'ora dell'ultimo accesso è abilitato, la gestione del ciclo di vita usa LastAccessTime per determinare se la condizione di esecuzione daysAfterLastAccessTimeGreaterThan viene soddisfatta. La gestione del ciclo di vita usa la data di abilitazione dei criteri relativi al ciclo di vita anziché LastAccessTime nei casi seguenti:
Il valore della proprietà
LastAccessTimedel BLOB è un valore Null.Nota
La proprietà
lastAccessedOndel BLOB è Null se non è stato eseguito l'accesso a un BLOB dall'ultima volta che è stato attivato il rilevamento dell'ora di accesso.Il rilevamento dell'ora dell'ultimo accesso non è abilitato.
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.
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à enablAutoTierToHotFromCool, assicurarsi di analizzare i modelli di accesso dei dati in modo da ridurre gli addebiti imprevisti.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Archiviare i 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.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Nota
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.
Impostare la scadenza dei dati in base al tempo trascorso
Alcuni dati sono destinati a scadere giorni o mesi dopo la creazione. È possibile configurare un criterio di gestione del ciclo di vita per impostare la scadenza dei dati tramite eliminazione in base al tempo trascorso. L'esempio seguente illustra un criterio che elimina tutti i BLOB in blocchi che non sono stati modificati negli ultimi 365 giorni.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Eliminare i dati con i tag indice BLOB
Alcuni dati devono essere scaduti solo se contrassegnati in modo esplicito per l'eliminazione. È possibile configurare dei criteri di gestione del ciclo di vita per la scadenza dei dati contrassegnati con attributi chiave/valore dell'indice BLOB. Nell'esempio seguente viene illustrato un criterio che elimina tutti i BLOB in blocchi contrassegnati con Project = Contoso. Per altre informazioni sull'indice BLOB, vedere Gestire e trovare i dati in Archiviazione BLOB di Azure con l'indice BLOB.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Gestire le 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 criteri per la suddivisione in livelli o l'eliminazione 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 con 90 giorni o più dopo la creazione della versione nel livello ad accesso sporadico ed elimina le versioni precedenti che hanno più di 365 giorni.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Disponibilità e prezzi a livello di area
La funzionalità di gestione del ciclo di vita è disponibile in tutte le aree di Azure.
I criteri di gestione del ciclo di vita sono gratuiti. I clienti vengono fatturati in base ai costi delle operazioni standard per le chiamate API Set Blob Tier. Le operazioni di eliminazione sono gratuite. Tuttavia, altri servizi e utilità di Azure, ad esempio Microsoft Defender per Archiviazione, possono essere addebitati in base alle operazioni gestite tramite criteri relativi al ciclo di vita.
Ogni aggiornamento all'ora dell'ultimo accesso di un BLOB viene fatturato nella categoria altre operazioni. Ogni aggiornamento dell'ora dell'ultimo accesso viene addebitato come "altra transazione" al massimo ogni 24 ore per oggetto, anche se vi si accede migliaia di volte in un giorno. Questa operazione è separata dagli addebiti per le transazioni di lettura.
Per altre informazioni sui prezzi, vedi Prezzi dei BLOB in blocchi.
Problemi noti e limitazioni
La suddivisione in livelli non è ancora supportata in un account di archiviazione BLOB in blocchi Premium. Per tutti gli altri account, la suddivisione in livelli è consentita solo nei BLOB in blocchi e non per i BLOB di accodamento e di pagine.
I criteri di gestione del ciclo di vita devono essere letti o scritti in modo completo. Gli aggiornamenti parziali non sono supportati.
Ogni regola può avere fino a 10 prefissi con distinzione tra maiuscole e minuscole e fino a 10 condizioni dei tag di indice BLOB.
I criteri di gestione del ciclo di vita non possono modificare il livello di un BLOB che usa un ambito di crittografia.
L'azione di eliminazione di un criterio di gestione del ciclo di vita non funzionerà con alcun BLOB in un contenitore non modificabile. Con criteri non modificabili, gli oggetti possono essere creati e letti, ma non modificati o eliminati. Per altre informazioni, vedere Archiviare dati di BLOB critici con archiviazione non modificabile.
Domande frequenti
Vedere Domande frequenti sulla gestione del ciclo di vita.