Gestão do ciclo de vida de objetos

Configure a gestão do ciclo de vida de objetos Exemplos de configuração

Para suportar exemplos de utilização comuns, como definir um tempo de vida (TTL) para objetos, reter versões não atuais de objetos ou "reduzir" as classes de armazenamento de objetos para ajudar a gerir os custos, o Cloud Storage oferece a funcionalidade de gestão do ciclo de vida de objetos.

Esta página descreve a funcionalidade, bem como as opções disponíveis quando a usa. Para o formato geral de um ficheiro de configuração do ciclo de vida, consulte a representação do recurso de contentor para JSON ou o formato de configuração do ciclo de vida para XML.

Introdução

Para usar a gestão do ciclo de vida de objetos, define uma configuração do ciclo de vida, que tem de ser definida num contentor. A configuração contém um conjunto de regras que se aplicam a objetos atuais e futuros no contentor. Quando um objeto cumpre os critérios de uma das regras, o Cloud Storage executa automaticamente uma ação especificada no objeto. Seguem-se alguns exemplos de utilização:

  • Reduza a classe de armazenamento de objetos com antiguidade superior a 365 dias para o armazenamento Coldline.
  • Elimine objetos criados antes de 1 de janeiro de 2019.
  • Mantenha apenas as 3 versões mais recentes de cada objeto num contentor com a gestão de versões ativada.

Configuração do ciclo de vida

Cada configuração de gestão do ciclo de vida contém um conjunto de regras. Cada regra contém uma ação e uma ou mais condições.

  • Um objeto tem de corresponder a todas as condições especificadas numa regra para que a ação na regra seja realizada.

  • Se especificar várias regras que contenham a mesma ação, a ação é executada num objeto quando esse objeto corresponder às condições em qualquer uma das regras.

  • Se várias regras tiverem as respetivas condições satisfeitas em simultâneo para um único objeto, o Cloud Storage executa a ação associada apenas a uma das regras, com base nas seguintes considerações:

    • A ação Delete tem precedência sobre qualquer ação SetStorageClass.
    • A ação SetStorageClass que muda o objeto para a classe de armazenamento com o preço de armazenamento em repouso mais baixo tem precedência.

    Por exemplo, se tiver uma regra que altere a classe do objeto para armazenamento Nearline e outra regra que altere a classe do objeto para armazenamento Coldline, mas ambas as regras usarem exatamente a mesma condição, a classe do objeto é sempre alterada para armazenamento Coldline quando a condição é cumprida.

  • Deve testar as regras do ciclo de vida em dados de desenvolvimento antes de as aplicar à produção para garantir que as regras não realizam ações em conjuntos de condições não pretendidos. Se isso não for possível, deve testar num pequeno subconjunto dos seus dados de produção usando as condições matchesPrefix ou matchesSuffix nas suas regras.

  • As alterações à configuração do ciclo de vida de um contentor podem demorar até 24 horas a entrar em vigor, e a gestão do ciclo de vida dos objetos pode continuar a realizar ações com base na configuração antiga durante este período.

    Por exemplo, se alterar uma condição de age10 dias para 20 dias, um objeto com 11 dias pode ser eliminado pela gestão do ciclo de vida dos objetos até 24 horas mais tarde, devido aos critérios da configuração antiga.

Para exemplos de utilização, consulte o artigo Exemplos de configuração para a gestão do ciclo de vida de objetos.

Ações do ciclo de vida

Uma regra do ciclo de vida especifica exatamente uma das seguintes ações:

Eliminar

A ação Delete elimina um objeto quando este cumpre todas as condições especificadas na regra do ciclo de vida. Por predefinição, quando elimina um objeto ativo, este é eliminado temporariamente e o Cloud Storage mantém-no durante sete dias. Pode restaurar este objeto eliminado temporariamente durante o período de retenção da eliminação temporária.

Exceção: em contentores com a funcionalidade de controlo de versões de objetos ativada, a eliminação da versão ativa de um objeto faz com que se torne numa versão não atual, enquanto a eliminação de uma versão não atual elimina essa versão do contentor. Consulte a configuração para eliminar objetos para ver um exemplo de utilização da ação Delete juntamente com o controlo de versões de objetos.

