The vSAN health service can check for the consistency of cluster-wide settings such as deduplication and compression, encryption, and fault domains. There are additional cluster health checks that can aid in the effort of rebuilding a vCenter server for an existing vSAN cluster. John Nicholson describes this nicely in the post vCenter Recoverability Improvements. These health checks can be especially useful in scenarios that include adding hosts to a vSAN cluster during periods in which vCenter was offline, restoring an older vCenter server from backup, and creating a new installation of a vCenter Server for an existing vSAN cluster. This health check will check for, and remediate any consistency issues that are seen with host membership and settings. The vCenter authority health check is a new health check introduced to vSAN 6.6.1 to verify host membership consistency between vCenter and the hosts in the cluster. VSAN 6.6 transitioned from the use of multicast to unicast for all host membership activities, and under the new architecture, maintains this in vCenter, as well as distributing the membership information across the hosts in the cluster. vCenter has never been responsible for any data path, or object management activities with vSAN. While vCenter plays an important role in the interactive management of a vSphere cluster, vSAN is sufficiently decoupled from vCenter to ensure continued operation if vCenter is offline, or rebuilt from a new installation. The scenario shown below helps describe how vSAN, and vCenter behaves when adding hosts previously participating in a vSAN cluster to a new, pristine vCenter server. Accounting for unplanned events is always a top-of-mind concern for data center administrators. Since VMware vCenter is used as a common control and management plane for a vSphere cluster, questions may arise when determining how a vSAN cluster reacts when a vCenter server must be rebuilt from a new installation, or restored from a backup.

Add vspace server