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.
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.
- 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 ===