Otimize os custos gerenciando automaticamente o ciclo de vida dos dados
O gerenciamento do ciclo de vida do Armazenamento de Blobs do Azure oferece uma política baseada em regras que é possível usar para fazer a transição dos seus dados de blob para as camadas de acesso apropriadas e para expirar os dados no final do seu ciclo de vida.
A política de gerenciamento do ciclo de vida permite:
- Fazer a transição de blobs de esporádico para frequente imediatamente quando são acessados a fim de otimizar o desempenho.
- Transfira versões atuais de um blob, versões anteriores de um blob ou instantâneos de blob para uma camada de armazenamento mais esporádica se esses objetos não forem acessados ou modificados por um período de tempo para otimizar o custo.
- Exclua as versões atuais de um blob, versões anteriores de um blob ou instantâneos de blob no final de seus ciclos de vida.
- Aplique regras a uma conta de armazenamento inteira para selecionar contêineres ou a um subconjunto de blobs usando prefixos de nome ou marcas de índice de blob como filtros.
Dica
Embora o gerenciamento do ciclo de vida ajude você a mover dados entre camadas em uma única conta, você pode usar uma tarefa de armazenamento para realizar essa tarefa em escala em várias contas. Uma conta de armazenamento é um recurso disponível em Ações de Armazenamento do Azure; uma estrutura sem servidor que você pode usar para executar operações de dados comuns em milhões de objetos em várias contas de armazenamento. Para saber mais, consulte O que são as Ações de Armazenamento do Azure?.
As políticas de gerenciamento de ciclo de vida têm suporte para blobs de blocos e blobs de acréscimo em contas de Armazenamento de Blob, blob de blocos premium de bloco e de uso geral v2. O gerenciamento do ciclo de vida não afeta contêineres do sistema, como $logs ou $web.
Importante
Se um conjunto de dados precisar ser legível, não defina uma política para mover os blobs para a camada de arquivos. Os blobs na camada de arquivo não podem ser lidos, a menos que eles sejam alimentados pela primeira vez, um processo que pode ser demorado e caro. Para obter mais informações, confira Visão geral da reidratação de blob da camada de arquivos. Se um conjunto de dados precisar ser lido com frequência, não defina uma política para mover blobs para as camadas frescas ou frias, pois isso pode resultar em custos de transação mais altos.
Otimização de custos gerenciando o ciclo de vida de dados
Conjuntos de dados têm ciclos de vida exclusivos. No início do ciclo de vida, as pessoas geralmente acessam alguns dados. Mas a necessidade de acesso cai drasticamente à medida que os dados envelhecem. Alguns dados permanecem ociosos na nuvem e raramente são acessados após serem armazenados. Alguns conjuntos de dados expiram dias ou meses após a criação, enquanto outros conjuntos de dados são lidos e modificados ativamente durante seu tempo de vida.
Considere um cenário onde dados obtém acesso frequente durante os estágios iniciais do ciclo de vida, mas apenas ocasionalmente após duas semanas. Após o primeiro mês, o conjunto de dados raramente é acessado. Nesse cenário, o armazenamento frequente é melhor durante os estágios iniciais. O armazenamento esporádico é mais apropriado para acesso ocasional. O armazenamento de arquivos é a melhor opção de camada após os dados envelhecerem um mês. Ao mover os dados para a camada de armazenamento apropriada com base em sua idade com as regras de política de gerenciamento do ciclo de vida, você pode criar a solução menos dispendiosa para suas necessidades.
Definição da política de gerenciamento do ciclo de vida
Uma política de gerenciamento do ciclo de vida é uma coleção de regras em um documento JSON. O seguinte JSON de exemplo mostra uma definição de regra completa:
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
Uma política é uma coleção de regras, conforme descrito na seguinte tabela:
| Nome do parâmetro | Tipo de parâmetro | Observações |
|---|---|---|
rules |
Uma matriz de objetos de regra | Pelo menos uma regra é necessária em uma política. Você pode definir até 100 regras em uma política. |
Cada regra na política tem vários parâmetros, descritos na seguinte tabela:
| Nome do parâmetro | Tipo de parâmetro | Observações | Obrigatório |
|---|---|---|---|
name |
String | Um nome de regra pode incluir até 256 caracteres alfanuméricos. A regra de nome diferencia maiúsculas de minúsculas. Ela deve ser exclusiva em uma política. | Verdadeiro |
enabled |
Boolean | Um booliano opcional para permitir que uma regra seja desabilitada temporariamente. O valor padrão será true se não estiver definido. | Falso |
type |
Um valor de enumeração | O tipo válido atual é Lifecycle. |
Verdadeiro |
definition |
Um objeto que define a regra de ciclo de vida | Cada definição é composta por um conjunto de filtros e um conjunto de ações. | Verdadeiro |
Definição de regra de gerenciamento do ciclo de vida
Cada definição de regra dentro de uma política inclui um conjunto de filtros e um conjunto de ações. O conjunto de filtros limita as ações de regras a determinado conjunto de objetos em um contêiner ou a nomes de objetos. O conjunto de ações aplica-se a camada ou excluir ações para o conjunto filtrado de objetos.
Regra de exemplo
A regra de exemplo a seguir filtra a conta para executar as ações em objetos que existem dentro de sample-container e começam com blob1.
- Colocar o blob na camada esporádica 30 dias após a última modificação
- Colocar o blob na camada de arquivos 90 dias após a última modificação
- Excluir o blob 2.555 dias (sete anos) após a última modificação
- Excluir versões anteriores 90 dias após a criação
{
"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"
]
}
}
}
]
}
Observação
O elemento baseBlob em uma política de gerenciamento de ciclo de vida refere-se à versão atual de um blob. O elemento version refere-se a uma versão anterior.
Filtros de regra
Os filtros limitam as ações de regra a um subconjunto de blobs na conta de armazenamento. Se mais de um filtro for definido, um AND lógico será executado em todos os filtros. Você pode usar um filtro para especificar quais blobs devem ser incluídos. Um filtro não fornece meios para especificar quais blobs devem ser excluídos.
Filtros incluem:
| Nome do filtro | Tipo de filtro | Observações | Obrigatório |
|---|---|---|---|
| blobTypes | Uma matriz de valores de enumeração predefinidos. | A versão atual dá suporte a blockBlob e appendBlob. Há suporte para a ação Excluir somente para appendBlob. Não há suporte para Definir Camada. |
Yes |
| prefixMatch | Uma matriz de cadeias de caracteres para prefixos a serem correspondidos. Cada regra pode definir até 10 prefixos que diferenciam maiúsculas e minúsculas. Uma cadeia de caracteres de prefixo deve começar com um nome de contêiner. Por exemplo, se você deseja encontrar uma correspondência para todos os blobs em https://myaccount.blob.core.windows.net/sample-container/blob1/..., especifique o prefixMatch como sample-container/blob1. Esse filtro corresponderá a todos os blobs no contêiner de exemplo cujos nomes começam com blob1.. |
Se você não definir prefixMatch, a regra se aplicará a todos os blobs na conta de armazenamento. As cadeias de caracteres de prefixo não dão suporte à correspondência de caracteres coringa. Caracteres como * e ? são tratados como literais das cadeias de caracteres. |
Não |
| blobIndexMatch | Uma matriz de valores de dicionário que consistem em condições de valor e chave de marca de índice de blob a serem combinadas. Cada regra pode definir até 10 condições de marca de Índice de blob. Por exemplo, se você deseja encontrar uma correspondência para todos os blobs com Project = Contoso em https://myaccount.blob.core.windows.net/ para uma regra, o blobIndexMatch é {"name": "Project","op": "==","value": "Contoso"}. |
Se você não definir blobIndexMatch, a regra se aplicará a todos os blobs na conta de armazenamento. | Não |
Para saber mais sobre o recurso de indexação de blobs, assim como problemas e limitações conhecidos, confira Gerenciar e localizar dados no Armazenamento de Blobs do Azure com o índice de blobs.
Ações de regra
Ações são aplicadas aos blobs filtrados quando a condição de execução é atendida.
O gerenciamento do ciclo de vida dá suporte às camadas e exclusão de versões atuais, bem como às versões anteriores e instantâneos de blob. Defina pelo menos uma ação para cada regra.
Observação
Ainda não há suporte para camadas em uma conta de armazenamento de blobs de blocos premium. Para todas as outras contas, a camada é permitida somente em blobs de blocos e não para blobs de acréscimo e de página.
| Ação | Versão atual | Instantâneo | Versões anteriores |
|---|---|---|---|
| tierToCool | Suporte para blockBlob |
Com suporte | Com suporte |
| tierToCold | Suporte para blockBlob |
Com suporte | Com suporte |
| enableAutoTierToHotFromCool1 | Suporte para blockBlob |
Sem suporte | Sem suporte |
| tierToArchive4 | Suporte para blockBlob |
Com suporte | Com suporte |
| delete2,3 | Com suporte para blockBlob e appendBlob |
Com suporte | Com suporte |
1 A ação enableAutoTierToHotFromCool está disponível apenas quando é utilizada com a condição de execução daysAfterLastAccessTimeGreaterThan. Essa condição é descrita na próxima tabela.
2 Quando aplicada a uma conta com um namespace hierárquico habilitado, uma ação de exclusão remove diretórios vazios. Se o diretório não estiver vazio, a ação de exclusão removerá objetos que atendam às condições de política no primeiro ciclo de execução da política de ciclo de vida. Se essa ação resultar em um diretório vazio que também atenda às condições de política, esse diretório será removido no próximo ciclo de execução e assim por diante.
3 Uma política de gerenciamento do ciclo de vida não excluirá a versão atual de um blob até que todas as versões anteriores ou instantâneos associados a esse blob tenham sido excluídos. Se os blobs em sua conta de armazenamento tiverem versões ou instantâneos anteriores, você deverá incluir versões e instantâneos anteriores ao especificar uma ação de exclusão como parte da política.
4 Somente contas de armazenamento configuradas para LRS, GRS ou RA-GRS dão suporte à movimentação de blobs para a camada de armazenamento de arquivos. A camada de armazenamento de arquivos não é compatível com as contas ZRS, GZRS ou RA-GZRS. Essa ação é listada com base na redundância configurada para a conta.
Observação
Se você definir mais de uma ação no mesmo blob, o gerenciamento do ciclo de vida aplicará a ação mais barata ao blob. Por exemplo, a ação delete é mais barata do que a ação tierToArchive. A ação tierToArchive é mais barata do que a ação tierToCool.
As condições de execução são baseadas na idade. As versões atuais usam o horário da última modificação ou do último acesso, as versões anteriores usam a hora de criação da versão e os instantâneos de blob usam a hora de criação do instantâneo para controlar a idade.
| Condição de execução de ação | Valor de condição | Descrição |
|---|---|---|
| daysAfterModificationGreaterThan | Valor inteiro que indica a idade em dias | A condição para ações em uma versão atual de um blob |
| daysAfterCreationGreaterThan | Valor inteiro que indica a idade em dias | A condição para ações na versão atual ou anterior de um blob ou um instantâneo de blob |
| daysAfterLastAccessTimeGreaterThan1 | Valor inteiro que indica a idade em dias | A condição para uma versão atual de um blob quando o controle de acesso está habilitado |
| daysAfterLastTierChangeGreaterThan | Valor inteiro que indica a idade em dias após o último horário de alteração da camada de blob | A duração mínima em dias em que um blob reidratado é mantido em camadas de acesso frequente, esporádico ou frio antes de ser retornado para a camada de arquivo morto. Essa condição se aplica apenas a ações tierToArchive. |
1 Se o rastreamento de hora do último acesso não estiver habilitado, o daysAfterLastAccessTimeGreaterThan usará a data em que a política de ciclo de vida foi habilitada em vez da propriedade LastAccessTime do blob. Essa data também é usada quando a propriedade LastAccessTime é um valor nulo. Para obter mais informações sobre como usar o rastreamento de hora do último acesso, confira Mover dados com base na hora do último acesso.
Execuções da política de ciclo de vida
Ao configurar ou editar uma política de ciclo de vida, pode levar até 24 horas para que as alterações entrem em vigor e a primeira execução seja iniciada. O tempo necessário para que as ações de política sejam concluídas depende do número de blobs avaliados e operados.
Se você desabilitar uma política, nenhuma nova execução de política será agendada, mas se uma execução já estiver em andamento, essa execução continuará até que ela seja concluída e você será cobrado por todas as ações necessárias para concluir a execução. Consulta a Disponibilidade regional e preços.
Evento de conclusão da política de ciclo de vida
O evento LifecyclePolicyCompleted é gerado quando as ações definidas por uma política de gerenciamento de ciclo de vida são executadas. Uma seção de resumo aparece para cada ação incluída na definição de política. O json a seguir mostra um exemplo de evento LifecyclePolicyCompleted para uma política. Como a definição de política inclui as ações delete, tierToCool, tierToCold e tierToArchive, uma seção de resumo aparece para cada uma delas.
{
"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"
}
A tabela a seguir descreve o esquema do evento LifecyclePolicyCompleted.
| Campo | Type | Descrição |
|---|---|---|
| scheduleTime | string | A hora em que a política de ciclo de vida foi agendada |
| deleteSummary | vector<byte> | O resumo dos resultados dos blobs agendados para a operação de exclusão |
| tierToCoolSummary | vector<byte> | O resumo dos resultados dos blobs agendados para a operação de camada para esporádico |
| tierToColdSummary | vector<byte> | Resumo dos resultados dos blobs programados para operação de camada para frio |
| tierToArchiveSummary | vector<byte> | O resumo dos resultados dos blobs agendados para a operação de camada para arquivar |
Exemplos de políticas de ciclo de vida
Os exemplos a seguir demonstram como tratar cenários comuns com as regras de política de ciclo de vida.
Mover dados antigos para uma camada mais fria
Este exemplo mostra como fazer a transição de blobs de blocos prefixados com sample-container/blob1 ou container2/blob2. A política faz a transição de blobs que não foram modificados há mais de 30 dias para o armazenamento esporádico e de blobs não modificados há mais de 90 dias para a camada de arquivos:
{
"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 }
}
}
}
}
]
}
Mover dados com base na data do último acesso
Você pode habilitar o acompanhamento de último acesso para manter um registro de quando o blob é lido ou gravado pela última vez e como um filtro para gerenciar a distribuição em camadas e a retenção de seus dados de blob. Para saber como habilitar o acompanhamento de último acesso, confira Opcionalmente, habilitar o acompanhamento de hora do último acesso.
Quando o acompanhamento da hora do último acesso é habilitado, a propriedade de blob chamada LastAccessTime é atualizada quando um blob é lido ou gravado. Uma operação Obter Blob é considerada uma operação de acesso. Obter Propriedades de Blob, Obter Metadados de Blobe Obter Marcas de Blob não são operações de acesso e, portanto, não atualizam a hora do último acesso.
Se o rastreamento de hora do último acesso estiver habilitado, o gerenciamento do ciclo de vida usará LastAccessTime para determinar se a condição de execução daysAfterLastAccessTimeGreaterThan é atendida. O gerenciamento do ciclo de vida usa a data em que a política de ciclo de vida foi habilitada em vez de LastAccessTime nos seguintes casos:
O valor da propriedade
LastAccessTimedo blob é um valor nulo.Observação
A propriedade
lastAccessedOndo blob será nula se um blob não tiver sido acessado desde que o rastreamento de hora do último acesso foi habilitado.O rastreamento de hora do último acesso não está habilitado.
Para minimizar o impacto na latência de acesso de leitura, somente a primeira leitura das últimas 24 horas atualiza o horário do último acesso. As leituras subsequentes no mesmo período de 24 horas não atualizam o horário do último acesso. Se um blob for modificado entre leituras, o horário do último acesso será o mais recente dos dois valores.
No exemplo a seguir, os blobs são movidos para a camada de armazenamento esporádico, caso não tenham sido acessados por 30 dias. A propriedade enableAutoTierToHotFromCool é um valor booliano que indica se um blob deve ser transferido automaticamente da camada de armazenamento esporádico para a camada de armazenamento frequente se ele for acessado novamente depois de ser transferido para a camada de armazenamento esporádico.
Dica
Se um blob for movido para a camada esporádica e, em seguida, for automaticamente movido de volta antes que 30 dias tenha decorrido, uma taxa de exclusão antecipada será cobrada. Antes de definir a enablAutoTierToHotFromCool propriedade, analise os padrões de acesso de seus dados para que você possa reduzir encargos inesperados.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Arquivar dados após a ingestão
Alguns dados permanecem ociosos na nuvem e raramente ou nunca são acessados depois de armazenados. A seguinte política de ciclo de vida é configurada para arquivar dados logo após a ingestão. Este exemplo faz a transição de blobs de blocos em um contêiner chamado archivecontainer para uma camada de arquivamento. A transição é realizada agindo sobre os blobs 0 dia após a hora da última modificação.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Observação
A Microsoft recomenda que você carregue seus blobs diretamente na camada de armazenamento de arquivos para maior eficiência. Você pode especificar a camada de arquivo no cabeçalho x-ms-access-tier na operação Colocar Blob ou Colocar Lista de Blobs. O cabeçalho x-ms-access-tier tem suporte em REST versão 2018-11-09 e mais recentes ou nossas bibliotecas de cliente de armazenamento de blob mais recentes.
Expirar os dados com base na idade
Espera-se que alguns dados expirem dias ou meses após a criação. Configure uma política de gerenciamento do ciclo de vida para expirar os dados por exclusão com base na idade deles. O seguinte exemplo mostra uma política que exclui todos os blobs de blocos que não foram modificados nos últimos 365 dias.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Exclui dados com marcas de índice de blob
Alguns dados só deverão expirar se explicitamente marcados para exclusão. Você pode configurar uma política de gerenciamento de ciclo de vida para expirar dados marcados com atributos de chave/valor de índice de blob. O exemplo a seguir mostra uma política que exclui todos os blobs de bloco marcados com Project = Contoso. Para saber mais sobre o índice de blobs, confira Gerenciar e localizar dados no Armazenamento de Blobs do Azure com o índice de blobs.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Gerenciar versões anteriores
Para dados modificados e acessados regularmente durante seu tempo de vida, você pode habilitar o controle de versão do armazenamento de blob para manter automaticamente as versões anteriores de um objeto. Você pode criar uma política para ser armazenada em camadas ou excluir versões anteriores. A idade da versão é determinada avaliando-se a hora de criação da versão. Essa regra da política move versões anteriores dentro do contêiner activedata com 90 dias ou mais após a criação da versão para a camada de armazenamento esporádico, além de exclui as versões anteriores que têm 365 dias ou mais.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Disponibilidade regional e preços
O recurso de gerenciamento do ciclo de vida está disponível em todas as regiões do Azure.
As políticas de gerenciamento do ciclo de vida são gratuitas. O custo de operação padrão para as chamadas à API Definir Camada de Blob é cobrado dos clientes. Operações de exclusão são gratuitas. No entanto, outros serviços e utilitários do Azure, como o Microsoft Defender para Armazenamento, podem cobrar por operações gerenciadas por meio de uma política de ciclo de vida.
Cada atualização para a hora de último acesso de um blob é cobrada na categoria outras operações. Cada última atualização de tempo de acesso será cobrada como uma "outra transação" no máximo uma vez a cada 24 horas por objeto, mesmo se for acessada muitas vezes em um dia. Isso será separado das cobranças de transações de leitura.
Para obter mais informações sobre preços, confira Preços do Blob de Blocos.
Limitações e problemas conhecidos
Ainda não há suporte para camadas em uma conta de armazenamento de blobs de blocos premium. Para todas as outras contas, a camada é permitida somente em blobs de blocos e não para blobs de acréscimo e de página.
Uma política de gerenciamento do ciclo de vida precisa ser lida ou gravada totalmente. Não há suporte para atualizações parciais.
Cada regra pode ter até 10 prefixos que diferenciam maiúsculas de minúsculas e até 10 condições de marca de índice de blob.
Uma política de gerenciamento de ciclo de vida não pode alterar a camada de um blob que usa um escopo de criptografia.
A ação de exclusão de uma política de gerenciamento de ciclo de vida não funcionará com nenhum blob em um contêiner imutável. Com uma política imutável, os objetos podem ser criados e lidos, mas não modificados nem excluídos. Para obter mais informações, consulte Armazenar dados de blob comercialmente críticos com armazenamento imutável.
Perguntas frequentes
Consulte Perguntas frequentes sobre o gerenciamento do ciclo de vida.