Ever since Windows 2000 was introduced, administrators and architects have been trying to figure out how to size a domain controller. Sizing a server typically refers to the number of processors, physical memory, disk space and the application(s) that the server will host.
The problem with sizing a domain controller (DC) is that the load is so variable. DCs handle authentication via the Lsass.exe process, which has a number of functions. In addition, processor resources are consumed by database operations on the Ntds.dit database in a non-linear fashion. As such, the DC load can be inconsistent for the following reasons:
- The number of authenticated clients is unpredictable since multiple DCs share the load for clients in and out of the site.
- Applications that perform authentication and Lightweight Directory Access Protocol (LDAP) queries put additional weight on the DC.
- Authentication and access to Windows resources by non-Windows clients increase the DC load with LDAP queries.
- Inefficient LDAP queries can put an unpredictable load on the DC.
- Active Directory (AD) analysis and monitoring tools put additional load on the DC.
While these factors make it more challenging to size a DC, it’s still possible. The key is to measure actual performance and determine the load and required resources.
I’ve worked with a number of administrators whose DCs were not up to the task of handling their business. Using some fairly straightforward Perfmon analysis, however, I was able to relieve the pressure on the DCs that were affecting logon performance. Working backwards, I can determine sizing.
Lsass.exe is the key ingredient to resolving DC performance issues in Windows 2008 and 2008 R2, and is responsible for all the authentication activity on a DC. In order to tackle performance issues, Lsass.exe takes up CPU and memory resources and leaves a detailed memory footprint. The ultimate goal here is to get enough RAM to put the entire Ntds.dit file in memory and still service LDAP queries.
To begin, it’s important to make sure all DCs are installed on x64 servers in order to determine how much memory is required. Anything smaller won’t allow Lsass.exe the memory it needs.
Determining memory size starts by calculating the Ntds.dit file size plus 20%, and following that up with a Perfmon analysis. To do this, simply look at the Ntds.dit file size in %systemroot%\windows\ntds and review the Task Manager to see the memory consumption by Lsass.exe. Note that the Ntds.dit file will be the same size on each DC, but the LDAP load may vary per site.
Active Directory processors are also important to calculating domain controller memory size and are linked to AD Jet database session operations. Windows Server 2008 R2 actually has a registry key to control these sessions, but they need to be managed cautiously. The more processors in the mix, the more Jet database sessions available. But running out of Jet sessions can cause a variety of events indicating insufficient AD resources. To avoid this, start out with at least four processors.
Disk space is fairly simple to manage and follows general disk performance rules. Remember to use high performance disks and put the logs and SYSVOL folder on a separate disk (spindle) from the Ntds.dit file. The size of Ntds.dit file and SYSVOL folder will be the big hitters for disk space, unless other applications are being hosted on the DC.
By running a Perfmon analysis, admins can determine the load on memory, processors and disk space, as well as the performance of an existing DC -- preferably on an x64 platform. Just use the standard counters (memory, processor, disk, network, etc.), but add NTDS counters and the Lsass.exe process counter to minimize the performance impact on the DC. Run it for at least 48 hours to capture a couple of days of peak and non-peak activity.
Once the analysis is complete, evaluate the Lsass.exe process counter and look for continuous, sustained CPU and memory usage. Compare that usage to available memory to determine if the memory usage follows Lsass.exe. Figure 1 shows an increase in available memory in the early morning hours at the same that there is a spike in LDAP bind time (see Figure 2).
Figure 1: Available memory
Figure 2: LDAP bind time
According to the Perfmon analysis, the LDAP bind time spike is not associated with a decrease in available memory. Therefore, the data needs to be captured over a longer period of time.
Note: For LDAP bind time, look for sustained periods of 15ms+. PAL will flag warning and error levels.
It’s best to have a baseline to compare to for CPU analysis, but if there isn’t, best practice is to make sure CPU usage is not above 80% for sustained periods. Also look for dominance by Lsass.exe over resources. If the system isn’t handling the load efficiently, add memory or processors as required.
While there is no magic spreadsheet or tool, understanding how to analyze Lsass.exe, processors and disk space provide a fairly accurate method for sizing Active Directory domain controllers.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Gary Olsen is a Solution Architect in Hewlett-Packard’s Technology Services organization and lives in Roswell, GA. Gary has worked in the IT industry since 1981 and holds an MS in Computer Aided Manufacturing from Brigham Young University. Gary has authored numerous technical articles for TechTarget, Redmond Magazine and TechNet magazine, and has presented numerous times at the HP Technology Forum. Gary is a Microsoft MVP for Directory Services and is the founder and president of the Atlanta Active Directory Users Group.
This was first published in June 2011