Gestión del ciclo de vida

Escenarios

Puede definir reglas de ciclo de vida para identificar objetos en los escenarios anteriores y gestionar aún más sus ciclos de vida.

Los objetos a los que ya no se accede con frecuencia se pueden pasar a Infrequent Access o Archive, lo que reduce los costos. En resumen, transición significa básicamente que la clase de almacenamiento de objetos se altera sin copiar el objeto. También puede cambiar manualmente la clase de almacenamiento de un objeto en la página Objects. Para obtener más información, consulte Carga de un archivo.

La configuración del ciclo de vida se puede agregar a un bucket con el control de versiones habilitado o deshabilitado. De forma predeterminada, el control de versiones está deshabilitado. Puede habilitarlo. Un bucket habilitado para la versión mantiene una versión de objeto actual y cero o más versiones de objeto no actuales. Puede usar versiones y configuraciones de ciclo de vida juntas para ayudar a reducir los costos de almacenamiento. Las acciones de configuración del ciclo de vida predefinidas pueden facilitar la gestión durante el ciclo de vida de las versiones de objetos actuales y no actuales.

Precauciones

• No hay límite en el número de reglas del ciclo de vida de un bucket, pero el tamaño total de las descripciones XML de todas las reglas del ciclo de vida de un bucket no puede superar los 20 KB.
• Se puede configurar un máximo de 20 reglas de ciclo de vida para un sistema de archivos paralelo.
• Un nombre de regla de ciclo de vida contiene solo letras mayúsculas o minúsculas, dígitos, puntos (.), guiones bajos (_) y guiones (-).
• La duración mínima de almacenamiento es de 30 días para el almacenamiento de Infrequent Access y 90 días para el almacenamiento de Archive. Después de pasar un objeto a la clase de almacenamiento de Archive, si permanece en esta clase de almacenamiento durante menos de 90 días, todavía tendrá que pagar por 90 días completos.
• Restricciones en la transición de clase de almacenamiento:
  • Solo se admiten las transiciones de la clase de almacenamiento Standard a la clase de almacenamiento de Infrequent Access. Para hacer la transición de objetos de Infrequent Access a Standard, debe operarlo manualmente.
  • Solo se admiten las transiciones de la clase de almacenamiento de Standard o de Infrequent Access a la clase de almacenamiento Archive. Para pasar objetos de Archive a Standard o Infrequent Access, primero debe restaurar los objetos archivados y, a continuación, realizar la transición manual de su clase de almacenamiento.
  • Only transitions from the Standard, Infrequent Access, or Archive storage class to the Deep Archive storage class are supported. To transition objects from Deep Archive to Standard, Infrequent Access, or Archive, you must restore the deep archived objects first and then manually transition their storage class.
• Supresión de objetos al expirar:

  Puede utilizar la regla de ciclo de vida de la acción Expiration para caducar un objeto cuando el objeto alcanza el final de su vida útil. En un bucket habilitado para control de versiones, también puede usar la acción NoncurrentVersionExpiration para caducar las versiones de objetos no actuales.

  • En un bucket con el control de versiones deshabilitado, la acción Expiration elimina permanentemente los objetos.
  • En un bucket con el control de versiones habilitado (o suspendido), la acción Expiration conserva la versión actual como una versión no actual agregando un marcador de eliminación, que luego se convierte en la versión actual. La acción NoncurrentVersionExpiration elimina permanentemente las versiones de objetos no actuales.
• Además de los bucket, también puede configurar el tiempo de caducidad de los objetos durante las cargas de objetos. El tiempo de caducidad de los objetos prevalece contra el de los cubos.

  Después de que un objeto expira, OBS agrega el objeto a la cola de eliminación y lo elimine asincrónicamente. Esto puede hacer que el tiempo de eliminación sea posterior al tiempo de expiración. Después de que un objeto caduque, no se le cobrará la tarifa de duración de almacenamiento relacionada.

  Para consultar el tiempo de caducidad planificado de un objeto, puede invocar a la API de objeto GET o a la API de objeto HEAD. Estas API devuelven encabezados de respuesta que proporcionan información de caducidad sobre el objeto.

