Administración del ciclo de vida de los objetos

Configurar la gestión del ciclo de vida de los objetos Ejemplos de configuración

Para admitir casos prácticos habituales, como definir un tiempo de vida (TTL) para los objetos, conservar versiones no actuales de los objetos o cambiar a clases de almacenamiento más frías para gestionar los costes, Cloud Storage ofrece la función de gestión del ciclo de vida de los objetos.

En esta página se describe la función y las opciones disponibles al usarla. Para ver el formato general de un archivo de configuración del ciclo de vida, consulta la representación del recurso de contenedor en JSON o el formato de configuración del ciclo de vida en XML.

Introducción

Para usar la gestión del ciclo de vida de los objetos, debes definir una configuración del ciclo de vida, que debe establecerse en un segmento. La configuración contiene un conjunto de reglas que se aplican a los objetos actuales y futuros del segmento. Cuando un objeto cumple los criterios de una de las reglas, Cloud Storage realiza automáticamente una acción especificada en el objeto. A continuación le mostramos algunos casos prácticos de ejemplo:

  • Cambia a una clase de almacenamiento inferior los objetos que tengan más de 365 días.
  • Elimina los objetos creados antes del 1 de enero del 2019.
  • Conserva solo las tres versiones más recientes de cada objeto de un segmento con el control de versiones habilitado.

Configuración del ciclo de vida

Cada configuración de gestión del ciclo de vida contiene un conjunto de reglas. Cada regla contiene una acción y una o varias condiciones.

  • Un objeto debe cumplir todas las condiciones especificadas en una regla para que se aplique la acción de la regla.

  • Si especifica varias reglas que contienen la misma acción, esta se lleva a cabo en un objeto cuando dicho objeto cumple las condiciones de cualquiera de las reglas.

  • Si se cumplen simultáneamente las condiciones de varias reglas para un mismo objeto, Cloud Storage lleva a cabo la acción asociada a una sola de las reglas, según las siguientes consideraciones:

    • La acción Delete tiene prioridad sobre cualquier acción SetStorageClass.
    • Tiene prioridad la acción SetStorageClass que cambia el objeto a la clase de almacenamiento con el precio de almacenamiento en reposo más bajo.

    Por ejemplo, si tienes una regla que cambia la clase de un objeto a Nearline Storage y otra que la cambia a Coldline Storage, pero ambas reglas usan exactamente la misma condición, la clase del objeto siempre cambiará a Coldline Storage cuando se cumpla la condición.

  • Debe probar las reglas de ciclo de vida en datos de desarrollo antes de aplicarlas a la producción para asegurarse de que no realizan acciones en conjuntos de condiciones no deseados. Si no es posible, debe hacer pruebas con un pequeño subconjunto de sus datos de producción mediante las condiciones matchesPrefix o matchesSuffix en sus reglas.

  • Los cambios en la configuración del ciclo de vida de un segmento pueden tardar hasta 24 horas en aplicarse, y la gestión del ciclo de vida de los objetos puede seguir realizando acciones basadas en la configuración anterior durante ese tiempo.

    Por ejemplo, si cambias una condición de age de 10 a 20 días, un objeto que tenga 11 días podría eliminarse mediante la gestión del ciclo de vida de los objetos hasta 24 horas después, debido a los criterios de la configuración anterior.

Para ver casos prácticos, consulta Ejemplos de configuración de la gestión del ciclo de vida de los objetos.

Acciones del ciclo de vida

Una regla de ciclo de vida especifica exactamente una de las siguientes acciones:

Eliminar

La acción Delete elimina un objeto cuando este cumple todas las condiciones especificadas en la regla de ciclo de vida. De forma predeterminada, cuando eliminas un objeto activo, se elimina de forma lógica y Cloud Storage lo conserva durante siete días. Puedes restaurar este objeto eliminado no definitivamente durante el periodo de retención de la eliminación no definitiva.

Excepción: En los segmentos que tienen habilitada la gestión de versiones de objetos, al eliminar la versión activa de un objeto, esta se convierte en una versión no actual, mientras que, al eliminar una versión no actual, esta se elimina del segmento. Consulta la configuración para eliminar objetos para ver un ejemplo de cómo usar la acción Delete junto con la gestión de versiones de objetos.

