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 22:06:44 GMT
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 <mike.tutkowski@solidfire.com
> 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 <aemneina@gmail.com> 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 <
>> mike.tutkowski@solidfire.com> 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 <
>>> 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>
>>> *™*
>>>
>>
>>
>
>
> --
> *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