MSDTC and Server Clustering – Revisited – Original Posted Mar 24, 2005

Greg Page of the Microsoft Cluster Group and I had a mini-discussion today on the microsoft.public.windows.server.clustering newsgroup, as well as followed it up with a phone conversation, regarding the implementation of the MSDTC resource.


In the past, Microsoft has clearly stated that the MSDTC resource and its dependent resources should be in their own cluster group separate from the default cluster group that contains the quorum. The reason behind that is that in the past, read: NT 4.0 clustering days, the MSDTC could consume enough disk time that the quorum would not be able to read/write to its disk, and it would result in a failure.


Recently, the Exchange team has stated that the MSDTC resource is OK if it is in the default cluster group along with the quorum. The Exchange team’s reasoning is that the MSDTC is only used when upgrading and patching Exchange and during the install of Exchange in a cluster. To put it in its own cluster group with its own resources is a waste for Exchange clusters unless work flow applications are run on the cluster.


Well, obviously disk technology has progressed considerably since NT 4.0 days. So based on increased performance and the general lack of use of MSDTC on most clusters where it is installed, the Microsoft Cluster Team has decided to change their view of the MSDTC resource being in the cluster group with the quorum. Basically, their view is morphing to a “we really don’t care if MSDTC is in the cluster group.” Of course this view also allows for adminsitrators to create a separate cluster group for the MSDTC resouce and its dependent resources that is separate from the cluster group holding the quorum and its resources based on performance needs.


I, personally, believe the MSDTC should be in its own cluster group in some cases, all of which are performance related. MSDTC may be heavily utilized, in which case it makes sense to give it its own spindle. While in many cases it is unlikely to impact the quorum enough to cause harm if it were in the default cluster group with the quorum, I am more concerned about those few cases where it might cause harm by there being many requests in the queue and the quorum would be unable to read/write and then cause failures. Failures of the default cluster group would result in the MSDTC resource offline for a few moments during the failover process.

Exchange work flow can cause a heavy load and SQL two phase commit transactions can also cause a heavy load. However, those are just a couple of examples where there may be problems.

I am a big advocate of HA being done right in that if there is a possibility of something happening that can have a negative impact, and it is easy to avoid the problem, then you should do it. So, I would rather avoid any potential problems by giving the MSDTC is own resources if it is heavily used.

So to sum it up:
View 1
– New disk technologies have improved performance to the degree that the MSDTC can share resources without negatively impacting the cluster group.
View 2 – The cost to avoid this risk is low enough that if the MSDTC is heavily used it is best to avoid the problem completely by giving the MSDTC its own resourcse.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>