Partilhar via

Estrutura da política de gerenciamento do ciclo de vida do Armazenamento de Blobs do Azure

Você pode usar políticas de gerenciamento de ciclo de vida para fazer a transição de blobs para camadas de acesso econômicas com base em seus padrões de uso. Você também pode excluir blobs completamente quando chegarem ao fim do seu ciclo de vida. Uma política pode operar em versões atuais, versões anteriores e instantâneos de dados, mas não opera em blobs em contentores do sistema, como os contentores $logs ou $web. Para obter informações gerais, consulte Visão geral do gerenciamento do ciclo de vida do Armazenamento de Blobs do Azure.

Este artigo descreve os elementos de uma política de gerenciamento do ciclo de vida. Para obter exemplos de políticas, consulte os seguintes artigos:

Sugestão

Embora o gerenciamento do ciclo de vida ajude a otimizar seus custos para uma única conta, você pode usar as Ações de Armazenamento do Azure para realizar várias operações de dados em escala em várias contas.

Regras

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": {...}
    }
  ]
}
Nome do parâmetro Tipo de parâmetro Observações
regras Uma matriz de objetos de normas 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 Observações Obrigatório
Nome Cordão 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. Sim
ativado booleano Um booleano opcional para permitir que uma regra seja temporariamente desativada. O valor padrão é true. Não
tipo Um valor de enum O tipo válido atual é Lifecycle. Sim
Definição 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. Sim

Filtros

Os filtros limitam as ações a um subconjunto de blobs na conta de armazenamento. Você pode usar um filtro para especificar quais blobs incluir. Um filtro não fornece meios para especificar quais blobs devem ser excluídos. Se mais de um filtro for definido, será aplicada uma operação lógica AND a todos os filtros. A tabela a seguir descreve cada parâmetro.

Nome do filtro Tipo Descrição Obrigatório
Tipos de Blob Matriz de valores de enum predefinidos O tipo de blob (blockblob ou appendBlob) Sim
prefixMatch Matriz de cadeias de caracteres Essas cadeias de caracteres são prefixos que devem ser correspondidos. Não
blobIndexMatch Uma matriz de valores de dicionário Esses valores consistem em condições de chave e valor do índice de blob que devem corresponder. Não

Filtro de correspondência de prefixo

Ao aplicar o filtro prefixMatch, cada regra pode definir até 10 prefixos sensíveis a maiúsculas e 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 sob o caminho https://myaccount.blob.core.windows.net/sample-container/blob1/..., especifique o prefixMatch como sample-container/blob1.

Esse filtro corresponderá a todos os blobs em sample-container que os nomes começam com blob1. Se você não definir uma correspondência de prefixo, a regra se aplicará a todos os blobs na conta de armazenamento. As cadeias de caracteres de prefixo não suportam correspondência de caracteres universais. Caracteres como * e ? são tratados como literais de cadeia de caracteres.

Filtro de correspondência de índice Blob

Se você aplicar o filtro blobIndexMatch, cada regra poderá definir até 10 condições de etiqueta de índice de blob. Por exemplo, se tu quiseres combinar todos os blobs com Project = Contoso em https://myaccount.blob.core.windows.net/, o filtro blobIndexMatch será {"name": "Project","op": "==","value": "Contoso"}. Se você não definir um valor para o filtro blobIndexMatch , a regra se aplicará a todos os blobs na conta de armazenamento.

Ações

Você deve definir pelo menos uma ação para cada regra. As ações são aplicadas aos blobs filtrados quando a condição de execução é cumprida. Para saber mais sobre as condições de execução, consulte a seção Condições de execução de ação deste artigo. A tabela a seguir descreve cada ação disponível em uma definição de política.

Ação Descrição
TierToCool Defina um blob para a camada de acesso esporádico.

Não é suportado com blobs de anexo, blobs de páginas ou com blobs em uma conta de armazenamento de blobs de blocos premium.
TierToCold Defina um blob para a camada de acesso frio.

Não é suportado com blobs de anexo, blobs de páginas ou com blobs em uma conta de armazenamento de blobs de blocos premium.
TierToArchive Defina um blob para a camada de acesso ao arquivo.

A reidratação de um blob não atualiza a propriedade da última modificação ou da última hora de acesso do blob. Como resultado, esta ação pode mover blobs reidratados de volta para o nível de arquivo. Para evitar que isso aconteça, adicione a daysAfterLastTierChangeGreaterThan condição a esta ação.

