Once again we return to cover another objective. It has been hectic lately, with delivering my first ICM 6 class and also delivering a vBrownBag the same week on one of the future objectives. Now we are back though and trying to get in the swing of things again. Here are the sub-points we will be covering this time:
Without further ado lets dig in. Storage Multi-pathing is a cool feature that allows you to load balance IO and also allows for path failover in the event of failure. Storage plays a rather important path in our virtualization world, so it stands to reason that we would want to make sure that it is as fast and as reliable as possible. We have 3 multi-pathing options available by default, but have the ability to add more depending on the storage devices we have in our environment. For example, Equallogic adds a new Multi-pathing PSP when you are using their “MEM” kit. The default policies are as follows:
Defining which of these we want to use we can choose how we load balance and failover paths. Of course we should probably get a better understanding of what they do in order to make the best choice.
How do we configure and manage these? We will need to do the following
And that is how we configure it.
Moving on to features of the PSA or Pluggable Storage Architecture now. To manage storage multipathing, ESXi uses a collection of Storage APIs. This is also known as the Pluggable Storage Architecture. It consists of the following pieces
Using the storage APIs, as mentioned before other companies can introduce their own Pathing Policy. Here is a good picture on how everything aligns
Storage Array Type Plugins or SATPs are run in conjunction with VMWare NMP and are responsible for array-specific operations. ESXi offers a SATP for every type of array it supports, and it also provides for default SATPs for active-active and active-passive and ALUA arrays. These are used to monitor the health of each path, report changes in them, and do necessary actions to failover in case of something going wrong.
Storage Policies are next on the agenda. Storage Policies are a mechanism that allow you to specify storage requirements on a per VM basis. If you are using VSAN or Virtual Volumes, then this policy can also determine how the machine is provisioned and allocated within the storage resource to guarantee the required level of service.
In vSphere 5.0 and 5.1 storage policies existed as storage profiles and had a different format and were not quite as useful. If you previously used them, when you upgrade to 6.0 they would be upgraded to the new Storage Policy.
There are 2 types of storage policies. You can base them on abilities or Storage-Specific data services, or you can use reference tags to group them. Let’s cover both of them a little more in depth.
Rules based on Storage-Specific Data Services
These rules are based on data services that storage entities such as Virtual SAN and Virtual Volumes advertise. To supply this information, these products use storage providers called VASA providers. This will surface the possible capabilities that are available to VMWare for you to put in your Storage Policy. Some examples of this include capacity, performance, availability, redundancy and so on.
Rules based on Tags
Rules based on tags reference datastore tags that you associate with specific datastores. Just like tags on other objects that, you as an administrator can apply, you can apply tags to a datastore. You can apply more than one tag to a single datastore. Once you apply a tag to a datastore, it will show up in the Storage Policies interface, which you can then use to define the rules for the storage policy.
So how do we use these? There are a number of steps we need to perform to enable these and apply them. The very first thing we need to do is to enable Storage Policies on a host or Cluster. To do that, perform the following steps:
Now you can define your VM Storage policy. For the first one we will work on the Tag based policy.
Now you can create a storage policy based on this tag. You do that by navigating to the same place where you enabled the policies.
The next thing to do to make this active is to apply it to a VM. You can do this when you create the VM or afterwards. If you are applying it afterwards, you will need to do it by going to the Settings of the VM and then clicking the little arrow in front of the Hard Disk. Next choose the Storage Policy you want from the drop down box
Now you have achieved your goal. You can go through the same steps with either policy.
Last thing we will need to go over is Enabling and Disabling Fault Domains for Virtual SAN. I don’t have a VSAN setup (if anyone wants to contribute toward my home lab fund let me know..J ) But if you did, you would enable them underneath the settings for the cluster. Then you would go to Manage and then VSAN. Underneath that sub category you will find Fault Domains. This is where you would create/enable/disable Fault Domains.
And thus concludes another objective. Next up, VMFS and NFS datastores. Objective 3.4