Enforced bucket-level quotas in the Ceph Object Gateway¶

Summary¶

It should be possible for a service provider to impose size quotas on each bucket, and prevent puts that would push that bucket over its allowed size.
There is probably also demand for a user-level quota mechanism (all buckets owned by a user), but that would be built on top of bucket-level quotas and will be the subject of a distinct proposal.

Owners¶

• Yehuda Sadeh (Inktank)

Interested Parties¶

• Li Wang
• Loic Dachary
• Christophe Courtaut christophe.courtaut@gmail.com
• Wido den Hollander (42on)

Current Status¶

Initial requirments and design proposals

Detailed Description¶

We still need to validate detailed requirements, but this is an outline of the sort of feature we are contemplating and how it could be implemented within the current gateway (based on the existing OSD-based bucket size tracking).
The key architectural issue:
Requests can come in through one of many gateways. To simplify, optimize, and ensure accurate record keeping, bucket size is maintained by the OSDs. Because one gateway does not know what others are doing, strong and accurate quota enforcement would require a per-put check ... which is a level of overhead we would like to avoid.
Add the following new attributes to each bucket:

• integer: quota (size to which this bucket is allowed to grow
• boolean: enable quota enforcement
• boolean[]: allow get, put, delete, list operations
• integer: soft limit (size above which all writes should be verified)
• integer: estimate time-to-live (seconds after which estimates should be refreshed)

On each put operation:

Look at the cached current access mask and see if puts are allowed. If not, re-fetch to confirm, and refuse the operation.
Look at the current size estimate for the target bucket. If we do not have it already cached (in this gateway) fetch it. Also fetch it if the old estimate has exeeded its time-to-live or is in excess of the soft-limit. The purpose of the soft limit is to avoid the overhead of confirming the actual size on each write, unless we are close enough to warrant the checks.
If the bucket is over-size and enforcement is enabled, disable puts and refuse the operation.
If this operation would put us over quota, and enforcement is enabled, refuse the operation.
Do the put, and if it succeds, update our (local) estimate of the bucket size. If we are at our quota, and enforcement is enabled, disable puts.

On each delete operation:

Look at the cached current access mask and see if deletes are allowed. If not, re-fetch to confirm, and refuse the operation.
Perform the delete, and update our (local) estimate of the bucket size.
Look at the cached current access mask and size. If writes are disallowed or we are over the soft limit, re-fetch to confirm.
If we are now under the quota, reenable puts.

Define new RESTful APIs and CLIs to:

set and query quota and enforcement enablement.

Work items¶