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:30:02 GMT
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>
*™*

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