OUs are designed to break up AD data into manageable chunks. Loading more than 10,000 objects into one OU is a bad idea because the performance of standard management tools such as the Microsoft Management Console (MMC) AD Users and Computers snap-in degrades significantly if you ask these tools to fetch large amounts of data each time an OU is expanded. By default, the MMC AD snap-ins fetch 2000 records when they open an OU. You can set an option to fetch more records, but this will slow down operations. It's best to design an OU structure so that each OU stores fewer objects. For example, our US phone number AD would have been far more efficient if we had established an OU for each county within a state and further subdivided some large counties.
Each phone number is represented in the AD as a separate contact object. Contacts are smaller than user objects because they aren't Win2K security principals. We could have created user objects rather than contact objects but chose not to because the load would have been slower. The resulting database would also have been larger (maybe twice as large), but searches would likely take the same amount of time because AD uses indexes effectively when searching attributes such as a last name.
Replication
AD replicates information between domain controllers to keep the directory in a state of loose consistency. The exact state of consistency depends on how often the domain controllers replicate, how many domain controllers are involved in replication, and the number of changes that occur to the data. Creating a very large directory on one server establishes a potential single point of failure, so we added a second server to our configuration.
You use the Dcpromo procedure to promote a Win2K server to become a domain controller. The promotion process replicates a complete copy of AD to the new domain controller. The load program can create new objects at slightly more than 130 objects per second, or nearly half a million objects per hour; however, replication proceeds much more slowly, at about 30 objects per second, probably because remote procedure calls (RPCs) send each object individually from an existing domain controller to the server you're promoting. The default size of a replication packet is roughly 900 objects. You can increase the packet size to send more objects at one time, but this action increases the amount of memory the process uses. As Figure 4 shows, promoting a server to a domain controller in a domain that hosts a very large AD results in a lot of data transfer, so the operation takes a long time to complete. In our case, replication finished after 7 days. Most Win2K sites don't need to replicate this much data, but replication is clearly an area that deserves attention as Microsoft continues to tune AD.
Hardware Requirements
To be effective, NT domain controllers don't require a high-performance configuration. Some domain controllers are based on old 486-class systems equipped with 64MB of memory and a small disk, a setup that is sufficient to provide authentication services for a small domain. Win2K domain controllers also authenticate client access, but the AD replication mechanism and the transactional nature of the database mandate a more robust hardware configuration. The good news is that effective Win2K network designs feature far fewer domain controllers than NT networks do.
Some Win2K applications make specific demands on AD. For example, Exchange 2000 stores all its information about mailboxes, stores, and connectors in AD and accesses a Global Catalog (GC) server to provide the Global Address List (GAL) to clients and to route messages. Therefore, in a Win2K project that involves Exchange 2000, you must place GCs so that every Exchange 2000 server can easily connect to one.
Win2K domain controllers and GCs need the same type of hardware configuration as Exchange 2000 or Exchange 5.5 servers need. For large domains, a typical domain controller should have two CPUs, 256MB of memory, a RAID 1 mirror set for the AD logs, and a RAID 5 set for the AD database. "AD Test Hardware Configuration," details the hardware we used in our scalability test. Figure 5 shows the disk configuration on the server. As with Exchange, the database and the transaction logs must be in separate volumes. If both are on a single drive, failure of that drive will render both the database and the transaction logs unavailable and result in data loss.
The domain controller configuration we've described is a basic one—Win2K binaries and other application files require additional disks. A RAID 0+1 volume (i.e., striping with mirroring) provides better I/O performance and is appropriate for a server hosting a large database that you expect to be heavily accessed, such as a GC that serves several large Exchange 2000 servers.
Remember, Exchange 2000 depends on a GC to provide the GAL to clients and to make every routing decision that is necessary to deliver a message to a user. The GC is the definitive source for discovering which server holds a user mailbox, and the Exchange 2000 routing engine must access the GC to determine how best to process each message. The efficient use of a cache for recently accessed addresses mitigates the potential performance impact of all the GC lookups, but a cache can't compensate for an underpowered system configuration.
Most Win2K administrators won't be interested in running an AD as large as our test database. However, as the pace speeds up in the application service provider (ASP) race to deliver services based on AD-enabled applications such as Exchange 2000, an obvious need is developing for the ability to build and manage directories that host millions of objects. Our AD scalability demo proves that AD can host millions of objects and delivering good performance at the same time, provided the implementation is well planned and hosted on the right type of hardware.
Register