• Después de modificar una regla de ciclo de vida, la modificación no se aplica a los objetos que ya cumplen las condiciones configuradas. Por ejemplo, la regla de ciclo de vida original hace que los objetos que cumplen las condiciones configuradas expiren y, a continuación, se eliminen después de que se almacenen durante un día. Bajo esta regla, los objetos cargados el 1 de enero de 2021 se eliminarán el 3 de enero de 2021. El 3 de enero de 2021, si cambia la regla del ciclo de vida para eliminar objetos después de que se almacenen durante siete días, los objetos cargados el 1 de enero de 2021 se eliminarán el 3 de enero de 2021, pero esta modificación se aplicará a los cargados el 2 de enero de 2021 y después.

Reglas del ciclo de vida

Las reglas del ciclo de vida tienen los siguientes elementos clave:

• Política: configure una regla de ciclo de vida que surta efecto a los objetos especificados.
  • Por prefijo: puede especificar un prefijo de nombre de objeto, por lo que la regla de ciclo de vida tendrá efecto en los objetos que comparten el mismo prefijo.
  • Bucket completo: puede especificar un bucket completo, por lo que la regla del ciclo de vida tendrá efecto en todos los objetos del bucket.
• Hora: hora programada en la que se realiza la transición de la clase de almacenamiento de objetos
  Puede especificar el número de días después de los cuales los objetos que se han actualizado por última vez y cumplen las condiciones especificadas se pasan automáticamente a Infrequent Access o Archive, o se eliminan automáticamente al expirar.

  • Transición a Infrequent Access: puede especificar el número de días después de los cuales los objetos que se han actualizado por última vez y que cumplen las condiciones especificadas pasan automáticamente a Infrequent Access.
  • Transición al Archive: puede especificar el número de días después de los cuales los objetos que se han actualizado por última vez y que cumplen las condiciones especificadas se pasan automáticamente al Archive.
  • Transition to Deep Archive: You can specify the number of days after which objects that have been last updated and meet specified conditions are automatically transitioned to Deep Archive.
  • Eliminados al expirar: puede especificar el número de días después de los cuales los objetos que se han actualizado por última vez y que cumplen las condiciones especificadas se eliminan automáticamente.
  El tiempo de la regla del ciclo de vida tiene las siguientes restricciones:

  • Si solo se trata de una transición, el tiempo debe ser al menos un día después.
  • Si se trata de transiciones múltiples, la última transición debe ser al menos un día más que la transición anterior.

    Por ejemplo, si desea que una regla de ciclo de vida cambie la clase de almacenamiento de objetos y elimine objetos caducados, puede establecer el tiempo de transición en 23 días después y el tiempo de eliminación en al menos 24 días después.

    

    La duración mínima de almacenamiento es de 30 días para el almacenamiento de Infrequent Access y 90 días para el almacenamiento de Archive. Si los objetos se eliminan mediante una regla de ciclo de vida antes de que se hayan almacenado durante esta duración mínima, todavía tendrá que pagar durante 30 o 90 días completos.

    Supongamos que tiene un objeto en la clase de almacenamiento Estándar almacenado en un bucket y que ya no planea realizar ninguna operación en el objeto. La regla de ciclo de vida aplicada a este objeto cambia el objeto de Standard a Infrequent Access tres días más tarde, luego a Archive el cuarto día y, finalmente, elimina el objeto cuando expire siete días más tarde. En este caso, se le cobrará tres días de almacenamiento Standard, 30 días de almacenamiento Infrequent Access y 90 días de almacenamiento Archive.

Elementos de configuración del ciclo de vida

Puede establecer el formato de configuración del ciclo de vida en XML. La configuración contiene una o más reglas de ciclo de vida.

Cada regla consta de los siguientes contenidos:

