支持 RBD 驱动中的延迟卷删除¶
https://blueprints.launchpad.net/cinder/+spec/rbd-deferred-volume-deletion
本文档提出在 RBD 驱动中配置化支持延迟卷删除，使用 Luminous 版本的 Ceph 中引入的 trash_* API 调用。
问题描述¶
Cinder 中的卷删除是同步的：删除卷的 c-vol worker 线程只有在后端确认删除卷后才会返回。这种方法确保后端使用的空间最多等于相应项目的配额，从而实现适当的资源管理。RBD 驱动的当前实现通过使用 RBD 的 ‘remove()’ API 调用来遵循这种方法。
对于拥有数千个卷/用户和大型卷（10-100TB）的部署，这可能会产生两个潜在问题
c-vol worker 线程将在删除期间被阻塞，并且根据卷的大小、后端的速度、并发请求的数量以及 worker 线程的总数，这可能会阻塞其他操作，使服务看起来无响应，并导致超时。
为了缓解这个问题，[1] 建议通过配置化原生线程的数量并更有效地利用后端的潜在能力来解决这个问题。
用户必须等到后端完成删除后才能重新使用释放的配额/空间——尽管他们已经向 Cinder 发出了信号，表明应该删除该卷并释放配额。对于大型卷，这种等待时间可能很长（大型卷需要数小时），因此对用户体验产生相应的负面影响。
为了解决这些问题，本文档提出在 RBD 驱动中可选地支持异步卷删除。
用例¶
管理员可以选择启用延迟删除：Ceph 后端将立即确认删除，从而解决上述两个问题。
提议的变更¶
建议如下
修改 RBD 驱动以支持延迟删除，通过在驱动程序的 ‘delete_volume()’ 实现中可选地调用 RBD 的 ‘trash_move()’ 而不是 RBD 的 ‘remove()’；
在 RBD 驱动中添加一个定期定时器，以触发定期的清理。
为此，需要以下额外的配置选项
- ‘enable_deferred_deletion’ (默认: ‘False’)
如果启用，将调用 RBD 的 ‘trash_move’ 而不是 ‘remove’。
- ‘deferred_deletion_delay’ (默认: 0)
移动到 trash 的镜像被视为过期并可以被清理之前的时间（秒）。
- ‘deferred_deletion_purge_interval’ (默认: 3600)
定期定时器运行之间清理后端 trash 的间隔时间（秒）。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
无。
Cinder 客户端影响¶
无。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
对于最终用户，删除将显得是即时的。释放的配额将立即可用。
性能影响¶
卷删除将独立于后端的速度或卷的大小。
其他部署者影响¶
由于删除是延迟的，因此占用的空间不会立即释放。部署者需要注意，所需的最大空间可能会超过所有项目的已分配配额之和。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Arne Wiebalck (arne.wiebalck@cern.ch)
工作项¶
更新 RBD 驱动以尊重延迟删除的选项，并在启用时调用 ‘trash_move’。
添加定期任务以调用 ‘trash_purge’，用于启用延迟删除的后端。
添加相关的单元测试用例。
依赖项¶
无
测试¶
添加单元测试以涵盖此更改。
文档影响¶
添加管理员文档，以宣传 RBD 的延迟删除选项，并解释应该使用此选项的原因、时间和方式，尤其强调通过启用此选项，删除的卷的空间不会在 RBD 后端释放，直到 trash 被清理为止。
