This is a question that has come up a number of times. Many of you will now be familiar with the VM Storage Policy capability Number Of Failures To Tolerate for VSAN, which defines how many failures can occur in the VSAN cluster and still provide a full copy of the data to allow a virtual machine to remain available. In this short post, I will explain how many physical ESXi hosts you need to accommodate the Number of Failures To Tolerate requirement in the VM Storage Policy.
In this post, we talk about a particular behaviour with using the default (or None) policy with VSAN. I have stated many times in the past that when a VM is deployed on the VSAN datastore, it behaves like it is thinly provisioned unless the capability ‘Object Space Reservation’ (OSR) is specified in the VM Storage Policy. The OSR will pre-allocate space on the VSAN datastore for the virtual machine’s storage objects, and is specified as a percentage of the actual VMDK size. However, there is a slightly different behaviour when the default policy is used. Once again, I was in a conversation with a customer who stated that when he used the default policy of “None”, he could see space being consumed on the VSAN datastore was equal to the size of the VMDK * FTT (Number of Failures To Tolerate). He wondered why this was the case when the default policy clearly did not contain an Object Space Reservation capability.
Those of you familiar with VSAN will know that one of the capabilities which can be placed in a VM Storage Policy is Number of Disk Stripes Per Object (stripe width for short). I covered this in an earlier post which looked at the various VSAN capabilities. Recently, a customer who had not specified a stripe width in the VM Storage Policy was perplexed to find that his storage objects had indeed been striped across a number of disks. He reached out to me if I could provide an explanation.
I thought it might be useful to share some of the various VM Storage Policy status that I have observed whilst testing Virtual SAN (VSAN). I’m sure this is by no means a complete list but as I said, these are the ones that I have come across and I am sure these are the status that you will observe most often too.
Continuing on my set of posts related to Virtual SAN (VSAN) interoperability, let’s take a look at how vCenter Operations Manager (vC Ops for short) integrates with Virtual SAN. vC Ops version 5.8, which was released in December 2013, recognizes the VSAN datastore and can report various characteristics, as you might expect. Although vC Ops 5.8 was released around 3 months before VSAN GA’ed, this release works with ESXi 5.5U1 and vCenter 5.5U1, the vSphere release which introduced VSAN. However, this release of vC Ops does not present all the ‘storage’ metrics for VSAN like it does for datastores based on other storage types. But, having said that, there are still a number of useful vC Ops views and metrics that you might find useful which this post will cover.
At this stage, VSAN has only been in GA for a number of weeks, even though many of us here at VMware have been working on it for a year or two (or even more). Sometimes when we get into explaining the details of storage objects, components, etc, we forget that this is all so new for so many people. In a recent post, someone asked me to explain the concept of a witness on VSAN. Looking back over my posts, I was surprised to realize that I hadn’t already explained it. That is the purpose of this post – explain what a witness disk is in VSAN, and what role it provides.
In a previous post I spoke in-depth about the different objects which go to make up a virtual machine which resides on a VSAN datastore. To recap, these are the VM Home Namespace, the VM Swap, the VMDK objects and the snapshot delta objects. Now, VMDKs comply with the full set of rules that are placed in a VM Storage Policy and applied to a virtual machine. Snapshot deltas inherit the same VM Storage Policies as their VMDK base disk and also comply with the full set of rules in the VM Storage Policy – so far so good. VM Home Namespace is a little different – its behaviour and which capabilities it complies with are discussed in this earlier article. This leaves the VM Swap object, and that is what I plan to cover in this article.