Esta ação não é suportada com blobs de adição, blobs de página ou com blobs numa conta de armazenamento de blob de bloco premium. Também não é suportado com blobs que usam um escopo de criptografia ou com blobs em contas configuradas para armazenamento com redundância de zona (ZRS), armazenamento com redundância de zona geográfica (GZRS) / armazenamento com redundância de zona geográfica de acesso de leitura (RA-GZRS).
habilitarAutoTierToHotFromCool Se um blob estiver definido para a camada cool, essa ação moverá automaticamente esse blob para a camada hot quando o blob for acessado.

Essa ação está disponível somente quando usada com a condição de execução daysAfterLastAccessTimeGreaterThan .

Essa ação não tem efeito sobre blobs que foram definidos para a camada fresca antes de habilitar esta ação em uma regra.

Esta ação move as bolhas de frio para quente apenas uma vez em 30 dias. Esta salvaguarda é implementada para proteger contra várias penalidades de exclusão antecipada cobradas da conta.

Não suportado em versões anteriores ou snapshots.
Eliminar Exclui um blob.

Não é compatível com blocos de página ou blocos em um contentor imutável.

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, uma ação de exclusão é mais barata do que a ação tierToArchive e a ação tierToArchive é mais barata do que a ação tierToCool .

Excluir ação em contas que têm um namespace hierárquico

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.

Excluir ação em blobs que tenham versões e instantâneos

Uma política de gerenciamento de 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.

Condições de execução da ação

Todas as condições de execução são baseadas no tempo. Se o número de dias que passaram ultrapassar o número especificado para a condição, a ação associada poderá ser executada. As condições da política são avaliadas em cada objeto apenas uma vez durante a execução de uma política. Em alguns casos, um objeto pode atender à condição depois de já ter sido avaliado por uma corrida. Tais objetos são processados em execuções subsequentes.

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.

A tabela a seguir descreve cada condição de execução de ação.

Nome da condição Tipo Descrição
diasDepoisModificaçãoMaiordo que Número inteiro A idade em dias após a última bolha de tempo modificada. Aplica-se a ações em uma versão atual de um blob.
diasDepoisCriaçãoMaior do que Número inteiro A idade em dias após o momento da criação. Aplica-se a ações na versão atual de um blob, na versão anterior de um blob ou num instantâneo de blob.
diasApósÚltimoTempoDeAcessoMaiorQue Número inteiro A idade em dias após a última data de acesso ou, em alguns casos, quando a política foi ativada. Para saber mais, consulte a seção Rastreamento de tempo de acesso abaixo. Aplica-se a ações na versão atual de um blob quando o rastreamento de acesso está habilitado.
diasDepoisDoÚltimoTierChangeMaiorQue Número inteiro A idade em dias desde a última alteração do nível do blob. A duração mínima em dias em que um blob reidratado é mantido em níveis quentes, mornos ou frios antes de ser devolvido ao nível de arquivamento. Aplica-se somente a ações tierToArchive .

Rastreamento de tempo de acesso

Você pode habilitar o controle de tempo de acesso para manter um registro de quando seu blob foi lido ou gravado pela última vez e como um filtro para gerenciar a hierarquização e a retenção de seus dados de blob.

Quando você habilita o controle de tempo de acesso, uma propriedade de blob chamada LastAccessTime é atualizada quando um blob é lido ou gravado. As operações Get Blob e Put Blob são operações de acesso e atualizarão o tempo de acesso de um blob. No entanto, as operações Obter Propriedades de Blob, Obter Metadados de Blob e Obter Tags de Blob não são operações de acesso. Essas operações não atualizarão o tempo de acesso de um blob.

Se aplicar a condição daysAfterLastAccessTimeGreaterThan a uma política, a condição LastAccessTime será usada para determinar se essa condição foi atendida.

Se você aplicar a condição daysAfterLastAccessTimeGreaterThan a uma política, mas não tiver habilitado a monitorização do tempo de acesso, a LastAccessTime não será usada. Em vez disso, é usada a data em que o último rastreamento de acesso foi habilitado. Na verdade, a data em que o último rastreamento de acesso foi habilitado é usada em qualquer situação em que a LastAccessTime propriedade do blob é um valor nulo. Isso pode acontecer mesmo se você tiver ativado o rastreamento de tempo de acesso nos casos em que um blob não foi acessado desde que o rastreamento foi habilitado.

Observação

Para minimizar o efeito na latência de leitura, apenas a primeira leitura das últimas 24 horas atualiza a hora do último 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.

Para saber como habilitar o rastreamento de tempo de acesso, consulte Opcionalmente habilitar o rastreamento de tempo de acesso.

Próximos passos

  • Last updated on