A commonly asked question is “What happens to vSAN when vCenter Server is offline?” The answer is simple: nothing. vSAN continues to operate normally and virtual machines continue to run. This article briefly discusses the impact to vSAN of vCenter Server being offline temporarily and the implications of a permanent loss of vCenter Server.
When vCenter Server is offline, the main disadvantage is we lose the full-featured functionality of the vSphere Web Client until vCenter Server is back online. However, that does not mean we are “flying blind” when it comes to vSAN management and monitoring. With vSAN 6.6 and newer versions, we can point a web browser directly at the ESXi management IP or FQDN of any host in the vSAN cluster and log in to the vSphere Host Client to monitor vSAN. As seen in the screenshot below, many of the vSAN Health items are visible in this UI.
When vCenter Server is back online, we can get back to managing the environment using the vSphere Web Client. However, if vCenter Server is permanently lost, this might seem a bit scary. Fortunately, vSAN is resilient in this situation. A new vCenter Server can be deployed and the existing vSAN hosts can be added to the new vCenter Server—all without VM downtime.
Here are the steps I started with to introduce a new vCenter Server instance to the environment:
- Deployed a new vCenter Server Virtual Appliance (VCSA).
- Added my licenses for vCenter Server, vSphere, and vSAN (and any other licenses you had in the previous vCenter Server instance).
- Created a datacenter object in vCenter server.
- Created a cluster object and checked the vSAN “Turn ON” box.
- Added the existing vSAN hosts to the cluster.
With vSAN 6.6 and newer versions, vCenter Server maintains a list of hosts that is considered the “source of truth” for the cluster configuration. As demonstrated above, vSAN will continue to operate if vCenter Server is offline. Deploying a new vCenter Server means the “source of truth” in the new vCenter Server instance will not match the configuration maintained by the vSAN hosts—even if there were no changes made to the existing vSAN cluster. This discrepancy in cluster configuration between the hosts and the new vCenter Server instance will be reported in vSAN Health.
Resolving this issue is a simple matter of clicking the Update ESXi configuration. BEFORE DOING THIS, be sure to review the associated knowledge base article which is accessed by clicking the Ask VMware button. Issues could occur if the configuration of the vSAN hosts does not match the cluster configuration in vCenter Server. For example, if deduplication and compression are enabled for the hosts, but the cluster configuration in vCenter Server has deduplication and compression disabled, this change (deduplication and compression disabled) will be pushed to all of the hosts.
This scenario might also apply if you restore a vCenter Server from backup media. Hopefully, you never encounter this issue. If you do, it is good to know that virtual machines do not incur downtime and the process to deploy a new vCenter Server instance to an existing vSAN cluster is fairly simple and non-disruptive.
@jhuntervmware
