Planning Domain Controller Capacity

(1)

C H A P T E R 4

Planning domain controller capacity helps you determine the appropriate number of domain controllers to place in each domain that is represented in a site. Capacity planning also assists you in estimating the hardware requirements for each domain controller so that you can minimize cost and maintain an effective service level for your users.

In This Chapter

Overview of Planning Domain Controller Capacity... 186

Collecting Site Topology Design Information ... 190

Determining the Number of Domain Controllers ... 192

Assessing Disk Space and Memory Requirements ... 195

Monitoring Domain Controller Performance ... 202

Additional Resources... 204 Related Information

u For more information about planning sites and site topology, see “Designing the Site Topology” in this book.

u For more information about designing the Active Directory^® directory service forest and domain structure, see “Designing the Active Directory Logical Structure” in this book.

u For more information about Active Directory data storage and directory partitions, see the Directory Services Guide of the Microsoft^® Windows^® Server 2003 Resource Kit (or see the Directory Services Guide at http://www.microsoft.com/reskit).

Planning Domain

Controller Capacity

(2)

Overview of Planning Domain

Controller Capacity

By helping you predict your organization’s needs, planning domain controller capacity protects you from underestimating hardware requirements. Underestimating your hardware requirements can cause poor performance and application response time, and can prevent users from quickly logging on to the network to access resources. Effectively planning domain controller capacity also helps to protect against overloading domain controllers that are running the Microsoft®

Windows® Server 2003, Standard Edition; Windows® Server 2003, Enterprise Edition; and Windows® Server 2003, Datacenter Edition operating systems.

Before you plan domain controller capacity, your Active Directory site topology design must be complete. Part of designing your site topology involves deciding which locations require domain controllers and what type of domain controllers are required in each location. After your site topology is designed, planning domain controller capacity helps you to determine the number of domain controllers that you need in each domain for each site and the hardware that is required for each domain controller. For more information about designing your site topology, see

“Designing the Site Topology” in this book.

Planning domain controller capacity helps you estimate the hardware requirements for domain controllers that are running Windows Server 2003. Your actual hardware requirements depend on the specific usage patterns in your environment.

After your Active Directory deployment project is complete, continue to monitor the

performance of your domain controllers. It is not possible to predict the actual load that client and network traffic put on your domain controllers. Continually monitoring performance helps you understand system workloads and the corresponding effect on your system resources. It also helps you to be aware of changes and trends in workloads and resource usage so that you can plan for future upgrades.

Note

For a list of the job aids that are available to assist you in planning domain controller capacity, see “Additional Resources” later in this chapter.

(3)

Overview of Planning Domain Controller Capacity 187

Process for Planning Domain Controller Capacity

To begin the process of planning domain controller capacity, gather the necessary information recorded earlier in the Active Directory design process. Use this information to determine the hardware requirements for the domain controllers in your environment. Finally, continue to monitor domain controller performance well after the deployment project is complete.

Figure 4.1 shows the tasks that you must perform to plan domain controller capacity for a Windows Server 2003 Active Directory environment.

Figure 4.1 Planning Domain Controller Capacity

Determine the number of domain controllers

Assess disk space and memory requirements

Monitor domain controller performance Collect site topology design information

(4)

Background Information for Planning Domain

Controller Capacity

Several factors influence domain controller capacity, including the number of objects in the domain, the number of users who are logging on to the domain, and the role of the domain controller and the services installed on it. Be aware of those operations and services that affect domain controller performance so that you can anticipate your requirements and better plan for future growth. Table 4.1 lists how operations and services affect domain controller performance.

The operations and services that have the greatest effect on domain controllers are listed first.

Table 4.1 Effect of Operations and Services on Domain Controller Performance Operation/Services Variables Affecting Performance

PDC emulator operations master The following operations typically have a high impact on the performance of the PDC emulator:

Password change forwarding and logon forwarding requests with mismatched passwords for users, computers, and service accounts.

Group Policy updates

The initial update of Distributed File System (DFS)

Replicating directory changes to Microsoft^® Windows NT® 4.0 backup domain controllers.

Active Directory replication

Replication to partner domain controllers

The impact varies based on the number of replication partners.

Replicating to more than fifteen intersite partners has a high impact on performance.

Workstation logon

Startup process

The impact varies based on the number of workstations.

Application directory partition hosting

The impact varies based on the use of data that is contained in the application directory partition.

Global catalog operations

Universal group membership lookups

Forestwide searches

If this domain controller functions as a global catalog server, performance varies according to the type of programs that are used.

Programs that use global catalog searches extensively, such as Exchange 2000, have a high impact on performance.

(continued)

(5)

Overview of Planning Domain Controller Capacity 189

Table 4.1 Effect of Operations and Services on Domain Controller Performance (continued)

Operation/Services Variables Affecting Performance Other operations

File and print

The impact varies based on the number of users who are using the domain controller as a file and print server.

Network Services

DNS

WINS

DHCP

Internet Protocol security (IPSec)

The impact varies based on the number of services that are performed by the domain controller. For example, hosting multiple services, such as DNS, WINS, and DHCP, typically has a high impact on performance. Hosting a single service, such as DNS, typically has a low impact on performance. For IPSec, the impact on performance varies according to the number of connections.

Users logging on

User authentication

Authorization for resource access requests

The impact varies based on the number of users.

Look-up operations

Lightweight Directory Access Protocol (LDAP) searches

The impact varies based on the type of searches and the number of searches that the program performs.

Infrastructure operations master The validation of links to moved objects typically has a low impact on performance.

RID pool operations master RID pool distribution typically has a low impact on performance.

Schema operations master Modification to the schema typically has low impact on performance.

Domain naming operations master

The addition or deletion of domains typically has low impact on performance.

(6)

Collecting Site Topology Design

Information

Begin the process for planning domain controller capacity by collecting the information that was recorded during the site topology design process. Figure 4.2 shows where this step happens in the domain controller capacity planning process.

Figure 4.2 Collecting Site Topology Design Information

During the site topology design process, the Active Directory design team records site topology design information in worksheets. Use these worksheets to determine the number of domain controllers that are required in each domain that is represented in each site, and the hardware that is required for each of these domain controllers to support client requests and service operations in each domain.

Use the “Associating Subnets with Sites” worksheet to determine the name of each site in the forest, and then review the “Domain Controller Placement” worksheet to determine the locations that require domain controllers. To review examples of these worksheets, see “Designing the Site Topology” in this book.

(7)

Collecting Site Topology Design Information 191

For each site, determine the following:

u The name of each domain in the site

u The number of users for each domain in the site u The distribution of global catalog servers

Record the design information in a new worksheet so that you can complete the process for planning domain controller capacity. Figure 4.3 shows an example of a worksheet that contains domain controller design information for the Trey Research forest. For a worksheet to assist you in collecting domain controller design information, see “Domain Controller Design Information”

(DSSDCC_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Domain Controller Design Information” on the Web at http://www.microsoft.com/reskit).

Figure 4.3 Example of a Domain Controller Design Information Worksheet

(8)

Determining the Number of Domain

Controllers

To maintain an effective service level, make sure that you place a sufficient number of domain controllers in each domain that is represented in a site. First, determine the minimum number of domain controllers that are required in each domain and the minimum CPU speed that is required to support the workload of each domain controller. If a domain controller in a site has a large number of outbound connections, add additional domain controllers for that domain to support the additional replication traffic across sites. Figure 4.4 shows the process for determining the number of domain controllers to place in each domain that is represented in a site.

Figure 4.4 Determining the Number of Domain Controllers for Each Domain in a Site

Determine the minimum number of domain controllers required

Add domain controllers to support replication between sites

(9)

Determining the Number of Domain Controllers 193

Determining the Minimum Number of Domain

Controllers Required

Use the design information that you recorded in the Domain Controller Design Information worksheet to determine the minimum number of domain controllers that are required in a domain that is represented in a site, based on the number of users in that domain. Table 4.2 provides guidelines for determining the minimum number of domain controllers and the minimum CPU speed. For each site in your forest, you must determine the minimum number of domain controllers that are required for each domain that is represented in that site.

For information about how memory allocation affects domain controller performance, see

“Determining Required Memory Allocation” later in this chapter.

Table 4.2 Determining Minimum Number of Domain Controllers Required Users per Domain

in a Site

Minimum Number of Domain Controllers Required per Domain in a Site

Minimum CPU Speed Required per Domain Controller

1 – 499 One Uniprocessor 850 megahertz (MHz)

or higher

500 – 999 One Dual processor 850 MHz or higher

1,000 - 2,999 Two Dual processor 850 MHz or higher

3,000 – 10,000 Two Quad processor 850 MHz or higher

> 10,000 users One for every 5,000 users Quad processor 850 MHz or higher

Note

Although one domain controller per domain might be sufficient to handle the workload that is related to Active Directory, you must always have a minimum of two domain controllers per domain for fault tolerance and disaster recovery.

(10)

Adding Domain Controllers to Support

Replication Between Sites

Replicating Active Directory to a large number of sites increases the workload on domain controllers. After you determine the minimum number of domain controllers that you require for each domain that is represented in a site and where the global catalog servers will be located, determine whether you need to add domain controllers or global catalog servers to support replication between sites.

In Microsoft® Windows® 2000, replication between domains that are hosted in a large number of sites is performed by the domain controller in each domain that is designated by the Knowledge Consistency Checker (KCC) as the bridgehead server. In Windows Server 2003, every domain controller in a domain is designated a candidate bridgehead server; therefore, the outbound replication connections that are created by the KCC are randomly distributed between all candidate bridgehead servers in a domain to share the replication workload. In Windows Server 2003, when a domain is represented in more than one site, replication to all other sites where that domain is represented is distributed between the domain controllers in the domain.

If the Windows Server 2003–based domain controllers in a site are replicating to between 15 and 31 other sites that are hosting the same domain, add one domain controller to the minimum number of domain controllers required (2+1) in that domain. If the domain controllers in that same site are replicating to between 32 and 45 other sites that are also hosting the same domain, the number of domain controllers required is (2+1+1). Continue adding domain controllers for every 15 replication connections.

The same rule applies to the number of global catalog servers in a site if only one global catalog server in the site is replicating to between 15 and 31 global catalog servers from other sites. For every 15 additional replication connections, add another global catalog server to the site. For more information about global catalog server placement, see “Designing the Site Topology” in this book.

(11)

Assessing Disk Space and Memory Requirements 195

Assessing Disk Space and Memory

Requirements

After you determine the number of domain controllers to place in each domain represented in a site, assess the disk space and memory requirements for each domain controller. Figure 4.5 shows the process for assessing disk space and memory requirements.

Figure 4.5 Assessing Disk Space and Memory Requirements

Determine required disk space Determine required memory allocation

(12)

Determining Required Disk Space

The disk space that is required for a domain controller varies based on the number of objects in the domain, whether the domain controller is a global catalog server, and whether the domain controller hosts application directory partitions. To determine disk space requirements, perform the following tasks:

u Determine the minimum disk space requirement for the domain controllers in each respective domain.

u Add disk space to the domain controllers on which you plan to host the global catalog.

u Add disk space to the domain controllers on which you plan to host application directory partitions.

Use a hardware assessment worksheet to record the disk space that is required on each domain controller. For an example of a completed hardware assessment worksheet, see “Example:

Assessing Disk Space and Memory Requirements” later in this chapter. For a worksheet to assist you in determining required disk space, see “Hardware Assessment” (DSSDCC_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Hardware Assessment” on the Web at http://www.microsoft.com/reskit).

Determining Minimum Disk Space Requirements

Domain controllers require at least enough disk space for the Active Directory database, Active Directory log files, the SYSVOL shared folder, and the operating system. Use the following guidelines to determine how much disk space to allot for your Active Directory installation:

u On the drive that will contain the Active Directory database, NTDS.dit, provide 0.4 gigabytes (GB) of storage for each 1,000 users. For example, for a forest with two domains (domain A, domain B), with 10,000 and 5,000 users respectively, provide a minimum of 4 GB of disk space for each domain controller that hosts domain A and a minimum of 2 GB of disk space for each domain controller that hosts domain B.

u On the drive that will contain the Active Directory transaction log files, provide at least 500 megabytes (MB) of available space.

u On the drive that will contain the SYSVOL shared folder, provide at least 500 MB of available space.

u On the drive that will contain the Windows Server 2003 operating system files, provide at least 1.5 GB to 2 GB of available space.

(13)

To prevent single disk failures, many organizations use a redundant array of independent disks (RAID). For domain controllers that are accessed by fewer than 1,000 users, all four components generally can be located on a single RAID 1 array. For domain controllers that are accessed by more than 1,000 users, place the log files on one RAID array and keep the SYSVOL shared folder and the database together on a separate RAID array, as specified in Table 4.3.

Table 4.3 RAID System Requirements

Component Operations Performed RAID System

Operating system files Read and write operations RAID 1 Active Directory log files Mostly write operations RAID 1 Active Directory database and

SYSVOL shared folder

Mostly read operations RAID 1 or RAID 0+1

Adding Disk Space for Global Catalog Servers

After you determine the minimum disk space requirements for your domain controllers, add disk space to the domain controllers that you want to use as global catalog servers. A global catalog server is a domain controller that stores a full replica of the domain directory partition for the domain where it is located and a partial replica of every other domain directory partition in the forest. Because the global catalog server stores partial information about every other domain directory in the forest, global catalog servers require additional disk space.

If your forest contains only one domain, designating a domain controller as a global catalog server does not increase the database size. However, if your forest contains more than one domain, each additional domain adds approximately 50 percent of its own database size to the global catalog.

The disk space requirements for a global catalog server that is running Windows Server 2003 are lower than those for a global catalog server that is running Microsoft® Windows® 2000 Server if Active Directory–integrated DNS is configured to use application directory partitions instead of the domain directory partition to store DNS zone data. Application directory partition data does not replicate to the global catalog.

Note

If cost is a factor in planning for disk space, you can place the operating system and Active Directory database on one RAID array (such as RAID 0+1) and the Active Directory log files on another RAID array (such as RAID 1).

However, it is recommended that you store the Active Directory database and the SYSVOL shared folder on the same drive.

(14)

server.

Figure 4.6 Disk Space Requirements for a Global Catalog Server

Global Catalog storage requirement

Domain Controller storage requirement

= + Domain Controller

storage requirements for other domains

2

Table 4.4 shows the storage requirements for a domain controller and a global catalog server for a forest that contains two domains with 10,000 users (domain A) and 5,000 (domain B) users, respectively.

Table 4.4 Storage Requirements for the Active Directory Database Number of Users

per Domain Domain Controller Active Directory Database

Storage Requirements

10,000 Domain controller (domain A) 4 GB

5,000 Domain controller (domain B) 2 GB

10,000 Global catalog server (domain A) 4 + 2/2 = 5 GB 5,000 Global catalog server (domain B) 2 + 4/2 = 4 GB

Adding Disk Space for Application Directory Partitions

Applications that depend on Active Directory can use application directory partitions to store application-specific data. Application directory partitions can be created either by applications, by services, or by administrators as container objects. Storing application data in an application directory partition instead of in a domain directory partition can help reduce replication traffic if the application data is replicated to only the domain controllers that require the application data.

Currently, Active Directory–integrated DNS is the only Windows Server 2003 service that is configured to use application directory partitions by default. However, you do not need to plan for additional disk space for DNS because the DNS-related disk space requirements have already been factored into the disk space recommendations in this chapter based on numbers of users.

If you are planning to use application directory partitions to store data for applications other than DNS, consult the application developer to determine how much additional disk space to allot for the application directory partition in which the data will be stored.

(15)

Determining Required Memory Allocation

Use the number of users per domain in a site to determine the minimum memory requirements for each domain controller in that domain. Table 4.5 gives a conservative estimate of the minimum required memory allocation for a domain controller.

Table 4.5 Determining Domain Controller Memory Requirements Users per Domain

in a Site

Minimum Number of Domain Controllers Required

per Domain in a Site

Minimum CPU Speed Required per Domain Controller

Minimum Memory Requirements per Domain Controller

1 – 499 One Uniprocessor 850 MHz

and higher

512 MB

500 – 999 One Dual processor 850 MHz

and higher

1 GB

1,000 - 2,999 Two Dual processor 850 MHz

and higher

2 GB

3,000 – 10,000 Two Quad processor 850

MHz and higher

2 GB

> 10,000 users One for every 5,000 users Quad processor 850 MHz and higher

2 GB

After you determine the minimum memory requirements for each domain controller, consider using the /3GB switch to allow the Lsass process (the process in which Active Directory runs) to cache a larger number of directory objects.

Lsass memory usage on domain controllers has two components:

u Data structures, which are like other processes and consist of threads, heaps, and stacks.

u Database buffer cache, which consists of database pages and index pages for the directory.

In Windows 2000, the memory that can be used by the database buffer cache without adding the /3GB switch to the Boot.ini file is .5 GB. With the /3GB switch in place, the database buffer cache is still limited to 1 GB.

(16)

However, with the /3GB switch in place on a 32-bit computer, virtual address space is limited to 4 GB, with 3 GB allocated for user mode processes and 1 GB for kernel mode processes.

Therefore, on a 32-bit computer, the database buffer cache never grows greater than 3 GB with the /3GB switch in place, and it does not grow that large because of the memory that is used by other processes. For information about modifying the Boot.ini file, see “Bootcfg” in Help and Support Center for Windows Server 2003.

Use a hardware assessment worksheet to record the required memory allocation for each domain controller. For an example of a completed hardware assessment worksheet, see “Example:

Assessing Disk Space and Memory Requirements” later in this chapter. For a worksheet to assist you in assessing hardware requirements, see “Hardware Assessment” (DSSDCC_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Hardware Assessment” on the Web at http://www.microsoft.com/reskit).

Example: Assessing Disk Space and Memory

Requirements

Figure 4.7 shows an example of a hardware assessment worksheet for the domain controllers in the Trey Research forest. The worksheet shows each site in the Trey Research forest, the domains located in each site, a number to identify the domain controllers in the domain (domain controllers in the Trey Research forest have not been named yet), and the existing hardware configuration on each domain controller. For a worksheet to assist you in assessing hardware requirements, see “Hardware Assessment” (DSSDCC_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Hardware Assessment” on the Web at

http://www.microsoft.com/reskit).

Note

The /3GB switch can be added to domain controllers that are running Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Do not add the /3GB switch to the Boot.ini file if you have less than 2 GB of physical memory.

(17)

Figure 4.7 Example of a Hardware Assessment Worksheet

(18)

Monitoring Domain Controller

Performance

After your Active Directory deployment project is complete, continuously monitor your domain controllers and Active Directory. Monitoring the distributed Active Directory service and the services that it depends on helps to maintain consistent directory data and a consistent level of service throughout the forest. Figure 4.8 shows monitoring domain controller performance as the final step in the process for planning domain controller capacity.

Figure 4.8 Monitoring Domain Controller Performance

As a distributed service, Active Directory depends on many interdependent services that are distributed across many devices and in many remote locations. As you increase the size of your network to take advantage of the scalability of Active Directory, monitoring becomes more important.

(19)

Monitoring Domain Controller Performance 203

Monitoring Active Directory assures administrators that:

u All necessary services that support Active Directory are running on each domain controller.

u Data is consistent across all domain controllers and end-to-end replication completes in accordance with service level agreements.

u Lightweight Directory Access Protocol (LDAP) queries respond quickly.

u Domain controllers do not experience high CPU usage.

Organizations with few domains and domain controllers, or organizations that do not provide a critical level of service, might only have to check the performance of a single domain controller periodically by using the built-in tools that are provided with Windows Server 2003, such as System Monitor. For a list of acceptable values for counters to use with System Monitor, see

“Using System Monitor” in Help and Support Center for Windows Server 2003.

Larger organizations that have many domains, domain controllers, and sites, or that provide a critical service and cannot afford the cost of lost productivity because of a service outage, must use an enterprise-level monitoring solution, such as Microsoft® Operations Manager (MOM).

Use the monitoring solution that best meets your requirements, but monitor the important indicators to make sure that all aspects of Active Directory are functioning correctly. MOM monitors all the important indicators. Implement your monitoring solution in a lab before you deploy it in your production environment.

For more information about monitoring Active Directory, see the Active Directory link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. Search under Administration and Configuration Guides and download the Active Directory Operations Guide.

For more information about MOM, see the Microsoft Operations Manager link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

(20)

Additional Resources

These resources contain additional information and tools related to this chapter.

Related Information

u “Designing the Site Topology” in this book.

u The Directory Services Guide of the Windows Server 2003 Resource Kit (or see the Directory Services Guide on the Web at http://www.microsoft.com/reskit) for information about Active Directory replication and data storage.

u The Active Directory Branch Office Planning Guide link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.