Hey, my name is John Griffith and I am a software engineer at SolidFire. I'm also a contributor
to OpenStack, specifically the block storage service, Cinder.
Today, I wanted to kind of go through real quick and talk about how you can use volume
types and extra-specs to set QOS on a volume when you're using SolidFire for your back-end
in Cinder. There's a number of things we've already done.
We've already set up our Grizzly install and we've set up our SolidFire cluster and configured
Cinder to use the SolidFire driver to point to our SolidFire cluster for the back-end
storage. From there, now all we need to do is go over to the shell. We've already installed
the Python Cinder Client and we've already sourced our credentials as an admin user.
It's important that you remember you're going to need admin privileges in order to create
the type and keys. Rather than type in my passwords and admin name, I'm going to go
ahead and just use a PRZ file that has all that set.
The first thing we're going to do is we're just going to go ahead and simply do a 'type
create' and we're going to call it "demo type". There we have a new volume type with a UUID
and a name. The next thing that we need to do is we need to actually give it some sort
of meaningful data. That's where the extra-specs keys come in which are basically meta data
that's assigned. Something to keep in mind is with Grizzly,
the filter scheduler has been introduced which makes a lot of intelligent decisions, or is
capable of making intelligent decisions based on volume types and in particular extra-specs.
Those extra-specs can be things like volume back-end names, capacity information, capabilities
information, things like that. We'll go into that in another talk, but for now we're just
going to focus on what the SolidFire driver [00:02:00] is using.
The reason I mention that is what we want to do is we want to give it what's called
a scoped key. A scoped key is basically giving it a designator to tell the filter scheduler,
"Hey, ignore this. Don't try and make capabilities decisions based on this information that I'm
passing in. Just pass it through to the driver." And then what happens is the SolidFire driver
can look at it, pick up those keys and then make the decisions that it needs to make and
make the settings that it needs to make using that information.
We're just going to go ahead and create an extra-spec key or keys. Type "key" and we're
going to give it the UID of that volume type we just created. In this case we're doing
a set, and then we're going to do QoS colon. That's the scoping that I talked about. The
actual values that we're interested in are min IOPS, max IOPS and burst IOPS. And another
zero there. Now we have created our type and we've assigned some keys to it. We can take
a look at the keys and verify that everything looks cool there. There we go. That all looks
fine. Now I'm just going to go ahead and I'm going
to create a couple of volumes. I'm going to create one without using the volume type that
we just created and show you what the default QOS settings. Then also I'm going to create
a second one with these settings. We'll do a 'cinder create'. I'm not going to give it
a description. I'm just going to give it a simple name there. You can see there's a volume
there. I'm going to do a 'list'. everything went well. Now,
we'll do another one, 'special'. We'll do 'type' and go back up to this UUID and give
it another set, 20. You can see already here the volume type is
specified so that's fine. Do a list real quick. You can see everything is available. Everything's
set up and ready to go. Let's go over and take a look at the SolidFire UI and check
out what it says the QOS settings are. Do a refresh here. Sure enough, there's our two
volumes. One thing you can take a look at too, be interesting, is that the volume name
that we used on the SolidFire cluster also corresponds to the UUID of the volume from
OpenStack or Cinders' perspective. Kind of nice little tool for an admin if you need
to go into the cluster through the UI or some other form through the API or something like
that and do some kind of operations. It's easy to make a correlation of what volumes
on the cluster correspond to volumes inside of OpenStack.
That's a real quick rundown on how to use volume types and extra-specs to set QOS if
you're using SolidFire. Hope that was helpful. If you have any questions, please feel free
to give myself or anybody else at SolidFire a call. Also, you can always reach me on IRC.
My handle is J Griffith. Thanks. [00:06:00]