x64 DCs are slowing getting rolled out to various companies. Most often I am hearing amazing things from an LDAP query standpoint which is great.
I am curious though how people are determining how many DCs they need? Are they just replacing their x86 DCs and leaving it at that or are they carefully watching performance and scaling DCs down as needed or just going forward with ball park guesses on what they will need for Exchange and Auth?
There is a nice whitepaper (http://www.microsoft.com/downloads/details.aspx?FamilyID=52E7C3BD-570A-475C-96E0-316DC821E3E7&displaylang=en) on the perf benefits of x64 for Domain Controllers but it has an omission for interactive auth. It has auth in general, but not interactive auth with the processing of GPOs, scripts, etc. This is important because you are talking about file ops which don’t appear to get that big speed boost you get with directory access.
Obviously this is all firmly entrenched in the world of “it depends” but sometimes you start with a greenfield deployment (say moving from some other OS to Windows) and can’t benchmark everything in a lab so where do you start? The ADSIZER hasn’t been updated since Windows 2000 because it has been killed, it was too easy to give false expectations. You could get burned by getting a result that was either under or overkill. Why? Because IT DEPENDS. You can understand why MSFT doesn’t want to give out false expectations… Generally in a greenfield deployment there are so many unknowns you have no clue what you are going to do or end up with. But it would be nice to have rough guidelines for a place to start. Most companies will not buy X hardware and then add to it as needed to get to Y where everything runs well. They want to know up front what Y is so they can understand their costs. You can’t argue with that other than by saying… it depends. With x86, it is a known beast, we have been dealing with it for some time and most consultants and support folks have seen it in real life under heavy load and have an idea of where you can ballpark. Not so with x64, we don’t have that built up “gut” level knowledge yet.
So let’s hear what you are doing with x64 and what your experiences have been…
joe
The first of our x64 hardware for new DCs just showed up. We’re doing a 1 for 1 replacement. More info in a couple of weeks.
well, IT DEPENDS is really the best answer. A company with a fairly small AD environment, where the DCs are not memory-constrained today, i.e. the whole DIT fits in memory, won’t really do much DC consolidation. They’ll have placed maybe 2 or 3 DCs in their hub-sites for fault-tolerance and a single DC (or none at all) in their branch offices, the later mostly for autonomy in case the WAN is out. 64bit DCs won’t change this picture very much.
So it should be clarified that the discussion really only matters for companies whose AD DIT is currently larger than approx. 2.6 GB or growing towards this limit (which is the max size that AD will be able to cache on the 32bit Win2003 OS using the /3GB boot ini option). Companies with larger DITs may already have noticed performance issues with their current applications leveraging AD, such as Exchange. In this case it is not uncommon for them to add new DC/GCs to spread the load.
This is where the 64bit DCs will help improve the situation – we’ve tested that a 64bit DC sufficiently equipped with memory to cache the whole DIT (e.g. 7GB) will easily take the load of 4 memory-constrained 32bit DC/GCs. Certainly this is not a general rule and your milage will vary, but a DC that can cache the whole DIT is worlds appart in query and auth. performance to a DC that can’t – however, I don’t have any specific numbers yet on the benefits rgd. the interactive auth load.
/Guido
We’re looking at implementing x64 in the new year. We’re in the initial phase of deployment and the latter stages of design, and one of my current tasks is looking at x64. We estimate our DIT is going to be somewhere in the region of 30 – 35 GB, therefore x64 is very important to us. We anticipate a consoldation of current numbers when we start implementing x64. The main issue that is stopping us pushing this stuff through pre-prod and into live now, rather than later, is there are a number of core tools that are not x64 compatible. I think this is a major reason why the uptake isn’t as radical as some of us expected. HP Protect Tools Authentication Services isn’t 64-bit yet, so we’re waiting on that and a systems management app client.
We are expecting to handle more outlook cached mode users per DC, as well as fewer DCs for application servers.
At the moment, we’re unsure about exchange and are simply going to do a 1:1 replacement of the current exchange site’s GCs.
It looks like we’re all gently probing the area, but none of us are more than knee deep with it yet. I was expecting Guido to have had some more info. as HP have been testing this stuff for ages. I believe there are some whitepapers on DL385s and k3 x64 out, or in the pipeline…
We were discussiing the 64bit DC planning today, and the question of th the Event Log Size limit being maxed at 300mb came up. Does the 1gb per process limit exist in the 64-bit version?
More info here: http://jeftek.spaces.live.com/blog/cns!F2042DC08607EF2!699.entry
Jef
quick feedback for Paul: yes, we do have more infos, it’s just difficult to make some puplic statements before anything is officially available. We did a lot of unofficial testing that we’re using internally and with customer engagements – the same is basically true for MSFT.
But just like MSFT we first want to gain more experience with some large scale projects currently going on, leveraging x64 DCs, prior to giving you public sizing guidance.
However, the inforamtion I mentioned above should already give you a good rule of thumb: in customer environments where the DIT currently doesn’t fit into memory (typically > 50.000 users, but could also be reached with much less), I typically plan to replace 4 32bit DCs with one 64bit DC and sufficient physical memory (may need more for fault tolerance etc.)
BTW, usually no need to use the Win2k3 x64 Enterprise Edition for DCs, since x64 Standard already supports 32GB physical memory. Your environment sounds like it will be very close to that limit though.
/Guido
Paul:
30Gb???? What the hell are you putting in there? What are you using to do the sizing? ADSIZER? If so, toss out the numbers. I just worked up a test environment that ADSIZER indicated would work out to ~9-10GB DIT and the DIT is ~3GB. Of course keep in mind ADIZER was designed with 2K in mind, not K3 and there are things such as single instance store of SD’s to reduce DIT size.
Thanks for the info. Guido.
Joe, yeah we did a number of calculations with ADSIZER that gave us some fun numbers. We deduced ~30GB based on the smaller numbers from ADSIZER and the current size in pre-prod (8GB with only 1/8 of the user base and more than 1/2 of the apps missing).
We’re currently investigating ways of reducing the size, e.g. storing the HP OpenView Radia information in ADAM, as well as getting some of our bespoke apps using ADAM instead. We can sync the ADAM instances using the existing MIIS infrastructure, or look at ADAMSync for specific attributes of specific objects.
I do like the rough idea of reducing 4 GCs to 1, but I don’t think that’s going to hold. I’ve been discussing some of this offline with Joe and we (he more than I 😉 realised that interactive logon still whacks the CPU and the disk, meaning an x64 DC can’t cope with loads more logons the x86 even though from an LDAP perspective (read -read access to the in-memory DIT) it certainly can.
When our apps are compatible with x64 I will post feedback back here. In the meantime I’d be interested in seeing how you guys are doing with your current projects (and your internal stuff).