Management Cluster (Stack?) thoughts

Hi there,

I hope for some comments on this to improve my thinking.


The idea of Management Clusters is not particularly old or new.  My first exposure was when I was part of Integration Engineering in R&D at VMware.  We had a management cluster that held our GA management software, and we had compute clusters that had our alpha and beta software that we tested.  This was mostly in the form of pods.  A pod BTW was a vApp that had within it what you needed to test.  So vRealize Automation was one of the things I was working on at the end of my work at VMware so my vRA pod had vCenter, ESXi hosts, a jump VM I connected to, and an Active Directory VM as well that did among other things, my DNS and DHCP PLUS my vRA VMs.  So it was fully self contained and had all I needed.  Very handy. A co-worker (also gone from VMware) was the View guy so he had a View pod that had all the same stuff as me, except he had next gen View stuff and not vRA. We used the pods for testing different builds and finding bugs and operational issues, and at some point they would become the onsite beta pods that customers used.  Very cool actually and a wonderful useful thing to do.

In the beginning the storage for the mgmt cluster was a couple of dedicated LUNs but it ended up having its own storage array later on. There was also a large NFS share that was common everywhere so as to be able to move things around as necessary – I hope to replace that idea in the future with a Content Catalog. In terms of network, it had its own VLAN(s), but also had shared VLANs and shared networking hardware too.

Management Clusters

I think that my idea of a management cluster would contain:

  • vCenter for the management cluster
  • vCenter(s) for the compute cluster(s)
  • vRealize Operations (vR Ops) for the management cluster and optionally for the compute cluster
  • VMware Infrastructure Navigator (VIN) for the management cluster and optionally for the compute cluster
  • Its own storage – such as VSAN (or maybe in my lab its own Synology)
  • Maybe a VxRail appliance (or something similar) for the mgmt cluster which would mean four nodes in the cluster
  • Log Insight for the mgmt cluster and optionally for the compute cluster.
  • VMware Update Manager (VUM) currently requires a Windows VM and it would be here.  I expect that to change in the near future.
  • Active Directory domain controller, or a NIS / LDAP server as appropriate.
  • In summary, their own hardware, software, and storage plus the management for the compute cluster(s). So likely we need to call this a Management Stack.

Management Clusters – questions

  • I know that vR Ops can handle multiple vCenters and the advantage is being able to look at both environments in the same UI.  In a very large environment perhaps a bad thing and you should have vR Ops for mgmt cluster and another instance for the rest of the environment.
  • I do not know if VIN can work with multiple vCenters, and this might be another reason to have separate vR Ops for mgmt and for compute.
  • Log Insight can handle the thinking above, but if you have separate vR Ops you should have separate Log Insight.  You could still do some forwarding as necessary.
  • Are we using vRA to provision our compute clusters?  If so that would put the vRA infrastructure in the mgmt cluster.
  • Are we using vCD to provision our compute clusters?  If so that would put the vCD infrastructure in the mgmt cluster.


  • I know one customer that put a small View instance into the management cluster so that even if the big corporate View was done they could get into the management cluster.  That was a very small footprint and investment and it paid off for them.
  • In a big vRA or vCD environment I would consider putting their infrastructure into an infrastructure cluster so as to keep the mgmt cluster small. It may, or may not be in the management stack.
  • Things like a PernixData management server, or the root DC, or root anti malware servers could be in the management cluster.
  • I think I know of a customer that put VDPA or now VDP, in the management cluster so it could be even more independent.

Compute Clusters

  • They would have ESXi hosts that are managed from the mgmt cluster with their own vCenter.
  • Web servers, application servers, database servers, backup server, email servers, anti – malware servers would all be in the compute clusters.
  • Compute clusters might be based on geography, application, or department.  Such as New York, Oracle, or HR.  There might be one that is Corporate that has corporate apps like email in it.
  • Domain Controllers, DNS server, DHCP servers, naming servers all too would be in compute clusters – maybe in the Corporate cluster.
  • VDI may be in computer cluster, but it may be in its own stack as well.

I guess a better phrase is actually Management Stack – right?

I am thinking of redoing my lab at home, and making it better.  More customer like even.  So this article is to help me out, but I think it can also help you out too.  Like my vSphere Best Practices article, I use that info and like to have it all in one place but that is also good for you too.

As always, any and all suggestions, comments, and questions are welcome.


=== END ===


2 thoughts on “Management Cluster (Stack?) thoughts

  1. I have typically tried to do the mgmt stack as a separate area in the majority of my designs. I like the view idea in the mgmt stack as that can allow better remote access functionality than normal rdp type access.
    VIN is installed per vCenter but now integrates with vROps instead of in the viclient and SRM. I do know that VCE uses one design that I do like in there mgmt stack. They use local storage for each host and use vSphere replication to replicate the vmdks from one host to the other.

    1. Thanks for the comments Chris. I will test out your VIN / vR Ops comment in the coming days. I think that VCE has quite the idea. I would not do it that way as I lose the ability to use VUM to do host patches. And using VR for the replication of VMs around seems like extra overhead that I would like to avoid. I wonder if VSAN would help in this area – maybe not all flash to help keep costs in line. Again, really appreciate the comments.


Leave a Reply