What is OSS lifecycle management - Object Storage Service - Centro de documentación de Alibaba Cloud

La frecuencia de acceso a los datos disminuye con el tiempo. La gestión del ciclo de vida permite crear reglas que transfieren automáticamente los objetos a clases de almacenamiento de menor costo (como Infrequent Access o Archive) o los eliminan después de un periodo especificado, lo que reduce los costos de almacenamiento sin intervención manual.

Funcionamiento

La gestión del ciclo de vida utiliza reglas definidas por el usuario para automatizar operaciones sobre los objetos de un bucket. OSS carga una regla nueva dentro de las 24 horas posteriores a su creación. Una vez cargada, OSS ejecuta las reglas coincidentes a una hora fija diariamente, por lo general después de las 00:00 (UTC) del día siguiente (08:00 UTC+8).

Una regla de ciclo de vida consta de tres partes principales:

Objetos a gestionar: Filtre los objetos objetivo por prefijo de objeto (Prefix), etiqueta de objeto (Tag) o tamaño de objeto (ObjectSize).

Las reglas de ciclo de vida no admiten caracteres comodín, coincidencia de sufijos ni expresiones regulares.
Acciones a realizar: Defina qué hacer con los objetos filtrados:
- Transición de clase de almacenamiento (Transition): Transfiera objetos a clases de almacenamiento de menor costo, como Infrequent Access, Archive o Cold Archive.
- Vencimiento y eliminación (Expiration): Elimine objetos después de que alcancen un periodo de ciclo de vida especificado.
- Limpieza de fragmentos (AbortMultipartUpload): Elimine automáticamente las partes de cargas multiparte incompletas después de un tiempo especificado.
Políticas de activación: Defina cuándo se activan las acciones:
- Hora de última modificación (Last-Modified-Time): Transfiera o elimine objetos según la hora de la última modificación. Adecuado para datos con un ciclo de vida claro, como registros y copias de seguridad.
- Hora de último acceso (Last-Access-Time): Después de habilitar el seguimiento de acceso, transfiera objetos según la hora del último acceso. Ideal para patrones de acceso impredecibles (como una biblioteca de materiales). Los datos fríos se degradan automáticamente y se restauran al acceder a ellos.

Todos los parámetros configurables están documentados en Lifecycle configuration elements.

Escenarios de configuración

Limpieza automática de archivos de registro vencidos

Los servidores cargan registros diariamente en un directorio designado. Utilice una regla basada en la hora de última modificación para delete all objects in a bucket after a specified number of days, liberar almacenamiento y reducir costos.

Uso de niveles de almacenamiento automáticos para datos calientes y fríos

Para datos con frecuencia de acceso incierta (imágenes de sitios web, videos, documentos), habilite el seguimiento de acceso y use a lifecycle rule based on the last access time to implement intelligent data tiering. El sistema transfiere los datos fríos a clases de almacenamiento de menor costo según los patrones de acceso reales.

Limpieza automática de versiones anteriores

Con el control de versiones habilitado, las sobrescrituras y eliminaciones se guardan como versiones anteriores. Cuando un bucket acumula muchas versiones anteriores o marcadores de eliminación vencidos, use a lifecycle rule based on the last modified time together with versioning to reduce storage costs. Esto reduce costos y mejora el rendimiento del listado de objetos.

Limpieza automática de fragmentos de cargas multiparte

Las cargas multiparte interrumpidas dejan partes sin fusionar que continúan generando cargos. Configure una regla de ciclo de vida para clean up incomplete parts after a specified time.

Además de los escenarios anteriores, puede implementar políticas de gestión de datos más detalladas. Para obtener más información, consulte Lifecycle configuration examples. Puede combinar diferentes reglas para lograr una gestión detallada de los datos en su bucket según sea necesario.

Múltiples reglas de ciclo de vida

El uso de múltiples reglas de ciclo de vida se basa en dos mecanismos: la prioridad de ejecución de reglas y el mecanismo de sobrescritura de configuración.

Prioridad de ejecución de reglas

