O que é o gerenciamento de ciclo de vida do OSS - Object Storage Service: Central de Documentação do Alibaba Cloud

A frequência de acesso a dados diminui ao longo do tempo. O gerenciamento de ciclo de vida permite criar regras que fazem a transição automática de objetos para classes de armazenamento de menor custo (como Infrequent Access ou Archive) ou os excluem após um período especificado, reduzindo custos de armazenamento sem intervenção manual.

Como funciona

O gerenciamento de ciclo de vida usa regras definidas pelo usuário para automatizar operações em objetos de um bucket. O OSS carrega uma nova regra em até 24 horas após a criação. Após o carregamento, o OSS executa as regras correspondentes em um horário fixo diariamente, normalmente após 00:00 (UTC) do dia seguinte (08:00 UTC+8).

Uma regra de ciclo de vida consiste em três partes principais:

Objetos a gerenciar: filtre os objetos de destino por prefixo de objeto (Prefix), tag de objeto (Tag) ou tamanho de objeto (ObjectSize).

As regras de ciclo de vida não oferecem suporte a caracteres curinga, correspondência por sufixo ou expressões regulares.
Ações a executar: defina o que fazer com os objetos filtrados:
- Transição de classe de armazenamento (Transition): faz a transição de objetos para classes de armazenamento de menor custo, como Infrequent Access, Archive ou Cold Archive.
- Expiração e exclusão (Expiration): exclui objetos após atingirem um período de ciclo de vida especificado.
- Limpeza de fragmentos (AbortMultipartUpload): exclui automaticamente partes de uploads multipart incompletos após um tempo especificado.
Políticas de acionamento: definem quando as ações são acionadas:
- Hora da última modificação (Last-Modified-Time): faz a transição ou exclui objetos com base na hora da última modificação. Adequado para dados com um ciclo de vida claro, como logs e backups.
- Hora do último acesso (Last-Access-Time): após ativar o rastreamento de acesso, faz a transição de objetos com base na hora do último acesso. Adequado para padrões de acesso imprevisíveis (como uma biblioteca de materiais). Dados frios são rebaixados automaticamente e restaurados quando acessados.

Todos os parâmetros configuráveis estão documentados em Elementos de configuração de ciclo de vida.

Cenários de configuração

Limpar arquivos de log expirados automaticamente

Os servidores fazem upload de logs diariamente em um diretório designado. Use uma regra baseada na hora da última modificação para excluir todos os objetos em um bucket após um número especificado de dias, liberando armazenamento e reduzindo custos.

Usar camadas de armazenamento automáticas para dados quentes e frios

Para dados com frequência de acesso incerta (imagens de sites, vídeos, documentos), ative o rastreamento de acesso e use uma regra de ciclo de vida baseada na hora do último acesso para implementar camadas de dados inteligentes. O sistema faz a transição de dados frios para classes de armazenamento de menor custo com base nos padrões de acesso reais.

Limpar versões anteriores automaticamente

Com o versionamento ativado, substituições e exclusões são salvas como versões anteriores. Quando um bucket acumula muitas versões anteriores ou marcadores de exclusão expirados, use uma regra de ciclo de vida baseada na hora da última modificação em conjunto com o versionamento para reduzir custos de armazenamento. Isso reduz custos e melhora o desempenho da listagem de objetos.

Limpar fragmentos de uploads multipart automaticamente

Uploads multipart interrompidos deixam partes não mescladas que continuam gerando cobranças. Configure uma regra de ciclo de vida para limpar partes incompletas após um tempo especificado.

Além dos cenários anteriores, você pode implementar políticas de gerenciamento de dados mais detalhadas. Para mais informações, consulte Exemplos de configuração de ciclo de vida. Combine diferentes regras para obter um gerenciamento detalhado dos dados no seu bucket conforme necessário.

Várias regras de ciclo de vida

Várias regras de ciclo de vida dependem de dois mecanismos: prioridade de execução de regras e o mecanismo de substituição de configuração.

