Scaling the Active Directory


When a company becomes very large it can be a challenge to make sure the environment can properly scale to support the expanding Active Directory. As more and more objects are added to Active Directory and as more and more fields are used the domain controllers can become more and more taxed. Many companies take an approach of making all the domain controllers identical in terms of hardware and configuration. This greatly reduces the support load of the servers. To do this it is important to properly size the domain controllers to handle the load. Toward this end, Microsoft offers a tool called the Active Directory Sizer Tool.

Active Directory Sizer Tool

In a perfect world, each domain controller would be capable of handling the entire authentication load of the entire environment. In this way if the entire network went to hell in a handbasket, users would still be able to authenticate to get to resources. In the real world this is actually a very realistic option. The difficulty comes in determining just how beefy a server must be to support the entire user base. Luckily Microsoft offers a specific tool that was developed for exactly this reason. It is called the Active Directory Sizer Tool. By following a simple wizard and having the necessary information about the enterprise you can determine the required specifications for the domain controllers. This tool takes into account factors such as Exchange 200x, typical user activity, and replication schedules. Although it is not an exact science it does provide a good starting point for determining the hardware specification of the domain controllers. Do not forget to factor in room for growth. If a company has a policy for replacing hardware on a regular schedule you must take that period of time of growth into account.

Based on user inputs and internal formulas, this tool can provide estimates for the number of

  • Domain controllers per domain per site.

  • Global Catalog servers per domain per site.

  • CPUs per machine and type of CPU.

  • Disks needed for Active Directory data storage.

  • Amount of memory required.

  • Network bandwidth utilization.

  • Domain database size.

  • Global Catalog database size.

  • Inter-site replication bandwidth required.

Additional information on the Active Directory Sizer Tool can be found on the Microsoft Web site at http://www.microsoft.com/windows2000/techinfo/planning/ activedirectory /adsizer.asp.

File Locations Matter

On any application that uses a database and log files, it behooves you to pay careful attention to where files are placed on the system. In a perfect world the operation system would have its own set of spindles, the swap file would have a separate set, the database would have another set, and finally the log files would have a fourth. The concept is that any spindle can be read or written independently of any other set of spindles. The side benefit of this is that if the spindles supporting the database were to fail, this would not affect the log files. This would greatly aid the recovery process for the database.

Active Directory is an application that uses a database and log files. By placing the database and log files on separate disks, you enable the system to read and write both of these simultaneously . This eliminates bottlenecks where the log files aren't written until the database access is done. Similarly by placing the operating system on its own set of disks, operating system tasks that access the disk will not affect the database or logs. Placing the swap file on its own set of disks is perhaps the most critical of all. The swap file is read from and written to almost constantly. If this activity had to compete with the OS, the database, and the log files, overall performance of the system would suffer.

Many Companies Would Rather Mirror Disks than Break Out the Roles

Because of cost constraints and disk backplane capacity it is often not realistic to break up the OS, swap file, database, and logs to the degree mentioned previously. For system resiliency, many companies would rather mirror disks than break out the roles. When faced with this compromise on a domain controller you can prioritize the functions as follows with regards to which function should get its own spindle first:

Swap file

NTDS.DIT

Active Directory logs


Configuring Your Disks the Right Way

The optimal configuration for a domain controller is for the operating system to be mirrored on a pair of drives. Each of the drives should be on their own channel of their own controller. This protects against disk failure and controller failure. The swap file should also be on a pair of mirrored drives with each drive on its own channel of the same two controllers running the OS. A third pair of drives should be mirrored in the same manner as the OS drives and these should hold the log files. The drives for the Active Directory database should also be mirrored in the same manner as the prior drives . If the database will be larger than a single drive it is preferred to run mirrored stripe sets (RAID 0+1) for the database. This is preferred over RAID 5 because of the performance hit on writes that is associated with RAID 5.

RAID 0+1 combines the performance of striping with the redundancy of mirroring. Striping multiple disks allows each disk to be read or written simultaneously. This allows the disk performance to scale nearly 1:1 with additional disks. RAID 5 uses a parity check that requires reading all the disks in the RAID and determining the parity value to write. This configuration results in good read speed but reduced write speed. The parity allows the RAID to lose one disk and still operate based on the ability to re-create the value on the missing drive. This also allows the RAID to rebuild the data on the missing disk when it is replaced .

Understanding Your Replication Topology

Properly scaling Active Directory goes beyond simply sizing the domain controllers and optimizing the location of files. When active directory becomes very large it is critical to address the replication topology. Logical placement of bridgehead servers helps to break up replication traffic. Rather than force all domain controllers to replicate back to a hub site, plan out replication to reduce traffic across slow links. If a network had a main office in San Jose, an office in New York, and an office in New Jersey and the New Jersey office connected only to New York it would not be optimal to have a hub and spoke replication back to the main office in San Jose. By allowing New York to act as a bridgehead with New Jersey using New York as a preferred bridgehead, replication traffic would be reduced. If the domain controller in New York failed, the domain controller in New Jersey could still replicate with the domain controllers in San Jose assuming site link bridging was still enabled. Site link bridging is enabled by default.

If an Active Directory site is going to have more than one domain controller one of the DCs should be configured as a bridgehead server. This allows the other DCs in that site to get their replication from the local server. Without this type of architecture it would be hard to scale Active Directory across a large environment. The use of site link bridging is useful for creating simple redundancy but as an environment grows the Knowledge Consistency Checker ”the function that determines replication across bridged site links ”is unable to scale and manually managed site links are required. A good rule of thumb is to check the environment against a complexity formula. To determine if the topology is too complex for the KCC to handle, a complexity formula is used:

KCC in Windows 2003 Is Greatly Improved from the Version in Windows 2000

By default, site link bridging is enabled. The KCC in Windows 2003 is greatly improved from the version in Windows 2000. Replication traffic in Windows 2003 is also reduced as a result of replicating attribute level changes instead of entire user objects. This being the case, it is still important to monitor the KCC to ensure that replication is occurring correctly.


(1 + D) * S^2 <= 100,000 (where D = Number of Domains and S = Number of Sites in your network)



Microsoft Windows Server 2003 Insider Solutions
Microsoft Windows Server 2003 Insider Solutions
ISBN: 0672326094
EAN: 2147483647
Year: 2003
Pages: 325

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net