Un bucket puede tener varias reglas de ciclo de vida independientes. Cuando un objeto coincide con múltiples reglas, la acción final se determina por todos los resultados coincidentes.

Cuando varias reglas coinciden con el mismo objeto al mismo tiempo, se ejecutan en el siguiente orden de prioridad: Eliminar objeto > Transferir a Deep Cold Archive > Transferir a Cold Archive > Transferir a Archive > Transferir a Infrequent Access > Transferir a Standard.

Importante

La acción de eliminación siempre tiene mayor prioridad que las transiciones de clase de almacenamiento. Establezca el tiempo de las reglas de eliminación para que sea mayor que el de las reglas de transición. Esto evita que los objetos se eliminen antes de completar la transición.

Ejemplo de ejecución

Suponga que especifica las siguientes dos reglas de ciclo de vida y ambas coinciden con el mismo objeto.

Regla 1: Especifica que los objetos modificados por última vez hace más de 365 días se transfieren a la clase de almacenamiento Infrequent Access.
Regla 2: Especifica que los objetos modificados por última vez hace más de 365 días se eliminan.

Resultado: El objeto que coincide con las reglas se eliminará después de 365 días desde su hora de última modificación.

Mecanismo de sobrescritura de configuración

La consola gestiona la fusión automáticamente para evitar sobrescrituras accidentales. Sin embargo, al usar ossutil, SDKs o la API, cada llamada a PutBucketLifecycle sobrescribe por completo todas las configuraciones de ciclo de vida existentes. Enviar una regla nueva sin incluir las existentes elimina esas reglas.

Ejemplo

Si desea agregar una regla nueva a sus reglas existentes, realice los siguientes pasos:

Recupere todas las reglas de ciclo de vida vigentes actualmente (por ejemplo, Regla 1).
Agregue la regla nueva (por ejemplo, Regla 2).
Vuelva a enviar la configuración completa que incluye todas las reglas (Regla 1 + Regla 2).

Nota: Si envía solo la configuración que contiene la regla nueva (Regla 2) sin incluir la regla existente (Regla 1), la Regla 1 se eliminará y dejará de estar vigente.

Puesta en marcha

Para desplegar la gestión del ciclo de vida en producción de forma segura:

Pruebe antes de desplegar: Cree reglas primero en un bucket de prueba. Compruebe el comportamiento antes de aplicarlas en producción.
Use reglas de eliminación con precaución: Establezca el prefijo con precisión para evitar la eliminación accidental de datos importantes.
Habilite el control de versiones como salvaguarda: Para datos críticos, habilite el control de versiones para que los objetos eliminados accidentalmente por una regla de ciclo de vida puedan recuperarse desde una versión anterior.
Utilice transiciones escalonadas para evitar cargos adicionales: Asegúrese de que el tiempo de activación de cada etapa posterior supere la suma del tiempo de activación de la etapa anterior y su duración mínima de almacenamiento. Esto evita cargos por transiciones prematuras.
- Ejemplo incorrecto: Standard 30 days -> Infrequent Access 40 days -> Archive Storage. El objeto permanece en IA solo 10 días (< 30 days) antes de transferirse nuevamente, lo que genera un cargo.
- Ejemplo correcto: Standard 30 days -> Infrequent Access 90 days -> Archive Storage. El objeto permanece en IA durante 60 días (cumpliendo el mínimo de 30 días) antes de transferirse a Archive el día 90.

Facturación

Configurar reglas de ciclo de vida es gratuito. Se aplican tarifas cuando las reglas se ejecutan y cambian el estado de almacenamiento.

Tarifas de solicitud: Cada transición de clase de almacenamiento, eliminación de objetos o eliminación de partes genera una solicitud tipo Put. Las tarifas se cobran por solicitud. Los detalles de facturación se encuentran en Lifecycle fee description.

Para buckets con muchos archivos pequeños, las tarifas de solicitud pueden ser significativas. Evalúelas antes de configurar las reglas.
Tarifas de almacenamiento: Después de la transición, los objetos se facturan según la tarifa de la nueva clase de almacenamiento.