Prioridade de execução de regras

Um bucket pode ter várias regras de ciclo de vida independentes. Quando um objeto corresponde a várias regras, a ação final é determinada por todos os resultados correspondentes.

Quando várias regras correspondem ao mesmo objeto ao mesmo tempo, elas são executadas na seguinte ordem de prioridade: Excluir objeto > Transição para Deep Cold Archive > Transição para Cold Archive > Transição para Archive > Transição para Infrequent Access > Transição para Standard.

null

A ação de exclusão sempre tem prioridade mais alta do que as transições de classe de armazenamento. Defina o tempo das regras de exclusão como maior que o tempo das regras de transição. Isso evita que objetos sejam excluídos antes que a transição seja concluída.

Exemplo de execução

Suponha que você especifique as duas regras de ciclo de vida a seguir e ambas correspondam ao mesmo objeto.

Regra 1: especifica que objetos com última modificação há mais de 365 dias são transferidos para a classe de armazenamento Infrequent Access.
Regra 2: especifica que objetos com última modificação há mais de 365 dias são excluídos.

Resultado: o objeto correspondente às regras será excluído após mais de 365 dias da hora da última modificação.

Mecanismo de substituição de configuração

O console lida com a mesclagem automaticamente, evitando substituição acidental. No entanto, ao usar ossutil, SDKs ou a API, cada chamada PutBucketLifecycle substitui completamente todas as configurações de ciclo de vida existentes. Enviar uma nova regra sem incluir as existentes exclui essas regras.

Exemplo

Para adicionar uma nova regra às regras existentes, execute as seguintes etapas:

Recupere todas as regras de ciclo de vida efetivas no momento (por exemplo, Regra 1).
Adicione a nova regra (por exemplo, Regra 2).
Reenvie a configuração completa que inclui todas as regras (Regra 1 + Regra 2).

Observação: se você enviar apenas a configuração contendo a nova regra (Regra 2) sem incluir a regra existente (Regra 1), a Regra 1 será excluída e não estará mais em vigor.

Implantação em produção

Para implantar o gerenciamento de ciclo de vida com segurança em produção:

Teste antes de implantar: crie regras em um bucket de teste primeiro. Verifique o comportamento antes de aplicá-las em produção.
Use regras de exclusão com cautela: defina o prefixo com precisão para evitar a exclusão acidental de dados importantes.
Ative o versionamento como proteção: para dados críticos, ative o versionamento para que objetos excluídos acidentalmente por uma regra de ciclo de vida possam ser recuperados de uma versão anterior.
Use transições em camadas para evitar taxas extras: verifique se o tempo de acionamento de cada estágio subsequente excede a soma do tempo de acionamento do estágio anterior e sua duração mínima de armazenamento. Isso evita taxas de transições prematuras.
- Exemplo incorreto: Standard 30 days -> Infrequent Access 40 days -> Archive Storage. O objeto permanece em IA por apenas 10 dias (< 30 days) antes de fazer a transição novamente, gerando uma taxa.
- Exemplo correto: Standard 30 days -> Infrequent Access 90 days -> Archive Storage. O objeto permanece em IA por 60 dias (atendendo ao mínimo de 30 dias) antes de fazer a transição para Archive no dia 90.

Faturamento

A configuração de regras de ciclo de vida é gratuita. As taxas são aplicadas quando as regras são executadas e alteram o estado de armazenamento.

Taxas de solicitação: cada transição de classe de armazenamento, exclusão de objeto ou exclusão de parte gera uma solicitação do tipo Put. As taxas são cobradas por solicitação. Os detalhes de faturamento estão em Descrição de taxas de ciclo de vida.

Para buckets com muitos arquivos pequenos, as taxas de solicitação podem ser significativas. Avalie antes de configurar regras.
Taxas de armazenamento: após a transição, os objetos são cobrados pela taxa da nova classe de armazenamento.

