cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wei ZHOU <ustcweiz...@gmail.com>
Subject Re: [PROPOSAL] Storage plug-in for 4.2
Date Fri, 31 May 2013 16:43:52 GMT
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.tutkowski@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
>

Mime
View raw message