As always a lot of new features come with new major version but VMware invested a lot in the latest version 6.7 of VSAN and brought us a lot of exciting things stretching from the support model to advanced technical improvements. In this post, we are going to highlight all this goodness.
HTML5 web interface
Awaited for a long time, 6.7 brings the new HTML5 interface to VSAN based on the “Clarity” framework for clearer and responsive browsing which will be great for day to day management. Some of the features of the old client are still missing in the new one but nothing preventing you from using it as it is not things you use every day like configuration assist or the vmkernel VSAN service enabled check.
Note that the HCL database update is now configured at the vCenter level for all clusters rather than the cluster level like it used to be.
Native vRealize integration
Just like for vSphere, the new UI now includes vROPS dashboards if the vROPS Client Plugin is installed (embedded in vCenter). Again it will make administering and troubleshooting easier by not having to switch between two separate user interfaces. You now have access to a bunch of vROPS metrics straight away and you can launch the full vRops user interface from there for further intelligence.
Note that this feature is only available in VSAN Advanced and Enterprise editions.
VSAN ReadyCare
ReadyCare is VMware’s go at simplifying and improving the support experience of VSAN in order to reduce the time to resolve support requests, holistic support experience as they call it. It leverages VSAN Support Insight for predictive analytics, that was delivered in VSAN 6.6 (Which uses CEIP), and cloud based health checks. This way, additional health checks can be added by VMware regularly without the need to upgrade vSphere, and with the Ask VMware button, you have a handy-dandy way to open the associated KB. In 6.7 VMware added over a dozen new health checks, raising the total to over fifty. Here are a few of the new health checks:
- Host maintenance mode verification
- Host consistency settings for advanced settings
- Improved vSAN and vMotion network connectivity checks
- Improved vSAN Health Service installation check
- Physical Disk Health checks combine multiple checks into a single health check
- Improved HCL check. Firmware checks are now independent of driver checks
Support for Windows Server Failover Clustering(WSFC)
It is now possible to run Microsoft clusters (WSFC) creating an iSCSI target and exposing it to the virtual machines that will be nodes in the cluster. Note that both virtual and physical machine can benefit from this shared target storage locations.
Stretched Cluster Availability
Witness Traffic Separation
You can now configure a network interface to separate data traffic from witness traffic in stretched clusters by tagging a vmknic for witness traffic. The connection for the Witness traffic requires only 100MBps and 200ms RTT. For now, it can only be done in esxcli but I’m sure the UI integration will come in future releases and it’s not like you are going to do it every day.
Preferred Site Override
This one fills a gap left open in previous versions rather than adding a new functionality. It makes sure VMs remain available in the secondary site should the primary one come back up after a failure and has connectivity only to the Witness. Meaning the secondary site is maintained as an active site until the link between the sites comes back. Not a scenario you encounter every day but it should give you peace of mind.
Efficient Resync
When a site came back up after a failure it needs to bring the components up back to the same level. While the other location is still working, as usual, it must catch up on what it missed when the network or site was down. Instead of copying all the components to rebuild across the ISL (Inter Site link), VSAN will use a “proxy host” on the target site. It will resync only one copy of each component to this host that will, in turn, copy it to its peers in the local site. This mechanism saves bandwidth on the ISL to leverage LAN connections, hence reducing the resync time, nice.
vSAN Host Pinning
Not many folks will get to be excited by that one but hey, it’s new! Here is new storage policies that maintain a single copy of the data on the local host where the VM runs. It is mostly aimed at big data workloads like Hadoop and sorts that handle data redundancy at the application layer. However note, that it requires VMware’s validation to ensure proper deployment.
Adaptive Resync
This feature enhances the resync mechanism by ensuring that the guest traffic does not suffer (too much) from the resync operation when congestion is detected. In order to achieve this, VSAN will limit the resync traffic to 20%, leaving 80% of the bandwidth for VM traffic. The components will take longer to rebuild but the service won’t be impacted as much.
Efficient and consistent storage policies
If you played with VSAN before, you may be used to enable the advanced setting SwapThickPrivisionDisabled. In previous versions, the swap object of a VM was thick provisioned (100% reserved) which used up a lot of space on the VSAN datastore incurring wasted capacity that could be quite chunky with big VMs. In the new release, the swap object will be thin provisioned by default and will inherit the storage policy of the VM rather than VSAN default storage policy. You no longer need to fiddle with the advanced settings here.
Fast Decommissioning of Host Trough Replica Consolidation
The operation of decommissioning a VSAN component involves the evacuation of the data off it. Over the lifetime of the cluster, the different components get split and distributed into smaller chunks for reasons other than storage policy. Now if a fault domain already hosts a replica component and has enough space, VSAN will try and consolidate all these components into one replica. It has the benefit to be faster and tidier.
Faster destaging
Destaging is the action of moving the data from the cache layer to the capacity layer. This also is where deduplication and compression happens. In VSAN 6.7, the destaging of this data to the capacity layer happens quicker which allows the cache layer to accept new IOs, which in turns improves performances.
Fast Network Failover
Just like iSCSI and port binding, you can have either one vmkernel with VSAN traffic attached to multiple vmknics or multiple vmkernels with VSAN traffic each attached to a single vmknic. Most people will go for the former but some may prefer the latter for specific reasons. In this case, the time it took to failover between vmkernels used to be way too long (~90sec). In 6.7 this timeout has been reduced to a few seconds at most.
Enhanced Diagnostic Partition
If you are not familiar with it, the diagnostic partition is one of the partitions created during the ESXi install process. It is used to store the coredump that are generated when a crash happens. Historically this partition had a fixed size, which could be an issue for the system equipped with large amounts of memory. In previous versions, VMware provided a scripted method to manually extend the size of the diagnostic partition but this is not the type of things you want to be doing in your production environment I believe. From now on, ESXi will resize the size of the diagnostic partition if there is free space.
Support for 4Kn Disks
As opposed to 512n and 512e, 4Kn disks directly expose 4KB as its logical and physical sector size. The other types are 512n which have a logical and physical sector size of 512 Bytes and 512e (the advanced version) with physical sectors of 4K and logical ones emulated at 512 Bytes to be used with OSs that do not support 4Kn sectors yet. But performance problems occur if the workload I/O’s is either not aligned at a 4KB offset from the start of the disk or are not 4KB in length
The good thing about the 4Kn drives is that they have a high density and don’t suffer from the issues of the sector emulation performed by the 512e drive. They also require less space for metadata, thereby increasing a disk’s capacity. However, the compatibility with the existing system is the main drawback at the moment. VSAN now support these types of drives.
FIPS 140-2 level 1 validation
That one is a little more obscure and probably not a lot of folks will feel concerned by it but it is worth mentioning. FIPS (Federal Information Processing Standard) 140-2 is a U.S. government security standard used to approve cryptographic modules. The VMware VMkernel Cryptographic Module v1.0 has achieved FIPS 140-2 under the Cryptographic Module Validation Program (CMVP). vSAN now leverages the same module for vSAN Encryption. The U.S. gov can now use VSAN!
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
