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: Question about storage plug-in architecture
Date Thu, 07 Feb 2013 05:16:11 GMT
Cool!  Thanks, Marcus


On Wed, Feb 6, 2013 at 10:14 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:

> That's right. The primary storage mechanism was designed such that you
> could just continue adding primary storage devices as you go. So you
> could have four storage devices/primary storage pools all with the tag
> 'fast', and cloudstack will use them up. There's an allocation
> algorithm that you can set in the global settings for whether you want
> them used sequentially, spread out, spread out per user, etc. At least
> I think it applies to storage and not just hypervisor host locations.
>
> On Wed, Feb 6, 2013 at 10:01 PM, Mike Tutkowski
> <mike.tutkowski@solidfire.com> wrote:
> > Based on your walk through above, it looks like two different SolidFire
> > storage clusters would equal setting up two different Primary Storage
> types
> > (because each SolidFire cluster would have a different Management VIP and
> > Storage VIP).  That makes sense.
> >
> > Even if the customer only has a single SolidFire storage cluster, it
> looks
> > like multiple Compute and Disk Offerings can be created to service
> different
> > IOPS requirements, which is perfect.
> >
> > Thanks for the info!
> >
> >
> > On Wed, Feb 6, 2013 at 9:58 PM, Mike Tutkowski
> > <mike.tutkowski@solidfire.com> wrote:
> >>
> >> It looks like I accidentally sent this out only to you, Marcus.
> >>
> >> Sending it onto the community at large now.
> >>
> >> ---------- Forwarded message ----------
> >> From: Mike Tutkowski <mike.tutkowski@solidfire.com>
> >> Date: Wed, Feb 6, 2013 at 9:52 PM
> >> Subject: Re: Question about storage plug-in architecture
> >> To: Marcus Sorensen <shadowsor@gmail.com>
> >>
> >>
> >> Awesome - thanks, Marcus!
> >>
> >> Yeah, I hesitated to single out Edison, but I figured I've been mainly
> >> working with him and wanted to get his attention.
> >>
> >> I certainly appreciate all the help people are offering.
> >>
> >> Thanks for the walk through.
> >>
> >> So, at SolidFire, we talk in terms of storage clusters.  A customer
> could,
> >> I suppose, have more than one storage cluster.  Each storage cluster
> has its
> >> own Management VIP.  Is that workable in this scheme?
> >>
> >>
> >> On Wed, Feb 6, 2013 at 9:46 PM, Marcus Sorensen <shadowsor@gmail.com>
> >> wrote:
> >>>
> >>> Then of course, from the internal perspective, when the createVolume
> API
> >>> call is run, for example by the UI when someone tries to create a disk,
> >>> edison passes you the parameters of the disk offering, along with the
> info
> >>> on the primary storage, and its up to your code to create a lun that
> is 30GB
> >>> big and is set to 500 iops on pool0 by talking to the San on
> management IP
> >>> 192.168.50.10.
> >>>
> >>> On Feb 6, 2013 9:40 PM, "Marcus Sorensen" <shadowsor@gmail.com> wrote:
> >>>>
> >>>> I know you asked Edison, but I'll chime in and he can confirm/reject.
> >>>>
> >>>> Primary storage will define where your storage is and how to connect.
> >>>> These are up to the developer to decide on, and really come down to
> >>>> what it takes to identify/configure the device
> >>>>
> >>>> management IP address
> >>>> target address/IQN
> >>>> disk pool (in case you intend for an admin to have multiple pools of
> >>>> disks to choose from, for example)
> >>>> storage tags
> >>>>
> >>>> Then disk offerings specify properties. The main property right now
is
> >>>> size, along with the tag to select a primary storage.
> >>>>
> >>>> Disk size,
> >>>> disk iops
> >>>> disk bandwidth
> >>>> storage tags
> >>>>
> >>>> So the architecture that an admin could create might look like this:
> >>>>
> >>>>
> >>>> SAN device san0.domain.com:
> >>>> API listens on a gigabit management network, 192.168.50.10
> >>>> iscsi Target exists on a 10Gbit SAN network, 10.10.10.10
> >>>> has pool0 which consists of 8 x SSD in RAID10, created lun 0 and
> >>>> exported as target
> >>>> pas pool1 which consists of 12 x HDD in RAID60, created lun 1 and
> >>>> exported as target
> >>>>
> >>>> Admin goes into CloudStack, registers primary storage. Fills out the
> >>>> following:
> >>>> Name: san0-ssd
> >>>> Management IP: 192.168.50.10
> >>>> Target: 10.10.10.10
> >>>> LUN: 0
> >>>> Tags: fast
> >>>>
> >>>> Admin goes into CloudStack, registers primary storage. Fills out the
> >>>> following:
> >>>> Name: san0-hdd
> >>>> Management IP: 192.168.50.10
> >>>> Target: 10.10.10.10
> >>>> LUN: 1
> >>>> Tags: slow
> >>>>
> >>>> Admin creates disk offering:
> >>>> Name: high-ssd
> >>>> Size: custom
> >>>> Tags: fast
> >>>> iops: 1000
> >>>> bandwidth(MB): 100Admin creates disk offering:
> >>>> Size: custom
> >>>> Tags: fast
> >>>> iops: 1000
> >>>> bandwidth(MB): 100
> >>>>
> >>>> Admin creates disk offering:
> >>>> Name: medium-ssd
> >>>> Size: custom
> >>>> Tags: fast
> >>>> iops: 500
> >>>> bandwidth(MB): 50
> >>>>
> >>>> Admin creates disk offering:
> >>>> Name: 100GB-hdd
> >>>> Size(GB): 100
> >>>> Tags: slow
> >>>> iops: 100
> >>>> bandwidth(MB): 25
> >>>>
> >>>> Now, users create disks by selecting a disk offering and filling in
> >>>> any options that are 'custom'.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Feb 6, 2013 at 9:16 PM, Mike Tutkowski
> >>>> <mike.tutkowski@solidfire.com> wrote:
> >>>> > Hi Edison,
> >>>> >
> >>>> > I have another quick question for you.  :)
> >>>> >
> >>>> > So, my first priority at SolidFire is to get a CloudStack storage
> >>>> > plug-in
> >>>> > up and running.
> >>>> >
> >>>> > Once that is complete, I need to look into how to enable CloudStack
> >>>> > users
> >>>> > to make use of our hard quality of service (QoS) feature.  This
is
> the
> >>>> > feature where a user can associate a max and min number of IOPS
to a
> >>>> > given
> >>>> > volume (LUN).
> >>>> >
> >>>> > You and I have discussed this a bit, but I was wondering if you
> could
> >>>> > give
> >>>> > me an idea of where you see admins or users specifying such values.
> >>>> > Our
> >>>> > preference is to have the admin who creates a Primary Storage type
> >>>> > based on
> >>>> > the SolidFire plug-in specify theses values.  Then a user could
make
> >>>> > use of
> >>>> > Compute and/or Disk Offerings that leverage the settings that were
> >>>> > configured when the Primary Storage type was created.
> >>>> >
> >>>> > Is that how you were envisioning this would work?
> >>>> >
> >>>> > Also, we could foresee there being several "levels" of volumes
> >>>> > supported by
> >>>> > the SolidFire plug-in.  For example, volumes created with "normal"
> >>>> > IOPS and
> >>>> > those created with higher IOPS.
> >>>> >
> >>>> > How do you picture this would fit into your new architecture? 
In
> >>>> > other
> >>>> > words, how would one associate a Compute or Disk Offering that
is
> >>>> > based on
> >>>> > one SolidFire quality of service versus another.
> >>>> >
> >>>> > 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™
> >>
> >>
> >>
> >> --
> >> 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