expirer: account and container level delay_reaping

Code Issues Proposed changes

The object expirer can be configured to delay the reaping of
objects from disk after their expiration time using account
and container level delay_reaping values. The delay_reaping
value of accounts and containers in seconds is configured in
the object server config. The object expirer references these
configured values to only reap objects from specified accounts
and containers after their corresponding delays.
The goal of the delay_reaping feature is to prevent accidental or
premature data loss if an object marked for deletion with the
'x-delete-at' feature should not be reaped immediately, for
whatever reason.
Configuring the delay_reaping value at a granular account and
container level is beneficial for being able to keep storage
capacity consumption in control while maintaining a desired
data recovery window.
This patch also adds a sample configuration, documentation, and
tests for bad configurations and grace period functionality.
Co-Authored-By: Anish Kachinthaya <akachinthaya@nvidia.com>
Change-Id: I106103438c4162a561486ac73a09436e998ae1f0

This commit is contained in:

Mandell Degerness

2023年02月22日 12:14:05 -08:00

committed by Anish Kachinthaya

parent b6dc24dbc0

commit 5961ba0ca7

6 changed files with 605 additions and 5 deletions

Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL

Download Patch File Download Diff File Expand all files Collapse all files

15
doc/source/config/object_server_config.rst

View File

@@ -746,4 +746,19 @@ ionice_priority None I/O scheduling pri

priority of the process. Work only with

ionice_class.

Ignored if IOPRIO_CLASS_IDLE is set.

delay_reaping_<ACCT> 0.0 A dynamic configuration option for

setting account level delay_reaping values.

The delay_reaping value is configured for

the account with the name placed in

<ACCT>. The object expirer will reap objects in

this account from disk only after this delay

following their x-delete-at time.

delay_reaping_<ACCT>/<CNTR> 0.0 A dynamic configuration option for

setting container level delay_reaping values.

The delay_reaping value is configured for

the container with the account name placed

in <ACCT> and the container name in <CNTR>.

The object expirer will reap objects in this

container from disk only after this delay

following their x-delete-at time.

============================= =============================== ==========================================

43
doc/source/overview_expiring_objects.rst

View File

@@ -55,6 +55,49 @@ it will then look for and use the ``/etc/swift/object-expirer.conf`` config.

The latter config file is considered deprecated and is searched for to aid

in cluster upgrades.

Delay Reaping of Objects from Disk

----------------------------------

Swift's expiring object ``x-delete-at`` feature can be used to have the cluster

reap user's objects automatically from disk on their behalf when they no longer

want them stored in their account. In some cases it may be necessary to

"intervene" in the expected expiration process to prevent accidental or

premature data loss if an object marked for expiration should NOT be deleted

immediately when it expires for whatever reason. In these cases

``swift-object-expirer`` offers configuration of a ``delay_reaping`` value

on accounts and containers, which provides a delay between when an object

is marked for deletion, or expired, and when it is actually reaped from disk.

When this is set in the object expirer config the object expirer leaves expired

objects on disk (and in container listings) for the ``delay_reaping`` time.

After this delay has passed objects will be reaped as normal.

The ``delay_reaping`` value can be set either at an account level or a

container level. When set at an account level, the object expirer will

only reap objects within the account after the delay. A container level

``delay_reaping`` works similarly for containers and overrides an account

level ``delay_reaping`` value.

The ``delay_reaping`` values are set in the ``[object-expirer]`` section in

either the object-server or object-expirer config files. They are configured

with dynamic config option names prefixed with ``delay_reaping_<ACCT>``

at the account level and ``delay_reaping_<ACCT>/<CNTR>`` at the container

level, with the ``delay_reaping`` value in seconds.

Here is an example of ``delay_reaping`` configs in the``object-expirer``

section in the ``object-server.conf``::

[object-expirer]

delay_reaping_AUTH_test = 300.0

delay_reaping_AUTH_test2 = 86400.0

delay_reaping_AUTH_test/test = 0.0

delay_reaping_AUTH_test/test2 = 600.0

.. note::

A container level ``delay_reaping`` value does not require an account level

``delay_reaping`` value but overrides the account level value for the same

account if it exists. By default, no ``delay_reaping`` value is configured

for any accounts or containers.

Upgrading impact: General Task Queue vs Legacy Queue

----------------------------------------------------