Ottimizzare i costi gestendo automaticamente 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 accedere spesso diminuisce drasticamente man mano che i dati sono di età. Alcuni dati rimangono inattive nel cloud e vengono raramente accessibili dopo l'archiviazione. Alcuni set di dati scadono giorni o mesi dopo la creazione, mentre altri set di dati vengono letti e modificati attivamente per tutta la durata. Archiviazione BLOB di Azure la gestione del ciclo di vita offre criteri basati su regole che è possibile usare per eseguire la transizione dei dati BLOB ai livelli di accesso appropriati o alla scadenza dei dati alla fine del ciclo di vita dei dati.
Nota
Ogni ultimo aggiornamento dell'ora di accesso viene addebitato come "altra transazione" al massimo ogni 24 ore per oggetto, anche se si accede a 1000 volte in un giorno. Questa operazione è separata dagli addebiti per le transazioni di lettura.
I criteri di gestione del ciclo di vita consentono di eseguire queste operazioni:
- Eseguire la transizione dei BLOB dall'accesso sporadico all'accesso frequente immediatamente, 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 questi oggetti non sono stati accessibili o 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 blob alla fine dei relativi cicli di vita.
- Applicare regole a un intero account di archiviazione, selezionare contenitori o a un subset di BLOB usando prefissi dei nomi o tag di indice BLOB come filtri.
Si consideri uno scenario in cui i dati vengono spesso accessibili durante le fasi iniziali 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.
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 $logs contenitori 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 riattivati per la prima volta, un processo che potrebbe richiedere molto tempo e 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 sporadico, perché ciò potrebbe comportare costi di transazione più elevati.
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 una definizione completa della regola:
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
Un criterio è 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 del criterio 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 in un criterio 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; Il livello set non è supportato. |
Sì |
| prefixMatch | Matrice di stringhe per i prefissi di cui trovare la corrispondenza. 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 in https://myaccount.blob.core.windows.net/sample-container/blob1/..., specificare il prefissoMatch come sample-container/blob1. Questo filtro corrisponderà a tutti i BLOB in sample-container i cui nomi iniziano con BLOB1.. |
Se non si definisce prefixMatch, 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, ad * esempio 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. Ad esempio, se si vuole trovare una corrispondenza con tutti i BLOB con Project = Contoso under https://myaccount.blob.core.windows.net/ per una regola, blobIndexMatch è {"name": "Project","op": "==","value": "Contoso"}. |
Se non si definisce blobIndexMatch, la regola si applica a tutti i BLOB all'interno dell'account di archiviazione. | No |
Per altre informazioni sulla funzionalità di indice BLOB insieme a problemi noti e limitazioni, vedere Gestire e trovare dati in Archiviazione BLOB di Azure con 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 |
| eliminare2,3 | Supportato per blockBlob e appendBlob |
Supportata | Supportata |
1 L'azione enableAutoTierToHotFromCool è disponibile solo se usata con la daysAfterLastAccessTimeGreaterThan condizione di esecuzione. Tale condizione è descritta nella tabella successiva.
2 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 entro 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 sono state eliminate le versioni o gli 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, archiviazione con ridondanza geografica o archiviazione con ridondanza geografica supportano lo spostamento dei BLOB nel livello di archiviazione. 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 il tempo 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 | Questa condizione si applica solo alle azioni tierToArchive e può essere usata solo con la condizione daysAfterModificationGreaterThan. |
1 Se il rilevamento dell'ora dell'ultimo accesso non è abilitato, daysAfterLastAccessTimeGreaterThan usa la data in cui il criterio del ciclo di vita è stato abilitato anziché la LastAccessTimeproprietà del BLOB. Questa data viene utilizzata anche quando la LastAccessTime proprietà è 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 relativi al ciclo di vita
La piattaforma esegue i criteri di gestione del ciclo di vita una volta al giorno. Quando si configurano o si modificano criteri relativi al 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 fatturate 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. Il codice JSON seguente mostra un esempio di evento LifecyclePolicyCompleted.
{
"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": ""
},
"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 | byte vettoriale<> | Riepilogo dei risultati dei BLOB pianificati per l'operazione di eliminazione |
| tierToCoolSummary | byte vettoriale<> | Riepilogo dei risultati dei BLOB pianificati per l'operazione da livello a accesso sporadico |
| tierToArchiveSummary | byte vettoriale<> | Riepilogo dei risultati dei BLOB pianificati per l'operazione da livello a archivio |
Esempi di criteri relativi al 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 di quando 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 dell'ora 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 Get BLOB viene considerata un'operazione di accesso. Le proprietà del BLOB, Recupera metadati BLOB e Recupera tag BLOB non sono operazioni di accesso e pertanto 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 LastAccessTime vita anziché nei casi seguenti:
Il valore della
LastAccessTimeproprietà del BLOB è un valore Null.Nota
La
lastAccessedOnproprietà del BLOB è Null se non è stato eseguito l'accesso a un BLOB dall'ultima verifica dell'ora di accesso abilitata.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 sono stati accessibili per 30 giorni. La enableAutoTierToHotFromCool proprietà è un valore booleano che indica se un BLOB deve essere automaticamente a livelli dall'accesso sporadico all'accesso frequente se si accede di nuovo dopo essere stato a livelli per l'accesso sporadico.
Suggerimento
Se un BLOB viene spostato nel livello ad accesso sporadico e quindi viene automaticamente spostato indietro prima della scadenza di 30 giorni, viene addebitata una tariffa per l'eliminazione anticipata. Prima di impostare la enablAutoTierToHotFromCool proprietà, 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 inattive nel cloud ed è raramente, se mai, accessibile. I criteri relativi al ciclo di vita seguenti 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 di archivio. La transizione viene eseguita agendo sui BLOB 0 giorni dopo l'ora 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 devono 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 mostra 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 dati con tag di indice BLOB
Alcuni dati devono essere scaduti solo se contrassegnati in modo esplicito per l'eliminazione. È possibile configurare 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 dati in Archiviazione BLOB di Azure con 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 un criterio per la suddivisione in livelli o l'eliminazione di versioni precedenti. L'età della versione è determinata dalla valutazione dell'ora di creazione della versione. Questa regola dei criteri sposta le versioni precedenti all'interno del contenitore activedata di 90 giorni o precedenti dopo la creazione della versione al livello ad accesso sporadico ed elimina le versioni precedenti di 365 giorni o precedenti.
{
"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 per i costi delle operazioni standard per le chiamate ALL'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 per le operazioni gestite tramite criteri relativi al ciclo di vita.
Ogni aggiornamento all'ora dell'ultimo accesso di un BLOB viene fatturato nella categoria di altre operazioni .
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.
Se per l'account di archiviazione si abilitano regole firewall, è possibile che le richieste di gestione del ciclo di vita vengano bloccate. È possibile sbloccarle specificando eccezioni per servizi attendibili di Microsoft. Per altre informazioni, vedere la sezione Eccezioni in Configurare firewall e reti virtuali.
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 un criterio non modificabile, 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.