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 você pode usar para fazer a transição de dados de blob para as camadas de acesso apropriadas ou para expirar dados no final do ciclo de vida dos dados.
Com a política de gerenciamento do ciclo de vida, você pode:
- Transfira os blobs de frio para quente imediatamente quando forem acessados, para 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 fria, se esses objetos não tiverem sido acessados ou modificados por um período de tempo, para otimizar o custo.
- Exclua 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 tags de índice de blob como filtros.
Gorjeta
Embora o gerenciamento do ciclo de vida ajude a mover dados entre níveis em uma única conta, você pode usar uma tarefa de armazenamento para realizar essa tarefa em escala em várias contas. Uma tarefa de armazenamento é um recurso disponível nas 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 gestão do ciclo de vida são suportadas para blobs de blocos e blobs de acréscimo nas contas fins gerais v2, blob de blocos premium e de Armazenamento de Blobs. O gerenciamento do ciclo de vida não afeta os contêineres do sistema, como os contêineres ou $logs $web .
Importante
Se um conjunto de dados precisar ser legível, não defina uma política para mover blobs para a camada de arquivamento. Os blobs na camada de arquivo não podem ser lidos a menos que sejam primeiro reidratados, um processo que pode ser demorado e caro. Para obter mais informações, consulte Visão geral da reidratação de blob da camada de arquivamento. Se um conjunto de dados precisar ser lido com frequência, não defina uma política para mover blobs para as camadas fria ou fria, pois isso pode resultar em custos de transação mais altos.
Otimizando custos gerenciando o ciclo de vida dos dados
Os conjuntos de dados têm ciclos de vida exclusivos. No início do ciclo de vida, as pessoas acessam alguns dados com frequência. Mas a necessidade de acesso muitas vezes diminui drasticamente à medida que os dados envelhecem. Alguns dados permanecem ociosos na nuvem e raramente são acessados uma vez armazenados. Alguns conjuntos de dados expiram dias ou meses após a criação, enquanto outros conjuntos de dados são ativamente lidos e modificados ao longo de suas vidas.
Considere um cenário em que os dados são acessados com frequência durante os estágios iniciais do ciclo de vida, mas apenas ocasionalmente após duas semanas. Além do primeiro mês, o conjunto de dados raramente é acessado. Nesse cenário, o armazenamento a quente é melhor durante os estágios iniciais. O armazenamento refrigerado é mais apropriado para acessos ocasionais. O armazenamento de arquivo morto é a melhor opção de nível depois que os dados envelhecem mais de um mês. Ao mover os dados para o nível de armazenamento apropriado com base em sua idade com regras de política de gerenciamento de ciclo de vida, você pode projetar a solução menos dispendiosa para suas necessidades.
Definição da política de gestão do ciclo de vida
Uma política de gerenciamento do ciclo de vida é uma coleção de regras em um documento JSON. O JSON de exemplo a seguir 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 tabela a seguir:
| Nome do parâmetro | Tipo de parâmetro | Notas |
|---|---|---|
rules |
Uma matriz de objetos de regra | Pelo menos uma regra é necessária em uma política. Pode definir até 100 regras numa política. |
Cada regra dentro da política tem vários parâmetros, descritos na tabela a seguir:
| Nome do parâmetro | Tipo de parâmetro | Notas | Necessário |
|---|---|---|---|
name |
String | Um nome de regra pode incluir até 256 caracteres alfanuméricos. O nome da regra diferencia maiúsculas de minúsculas. Tem de ser único dentro de uma política. | True |
enabled |
Boolean | Um booleano opcional para permitir que uma regra seja temporariamente desativada. O valor padrão será true se não estiver definido. | False |
type |
Um valor de enum | O tipo válido atual é Lifecycle. |
True |
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. | True |
Definição de regras 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 da regra a um determinado conjunto de objetos dentro de um contêiner ou nomes de objetos. O conjunto de ações aplica as ações de camada ou exclusão ao 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 sample-container e começam com blob1.
- Blob de nível para nível de resfriamento 30 dias após a última modificação
- Blob de camada para arquivar camada 90 dias após a última modificação
- Excluir 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"
]
}
}
}
]
}
Nota
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 regras
Os filtros limitam as ações da regra a um subconjunto de blobs na conta de armazenamento. Se mais de um filtro for definido, uma lógica AND será executada em todos os filtros. Você pode usar um filtro para especificar quais blobs incluir. Um filtro não fornece meios para especificar quais blobs devem ser excluídos.
Os filtros incluem:
| Nome do filtro | Tipo de filtro | Notas | É Necessário |
|---|---|---|---|
| blobTipos | Uma matriz de valores de enum predefinidos. | A versão atual suporta blockBlob e appendBlob. Somente a ação Excluir é suportada para appendBlob; Definir camada não é suportado. |
Sim |
| prefixMatch | Uma matriz de cadeias de caracteres para prefixos a serem correspondidos. Cada regra pode definir até 10 prefixos que diferenciam maiúsculas de minúsculas. Uma cadeia de prefixo tem de começar com um nome de contentor. Por exemplo, se você quiser corresponder a todos os blobs em https://myaccount.blob.core.windows.net/sample-container/blob1/..., especifique o prefixMatch como sample-container/blob1. Este filtro corresponderá a todos os blobs no recipiente de amostra 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 suportam correspondência curinga. Caracteres como * e ? são tratados como literais de cadeia de caracteres. |
Não |
| blobIndexMatch | Uma matriz de valores de dicionário que consiste em blob, indexação, marca, chave e condições de valor a serem correspondidas. Cada regra pode definir até 10 condições de etiquetas de índice de blobs. Por exemplo, se você quiser corresponder todos os blobs com Project = Contoso under 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 dentro da conta de armazenamento. | Não |
Para saber mais sobre o recurso de índice de blob juntamente com problemas e limitações conhecidos, consulte Gerenciar e localizar dados no Armazenamento de Blob do Azure com índice de blob.
Ações de regra
As ações são aplicadas aos blobs filtrados quando a condição de execução é cumprida.
O gerenciamento do ciclo de vida oferece suporte à hierarquização e exclusão de versões atuais, versões anteriores e instantâneos de blob. Defina pelo menos uma ação para cada regra.
Nota
A hierarquização ainda não é suportada em uma conta de armazenamento de blob de bloco premium. Para todas as outras contas, a hierarquização é permitida apenas em blobs de bloco e não para blobs de acréscimo e página.
| Ação | Versão Atual | Instantâneo | Versões anteriores |
|---|---|---|---|
| tierToCool | Suportado para blockBlob |
Suportado | Suportado |
| tierToCold | Suportado para blockBlob |
Suportado | Suportado |
| habilitarAutoTierToHotFromCool1 | Suportado para blockBlob |
Não suportado | Não suportado |
| tierToArchive4 | Suportado para blockBlob |
Suportado | Suportado |
| suprimir2,3 | Suportado para blockBlob e appendBlob |
Suportado | Suportado |
1 A enableAutoTierToHotFromCool ação só está disponível quando usada com a daysAfterLastAccessTimeGreaterThan condição de execução. Essa condição é descrita na tabela seguinte.
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á os objetos que atendem às condições da 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 quaisquer 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 anteriores e instantâneos ao especificar uma ação de exclusão como parte da política.
4 Apenas as contas de armazenamento configuradas para LRS, GRS ou RA-GRS suportam a movimentação de blobs para a camada de arquivamento. A camada de arquivamento não é suportada para contas ZRS, GZRS ou RA-GZRS. Esta ação é listada com base na redundância configurada para a conta.
Nota
Se você definir mais de uma ação no mesmo blob, o gerenciamento do ciclo de vida aplicará a ação menos dispendiosa 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 a hora da última modificação ou a hora do último acesso, as versões anteriores usam o tempo de criação da versão e os instantâneos de blob usam o tempo de criação do instantâneo para controlar a idade.
| Condição de execução da ação | Valor da condição | Description |
|---|---|---|
| diasDepoisModificaçãoMaiordo que | Valor inteiro que indica a idade em dias | A condição para ações em uma versão atual de um blob |
| diasDepoisCriaçãoMaior do que | Valor inteiro que indica a idade em dias | A condição para ações na versão atual ou na versão anterior de um blob ou de um instantâneo de blob |
| diasDepoisÚltimoAcessoTempoMaior que1 | Valor inteiro que indica a idade em dias | A condição para uma versão atual de um blob quando o rastreamento de acesso está habilitado |
| diasDepoisÚltimoTierChangeGreaterThan | Valor inteiro que indica a idade em dias após o último tempo de alteração da camada de blob | A duração mínima em dias em que um blob reidratado é mantido em níveis quentes, frios ou frios antes de ser devolvido ao nível de arquivamento. Esta condição aplica-se apenas a tierToArchive ações. |
1 Se o controle do tempo do último acesso não estiver habilitado, daysAfterLastAccessTimeGreaterThan usará a data em que a política de ciclo de vida foi habilitada em vez da LastAccessTime propriedade do blob. Essa data também é usada quando a LastAccessTime propriedade é um valor nulo. Para obter mais informações sobre como usar o controle do tempo do último acesso, consulte Mover dados com base na hora do último acesso.
A política de ciclo de vida é executada
Quando você configura ou edita uma política de ciclo de vida, pode levar até 24 horas para que as alterações entrem em vigor e para que a primeira execução seja iniciada. O tempo necessário para a conclusão das ações de política 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é ser concluída e você será cobrado por todas as ações necessárias para concluir a execução. Consulte Disponibilidade regional e preços.
Evento concluído da política de ciclo de vida
O evento LifecyclePolicyCompleted é gerado quando as ações definidas por uma política de gestão do ciclo de vida são executadas. Uma seção de resumo é exibida para cada ação incluída na definição de política. O json a seguir mostra um evento de exemplo LifecyclePolicyCompleted para uma política. Como a definição de política inclui o delete, tierToCool, tierToColde tierToArchive ações, uma seção de resumo é exibida 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 LifecyclePolicyCompleted esquema do evento.
| Campo | Tipo | Description |
|---|---|---|
| horárioHora | string | A hora em que a política de ciclo de vida foi agendada |
| excluirResumo | <byte vetorial> | O resumo dos resultados dos blobs agendados para a operação de exclusão |
| tierToCoolSummary | <byte vetorial> | O resumo dos resultados dos blobs agendados para operação tier-to-cool |
| tierToColdSummary | <byte vetorial> | O resumo dos resultados dos blobs agendados para operação de camada a frio |
| tierToArchiveSummary | <byte vetorial> | O resumo dos resultados dos blobs agendados para a operação de camada para arquivamento |
Exemplos de políticas de ciclo de vida
Os exemplos a seguir demonstram como abordar cenários comuns com 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 bloco prefixados com sample-container/blob1 ou container2/blob2. A política faz a transição de blobs que não foram modificados em mais de 30 dias para resfriamento do armazenamento e blobs não modificados em 90 dias para a camada de arquivamento:
{
"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 no último acesso
Você pode habilitar o controle do tempo do último acesso para manter um registro de quando seu blob é lido ou gravado pela última vez e como um filtro para gerenciar a hierarquização e a retenção de seus dados de blob. Para saber como habilitar o rastreamento do tempo do último acesso, consulte Habilitar opcionalmente o rastreamento do tempo de acesso.
Quando o controle da hora do último acesso está habilitado, a propriedade blob chamada LastAccessTime é atualizada quando um blob é lido ou gravado. Uma operação Get Blob é considerada uma operação de acesso. Obter Propriedades de Blob, Obter Metadados de Blob e Obter Tags de Blob não são operações de acesso e, portanto, não atualizam a última hora de acesso.
Se o controle do tempo do último acesso estiver habilitado, o gerenciamento do ciclo de vida será usado LastAccessTime para determinar se a condição de execução daysAfterLastAccessTimeGreaterThan será atendida. O gerenciamento do ciclo de vida usa a data em que a política de ciclo de vida foi habilitada em vez dos LastAccessTime seguintes casos:
O valor da
LastAccessTimepropriedade do blob é um valor nulo.Nota
A
lastAccessedOnpropriedade do blob será nula se um blob não tiver sido acessado desde que o rastreamento do último tempo de acesso foi habilitado.O rastreamento do tempo do último acesso não está habilitado.
Para minimizar o efeito na latência de acesso de leitura, apenas a primeira leitura das últimas 24 horas atualiza a última hora de acesso. As leituras subsequentes no mesmo período de 24 horas não atualizam a última hora de acesso. Se um blob for modificado entre leituras, o último tempo de acesso será o mais recente dos dois valores.
No exemplo a seguir, os blobs são movidos para armazenamento refrigerado se não tiverem sido acessados por 30 dias. A enableAutoTierToHotFromCool propriedade é um valor booleano que indica se um blob deve ser automaticamente hierarquizado de cool back para hot se for acessado novamente depois de ser hierarquizado para cool.
Gorjeta
Se um blob for movido para o nível legal e, em seguida, for automaticamente movido de volta antes de 30 dias terem decorrido, uma taxa de exclusão antecipada será cobrada. Antes de definir a enablAutoTierToHotFromCool propriedade, certifique-se de analisar os padrões de acesso dos seus dados para reduzir cobranças inesperadas.
{
"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 ficam ociosos na nuvem e raramente ou nunca são acessados. A política de ciclo de vida a seguir é configurada para arquivar dados logo após sua ingestão. Este exemplo faz a transição de blobs de bloco em um contêiner nomeado archivecontainer para uma camada de arquivamento. A transição é realizada agindo em blobs 0 dias após o tempo da última modificação.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Nota
A Microsoft recomenda que você carregue seus blobs diretamente para a camada de arquivamento para maior eficiência. Você pode especificar a camada de arquivo no cabeçalho x-ms-access-tier na operação Put Blob ou Put Block List . O cabeçalho x-ms-access-tier é suportado com a versão REST 2018-11-09 e mais recente ou com as bibliotecas de cliente de armazenamento de blob mais recentes.
Dados de expiração com base na idade
Espera-se que alguns dados expirem dias ou meses após a criação. Você pode configurar uma política de gerenciamento de ciclo de vida para expirar dados por exclusão com base na idade dos dados. O exemplo a seguir mostra uma política que exclui todos os blobs de bloco 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 }
}
}
}
}
]
}
Excluir dados com tags de índice de blob
Alguns dados só devem expirar se estiverem explicitamente marcados para eliminação. Você pode configurar uma política de gerenciamento de ciclo de vida para expirar dados marcados com atributos 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 blob, consulte Gerenciar e localizar dados no Armazenamento de Blobs do Azure com índice de blob.
{
"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 que são modificados e acessados regularmente durante toda a sua vida útil, você pode habilitar o controle de versão de armazenamento de blob para manter automaticamente as versões anteriores de um objeto. Você pode criar uma política para hierarquizar ou excluir versões anteriores. A idade da versão é determinada pela avaliação do tempo de criação da versão. Esta regra de política move versões anteriores dentro do contêiner activedata que são 90 dias ou mais após a criação da versão para a camada legal e exclui versões anteriores com 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 gestão do ciclo de vida são gratuitas. Os clientes são cobrados pelos custos de operação padrão para as chamadas de API set Blob Tier . As operações de eliminação são gratuitas. No entanto, outros serviços e utilitários do Azure, como o Microsoft Defender for Storage , podem cobrar por operações gerenciadas por meio de uma política de ciclo de vida.
Cada atualização para a última hora de acesso de um blob é cobrada na categoria de outras operações . Cada última atualização de tempo de acesso é cobrada como uma "outra transação" no máximo uma vez a cada 24 horas por objeto, mesmo que seja acessada 1000 vezes em um dia. Isso é separado dos encargos de transações de leitura.
Para obter mais informações sobre preços, veja os preços do Blob de Blocos.
Problemas e limitações conhecidos
A hierarquização ainda não é suportada em uma conta de armazenamento de blob de bloco premium. Para todas as outras contas, a hierarquização é permitida apenas em blobs de bloco e não para blobs de acréscimo e página.
Uma política de gerenciamento do ciclo de vida deve ser lida ou escrita na íntegra. 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 tag 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 do 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 ou excluídos. Para obter mais informações, consulte Armazenar dados de blob críticos para os negócios com armazenamento imutável.
Perguntas mais frequentes (FAQ)
Consulte Perguntas frequentes sobre gerenciamento do ciclo de vida.