The story of the MSDTC resource and Exchange 200x cluster servers


As I already mentioned on my blog, here is some information on a somewhat confusing subject. I added two more questions about MSDTC that we hear often:

 

Over the years, the best practice recommendations on where to place the MS Distributed Transaction Coordinator (MSDTC) resource in Exchange cluster has bounced between two differing views. One camp thought it was unadvisable to place this resource in the cluster group occupied by the quorum resource, while others noted that Exchange doesn’t really use DTC and its wasteful to dedicate a whole group (with IP and disk) to this resource.

Let’s address this from the bottom up:

Why does Clustered Exchange 200x need a MSDTC resource anyways?
Exchange provides support for a workflow function, and this capability is installed on all Exchange 200x servers by the Exchange setup. This functionality is encapsulated in the CDOWFEVT.DLL binary. This workflow functionality requires various components to be registered with COM+ to function. COM+ requires DTC to be running. And on Clustered Windows, DTC won’t initialize unless it’s configured for the cluster — ala MSDTC resource. Perhaps this domino-effect failure is familiar, particularly if you’ve run into the problem described in KB.312316!

So, does Exchange 200x workflow use MSDTC extensively?
Nope. Essentially just for the setup/upgrade steps, particularly if you’ve not actively implemented workflow applications.

OK, so – if that is the case – can we take the MSDTC resource offline and keep it that way on our clustered Exchange server?
If you are not using workflow applications on your clustered Exchange server – that is fine, the MSDTC resource can be kept offline. You do need to remember to bring the resource ONLINE though when running Setup of Exchange service packs or hotfixes.

What about deleting the MSDTC resource and then recreating it when having to run Setup?
This has not been tested and therefore we can not recommend it.

When, then, do some folks recommend to not put MSDTC into the default cluster group?
KB.168948 says pretty clearly not to put anything in the default cluster group that doesn’t need to be there. This is a very important group, and anything placed in this group can contribute to lowered availability of the cluster.

But doesn’t the old COMCLUST.EXE program put it there automatically?
Yes. Typically. Unless you follow the wacky steps in
KB.290624. This is a big part of what leads to this confusion, because in Windows 2003 you don’t use Comclust anymore, instead following the steps in KB.301600 so we see lots of variation with customers here based on which method they followed.

Ok, that makes sense… so why do others say DO put it in that group for Exchange 200x clusters?
Here’s where it gets interesting. Consider the characteristics of a typical, real-world Exchange 200x cluster server: heavily-loaded, never enough disk spindles, etc. If you follow this path of recommendations, now all of a sudden you need to add AT LEAST one extra IP, one extra network name, and one extra physical disk. Just to support this MSDTC resource that 99% of Exchange clusters only need for setup/upgrade purposes. If you have to choose between allocating this extra disk spindle to an underutilized MSDTC resource or to an under provisioned database store LUN, most Exchange design architects will choose the second!

Microsoft has long advocated the first option (dedicated group/disk/etc for MSDTC) as a best practice, since it maintains the cluster group containing the quorum disk untouched. Pretty much all of the documentation and KBs currently state this position. However, after a bunch of internal discussion and debate, this recommendation is about to change and the KB/documentation will be updated shortly.

So, if you have long ignored older recommendation and placed the MSDTC resource in the cluster group containing the quorum… you’re fine. Exchange so minimally utilizes DTC that the performance hit and impact to cluster availability are negligible and generally not worth allocating the additional resources. Put that extra disk toward your Exchange data storage instead (see previous postings here, here, and here for more). Additionally, it is recommended that you remove (uncheck) the option to “Affect the Group” from this MSDTC resource, so that if it does ever fail it will not impact the cluster group containing the quorum resource.

Note that this recommendation change does NOT apply if you are running SQL or some other application that utilizes MSDTC extensively. If your MSDTC is being utilized, you definitely still should keep this resource out of the cluster group containing the quorum to avoid any possible negative effect on cluster availability.

Evan Dodds


Comments (6)
  1. Doug says:

    This only applies to physical disk clusters, and most clusters are at a minimum RAID attached, or more often than not SAN attached. The arguement of saving a spindle falls apart since the presentation of a logical physical disk (yes those 3 words make sense together) by the RAID controller/SAN HBA has no relation to the underlying physical disk.

    e.g. Take an HP shelf with 5 disks, build one RAID 5 array, present a minimal logical physical disk for quroum, present a minimal logical physical disk for MSDTC, present a maximal logical physical disk for actual storage. Similar rules apply for performance tweaking with multiple arrays of various RAID levels depending on ones needs.

    Only on low end gear does one ever have to worry about physical disks having any relation to the logical physical disk presented by the controller to the operating system. All server class equipment I have encountered allows for the configuration of logical disks of any size within the array.

  2. Evan says:

    Good points, Doug! In most cases, it would be as simple as carving out a little bit of extra logical space from the SAN and making it visible to the OS. Only in rare cases will disks exposed logically to the OS map 1:1 to spindles on the SAN.

    That said, whether they are dedicated spindles or simply "stealing some capacity off the top", it still requires extra resources taken from the SAN to provide this service on the cluster. Although the performance characteristics of this logical disk should be insignificant, they may not be and you’d have to take this into consideration when designing the cluster storage.

    Also consider that if you segment it all off to its own group, you’ll also have to provide an additional IP and network name.

    Overall, none of this is insurmountable. But it’s extra work and resource consumption that is typically unnecessary.

    Thanks for your comment!

    Evan

  3. Anonymous says:

    The Exchange 2003 Deployment Guide has just been updated (at this link) to reflect the best practice…

  4. Anonymous says:

    Still catching up on my queue of blog posts, I think that all of the documentation around MSDTC and Exchange…

  5. Anonymous says:

    Still catching up on my queue of blog posts, I think that all of the documentation around MSDTC and Exchange…

  6. Anonymous says:

    The Exchange 2003 Deployment Guide has just been updated (at this link) to reflect the best practice…

Comments are closed.