Today we continue our series on VAIO. You can start with the prologue (Running vSphere 6? Why you should care about VAIO), the first two posts ("What is VAIO?", "Getting Started with Storage Policies") or just start here.
In the first two posts in this series we covered how Accelerator integrates with storage policies and by doing so, the Accelerator I/O Filter is associated with VMDKs. This allows granular control while making it easy to associate an I/O Filter with a large number of VMs.
In general, the idea of storage policies is that when you create VMs from scratch or from a template, you can select the policy that fits that VM’s needs. This policy might define things such as replication policies, snapshot policies, performance SLAs, or simply help you keep things organized by the use of tags. It’s a good, simple way to maintain tiers of storage performance to ensure that you never have to deal with the “noisy neighbor” scenario or run out of Tier-1 storage due to over-provisioning.
Today I'll show you how to put storage policies and tags to work. Once we have this established I will explain two different ways to add in Accelerator to
1) improve your current storage performance, and
2) create a new top performance tier
To start, let me show how we have tagged our datastores. These tags are not unlike tags in other applications where they physically are nothing more than an attribute, but once the attribute is set, filters can be created to manipulate the resulting data set to make our lives easier. In our case we created a single tag category called “Performance Tiers” and the tags “1.Gold”, “2.Silver”, and “3.Bronze”. Note, you must create these vCenter-wide tags before associating them with a given object. That is, you cannot go directly to the Storage view and create datastore tags or go to the networking view and create vSwitch tags.
In our case, we purposely kept the tags fairly generic and chose to allow them to be assigned to any object type. This way we can reuse the tags for a number of different purposes and avoid tag sprawl.
Each datastore in this datacenter has had one of these tags assigned to it based on the current performance, snapshot, and replication parameters. Other configuration details such as SIOC or third-party capability sets could also be tweaked such that each datastore is conditioned according to its tier. Seeing that our tags have been created and our datastores are appropriately tagged, the next step is to create storage policies.
When creating the policies we configured the Common Rules as needed for our particular storage, and you would do the same. Perhaps you don’t run any Common Rules yet since most basic VMFS and NFS storage don’t use them unless you have installed a third-party plugin. Beyond the Common Rules, we added a tag-based rule when defining the Rule-Set in order to restrict the collection of datastores each policy can access to just those assigned to the performance tier. Here we see the tag-based Rule-Set for our gold policy.
In our case, we created three storage polices, one each for the three tags we created earlier. Note there are also two default policies, “Virtual SAN Default Storage Policy” and “VVOL No Requirements Policy”. These will show up even if you are not using VSAN or VVOLs. There is also a third default policy for VMFS and NFS that is not shown and cannot be modified, called “Datastore Default”. This default will only show up when modifying the policy of a VM or VMDK.
At this point we could assign these policies to VMs, check the compliance status, and audit the environment to see if it aligns with our planned performance tiers. That’s well and good, but we’re looking for more performance too. So we took a slightly different route.
Following the tag and policy configuration we installed Infinio Accelerator. This process is as simple as kicking off a Windows executable to walk through a series of steps to deploy the Infinio Management Console. Once that was up and running we logged into the UI and proceeded to install the Accelerator I/O Filters. To do this you would navigate to the Configuration tab and select “Setup Clusters+”. This is a shortcut workflow to get the filters installed without completing the full “first use” experience.
In our case, we installed the I/O Filter to Cluster-1, seen in the next few screenshots.
Once the filter was installed, we sized the cache for this cluster to 32GB of RAM cache per host.
The whole process of installation and resize will only take ~5 minutes in a typically sized environment.
Once the filter was installed we could add it to storage policies as a “cache” type common rule. Before we did this, a little planning was required. In our environment we already have three tags equating to three performance tiers. By adding the Accelerator cache we can either further increase the performance of our Gold tier, or another tier, or else create a new top level tier, a Platinum tier. There are pros/cons of each option. If we associated the I/O Filter to an existing storage policy that is already assigned to VMDKs, then due to this association the I/O Filter would automatically start caching for these VMs. This is a great low-touch option for associating the filter to a large number of VMs but we wanted a little more control over the application of the filter. In our case, we chose to go the route of creating a new performance tier.
Our new performance tier was called “0.Platinum” and is used for mission-critical apps. It is backed by the same storage as the Gold tier but will have the addition of the Accelerator filter. The process for adding the filter to this new policy couldn’t have been easier.
We started by creating a new storage policy and chose to enable the use a cache type common rule. Then we selected Infinio Accelerator and the version identifier. The version identifier will be prepopulated and is used for debug purposes only. Finally, we set the appropriate tag and saved the new policy.
Click Next and progress through the workflow to save these changes.
As you can see, we now have four performance tiers and also the option of adding the I/O Filter to any of the older policies at any time.
Now that our software defined infrastructure was configured, we assigned the new Platinum policy to our high value virtual machines. To do this, all we had to do was navigate to one of these VMs, then to the Manage tab, and finally to the Policies view.
From here we selected Edit Storage Policies. For each VMDK we wanted to accelerate we selected the Platinum policy. For some VMs where we wanted to accelerate all of the VMDKs we simply used the “Apply to all” menu item.
Note, the “VM home” object represents the VM’s default policy. If this is set to “Platinum” and a new virtual disk is created, that new disk will inherit the Platinum policy.
At this point we were pretty much done. The infrastructure had been configured to support our growing software defined management style and Accelerator had been added to a new top performance tier to be used by our mission critical applications.
Any VM that had at least one VMDK accelerated automatically shows up in the Infinio Accelerator Management Console. As you can see, we already have a significant improvement in both I/O latency and throughput.
If you have any questions or comments on this post, or any of the posts in the VAIO series, just add them below.
Interested in trying Infinio for yourself?