cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Syed Ahmed <sah...@cloudops.com>
Subject Re: [DISCUSS] IOPS/GB and Highest Min and Max IOPS for disk offering
Date Thu, 27 Jul 2017 20:13:34 GMT
Mike, you are absolutely right. I have added 4 new fields in the
disk_offering table. The driver code won't need to change as I would pass
the min and max IOPS after translating them. I am not using a fifth
parameter since it is an either or situation, if you pass IOPS/GB in your
API call and also pass an IOPS value, I will error out saying that you can
only use one of those.

Thanks,
-Syed

On Thu, Jul 27, 2017 at 2:53 PM, Tutkowski, Mike <Mike.Tutkowski@netapp.com>
wrote:

> So then, based on the use case you mentioned, you are saying you don't
> really care about minimum limits, right?
>
> Are the values you specify for the disk offering going to be translated
> into the standard min and max values that get stored in the volumes table?
> If that is the case, then the storage driver code won't need to change. You
> would perform the translation and then pass in the min and max values to
> the driver as is done today.
>
> In that situation, you would only need four new fields in the
> cloud.disk_offering table. Perhaps a fifth column saying whether you were
> using IOPS/GB or the standard way.
>
> On Jul 27, 2017, at 12:45 PM, Syed Ahmed <sahmed@cloudops.com<mailto:sa
> hmed@cloudops.com>> wrote:
>
> Hi Mike,
>
> In case of min and max values of IOPS for a specific offering, there is
> another use case. We want to offer tiered storage. Right now if we have a
> disk offering, there is no way for us to limit the IOPS that the customer
> can set. We want to have say an offering which scales upto 10k IOPS and if
> the want more IOPS, they must switch to a higher tiered offering which has
> its values set to a higher limit.
>
> As for compatibility with existing offering. You are right, the existing
> offerings will still work as expected. An IOPS/GB setting will be used
> independently of the current method (fixed or custom)
>
> Thanks,
> -Syed
>
> On Thu, Jul 27, 2017 at 2:34 PM, Tutkowski, Mike <
> Mike.Tutkowski@netapp.com<mailto:Mike.Tutkowski@netapp.com>> wrote:
> Hi Syed,
>
> I have a couple questions.
>
> What about the minimum number of IOPS a storage provider can support?
>
> For example, with SolidFire, in some releases we can go down as low as 100
> IOPS per volume and in newer releases as low as 50 IOPS per volume.
>
> Perhaps you should just leave it to the storage driver to confine itself
> to its minimum and maximum values. This would not require such parameters
> to be passed to the disk offering.
>
> Another question I have is how compatibility will work between this
> proposed feature and the existing way this works. I assume it will be an
> either or situation.
>
> Thanks!
> Mike
>
> > On Jul 27, 2017, at 9:34 AM, Syed Ahmed <sahmed@cloudops.com<mailto:sa
> hmed@cloudops.com>> wrote:
> >
> > Hi All,
> >
> > I am planning to add 4 new parameters to the disk offering. The use case
> for this is as follows:
> >
> > We want to provide a provisioned IOPS style offering to our customers
> with managed storage like SolidFire. The model is similar to GCE where we
> have IOPS scale with the size based on a predefined ratio. So for this I
> want to add two options. minIOPSPerGB and maxIOPSPerGB. Now, based on what
> storage you have, you have limits on the highest values for your min and
> max IOPS and after which you don't want to scale your IOPS (SolidFire for
> example can do 10k minIOPS and 20k max IOPS). To support this, I have to
> add two more parameters, highestMinIOPS, highestMaxIOPS. This should work
> with existing disk offerings without problem. I am looking for comments on
> this approach. Would really appreciate your reviews.
> >
> > Thanks,
> > -Syed
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message