Otimize os custos gerenciando automaticamente o ciclo de vida dos 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. O gerenciamento do ciclo de vida do Armazenamento do Azure oferece uma política baseada em regras que você pode usar para fazer a transição dos seus dados de blob para as camadas de acesso apropriados e para expirar os dados no final do seu ciclo de vida.

Observação

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.

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. Nesse cenário, a política de gerenciamento do ciclo de vida pode mover objetos de frequente para esporádico, de frequente para arquivo ou de esporádico para arquivo.
  • 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.
  • Definir regras a serem executadas uma vez por dia no nível da conta de armazenamento.
  • Aplicar regras a contêineres ou um subconjunto de blobs, usando prefixos de nome ou marcas de índice de blob como filtros.

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.

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.

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.

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. Somente a exclusão tem suporte para appendBlob, não há suporte para a camada do conjunto. 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/... em uma regra, o prefixMatch é sample-container/blob1. Se você não definir prefixMatch, a regra se aplicará a todos os blobs na conta de armazenamento. 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
enableAutoTierToHotFromCool Suporte para blockBlob Sem suporte Sem suporte
tierToArchive Suporte para blockBlob Com suporte Com suporte
delete1 Com suporte para blockBlob e appendBlob Com suporte Com suporte

1 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 24 horas. 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 24 horas e assim por diante.

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 em uma versão anterior de um blob ou um instantâneo de blob
daysAfterLastAccessTimeGreaterThan 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 Essa condição se aplica apenas a ações tierToArchive e só pode ser usada com a condição daysAfterModificationGreaterThan.

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.

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.

{
  "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 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"
          ]
        }
      }
    }
  ]
}

Suporte a recursos

O suporte para esse recurso pode ser afetado ao habilitar o Data Lake Storage Gen2, o protocolo NFS (Sistema de Arquivos de Rede) 3.0 ou o protocolo SFTP (Protocolo de Transferência de Arquivo SSH).

Se você tiver habilitado qualquer um desses recursos, consulte o Suporte a recursos de Armazenamento de Blobs nas contas de Armazenamento do Azure para avaliar o suporte para esse recurso.

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.

Para obter mais informações sobre preços, confira Preços do Blob de Blocos.

Perguntas frequentes

Criei uma nova política. Por que as ações não são executadas imediatamente?

A plataforma executa a política de ciclo de vida uma vez por dia. Após configurar uma política, ela pode levar até 24 horas para entrar em vigor. Assim que a política entra em vigor, pode levar até 24 horas para algumas ações serem executadas pela primeira vez.

Se eu atualizar uma política existente, quanto tempo levará para as ações serem executadas?

A política atualizada leva até 24 horas para entrar em vigor. Quando a política está em vigor, pode levar até 24 horas para as ações serem executadas. Portanto, as ações da política podem levar até 48 horas para serem concluídas. Se a atualização for desabilitar ou excluir uma regra e enableAutoTierToHotFromCool tiver sido usado, a disposição automática em camadas para o estado frequente continuará ocorrendo. Por exemplo, definir uma regra incluindo enableAutoTierToHotFromCool com base no último acesso. Se a regra for desabilitada/excluída e um blob estiver atualmente em estado esporádico e for acessado, ele retornará para o estado frequente, pois essa regra se aplica ao acesso fora do gerenciamento do ciclo de vida. Nesse caso, o blob não passará de frequente para esporádico, visto que a regra de gerenciamento do ciclo de vida está desabilitada/foi excluída. A única maneira de impedir autoTierToHotFromCool é desativando o acompanhamento de último acesso.

Reidratei um blob arquivado. Como posso impedir que ele seja movido de volta para a camada de armazenamento de arquivos temporariamente?

Se houver uma política de gerenciamento do ciclo de vida em vigor para a conta de armazenamento, reidratar um blob mudando a camada dele poderá resultar em um cenário em que a política de ciclo de vida move o blob de volta para a camada de arquivos. Isso pode acontecer se a hora da última modificação, a hora de criação ou a hora do último acesso estiver além do limite definido para a política. Há três maneiras de evitar que isso aconteça:

  • Adicione a condição daysAfterLastTierChangeGreaterThan à ação tierToArchive da política. Essa condição se aplica somente à hora da última modificação. Confira Usar políticas de gerenciamento do ciclo de vida para arquivar blobs.

  • Desabilite a regra que afeta esse blob temporariamente para impedir que ele seja arquivado novamente. Habilite novamente a regra quando o blob puder ser movido com segurança de volta para a camada de armazenamento de arquivos.

  • Se o blob precisar permanecer permanentemente na camada quente ou fria, copie-o para outro local em que a política de gerenciamento do ciclo de vida não esteja em vigor.

A cadeia de caracteres de correspondência de prefixo do blob não aplicou a política aos blobs esperados

O campo de correspondência de prefixo blob de uma política é um caminho de blob completo ou parcial, que é usado para corresponder aos blobs nos quais você deseja que as ações de política sejam aplicadas. O caminho deve começar com o nome do contêiner. Se nenhuma correspondência de prefixo for especificada, a política será aplicada a todos os blobs na conta de armazenamento. O formato da cadeia de caracteres de correspondência de prefixo é [container name]/[blob name].

Tenha em mente os seguintes pontos sobre a cadeia de caracteres de correspondência de prefixo:

  • Uma cadeia de caracteres de correspondência de prefixo, como container1/ aplica-se a todos os blobs no contêiner chamado container1. Uma cadeia de caracteres de correspondência de prefixo de container1, sem o caractere de barra à direita (/), aplica-se a todos os blobs em todos os contêineres em que o nome do contêiner começa com o contêiner de cadeia de caracteres1. O prefixo corresponderá a contêineres chamados container11, container1234, container1ab e assim por diante.
  • Uma cadeia de caracteres de correspondência de prefixo de container1/sub1/ aplica-se a todos os blobs no contêiner nomeado container1 que começam com a cadeia de caracteres sub1/. Por exemplo, o prefixo corresponderá aos blobs nomeados como container1/sub1/test.txt ou container1/sub1/sub2/test.txt.
  • O caractere asterisco * é um caractere válido em um nome de blob. Se o caractere de asterisco for usado em um prefixo, o prefixo corresponderá a blobs com um asterisco em seus nomes. O asterisco não funciona como um caractere curinga.
  • O caractere de ponto de interrogação ? é um caractere válido em um nome de blob. Se o caractere de ponto de interrogação for usado em um prefixo, o prefixo corresponderá aos blobs com um ponto de interrogação em seus nomes. O ponto de interrogação não funciona como um caractere curinga.
  • A correspondência de prefixo considera apenas comparações lógicas positivas (=). Comparações lógicas negativas (!=) são ignoradas.

Há uma maneira de identificar o momento em que a política será executada?

Infelizmente, não há nenhuma maneira de acompanhar o momento em que a política será executada, pois é um processo de agendamento em segundo plano. No entanto, a plataforma executará a política uma vez por dia.

Próximas etapas