Configuración Muestras de configuración
Cloud Storage ofrece la característica de Administración del ciclo de vida de los objetos a fin de ser compatible con casos prácticos comunes que incluyen establecer un tiempo de actividad (TTL) para los objetos, archivar versiones anteriores de objetos o “cambiar a una versión anterior” de las clases de almacenamiento de objetos para facilitar la administración de los costos.
En esta página, se describen las características y las opciones disponibles cuando se usan. Si deseas obtener más información sobre el formato general del archivo de configuración del ciclo de vida, consulta la representación de recursos del bucket para JSON o el formato de configuración del ciclo de vida para XML.
Introducción
Para usar la Administración del ciclo de vida de los objetos, debes definir una configuración del ciclo de vida, que se debe establecer en un bucket. La configuración contiene un conjunto de reglas que se aplican a los objetos actuales y futuros del bucket. Cuando un objeto cumple con los criterios de una de las reglas, Cloud Storage realiza de forma automática una acción específica en él. Estos son algunos ejemplos de casos de uso:
- Pasar la clase de almacenamiento de objetos con más de 365 días a Coldline Storage
- Borrar objetos creados antes del 1 de enero de 2019
- Conservar solo las 3 versiones más recientes de cada objeto en un bucket con el control de versiones habilitado
Configuración del ciclo de vida
Cada configuración de administración del ciclo de vida contiene un conjunto de reglas. Cada regla contiene una acción y una o más condiciones.
Un objeto debe coincidir con todas las condiciones especificadas en una regla para que se realice la acción de la regla.
Si especificas varias reglas que contienen la misma acción, esta se realiza en un objeto cuando ese objeto coincide con las condiciones de cualquiera de las reglas.
Si se cumplen las condiciones de varias reglas de forma simultánea para un solo objeto, Cloud Storage realiza la acción asociada con solo una de las reglas, según las siguientes consideraciones:
- La acción
Delete
tiene prioridad sobre cualquier acciónSetStorageClass
. - La acción
SetStorageClass
que cambia el objeto a la clase de almacenamiento con el precio de almacenamiento en reposo más bajo tiene prioridad.
Por ejemplo, si tienes una regla que cambia la clase del objeto a Nearline Storage y otra que la cambia a Coldline Storage, pero ambas reglas usan la misma condición, la clase del objeto siempre cambia a Coldline Storage cuando se cumple la condición.
- La acción
Debes probar las reglas del ciclo de vida en los datos en desarrollo antes de aplicarlas a la producción para asegurarte de que no realicen acciones en conjuntos de condiciones no deseados. Si eso no es posible, debes realizar pruebas en un subconjunto pequeño de tus datos de producción mediante las condiciones
matchesPrefix
omatchesSuffix
en tus reglas.Los cambios en la configuración del ciclo de vida de un depósito pueden tardar hasta 24 horas en aplicarse, y la Administración del ciclo de vida de los objetos aún puede realizar acciones basadas en la configuración anterior durante este tiempo.
Por ejemplo, si cambias una condición
age
de 10 días a 20, la Administración del ciclo de vida de los objetos podría borrar un objeto de 11 días de antigüedad hasta 24 horas más tarde, debido a los criterios de la configuración anterior.
Para casos prácticos, consulta Ejemplos de configuración para la Administració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:
Borrar
La acción Delete
borra un objeto cuando este cumple con todas las condiciones especificadas en la regla del ciclo de vida. Según la configuración predeterminada, cuando borras un objeto activo, este se borra de forma no definitiva y Cloud Storage lo conserva durante siete días. Puedes restablecer este objeto borrado de forma no definitiva dentro del período de retención de la eliminación no definitiva.
Excepción: En los buckets con el control de versiones de objetos habilitado, borrar la versión publicada de un objeto hace que se convierta en una versión no actual, mientras que borrar una versión no actual provoca que se borre esa versión del bucket. Consulta la configuración para borrar objetos a fin de obtener un ejemplo del uso de la acción Delete
junto con el control de versiones de objetos.
La acción Delete
no tiene efecto en un objeto mientras ese objeto tenga una conservación de objetos en él o una política de retención que aún no se completó. Siempre que las condiciones de la acción Delete
se cumplan para el objeto, la acción Delete
se produce después de que se quita cualquier conservación de objeto y se cumple cualquier política de retención.
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 con todas las condiciones especificadas en la regla del ciclo de vida.
SetStorageClass
es compatible con las siguientes transiciones de clases de almacenamiento:
Clase de almacenamiento original | Nueva clase de almacenamiento |
---|---|
Durable Reduced Availability Storage (DRA) | Nearline storage Coldline storage Archive storage Multi-Regional storage/Regional storage1 |
Standard storage, Multi-Regional storage o Regional storage | Nearline Storage Coldline Storage Archive Storage |
Nearline Storage | Coldline Storage Archive Storage |
Coldline Storage | Archive Storage |
1 Para los buckets en una región, la clase de almacenamiento nueva no puede ser Multi-Regional Storage. En el caso de los buckets en una región doble o múltiple, la clase de almacenamiento nueva no puede ser Regional Storage.
Cloud Storage no valida si la transición de la clase de almacenamiento es correcta. Esto significa que puedes especificar una transición de una clase de almacenamiento que no aparece en la tabla anterior, pero la transición no se llevará a cabo. Debes verificar que en las reglas del ciclo de vida se usen las transiciones de una clase de almacenamiento de la lista.
Anula cargas multiparte incompletas
La acción AbortIncompleteMultipartUpload
anula una carga multiparte incompleta y borra las partes asociadas cuando la carga multiparte cumple las condiciones especificadas en la regla del ciclo de vida.
Con esta acción, solo se pueden usar las siguientes condiciones del ciclo de vida:
Si intentas crear una regla que use la acción AbortIncompleteMultipartUpload
en combinación con otras condiciones, se generará un error.
Condiciones del ciclo de vida
Una regla de ciclo de vida incluye condiciones que un objeto debe cumplir antes de que la acción definida en la regla se produzca en él. Las reglas de ciclos de vida son compatibles con las siguientes condiciones:
age
createdBefore
customTimeBefore
daysSinceCustomTime
daysSinceNoncurrentTime
isLive
matchesStorageClass
matchesPrefix
ymatchesSuffix
noncurrentTimeBefore
numNewerVersions
Todas las condiciones son opcionales, pero se requiere al menos una. Si quieres establecer una configuración del ciclo de vida no válida, como el uso de una acción o condición que no existe, recibirás una respuesta de error 400 Bad request
, y no se modificará ninguna configuración del ciclo de vida existente.
age
La condición age
se cumple cuando un recurso alcanza la antigüedad especificada (en días). La antigüedad se mide desde la hora de creación del recurso.
En el caso de los objetos, la hora de creación es el momento en que el objeto se escribe en el bucket de forma correcta, como cuando se completa una carga.
- La antigüedad de un objeto no se ve afectada cuando el objeto se convierte en una versión no actual.
En el caso de las cargas de varias partes, la hora de creación es el momento en que se inicia la carga.
Por ejemplo, si se crea un recurso el 10/01/2022 a las 10:00 UTC y la condición age
es de 10 días, la condición se cumple para el recurso 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 correspondiente a la fecha de los metadatos Custom-Time
de un objeto es anterior a la fecha especificada en esta condición. Esta condición se establece con el formato de fecha YYYY-MM-DD
.
customTimeBefore
nunca se cumple en un objeto sin metadatos Custom-Time
establecidos.
daysSinceCustomTime
La condición daysSinceCustomTime
se cumple cuando la cantidad especificada de días pasó desde la fecha y hora especificadas en el campo de metadatos Custom-Time
de un objeto. Por ejemplo, si la 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 2020/05/26 10:00 UTC.
daysSinceCustomTime
nunca se cumple en un objeto sin metadatos Custom-Time
establecidos.
daysSinceNoncurrentTime
Por lo general, la condición daysSinceNoncurrentTime
solo se usa junto con el control de versiones de objetos. La condición se cumple cuando la cantidad especificada de días pasó desde que el objeto se convirtió en no actual, ya sea porque la versión publicada se borró o se reemplazó. Por ejemplo, si un objeto se convirtió en no actual el 2020/07/08 15:00 UTC y la condición daysSinceNoncurrentTime
es de 10 días, la condición se cumple para el objeto a partir del 2020/07/18 15:00 UTC.
isLive
Por lo general, la condición isLive
solo se usa junto con el control de versiones de objetos. Cuando se establece en false
, esta condición se cumple para cualquier versión no actual de un objeto. Cuando se establece en true
, esta condición se cumple para la versión publicada de un objeto. Si no usas el control de versiones, todos tus objetos se consideran publicados y coinciden cuando isLive
se establece en true
.
matchesPrefix
y matchesSuffix
Las condiciones matchesPrefix
y matchesSuffix
se cumplen cuando el principio o el final del nombre de un objeto coincide exactamente con el prefijo o sufijo especificado, distinguiendo mayúsculas de minúsculas. Puedes especificar varias strings como una lista (por ejemplo, "matchesSuffix": [".jpg", ".png"]
).
Cuando uses matchesPrefix
, no incluyas el nombre del bucket ni el /
que precede a los nombres de objetos en la mayoría de las rutas de solicitud. Por ejemplo, en Google Cloud CLI, la ruta a un objeto en un bucket denominado my_bucket
tiene un formato similar a gs://my_bucket/pictures/paris_2022.jpg
. Para que coincida con el objeto, debes usar una condición como "matchesPrefix":["pictures/paris_"]
.
Puedes tener hasta 50 prefijos y 50 sufijos especificados en todas las reglas. No se puede usar un prefijo ni sufijo dos veces en una sola condición.
matchesStorageClass
La condición matchesStorageClass
se cumple cuando se almacena un objeto en el bucket como la clase de almacenamiento especificada. Puedes usar los siguientes valores para matchesStorageClass
: STANDARD
, NEARLINE
, COLDLINE
, ARCHIVE
, MULTI_REGIONAL
, REGIONAL
y DURABLE_REDUCED_AVAILABILITY
.
En general, si quieres usar la condición matchesStorageClass
en objetos de Standard Storage, también debes incluir lo siguiente:
Si el depósito está en una región, debes incluir
REGIONAL
yDURABLE_REDUCED_AVAILABILITY
en la condición.Si el bucket está en una región doble o múltiple, incluye
MULTI_REGIONAL
yDURABLE_REDUCED_AVAILABILITY
en la condición.
La inclusión de estas clases adicionales garantiza que la regla del ciclo de vida cubra objetos más antiguos en tus buckets, los que pueden configurarse en clases de almacenamiento heredadas.
noncurrentTimeBefore
Por lo general, la condición noncurrentTimeBefore
solo se usa junto con el control de versiones de objetos. La condición se cumple en los objetos que se convirtieron en no actuales en una fecha anterior a la que se especifica en esta condición. La condición se establece con el formato de fecha YYYY-MM-DD
. noncurrentTimeBefore
nunca se cumple en un objeto activo.
numNewerVersions
Por lo general, la condición numNewerVersions
solo se usa junto con el control de versiones de objetos. Si el valor de esta condición se establece en N, una versión de objeto cumple con la condición cuando existen, al menos, N versiones más recientes que esta (incluida la versión publicada). Para la versión publicada de un objeto, la cantidad de versiones más recientes es 0. Para la versión no actual más reciente, la cantidad de versiones más recientes es 1 (o 0 si no existen versiones publicadas de un objeto), y así de forma sucesiva.
Comportamiento del ciclo de vida del objeto
Cloud Storage inspecciona con regularidad todos los objetos en un bucket en el que esté configurada la Administración del ciclo de vida de los objetos y realiza todas las acciones aplicables según las reglas del bucket. Cloud Storage realiza una acción de manera asíncrona, por lo que puede haber un lapso de tiempo entre el momento en el que las condiciones se cumplen y en el que se realiza la acción. Tus aplicaciones no deben depender de las acciones del ciclo de vida que se producen en un determinado período después de que se cumple una condición del ciclo de vida.
Por ejemplo, si un objeto cumple con las condiciones para la eliminación, es posible que el objeto no se borre de inmediato y lo veas hasta que la acción del ciclo de vida se ejecute en él. En buckets que tienen habilitado el control de versiones de objetos, esto significa que un objeto activo existirá en un estado no actual por un tiempo, incluso si la versión no actual del objeto también cumple con las condiciones de la regla de eliminación.
Se siguen aplicando cargos aplicables mientras el objeto se mantenga en su estado original, con una excepción: los costos del almacenamiento en reposo no se aplican si el objeto cumple con todos los criterios siguientes:
- El objeto está en un bucket con la opción de eliminación no definitiva inhabilitada
- El objeto está sujeto a una regla con una acción
Delete
- La única condición para la regla es una condición
age
- La condición
age
se cumple en el objeto.
Consideraciones de costo para SetStorageClass
De manera similar a Cambia clases de almacenamiento de objetos de forma manual, el uso de SetStorageClass
cuenta como una operación de Clase A y se factura con la tarifa que determina la clase de almacenamiento del destino
A diferencia del cambio de la clase de almacenamiento de un objeto de forma manual, el uso de SetStorageClass
no reescribe un objeto. Esto le brinda a la Administración del ciclo de vida de los objetos ciertas ventajas
de precios:
Nunca se aplican cargos de replicación interregionales, tarifas de recuperación ni tarifas de eliminación temprana asociados con el cambio de clase de almacenamiento.
El tiempo consumido del objeto establecido en la clase de almacenamiento original se considera como parte de cualquier duración de almacenamiento mínima que se aplique a la clase de almacenamiento nueva.
Por ejemplo, supongamos que subiste un objeto como Nearline Storage y, 20 días después, la configuración del ciclo de vida cambia la clase de almacenamiento del objeto a Coldline Storage. Este cambio no genera tarifas de recuperación ni de eliminación temprana. Si borras el objeto 60 días después del cambio de clase de almacenamiento, solo se aplicará un cargo por eliminación temprana correspondiente a 10 días, dado que Coldline Storage tiene una duración mínima de almacenamiento de 90 días y el objeto existió por un total de 80 días.
En comparación, supongamos que subiste un objeto como Nearline Storage y, 20 días después, cambias la clase de almacenamiento mediante una reescritura (de nuevo a Coldline Storage). Este cambio genera una tarifa de recuperación y un cargo de eliminación temprana correspondiente a 10 días. Si borras el objeto 60 días después de la reescritura, hay un cargo por eliminación temprana correspondiente a 30 días.
En ambos ejemplos, si la eliminación no definitiva está habilitada en el bucket, los cargos por almacenamiento aumentan, pero los cargos por eliminación temprana se reducen según la duración del período de retención de eliminación no definitiva.
Hora de creación de los objetos
En muchos casos, la carga de un objeto se completa poco después de que comienza. Sin embargo, para las cargas que ocurren en varias solicitudes, como las cargas reanudables, pueden pasar días entre el momento en el que se envía la solicitud de carga inicial y el momento en que se envía la solicitud de carga final. En esos casos, debes tener en cuenta lo siguiente:
- Un objeto no está sujeto a las reglas del ciclo de vida hasta que se completa la carga.
- La hora de creación de un objeto se basa en la finalización de la carga. Esto afecta las condiciones del ciclo de vida de
age
ycreatedBefore
. - Cuando configuras un
Custom-Time
para el objeto, lo haces al comienzo de la carga. Si configuras unCustom-Time
según el momento de la solicitud,Custom-Time
podría darse mucho antes que la hora de creación del objeto. Esto afecta las condiciones del ciclo de vida decustomTimeBefore
ydaysSinceCustomTime
.
Metadatos de hora de vencimiento
Si se especifica una acción Delete
para un bucket con la condición age
(y ninguna otra condición aparte de matchesStorageClass
), algunos objetos pueden etiquetarse con metadatos de hora de vencimiento. La hora de vencimiento de un objeto indica el momento en que el objeto cumple (o cumplió) con las condiciones para que la Administración del ciclo de vida de los objetos lo borre. La hora de vencimiento puede cambiar a medida que cambia la configuración del ciclo de vida del bucket o la política de retención.
Ten en cuenta que la ausencia de los metadatos de hora de vencimiento no significa necesariamente que el objeto no se borrará, sino que no hay suficiente información disponible para determinar cuándo se borrará o si se borrará. Por ejemplo, si la hora de creación de un objeto es 10:00 UTC del 10/01/2020 y la condición age
es 10 días, entonces la hora de vencimiento del objeto es a las 10:00 UTC del 20/01/2020. Sin embargo, la hora de vencimiento no está disponible para el objeto en los siguientes casos:
Hay otras condiciones especificadas en la regla
Delete
, con la excepción dematchesStorageClass
.Usas una condición
matchesStorageClass
que no incluye la clase de almacenamiento del objeto.El objeto está en conservación, debido a que Cloud Storage no puede saber cuándo se quitará la conservación.
La eliminación no definitiva está habilitada en tu bucket.
No se cobra por el almacenamiento después de la hora de vencimiento del objeto incluso si el objeto no se borra de inmediato. Puedes acceder al objeto antes de que se borre. Eres responsable de otros cargos (solicitud, ancho de banda de la red). Si la hora de vencimiento no está disponible para un objeto, se cobra por el almacenamiento del objeto hasta el momento en que se borre.
Cuando trabajes con horas de vencimiento, ten en cuenta lo siguiente:
Si el bucket tiene una política de retención, la hora de vencimiento es la última de la condición
age
de la Administración del ciclo de vida de los objetos y la hora en que el objeto cumple con el período de retención que especifica la política de retención.Si existen varias horas de vencimiento en conflicto aplicables para un objeto debido a diferentes reglas de administración de ciclos de vida, se usa la primera hora de vencimiento aplicable.
Opciones para el seguimiento de las acciones del ciclo de vida
Para realizar un seguimiento de las acciones de administración del ciclo de vida que realiza Cloud Storage, usa una de las siguientes opciones:
- Usa los registros de uso de Cloud Storage. Esta característica registra la acción y quién la realiza. Un valor de
GCS Lifecycle Management
en el campocs_user_agent
de la entrada de registro indica que Cloud Storage realizó la acción en función de una configuración del ciclo de vida.
- Habilita las notificaciones de Pub/Sub para Cloud Storage en tu bucket. Con esta característica, se envían notificaciones a un tema de Pub/Sub de tu elección cuando se producen acciones específicas. Ten en cuenta que en esta característica no se registra quién realizó las acciones.
¿Qué sigue?
- Habilita la administración del ciclo de vida de los objetos.
- Explora los ejemplos de configuración del ciclo de vida.
- Revisa el formato general de la configuración del ciclo de vida en las solicitudes a la API de JSON y las solicitudes a la API de XML.