null
Classes de armazenamento como Infrequent Access, Archive e Cold Archive possuem requisitos de duração mínima de armazenamento (por exemplo, 30 dias para Infrequent Access e 60 dias para Archive). Se uma regra de ciclo de vida excluir ou fizer a transição de um objeto antes que a duração mínima de armazenamento seja atingida, você deverá pagar pela duração restante do armazenamento. Para evitar taxas de capacidade condicional para armazenamento inferior à duração especificada devido a transições ou exclusões, consulte Como evitar taxas de capacidade para armazenamento inferior à duração especificada?. Verifique se a duração mínima de armazenamento foi atingida antes de fazer a transição ou exclusão.
Taxas de recuperação de dados: as regras de ciclo de vida em si não geram taxas de recuperação de dados. No entanto, acessar objetos em classes de armazenamento como Infrequent Access ou Archive gera taxas de recuperação.
- A leitura direta de um objeto IA gera taxas de recuperação de dados.
- A leitura de um objeto Archive gera taxas de capacidade de recuperação de dados para acesso em tempo real.
- A restauração de um objeto Archive gera taxas de solicitação do tipo Put e taxas de capacidade de recuperação.
- A restauração de um objeto Cold Archive ou Deep Cold Archive gera taxas de solicitação de recuperação, taxas de capacidade de recuperação e taxas de capacidade restaurada temporária.
null
Para objetos Cold Archive e Deep Cold Archive, a taxa varia conforme a prioridade de recuperação escolhida. Uma prioridade mais alta resulta em uma taxa mais alta.

Perguntas frequentes

Qual é a diferença entre regras de ciclo de vida baseadas na hora da última modificação e na hora do último acesso?

As principais diferenças:

Política	Baseada na hora da última modificação	Baseada na hora do último acesso
Scenarios	Adequada para cenários de dados com padrões de acesso fixos ou previsíveis.	Adequada para cenários de dados com padrões de acesso variáveis ou imprevisíveis.
Supports Object Deletion	Compatível.	Não.
Object Recovery After Deletion	Se o versionamento não estiver ativado, objetos excluídos não poderão ser recuperados. Se o versionamento estiver ativado, quando uma regra de ciclo de vida excluir um objeto da versão atual, ele se tornará uma versão anterior e poderá ser recuperado. No entanto, quando uma regra de ciclo de vida excluir um objeto de versão anterior, ele não poderá ser recuperado.	Uma política baseada na hora do último acesso não envolve recuperação de objetos após exclusão.
Reversibility Of Storage Class Transition	Não reversível. Após a transição de um objeto de Standard para IA, ele não pode fazer a transição de volta automaticamente. Os detalhes estão em Transição de classe de armazenamento. A transição para IA, Archive, Cold Archive ou Deep Cold Archive envolve tamanho mínimo faturável, duração mínima de armazenamento e taxas de recuperação de dados. Os detalhes estão em Transição de classe de armazenamento.	Reversível. Quando um objeto é transferido automaticamente da classe de armazenamento Standard para a classe de armazenamento Infrequent Access, você também pode optar por retorná-lo à classe de armazenamento Standard quando ele for acessado. Importante Um objeto é considerado "acessado" somente quando é acessado por meio de uma chamada de API GetObject. Outras chamadas de API não são incluídas. Isso também envolve tamanho mínimo faturável, duração mínima de armazenamento e taxas de recuperação de dados. Os detalhes estão em Regras de ciclo de vida baseadas na hora do último acesso.

Por que minha regra de ciclo de vida não está funcionando?

Verifique os seguintes itens:

Tempo de ativação: a regra foi criada há mais de 24 horas? Novas regras precisam de tempo para serem carregadas.
Correspondência de prefixo: o prefixo na regra está definido corretamente? Por exemplo, uma pasta deve ser logs/ em vez de logs.
Condição de tempo: a hora da última modificação ou do último acesso do objeto realmente atende ao número de dias especificado?
Recurso de pré-requisito: se você estiver usando uma regra baseada na hora do último acesso, ativou o recurso de rastreamento de acesso para o bucket?

