Friday, December 11, 2015

Nimble Storage - So Easy Even I Can Do It - Part Deux - Volumes, Initiators and Performance Policies

Hi Friends,

So last we left our array it was setup and ready to login.  Okay, great, now what?  The great thing is creating a volume and getting it visible to your consumers is super simple!

After you log into your Nimble array you'll be at the Home screen.  Lots of cool stuff there, but let's focus on creating our volume first.  Click on Manage > Volumes.

Now that we're in the Volume area, let's click on New Volume.  Yep, there's cool stuff on the left side too, I'll talk about that later as well.

Lots of new goodies!!  First we name our volume, give it a performance policy, choose if the data is encrypted, what iSCSI Initiator Group can access the data and if we're going to use CHAP or not.

Let's start with Performance Policy.  Applications are interesting things.  They tend to vary a lot, not just in what they do, but how they read and write data to disk.  The cool thing about the Nimble is you can select from a pre-defined list of popular applications or you can create your own performance policy!

Here's a list of the pre-defined policies and if you don't see your application here, you can either select "default" or you can create a policy to best match the performance characteristics of your application.

Here I've clicked on the New Performance Policy button.  Fist you name your new policy, select the block size your application best utilizes and whether or not you want to use compression and caching.  Compression and caching are usually on by default to give you great space savings and performance, but there are times when you don't need or want those features enabled.  More on that in another blog post.

Here I've called my volume "vol-creation1", given it a Performance Policy of "VMware ESX", Data Encryption is "Disabled", my iSCSI Initiator Group is set to group I've already created and I'm not using CHAP.  More on Encryption later!

Next we tell our Nimble what size our volume is going to be.  Here I'm selecting 2TB.  How about SPACE?  This is all about volume reserves, quotas, warnings, etc.  I'm going to take the defaults because they are pretty good as is.  If there's something you want to change, you can.

Lot's of good stuff here, so I'm going to break this up into two images.  First of all we're going to choose how we protect the volume.  You've got a lot of choices, none, use a pre-existing collection, create a new volume collection or protect the volume as standalone.  So what is a volume collection?  Basically you're creating a protection template that tells Nimble how you're going to protect the volume.  And the cool thing is you can re-use the template after you create it for other volumes.

The next step is to choose your synchronization.  You can select None, Microsoft VSS or VMware vCenter.  This is really cool because with Microsoft VSS you can have Nimble talk to your Microsoft application that supports VSS to do application consistent snapshots.  If you're using VMware, you can have vCenter create a VM consistent snapshot before you create your Nimble snapshot.

Now we're going to create a schedule for our template.  We can choose how often, when to start, on what days, how many snapshots to keep and if we want to replicate to another Nimble array.  Pretty neat huh?  More on replication later.

Okay, something new for our seasoned Nimble admins.  Notice the Performance piece in the workflow?  And notice we can click Next or Finish?  If you don't want to mess with advanced performance just click Finish, but I'm adventurous, so let's click Next!

Now this is really cool!  If you want Nimble to make the caching decisions, just leave this at Normal(default), BUT, if you're daring like me, you can choose to pin this volume.  So what does pinning do?  Say you want a particular volume to behave like a flash array.  You can select Pinned and the volume will not be evicted from cache when the data gets cold.

Remember, you've got a finite amount of cache in your array, so the more volumes you pin, the less cache you have for "regular" volumes.  CASL does a fantastic job swapping data in and out of cache, but sometimes you just need a bigger hammer!

So when would you need this?  One scenario I've been working on is putting your VDI gold image and replica on a single volume and pinning that to cache.  Create a small volume ~50g and pin the sucker!  It's a small size so it won't use a lot of cache, plus when you do a refresh or recompose, you're reading the two images directly from cache!

After you decide whether to pin or not, click Finish and you're done!!

Until Next Time!

No comments:

Post a Comment