Cool! Thanks, Marcus
On Wed, Feb 6, 2013 at 10:14 PM, Marcus Sorensen <[email protected]>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 > <[email protected]> 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 > > <[email protected]> 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 <[email protected]> > >> Date: Wed, Feb 6, 2013 at 9:52 PM > >> Subject: Re: Question about storage plug-in architecture > >> To: Marcus Sorensen <[email protected]> > >> > >> > >> 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 <[email protected]> > >> 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" <[email protected]> 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 > >>>> <[email protected]> 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: [email protected] > >>>> > 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: [email protected] > >> o: 303.746.7302 > >> Advancing the way the world uses the cloud™ > >> > >> > >> > >> -- > >> Mike Tutkowski > >> Senior CloudStack Developer, SolidFire Inc. > >> e: [email protected] > >> o: 303.746.7302 > >> Advancing the way the world uses the cloud™ > > > > > > > > > > -- > > Mike Tutkowski > > Senior CloudStack Developer, SolidFire Inc. > > e: [email protected] > > o: 303.746.7302 > > Advancing the way the world uses the cloud™ > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: [email protected] o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