La acción Delete no se aplica a un objeto mientras este tenga una retención de objeto o una política de conservación que aún no haya cumplido. Mientras se sigan cumpliendo las condiciones de la acción Delete para el objeto, esta acción se producirá después de que se retire cualquier retención del objeto y se cumpla cualquier política de retención.Delete

SetStorageClass

La acción SetStorageClass cambia la clase de almacenamiento de un objeto y actualiza la hora de modificación del objeto cuando este cumple todas las condiciones especificadas en la regla de ciclo de vida.

SetStorageClass admite las siguientes transiciones de clase de almacenamiento:

Clase de almacenamiento original Nueva clase de almacenamiento
DRA Storage Nearline Storage
Coldline Storage
Archive Storage
Almacenamiento multirregional o regional1
Almacenamiento estándar, multirregional o regional Nearline Storage
Coldline Storage
Archive Storage
Nearline Storage Almacenamiento Coldline
Archive Storage
Almacenamiento Coldline Almacenamiento de archivado

1 En el caso de los segmentos de una región, la nueva clase de almacenamiento no puede ser Multi-Regional Storage. En el caso de los segmentos de una multirregión o de dos regiones, la nueva clase de almacenamiento no puede ser Regional.

Cloud Storage no valida la corrección de la transición de la clase de almacenamiento. Esto significa que puedes especificar una transición de clase de almacenamiento que no figure en la tabla anterior, pero la transición no se producirá. Debe verificar que sus reglas de ciclo de vida usen una de las transiciones de clase de almacenamiento que se indican en la lista.

Anular subidas multiparte incompletas

La acción AbortIncompleteMultipartUpload aborta una subida multiparte incompleta y elimina las partes asociadas cuando la subida multiparte cumple las condiciones especificadas en la regla de ciclo de vida.

Con esta acción solo se pueden usar las siguientes condiciones de ciclo de vida:

Si intentas crear una regla que use la acción AbortIncompleteMultipartUpload en combinación con otras condiciones, se producirá un error.

Condiciones del ciclo de vida

Una regla de ciclo de vida incluye las condiciones que debe cumplir un objeto para que se aplique la acción definida en la regla. Las reglas del ciclo de vida admiten las siguientes condiciones:

Todas las condiciones son opcionales, pero se necesita al menos una. Si intentas definir una configuración de ciclo de vida no válida, por ejemplo, usando una acción o una condición que no existe, recibirás una respuesta de error 400 Bad request y se mantendrá la configuración de ciclo de vida que ya tuvieras.

age

La condición age se cumple cuando un recurso alcanza la antigüedad especificada (en días). La antigüedad se mide a partir de la hora de creación del recurso.

  • En el caso de los objetos, la hora de creación es el momento en el que se escribe correctamente en el segmento, por ejemplo, cuando se completa una subida.

    • La antigüedad de un objeto no se ve afectada por el hecho de que se convierta en una versión no actual.

  • En el caso de las subidas de varias partes, la hora de creación es la hora en la que se inicia la subida.

Por ejemplo, si un recurso se crea el 10/01/2022 a las 10:00 UTC y la agecondición es de 10 días, se cumplirá a partir del 20/01/2022 a las 10:00 UTC.

createdBefore

La condición createdBefore se cumple cuando se crea un objeto antes de la medianoche de la fecha especificada en UTC.

customTimeBefore

La condición customTimeBefore se cumple cuando la parte de la fecha de los Custom-Timemetadatos de un objeto es anterior a la fecha especificada en esta condición. Esta condición se define con el formato de fecha YYYY-MM-DD. customTimeBefore nunca se cumple en un objeto que no tiene metadatos Custom-Time definidos.

daysSinceCustomTime

La condición daysSinceCustomTime se cumple cuando han transcurrido el número de días especificado desde la fecha y la hora indicadas en el campo de metadatos Custom-Time de un objeto. Por ejemplo, si el Custom-Time de un objeto es 2020-05-16T10:00:00Z y la condición daysSinceCustomTime es de 10 días, la condición se cumple para el objeto a partir del 26/05/2020 a las 10:00 (UTC).

