Tids bits of vSAN 6.6

The VMkernel port is labeled as vSAN. This port is used for intra-cluster node communication and for read and writes when one of the vSphere hosts in the cluster owns a particular virtual machine, but the actual data blocks making up the virtual machine files are located on a different vSphere host in the cluster. In this case, I/O will need to traverse the network configured between the hosts in the cluster.

In all-flash VSAN, which is where deduplication and compression are supported, data blocks are kept in the cache tier while it is active/hot for optimal performance. As soon as the data is no longer active (cold), it is destaged to the capacity tier. It is during this destaging process that VSAN does the deduplication (and compression) processing.

Deduplication on VSAN uses the SHA-1 hashing algorithm, creating a “fingerprint” for every data block. This hashing algorithm ensures that no two blocks of data result in the same hash, so that all blocks of data are uniquely hashed. When a new block arrives in, it is hashed and then compared to the existing table of hashes.

VSAN uses the LZ4 compression mechanism, and it works on 4KB blocks. If a new block is found to be unique, it also goes through compression. If the LZ4 compression manages to reduce the size of the block to less than or equal to 2KB, then the compressed version of the block is persisted to the capacity tier. If compression cannot reduce the size to less than 2KB, then the full-sized block is persisted. We do it this way (deduplication followed by compression) because if the block already exists, then we don’t have to pay the compression penalty for that block.

To be able to access the Virtual SAN datastore, an ESXi host must be a member of the Virtual SAN cluster.

Selecting Allow Reduced Redundancy, vSAN will be able to reduce the protection level of your VMs, if needed, during operations enabling Deduplication and Compression. This option is only usable if your setup is at the limit of the protection level, configured by the Storage Policy of a Specific VM.

In vSAN 6.5 overhead is [1% x (physical disk capacity) + deduplication metadata] which is highly variable and will depend on the data set stored in the vSAN datastore).

Each ESXi host participating in the Virtual SAN cluster will have a provider, but only one needs to be active to provide vSAN datastore capability information.

Some of the normal vSAN recommendations/checks that are not configured as part of the vSAN cluster wizard include:

  1. vSphere Availability
  2. vSphere Distributed Resource Scheduler (DRS)
  3. vSphere Distributed Switch for vSAN Traffic
  4. vMotion configuration
  5. Ensuring all available disks are claimed
  6. Appropriate host controller tools are present
  7. Appropriate host controller firmware

To configure each of these, tasks must be performed in different parts of the vSphere Web Client. Configuration Assist allows these to be done from a single location in the UI. Previously configuring vSAN VMKernel interfaces for vSAN or vMotion traffic required creating these individually on each host or through the vSphere Distributed Switch

wizard.They are now part of Configuration Assist.

SwapThickProvisionDisabled was created to allow the VM swap option to be provisioned as a thin object. If this advanced setting is set to true, the VM swap objects will be thinly provisioned.

The RAID-5 or RAID-6 configuration is determined by the number of failures to tolerate setting. If this is set to 1, the configuration is RAID-5. If this is set to 2, then the configuration is a RAID-6.

Reserved flash capacity cannot be used by other objects.

Force Provisioning: Use this parameter in bootstrapping scenarios and during an outage when standard provisioning is no longer possible.