• Metadatos, especificando el ID de regla y si la regla está activada o desactivada. Si la regla está deshabilitada, OBS no realiza ninguna acción definida en la regla.
• Criterios de filtrado, identificando los objetos a los que se aplican las reglas del ciclo de vida. Puede establecer el prefijo de nombre de objeto para que sea el criterio de filtrado.
• Cuándo (una fecha o un período de tiempo) se realizará una acción de transición o expiración en los objetos del ciclo de vida.

Ejemplos de configuración:

Ejemplo 1: Configuración del ciclo de vida para un bucket con el control de versiones deshabilitado

De forma predeterminada, el control de versiones está deshabilitado para los bucket. En tal caso, cada objeto en el bucket solo tiene una versión.

Supongamos que el control de versiones está deshabilitado para el bucket. Si desea que los objetos Standard cuyo nombre comienza por documents/ pasen a la clase de almacenamiento Infrequent Access 30 días después de que se carguen, a continuación, realice la transición de Infrequent Access a Archive 60 días después de que se carguen y, finalmente, se eliminen un año después de que se carguen, puede agregar la siguiente configuración de ciclo de vida para su bucket. Esta configuración incluye las acciones Transition y Expiration y se aplica a los objetos cuyo prefijo clave sea documents (especificado en el elemento Prefix).

<LifecycleConfiguration> 
    <Rule> 
        <ID>sample-rule</ID> 
        <Prefix>documents/</Prefix> 
        <Status>Enabled</Status> 
        <Expiration> 
             <Days>365</Days> 
        </Expiration> 
        <Transition>  
             <Days>30</Days> 
             <StorageClass>WARM</StorageClass>
        </Transition>  
        <Transition>  
             <Days>60</Days>  
             <StorageClass>COLD</StorageClass>  
        </Transition> 
    </Rule> 
</LifecycleConfiguration>

Ejemplo 2: Configuración del ciclo de vida de un bucket con versionado activado

Puede habilitar el control de versiones para los bucket. Si el control de versiones está habilitado para un bucket, el bucket conservará la versión de objeto actual y sus versiones de objeto no actuales. Para obtener más información, véase Control de versiones. El control de versiones le permite mantener los registros históricos de objetos y la gestión del ciclo de vida le permite controlar la retención de versiones de objetos, así como la transición de clases de almacenamiento.

Para un bucket con control de versiones habilitado, la configuración del ciclo de vida proporciona varias acciones predefinidas que se pueden utilizar para administrar versiones de objetos no actuales. En este ejemplo, la configuración del ciclo de vida tiene una regla que especifica dos operaciones NoncurrentVersionTransition y NoncurrentVersionExpiration para los objetos cuyo prefijo clave es logs/. Cuando los objetos se convierten en versiones no actuales, la acción NoncurrentVersionTransition los pasa a Infrequent Access después de 30 días y a Archive después de 60 días. La acción NoncurrentVersionExpiration elimina permanentemente los objetos 180 días después de que se conviertan en versiones no actuales.

<LifecycleConfiguration> 
    <Rule> 
        <ID>sample-rule</ID> 
        <Prefix>logs/</Prefix> 
        <Status>Enabled</Status>    
        <NoncurrentVersionExpiration>      
            <NoncurrentDays>180</NoncurrentDays>     
        </NoncurrentVersionExpiration> 
        <NoncurrentVersionTransition>  
            <NoncurrentDays>30</NoncurrentDays>  
            <StorageClass>WARM</StorageClass>  
        </NoncurrentVersionTransition>  
        <NoncurrentVersionTransition>  
            <NoncurrentDays>60</NoncurrentDays>  
            <StorageClass>COLD</StorageClass>  
        </NoncurrentVersionTransition> 
    </Rule> 
</LifecycleConfiguration>

Puede usar las acciones predefinidas de NoncurrentVersionTransition y NoncurrentVersionExpiration para gestionar las versiones no actuales en su bucket.

Por lo general, cada regla del ciclo de vida consta de las siguientes partes:

