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 Fri, 08 Feb 2013 03:03:11 GMT
Interesting idea, Marcus.

The hard part is in guaranteeing CSPs the IOPS they selected...especially
if they've written SLAs for their customers around said performance.

It all comes down to the "Noisy Neighbor" problem:  If you have multiple
VMs running on the same volume, any one of them can - at one point or
another - utilize a disproportionate number of IOPS and starve its
neighbors.


On Thu, Feb 7, 2013 at 4:34 PM, Marcus Sorensen <shadowsor@gmail.com> wrote:

> Hmm, you could do something like create a 'high iops' storage pool,
> and the VM host mounts that and creates multiple vm volumes (vhd) on
> that, just like stock, but then you have a script that polls
> cloudstack occasionally, asks how many volumes are on that pool, and
> adjusts your LUN's iops to be volumes x iops. So if you register a
> high perf 10TB lun to provide Z iops per volume as a primary storage,
> then create 3 volumes on it, your script sets the iops on that lun to
> Z x 3. It's still limited by only offering certain classes of
> performance, instead of a large variety (one class per primary pool),
> but it's another avenue to consider.
>
> On Thu, Feb 7, 2013 at 4:28 PM, Marcus Sorensen <shadowsor@gmail.com>
> wrote:
> > He's saying that the VM can connect via iscsi directly to the
> > solidfire device, rather than the host. You'd lose more performance
> > that way and there's more overhead, but it would be a way to give
> > individual VMs their own solidfire LUN.
> >
> > On Thu, Feb 7, 2013 at 4:06 PM, Mike Tutkowski
> > <mike.tutkowski@solidfire.com> wrote:
> >> Hi Edison,
> >>
> >> I'm not sure I entirely follow.  Creating the volume (LUN) on our SAN is
> >> straightforward enough.  We'd get back an IQN.  Are you saying at this
> point
> >> I'd talk to, say, XenServer and have it create a storage repository that
> >> makes use of the iSCSI target (my IQN)?  If so, once that is done, I was
> >> thinking I'd update a known (PreSetup-based) Primary Storage's Storage
> Tag.
> >> After, I'd update the single Compute Offering that references that
> Primary
> >> Storage by changing its Storage Tag to be equal to that of my Primary
> >> Storage.  Once this is done, the VM could be spun up from the Compute
> >> Offering (and underlying Primary Storage).  When the VM Instance is up
> and
> >> running, the Compute Offering's and Primary Storage's Storage Tag could
> be
> >> changed back to some expected value.
> >>
> >> I don't particularly like this solution in the sense that you can't
> kick off
> >> such a new Compute Offering until the one before it was done, but it
> would
> >> only serve as a temporary measure to help customers leverage our QoS
> >> feature.
> >>
> >> What do you think?  Does this sound doable with the CS API?
> >>
> >>
> >> On Thu, Feb 7, 2013 at 3:55 PM, Edison Su <Edison.su@citrix.com> wrote:
> >>>
> >>> Another solution would be, totally bypass cloudstack and hypervisor,
> >>> create LUN in your storage box, then give the IQN to guest VM. Inside
> guest
> >>> VM, there may have a script, which can grab that IQN from
> somewhere(can be
> >>> in user data), then scan iSCSI, mount the device, etc. It can work
> with all
> >>> the hypervisors.
> >>>
> >>>
> >>>
> >>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >>> Sent: Thursday, February 07, 2013 11:18 AM
> >>> To: cloudstack-dev@incubator.apache.org; Edison Su; Marcus Sorensen
> >>>
> >>>
> >>> Subject: Supporting SolidFire QoS Before 4.2
> >>>
> >>>
> >>>
> >>> 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™
> >>
> >>
> >>
> >>
> >> --
> >> Mike Tutkowski
> >> Senior CloudStack Developer, SolidFire Inc.
> >> e: mike.tutkowski@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the cloud™
>



-- 
*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