A ação Delete não tem efeito num objeto enquanto o objeto tiver uma retenção de objeto ou uma política de retenção que ainda não tenha cumprido. Enquanto as condições na ação Delete permanecerem satisfeitas para o objeto, a ação Delete ocorre após a remoção de qualquer retenção de objeto e o cumprimento de qualquer política de retenção.

SetStorageClass

A ação SetStorageClass altera a classe de armazenamento de um objeto e atualiza a hora de modificação do objeto quando este cumpre todas as condições especificadas na regra do ciclo de vida.

O SetStorageClass suporta as seguintes transições de classe de armazenamento:

Classe de armazenamento original Nova classe de armazenamento
Armazenamento de disponibilidade reduzida duradouro (DRA) Nearline Storage
Coldline Storage
Archive Storage
Multi-Regional Storage/Regional Storage1
Armazenamento padrão, armazenamento multirregional ou armazenamento regional Nearline Storage
Coldline Storage
Archive Storage
Nearline Storage Coldline Storage
Archive Storage
Coldline Storage Armazenamento de arquivo

1 Para contentores numa região, a nova classe de armazenamento não pode ser Multi-Regional Storage. Para contentores numa multirregião ou numa região dupla, a nova classe de armazenamento não pode ser o armazenamento regional.

O Cloud Storage não valida a correção da transição da classe de armazenamento. Isto significa que pode especificar uma transição de classe de armazenamento não indicada na tabela acima, mas a transição não ocorre. Deve verificar se as suas regras de ciclo de vida usam uma das transições de classe de armazenamento indicadas.

Aborte carregamentos em várias partes incompletos

A ação AbortIncompleteMultipartUpload anula um carregamento multipartes incompleto e elimina as partes associadas quando o carregamento multipartes cumpre as condições especificadas na regra do ciclo de vida.

Só é possível usar as seguintes condições do ciclo de vida com esta ação:

A tentativa de criar uma regra que use a ação AbortIncompleteMultipartUpload em combinação com outras condições resulta num erro.

Condições do ciclo de vida

Uma regra do ciclo de vida inclui condições que um objeto tem de cumprir antes de a ação definida na regra ocorrer no objeto. As regras do ciclo de vida suportam as seguintes condições:

Todas as condições são opcionais, mas é necessária, pelo menos, uma condição. Se tentar definir uma configuração do ciclo de vida inválida, por exemplo, usando uma ação ou uma condição que não existe, recebe uma resposta de erro 400 Bad request e qualquer configuração do ciclo de vida existente permanece em vigor.

age

A condição age é satisfeita quando um recurso atinge a idade especificada (em dias). A idade é medida a partir da hora de criação do recurso.

  • Para objetos, a data/hora de criação é a data/hora em que o objeto é escrito com êxito no contentor, como quando um carregamento é concluído.

    • A idade de um objeto não é afetada pelo facto de o objeto se tornar uma versão não atual.

  • Para carregamentos multipartes, a hora de criação é a hora em que o carregamento é iniciado.

Por exemplo, se um recurso for criado a 10/01/2022 às 10:00 UTC e a condição for de 10 dias, a condição é satisfeita para o recurso a partir de 20/01/2022 às 10:00 UTC, inclusive.age

createdBefore

A condição createdBefore é satisfeita quando um objeto é criado antes da meia-noite da data especificada em UTC.

customTimeBefore

A condição customTimeBefore é satisfeita quando a parte da data dos Custom-Time metadados de um objeto é anterior à data especificada nesta condição. Esta condição é definida através do formato de data YYYY-MM-DD. customTimeBefore nunca é satisfeita para um objeto sem um conjunto de metadados Custom-Time.

daysSinceCustomTime

