The idea behind a management cluster is to form a pool of compute that manages the other pool of compute. Much like a tug boat pulling along some massive tanker, it exists as a separate entity to provide management in an out-of-band fashion. These are often a great idea, akin to the rationale of sticking iLO cards on an HP server – sometimes bad things happen, and you need a way to fix them that don’t exist inside of the smoking crater that was decimated. But there is no reason to reserve this idea to only large scale, production ready, enterprise environments – your own home lab can (and should) enjoy these features!
Here are three big reasons to have a management cluster, be it one standalone hosts or an HA pair of them, for your home lab.
1) Home Labs Explode … Often
In fact, that’s sort of the point of a home lab. Unlike a real, production environment, a lab is an area where you can go in with guns blazing and have no fear of causing harm. If something breaks, you’ve learned a valuable lesson that will save you the same headache, usually amplified, in your production environment. But there’s a darker side to this – what if you broke your storage array and lost all your data? Re-building an entire lab environment, even from backups, is a non-trivial amount of time in most cases. You have to have all of the software and/or ISOs available, potentially rebuild a domain controller or two, re-create accounts – the list goes on.
By protecting the guts of your home lab with a management cluster, you can focus on just fixing the broken bits and not an entire infrastructure. It has the added bonus of giving you an even more warm and fuzzy feeling when you are running head long into a brand new process that may cause a spectacular level of lab failure. 🙂
2) Rebuild Time
This somewhat ties into the previous statement, but is more focused on the rebuild time to get the lab back to the way it was before you did an update. Let’s take an example of providing some sort of application that needs to talk directly to one of your management servers, such as a domain controller or vCenter. If you only have one layer – in this case the server or a single domain – then an upgrade will affect your entire lab. Even the bits that you don’t want to affect (such as vCloud or View, perhaps?).
Instead, having a management cluster with a unique domain and/or vCenter server will give you a way to still manage your hardware and domain accounts even if your lab was ruined by a faulty application. Additionally, if the application was in fact attached successfully, you can more easily roll it back to repeat the process (I tend to do this frequently for documenting steps, working with beta builds, and writing blog posts).
One caveat to this is that you will need more evaluation licenses for VMware products – this really does suck and is another great point for bringing back the VMTN subscription! It’s less of a headache for Microsoft applications, as their TechNet is awesome and I recommend having a subscription. I’ve had mine for something like 8 years now; it’s worth every penny.
3) Maintenance and Upgrades
The final reason to have a management cluster is to make maintenance and upgrades a simple routine. If you need to run a new bit of code, you can literally power off the entire lab cluster and do that without fear of causing issues with your management layer. And there’s no need to play whack-a-mole with your vCenter server because it lives on a management cluster. Additionally, you’ll have much less need to connect to a host directly, or worry about having to down a domain controller or database server that is used by a number of other services.
It’s definitely nice to put an entire lab into maintenance mode for when you want to go to vSphere version .Next, especially if Update Manager (VUM) is also included in your management cluster!
I happen to use an HP N40L Microserver for my management cluster (here’s how to stick 16 GB of RAM in it), which makes it a “standalone server” model. I’m fine with this risk for the home lab. Even if the drives fail inside of it, I still use Veeam to backup the VMs on a daily basis (although very little changes on there). The huge benefit here is that the N40L is amazingly cheap, often in the $100-200 range, and is a great way to put vCenter, SQL, Active Directory, and VUM into a nice little box.
Another idea is just running vCenter from VMware Workstation and and the rest of the lab on physical hardware (I used to do this back in the day). This can work for a budget constrained lab and lets you tinker with the physical hosts as needed. I’m open to other options as well – comment below? 🙂