Spec Lite: 限制每个共享允许的副本数量¶
- 问题:
目前,Manila 允许创建给定共享的无限数量的共享副本。这对于
DHSS=True和DHSS=False模式都是一个问题。它允许用户耗尽存储资源,并根据配置的后端遇到问题。在用户可见性方面,关于哪些后端支持或不支持也存在问题。某些后端不支持超过有限数量的共享副本,并且在后端异步拒绝操作之前无法注意到。- 解决方案:
我们应该让管理员根据后端容量指定给定共享能够拥有的最大副本数量。 这样,API 能够在新的副本创建请求期间检查现有共享副本的数量,并能够更快、同步地失败。 建议的解决方案是在共享类型中添加一个新的额外规范,称为
max_replicas_per_share。 然后,在创建共享副本时,Manila 将检查源共享的共享类型的max_replicas_per_share值,并验证源共享的现有副本数量。 如果现有共享副本的数量已经达到max_replicas_per_share值,则创建新副本的请求将被拒绝。 在为共享类型创建新的额外规范时,管理员必须指定一个整数值。 将创建一个数据库迁移,以便为所有现有的共享类型添加新的共享类型额外规范。 在数据库迁移中,将设置默认值为两个副本,因为某些后端的容量限制。 所有管理员都需要根据其后端容量更新共享类型,并根据给定共享类型下创建的共享能够拥有的副本数量设置额外规范。 在创建新的共享类型时,如果用户没有指定新的额外规范,则服务将自动将此值设置为2,并且如果管理员需要更改该值,则需要更新额外规范。 管理员还可以为每个后端提供一个新的后端属性,称为supported_replicas_per_share。 将改进调度器,以便考虑此后端属性来过滤后端。 此解决方案可以与改进结合使用,包括使用现有的配额系统为共享副本定义项目配额,并允许管理员为max_replicas_per_share额外规范设置默认值。 因此,最终整个解决方案将有一种避免此错误的方法,以及将帮助管理员管理其资源的一种改进。 该错误的解决方案需要管理员干预,因为数据库迁移脚本将使用默认值更新所有共享类型,并且在迁移数据库后,用户在创建新的共享副本时可能会被阻止。 目前无法设置如本规范中建议的每个共享的副本限制,但自 Ussuri 版本发布以来,Manila 项目配额控制可以应用于共享副本。- 影响:
- REST API 影响。
在创建共享副本时,如果共享已经达到允许的共享副本数量,API 将返回
403 Forbidden,并显示以下消息:“共享 ID 为 ‘share_id’ 的共享已达到其共享类型的副本限制”。API 在设置
max_replicas_per_share额外规范时,将期望一个整数值,否则将返回400 BadRequest,并显示以下消息:“指定的最大副本值 ‘non_integer_value’ 必须是大于或等于 2 的整数”。
- 文档影响
管理员指南
API 参考
- 时间线:
包含在 Ussuri 版本中。
- 链接:
https://blueprints.launchpad.net/manila/+spec/limit-share-replicas-per-share
- 负责人:
carloss