A condição daysSinceCustomTime é satisfeita quando o número especificado de dias tiver passado desde a data e a hora especificadas no campo de metadados Custom-Time de um objeto. Por exemplo, se o Custom-Time de um objeto for 2020-05-16T10:00:00Z e a condição daysSinceCustomTime for de 10 dias, então a condição é satisfeita para o objeto a partir de 26/05/2020 às 10:00 UTC, inclusive.

daysSinceCustomTime nunca é satisfeita para um objeto sem um conjunto de metadados Custom-Time.

daysSinceNoncurrentTime

Normalmente, a condição daysSinceNoncurrentTime só é usada em conjunto com a versão de objetos. A condição é satisfeita quando o número especificado de dias tiver decorrido desde que o objeto se tornou não atual, quer porque a versão publicada foi eliminada ou substituída. Por exemplo, se um objeto ficar obsoleto a 08/07/2020 às 15:00 UTC e a condição daysSinceNoncurrentTime for de 10 dias, a condição é satisfeita para o objeto a partir de 18/07/2020 às 15:00 UTC, inclusive.

isLive

Normalmente, a condição isLive só é usada em conjunto com a versão de objetos. Quando está definida como false, esta condição é cumprida para qualquer versão não atual de um objeto. Quando está definida como true, esta condição é satisfeita para a versão publicada de um objeto. Se não usar o controlo de versões, todos os seus objetos são considerados ativos e correspondem quando isLive é true.

matchesPrefix e matchesSuffix

As condições matchesPrefix e matchesSuffix são satisfeitas quando o início ou o fim do nome de um objeto corresponde exatamente, com distinção entre maiúsculas e minúsculas, ao prefixo ou ao sufixo especificado. Pode especificar várias strings como uma lista (por exemplo, "matchesSuffix": [".jpg", ".png"]).

Quando usar matchesPrefix, não inclua o nome do contentor nem o / que precede os nomes dos objetos na maioria dos caminhos dos pedidos. Por exemplo, na Google Cloud CLI, o caminho para um objeto num contentor denominado my_bucket tem um formato semelhante a gs://my_bucket/pictures/paris_2022.jpg. Para fazer corresponder o objeto, usaria uma condição como "matchesPrefix":["pictures/paris_"].

Pode ter um total de até 1000 prefixos e sufixos especificados em todas as regras. Na Google Cloud consola, pode copiar e colar até 1000 prefixos ou sufixos no total. Não é possível usar um prefixo ou um sufixo duas vezes numa única condição.

matchesStorageClass

A condição matchesStorageClass é satisfeita quando um objeto no contentor é armazenado como a classe de armazenamento especificada. Pode usar os seguintes valores para matchesStorageClass: STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL e DURABLE_REDUCED_AVAILABILITY.

Geralmente, se pretender usar a condição matchesStorageClass em objetos de armazenamento padrão, também deve incluir o seguinte:

  • Se o contentor estiver numa região, inclua REGIONAL e DURABLE_REDUCED_AVAILABILITY na condição.

  • Se o contentor estiver numa região múltipla ou em duas regiões, inclua MULTI_REGIONAL e DURABLE_REDUCED_AVAILABILITY na condição.

A inclusão destas classes adicionais garante que a regra do ciclo de vida abrange objetos mais antigos nos seus contentores, que podem estar definidos para classes de armazenamento antigas.

noncurrentTimeBefore

Normalmente, a condição noncurrentTimeBefore só é usada em conjunto com a versão de objetos. A condição é cumprida para objetos que se tornaram não atuais numa data anterior à especificada nesta condição. A condição é definida através do formato de data YYYY-MM-DD. noncurrentTimeBefore nunca é satisfeita para um objeto dinâmico.

numNewerVersions

Normalmente, a condição numNewerVersions só é usada em conjunto com a versão de objetos. Se o valor desta condição estiver definido como N, uma versão de objeto satisfaz a condição quando existem, pelo menos, N versões (incluindo a versão publicada) mais recentes do que a versão de objeto. Para uma versão de objeto ativa, o número de versões mais recentes é considerado 0. Para a versão não atual mais recente, o número de versões mais recentes é 1 (ou 0 se não existir uma versão de objeto publicada) e assim sucessivamente.

