incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmad Emneina <aemne...@gmail.com>
Subject Re: Supporting SolidFire QoS Before 4.2
Date Thu, 07 Feb 2013 22:43:15 GMT
My $0.02 is $solidfiredev should focus on the end goal of implementing this
awesome feature, and not some interim solution that wont be supported going
forward.


On Thu, Feb 7, 2013 at 2:06 PM, Mike Tutkowski <mike.tutkowski@solidfire.com
> wrote:

> 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