daysSinceCustomTime nunca se cumple en un objeto que no tiene metadatos Custom-Time definidos.

daysSinceNoncurrentTime

La condición daysSinceNoncurrentTime solo se suele usar junto con la gestión de versiones de objetos. La condición se cumple cuando han transcurrido el número de días especificado desde que el objeto dejó de estar actualizado, ya sea porque se eliminó o se sustituyó la versión activa. Por ejemplo, si un objeto dejó de ser actual el 8/7/2020 a las 15:00 (UTC) y la condición daysSinceNoncurrentTime es de 10 días, la condición se cumple para el objeto a partir del 18/7/2020 a las 15:00 (UTC).

isLive

La condición isLive solo se suele usar junto con la gestión de versiones de objetos. Si se le asigna el valor false, esta condición se cumple para cualquier versión no actual de un objeto. Si se le asigna el valor true, esta condición se cumple en la versión activa de un objeto. Si no usas el control de versiones, todos tus objetos se consideran activos y coinciden cuando isLive es true.

matchesPrefix y matchesSuffix

Las condiciones matchesPrefix y matchesSuffix se cumplen cuando el principio o el final del nombre de un objeto coincide exactamente (distinguiendo entre mayúsculas y minúsculas) con el prefijo o el sufijo especificados. Puedes especificar varias cadenas como una lista (por ejemplo, "matchesSuffix": [".jpg", ".png"]).

Cuando uses matchesPrefix, no incluyas el nombre del contenedor ni el / que precede a los nombres de los objetos en la mayoría de las rutas de las solicitudes. Por ejemplo, en la CLI de Google Cloud, la ruta a un objeto de un segmento llamado my_bucket tiene un formato similar a gs://my_bucket/pictures/paris_2022.jpg. Para que coincida con el objeto, puedes usar una condición como "matchesPrefix":["pictures/paris_"].

Puedes especificar hasta 1000 prefijos y sufijos en total en todas las reglas. En la Google Cloud consola, puedes copiar y pegar hasta 1000 prefijos o sufijos en total. No se puede usar un prefijo o un sufijo dos veces en una misma condición.

matchesStorageClass

La condición matchesStorageClass se cumple cuando un objeto del segmento se almacena con la clase de almacenamiento especificada. Puede usar los siguientes valores para matchesStorageClass: STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL y DURABLE_REDUCED_AVAILABILITY.

Por lo general, si tiene intención de usar la condición matchesStorageClass en objetos de almacenamiento estándar, también debe incluir lo siguiente:

  • Si el segmento está en una región, incluye REGIONAL y DURABLE_REDUCED_AVAILABILITY en la condición.

  • Si el segmento está en una multirregión o una birregión, incluya MULTI_REGIONAL y DURABLE_REDUCED_AVAILABILITY en la condición.

Si incluye estas clases adicionales, se asegurará de que la regla de ciclo de vida abarque los objetos más antiguos de sus segmentos, que podrían estar configurados con clases de almacenamiento antiguas.

noncurrentTimeBefore

La condición noncurrentTimeBefore solo se suele usar junto con la gestión de versiones de objetos. La condición se cumple en los objetos que dejaron de ser actuales en una fecha anterior a la especificada en esta condición. La condición se define con el formato de fecha YYYY-MM-DD. noncurrentTimeBefore nunca se cumple en el caso de un objeto activo.

numNewerVersions

La condición numNewerVersions solo se suele usar junto con la gestión de versiones de objetos. Si el valor de esta condición es N, una versión de un objeto cumple la condición cuando hay al menos N versiones (incluida la publicada) más recientes que ella. En el caso de una versión activa de un objeto, el número de versiones más recientes es 0. En el caso de la versión no actual más reciente, el número de versiones más recientes es 1 (o 0 si no hay ninguna versión publicada del objeto), y así sucesivamente.

Comportamiento del ciclo de vida de los objetos

