过期对象支持

swift-object-expirer 提供对象的定时删除功能。Swift 客户端在对象 PUT 或 POST 期间会使用 X-Delete-At 或 X-Delete-After 头部，集群将在指定时间自动停止提供该对象，并在此后不久将该对象从系统中删除。

X-Delete-At 头部接受 Unix Epoch 时间戳，以整数形式；例如：1317070737 表示 Mon Sep 26 20:58:57 2011 UTC。

X-Delete-After 头部接受一个正整数秒数。接收请求的代理服务器将使用请求时间戳加上给定值，将此头部转换为 X-Delete-At 头部。

如果请求中同时发送了 X-Delete-At 和 X-Delete-After 头部，则 X-Delete-After 头部将优先。

当过期对象添加到系统时，对象服务器将在一个隐藏的 .expiring_objects 账户中记录过期信息，供 swift-object-expirer 稍后处理。

通常，集群只需运行一个 swift-object-expirer 守护进程实例。这并不是完全自动故障转移的高可用性，但如果此守护进程几个小时不运行，应该不是真正的问题。已过期但尚未删除的对象在有人尝试 GET 或 HEAD 它们时仍将返回 404 Not Found，并且在守护进程重新启动后稍晚才会被删除。

默认情况下，swift-object-expirer 守护进程将以 1 的并发数运行。增加此值以获得更高的并发数。对于特定的 Swift 集群，1 的并发数可能不足以及时删除过期对象。

如果单个进程的并发数大于 1 仍不足以完成工作，则可以运行多个守护进程来完成不同的工作部分（详见示例配置文件）。

要将 swift-object-expirer 作为多个进程运行，请将 processes 设置为进程数（可在配置文件中或命令行中设置）。然后为每个部分运行一个进程。使用 process 通过命令行或配置指定进程要完成的工作部分。因此，例如，如果您想运行三个进程，请将 processes 设置为 3，并为这三个进程运行三个进程，其中 process 分别设置为 0、1 和 2。如果使用多个进程，则必须为工作的每个部分运行一个进程，否则该部分工作将无法完成。

默认情况下，守护进程会查找两个不同的配置文件。启动时，进程会在

/etc/swift/object-server.conf 配置中查找 [object-expirer] 部分。如果该部分或配置缺失，它将查找并使用 /etc/swift/object-expirer.conf 配置。后者配置文件被视为已弃用，之所以查找它是为了辅助集群升级。

延迟从磁盘回收对象

Swift 的过期对象 x-delete-at 功能可用于在用户不再希望将对象存储在其帐户中时，让集群自动从磁盘上回收用户的对象。在某些情况下，如果一个标记为过期的对象因某种原因不应在过期时立即删除，可能需要“干预”预期的过期过程以防止意外或过早的数据丢失。在这些情况下，swift-object-expirer 提供在账户和容器上配置 delay_reaping 值，这提供了一个延迟，介于对象被标记为删除或过期与实际从磁盘回收之间。当在对象过期器配置中设置此值时，对象过期器会将过期对象保留在磁盘上（和容器列表中）一段 delay_reaping 时间。在此延迟时间过后，对象将照常回收。

delay_reaping 值可以在账户级别或容器级别设置。当在账户级别设置时，对象过期器只会在延迟之后回收账户内的对象。容器级别的 delay_reaping 对容器同样有效，并会覆盖账户级别的 delay_reaping 值。

delay_reaping 值在对象服务器或对象过期器配置文件的 [object-expirer] 部分中设置。它们通过以 delay_reaping_<ACCT> 为前缀的动态配置选项名称在账户级别进行配置，以及以 delay_reaping_<ACCT>/<CNTR> 为前缀的动态配置选项名称在容器级别进行配置，delay_reaping 值为秒数。

以下是 object-server.conf 中 ``object-expirer`` 部分的 delay_reaping 配置示例：

[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

注意

容器级别的 delay_reaping 值不需要账户级别的 delay_reaping 值，但如果存在，则会覆盖同一账户的账户级别值。默认情况下，未为任何账户或容器配置 delay_reaping 值。

过期后访问对象

默认情况下，过期对象将无法访问，即使是账户所有者也无法访问。对象可能尚未删除，但在 x-delete-at 时间戳过后，任何针对该对象的 GET/HEAD/POST 客户端请求都将响应 404 Not Found。

swift-proxy-server 提供了全局配置一个标志的能力，以允许请求访问尚未删除的过期对象。当启用此标志时，用户可以通过将 x-open-expired 头部设置为 true 来发出 GET、HEAD 或 POST 请求，以访问过期对象。

全局配置是一个可选标志，可以在 proxy-server.conf 文件的 [proxy-server] 部分中设置。它使用一个名为 allow_open_expired 的标志进行配置，可设置为 true 或 false。默认情况下，此标志设置为 false。

以下是 proxy-server.conf 中 proxy-server 部分的一个示例

[proxy-server]
allow_open_expired = false

要检测此标志是否已设置，您可以向 /info 可发现性 路径发送 GET 请求。这将以 JSON 格式返回配置数据，其中 allow_open_expired 的值将公开。

使用临时 URL 访问对象时，此功能未启用。这意味着添加此头部将不允许通过临时 URL 的请求访问过期对象。

升级影响：通用任务队列与旧版队列

过期器守护进程将迁移到基于新通用任务队列的设计，该设计将工作分配给所有对象服务器，因此只有在对象服务器配置中定义的过期器才能使用新系统。

旧版对象过期器配置记录在 etc/object-expirer.conf-sample 中。备用对象服务器配置部分记录在 etc/object-server.conf-sample 中。

两个文件中的参数除了对象服务器 [object-expirer] 部分中的一个新选项 dequeue_from_legacy 之外是相同的，当设置为 True 时，它将告知过期器除了使用新任务队列系统外，还要检查旧版（即将弃用）队列。

注意

新的任务队列系统尚未完成。因此，将 dequeue_from_legacy 设置为 False 的过期器目前将不执行任何操作。

默认情况下，dequeue_from_legacy 将为 False，在从旧的过期队列迁移时，需要将其显式设置为 True。

任何使用旧配置 /etc/swift/object-expirer.conf 的过期器都不会使用新的通用任务队列。它会忽略 dequeue_from_legacy 并且只会检查旧版队列。这意味着它将作为旧版过期器运行。

为什么这很重要？如果您目前在非对象存储节点上运行对象过期器，那么暂时它们仍然会工作，但仅通过从旧队列中出队。当引入新的通用任务队列时，过期器将被要求在对象服务器上运行，以便可以删除任何新添加的对象。如果您处于这种情况，您可以安全地在 object-server.conf 中设置新的过期器部分来处理新队列，并让旧版过期器在其他地方运行。

但是，如果您的旧过期器在对象服务器上运行，这是最常见的拓扑结构，那么您将把新部分添加到所有对象服务器，以处理新队列。为了保持检查旧版队列的过期器数量不变，选择与您之前相同数量的节点，并仅在这些节点上启用 dequeue_from_legacy。另请注意，在这些节点上，您需要保留旧版的 process 和 processes 选项，以保持旧版队列的并发级别。

注意

请注意不要在过多的过期器上启用 dequeue_from_legacy，因为所有旧版任务都存储在单个隐藏帐户和相同的隐藏容器中。在一个大型集群中，可能会无意中使处理旧版过期器队列的帐户/容器服务器过载。

注意

运行旧版过期器时，守护进程需要在能够访问集群中所有后端服务器的机器上运行，但不需要代理服务器或公共访问。守护进程将使用其自身的内部代理代码实例来访问后端服务器。