Workflow

The high-level workflow of Object Expiration is detailed in the following bullet items.

• User configures Object Expiration on a storage pool and then on the vaults on that storage pool.
• User adds lifecycle policies to any or all buckets that have expiration that is enabled.
• Each day, at midnight Coordinated Universal Time, the scanning services and the reclamation service begin scanning for objects to be deleted. These services run on each access pool that has an expiration-enabled vault that is deployed to it. The background work is shared between all Accesser devices in a pool.
  • The scanning services find objects to delete the following day. These services update a queue of object to reclaim that is evaluated by the reclamation service the following day. The services also communicate among themselves by updating queues that the following service reads.
    • The lifecycle-container-listing service (only in container mode) lists all containers that have a lifecycle policy and passes these operations to the container-scanning-range-service.
    • The container-scanning-range-service or vault-scanning-range-service (in container mode or vault mode respectively) divides the objects in each bucket to smaller ranges and passes these ranges to the lifecycle-name-index-scan service.
    • The lifecycle-name-index-scan service reads the objects in each scanning range and puts the objects that, according to the bucket’s lifecycle policy, must be deleted the following day into the reclamation queue.
  • The reclamation service deletes objects that are due to expire on the current day. The service reads objects in the reclamation queue that were found the previous day, reevaluates the policy to make sure they’re still eligible for deletion, and then deletes them.