Cuando se configura la gestión del ciclo de vida de los objetos en los segmentos de Cloud Storage, Cloud Storage inspecciona periódicamente todos los objetos y realiza todas las acciones aplicables según las reglas del segmento. Cloud Storage realiza una acción de forma asíncrona, por lo que puede haber un retraso entre el momento en que se cumplen las condiciones y el momento en que se lleva a cabo la acción. Tus aplicaciones no deben depender de que las acciones del ciclo de vida se produzcan en un periodo determinado después de que se cumpla una condición del ciclo de vida.

Por ejemplo, si un objeto cumple las condiciones para eliminarse, es posible que no se elimine de inmediato y que lo vea hasta que se ejecute la acción del ciclo de vida en el objeto.

Se seguirán aplicando los cargos correspondientes mientras el objeto permanezca en su estado original, a excepción de los costes de almacenamiento en reposo, que no se aplicarán si el objeto cumple todos los criterios siguientes:

  • El objeto está en un segmento con la eliminación no definitiva inhabilitada.

  • El objeto está sujeto a una regla con una acción Delete.

  • La única condición de la regla es una condición age o una combinación de las condiciones age y matchesStorageClass.

  • La condición age se cumple en el objeto de las reglas que solo tienen la condición de antigüedad. Si la regla de eliminación tiene ambas condiciones, se deben cumplir tanto la condición age como la matchesStorageClass para el objeto.

  • El objeto no tiene ninguna retención de objetos.

Comportamiento del ciclo de vida de los objetos en objetos con versiones

En los segmentos que tienen habilitada la gestión de versiones de objetos, un objeto activo que se elimina según las reglas de ciclo de vida se encontrará en un estado no actual durante un periodo determinado. Si la versión no actual del objeto también cumple las condiciones de la regla de eliminación, también se eliminará una vez transcurrido el tiempo.

Por ejemplo, supongamos que hay una regla de ciclo de vida que elimina los objetos con una antigüedad superior a 180 días. Si un objeto activo tiene 200 días, se elimina y deja de ser actual. El objeto que ya no es actual sigue teniendo más de 180 días, por lo que también se eliminará al cabo de un tiempo.

SetStorageClass consideraciones sobre el coste

Al igual que cuando cambias manualmente la clase de almacenamiento de un objeto, usar SetStorageClass se considera una operación de clase A y se factura según la tarifa determinada por la clase de almacenamiento de destino.

A diferencia de cuando se cambia la clase de almacenamiento de un objeto manualmente, al usar SetStorageClass no se reescribe el objeto. Esto ofrece a la gestión del ciclo de vida de los objetos ciertas ventajas en cuanto a los precios:

  • Nunca se aplican cargos por replicación entre regiones, tarifas de recuperación ni tarifas por eliminación anticipada asociadas al cambio de clase de almacenamiento. Sin embargo, se aplican tarifas por eliminación anticipada si se eliminan objetos de una clase de almacenamiento con un tiempo mínimo de almacenamiento especificado antes de que finalice ese tiempo.

  • El tiempo que el objeto ha estado en la clase de almacenamiento original se tiene en cuenta de cara al tiempo mínimo de almacenamiento aplicable a la nueva clase de almacenamiento.

Por ejemplo, supongamos que subes un objeto a la clase de almacenamiento Nearline y, 20 días después, la configuración del ciclo de vida cambia la clase de almacenamiento del objeto a Coldline. Este cambio no conlleva ninguna tarifa de recuperación ni de eliminación anticipada. Si eliminas el objeto 60 días después de cambiar la clase de almacenamiento, solo se te cobrará por 10 días de eliminación anticipada, ya que la clase Coldline Storage tiene un tiempo mínimo de almacenamiento de 90 días y el objeto ha estado disponible durante 80 días.

En cambio, supongamos que subes un objeto con la clase Nearline Storage y, 20 días después, cambias la clase de almacenamiento mediante una reescritura (de nuevo a Coldline Storage). Este cambio conlleva una tarifa de recuperación y un cargo por eliminación anticipada de 10 días. Si eliminas el objeto 60 días después de la reescritura, se aplicará un cargo por eliminación anticipada de 30 días.

