In vSAN 6.6 vSAN switched from using Multicast to Unicast for new node discovery. This was a huge improvement that improved scalability, simplified deployment and troubleshooting. This drastically simplified layer 3 and stretched cluster deployment as well as reduced configuration times in new clusters being deployed. While upgrading hosts will operate with Unicast between 6.5 hosts, and multicast with prior releases.
One side effect of this feature was that the vCenter became by default an undisputed source of truth for vSAN cluster Membership. This created some slight complications when recovering a vCenter from Backup, or re-deploying a vCenter Server as it documented in the Multicast removal documentation for vSAN 6.6 The core problem could come from a vCenter not being aware of all cluster members purging out members that were not within the vCenter Server’s inventory.
In 6.6.1 vSAN improved this workflow and reduced risk of accidental cluster partition. Now if something causes the membership list to become out of sync, a sequence number system will prevent a vCenter from over-writing the local database on the hosts. A Health Alert will be generated and only once all hosts have been re-added to the cluster an administrator can use health UI to establish re-synchronization without risk of impacting object availability. A critical behavior of a hyper-converged system is self-healing and proactive simple management and monitoring. For other health checks like this be sure to check out the vSAN healthUI that can be checked by GUI, CLI, and API.
For more information read the vSAN 6.6.1 Multicast Removal instructions on StorageHub.
