cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tutkowski, Mike" <Mike.Tutkow...@netapp.com>
Subject Re: [DISCUSS] IOPS/GB and Highest Min and Max IOPS for disk offering
Date Thu, 27 Jul 2017 20:30:02 GMT
That sounds good, Syed.

On Jul 27, 2017, at 2:14 PM, Syed Ahmed <sahmed@cloudops.com<mailto:sahmed@cloudops.com>>
wrote:

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<mailto: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:sahmed@cloudops.com><mailto:sahmed@cloudops.com<mailto:sahmed@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><mailto: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:sahmed@cloudops.com><mailto:sahmed@cloudops.com<mailto:sahmed@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