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…
If you’ve been following my series on VSAN 6.2 blog posts, you’ll be aware of a considerable number of new features, especially around space efficiency, such as deduplication and compression. On top of this, there is a new on-disk format (v3) and a new software checksum mechanism. All of these features introduce some capacity overhead in their own right, so as to allow administrators track where the storage consumption is occurring a brand new capacity view has been introduced with VSAN 6.2.
Many seasoned VSAN administrators will know how heavily we rely on VSAN Observer to get an understanding of the underlying performance of VSAN. While VSAN Observer is a very powerful tool, it does have some drawbacks. For one, it does not provide historic performance data, it simply gives a real-time view of the state of the system as it is currently, not what it was like previously. VSAN Observer is also a separate tool and is not integrated with vSphere web client, thus you didn’t have a “single pane of glass” view of the system. The tool is also complex,…
Those of you who have a good understanding of VSAN at this stage will know that a virtual machine deployed on the VSAN datastore is deployed as a set of objects, and not a set of files, which is how a VM is deployed on traditional datastores. Those objects include the VM Home Namespace, VMDKs and of course VM Swap. VM Swap is interesting, in that it only exists when the VM is powered on, but on VSAN it has always been provisioned with 100% Object Space Reservation in the past. This has some drawbacks, since it tended to consume…
VSAN 6.2 has a new quality of service mechanism which we are referring to as “IOPS limit for object”. Through a policy setting, a customer can set an IOPS limit on a per object basis (typically VMDK) which will guarantee that the object will not be able to exceed this amount of IOPS. This is very useful if you have a virtual machine that might be consuming more than its fair share of resources. This policy setting will ensure that there are “guard rails” placed on this virtual machine so it doesn’t impact other VMs, or impact the overall performance…
This next part of the VSAN 6.2 series of posts focuses on an important feature which many customer have been requesting. VSAN 6.2 introduces another new feature, end-to-end software checksum, to help customers avoid data integrity issues arising due to problems on the underlying storage media. In VSAN 6.2, checksum is enabled by default, but may be enabled or disabled on per virtual machine/object basis via VM storage policies. Checksum is enabled by default as we feel customers will always want to leverage this great new feature. The only reason one might disable it is if the application already has…