Comportamento do ciclo de vida de objetos

Quando a gestão do ciclo de vida de objetos está configurada para contentores do Cloud Storage, o Cloud Storage inspeciona regularmente todos os objetos e executa todas as ações aplicáveis de acordo com as regras do contentor. O Cloud Storage executa uma ação de forma assíncrona, pelo que pode haver um atraso entre o momento em que as condições são satisfeitas e o momento em que a ação é tomada. As suas aplicações não devem depender de ações do ciclo de vida que ocorram num determinado período após o cumprimento de uma condição do ciclo de vida.

Por exemplo, se um objeto cumprir as condições para eliminação, o objeto pode não ser eliminado imediatamente e vê o objeto até que a ação do ciclo de vida seja executada no objeto.

As cobranças aplicáveis continuam a aplicar-se enquanto o objeto permanecer no seu estado original, com exceção dos custos de armazenamento em repouso, que são dispensados se o objeto cumprir todos os seguintes critérios:

  • O objeto está num contentor com a eliminação reversível desativada.

  • O objeto está sujeito a uma regra com uma ação Delete.

  • A única condição para a regra é uma condição age ou uma combinação das condições age e matchesStorageClass.

  • A condição age é satisfeita para o objeto em regras com apenas a condição de idade. As condições age e matchesStorageClass devem ser cumpridas para o objeto se a regra de eliminação tiver ambas as condições.

  • O objeto não tem retenções de objetos.

Comportamento do ciclo de vida de objetos em objetos com versões

Nos contentores com a versão de objetos ativada, um objeto ativo que é eliminado de acordo com as regras do ciclo de vida existe num estado não atual durante algum tempo. Se a versão não atual do objeto também satisfizer as condições da regra de eliminação, a versão não atual do objeto também é eliminada após o tempo decorrido.

Por exemplo, suponhamos que existe uma regra de ciclo de vida que elimina objetos com mais de 180 dias. Se um objeto ativo tiver 200 dias, é eliminado e torna-se não atual. O objeto que já não é atual continua a ter mais de 180 dias, pelo que o objeto que já não é atual também é eliminado após algum tempo.

SetStorageClass considerações sobre o custo

Semelhante à alteração manual da classe de armazenamento de um objeto, a utilização de SetStorageClass é considerada uma operação de classe A e é faturada à taxa determinada pela classe de armazenamento de destino.

Ao contrário da alteração manual da classe de armazenamento de um objeto, a utilização de SetStorageClass não reescreve um objeto. Isto dá à gestão do ciclo de vida de objetos determinadas vantagens de preços:

  • Nunca existem taxas de replicação entre regiões, taxas de obtenção ou taxas de eliminação antecipada associadas à alteração da classe de armazenamento. No entanto, aplicam-se taxas de eliminação antecipada se os objetos numa classe de armazenamento com uma duração mínima de armazenamento especificada forem eliminados antes do fim da duração.

  • O tempo gasto do objeto definido na classe de armazenamento original é contabilizado para qualquer duração mínima de armazenamento que se aplique à nova classe de armazenamento.

Por exemplo, suponhamos que carrega um objeto como armazenamento Nearline e, 20 dias depois, a configuração do ciclo de vida altera a classe de armazenamento do objeto para armazenamento Coldline. Esta alteração não incorre em taxas de obtenção nem de eliminação antecipada. Se, em seguida, eliminar o objeto 60 dias após a alteração da classe de armazenamento, só é cobrada uma taxa de eliminação antecipada de 10 dias, uma vez que o armazenamento Coldline tem uma duração mínima de armazenamento de 90 dias e o objeto existiu durante um total de 80 dias.

Em comparação, suponhamos que carrega um objeto como armazenamento Nearline e, 20 dias depois, altera a classe de armazenamento através de uma reescrita (novamente para armazenamento Coldline). Esta alteração implica uma taxa de obtenção e um custo de eliminação antecipada de 10 dias. Se, em seguida, eliminar o objeto 60 dias após a reescrita, é cobrada uma taxa de eliminação antecipada de 30 dias.

