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…
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…
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…
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.
The folks from the Nordic VMUG team in Denmark were kind enough to record my Virtual SAN (VSAN) session in Copenhagen last week. If you are interested in VSAN, or considering a VSAN evaluation or Proof of Concept, then this might be worth watching. In it, I cover design considerations, troubleshooting tools, monitoring and performance, as well as some common gotchas. I close with some VSAN futures. Enjoy!