You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Mike Tutkowski <mi...@solidfire.com> on 2013/02/07 05:16:56 UTC
Question about storage plug-in architecture
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>
*™*
Re: Question about storage plug-in architecture
Posted by Mike Tutkowski <mi...@solidfire.com>.
Cool! Thanks, Marcus
On Wed, Feb 6, 2013 at 10:14 PM, Marcus Sorensen <sh...@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
> <mi...@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
> > <mi...@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 <mi...@solidfire.com>
> >> Date: Wed, Feb 6, 2013 at 9:52 PM
> >> Subject: Re: Question about storage plug-in architecture
> >> To: Marcus Sorensen <sh...@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 <sh...@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" <sh...@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
> >>>> <mi...@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>
*™*
Re: Question about storage plug-in architecture
Posted by Marcus Sorensen <sh...@gmail.com>.
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
<mi...@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
> <mi...@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 <mi...@solidfire.com>
>> Date: Wed, Feb 6, 2013 at 9:52 PM
>> Subject: Re: Question about storage plug-in architecture
>> To: Marcus Sorensen <sh...@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 <sh...@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" <sh...@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
>>>> <mi...@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™
Re: Question about storage plug-in architecture
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <mi...@solidfire.com>
> Date: Wed, Feb 6, 2013 at 9:52 PM
> Subject: Re: Question about storage plug-in architecture
> To: Marcus Sorensen <sh...@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 <sh...@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" <sh...@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
>>> <mi...@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<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>
*™*
Re: Fwd: Question about storage plug-in architecture
Posted by Marcus Sorensen <sh...@gmail.com>.
That's the reply to issue that everyone has been discussing. I did it too,
even knowing about it.
On Feb 6, 2013 9:58 PM, "Mike Tutkowski" <mi...@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 <mi...@solidfire.com>
> Date: Wed, Feb 6, 2013 at 9:52 PM
> Subject: Re: Question about storage plug-in architecture
> To: Marcus Sorensen <sh...@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 <sh...@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" <sh...@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
>>> <mi...@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<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>
> *™*
>
Fwd: Question about storage plug-in architecture
Posted by Mike Tutkowski <mi...@solidfire.com>.
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 <mi...@solidfire.com>
Date: Wed, Feb 6, 2013 at 9:52 PM
Subject: Re: Question about storage plug-in architecture
To: Marcus Sorensen <sh...@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 <sh...@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" <sh...@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
>> <mi...@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<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>
*™*
Re: Question about storage plug-in architecture
Posted by Marcus Sorensen <sh...@gmail.com>.
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
<mi...@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>
> *™*