Domain Controller virtualization solutions - Part 3

Network administration - Although domain controllers seem to be a fairly simple concept, virtualization of domain controllers is really not a simple matter at all. To follow the previous two parts of this series, I will show you the options for domain controller virtualization.

In the previous article of this series, we have introduced a server placement model that combines virtual domain controllers and virtual domain controllers. Before I introduce the new issues, I want to go back a bit and describe the domain controller model that we will continue to discuss here.

The basic idea behind the domain controller model we are talking about is a model that has two new physical servers set up as new domain controllers. All previously existing domain controllers are virtualized, as shown in Figure A.

Figure A: A domain controller model

As we have shown in the previous article of this series, we are currently working under the assumption that the forest consists of only one domain. There are many models that are the same for many forest domains, but we will mention them in the following sections. For now, we should simplify things so you can focus on the basic concepts.

In addition to what should be noted above, there are some things we want to introduce in the diagram above. As you can see, the figure shown above includes two server rows. The top row is physical servers and the bottom row is virtual servers. There are 6 domain controllers shown in this diagram. However that does not mean that we will deploy 6 domain controllers. Domain controllers shown in the diagram are only representative. The actual number of domain controllers you need will depend on your network size and configuration.

You will see that each domain controller is linked to a domain named Contoso.com and that those domain controllers are labeled with numbers 1 through 6. These numbers represent the order for domain controllers. when they are added to the domain. For example, DC1.contoso.com represents this as the first domain controller online. So this domain controller will host the main operational roles and also work as a primary DNS server for the forest / domain.

This diagram also shows that we have online two physical servers (DC5.contoso.com and DC6.contoso.com) into domain controllers before to virtualize the first four domain controllers. This way helps us achieve two purposes. First, physical domain controllers will provide a load balancing level because Active Directory requests will now be distributed across 6 domain controllers instead of 4. This may not be very terrible, but remember that The virtual server must compete for a certain amount of resources. If certain requirements make all four domain controllers busy, sharing some workloads to physical domain controllers will definitely make virtual domain controllers more free. The only way to be sure of this is to use some performance testing tools.

More importantly, adding two physical domain controllers will help overcome host server error. For example, suppose that VM-Host1.contoso.com is down, this error causes DC1.contoso.com and DC2.contoso.com to be down. Meanwhile DC1.contoso.com is acting as a primary DNS server for the network. Because the Active Directory is completely dependent on DNS, such an error can disrupt the entire network. That's why we configure a physical server as a secondary DNS server. Now if the host server containing the main DNS server fails, the second DNS server can still take over the work and thus overcome the entire network crash.

This is the topic that refers to domain controllers, so it should be added that virtual domain controllers need to be scattered alongside hosts. The diagram above is an example, we have four virtual domain controllers and they reside on two separate hosts. Although a new host server can now host four domain controllers, we should not do so because, putting all the virtual domain controllers into a particular host will accidentally turn this host server into an error point. Department. If the host server has a problem, it will cause all four virtual domain controllers to crash under it.

In addition, we have emphasized the importance of spreading domain controllers to multiple hosts because of load problems, an overloaded host can also become a global error. So that's what we need to avoid to happen, global errors.

Even if you have a simple network like this, you should pay attention to distributing your domain controllers to multiple hosts. To see the reason, you can imagine that VM-Host1.contoso.com is hosting all four virtual domain controllers and VM-Host2.contoso.com does not exist. Suppose VM-Host1.contoso.com is experiencing a catastrophic error.

In this situation, the network will still work. The remaining two domain controllers can serve Active Directory and DNS requests, and they can be assigned a host activity role if needed. So what is the benefit of spreading virtual domain controllers here? In the situation we have described, the two remaining physical domain controllers will handle the workload that was previously shared via 6 domain controllers. It is likely that performance will be severely degraded and you will probably have problems if one of the remaining two physical domain controllers is having trouble. Conversely, if you structure the domain controllers in the way shown in Figure A, the error will never cost you more than two domain controllers.

Above we explained why we should design a network in the way shown in Figure A. There is, however, another reason, the final reason, which we want to talk about in this section. If you look back at the figure, you will notice that both host servers (VM-Host1, Contoso.com and VM-Host2.contoso.com) are domain members. This allows host servers to access the same Active Directory information as other servers on the network, making network management easier.

Conclude

In this section, I have discussed the importance of physical domain controllers, besides the distribution of virtual domain controllers to multiple host servers. In the next part of this series, we will focus on how to place the global catalog server into this design.