Em ambos os exemplos, se a eliminação temporária estiver ativada no contentor, as taxas de armazenamento aumentam, mas as taxas de eliminação antecipada diminuem com base na duração do período de retenção da eliminação temporária.

Hora de criação do objeto

Em muitos casos, o carregamento de um objeto é concluído pouco depois de começar. No entanto, para carregamentos que ocorrem em vários pedidos, como carregamentos retomáveis, podem passar dias entre o envio do pedido de carregamento inicial e o envio do pedido de carregamento final. Nesses casos, deve ter em atenção o seguinte:

  • Um objeto não está sujeito a regras do ciclo de vida até que o respetivo carregamento seja concluído.
  • A hora de criação de um objeto baseia-se no momento em que o carregamento é concluído. Isto afeta as condições do ciclo de vida age e createdBefore.
  • Quando define um Custom-Time para o objeto, fá-lo no início do carregamento. Se definir um Custom-Time com base na hora do pedido, o Custom-Time pode ser muito anterior à hora de criação do objeto. Isto afeta as condições do ciclo de vida da customTimeBefore e da daysSinceCustomTime.

Metadados de tempo de expiração

Se for especificada uma ação Delete para um contentor com a condição age (e nenhuma outra condição além de matchesStorageClass), alguns objetos podem ser etiquetados com metadados de tempo de validade. A hora de expiração de um objeto indica a hora em que o objeto se torna (ou tornou-se) elegível para eliminação pela gestão do ciclo de vida de objetos. O tempo de expiração pode mudar à medida que a configuração do ciclo de vida ou a política de retenção do contentor mudam.

Tenha em atenção que a ausência de metadados de tempo de expiração não significa necessariamente que o objeto não vai ser eliminado, mas sim que não estão disponíveis informações suficientes para determinar quando ou se vai ser eliminado. Por exemplo, se a hora de criação do objeto for 10/01/2020 às 10:00 UTC e a condição age estiver definida para 10 dias, a hora de validade do objeto é 20/01/2020 às 10:00 UTC. No entanto, a hora de expiração não está disponível para o objeto se:

  • Existem outras condições especificadas na regra Delete, com exceção de matchesStorageClass.

  • Usa uma condição matchesStorageClass que não inclui a classe de armazenamento do objeto.

  • O objeto está sob uma retenção, porque o Cloud Storage não consegue saber quando a retenção vai ser removida.

  • A eliminação temporária está ativada no seu contentor.

Não lhe é cobrado armazenamento após a hora de expiração do objeto, mesmo que o objeto não seja eliminado imediatamente. Pode continuar a aceder ao objeto antes de ser eliminado e é responsável por outros encargos (pedido, largura de banda da rede). Se a hora de validade não estiver disponível para um objeto, o objeto é cobrado pelo armazenamento até à hora em que é eliminado.

Quando trabalhar com prazos de validade, tenha em atenção o seguinte:

  • Se o contentor tiver uma política de retenção, a hora de validade é a mais tardia entre a condição de gestão do ciclo de vida do objeto age e a hora em que o objeto cumpre o período de retenção especificado pela política de retenção.

  • Se existirem vários prazos de validade em conflito aplicáveis a um objeto devido a diferentes regras de gestão do ciclo de vida, é usado o prazo de validade aplicável mais antigo.

Opções para acompanhar ações do ciclo de vida

Para acompanhar as ações de gestão do ciclo de vida que o Cloud Storage realiza, use uma das seguintes opções:

  • Use os registos de utilização do Cloud Storage. Esta funcionalidade regista a ação e quem a realizou. Um valor de GCS Lifecycle Management no campo cs_user_agent da entrada do registo indica que a ação foi realizada pelo Cloud Storage de acordo com uma configuração do ciclo de vida.
  • Ative as notificações do Pub/Sub para o Cloud Storage para o seu contentor. Esta funcionalidade envia notificações para um tópico do Pub/Sub à sua escolha quando ocorrem ações especificadas. Tenha em atenção que esta funcionalidade não regista quem realizou as ações.

O que se segue?