Após ativar o versionamento, excluí um objeto. Por que meu uso de armazenamento não diminuiu?

Com o versionamento ativado, uma operação de exclusão apenas cria um marcador de exclusão. O objeto original se torna uma versão anterior e continua ocupando espaço. Crie uma regra de ciclo de vida para limpar versões anteriores.

Os objetos convertidos serão restaurados se eu excluir a regra de ciclo de vida?

Não. A exclusão de uma regra não reverte ações já executadas. Restaure manualmente os objetos convertidos para sua classe de armazenamento original.

Por que um objeto excluído ainda ocupa espaço após a ativação do versionamento?

Com o versionamento ativado, uma operação de exclusão cria um marcador de exclusão. O objeto original se torna uma versão anterior e continua ocupando espaço. Configure uma regra para excluir versões anteriores.

O que devo fazer se receber o erro Set bucket lifecycle error, InvalidArgument, Days in the Transition action for StorageClass Archive must be more than the Transition action for StorageClass IA?

Esse erro ocorre porque os tempos de transição para diferentes classes de armazenamento não atendem aos requisitos. O período de transição configurado para o bucket deve satisfazer: Infrequent Access < Archive < Cold Archive < Deep Cold Archive.

O recurso de ciclo de vida do OSS pode executar ações de camadas de dados ou exclusão correspondendo a sufixos de arquivo?

As regras de ciclo de vida não oferecem suporte à correspondência por sufixo (como .png). Use as seguintes soluções alternativas:

Método 1: armazene objetos usando um prefixo específico

Armazene objetos com um sufixo específico (como .png arquivos) em um diretório dedicado com um prefixo como images/. Em seguida, configure uma regra de ciclo de vida correspondente ao prefixo images/.

Método 2: use tags de objeto

Adicione uma tag (como image:png) a todos os arquivos .png e configure a regra de ciclo de vida para corresponder por tag. Para mais informações, consulte Adicionar tags a objetos.

As regras de ciclo de vida se aplicam a objetos existentes em um bucket?

Uma regra de ciclo de vida se aplica a todos os objetos, incluindo aqueles enviados antes da configuração da regra. Por exemplo, se uma regra configurada em 7 de outubro exclui objetos após 30 dias, um objeto enviado em 5 de outubro é excluído em 6 de novembro e um objeto enviado em 8 de outubro é excluído em 9 de novembro.

Como modifico uma ou mais configurações de regra de ciclo de vida?

Suponha que seu bucket tenha duas regras de ciclo de vida (Rule1 e Rule2) e você queira modificar Rule1:

Chame GetBucketLifecycle para recuperar todas as regras de ciclo de vida atuais (Rule1 e Rule2).
Modifique o item de configuração da regra de ciclo de vida Rule1.
Chame PutBucketLifecycle para enviar as regras atualizadas (Rule1 + Rule2).

Existem registros de log para transições de tipo e exclusões por expiração realizadas por regras de ciclo de vida?

Sim. Todas as transições de tipo e exclusões por expiração realizadas com êxito por regras de ciclo de vida são registradas em log. Os campos de log são os seguintes:

Operation
- CommitTransition: faz a transição da classe de armazenamento.
- ExpireObject: exclui um objeto expirado.
Sync Request

lifecycle: as operações de transição e exclusão que foram acionadas.

Os campos de log do OSS estão documentados em Detalhes dos campos de log. O faturamento de consultas de log é abordado em Faturamento.

Posso criar uma única regra de ciclo de vida para limpar marcadores de exclusão de objetos e objetos da versão atual ao mesmo tempo?

Não. Você deve criar uma regra para limpar marcadores de exclusão de objetos e outra regra para excluir objetos da versão atual.

Como limpar rapidamente todos os arquivos em um bucket usando regras de ciclo de vida

