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