Solutions for Virtualizing Domain Controllers (Part 1)

by [Published on 25 May 2010 / Last Updated on 25 May 2010]

The pros and cons of some of the more popular domain controller placement models.

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

Introduction

When it comes to building a virtual datacenter, perhaps no topic is as controversial as domain controller placement. Server virtualization has been around for a long time now, and with several mature virtualization products on the market, one would think that the ground rules for virtualizing network servers would have been firmly established by now. For the most part there are clear and concise guidelines for server virtualization. This is not necessarily the case when it comes to virtualizing domain controllers though. It absolutely amazes me how many different philosophies there are as to how domain controllers should be dealt with in a virtual environment. Since there are pros and cons associated with each of these different philosophies, I decided to take a critical look at domain controller placement in a virtualized environment.

What’s the Big Deal?

Right now you may be wondering why domain controller placement is such a controversial topic. I have heard domain controller placement compared to the old question of which came first the chicken or the egg. On one hand, domain controllers establish the Active Directory structure that all other Windows servers latch onto. On the other hand, you have to create and configure virtualization host servers (usually Hyper-V or VMware servers) before you can virtualize anything. You must therefore decide whether or not your host servers should be domain members. If you decide to make the host servers a part of the domain, you must then figure out how to do so in a way that promotes network stability.

Excluding the Host Servers from the Domain

One potential solution to the domain controller placement problem is to exclude your host servers from the domain. In this domain model, the entire Active Directory forest would be virtualized, but the host servers would simply reside in a workgroup outside of the domain.

Believe it or not, this particular domain controller virtualization model works pretty well, especially in smaller organizations. In fact, when I initially decided to virtualize my production network, this was the domain controller placement model that I chose to use. The rationale behind my decision was that this model allowed me to virtualize all of my production servers. This gives me the flexibility to move my production servers from one host server to another as my needs dictated.

As well as this type of design works though, it is not perfect. For me, the biggest issue that I have run into, as a result of using this model, is that it limits my options when it comes to backing up my network.

On my network, I run Hyper-V on all of my virtualization hosts, and I use System Center Data Protection Manager 2007 (DPM 2007) as my backup solution. The problem is that DPM 2007 is heavily dependent on the Active Directory. This meant that I had no choice but to join my DPM 2007 server to my domain. As a result, DPM 2007 has no trouble backing up my virtual machines, but I have no way of backing up the virtualization hosts as a whole (at least not with DPM 2007 anyway).

Another issue with excluding virtualization hosts from the Active Directory is that almost all network management software extracts information from the Active Directory. As such, this type of design may limit your ability to manage your virtualization hosts using any sort of management software.

To give you an idea of what I am talking about, consider another aspect of my network’s design. After I had virtualized my production network, I decided that I needed to add another virtualization host, and use it to host some lab machines. None of the lab machines are members of my production domain, but the server that is hosting the lab machines is a domain member.

As my network continued to evolve, I decided to install System Center Virtual Machine Manager 2008 (SCVMM 2008) onto the server that was hosting my lab machines. You can see a screen capture from the SCVMM 2008 console in Figure A.

DC placement 1A.jpg

Figure A: SCVMM 2008 is unable to see my other host servers

Notice in the figure that the All Hosts container only lists a single host server, even though there are multiple Hyper-V host servers present on my network. This behavior is the direct result of the other host servers not being domain members. Not only can SCVMM 2008 not see my other host servers (or the virtual machines that reside on them for that matter), but you cannot even install SCVMM 2008 on a server that does not belong to a domain.

 Create a Separate Domain

As you can see, omitting the virtualization hosts from the Active Directory works fairly well for smaller networks, but can lead to various management problems as the network grows and evolves. There is however a variation of this technique that addresses most of these issues.

This technique involves establishing an Active Directory domain prior to deploying any host servers. This domain exists solely for the purpose of managing your virtualization hosts. In this model, all of your production servers would be members of an entirely separate Active Directory forest that is based on virtualized domain controllers.

This technique offers all of the same advantages as excluding your host servers from the Active Directory, but also allows you to take advantage of network management tools that depend on the Active Directory database.

As is the case with all of the other domain controller placement models that I will be discussing, this model isn’t perfect. As I’m sure you know, one of the major driving forces behind virtualization is to reduce hardware costs by making better use of underutilized server resources. This model does not accomplish that goal.

Having a separate domain for your virtualization host servers means that you are going to need at least one physical server to act as a domain controller. Of course, having a domain with only a single domain controller is a risky proposition, so in reality you would probably be dedicating two or more physical servers to the task of serving as domain controllers.

Since the domain in question is being created solely for the purpose of servicing virtualization hosts, it means that the domain controllers for that domain will experience a very light workload, which isn’t a good thing if your goal is to make better use of your server hardware resources.

If you find yourself wanting to use this domain model, but you have a hard time justifying the dedication of physical servers to act as domain controllers, then I would recommend looking into the possibility of using old servers that you previously retired. As long as your old servers are still functional, and not too outdated, they should have no trouble acting as domain controllers for the virtualization hosts. Keep in mind though, that even if you choose to reuse old server hardware, this model still requires you to purchase the necessary software licenses for the additional domain controllers that you will be deploying.

Conclusion

So far I have talked about two different models for domain controller placement within a virtualized environment. Believe it or not, there are many other domain controller placement models that you can use. I will discuss more of these models in Part 2 of this series.

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

Advertisement

Featured Links