Renaming the thead due to change of focus
topic
I've been doing quite a bit with my own 64bit notebook
(using WinXP x64) in the past few weeks and I do have to say that there are
plenty of little surprises. Many of which don't play a role for servers, which
are used with a much lesser range of applications and drivers (usually no issues
with high res video; WLAN; bluetooth etc.). I was actually more successful
to get the right drivers for WinXPx64 than for VISTAx64, which is why I stuck
with WinXP for now (this will change soon, as Vendors pick up their support for
Vista and any driver will have to be available as 32 and 64bit to be Vista
ready).
But it's not only drivers, it's also some 32bit
applications that - although they don't have a driver dependency (which must all
be 64bit) - simply refuse to run in the WOW64 instance (a 32-bit Windows
instance on in a Win x64 OS). Have to say that the most important 32bit
apps (such as MS Office 2003) and naturally all 64bit apps do run though without
issues. And I can work around most of the other 32-bit problems by
leveraging a 32-bit WinXP VM on the same box (not ideal, but better than two
machines).
So a lot of testing is required either for deployment of
64-bit clients (which I'd rather do with Vista when released) or even with
64-bit Terminal Servers that are used to host office applications for users
(generally a great idea, as you have plenty of more virtual memory available for
hosting many more users per TS).
See my other note on 64-bit for DCs in the "Raid 1
tangent -- Vendor Domain" thread with many more details on the difference of
memory handling between the two worlds. 64bit is certainly the right way to go
for most larger AD deployments.
I'd love to hear about other's experience with 64-bit
Windows - how are you leveraging it and what were the problems you've been
running into...?
What were your solutions or
workarounds?
/Guido
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Hargraves
Sent: Sunday, July 23, 2006 5:26 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Raid 1 tangent -- Vendor Domain
On 7/23/06, Matt
Hargraves <[EMAIL PROTECTED]
> wrote:
That being said.... wait on 64-bits for the client side until you know, unequivocably, that all of the software that your clients need is supported and stable on a 64-bit OS. The performance boost isn't that big of a deal, just to be honest.
On 7/23/06, Matt Hargraves < [EMAIL PROTECTED]> wrote:Just as an FYI: I've seen 64-bit DCs run and I have one thing that I can recommend to everyone:
Go 64-bits as soon as possible. There are hundreds of benefits on the server side when going 64-bits, whether it's Exchange (yay for 2007) or your DCs, the performance level is just staggering compared to a 32-bit OS. All your former large application limitations just kinda disappear, unless it's an application-based limitation. No 3GB limitation on the application memory size, no paged pool memory limitation for connections (this hits Exchange first).... It's like you're crippling your hardware by staying 32-bits nowadays if you don't have to.
On 7/22/06, joe < [EMAIL PROTECTED]> wrote:That's a command line guy for you...
:o)
The thing is that I type in a very odd way two, my whole right hand just one
or two fingers from my left hand. People tend to get a bit confused when
they see me type.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto: [EMAIL PROTECTED]] On Behalf Of Kevin Gent
Sent: Saturday, July 22, 2006 7:29 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Raid 1 tangent -- Vendor Domain
joe,
you must type really, really fast............
----- Original Message -----
From: "Albert Duro" < [EMAIL PROTECTED]>
To: < ActiveDir@mail.activedir.org>
Sent: Saturday, July 22, 2006 7:06 PM
Subject: Re: [ActiveDir] Raid 1 tangent -- Vendor Domain
> no debate from me. I was just asking. Thank you for the lesson.
>
> ----- Original Message -----
> From: "joe" < [EMAIL PROTECTED] >
> To: < ActiveDir@mail.activedir.org>
> Sent: Saturday, July 22, 2006 9:48 AM
> Subject: RE: [ActiveDir] Raid 1 tangent -- Vendor Domain
>
>
>> Mirrors don't scale.
>>
>> Microsoft's deployment doc mostly just talks about using mirrors (small
>> nod
>> to RAID 10/0+1) so everyone thinks that they should build their Corporate
>> DCs on mirrors, usually 3 - OS, Logs, and DIT. Very few people if anyone
>> would build a corporate Exchange Server on mirrors... Why not? The DB is
>> the
>> same under both of them... What is critical to Exchange? IOPS and that
>> means
>> spindles. If something is really beating on AD and the entire DIT can't
>> be
>> cached, IOPS are critical to AD as well. The main difference is that AD
>> is
>> mostly random read and Exchange is heavy writing and reading. The
>> exception
>> to this is the edge case of Eric's big DIT[1] in which he dumped 2TB of
>> data
>> into AD in a month at which point he did something that few people see,
>> pushed the IOPS on the log drive through the roof.
>>
>> In a smaller environment (very low thousands), or for a low use DC (small
>> WAN site), or a DC with a DIT fully cached a RAID-1 drive for DIT will
>> probably be sufficient, you will note that the only numbers mentioned in
>> the
>> deployment guide are about 5000[2]... That usually means a small DIT and
>> it
>> is extremely likely that a K3 DC will cache the entire DIT. Plus the
>> usage
>> is probably such that the IO capability of two spindles will likely be
>> ok.
>> Let me state though that even in a small user environment if there was an
>> intensive directory based app or a buttload of data that pushes the DIT
>> into
>> GB's instead of MBs I would still be watching my disk queueing pretty
>> close
>> as well as the Read and Write Ops.
>>
>> AD admins who aren't running directory intensive apps (read as Exchange
>> 2000+) usually don't see any issues but then again most aren't looking
>> very
>> closely at the counters because they haven't had a reason too and even if
>> they had some short lived issues they probably wouldn't go look at the
>> counters. At least that has been my experience in dealing with companies.
>> I
>> will admit that prior to implementing Exchange when I did AD Ops with a
>> rather large company I didn't once look at the disk counters, didn't
>> care,
>> everything ran perfectly well and about the only measure of perf was
>> replication latency and does ADUC start fast enough and it always was
>> fine
>> there unless there were network related issues or a DC was having
>> hardware
>> failure.
>>
>> Enter Exchange... Or some other app that pounds your DCs with millions of
>> queries a day and tiny little bits of latency that you didn't previously
>> feel start having an impact. You won't feel 70-80ms of latency in
>> anything
>> you are doing with normal AD tools or NOS ops, not at all. You will feel
>> that with Exchange (and other heavy directory use apps), often with
>> painful
>> results unless it isn't consistent and the directory can unwind itself
>> again
>> and hence allow Exchange to then unwind itself.
>>
>> Now let me point out, I don't deal with tiny companies for work, small to
>> me
>> is less than 40-50k. The smallest I tend to deal with is about 30k. I
>> usually get called to walk in to Exchange issues where Exchange is
>> underperforming or outright hanging, sometimes for hours at a time. There
>> can be all sorts of issues causing this such as
>>
>> O poor disk subsystem design for Exchange (someone say got fancy with a
>> SAN
>> layout and really didn't know what they were doing seems to be popular
>> here)
>>
>>
>> O hardware/drivers on the Exchange server just aren't working properly
>> and
>> the drivers are experiencing timeout issues (for some reason I want to
>> say
>> HBA here)
>>
>> O poor network configurations and odd load balancing solutions, etc that
>> generate a whole bunch of say keep alive traffic on the segment that no
>> one
>> had any idea about because no one understood the solution nor took time
>> to
>> look at the network traces. Or maybe
>> the infamous Full/100 on one end and half/100 on the other. Whatever.
>>
>> O Applications that beat the crap out of Exchange that weren't accounted
>> for
>> in the design well or at all... such as Blackberry or Desktop Search or
>> various Archive solutions
>>
>> O Poorly written event sinks, disclaimer type products that query AD
>> themselves for additional info fit nicely into this category (hint do not
>> deploy one of these unless you understand the queries it generates)
>>
>> O DCs being too far away say like an Exchange server in the US hosting
>> APAC
>> users. If you are running Exchange, you put Exchange and the DCs for the
>> domains of any users on that Exchange server on the same physical subnet.
>> And if you have a multidomain forest, strongly consider shortcut trusts
>> between the domains that the Exchange servers are in with the domains the
>> users are in.
>>
>> O DCs underperforming
>>
>> The last is almost always, heck, I will say in 98% of the cases I have
>> had
>> to investigate, related to DC disk configuration and it is always a
>> mirrored
>> setup. In fact, almost always it is the deployment guide recommendation
>> of
>> mirror for OS, mirror for logs, and mirror for DIT. Then you look at the
>> perf and you see that the counters on the DIT disk are in the nose bleed
>> seats and you are getting maybe 150 ops per second through the DIT disk
>> and
>> counters on the OS and log drives can't even be viewed unless you use the
>> multiplier to boost them in perfmon because they are dead asleep with an
>> occasional bump to let you know they aren't outright dead.
>>
>> The logic is fairly sound if you don't probe it too deeply, of course you
>> want the OS by itself because you don't want it impacting the directory
>> perf
>> and you don't want directory perf impacting the OS. The logs are
>> sequential
>> and the DIT is random so you don't want to mix and match those as you
>> will
>> impact log perf. But then you look at the counters and again, the OS is
>> sleeping and the Logs are sleeping and the DIT is on fire with no water
>> in
>> sight. What do you need for the DIT in this condition? Gold star to
>> whomever
>> said "Available IOPS capability" first... How do you add the capacity for
>> more IOPS? You add spindles. How many IOPS do you need for your DIT? Good
>> question, I have never seen a document that starts to help you guess that
>> as
>> profiling DC usage is tough. Probably tougher than profiling Exchange
>> usage
>> where you do hear a lot about how many IOPS capability you need. If you
>> want
>> a nice baseline of how many you need, start with as many you can freakin
>> get
>> in the box you have available. I.E. Every slot you have for a disk you
>> put a
>> disk into and give that to the DIT drive, the OS and Logs fit in wherever
>> there is room and they don't get dedicated slots. You will not be
>> penalized
>> for having too much capacity for reading the DIT.
>>
>> So then I spend 1 day to 3 weeks trying to convince the folks that AD is
>> causing an issue even though LDP, ADSIEDIT, etc[3] fires up properly and
>> seemingly quickly and people assure me that before Exchange came around
>> everything worked great and everyone was happy so obviously the DCs are
>> fine
>> and it is Exchange that is the problem. If I can't prove things with the
>> counters I usually have to prove it with a little script I have that
>> sends
>> queries to the DCs in a couple of sites (some with Exchange and some
>> without) every 1-5 minutes and generates a little simple graph showing
>> the
>> response times. Currently this only has a resolution of seconds because
>> it
>> requires spinning up an outside executable and perl does seconds easily
>> for
>> the timers. However, it is usually quite rare that I don't have a graph
>> at
>> the end of the week that helps me determine the usual interval for online
>> defrag for each DC as well as when the users are logging into Exchange.
>> For
>> the most part the non-Exchange DCs are all showing response times in that
>> graph of 1-2 seconds (again recall the resolution is seconds, the actual
>> responses to the multiple queries are subsecond) and the Exchange servers
>> will be 1-2 seconds except in the mornings (or during heavy DL periods)
>> at
>> which point I have seen timings of 4,5,6,7 seconds and sometimes as bad
>> as
>> 15,20,30 seconds. Let me put it this way, if it take a couple of seconds
>> to
>> return a simple query of a couple of attributes of your schema... There
>> is
>> an issue regardless of whether your NOS users feel it or not or if some
>> admin tool works ok.
>>
>> So finally someone says, what can we do? I say, rebuild the disk array
>> with
>> a single RAID 10 or 0+1, you pick, I don't care about anything other than
>> the perf and they are identical, you can argue out the redundancy points
>> amongst yourselves. If that isn't an option, I say use RAID-5. Anything
>> that
>> throws multiple spindles at the DIT. I lump it all together, OS, DIT, and
>> Logs. There is no reason you should be protecting your OS and Logs such
>> that
>> they are sleeping while the DIT is burning. If a DC isn't running AD very
>> well, I don't care if the OS is running well, it is a moot point. As for
>> the
>> logs... They are a rounding error unless you are like Eric and really
>> like
>> playing with your DIT by pounding it with writes.
>>
>> Between RAID 10/0+1 and 5, from the numbers I have seen, 10/0+1 tends to
>> enjoy somewhere in the area of a 2-10% perf for available OPS with the
>> same
>> number of spindles used. Usually what you see though is that you have say
>> a
>> machine with 6 disk capability and you will see a 5+1 RAID-5 (+1 is the
>> hotspare) or a 4+2 RAID-10/0+1. Right off the RAID-5 has the benefit of
>> having an additional spindle over the RAID-10/0+1 configuration so it
>> should
>> outperform the RAID-10/0+1. Me, for a staffed class-A datacenter with a 6
>> disk internal capability I would run a 6 disk RAID-10/0+1 then if that
>> wasn't ok a 6 disk RAID-5. Hot spares are for sites where you have no
>> clue
>> how long it will take to get someone in to change the disk. If you have a
>> staffed datacenter it shouldn't take more than 60 minutes to get a disk
>> swapped, really it shouldn't be but 10-20 minutes. That is what all that
>> monitoring and 24x7x365.25 staff is about.
>>
>> Oh... One more thing before I wrap this... You don't get perf gain from
>> logically partitioning a single RAID array. I have seen deployments where
>> they actually went with a multiple spindle disk configuration and then
>> broke
>> the OS, Logs, and DIT up into different volumes within the OS... OS I am
>> fine with, it is a nice mental breakout of that aspect, but the points in
>> separating the LOGs and the DIT aren't that great that I am aware of
>> unless
>> you expect to run your DIT out of space and you really shouldn't be
>> thinking
>> about doing that (again monitoring but also protecting your directory
>> from
>> letting people add things unhindered). Certainly breaking things out by
>> volume isn't a perf gain and personally I think it adds to the design
>> complexity needlessly.
>>
>> So if your DIT is under 1.5GB and you have the RAM to cache that DIT on
>> K3
>> AD then a mirror will probably be fine for you. If the DIT is under, what
>> is
>> it about, 2.7 or so GB, and you have the RAM and /3GB on K3 AD enabled
>> then
>> a mirror will probably be fine for you. If you have a WAN site that has
>> some
>> basic users logging on and getting GPOs and accessing file shares
>> locally, a
>> mirror will probably be fine for you. If you are just doing NOS stuff
>> then a
>> mirror may be fine for you even in real large orgs. If you are outside of
>> that criteria, think hard about whether a mirror is right for you and
>> prove
>> that out by watching the disk counters. If you have Exchange beating
>> against
>> your AD and it can't be cached, a mirror is most likely not going to be
>> as
>> performant as it should be for *optimal* Exchange performance.
>>
>> I say optimal because Exchange may appear to be fine but as I often tell
>> people, Exchange will put up with a lot of stupid things until it hits
>> the
>> limit and then it will throw a fit and blow out completely on you and you
>> have to chase through and figure out out of all the stupid things you are
>> doing, which one is the one pushing it over the edge this time so you can
>> fix it (reminds me of some relationships I know of with girls taking on
>> the
>> part of Exchange and guys taking on the part of doing lots of stupid
>> things<eg>).
>>
>> I don't have a lot of experience yet with x64 DCs but my gut says that
>> assuming you have enough RAM to cache the entire DIT and you aren't
>> constantly rebooting the DC or doing things that force the cache to be
>> trimmed, the disk subsystem is really only going to be important for
>> writes
>> (which we have already said aren't really all that much of what AD is
>> doing)
>> and the initial caching of the DIT.
>>
>> Let the debates begin. :)
>>
>>
>> joe
>>
>>
>>
>>
>>
>> [1] http://blogs.technet.com/efleis/archive/2006/06/08/434255.aspx
>>
>> [2] BTW, I read that 5000 as total users using AD, not users using that
>> one
>> DC. The more users you have, the more likely your DIT is going to hit a
>> size
>> that can't be cached.
>>
>> [3] Even in one case adfind was used to prove AD was fine and the person
>> didn't know I wrote it... That was an interesting conversation as the
>> person
>> tried to explain to me how ADFIND worked and then I explained he was
>> wrong
>> and laid out the actual algorithm for what it was doing and he said I was
>> wrong and I said I hope not, I wrote it.
>>
>>
>> --
>> O'Reilly Active Directory Third Edition -
>> http://www.joeware.net/win/ad3e.htm
>>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto: [EMAIL PROTECTED] ] On Behalf Of
>> [EMAIL PROTECTED]
>> Sent: Saturday, July 22, 2006 11:06 AM
>> To: ActiveDir@mail.activedir.org
>> Subject: RE: [ActiveDir] Raid 1 tangent -- Vendor Domain
>>
>> "- stop using mirrors damnit) ."[1]
>>
>>
>> can you please explain that? What's wrong with mirrors?
>>
>> [1] joe, speaking particularly in the context of Exchange
>> List info : http://www.activedir.org/List.aspx
>> List FAQ : http://www.activedir.org/ListFAQ.aspx
>> List archive: http://www.activedir.org/ml/threads.aspx
>>
>> List info : http://www.activedir.org/List.aspx
>> List FAQ : http://www.activedir.org/ListFAQ.aspx
>> List archive: http://www.activedir.org/ml/threads.aspx
>>
>
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ml/threads.aspx
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