Importante
Las clases de almacenamiento como Infrequent Access, Archive y Cold Archive tienen requisitos de duración mínima de almacenamiento (por ejemplo, 30 días para Infrequent Access y 60 días para Archive). Si una regla de ciclo de vida elimina o transfiere un objeto antes de cumplir la duración mínima de almacenamiento, debe pagar por el tiempo de almacenamiento restante. Para evitar conditional capacity fees for storage shorter than the specified duration debido a transiciones o eliminaciones, consulte How do I avoid capacity fees for storage shorter than the specified duration?. Asegúrese de cumplir la duración mínima de almacenamiento antes de realizar la transición o eliminación.
Tarifas de recuperación de datos: Las reglas de ciclo de vida por sí mismas no generan tarifas de recuperación de datos. Sin embargo, acceder a objetos en clases de almacenamiento como Infrequent Access o Archive genera tarifas de recuperación.
- Leer un objeto IA directamente genera tarifas de recuperación de datos.
- Leer un objeto Archive genera tarifas de capacidad de recuperación de datos para acceso en tiempo real.
- Restaurar un objeto Archive genera tarifas de solicitud tipo Put y tarifas de capacidad de recuperación.
- Restaurar un objeto Cold Archive o Deep Cold Archive genera tarifas de solicitud de recuperación, tarifas de capacidad de recuperación y tarifas de capacidad restaurada temporalmente.
Importante
Para objetos Cold Archive y Deep Cold Archive, la tarifa varía según la prioridad de recuperación que elija. Una prioridad más alta resulta en una tarifa mayor.

Preguntas frecuentes

¿Cuál es la diferencia entre las reglas de ciclo de vida basadas en la hora de última modificación y la hora de último acceso?

Las diferencias clave son:

Política	Basada en la hora de última modificación	Basada en la hora de último acceso
Scenarios	Adecuado para escenarios de datos con patrones de acceso fijos o predecibles.	Adecuado para escenarios de datos con patrones de acceso variables o impredecibles.
Supports Object Deletion	Sí es compatible.	No.
Object Recovery After Deletion	Si el control de versiones no está habilitado, los objetos eliminados no se pueden recuperar. Si versioning está habilitado, cuando una regla de ciclo de vida elimina un objeto de versión actual, este se convierte en una versión anterior y puede recuperarse. Sin embargo, cuando una regla de ciclo de vida elimina un objeto de versión anterior, este no se puede recuperar.	Una política basada en la hora de último acceso no implica la recuperación de objetos tras la eliminación.
Reversibility Of Storage Class Transition	No es reversible. Después de que un objeto pasa de Standard a IA, no puede volver automáticamente a la clase anterior. Los detalles se encuentran en Transition storage class. La transición a IA, Archive, Cold Archive o Deep Cold Archive implica un tamaño mínimo facturable, una duración mínima de almacenamiento y tarifas de recuperación de datos. Los detalles se encuentran en Transition storage class.	Es reversible. Cuando un objeto se transfiere automáticamente de la clase de almacenamiento Standard a Infrequent Access, también puede elegir que regrese a la clase Standard al acceder a él. Importante Un objeto se considera "accedido" solo cuando se accede a través de una llamada a la API GetObject. Otras llamadas a la API no se incluyen. Esto también implica un tamaño mínimo facturable, una duración mínima de almacenamiento y tarifas de recuperación de datos. Los detalles se encuentran en Lifecycle rules based on last access time.

¿Por qué mi regla de ciclo de vida no funciona?

Compruebe los siguientes elementos:

Tiempo de vigencia: ¿La regla se creó hace más de 24 horas? Las reglas nuevas necesitan tiempo para cargarse.
Coincidencia de prefijos: ¿El prefijo en la regla está establecido correctamente? Por ejemplo, una carpeta debe ser logs/ en lugar de logs.
Condición de tiempo: ¿La hora de última modificación o de último acceso del objeto realmente cumple con el número de días especificado?
Función prerequisite: Si utiliza una regla basada en la hora de último acceso, ¿habilitó la función de seguimiento de acceso para el bucket?

