In the VSAN 6.0 Design & Sizing Guide, a caveat was placed around the size of a VMDK, and the Number of Failures to Tolerate (FTT) number. It reads like this: “If the VMDK size is greater than 16TB, then the maximum value for NumberOfFailuresToTolerate is 1.” I’m pleased to say that this restriction has been lifted in VSAN 6.2.
I’ve noticed a couple of customers experiencing a Component Metadata Health failure on the VSAN health check recently. This is typically what it looks like: The first thing to note is that the KB associated with this health check states the following: Note: This health check test can fail intermittently if the destaging process is slow, most likely because VSAN needs to do physical block allocations on the storage devices. To work around this issue, run the health check once more after the period of high activity (multiple virtual machine deployments, etc) is complete. If the health check continues to fail the…
Our friends over at Pearson and VMware Press have informed us that the second edition of the Essential Virtual SAN book (that I wrote with Duncan Epping) is now available for pre-order on Amazon. It looks like it will be available on June 13th, but VMware Press have told us that they will do what they can to pull the date in a little closer. This new edition covers all of the new features added to Virtual SAN, up to the latest (yet to be released) VSAN 6.2. Here’s some blurb on the new edition, which gives a little insight…
Earlier this month I had the opportunity to meet with a number of VMware customers in both Singapore and in the UAE. Most of the sessions were enablement and education type sessions, where there was a lot of white-boarding of VSAN (VMware’s hyper-converged infrastructure product) and Virtual Volumes (VVols – Software Defined Storage or SDS for the storage arrays). This wasn’t a sales session; I’m not in sales. The objective of these sessions was simply to educate. I guess when you are immersed in this stuff 24×7, it easy to fall into the trap of believing that everyone is well…
In this post, I want to talk about a feature called Problematic Disk Handling. Some history behind why we have such a feature can be found in this post. In VSAN 6.2/vSphere 6.0 U2, Problematic Disk Handling has been improved so that it will unmount a problematic disk/diskgroup for two reasons:
There might be a reason in VSAN stretched cluster environments or in 2-node VSAN ROBO deployments to change the witness appliance. The one thing to keep in mind is that you must use a witness appliance that has the same on-disk format as the rest of the disk groups in the cluster. Right now, there is a 6.1 version of the appliance and a 6.2 version of the appliance, so make sure that you select the correct one. Replacing the current witness with a new witness is very straight forward, and the tasks can be summarized as follows: Deploy the…
This is an exercise that we ran through in our lab environment, and we thought that the steps would be useful to share here. By way of introduction, our 4 node cluster is split into a 2+2+1 configuration, where there are 2 ESXi hosts on site A (VLAN 4), 2 ESXi hosts on site B (VLAN 3), and a third site, site C (VLAN 80), hosting the witness appliance (nested ESXi host). All sites are connected over L3. In other words, static routes are added to each of the ESXi hosts so that ESXi hosts on site A can reach…