Gestión del ciclo de vida

Escenario de la aplicación

Puede definir las reglas de ciclo de vida para identificar objetos y gestionar los ciclos de vida de los objetos basándose en las reglas.

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. Si el control de versiones está habilitado para un bucket, el bucket mantendrá la versión de objeto actual y cero o más versiones de objeto no actuales. Puede reducir los costos de almacenamiento de objetos mediante reglas de control de versiones y de ciclo de vida. 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.
• La duración mínima de almacenamiento del almacenamiento de Archive es de 90 días. Después de la transición, si el período de almacenamiento del objeto Archive es más corto que la duración mínima de almacenamiento, deberá pagar los días restantes.
• Restricciones en la transición de clase de almacenamiento:
  • Las reglas de ciclo de vida sólo pueden hacer la transición de objetos de la clase de almacenamiento Standard a la clase de almacenamiento Infrequent Access. Se requieren operaciones manuales para realizar la transición de objetos de la clase de almacenamiento Infrequent Access a la clase de almacenamiento Standard.
  • Los objetos sólo se pueden pasar de la clase de almacenamiento Standard o Infrequent Access a la clase de almacenamiento Archive. Si desea realizar la transición de objetos de la clase de almacenamiento Archive a la clase de almacenamiento Standard o Infrequent Access, primero debe restaurar objetos de la clase de almacenamiento Archive y, a continuación, realizar la transición manual de la clase de almacenamiento.
• Supresión de objetos al expirar:

  OBS proporciona la acción Expiration que le permite establecer el tiempo de expiración para los objetos. Además, para los bucket con control de versiones habilitado, OBS proporciona la operación NoncurrentVersionExpiration que le permite establecer el tiempo de caducidad para las versiones de objetos no actuales.

  • Para los bucket con el control de versiones deshabilitado, la acción Expiration permite eliminar los objetos caducados de forma permanente.
  • Si el control de versiones está habilitado (o suspendido) para un bucket, la acción Expiration eliminará lógicamente la versión actual de un objeto creando un marcador de eliminación para la versión actual y reconociendo el marcador de eliminación como la nueva versión actual. La acción NoncurrentVersionExpiration elimina objetos de versiones no actuales de forma permanente.
• 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 llamar 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 recientemente y cumplen las condiciones especificadas se transfieren automáticamente a la clase de acceso infrecuente o de archivo; o los que han vencido, se eliminan automáticamente.

  • 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.
  • 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.

    

    El período mínimo de facturación es de 30 días para el almacenamiento de Infrequent Access y de 90 días para el almacenamiento de archivos. Si los objetos se eliminan mediante una regla de ciclo de vida antes de que se hayan almacenado durante este período mínimo, se le cobrará el período completo (30 o 90 días, según el servicio).

    Ejemplo: se carga un objeto a la clase de almacenamiento Standard y no se realiza ninguna otra operación en el objeto. El bucket, donde reside el objeto, tiene una regla de ciclo de vida que cambiará la clase de almacenamiento de objetos desde Standard hacia lla de Infrequent Access tres días más tarde, luego de Infrequent Access a Archive y, finalmente, eliminará los objetos a medida que caduquen 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 las acciones especificadas 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 de un bucket con el control de versiones deshabilitado

De forma predeterminada, el control de versiones está deshabilitado para los bucket. Cada objeto tiene una sola versión.

Supongamos que el control de versiones está deshabilitado para el bucket y que desea que los objetos cuyo nombre comience con documents/ pasen de la clase de almacenamiento Standard a la clase de almacenamiento Infrequent Access 30 días después de que se hayan cargado, luego de la clase de almacenamiento Infrequent Access a la clase de almacenamiento de archivo 60 días después de que se cargan, y finalmente se eliminan un año después de que se cargan. Para lograr esto, puede agregar la siguiente configuración de ciclo de vida para su bucket. Esta regla del ciclo de vida incluye dos operaciones (Transition y Expiration). Esta regla se aplica a los objetos cuyo prefijo clave es 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 control de versiones habilitado

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 más detalles, consulte 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 las acciones especificadas 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). Cada acción incluye la fecha en que o período de tiempo después del cual se realizará la acción.

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 un máximo de 1000 reglas. Cada regla tiene el ID único.

• 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 sólo 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 nulo, 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 acción depende del estado del control de versiones de un bucket.

  

  De forma predeterminada, el control de versiones está deshabilitado para los bucket. Puede habilitar el control de versiones de bucket, de modo que cada objeto tenga una versión actual y pueda tener una o más versiones no actuales. Además, puede deshabilitar el control de versiones. Para más detalles, consulte Control de versiones.

• Acción Transition

  Esta acción archiva los objetos cambiando la clase de almacenamiento de objetos a Infrequent Access o Archive. Cuando llega la fecha o el período de tiempo especificado, el sistema cambia la clase de almacenamiento de objetos a Infrequent Access o Archive.

  • 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 los bucket con el control de versiones habilitado y suspendido, la acción Transition cambia la clase de almacenamiento de la versión de objeto actual a Infrequent Access o Archive. Esta acción no afecta a las versiones de objetos no actuales.
• Acción Expiration

  Esta acción establece el tiempo en que caducan los objetos. 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 eliminará las partes cargadas de una carga de varias partes incompleta.

  • 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, consulteControl 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 sólo 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, incluyendo 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. No se puede restaurar un objeto eliminado.

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.

En 1/1/2016 10:30 (hora UTC), creó un objeto llamado photo.gif cuyo ID de versión es 111111. En 2/1/2016 10:30 (hora UTC), eliminó accidentalmente este objeto y OBS creó un marcador de eliminación para este objeto con un nuevo ID de versión, 4857693. En los próximos cinco días, se le permitió restaurar el objeto original photo.gif cuyo ID de versión es 111111.

En 8/1/2016 00:00 (hora UTC), la acción NoncurrentVersionExpiration eliminó permanentemente el objeto photo.gif cuyo ID de versión es 111111 (después de que se convirtió en una versión no actual durante 5 días.)

¿Cómo verifica OBS durante cuánto tiempo un objeto se ha convertido en una versión no actual?

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. Cada vez que se carga un objeto, la versión actual existente se guarda como una versión no actual, mientras que la versión cargada se convierte en la versión actual. Para comprobar los días en que una versión de objeto se ha convertido en una versión no actual, OBS comprueba la hora de creación del objeto correspondiente de la versión actual. OBS utiliza los días en que el objeto de la versión actual ha sido creado como los días en que el objeto de una versión no actual ha existido.

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 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. Elimine la versión de objeto actual de forma permanente. Después de eliminar la versión actual de un objeto, una versión no actual del objeto se convierte en la versión actual.

Se recomienda utilizar el primer método para copiar la versión de objeto no actual en el mismo bucket. 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). Además, la acción de caducidad para las versiones no actuales, si ha configurado, puede eliminar las versiones de objetos no actuales de forma permanente, incluidas las que desea restaurar. Por lo tanto, el método de copiar una versión no actual es más seguro.

Tabla 1enumera 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 sólo 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 usar esta función?

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