Bucket com versionamento desativado

Para um bucket com versionamento desativado, você precisa configurar apenas uma regra de ciclo de vida para limpar automática e rapidamente todos os arquivos e partes de uploads multipart incompletos.

Faça logon no console do OSS, acesse a página Bucket List e encontre o bucket de destino.
No painel de navegação à esquerda, escolha Data Security > Versioning e confirme que o versionamento está desativado para o bucket.
No painel de navegação à esquerda, escolha Data Management > Lifecycle. Defina uma regra de ciclo de vida para excluir automaticamente todos os arquivos no bucket 1 dia após a última modificação. Além disso, limpe automaticamente partes de uploads multipart incompletos criados há mais de 1 dia.

Bucket com versionamento ativado

Após o versionamento ser ativado para um bucket, ele gera objetos da versão atual, objetos de versões anteriores, partes de uploads multipart incompletos e marcadores de exclusão. Você precisa configurar apenas uma regra de ciclo de vida para limpar automática e rapidamente todos eles.

Faça logon no console do OSS, acesse a página Bucket List e encontre o bucket de destino.
No painel de navegação à esquerda, escolha Data Security > Versioning e confirme que o versionamento está ativado para o bucket.
No painel de navegação à esquerda, escolha Data Management > Lifecycle. Defina uma regra de ciclo de vida para excluir automaticamente todos os objetos das versões atual e anteriores no bucket 1 dia após a última modificação. Além disso, limpe automaticamente partes de uploads multipart incompletos criados há mais de 1 dia. Essa regra também limpa marcadores de exclusão.

Se eu criar duas regras de ciclo de vida para objetos com o mesmo prefixo, uma baseada na hora da última modificação e outra baseada na hora do último acesso, qual regra é aplicada?

Por exemplo, você cria duas regras de ciclo de vida para o bucket de destino `examplebucket`. A Regra 1 especifica que todos os objetos com o prefixo `doc` no bucket são excluídos 30 dias após a hora da última modificação. A Regra 2 especifica que todos os objetos com o prefixo `doc` no bucket são transferidos para a classe de armazenamento Infrequent Access 30 dias após a hora do último acesso.

O OSS executa regras de ciclo de vida com base no princípio de minimizar custos para o usuário. Portanto, somente a Regra 1 entra em vigor. Isso ocorre porque a Regra 1 exclui os objetos após 30 dias, interrompendo todas as taxas. Em contraste, a Regra 2, que faz a transição de objetos para a classe de armazenamento Infrequent Access, ainda geraria taxas de armazenamento ou recuperação de dados.

Quando uma alteração em uma regra de ciclo de vida configurada entra em vigor e como os dados correspondidos pela regra original são tratados?

Por exemplo, você configura uma regra de ciclo de vida para objetos com o prefixo er. Essa regra faz a transição dos objetos para a classe de armazenamento Infrequent Access 30 dias após a hora do último acesso e, em seguida, os transfere de volta para a classe de armazenamento Standard se forem acessados novamente após mais 30 dias. No entanto, 35 dias após a hora do último acesso de um objeto, você altera o prefixo na regra de ciclo de vida de er para re. Como resultado, o objeto é transferido para a classe de armazenamento Infrequent Access, mas a ação de transferi-lo de volta para a classe de armazenamento Standard não entra em vigor. Para objetos que correspondem à regra atualizada, a hora do último acesso é calculada a partir do momento em que o rastreamento de acesso foi ativado para o bucket.

Em um bucket com versionamento ativado, como as camadas inteligentes afetam as classes de armazenamento de diferentes versões de objeto?

Em um bucket com versionamento ativado, cada versão de objeto possui um ID de versão exclusivo e é tratada como um objeto independente. Portanto, uma versão anterior de um objeto pode estar na classe de armazenamento Infrequent Access, enquanto a versão atual do mesmo objeto está na classe de armazenamento Standard.