Solutions for Virtualizing Domain Controllers (Part 3)

If you would like to read the other parts in this article series please go to:

Introduction

In my previous article in this series, I began discussing a server placement model that involved a combination of physical and virtual domain controllers. Before I start talking about anything new, I want to take a step back and describe the domain controller placement model that I am going to continue to discuss.

The basic idea behind the domain controller placement model that I have been discussing is that two new physical servers are brought online as new domain controllers. All of the previously existing domain controllers are then virtualized, as shown in Figure A.

Figure A: This is one possible domain controller placement model

As I pointed out in my previous article, I am currently working under the assumption that the forest contains only a single domain. There are similar models for multi domain forests, and I will be discussing those models later in this series. For right now though, I want to try to keep things simple so that I can focus on explaining the basics.

With that said, there are a few things that I want to point out in the diagram above. As you can see, the diagram contains two rows of servers. The top row represents physical servers, while the bottom row represents virtual servers. There are six domain controllers shown in the diagram. This isn’t to say that I recommend deploying six domain controllers. The domain controllers shown in the diagram are purely representative. The actual number of domain controllers that you will need depends on your network’s size and configuration.

With that said, you will notice that each of the domain controllers is associated with a domain named Contoso.com, and that the domain controllers are labeled with numbers ranging from 1 to 6. This number represents the order in which the domain controllers were originally added to the domain. For example, DC1.contoso.com represents the first domain controller that was brought online. As such, this domain controller is hosting the flexible single master operations roles, and is also acting as the primary DNS server for the forest / domain.

This diagram also illustrates that we have brought two physical servers (DC5.contoso.com and DC6.contoso.com) online as domain controllers prior to virtualizing the four original domain controllers. This serves two purposes. First, the physical domain controllers provide a degree of load balancing since Active Directory requests are now being distributed across six domain controllers instead of four. That might not seem like a big deal, but remember that virtual servers must compete for a finite pool of resources. If the network is busy enough to require four domain controllers, then offloading some of the workload onto physical domain controllers is probably going to help give our virtual domain controllers a bit of breathing room. Of course the only way to tell for sure is by doing some performance monitoring.

More importantly though, the addition of our two physical domain controllers helps to protect the domain against a host server failure. For example, let’s pretend that VM-Host1.contoso.com failed, which caused DC1.contoso.com and DC2.contoso.com to also drop offline. As you will recall, DC1.contoso.com is acting as the primary DNS server for the network. Since the Active Directory is completely dependant on DNS, such a failure could disrupt the entire network. That’s why I have configured one of the physical servers to act as a secondary DNS server. If the host server containing the primary DNS server fails, then the secondary DNS server can take over, thus preventing a major outage.

While I am on the subject of domain controller placement, I want to point out that your virtual domain controllers should be scattered among multiple hosts. In my diagram for instance, I have four virtual domain controllers, and they reside on two separate hosts. Even a modestly equipped host server could probably host four domain controllers. Doing so would be a bad idea though, because by placing all of the virtual domain controllers onto a single host, the host server becomes a single point of failure. If the host goes down, it will take all four virtual domain controllers with it.

OK, the host wouldn’t be a true single point of failure because the two physical domain controllers would still be online. Even so, I wanted to underscore the importance of spreading your domain controllers across multiple hosts because when we start talking about networks with multiple domains or multiple sites later on in this series, an overloaded host could very well become a true single point of failure.

Even if you have a simple network like this one, it is still important to distribute your virtual domain controllers across multiple hosts. To see why, imagine that VM-Host1.contoso.com was hosting all four of the virtual domain controllers, and that VM-Host2.contoso.com doesn’t exist. Now suppose that VM-Host1.contoso.com suffers a catastrophic failure.

Even in this situation, the network would still be relatively OK. The two remaining domain controllers could service the Active Directory and DNS requests, and they can be designated the flexible single master operations roles if necessary. So what’s the big deal about spreading out the virtual domain controllers? Well, in the situation that I just described, the two remaining physical domain controllers would now be required to handle the workload that was previously distributed across six domain controllers. In all likelihood performance would suffer considerable, and you would probably really be in trouble if one of the remaining physical domain controllers failed. In contrast, if you structured the domain controller placement in the way that is shown in Figure A, then a failure would never cost you more than two domain controllers.

Now that I have explained why the network shown in Figure A is designed the way that it is, there is one last issue that I want to talk about in this article. If you look back at the figure, you will notice that both of the host servers (VM-Host1,Contoso.com and VM-Host2.contoso.com) are domain members. This allows the host servers to have access to the same Active Directory information as the other servers on the network, potentially making network management much easier.

Having a mix of physical and virtual domain controllers made it a lot easier to join the host servers to the domain. The host servers could have been joined to the domain even if all of the domain controllers were virtualized, but then you get back into the chicken and egg paradox because the host servers depend on the domain controllers, but the domain controllers can’t function without the host servers. Believe it or not though, there is a way of making this paradox work, and that is one of the issues that I plan on discussing later in the series.

Conclusion

In this article, I have taken a step back and discussed the importance of physical domain controllers, and of distributing virtual domain controllers across multiple host servers. In Part 4 of this series, I want to turn my attention to the way that global catalog server placements factor into this design.

If you would like to read the other parts in this article series please go to: