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" <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> > *™* >
