In our daily work, we do often face a choice between low cost or high reliability. Today, I want to establish whether the game is worth the candle when you want to cut your expenses on important things. The premise is that combining Hyper-V and DC roles on the same bare-metal server is a bad idea.
To begin with, all the suggestions and statements in this material are derived from the personal experience, which means they were tried and tested on practice not once and not even twice. Getting that much into detail is not as significant as delivering you the big picture, so I’m going to concentrate on the latter.
The minimum system requirements for OS Windows Server 2016, according to Microsoft, come down to official requirements for installing Windows Server 2016 as follows:
- 1,4 GHz 64-bit CPU;
- 2 GB RAM (ECC memory or similar technology);
- 32 GB HDD (controller must be compatible with PCI Express architecture since PATA technology is not supported as a boot device anymore);
- 1 Gbps NIC (compatible with PCI Express architecture and supporting PXE).
Of course, the given requirements isn’t something impossible these days, but they still don’t guarantee comfortable conditions for your services. For example, while DC serving a small network can get up and running if those requirements are satisfied, Hyper-V operating several virtual machines (VMs) won’t even get started. Therefore, according to Microsoft, the official requirements for running Hyper-V are as follows:
- 64-bit CPU with SLAT (second-level address translation) (the number of cores, their frequency depending on the amount of VMs on the host and their processing power);
- 4 GB RAM (depends on the amount of VMs and memory size required for running them);
- HDD (no official information is available, but from my experience, I can tell that it’s no less than 32 GB + memory size required to run a VM and its components (HDD, snapshots);
- NIC (no official information is available as well, but from my experience that it’s no less than 1 x 1 Gbps).
While planning the future infrastructure and its measurements, every admin will naturally account for its scalability, but, unfortunately, the company’s budget usually brings down every single expectation. It gets hard enough to establish a universal model for most IT environments, and modeling a full picture of the number of resources your server will require is virtually impossible. The only possible way to answer this question is practical experience. So, since I won’t be able to produce a detailed analysis of specific systems, let’s talk purely hypothetically. If you, for some reason, would want to combine Hyper-V and DC roles on the same machine, you’ll have to limit your resources to some extent, but does it really worth it? Saving your expenses in such a way would compromise the reliability of the whole infrastructure. Even if you were to calculate your resources and scale your system entirely, you wouldn’t be able to predict everything. Therefore, such a rigorous approach might cost you a lot. Sooner or later, both roles will struggle for core, memory, HDD, or any other resource because the system itself can’t distribute it all equally, so you’ll have to control resource distribution manually. And you can be well sure that additional control measures are handy in such a case, cause solving this matter within a bare-metal server even with Windows Server 2016 is not possible. Also, please, remember that any thoughtless limitation of any of those roles can and will disrupt the speed and stability of their work. While the problematic DC user authorization response time is hardly pleasant but not insufferable, a VM suffering from low memory or extended processing time can slow down your company’s work big time.
Yet another inconvenience that results from combining both roles on the same machine is an appearance of the additional points of failure. Everybody knows that besides being extremely resource-hungry, Hyper actively uses memory and HDD as well. I don’t have official statistics at my disposal, but I can assure you that server hardware functioning as a virtualization platform can fail more often than you may think. You’re lucky if you planned the work of your IT infrastructure with utmost preciseness, and these services aren’t critical to overall performance. But if your DC is left alone and sustains the whole network or its vital part? What if your Hyper-V isn’t configured to work in a cluster environment or a cluster was damaged, and you can’t access your data or a VM inside of the Hyper-V host? In cases like these, the only thing that can redeem your environment is either recovering both services or installing them all over again. Also, you’ll probably have to reload the whole server so that you can perform its maintenance. A system update can be a bugger too since I saw too many cases when the update was useful for one service but harmful for another. One way or another, it’ll eventually force you to stop both services.
With that being said, in terms of backup and recovery, as you know, some admins back up already, some still don’t, and some back up and recover. What does it mean? It means that in a lot of cases, a decent backup plan can save you a lot of trouble. No matter how experienced an admin is, nobody can predict everything. Even an owner of the most sophisticated IT environment will regret not having an efficient backup strategy. Having two different services installed only worsens this situation. Different working processes suggest differences in backup planning. Imagine this: your service, the one with two roles combined, is the one being most technically capable. Thus, if it fails, you’ll have nothing to replace it with! Now you’re stuck with the problem when you need new hardware and to arrange a correct migration of both services. Furthermore, if you recover one of those services in the previous state with your backups, how would you be able to do it without critically affecting the other one?
Remember that two services on one host server mean twice the risk of security failure. They both work with the same OS, and chances are they both are working with the same credentials, the same IP address, the same disk space, and, eventually, the same antivirus software. Hence if one service is compromised, you can bet it will compromise another.
You may think I’m paranoid, but, as the saying goes, if you’re paranoid, it doesn’t mean nobody’s after you. All of these conclusions are drawn from personal experience, and they’re more than trustworthy. My advice is quite simple: don’t try to save a couple of bucks here and there because there’s a high chance it’s going to cost you later even more. However, if you don’t really have that much of choice, there is another way. If there is a possibility, create a cluster with another Hyper-V host no more powerful than the primary Hyper-V, and put a VM with DC server inside for backup. This option is not perfect as well, but that is a topic for a different conversation.