incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Supporting SolidFire QoS Before 4.2
Date Thu, 07 Feb 2013 21:22:33 GMT
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.tutkowski@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 <aemneina@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message