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.tutkow...@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.tutkow...@solidfire.com> > Date: Wed, Feb 6, 2013 at 9:52 PM > Subject: Re: Question about storage plug-in architecture > To: Marcus Sorensen <shadow...@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 <shadow...@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" <shadow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
