cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: Question about storage plug-in architecture
Date Thu, 07 Feb 2013 04:40:09 GMT
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>
> *™*

Mime
View raw message