• Metadatos: especificando el ID de regla (elemento <ID>) y si la regla está habilitada o deshabilitada (elemento <Status>). Si la regla está deshabilitada, OBS no realiza ninguna acción definida en la regla.
• Prefix (elemento <Prefix>), que identifica los objetos a los que se aplica la regla.
• Acciones que desea realizar en los objetos especificados (como NoncurrentVersionTransition y NoncurrentVersionExpiration mencionados en el ejemplo anterior). Para cada acción, debe especificar una fecha o un período de tiempo.

Los elementos de la regla de configuración del ciclo de vida se describen de la siguiente manera:

• Elemento ID

  Una configuración de ciclo de vida puede tener hasta reglas de 1,000. El elemento ID identifica de forma única una regla.

• Elemento Status

  El valor puede ser Enabled o Disabled. Si una regla está deshabilitada, OBS no realiza ninguna acción definida en la regla.

• Elemento Prefix

  Una regla de ciclo de vida se aplica a uno o varios objetos con el prefijo de nombre especificado en la regla. Suponga que tenga los siguientes objetos:

  • logs/day1
  • logs/day2
  • logs/day3
  • ExampleObject.jpg

    Si establece Prefix en ExampleObject.jpg, la regla solo se aplica al ExampleObject.jpg. Si establece Prefix en logs/, la regla se aplica a los objetos cuyo nombre comience por logs/. Si deja Prefix en blanco, la regla se aplica a todos los objetos del bucket.

• Elemento Action

  Puede especificar acciones predefinidas en la regla de ciclo de vida para realizarlas en los depósitos del ciclo de vida. Las acciones predefinidas incluyen Transition, Expiration, NoncurrentVersionTransition y NoncurrentVersionExpiration. El efecto de estas operaciones depende del estado de control de versiones del bucket.

  

  De forma predeterminada, el control de versiones está deshabilitado para los bucket. Puede habilitarlo para su bucket según sea necesario, de modo que cada objeto de este bucket pueda tener una versión actual y cero o más versiones no actuales. También puede suspender el control de versiones. Para obtener más información, véase Control de versiones.

• Acción Transition

  Esta acción archiva los objetos cambiando la clase de almacenamiento de objetos a Infrequent Access. Cuando se alcanza la fecha o el período de tiempo especificado en el ciclo de vida de un objeto, la OBS realiza la transición del objeto según lo configurado.

  • Para los bucket con el control de versiones deshabilitado, la acción Transition cambia la clase de almacenamiento de objetos a Infrequent Access o Archive.
  • Para bucket con versiones activadas y suspendidas, la acción Transition cambia la clase de almacenamiento de la versión actual del objeto a Infrequent Access o Archive. Esta acción no afecta a las versiones no actuales del objeto.
• Acción Expiration

  Esta acción expira los objetos identificados en la regla. Los objetos no están disponibles una vez que caducan. Si los objetos caducados se eliminarán permanentemente depende del estado de control de versiones del bucket.

  

  La acción Expiration no elimina las cargas incompletas de varias partes.

  • Para los bucket con el control de versiones deshabilitado, la acción Expiration elimina los objetos permanentemente y los objetos eliminados no se pueden restaurar.
  • Para los bucket con control de versiones habilitado, esta acción se aplica solo a las versiones de objetos actuales, en lugar de a las versiones de objetos no actuales. Esta acción no elimina permanentemente las versiones de objetos actuales. Retiene la versión actual como una versión no actual al agregarle un marcador de eliminación. Esta acción no se realizará en las versiones de objetos actuales que ya tengan los marcadores de eliminación. Si la versión actual del objeto es la única versión del objeto y tiene un marcador de eliminación, OBS eliminará la versión actual del objeto. El borrado de un marcador de eliminación puede tardar un tiempo, ya que OBS necesita confirmar que el marcador de eliminación es la única versión del objeto.

Si inicia una solicitud GET en un objeto cuya versión actual tiene el marcador de eliminación sin especificar el ID de versión, OBS identificará el objeto como eliminado y devolverá el error 404 Object Not Found. Pero puede especificar el ID de versión en la solicitud GET para recuperar el objeto eliminado.

