By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
It seems everyone is jumping on the 64-bit bandwagon these days.
Microsoft has put Exchange Server 2007 on x64 platforms only, and at the Windows Hardware Engineering Conference 2007 last May, Microsoft general manager for Windows Server Bill Laing said that Windows Server 2008 would be the last 32-bit operating system for the client or server.
Obviously, 64-bit is a growing part of the Windows world, and it is important for IT managers to examine how it can impact their infrastructures. In order to learn how 64-bit can help, though, you must first understand how it works.
Currently, hardware is referred to as being 32-bit or x86. Very simply, it means that only 232 bytes (about 4 GBs) of physical memory can be addressed. A 64-bit system can address 264 bytes (16 exabytes) of physical memory. Of course the operating system must know how to address that memory so that the application can use it -- meaning the actual addressable memory ultimately rests with the OS.
In 32-bit Windows, 2 GB is reserved for system instructions, or the kernel, leaving only 2 GB for applications. While some apps like Exchange Server can steal 1 GB from kernel space by using the /3GB switch applied in the Boot.ini, it limits kernel memory, which can be dangerous. In addition, the application has to know how to use that extra memory.
Intel Corp. developed a memory feature called Physical Address Extension (PAE). It allows addressing of memory above the 4 GB limit. However, in order to use the additional memory, applications must use Address Windowing Extensions (AWE) APIs and admins must add the /PAE switch to Boot.ini. While these features can help, they are basically slight of hand tricks trying to extend a hard limit.
When physical memory is depleted, the OS stores instructions in the page file on disk. Moving information between the page file and memory when it is needed by applications is called paging, and it degrades performance. If an application can run entirely in memory and never have to access the page file, performance will be much more efficient than it is when paging is required. In a 64-bit system, it is quite feasible to load applications entirely in memory.
Two distinct 64-bit platforms
A very important point to make here is that there are two different 64-bit platforms. Intel developed the Itanium processor (IA64), which is a completely new architecture engineered from scratch. However, Itanium systems are very expensive and not feasible to use for workstations or low-end servers.
Note: x64 Windows can address 8 TB of physical memory, while IA64 Windows can address about 24 TB (though improvements make these values moving targets).
To meet the need for inexpensive 64-bit systems, the x64 chip was developed. This processor is basically an extension of the x86 (32-bit) processor that permits addressing in the 64-bit model. While Itanium-based systems haveare magnitudes more powerful magnitudes in terms of performance and scalability, x64 systems can usually satisfy most needs.
Microsoft has stated that even a memory hog like Exchange Server can't take advantage of Itanium's power, so Exchange will only run on x64 platforms. Many apps, in fact, will have better performance on x64 or even x86 systems than on Itanium. It really depends on the application. Databases, computer graphics and video seem to be the killer apps for Itanium. The important thing here is that you really must perform your own benchmarks when evaluating if x64 or Itanium will give your environment any advantages, and you will probably end up with a mix of the two.
64-bit and Active Directory
OK, so now that we have a basic understanding of 64-bit technology, let's see if Active Directory can use a 64-bit architecture.
Each domain controller has a copy of the Active Directory database, NTDS.dit. Like any other application, Active Directory loads this database into memory and the page file. Also like other apps, Active Directory functions will exhibit better performance if the domain controller has more memory to hold the database. In the 32-bit world, if your AD database is larger than 2 GB (which is not hard to do), you will have a performance degradation, as opposed to putting it all in memory.
Now let's say you have a 6 GB Active Directory database. You will be able to benefit by moving your DCs to 64-bit Windows and loading NTDS.dit entirely in memory. Several years ago, Hewlett-Packard Co. converted several DCs to x64 servers and noticed a huge benefit. HP's NTDS.dit was around 8 GB -- about four times what could be loaded in memory on x86 platforms. There is little doubt that 64-bit DCs will show a huge benefit.
There are other issues to consider, however, such as the inability to load the entire NTDS.dit into cache and figuring out which functions in AD can actually benefit from the larger memory model. You also may wonder if having everything loaded in memory precludes the need for a page file. These issues will be addressed in a future article in more detail.
The next question, then, is if there is any further benefit to using IA64 systems for DCs. The simple answer is no. I personally don't know of anyone that has really tested DCs on IA64 simply because the performance benefit of x64 is great enough to make the higher cost of Itanium systems unjustifiable.
That really is the story in evaluating x64 systems and IA64 systems. You must determine if the application's performance benefits can justify the cost of the IA64 system. Itanium certainly has its place, but probably not in Active Directory.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.