John Griffith, Software Engineer at SolidFire and is also currently the Technical Lead for the Block Storage project in Openstack. In this video you will see how to configure OpenStack & SolidFire: QoS via Volume Types.
Hey, my name is John Griffith and I am a software engineer at SolidFire. I'm also a contributor to open stack, specifically the block storage service cinder. Today I kind of wanted to 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 shell, and we've already installed the python cinder client, and we've already sourced our credentials as an admin user. That's important that 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 [preds 00:01:06] file that has all that set.
First thing we're going to do is we're just going to go ahead and just simply do a type create, and we're going to call it 'demo type'. There we have a new volume type, with a you, ID, and a name. The next thing 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 mind is with grizzly, the filter scheduler has been introduced which makes a lot of intelligent decisions, whereas 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 another talk, but for now, we're just going to focus on what the SolidFire driver 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 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." 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 going to go ahead now and 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. And in this case we're doing a set, and then we're going to do 'QoS:' and that's the scoping that I talked about. Then the actual values that we're interested in are [minim-iops 00:02:55], [max-iops 00:03:01], and [verse-iops 00:03:03]. Was there other. 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 volumes. I'm going to create one without using the volume type that we just created, and show you the default QoS settings. Then also I'm going to create a second one with these settings. We'll do a cinder create. And 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, and a list, so we know everything went well.
Now, we'll do another one, special one. And we'll do one type, and go back up to this UUID and give it another 620. You can see already here the volume type we specified, so that's assigned. We'll do a list real quick, and you can see everything's 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, and sure enough, there's our two volumes. One thing you can take a look at too, interesting. Notice that the volume name that we use on the SolidFire cluster also corresponds to the UUID of the volume from open stack, or cinders perspective. Kind of a 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, and thanks.