Tuesday, August 20, 2019

VMware vSAN 6.7 U3 has been released

VMware vSAN 6.7 U3 is GA as of August 20, 2019!
This is a great release. I was waiting mainly for Native support for Windows Server Failover Clusters which is now officially supported so no more vSAN iSCSI targets and in-Guest iSCSI for shared disks across the WSFC as vSAN VMDKs now support SCSI-3 persistent reservations. This is a great improvement and significant simplification for vSphere / vSAN architects, technical designers, implementers, and operational guys. For further details see blog post "Native SQL Server Cluster support on vSAN

The second feature I like a lot is the performance improvement. Performance improvements and better performance predictability are always welcome. More predictable application performance is achieved in vSAN 6.7 U3 by destaging data from the write buffer to the capacity tier. This makes vSAN more efficient and consistent with increased throughput for sequential writes. The increased consistency in destaging operations results in a smaller deviation between high and low latency. This increased throughput also reduces the amount of time necessary for resyncs from repairs and rebuild tasks. The destaging improvement is depicted in the figure below.


However, there are other operations and availability improvements in 6.7 U3. Let's highlight the vSAN 6.7 U3 improvements one by one as published in Release Notes.
What's New?
Cloud Native Applications
Cloud Native Storage: Introducing vSphere integrated provisioning and management of Kubernetes persistent volumes (PVs) and a CSI (Container Storage Interface) based plugin. This integration enables unified management of modern and traditional applications in vSphere.
Intelligent Operations
Enhanced day 2 monitoring: vSAN’s capacity dashboard has been overhauled for greater simplicity, and the resync dashboard now includes improved completion estimates and granular filtering of active tasks
Data migration pre-check report: A new detailed report for greater insight and predictive analysis of host maintenance mode operations
Greater resiliency with capacity usage conditions: Key enhancements include reduced transient capacity usage for policy changes, and improved remediation during capacity-strained scenarios
Automated rebalancing: Fully automate all rebalancing operations with a new cluster-level configuration, including modifiable thresholds
Native support for Windows Server Failover Clusters: Deploy WSFC natively on vSAN VMDKs with SCSI-3 persistent reservations
Enhanced Performance & Availability
Performance enhancements: Deduplication & compression enabled workloads will have improved performance in terms of predictable I/O latencies and increased sequential I/O throughput
Availability enhancements: Optimizations to sequential I/O throughput and resync parallelization will result in faster rebuilds
For further details about vSAN 6.7 U3 read blog post vSAN 6.7 Update 3 – What’s New available at https://blogs.vmware.com/virtualblocks/2019/08/13/vsan67u3-whats-new/

7 comments:

Unknown said...

How does wsfc on native vSAN work?
Screenshots are helpful
Thanks

David Pasek said...

VMware supports shared VMDK's n Multi Write Mode for ages. The only problem was that it did not support SCSI-3 so it was not supported for WSFC. This is changed with vSAN 6.7u3.

You can read my older blog post "VMware virtual disk (VMDK) in Multi Write Mode"
https://www.vcdx200.com/2018/10/vmware-virtual-disk-vmdk-in-multi-write.html
where you can see some screenshots.

Another blog post is here
https://blogs.vmware.com/virtualblocks/2019/08/23/vsan67-u3-wsfc-shared-disksupport/

Or read Cormac Hogan's blog post here http://cormachogan.com/2019/08/27/whats-new-in-vsan-6-7u3/

[SNIP from Cormac blog]
While we have been able to support WSFC (Windows Server Failover Clusters) on vSAN for some time through the use of iSCSI, this is a significant improvement over that implementation. vSAN 6.7U3 can now support SCSI-3 persistent group reservations (PGR) natively, which in turn means that a VMDK residing on vSAN can now be used as the shared quorum disk for WSFC implementations. I know of a number of customers who were looking for this functionality, and I'm delighted that we can now officially announce it. Do note however that this is for virtualized WSFC environments. If you are using physical servers, you should continue to use the vSAN iSCSI service method to share a quorum disk. There are a number of other caveats to take into account as well when a VMDK is shared via this SCSI-3 PGR mechanism. Please refer to the official documentation for full details.
[/SNIP]

And here is the link to the official documentation
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vsan-planning.doc/GUID-DC8E1129-E58E-4684-948C-66E28F5C35CB.html?hWord=N4IghgNiBcIOoGUBiBhEBfIA

Hope his helps.

David Pasek said...


How does wsfc on native vSAN work?
You can reed details and see screenshots in blog post "Native SQL Server Cluster support on vSAN" at https://blogs.vmware.com/virtualblocks/2019/03/04/native-sql-server-cluster-support-on-vsan/

Anonymous said...

Running vsan 6.7u3 and win server 2016, and have followed the guides exactly, but cant get it to work for some reason.

David Pasek said...

It should work. If not, I would open a support request with VMware Support (aka GSS).

Anonymous said...

Thanks for the reply David, I did, unfortunately they are so slow and not proacvtive at all. Both microsoft and vmware having been passing the buck with me on this issue. I've been working on this for months now. The failure happens when I disconnect the NIC on the Owner Node. I understand this is an unlikely scenario but it should still work. In the debug, I can see the Owner node sending the SCSI-3 PR Release command, and I see the Secondaryu node trying to failover the disk but it fails. This is the error
Cluster physical disk resource terminate encountered an error.

Physical Disk resource name: Cluster Disk 2
Device Number: 3
Device Guid: {b5cc7ebd-47f3-fd7d-6466-ff8d70652db7}
Error Code: 1168
Additional reason: ReleaseDiskPRFailure

David Pasek said...

Hmm. Very interesting. Can you share with me SR#? You can share it here or if you want more privacy communication, you can send it to david.pasek (at) gmail.com or as a direct message to Twitter @david_pasek