> We're working on getting infrasture into RADOS to allow for proper > distributed quality-of-service guarantees. The work is based on the > mclock paper published in OSDI'10 > > https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Gulati.pdf > > There are a few ways this can be applied: > > - We can use mclock simply as a better way to prioritize background > activity (scrub, snap trimming, recovery, rebalancing) against client IO. > - We can use d-mclock to set QoS parameters (e.g., min IOPS or > proportional priority/weight) on RADOS pools > - We can use d-mclock to set QoS parameters (e.g., min IOPS) for > individual clients. > > Once the rados capabilities are in place, there will be a significant > amount of effort needed to get all of the APIs in place to configure and > set policy. In order to make sure we build somethign that makes sense, > I'd like to collection a set of user stores that we'd like to support so > that we can make sure we capture everything (or at least the important > things). > > Please add any use-cases that are important to you to this pad: > > http://pad.ceph.com/p/qos-user-stories > > or as a follow-up to this email. > > mClock works in terms of a minimum allocation (of IOPS or bandwidth; they > are sort of reduced into a single unit of work), a maximum (i.e. simple > cap), and a proportional weighting (to allocation any additional capacity > after the minimum allocations are satisfied). It's somewhat flexible in > terms of how we apply it to specific clients, classes of clients, or types > of work (e.g., recovery). How we put it all together really depends on > what kinds of things we need to accomplish (e.g., do we need to support a > guaranteed level of service shared across a specific set of N different > clients, or only individual clients?). I added a handful of user stories to the page that address the use case of someone wanting to emulate aws / gce block storage services. I'm also keen to see a 'best effort' qos policy :) -- Kyle Bader -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