Por ejemplo, puede establecer una regla para que el objeto llamado photo.gif caduque 5 días después de su carga. Si photo.gif se crea a las 10:30 UTC del 1 de enero de 2016, la regla de vencimiento se ejecutará en un punto de tiempo después de las 00:00 UTC (cinco días después de la creación del objeto) del 7 de enero de 2016. La hora no será posterior a las 23:59 UTC del 7 de enero de 2016. Para un bucket con el control de versiones deshabilitado, una operación de eliminación elimina permanentemente photo.gif. Para un bucket con control de versiones habilitado, después de ejecutar la regla de caducidad, photo.gif (versión 111111) todavía se almacena en el bucket y se puede acceder si es necesario, pero la versión actual (versión 4857693) del objeto tiene un marcador de eliminación. El objeto original photo.gif se convierte en una versión no actual. Para obtener más información sobre cómo funciona un marcador de eliminación, consulte Control de versiones.

Para los bucket con versiones suspendidas, OBS creará marcadores de eliminación para objetos caducados cuyo ID de versión sea null. Cualquier versión null existente será sobrescrita por nuevas versiones null, y los datos asociados con esta versión no se pueden restaurar.

Acciones específicas para los bucket con control de versiones habilitado (o suspendido)

Las acciones del ciclo de vida de Transition y Expiration pueden administrar el ciclo de vida de las versiones de objetos actuales. Las acciones NoncurrentVersionTransition y NonCurrentVersionExpiration pueden administrar el ciclo de vida de las versiones de objetos no actuales.

Las siguientes acciones de configuración del ciclo de vida solo se pueden realizar en los bucket con control de versiones habilitado (o suspendido). En un bucket con control de versiones habilitado, un objeto puede tener varias versiones, incluida una versión actual y cero o más versiones no actuales. Puede utilizar estas acciones para solicitar a OBS que realice operaciones específicas en versiones de objetos no actuales. Estas acciones no afectan a las versiones de objetos actuales.

NoncurrentVersionTransition: especifica el período de tiempo tras el cual las versiones no actuales se transitarán desde Standard hacia Infrequent Access o Archive.

NoncurrentVersionExpiration: Especifica el período de tiempo tras el cual las versiones de objetos no actuales se eliminarán permanentemente. Los objetos eliminados no se pueden recuperar.

Por ejemplo, si desea habilitar un período de cinco días para corregir cualquier eliminación o sobrescritura accidental, puede configurar una regla de caducidad para que el objeto se pueda eliminar 5 días después de que se haya convertido en una versión no actual.

A las 10:30 (hora UTC) del 1 de enero de 2016, creó el objeto photo.gif con el ID de versión 111111. A las 10:30 (hora UTC) del 2 de enero de 2016, eliminó accidentalmente este objeto y OBS creó un marcador de eliminación con ID de versión 4857693. En los cinco días siguientes, se le permitió recuperar el objeto original photo.gif con el ID de versión 111111.

A las 00:00 (hora UTC) del 8 de enero de 2016, 5 días después de que el objeto photo.gif con ID de versión 111111 no fuera actual, la acción NoncurrentVersionExpiration eliminó permanentemente esta versión del objeto.

¿Cómo calcula la OBS el tiempo que un objeto ha dejado de ser actual?

En un bucket con control de versiones habilitado, un objeto puede tener varias versiones. Siempre hay una versión actual y cero o más versiones no actuales. Cada vez que se carga un objeto, la versión actual se guarda como una versión no actual, y la versión recién cargada (el sucesor) se convierte en la versión actual. Para determinar el número de días que una versión de objeto ha pasado a ser no actual, OBS comprueba cuándo se creó su sucesor. OBS utiliza el número de días desde que se creó su sucesor como el número de días que un objeto no ha sido actual.

Restaurar una versión no actual mediante la configuración del ciclo de vida

Puede utilizar cualquiera de los métodos siguientes para restaurar un objeto a una versión no actual:

