So, yeah, at this point, I'm playing around with ideas. I'm thinking my initial flow, while not perfect by any means (reference potential race condition), might work sufficiently.
I definitely would like to tap people in the CloudStack community for a sanity check, though. :) On Thu, Feb 7, 2013 at 2:30 PM, Mike Tutkowski <[email protected] > wrote: > Exactly...and Edison's new plug-in architecture will enable us to create a > volume per VM Instance or Data Disk, but that won't be out until 4.2. > > In the meanwhile, I'm kind of brainstorming to see if I can write a script > to enable this functionality before 4.2 (and for customers who won't > upgrade to 4.2 right away when it comes out). > > > On Thu, Feb 7, 2013 at 2:27 PM, Ahmad Emneina <[email protected]> wrote: > >> got it. the iops are shared amongst guest vm disks that reside on a >> volume. So is the idea to create a volume per vm? >> >> >> On Thu, Feb 7, 2013 at 1:22 PM, Mike Tutkowski < >> [email protected]> wrote: >> >>> Also, when I say "volume", that is equal to "LUN" when talking about >>> SolidFire. >>> >>> >>> On Thu, Feb 7, 2013 at 2:21 PM, Mike Tutkowski < >>> [email protected]> wrote: >>> >>>> Hi Ahmad, >>>> >>>> Thanks for the comments. >>>> >>>> In regards to your first idea about creating multiple targets on the >>>> SolidFire system, I'd be concerned that I wouldn't know how many to create. >>>> Would I make 100...200...? Not sure. Since SolidFire can control IOPS on >>>> a per-volume basis, in our ideal world, each VM Instance or Data Disk would >>>> be serviced by a single SolidFire volume. If I ever have more than one VM >>>> Instance, for example, running on the same SolidFire volume, I can't >>>> guarantee any individual VM its IOPS (as its IOPS may be absorbed unequally >>>> by the other VM(s) running on the same volume). >>>> >>>> Does that make sense? If you see some flaw in my logic, please let me >>>> know. :) >>>> >>>> Thanks! >>>> >>>> >>>> On Thu, Feb 7, 2013 at 1:02 PM, Ahmad Emneina <[email protected]>wrote: >>>> >>>>> Hey Mike, >>>>> >>>>> The cleanest approach as a user would be: >>>>> I create multiple targets on the solid fire. Each with a different >>>>> IOPs setting (assuming you can control max iops for volumes this way). I'd >>>>> mount each to the hypervisor and create a specific service offering for >>>>> each. That way youre intercepting calls with a script and modifying >>>>> tags/offerings on the fly, and avoid said race condition. >>>>> >>>>> second cleanest approach IMO: >>>>> Or to backpack off your previous method. Create 3 different service >>>>> offerings (fast, medium, slow). That way when the deploy vm is called, >>>>> your volume create script can intercept the call and will know the QOS >>>>> based on the offering. >>>>> >>>>> Why I'd do this is say you change the service offering to fast while >>>>> provisioning a vm, and a user with a disk thats meant to be slow reboots >>>>> her vm... she'll be upgraded to fast. All because your modifying the one >>>>> and only offering. >>>>> >>>>> >>>>> On Thu, Feb 7, 2013 at 11:17 AM, Mike Tutkowski < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I learned yesterday that Edison's new storage plug-in architecture >>>>>> will >>>>>> first be released with 4.2. >>>>>> >>>>>> As such, I began to wonder if there was any way outside of CloudStack >>>>>> that >>>>>> I could support CloudStack users who want to make use of SolidFire's >>>>>> QoS >>>>>> feature (controlling IOPS). >>>>>> >>>>>> A couple of us brainstormed for a bit and this is what we came up >>>>>> with. >>>>>> Can anyone confirm if this could work? >>>>>> >>>>>> ******************** >>>>>> >>>>>> The CloudStack Admin creates a Primary Storage that is of the type >>>>>> PreSetup. This is tagged with a name like "SolidFire_High" (for >>>>>> SolidFire >>>>>> High IOPS). >>>>>> >>>>>> The CloudStack Admin creates a Compute Offering that refers to the >>>>>> "SolidFire_High" Storage Tag. >>>>>> >>>>>> In the CSP's own GUI, a user picks the Compute Offering referred to >>>>>> above. >>>>>> The CSP's code sees the Storage Tag "SolidFire_High" and that cues >>>>>> it to >>>>>> invoke a script of mine. >>>>>> >>>>>> My script is passed in the necessary information. It creates a >>>>>> SolidFire >>>>>> volume with the necessary attributes and hooks it up to the hypervisor >>>>>> running in the Cluster. It updates my Primary Storage's Tag with the >>>>>> IQN >>>>>> (or some unique identifier), then it updates my Compute Offering's >>>>>> Storage >>>>>> Tag with this same value. >>>>>> >>>>>> Once the Primary Storage and the Compute Offering have been updated, >>>>>> CloudStack can begin the process of creating a VM Instance. >>>>>> >>>>>> Once the VM Instance is up and running, the CSP's GUI could set the >>>>>> Primary >>>>>> Storage's and Compute Offering's Storage Tags back to the >>>>>> "SolidFire_High" >>>>>> value. >>>>>> >>>>>> ******************** >>>>>> >>>>>> The one problem I see with this is that you would have to be sure not >>>>>> to >>>>>> kick off the process of creating such a Compute Offering until your >>>>>> previous such Compute Offering was finished (because there is a race >>>>>> condition while the Storage Tag field points to the IQN (or some other >>>>>> unique identifier)). >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -- >>>>>> *Mike Tutkowski* >>>>>> *Senior CloudStack Developer, SolidFire Inc.* >>>>>> >>>>>> e: [email protected] >>>>>> 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: [email protected] >>>> 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: [email protected] >>> 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: [email protected] > 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: [email protected] o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