Después de habilitar el control de versiones, eliminé un objeto. ¿Por qué no disminuyó mi uso de almacenamiento?

Con el control de versiones habilitado, una operación de eliminación solo crea un marcador de eliminación. El objeto original se convierte en una versión anterior y continúa ocupando espacio. Cree una regla de ciclo de vida para limpiar las versiones anteriores.

¿Se restaurarán los objetos convertidos si elimino la regla de ciclo de vida?

No. Eliminar una regla no revierte las acciones ya ejecutadas. Restaure manualmente los objetos convertidos a su clase de almacenamiento original.

¿Por qué un objeto eliminado sigue ocupando espacio después de habilitar el control de versiones?

Con el control de versiones habilitado, una operación de eliminación crea un marcador de eliminación. El objeto original se convierte en una versión anterior y continúa ocupando espacio. Configure una regla para eliminar versiones anteriores.

¿Qué debo hacer si recibo el error Set bucket lifecycle error, InvalidArgument, Days in the Transition action for StorageClass Archive must be more than the Transition action for StorageClass IA?

Este error ocurre porque los tiempos de transición para diferentes clases de almacenamiento no cumplen con los requisitos. El periodo de transición configurado para el bucket debe satisfacer: Infrequent Access < Archive < Cold Archive < Deep Cold Archive.

¿La función de ciclo de vida de OSS puede realizar acciones de nivelación o eliminación de datos mediante la coincidencia de sufijos de archivo?

Las reglas de ciclo de vida no admiten coincidencia de sufijos (como .png). Utilice las siguientes soluciones alternativas:

Método 1: Almacenar objetos mediante un prefijo específico

Almacene objetos con un sufijo específico (como archivos .png) en un directorio dedicado con un prefijo como images/. Luego configure una regla de ciclo de vida que coincida con el prefijo images/.

Método 2: Usar etiquetas de objeto

Agregue una etiqueta (como image:png) a todos los archivos .png, luego configure la regla de ciclo de vida para que coincida por etiqueta. Para obtener más información, consulte Tag objects.

¿Las reglas de ciclo de vida se aplican a los objetos existentes en un bucket?

Una regla de ciclo de vida se aplica a todos los objetos, incluidos aquellos cargados antes de configurar la regla. Por ejemplo, si una regla configurada el 7 de octubre elimina objetos después de 30 días, un objeto cargado el 5 de octubre se elimina el 6 de noviembre, y un objeto cargado el 8 de octubre se elimina el 9 de noviembre.

¿Cómo modifico una o más configuraciones de reglas de ciclo de vida?

Suponga que su bucket tiene dos reglas de ciclo de vida (Rule1 y Rule2) y desea modificar Rule1:

Llame a GetBucketLifecycle para recuperar todas las reglas de ciclo de vida actuales (Rule1 y Rule2).
Modifique el elemento de configuración de la regla de ciclo de vida Rule1.
Llame a PutBucketLifecycle para enviar las reglas actualizadas (Rule1 + Rule2).

¿Existen registros para las transiciones de tipo y eliminaciones por vencimiento realizadas por las reglas de ciclo de vida?

Sí. Todas las transiciones de tipo exitosas y las eliminaciones por vencimiento realizadas por las reglas de ciclo de vida se registran. Los campos del registro son los siguientes:

Operación
- CommitTransition: Transfiere la clase de almacenamiento.
- ExpireObject: Elimina un objeto vencido.
Solicitud de sincronización

lifecycle: Las operaciones de transición y eliminación que se activaron.

Los campos de registro de OSS están documentados en Log field details. La facturación de consultas de registros se trata en Billing.

¿Puedo crear una sola regla de ciclo de vida para limpiar tanto los marcadores de eliminación de objetos como los objetos de versión actual al mismo tiempo?

No, no es posible. Debe crear una regla para limpiar los marcadores de eliminación de objetos y otra regla para eliminar los objetos de versión actual.

Cómo limpiar rápidamente todos los archivos de un bucket mediante reglas de ciclo de vida

