Hi Wei, Thanks!
Here are the details you requested. This also talks about Min and Max IOPS. Please let me know if you'd like more information. I have an entire document I could share with you regarding SolidFire QoS (the info below is taken from this document). Talk to you later! How does SolidFire QoS use burstIOPS? When the cluster is running in a state of low cluster utilization, clients are able to accrue burstIOPS credits and use these credits to burst above their max up to their burst IOPS for the burst period. The current burst period is 60 seconds. Burst IOPS credits are accrued by performing less IO than the maxIOPS. Each IO that is not used under the maxIOPS, is considered an IOPS “credit”, that can be used later. There are two limits to the way that the burst IOPS credits can be used. The first limit is that the total number of burst credits that a customer can accrue is (60 seconds) * (burst IOPS - max IOPS). The second limit is that the number of credits that can be depleted at any time is at most the burst IOPS. Thus, a customer will never be able to go higher than the burst IOPS set for the volume. Note: when another volume on the node is unable to reach its minIOPS, burstIOPS are reset for all customers on the node. Basic explanation: When there is performance left to do so, SolidFIre allows customers to burst above their maximum for 60 seconds. How does SolidFire QoS use maxIOPS? MaxIOPS is a sustained rate limit. For a sustained period of time, the customer will be able to sustain this IO rate, as long as no one else on the cluster is unable to get their minimum IOPS. Basic explanation: MaxIOPS is what a customer will sustain for a long period of time if everyone is getting their minimum IOPS guarantees. How does SolidFire QoS use minIOPS? The minIOPS is a lower limit on the performance that a customer should expect in normal operating scenarios. SolidFire QoS is constantly monitoring the latencies observed by the client, and the queue depth that the client is driving to the cluster. When a customer reaches the “cannot reach minIOPS situation”, as detected by the targetIOPS and the latencies that the cluster is seeing at the given IOPS, other customers are gradually ratcheted and pushed down to their minIOPS. Note: customers are never throttled to less than their minIOPS unless there is serious overload. What this means, is that at sufficiently high queue depth on a heavily utilized cluster, our quality of service detects situations where a customer is unable to get their minIOPS, and takes performance away from other customers running above their minIOPS, and gives it to the customer that is unable to reach their minIOPS until the “unhappy” customer reaches their minIOPS. Note: In Boron (Version 5), to qualify for the minIOPS guarantee, the customer must be running a queue depth higher than 8. What these three settings give us is something unique to storage: a quality of service that limits the customer’s sustained effect on performance on the cluster (max IOPS), the ability to burst and use unused performance (burst IOPS) if there is any, and a reasonable expectation of performance even in high utilization situations where performance can be dynamically balanced throughout customers in the system. The net effect of this, is that, in SolidFire, because the ratio of performance between customers is changing depending on cluster utilization, we’ve made it so that each customer’s performance isn’t directly tied to each other. On Fri, May 31, 2013 at 10:43 AM, Wei ZHOU <ustcweiz...@gmail.com> wrote: > Mike, > > good work. > I notice the burst IOPS. Do you know the mechanism and the config of > it, like the duration and interval burst IO? Thanks. > > -Wei > > 2013/5/31, Mike Tutkowski <mike.tutkow...@solidfire.com>: > > Hi everyone, > > > > I apologize for being unfamiliar with how I should have gone about > getting > > consensus for the storage plug-in I developed for 4.2. > > > > I talked with Animesh and he has asked me to send out this proposal > related > > to the storage plug-in I built for 4.2 and submitted to Review Board > > earlier this week. > > > > Here is a link to the design document: > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Implement+SolidFire+(storage)+plug-in+and+expose+control+of+IOPS+to+admins+and+end+users > > > > Here is a link to the JIRA ticket: > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-2778 > > > > Here is a link to it on Review Board: > > > > https://reviews.apache.org/r/11479/ > > > > Here is a high-level summary: > > > > I have developed a storage plug-in which makes use of the new storage > > framework that Edison put in place for the 4.2 release. > > > > Working with Edison, I have identified a few areas of the storage > framework > > that needed to be enhanced (and I have done so in the code that I > > submitted) for dynamic, zone-wide primary storage to function. > > > > This storage plug-in is specific to SolidFire (a data-storage company), > > whose architecture is designed around Quality of Service. Each volume on > > this SAN is assigned a Min, Max, and Burst number of IOPS. The Min is, as > > one might expect, a guaranteed number (even in fault conditions) (as long > > as the IOPS of the SAN are not over-provisioned). > > > > Per a discussion several months ago on this list, I have added into the > > Disk Offerings Min, Max, and Burst values (all optional). These values > > follow the patterns of the Disk Size field in that they can be customized > > by the end user (in the Add Volume) if the admin decides to allow this. > > > > In the end, this feature allows users to create a 1:1 mapping between a > > volume on the SAN and a data disk that can be attached to a VM (XenServer > > supported...perhaps VMware, depending on time). This allows CloudStack > > admins to offer their end users guaranteed IOPS on data disks > (eliminating > > the Noisy Neighbor effect). The plan is to support root disks in a > post-4.2 > > release. > > > > Again, I am sorry about my confusion regarding process here. I certainly > > appreciate all of the input I have received on the e-mail list over the > > past couple months while I was developing this feature. > > > > Please let me know if you have any questions. > > > > Thanks! > > > > -- > > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@solidfire.com > > o: 303.746.7302 > > Advancing the way the world uses the > > cloud<http://solidfire.com/solution/overview/?video=play> > > *™* > > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
