Who Wants a 100-Million-Entry AD?

Everyone realizes that the Windows NT SAM is a domain-scalability bottleneck, given its practical limit of about 40,000 user accounts in any one domain. Some companies have probed the upper limits of the SAM and have built very large domains. But they've found that these domains are difficult to manage. To work around the limitations of the SAM, many implementations have included far too many account domains.

Windows 2000 is based on Active Directory (AD), a repository for user accounts and many more object types. You can be confident that Microsoft won't make the same mistake twice—AD is more scalable than the SAM is. How much more scalable is an interesting question. How many objects can you store in one domain, how large and manageable is the database, and what type of performance can you expect from AD?

To find out, we created a very large AD database, whose capabilities we demonstrated at Comdex in Las Vegas in November 1999 and at the Win2K launch in San Francisco in February 2000. Our AD scalability demonstration shows that the database can cope with 100 million entries in a realistic production environment. Before we show you how we built the demonstration database and reveal what the building process taught us about AD, let's review some AD basics.

AD Database Basics
AD is a transactional database that features a write-ahead logging model and uses Microsoft Extensible Storage Engine 97 (ESE97) technology. Microsoft Exchange Server 5.5's Information Store (IS) and Directory Store also use ESE97. Although some small differences exist between Exchange Server's and AD's ESE97 implementations, the lessons that Exchange administrators have learned over the years are good preparation for AD management. Exchange 2000 Server uses the ESE98 engine, a newer ESE version that supports database partitioning and the streaming file for Internet content. Currently, AD doesn't need to partition its databases and holds only record-oriented data, so there's no point to AD using ESE98.

We've accumulated a great deal of experience with ESE. We know it's scalable because many Exchange 5.5 servers support databases larger than 100GB. The database can grow large without compromising performance if administrators carefully balance the I/O load. Most important, ESE can deal with hardware failures through soft or hard recoveries of data from its transaction logs. In a soft recovery, the system fails for some reason, but you don't need to restore the AD database file from backup. A hard recovery is typically caused by a catastrophic disk failure that requires you to restore the AD database from backup.

Figure 1 shows AD's architecture. You access AD through various client interfaces. Clients such as Microsoft Outlook 2000 use Messaging API (MAPI), whereas Win2K's standard Find Users feature uses Lightweight Directory Access Protocol (LDAP). Programs such as ADSIEDIT (a tool from the Microsoft Windows 2000 Resource Kit that lets you examine information about AD objects) use Active Directory Service Interfaces (ADSI) as their main programming interface.

The directory service agent (DSA) handles transactions and communicates through the database layer to ESE. The DSA and database layers represent the AD schema and functions; ESE is concerned only with managing information within the database. The database layer is responsible for taking data from the DSA and transforming it into a format that ESE understands.

The files on disk include ntds.dit, which is the AD database; a set of transaction logs; a checkpoint file that records the last buffer committed to the database; and a temporary database file. These files are comparable to dir.edb (the ESE97 database that the Exchange 5.5 Directory Store uses) and its attendant transaction logs and checkpoint file.

Figure 2 shows some of the files we used in the AD scalability demonstration. Note the size of the database (ntds.dit), which contains 100 million objects. Notice also that the transaction logs are 10MB. In contrast, Exchange transaction logs are 5MB. The difference is due to the size of the records within the databases. Exchange uses a 4KB record; AD uses an 8KB record, largely because AD holds more than 4KB of information for an average user account. Microsoft could have specified a 4KB record size for AD, but the result would have been a large number of page overflows and an inefficient internal database structure. Larger records mean that each transaction can capture more data, so Microsoft increased the log-file size to avoid some file-creation overhead.

I/O Patterns and Transaction Logs
Observation shows that 70 to 90 percent of all operations that AD performs on ntds.dit are reads. These numbers aren't surprising because AD's basic function is user authentication, which requires a check of passwords held in AD against user-supplied credentials. Even an application such as Exchange 2000, which puts information in AD, performs more reads than writes because it tends to retrieve far more information than it updates.

Access to ntds.dit is multithreaded and asynchronous. In other words, many threads run at one time to service requests from different clients and applications. Write operations return control to ESE immediately, but ESE might wait for a while before applying an update to the database.

The system reads log files only during a soft or hard recovery operation, when it must replay transactions. Writes are single-threaded and synchronous. One thread controls all writes, so only one write operation can be in progress at any time. The calling thread must wait until a write is complete before the thread can proceed. AD accesses log files sequentially and appends data to the end of the current log.

When you add, modify, or delete an AD object, the database engine first writes the transaction to a set of buffers, forming an in-memory cache, then immediately captures the transaction in the current transaction log (edb.log). When both operations are complete, the system considers the transaction committed. This implementation ensures that the data is recoverable before the system makes any attempt to write it to ntds.dit.

Lsass.exe (the Local Security Authority—LSA—process) controls all AD transactions. When system load allows, lsass.exe checks the memory cache for unsaved pages, saves those pages to the database, and moves the checkpoint pointer while the system saves buffers. Should a system crash or disk fail at this point, you can recover the data from the transaction logs.

   Previous  [1]  2  3  Next