Bucket con control de versiones deshabilitado

Para un bucket con control de versiones deshabilitado, solo necesita configurar una regla de ciclo de vida para limpiar automática y rápidamente todos los archivos y partes de cargas multiparte incompletas.

Inicie sesión en la consola de OSS, vaya a la página Bucket List y localice el bucket objetivo.
En el panel de navegación izquierdo, elija Data Security > Versioning y confirme que el control de versiones está deshabilitado para el bucket.
En el panel de navegación izquierdo, elija Data Management > Lifecycle. Establezca una regla de ciclo de vida para eliminar automáticamente todos los archivos del bucket 1 día después de su última modificación. Además, limpie automáticamente las partes de cargas multiparte incompletas creadas hace más de 1 día.

Bucket con control de versiones habilitado

Después de habilitar el control de versiones para un bucket, este genera objetos de versión actual, objetos de versión anterior, partes de cargas multiparte incompletas y marcadores de eliminación. Solo necesita configurar una regla de ciclo de vida para limpiar automática y rápidamente todos estos elementos.

Inicie sesión en la consola de OSS, vaya a la página Bucket List y localice el bucket objetivo.
En el panel de navegación izquierdo, elija Data Security > Versioning y confirme que el control de versiones está habilitado para el bucket.
En el panel de navegación izquierdo, elija Data Management > Lifecycle. Establezca una regla de ciclo de vida para eliminar automáticamente todos los objetos de versión actual y anterior del bucket 1 día después de su última modificación. Además, limpie automáticamente las partes de cargas multiparte incompletas creadas hace más de 1 día. Esta regla también limpia los marcadores de eliminación.

Si creo dos reglas de ciclo de vida para objetos con el mismo prefijo, una basada en la hora de última modificación y la otra en la hora de último acceso, ¿qué regla se aplica?

Por ejemplo, crea dos reglas de ciclo de vida para el bucket objetivo examplebucket. La Regla 1 especifica que todos los objetos con el prefijo doc en el bucket se eliminan 30 días después de su hora de última modificación. La Regla 2 especifica que todos los objetos con el prefijo doc en el bucket se transfieren a la clase de almacenamiento Infrequent Access 30 días después de su hora de último acceso.

OSS ejecuta las reglas de ciclo de vida basándose en el principio de minimizar los costos del usuario. Por lo tanto, solo la Regla 1 surte efecto. Esto se debe a que la Regla 1 elimina los objetos después de 30 días, lo que detiene la generación de cualquier tarifa. En cambio, la Regla 2, que transfiere objetos a la clase de almacenamiento Infrequent Access, seguiría generando tarifas relacionadas con el almacenamiento o la recuperación de datos.

¿Cuándo surte efecto un cambio en una regla de ciclo de vida configurada y cómo se manejan los datos coincidentes con la regla original?

Por ejemplo, configura una regla de ciclo de vida para objetos con el prefijo er. Esta regla transfiere los objetos a la clase de almacenamiento Infrequent Access 30 días después de su hora de último acceso, y luego los devuelve a la clase de almacenamiento Standard si se accede a ellos nuevamente después de 30 días adicionales. Sin embargo, 35 días después de la hora de último acceso de un objeto, cambia el prefijo en la regla de ciclo de vida de er a re. Como resultado, el objeto se transfiere a la clase de almacenamiento Infrequent Access, pero la acción para devolverlo a la clase de almacenamiento Standard no surte efecto. Para los objetos que coinciden con la regla actualizada, su hora de último acceso se calcula desde el momento en que se habilitó el seguimiento de acceso para el bucket.

En un bucket con control de versiones habilitado, ¿cómo afecta la nivelación inteligente a las clases de almacenamiento de las diferentes versiones de objetos?

En un bucket con control de versiones habilitado, cada versión de objeto tiene un ID de versión único y se trata como un objeto independiente. Por lo tanto, una versión anterior de un objeto podría estar en la clase de almacenamiento Infrequent Access, mientras que la versión actual del mismo objeto está en la clase de almacenamiento Standard.