Mike, Thanks a lot! -Wei
2013/5/31, Mike Tutkowski <mike.tutkow...@solidfire.com>: > 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> > *™* >
