It is fair to say that VMware vSphere’s clustering technology introduced the concept, and the common practice of the management cluster. Now a staple of data centers large and small, most administrators have experience with running some form of a management cluster. While management clusters come in all shapes and sizes, the intention is largely the same: establish a boundary of resources to run an assortment of systems supporting the infrastructure to aid in the operation of a data center. With vSAN becoming commonplace for so many of our customers, eventually, the question is asked on whether a management cluster should be powered by vSAN. The short answer is “absolutely!” But let’s go into why this approach makes sense.
With three-tier architectures, management clusters are often the result of little more than the act of carving out a simple cluster in vSphere, and moving the appropriate VMs supporting the infrastructure to the new cluster. While this does help isolate some resources such as compute and memory, it doesn’t always meet the desired outcome. The following are examples of what can be found in suboptimal management cluster implementations.
- A management cluster using the same storage array(s) that the production clusters are using. This can pose real challenges (such as circular dependencies) in maintenance scenarios of the array or the backing fabric used for connectivity. Arrays that serve multiple clusters can also be subject to noisy neighbor issues, where VMs from one cluster are unduly impacting the performance of VMs in another cluster.
- A storage array no longer under manufacturer maintenance repurposed for use with the management cluster. This starts out with good intentions, as the administrator may have recognized the need for independent storage. It shoehorns in a solution using unsupported hardware that would have otherwise been decommissioned. This is a practice that gives the illusion that it is a cost-effective option, but introduces risk, complexity, and just isn’t an effective long-term strategy.
- Direct attached, local storage. This attempts to work around the need for shared storage, but compromises the availability of infrastructure related VMs. What starts out as a simple idea ends up being an administrative burden that puts availability at risk.
- Partial or full use of the same network connectivity as production clusters. This can occur quite often with clusters that do not have sufficient network topologies that support some level of segregation with other network switching.
These options result in potential compromises in resiliency, the contention of resources, and adding operational complexity associated with these risks.
A vSAN powered management cluster
vSAN helps address the challenges with designing a fully independent management cluster. Unlike three-tier architectures, vSAN treats storage as a cluster resource. Beyond the granular capabilities that storage policy based management gives to VMs running within the cluster, this model isolates storage traffic to VMs living within that cluster, as shown in Figure 1. This is what greatly simplifies dependency trees during planned and unplanned maintenance events. Lines of demarcation are clear with vSAN.
Figure 1. Storage I/O properly segregated when using a vSAN powered management cluster.
Most importantly, vSAN addresses the common issues outlined in an easy, flexible way. Instead of using the wrong resource for the job, one can tailor the build of the vSAN cluster that is most fitting for these infrastructure level services. For instance, to meet the demands of your other workloads, maybe your typical vSAN cluster typically consists of dual-processor hosts with 3 disk groups per host. Perhaps the VMs targeted for a management cluster are not as resource intensive. One could build a vSAN management cluster using single processor hosts with two disk groups per host. A vSAN powered management cluster allows you to right-size your resources, and your licensing. A four-node management cluster would give you the ability to set a level of failure to tolerate of 1 on the management VMs, and maintain that level of resiliency even with an additional host is taken offline for maintenance.
Management clusters running vSAN can easily adapt to change. Some smaller environments choose to run their log aggregators and infrastructure analytics applications in their management cluster. Performance and protection objectives can easily be controlled per VM or VMDK using storage policies. As the environment grows, resources can be added to that same cluster by scaling up or scaling out. Eventually, those specific workloads may be shifted to another cluster if the desire is to keep the management cluster relatively small.
Since vSAN communicates over traditional IP networking, many environments have more flexibility when it comes to providing a switch topology that is independent of switchgear serving other clusters, versus their dedicated storage fabrics. This allows cluster design to address a desired result for the applications, rather than comply to a current constraint of hardware, or a topology.
vCenter on vSAN
What about running vCenter on vSAN you might ask. Isn’t there a dependency? While vCenter is the most common way to interact with a vSAN cluster, much of the vSAN control plane resides across the hosts that make up the cluster. The data path, and all low-level activities such as object management, health, and performance monitoring are all independent from vCenter. If for some reason the management cluster needs to be powered off, this can be achieved using the common method used for shutting down and powering on a vSAN cluster. The VMware ESXi host client includes all of the abilities to easily power on and off hosts in a vSAN cluster, and even includes access to many vSAN related functions. And finally, in a worst-case scenario, a backup of vCenter can be restored, or a pristine vCenter can be built to replace a vCenter server for existing vSAN hosts. In other words, vCenter is commonly run on vSAN, whether it is residing on a dedicated management cluster powered by vSAN, or living on another production cluster running vSAN.
Conclusion
Powering your vSAN management cluster makes sense. It provides an easy way to run systems that support the infrastructure in an independent manner, without compromising availability and operational objectives. For more information on using vSAN in a management cluster, see this use case about this topic: vSAN for Independent cluster management out on StorageHub.
