I was having some discussions recently on the community forums about Virtual SAN behaviour when a VM storage policy is changed on-the-fly. This is a really nice feature of Virtual SAN whereby requirements related to availability and performance can be changed dynamically without impacting the running virtual machine. I wrote about it in the blog post here. However there are some important considerations to take into account when changing a policy on the fly like this.
Yesterday I posted an article which discussed some common misconceptions with Virtual SAN that come up time and again. Once I published that article, I immediately had an additional question about basic VSAN behaviour and functionality related to stripe width. More specifically, the question is how many disks do you need to satisfy a stripe width requirement. Let’s run through it here.
I’m currently neck-deep preparing for the next version of Virtual SAN to launch. As I prepare for all the new features that are coming (that I hope to be able to start sharing with you shortly), I’m still surprised by the misconceptions that still exist with regards to basic Virtual SAN functionality. The purpose of this post is to clear up a few of those.
I was involved in an interesting case recently. It was interesting because the customer was running an 8 node cluster, 4 disk groups per host and 5 x ~900GB hard disks per disk group which should have provided somewhere in the region of 150TB of storage capacity (with a little overhead for metadata). But after some maintenance tasks, the customer was seeing only 100TB approximately on the VSAN datastore.
This was a little strange since the VSAN status in the vSphere web client was showing all 160 disks claimed by VSAN, yet the capacity of the VSAN datastore did not reflect this. So what could cause this behaviour?
I’m sure many of you will be attending Partner Exchange next month in the Moscone Center in downtown San Francisco. I did not expect to be attending this year, but I got a request to co-present a Virtual SAN Proof Of Concept/Evaluation session. I’ve delivered a similar session at a number of EMEA VMUGs recently. This presentation seems to have been well received to date, and I’m hoping it will got down well at Partner Exchange also. The session details are as follows:
- STO4289 – Conducting a Successful Proof of Concept for Virtual SAN
[update] I checked the schedule builder and now see that this session will be held on PEX Day 1, Tuesday, February 3rd from 5PM – 6PM. I’ll be presenting with Noel Nguyen who is director of our storage system engineering. Hope to see you there.
In a previous post, I discussed the difference between a component that is marked as ABSENT, and a component that is marked as DEGRADED. In this post, I’m going to take this up a level and talk about objects, and how failures in the cluster can change the status of objects. In VSAN, and object is made up of one or more components, so for instance if you have a VM that you wish to have tolerate a number of failures, or indeed you wish to stripe a VMDK across multiple disks, then you will certainly have multiple components making up the VSAN object. Read this article for a better understanding of object and components. Object compliance status and object operation status are two distinct states that an object may have. Let’s look at them in more detail next.
As part of a quick reference proof-of-concept/evaluation guide that I have been working on, it has become very clear that one of the areas that causes the most confusion is what happens when a storage device is either manually removed from a host participating in the Virtual SAN cluster or the device suffers a failure. These are not the same thing from a Virtual SAN perspective.
To explain the different behaviour, it is important to understand that Virtual SAN has 2 types of failure states for components: ABSENT and DEGRADED.