En ambos ejemplos, si la eliminación no definitiva está habilitada en el cubo, los cargos por almacenamiento aumentan, pero los cargos por eliminación anticipada se reducen en función de la duración del periodo de conservación de la eliminación no definitiva.

Hora de creación del objeto

En muchos casos, la subida de un objeto se completa poco después de que comience. Sin embargo, en las subidas que se realizan en varias solicitudes, como las subidas reanudables, pueden pasar días entre el envío de la solicitud de subida inicial y el envío de la solicitud de subida final. En estos casos, debes tener en cuenta lo siguiente:

  • Los objetos no están sujetos a reglas de ciclo de vida hasta que se completa su subida.
  • La hora de creación de un objeto se basa en el momento en que se completa la subida. Esto afecta a las condiciones del ciclo de vida de age y createdBefore.
  • Cuando define un Custom-Time para el objeto, lo hace al principio de la subida. Si define una Custom-Time en función de la hora de la solicitud, la Custom-Time podría ser mucho anterior a la hora de creación del objeto. Esto afecta a las condiciones del ciclo de vida de customTimeBefore y daysSinceCustomTime.

Metadatos de la hora de vencimiento

Si se especifica una acción Delete para un segmento con la condición age (y ninguna otra condición además de matchesStorageClass), es posible que algunos objetos se etiqueten con metadatos de tiempo de vencimiento. La hora de vencimiento de un objeto indica el momento en el que el objeto puede (o pudo) eliminarse mediante la gestión del ciclo de vida de los objetos. El tiempo de vencimiento puede cambiar si se modifica la configuración del ciclo de vida o la política de conservación del contenedor.

Ten en cuenta que la ausencia de metadatos de tiempo de vencimiento no significa necesariamente que el objeto no se vaya a eliminar, sino que no hay suficiente información disponible para determinar cuándo o si se eliminará. Por ejemplo, si la hora de creación del objeto es el 10/01/2020 a las 10:00 (UTC) y la condición age se establece en 10 días, la hora de vencimiento del objeto es el 20/01/2020 a las 10:00 (UTC). Sin embargo, el tiempo de vencimiento no está disponible para el objeto si:

  • Hay otras condiciones especificadas en la regla Delete, con la excepción de matchesStorageClass.

  • Utiliza una condición matchesStorageClass que no incluye la clase de almacenamiento del objeto.

  • El objeto está bloqueado porque Cloud Storage no puede saber cuándo se quitará el bloqueo.

  • La eliminación suave está habilitada en tu bucket.

No se te cobrará por el almacenamiento después de la hora de vencimiento del objeto, aunque el objeto no se elimine inmediatamente. Puedes seguir accediendo al objeto antes de que se elimine y eres responsable de otros cargos (solicitud, ancho de banda de la red). Si el tiempo de vencimiento no está disponible para un objeto, se le cobrará el almacenamiento hasta que se elimine.

Cuando trabajes con tiempos de vencimiento, ten en cuenta lo siguiente:

  • Si el segmento tiene una política de retención, la hora de vencimiento es la posterior entre la condición de age de gestión del ciclo de vida de los objetos y el momento en el que el objeto cumple el periodo de retención especificado en la política de retención.

  • Si hay varios tiempos de vencimiento contradictorios aplicables a un objeto debido a diferentes reglas de gestión del ciclo de vida, se usará el tiempo de vencimiento aplicable más antiguo.

Opciones para monitorizar las acciones del ciclo de vida

Para monitorizar las acciones de gestión del ciclo de vida que lleva a cabo Cloud Storage, utilice una de las siguientes opciones:

  • Usa los registros de uso de Cloud Storage. Esta función registra tanto la acción como el usuario que la ha realizado. El valor GCS Lifecycle Management en el campo cs_user_agent de la entrada de registro indica que Cloud Storage ha realizado la acción de acuerdo con una configuración del ciclo de vida.
  • Habilita Notificaciones de Pub/Sub para Cloud Storage en tu segmento. Esta función envía notificaciones a un tema de Pub/Sub que elijas cuando se produzcan las acciones especificadas. Ten en cuenta que esta función no registra quién ha realizado las acciones.

Siguientes pasos