Win 2003 High Availability Solutions, Transactions

In the quest for increased reliability and integrity, transactions, a sequence of related tasks that constitute a unit of work and pass the ACID test, make a fine complement to server clustering.

One of the prevailing IT trends is the quest for increased reliability and integrity of computer systems. In our series dedicated to Windows Server 2003 High Availability Solutions, we have been concentrating so far on clustering, which is commonly used to near the ultimate goal of perfect resiliency. There are, however, other ways to approach this challenge, some of which can be combined with server clustering to realize more benefits.

One of them, which leverages the concept and characteristics of transactions, is the focus of this article.

The term transaction (in the context that is of interest to us) is defined as a sequence of related tasks that constitute a unit of work satisfying rules described collectively using the acronym ACID, derived from the following four properties, which in combination yields additional advantages of concurrency control and overall system integrity:

• Atomicity guarantees all transactional activities operate as a single unit. This implies there are only two possible outcomes of a transaction — either all the tasks finish or none of them do.
• Consistency determines that once a transaction completes, it will leave the underlying system in a state that complies with its integrity principles.
• Isolation dictates that any simultaneously executing transactions must operate independently, with their respective intermediate results having no impact on one another.
• Durability ensures that once the transaction ends, its outcome changes state of the underlying system in a persistent manner, which will be preserved even in the event of an intermittent outage.

Variety of resources are transactional in nature, due to requirements that have driven their design and implementation. This routinely applies to multiuser database or file management software (such as Microsoft SQL Server or NTFS) as well as messaging queues, where the ability to accommodate independent, potentially simultaneous operations, with the assurance of predictable results is critical. However, transactional support in such cases is typically limited by the boundaries of the resource itself and does not extend to external systems (even if they have their own, transactional capabilities), which participation might be required to complete some internally initiated actions.

If you want to expand this scope in a distributed environment to encompass activities that take place across multiple, distinct entities, you will have to resort to help of a specialized software component that functions as a transaction manager. The transaction manager coordinates the flow of each transaction, from initiation to completion, by handling communication and arbitration between all independent programs (referred to as resource managers) involved in its processing. Windows-based implementation of such component is known as Microsoft Distributed Transaction Coordinator (MSDTC). Its primary responsibility is to enforce ACID rules in scenarios involving multiple, autonomous programs, which can reside on the same or different physical systems. This is accomplished by employing a two-phase commit mechanism, thus guaranteeing a transaction is not considered as completed until its successful execution is confirmed by everyone involved in its processing. If any of the participants reports a failure, the transaction is rolled back on all of them.

In case of Windows Server 2003 based highly available installations, any transaction-based clustered software (e.g., Microsoft SQL Server, Exchange Server, or BizTalk Server) should be able to operate across all nodes, which implies the need for MSDTC. To provide sufficient reliability, this component is implemented as a clustered resource. To further improve its resiliency, you might want to consider hosting it in its own group, with dedicated Physical Disk, IP Address, and Network Name resources, on which MSDTC is dependent. Creation of the resource will generate a DTC log file (MSDTC.LOG, which is used to keep track of pending or recently completed transactions and is stored in the MSDtc folder in the root of the Physical Disk resource) and DTC-related registry entries, which reside in the Cluster registry hive.

In addition, the DTC service (assigned, by default, the manual startup type) is initiated on the active node in the security context of NT AUTHORITYNetworkService account. Interestingly, this configuration is enforced, regardless of prior settings. A single clustered DTC service is capable of providing transactional support to all processes running on any of the nodes. Note that it is not possible to create more than a single MSDTC resource per cluster.

Detailed instructions describing the process of creating MSDTC in a clustered environment using Cluster Administrator graphical interface and cluster.exe command-line utility are outlined in the Microsoft KB article 301600 How to configure Microsoft Distributed Transaction Coordinator on a Windows Server 2003 cluster. Once you stepped through them, you can proceed with configuration of MSDTC-specific properties.

