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 <mike.tutkow...@solidfire.com > 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 <aemne...@gmail.com> 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 < >> mike.tutkow...@solidfire.com> 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: 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> > *™* > -- *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> *™*