1. Copie una versión de objeto no actual del objeto en el mismo bucket. La versión copiada se convertirá en la versión actual y todas las versiones de objeto están reservadas.
2. Eliminar permanentemente la versión actual del objeto. La eliminación de la versión actual de un objeto convierte en realidad una versión no actual en la versión actual.

Se recomienda utilizar el primer método. Debido a la sintaxis de coherencia de OBS, antes de cambiar el modo de comunicación, una versión actual que se elimina permanentemente no puede desaparecer (OBS puede no estar al tanto de esta acción de eliminación). Mientras tanto, la acción de caducidad configurada para las versiones no actuales puede eliminar permanentemente las versiones de objetos no actuales, incluidas las que desea restaurar. Por lo tanto, copiar una versión no actual, como se describe en el primer método, es más seguro.

Tabla 1 enumera la relación entre la regla de configuración del ciclo de vida y el estado de control de versiones de un bucket.

Reglas de ciclo de vida basadas en fechas

Puede especificar las fechas de ejecución de las acciones Transition y Expiration. Las fechas deben cumplir con las normas ISO 8601 y la hora exacta es siempre 00:00 (hora UTC). Si especifica la hora hasta una fecha pasada, todos los objetos aplicables se ejecutarán inmediatamente.

No se puede crear una regla de ciclo de vida basada en fechas en OBS Console.

Una acción de ciclo de vida con una fecha especificada no es una acción única. Incluso si la fecha ha pasado, OBS adoptará esta acción siempre que el ciclo de vida esté habilitado.

Suponga que haya especificado una fecha para realizar la acción Expiration para eliminar todos los objetos (sin establecer ningún criterio de filtrado). En la fecha especificada, OBS hace que todos los objetos del bucket expiren. Además, OBS continúa haciendo que todos los objetos nuevos creados en el bucket expiren. Para finalizar la acción Expiration, debe eliminar esta acción de la configuración del ciclo de vida, deshabilitar la regla o eliminarla de la configuración del ciclo de vida.

Regla de ciclo de vida basada en periodos de tiempo

Puede especificar cuántos días después de crear un objeto se realizará la acción Transition o Expiration en el objeto. Después de especificar el número de días, OBS comienza a calcular la hora a partir de las 00:00 (hora UTC) del día siguiente. Por ejemplo, creó un objeto en 15/1/2016 10:30 (hora UTC) y especificó que los objetos se cambiarían 3 días después de la creación, el objeto se transitaría en 19/1/2016 00:00 (hora UTC).

OBS solo registra la última fecha de modificación de cada objeto. En la consola OBS, puede ver la última hora de modificación (LastModified) de un objeto en la página de propiedades del objeto. Después de crear un objeto, la fecha es la fecha de creación. Si se reemplaza el objeto, la fecha también cambiará.

Al utilizar la acción NoncurrentVersionTransition o NoncurrentVersionExpiration, puede especificar después de cuántos días desde que un objeto cambie a una versión no actual (debido a sobrescribir o eliminar) se realizará la acción en el objeto.

Cuando se utilizan las operaciones NoncurrentVersionTransition y NoncurrentVersionExpiration para especificar el número de días, OBS agrega el número de días especificado en la regla al momento en que la versión del objeto se convierte en una versión no actual. A continuación, se calcula el tiempo de operación a partir de las 00:00 (hora UTC) del día siguiente. Por ejemplo, la versión actual de un objeto en un bucket se crea a las 10:30 UTC del 1 de enero de 2016. Si la versión del objeto se convierte en una versión no actual a las 10:30 UTC del 15 de enero de 2016 y especifica tres días en la regla de conversión, la fecha para cambiar la clase de almacenamiento de objetos se calcula como 00:00 UTC del 19 de enero de 2016.

Al configurar las reglas del ciclo de vida, dentro de una regla y para las reglas cuyos prefijos tienen una relación de inclusión, Date o Days de Transition y Expiration deben ser coherentes.

Cómo usarlo

Puede utilizar la consola de OBS, las API o los SDK para configurar las reglas del ciclo de vida.