MSDTC configuration details are controlled the same way as its non-clustered implementation via Component Services MMC snap-in, which is accessible from the Administrative Tools menu on any of cluster members. Once the console has been launched and is in active node, expand the Computers subnode of the Component Services node, right-click on the My Computer icon underneath, and select Properties from its context-sensitive menu. In the resulting dialog box, switch to the MSDTC tab. From there, you will be able to manage the log location and size (as well as determine its current owner), select client network protocol (the default of TCP/IP is the only choice suitable for clustered setup), stop and start the DTC service and verify its status, adjust tracing level, and control Security Configuration. Options available via the Security Configuration dialog box, which dictate rules governing network communication with remote systems participating in transactions, have been enhanced with introduction of Windows Server 2003 Service Pack 1, allowing following settings to be configured:

• Network DTC Access determines whether the MSDTC component is able to interact with other computers. In general, you should enable this setting for clustered installations; it is disabled by default, as part of the security-related changes in Windows Server 2003 Service Pack 1. This is the prerequisite that makes other Security Configuration settings (listed below) accessible and relevant.
• Allow Inbound permits accepting inbound requests that are part of a distributed transaction initiated from a remote system.
• Allow Outbound permits initiating a distributed transaction from a cluster node to a resource on a remote system.
• Mutual Authentication Required is designed to provide the highest level of security by enforcing encryption and authentication on the local and remote computers participating in the transaction. However, since the authentication mechanism relies on impersonation of a computer account, and, in case of MSDTC clustered resource, the local computer name gets substituted with the Network Name resource (on which MSDTC depends), this option is not suitable for clustered installations. However, it remains a preferred choice in stand-alone scenarios.
• Incoming Caller Authentication Required forces message encryption and remote system authentication when communicating with another instance of Microsoft Distributed Transaction Coordinator. This should be your selection for Windows Server 2003 R2-based clustered instances of MSDTC, as long as the remote system is running Windows Server 2003 SP1 or Windows XP SP2 or newer.
• No Authentication Requried allows you to engage in a distributed transaction with computers running an operating system earlier than Windows Server 2003 Service Pack 1 (including Windows 2000 and Windows XP SP1) or which are not part of the same or trusted Active Directory domain. Since this is accomplished by eliminating authentication and encryption requirements, you should resort to its use only if the two previously described options are not viable.
• Enable Transaction Internet Protocol (TIP) Transactions is used in situations that involve Business Activity Monitor (BAM) Portal, included in BizTalk Server 2006. This particular setting must be enabled in case you are using BizTalk administrative console to manage Windows SharePoint Services-hosted Business Activity Services (BAS) site, both on the system running the console and the one where the BAS site resides.
• Enable XA Transactions is necessary for support of distributed transactions in heterogeneous environments and commonly used when communicating with IBM WebSphere MQ via MQSeries adapter. For more information on this subject, refer to MSDN article Managing XA Transactions.

Each of these settings has a corresponding registry value, which you can determine based on the information provided in the Distributed Transaction Coordinator Microsoft TechNet article. Since these registry values are included in the cluster registry hive, any changes made via the Component Services interface will automatically propagate to other members of the same cluster.

The decision to enable Network DTC Access is dependent on whether the functionality is needed by resources hosted by the cluster. For example, according to Exchange Server 2003 and 2007 security best practices, it is recommended the setting be disabled, in this case because the dependency exists mainly due to setup/upgrade processes and workflow applications that employ built-in Exchange COM+ components, which in turn rely on MSDTC being operational.

On the other hand, while SQL Server 2005 clustered installation remain operational without ability to take advantage network-based distributed transactions , some of its features, such as replication, distributed queries, or remote stored procedures will be negatively affected. Note however that clustered MSDTC resource are required for its setup to complete successfully, if you include SSIS, Notification Services, or Workstation Components.

BizTalk Server 2006 is on the far end of the spectrum as far as DTC dependencies are concerned. Most of its runtime operations (such as single Sign-On service or communication between BizTalk host instances and SQL Server instances) use distributed transactions, so the impact of disabling Network DTC Access could be significant.

Also bear in mind that if you enable Windows Firewall on public network interfaces of cluster nodes, you must include %system32%Msdtc.exe program in the list of exceptions (on the Exceptions tab of the Windows Firewall dialog box). Furthermore, if you intend to engage in distributed transactions remote systems located behind a firewall, take into account the information provided in the Microsoft Knowledge Base article 306843 How to troubleshoot MS DTC firewall issues. Some of these points apply to older versions of Windows.

The next article in this series will review Message Queuing, another example of a software component that can be clustered to increase resiliency of distributed applications.