Export (0) Print
Expand All
1 out of 1 rated this helpful - Rate this topic

High-Availability Solutions Using Microsoft Windows 2000 Cluster Service

 

Microsoft Corporation

March 2002

Applies to:
     Microsoft® BizTalk® Server 2002
     Microsoft Windows® 2000 Cluster Service

Summary: Learn how to design and deploy a highly available implementation of Microsoft BizTalk Server 2002 using the Cluster service component of Microsoft Windows 2000. (45 printed pages)

  • Part 1 contains general information about the importance of clustering and the software, hardware, and cost considerations for its deployment.
  • Part 2 contains detailed steps for setting up the cluster.

Contents

Part 1
Introduction: Guaranteed Data Delivery and Uptime
How the Cluster Service Works
Using the Cluster Service with BizTalk Server
How a Failover Works
Deciding on the Right Cluster Configuration
Higher Levels of Protection Using Multiple Clusters with Server Groups

Part 2
Introduction
Cluster Resources and BizTalk Server
Planning a BizTalk Server Cluster Configuration
BizTalk Server Cluster Setup Requirements
Cluster Setup
Upgrading to Biztalk Server 2002
Troubleshooting
References

Part 1

Introduction: Guaranteed Data Delivery and Uptime

Many companies use Microsoft® BizTalk® Server to process the core data that their business depends on. These businesses have no room for error, and a prolonged downtime due to a simple hardware outage could mean losing a large amount of money. BizTalk Server provides guaranteed data delivery by using a robust transactional support that incorporates the ACID attributes: atomicity, consistency, isolation, and durability. In addition, the Microsoft Windows® 2000 Cluster service should be used to safeguard against hardware failure of any server that is used to persist data to a local disk. Both Windows 2000 Advanced Server and Windows 2000 Datacenter Server include this component. BizTalk Server supports active/passive clustering using Microsoft Windows 2000 Cluster service, providing high availability in Orchestration scenarios.

The Cluster service allows the combination of two or more servers to work together as a server cluster to ensure that mission-critical applications and resources remain available to clients. Server clusters enable users and administrators to access certain resources of the servers, or nodes, as a single system rather than as separate computers.

The design of a highly available solution is focused on minimizing the points of failure within the available budget. In conjunction with a robust storage system (Redundant Array of Independent Disks, or RAID), the Cluster service allows for a cost-effective way to provide reliability for servers that persist data locally by using the concept of redundant server failover.

An important distinction must be made between redundant servers, which do not persist any data on their local hard disks, and servers that do persist data. BizTalk Server already provides an impressive degree of redundancy and scalability by allowing all the servers within a group to access a single BizTalk Server database server over the network. Should any one of the servers in the group fail, the others would simply take over and continue to access the database server. This is possible because none of the servers in the group persist working data to their local disks. However, if the remote database server becomes unavailable for any reason then all servers in the group will be rendered inactive. The Cluster service removes this single point of failure by ensuring that the central database server is available to service database access requests even if there is a complete server failure.

The decision to use the Cluster service depends on two factors:

  • The downtime that the business can tolerate when a server that persists important data to a local disk becomes unavailable.
  • The budget available for the additional hardware and software to provide satisfactory redundancy.

At a minimum, two servers are required for simple redundancy.

How the Cluster Service Works

Figure 1 depicts a two-node cluster and illustrates a basic implementation of clustering, known as a "share-nothing" architecture. A fundamental concept to note here is that both servers are connected to the same physical disk subsystem. However, only one of the servers will "own" and control the disk storage at any given time. The portion of the disk subsystem that is shared between the two servers (nodes) is referred to as shared storage.

Ee265629.bts_2002clustering_01(en-US,BTS.10).gif

Figure 1. Shared-nothing cluster, Server A active

Server A is currently active, which means that it has complete control over the shared storage. Server B is up and running but is in a passive state ready to take ownership of the shared storage if the other node fails. An instance of Microsoft SQL Server™ is running on the active node and, as a rule, always runs on the cluster node that owns the shared storage. In this case, the disks contain all the physical files necessary to support the SQL Server databases that are needed for BizTalk Server to operate normally. This implementation is known as an active/passive SQL Server cluster.

The instance of SQL Server and the shared storage containing the databases are referred to as "virtual" resources because they are not permanently tied to any particular server. This means that another computer can access the SQL Server databases without having to know which of the two servers is active. The Cluster service handles all the processes necessary to make this completely transparent. To connect to the database server, users and applications refer to a "virtual server" name, which is unique and distinct from the server names of the two nodes in the cluster.

If there is a hardware failure on Server A, all the virtual resources (that is, the SQL Server instance and disk storage) automatically fail over as a group to Server B and continue running. This occurs with no loss of data. Figure 2 shows the new configuration, known as active/passive. To make optimal use of both servers during normal operation, a more cost-effective approach is to run different virtual resources on each server. In this type of configuration, each server acts as the failover node for the other.

Ee265629.bts_2002clustering_02(en-US,BTS.10).gif

Figure 2. Active-passive cluster, Server B active

The Cluster service is supported by most of the leading hardware suppliers that are certified by Microsoft as hardware-compatible with the Windows 2000 Advanced Server operating system. Many businesses are now clustering very powerful enterprise-class servers having up to 8 processors using Windows 2000 Advanced Server or up to 32 processors using Windows 2000 Datacenter Server.

Using the Cluster Service with BizTalk Server

The primary purpose of using the Cluster service is to guarantee uptime for a server that is used to persist data on its disk subsystem. To completely protect BizTalk Server against hardware failures, clustering should be implemented on the following four areas:

  • SQL Server databases. BizTalk Server needs four databases to function properly: Message Management, Shared Queue, Tracking, and Orchestration. At a minimum, these databases should be protected against server failure by using the Cluster service.
  • Message queues. BizTalk Server can receive or send data using Message Queuing (also known as MSMQ), a feature of the Windows 2000 Server operating system. Queues are often used for application-to-application integration where high throughput is important and where transacted reads and writes are essential. Message Queuing can be clustered as a virtual resource in much the same way as SQL Server.
  • File shares. BizTalk Server can receive or send standard text file formats (comma-separated values or fixed width). If the server used to store these files experiences a failure, BizTalk Server cannot process the data. When a significant downtime threatens a business operation, the file share can be protected by using clustering.
  • Web Distributed Authoring and Versioning (WebDAV) repository (optional). To guard against a failure of the local drive of a node containing the BizTalk Server repository information, the files can be placed on a shared cluster disk resource. In addition, this configuration allows easy access to the repository files from any of the cluster nodes.

The importance of protecting these data stores is evident when looking at the flow of data in a typical BizTalk Server implementation. Figure 3 shows the areas of exposure.

Ee265629.bts_2002clustering_03(en-US,BTS.10).gif

Figure 3. Candidates for failure protection with clustering

Guaranteeing the Flow of Data into BizTalk Server by Protecting the Receive Functions

Each inbound data source is passed into BizTalk Server by using a receive function. BizTalk Server reads all data in the context of a transaction, ensuring that no data can ever be lost. There are many ways to pass data into BizTalk Server, but two in particular—flat files and Message Queuing queues—are persisted into a data store prior to being passed in. When BizTalk Server is fully clustered, the data is simply read from a virtual Message Queuing instance or from a virtual file share.

Note   If you do not intend to use either flat files or Message Queuing queues, it is unnecessary to cluster these resources.

Protecting the Data While BizTalk Server Is Processing It

After BizTalk Server has successfully received the data, it immediately persists the data into a SQL Server database. This is done as part of an all-or-nothing transaction, again guaranteeing that no data is lost. If a clustered instance of SQL Server is used as previously described, the failure of a database server will not impact the ability of BizTalk Server to continue processing.

To carry out the normal processing of XML documents, BizTalk Server uses WebDAV to read and write the XML repository data to disk. This important data repository contains a directory of files that are XML document specifications, map specifications, and flat file conversion specifications known as envelopes. WebDAV is a feature that is provided as part of Internet Information Services (IIS).

Although some caching is employed when reading the repository data, BizTalk Server eventually needs to obtain a fresh copy directly from disk. Clustering can be used to ensure that processing is never impacted even when IIS and the disk storage that it relies on become unavailable.

Protecting Outbound Data Coming from BizTalk Server

After BizTalk Server has completely processed the XML data, it uses an outbound port to send the data to its destination. There are many options for sending data from BizTalk Server, but only the flat files and Message Queuing queues depend heavily on the availability of a persisted data store. As with all other data-handling operations in BizTalk Server, the process of writing the data is done in the context of an all-or-nothing transaction ensuring that no data can be lost.

By default, BizTalk Server employs a retry mechanism when the destination server is unavailable. However, if the throughput requirements are stringent and downtime is a serious problem, adopting clustering is a prudent decision. The most obvious outbound BizTalk Server ports that would benefit from clustering are Message Queuing queues and flat files.

Protecting BizTalk Orchestration

When more complex business rules are required, BizTalk Orchestration is a powerful feature that can be used for long-running or complex transactions.

When BizTalk Orchestration is used and the throughput requirements need constant uptime, clustering should be implemented to protect BizTalk Server repository data files, the Orchestration database, and Message Queuing queues. Figure 4 shows the role of BizTalk Orchestration in the cluster and its interaction with the other components.

Ee265629.bts_2002clustering_04(en-US,BTS.10).gif

Figure 4. BizTalk Orchestration's role in the cluster

How a Failover Works

There are two types of failovers—planned (manual) failovers and those that occur as a result of a server hardware or software problem.

Planned Failover

When a server requires maintenance or upgrades, a manual failover can be performed. Manual failover involves instructing the Cluster service to move all resources from one node to another. In the two-node example described earlier, this would mean moving the shared storage and the SQL Server instance. Failover occurs quickly, so after the upgrade or maintenance task is complete on one server, the cluster resources can be restored to that server and the task can be performed on the second server. Without the Cluster service, a server would be unavailable for significant periods of time while the maintenance work was carried out.

Automatic Failover Due to a Server Hardware Problem

The Cluster service always runs on both cluster nodes and constantly monitors each server to ensure that all resources are behaving normally. In the event that a serious hardware or unexpected error occurs, all resources will be moved to the remaining node without human intervention.

In a well-organized server configuration, this failover will be detected immediately by monitoring tools such as those provided by Microsoft Operations Manager 2000. These tools can then notify the appropriate operational staff that the server is down and needs attention. If necessary, the monitoring tools can be configured to run additional scripts automatically.

Making the Failover Completely Transparent

The ACID attributes are considered the key factors that ensure data will never be lost. If BizTalk Server is in the middle of sending data, it is within the context of a transaction. When a hardware failure occurs, the transaction is rolled back. After the cluster resources have successfully been moved to the other node, BizTalk Server automatically retries the transaction. If the applications that pass data to BizTalk Server are written to comply with standard ACID transaction rules and have an automatic retry mechanism, there should be no noticeable impact during failover.

The technology provided by Message Queuing is a great benefit when considering the initial design of a highly available BizTalk Server implementation. Message Queuing enables a loosely coupled messaging model and guarantees delivery of XML messages even if the destination server is temporarily unavailable.

As an example of how a failover can be made completely transparent by using Message Queuing, Figure 5 shows a source application that is sending multiple XML messages over the network to a virtual Message Queuing queue. The virtual queue is running as a clustered instance and is currently active on Server A. The source server has installed Message Queuing as an independent client, meaning that there is a local instance of Message Queuing running on the same server.

Ee265629.bts_2002clustering_05(en-US,BTS.10).gif

Figure 5. Source application sending XML messages to Message Queuing queue

When Server A crashes and a failover occurs, the virtual instance of Message Queuing is temporarily unavailable while the shared storage is moved from Server A to Server B. During this time the source application can continue to send XML messages to the message queue without interruption. This is possible because Message Queuing intercepts the messages and automatically collects them into a local outbound queue. The application does not need to know anything about the failover.

Ee265629.bts_2002clustering_06(en-US,BTS.10).gif

Figure 6. Messages are cached locally in the outbound queue during the failover

After failover has successfully completed and the virtual Message Queuing instance is back online, the Message Queuing service on the source server sends all the messages that were collected during the interruption to the destination server. Everything continues as normal and all messages are processed.

Ee265629.bts_2002clustering_07(en-US,BTS.10).gif

Figure 7. After failover, cached messages are sent to the destination server

Deciding on the Right Cluster Configuration

The final decision about which servers in a BizTalk Server configuration will need to be clustered depends on the business tolerance for downtime and the server budget available. If the volume is quite low, it is possible to design a complete BizTalk Server clustered implementation of all exposed areas using just two relatively high-powered servers (a two-node cluster).

Many businesses have extremely high volumes of documents processed by BizTalk Server and will choose to use the scale-out features of BizTalk Server to distribute the load. The following paragraphs describe options for both scenarios.

Warning   BizTalk Server supports active/passive cluster configurations, which means that there cannot be two active instances of BizTalk Messaging Service or two active instances of BizTalk Orchestration in a cluster. A cluster in which a BizTalk Messaging Service instance and a BizTalk Orchestration instance are running on two different cluster nodes still constitutes an active/passive configuration. Active/active configurations of SQL Server, Message Queuing, and Internet Information Services (IIS) are supported.

BizTalk Server Two-Node Cluster Configuration

A complete failover solution for BizTalk Server can be configured using a two-server cluster configuration. This provides protection against server failure for all the areas of exposure previously described.

Important   This solution is not likely to be appropriate for scenarios where BizTalk Server handles a high volume of documents. It is important to understand the data volume and peak throughput requirements before deciding on the design of the cluster.

When deciding the size of any server in a cluster, it is assumed that all virtual resources will at some point have to run on one node. Examples of server sizes are provided later as a guideline (in Sizing Guidelines), but only a controlled stress test will give an accurate assessment of the server requirements for your particular implementation.

For the BizTalk Server implementation presented here, we will assume that storage is used for the following elements:

  • File share for file transfer in and out of BizTalk Server
  • Message Queuing queues
  • SQL Server
  • WebDAV repository

Figure 8 shows a cluster configuration that makes full use of both nodes and also provides failover protection for all the areas of exposure, resulting in the two servers behaving as active/passive failover for each other.

Ee265629.bts_2002clustering_08(en-US,BTS.10).gif

Figure 8. Two servers act as active/passive failover for each other

In this configuration, SQL Server runs on Server A under normal circumstances and fails over to Server B if a failure occurs, while BizTalk Server runs on Server B under normal circumstances and fails over to Server A if a failure occurs.

The choice to separate the instances of SQL Server and BizTalk Server depicted above is a logical first choice for most installations. However, this does not mean that this configuration must remain locked down. Whenever it is necessary to optimize performance, a manual failover can be used to move the various cluster resources to either server. For example, if BizTalk Orchestration performance is a concern, better performance might be achieved by moving the group that has the virtual BizTalk Orchestration instance to run on the same node as the virtual SQL Server instance.

Combining BizTalk Server Groups and the Cluster Service

A strong configuration is available when both scalability and high availability are important. Figure 9 shows this configuration, which takes full advantage of the features of both the BizTalk Server groups and the Cluster service.

Ee265629.bts_2002clustering_09(en-US,BTS.10).gif

Figure 9. Strong configuration of BizTalk Server groups and the Cluster service

In this configuration the main concern is to have high availability for the BizTalk Server databases. For this reason, only the SQL Server instance is clustered and each BizTalk Server instance in the group accesses this virtual instance. For more information on clustering SQL Server, see the SQL Server 2000 Failover Clustering white paper.

The basic assumption is that the failure of one of the BizTalk Servers in the group is not a serious impediment because:

  • If a BizTalk Server within the group fails, there are three other BizTalk Server instances running that continue to process data.
  • None of the BizTalk Servers is relying on a local disk to receive or send data. Alternative data interchange methods are used, such as HTTP or Application Integration Components (AIC).

    - Or -

    Data is persisted locally on each BizTalk Server but downtime is not considered important enough to justify the additional costs associated with deploying extra clusters.

Higher Levels of Protection Using Multiple Clusters with Server Groups

Some customers require complete protection against the failure of any server in their configuration. At the same time, they need the scale-out features of BizTalk Server groups to achieve load balancing. Typically in these cases, the timely delivery of data is absolutely critical to the business, so the additional hardware costs are of less concern.

Figure 10 shows how a customer can deploy a highly available and scalable implementation of BizTalk Server using three clusters.

Ee265629.bts_2002clustering_10(en-US,BTS.10).gif

Figure 10. Three clusters for a highly available and scalable implementation

Cluster 1 is an active/active configuration with two SQL Server instances. The most heavily used databases are the BizTalk Server Tracking and the Queue databases, so they are distributed between the two nodes for optimal load balancing. This achieves optimum performance for the databases while making good use of both servers in the cluster. For more information on SQL Server clustering, see the SQL Server 2000 Failover Clustering white paper.

Cluster 2 is an active/passive implementation of BizTalk Messaging Service. This BizTalk service is the most heavily used and handles all the receive functions as well as the processing. In this configuration the passive node is inactive to allow room for future growth.

Cluster 3 is an active/passive implementation of BizTalk Messaging Service owned by node A. This BizTalk service is optimized to concentrate on processing items that are placed into the database work queue by the BizTalk Server on cluster 2. For optimal performance, BizTalk Orchestration is separated to run alone on node B of cluster 3 as an active/passive configuration, because it is heavily used and involves calls to numerous custom components. It warrants separation for both performance and safety reasons.

Note that Message Queuing is needed on cluster 2 to support BizTalk Messaging on node A. It is also needed on cluster 3 to support BizTalk Messaging on node A and BizTalk Orchestration on node B.

Another highly available implementation of BizTalk Server consists of using a four-node cluster configuration, where BizTalk Messaging is active in one node and can fail over to any of the other three nodes, BizTalk Orchestration is active in a second node and can fail over to any of the other three nodes, and SQL Server is clustered in the remaining two nodes.

Part 2

Introduction

Part 1 covered different options for how the Cluster service component of Microsoft® Windows® 2000 can be used to provide high availability for Microsoft BizTalk® Server. We also introduced the basic terms and concepts of clustering. This section describes in detail how to implement BizTalk Server in the configurations described previously, and covers the following areas:

  • Hardware and software requirements
  • Setting up the BizTalk Server resources and resource groups
  • Upgrading from BizTalk Server 2000 SP1A to BizTalk Server 2002
  • Troubleshooting

Throughout the remainder of this article it is assumed that the cluster has already been set up and the Cluster service has been installed and tested. For further information, the Microsoft Knowledge Base articles Q259267, Microsoft Cluster Service Installation Resources and Q243218, INF: Installation Order for SQL Server 2000 Enterprise Edition on Microsoft Cluster Server, and the Windows Clustering Technologies Web site.

Cluster Resources and BizTalk Server

In a Cluster service implementation, a "virtual server" is created by grouping together the core cluster resources as follows:

  • Network IP address. A unique IP address identifies this virtual server on the network.
  • Network name. Clients can access this virtual server by a unique network name.
  • Physical disk. This is the disk storage that will be seen as local to the virtual server.

After these resources have been set up they can fail over together as a group. These resources must come online in the order listed above. This group forms the basis of any virtual server, and there can be many of these groups running on a single cluster.

In a BizTalk Server implementation we add the following additional resources to a virtual server group in the order presented:

  • Microsoft Distributed Transaction Coordinator (MS DTC). BizTalk Messaging requires MS DTC as part of the group to ensure that data delivery is guaranteed. It must belong to the same group in which BizTalk Messaging will run.
  • Message Queuing. BizTalk Server will perform "transacted" reads of the Message Queuing queues. To do this the queue must be seen as local to the server on which BizTalk Server is running. In this case, BizTalk Server is running on the virtual server and this virtual Message Queuing instance is considered local to the virtual server.
  • IIS WebDAV repository (optional). By default the IIS WebDAV repository is stored on the local drive of the first node in the cluster where BizTalk Messaging is installed. To safeguard against a failure of that node, the IIS instance can be made virtual and the files placed on a shared disk. Refer to the Microsoft KB article Q248025, How to Configure Clustered IIS Virtual Servers on Windows 2000 Advanced Server for further information.
  • BizTalk Messaging. After all of the preceding resources are brought online in the order listed, BizTalk Messaging has everything it needs to be brought online and start running.
  • XLANG Scheduler Engine (optional). This resource can run in the same group as BizTalk Messaging or in a separate virtual server group running on the other node.
  • XLANG Schedule Restart Service (optional). This resource must run in the same group as the XLANG Scheduler Engine. It ensures that the orchestration schedules are started and stopped in a controlled manner on the cluster.

Planning a BizTalk Server Cluster Configuration

It is important to understand the performance characteristics of your unique environment before planning a cluster implementation. A good understanding of where the most likely bottlenecks could occur will feed into the overall architecture and help you decide on the optimal configuration. Based on the unique performance characteristics and requirements of the desired solution, choose to deploy different components of the solution on separate machines, and then decide upon the optimal configuration for clustering those resources. For a detailed list for planning your cluster requirements, refer to Microsoft Windows 2000 Server Deployment Planning Guide, and the Microsoft KB article Q259267, Microsoft Cluster Service Installation Resources.

Important Decision Factors

Before deciding on a cluster configuration, you should consider the following information about the cluster elements.

BizTalk Messaging

An instance of BizTalk Server can be configured to perform receiving functions, processing/sending functions, or both. Here we will focus primarily on receiving Message Queuing messages. You can easily scale out for additional processing after the original setup by simply adding stand-alone servers to help carry the load. If you are planning to use Message Queuing heavily during receiving functions then it may be appropriate to dedicate at least one cluster node to performing mainly this type of receiving activity.

BizTalk Server and Message Queuing are well tuned for fast performance in reading and storing Message Queuing messages. Taking the time to perform a small simulation test will help provide an estimate of the server load for this activity

SQL Server

In situations where database load is not critical, Microsoft SQL Server can be installed to run on the same cluster node as BizTalk Server for optimal performance. The server will need to be sized appropriately, and a minimum of two processors is a frequent choice for each cluster in this case.

However, the following situations will make it necessary to install SQL Server on its own dedicated cluster node:

  • Many processing servers will access the BizTalk Server databases, increasing the load significantly on the SQL Server instance.
  • There will be heavy use of the BizTalk Server tracking features.
  • The results of a simulation test of Message Queuing and BizTalk Messaging indicate that it makes sense to dedicate a server to perform only BizTalk Messaging and move the database activity onto a separate server.
  • A lot of room is required for future growth.

BizTalk Orchestration

Light use of the BizTalk Orchestration features might make it possible to run the XLANG Scheduling Engine in the same group as BizTalk Messaging. Because BizTalk Orchestration makes heavy use of Message Queuing, this will keep the cluster configuration simpler by limiting the number of groups and disk resources in the overall configuration.

However, heavy use of BizTalk Orchestration can result in high CPU use and increased memory consumption as multiple schedules run concurrently. In these cases, it is important to use a pooling mechanism to prevent the number of concurrently running schedules from overcoming the server abilities. It might also make sense to run the XLANG Scheduler Engine on a separate computer. One option would be to have it on the passive node for Biztalk Messaging—that is, BizTalk Messaging might normally run on node A and BizTalk Orchestration might normally run on node B.

Separating the two fundamental components of BizTalk Server in this manner will also make it easier to tune each node for optimal performance later.

To ensure that BizTalk Orchestration offers fault tolerance, it is necessary to make sure that the data stored in memory is persisted. This can be accomplished by using transaction control. For more information about BizTalk Orchestration transaction control, refer to Orchestration Part 2: Transactions, Exceptions, Debugging.

Important   Note that at some point all resource groups might need to run on the same cluster node for a period of time. Therefore, each node should have enough memory and adequate CPU resources to handle such occurrences.

Hardware Considerations

One of the main considerations when planning a cluster configuration is hardware cost. A number of offerings are available from the leading hardware vendors ranging from basic shared Small Computer System Interface (SCSI) disk arrays to a complete storage area network (SAN) solution.

For SCSI disk arrays, a disk resource in a group typically equates to a separate array of physical disk drives. Each array will be configured as RAID 5 (striping with parity) or sometimes as RAID 10 (both striping and mirroring). More expensive solutions like SAN offer a much more flexible approach involving fiber channel switching. Whatever your choice of hardware, make sure it is included in the Microsoft Windows Hardware Compatibility List.

From a simplicity standpoint, the easiest cluster configuration is an active/passive configuration with all the necessary BizTalk Server resources belonging to a single group.

Figure 11 shows such a configuration. It is recommended that a separate disk be available to be used for the quorum disk. In this type of configuration the disk subsystem will have two separate disk arrays.

Note   Throughout this paper there will be references to a quorum disk, which is a shared disk that the Cluster service uses to store crucial information about the cluster configuration and state of the cluster resources. For this reason it is recommended that a separate group be used with a disk resource of approximately 500 megabytes (MB) (minimum 100 MB).

Ee265629.bts_2002clustering_11(en-US,BTS.10).gif

Figure 11. A simple active/passive configuration

When performance is crucial, an additional group might be required so that SQL Server and/or BizTalk Orchestration can run on the other cluster node, as shown in the following illustration. In this case three disk arrays are necessary. This configuration results in both nodes acting as active/passive standby for each other.

Ee265629.bts_2002clustering_12(en-US,BTS.10).gif

Figure 12. Both nodes are active and serve as passive standby for each other

BizTalk Server Cluster Setup Requirements

Refer to the Microsoft KB article Q259267, Microsoft Cluster Service Installation Resources for information about ensuring that your hardware is compatible with Windows Cluster service. The following requirements specific to BizTalk Server should also be considered for each computer that will participate in the cluster.

Sizing Guidelines

Each computer needs enough CPU, memory, and disk space to handle the complete set of all cluster resources after a failover to a single node. Only an analysis of the expected throughput and a load simulation test will give an accurate picture of the server requirements. However, as a starting point, here are some general guidelines for server sizing:

  • CPU. Low-volume scenarios might allow for each node to have a single CPU, but this is more likely the exception in a failover cluster situation. Whether all resources are running on a single node or there is a separation of the groups onto both nodes, there will need to be enough capacity to handle the load during peak periods. Failover can drain the CPU processing capacity of the node taking control over the resources of the failed node. Therefore, at least two CPUs are recommended, and this should be verified through a load simulation test using the tools provided with this paper.
  • Memory. Make sure that each node has enough memory to run all the processes in case of a failover. As a general guideline, a starting point for server memory would be 1 gigabyte (GB) if only one of BizTalk Messaging, BizTalk Orchestration, or SQL Server will reside on the cluster node. Use at least 2 GB per node (setting the maximum for SQL Server memory usage to 1 GB) if any two of BizTalk Messaging, BizTalk Orchestration, or SQL Server will reside on the same node, and 3 GB if all three will reside on the same cluster node.
  • Disk storage requirements. Expect up to 2 GB for Message Queuing and reserve at least 50 GB for the BizTalk Server databases. The Tracking database will consume the most space and, depending on the volume and tracking options chosen, can grow quite quickly. If there is no requirement for tracking (unlikely) or if the throughput is very low then the disk space requirements are considerably less.

Software Requirements

The following software products and appropriate licenses are required:

  • Windows 2000 Advanced Server or Windows 2000 Datacenter Server with SP2 or later
  • Microsoft SQL Server 2000 Enterprise Edition with SP1 or later
    Note   Whether on the same cluster as BizTalk Server or on a separate cluster, here it is assumed that SQL Server will be clustered as part of any high-availability solution for BizTalk Server.
  • BizTalk Server 2000 Enterprise Edition with SP1A or later, or BizTalk Server 2002 Enterprise Edition, which includes BizTalk Orchestration (optional)
  • Microsoft Visio® 2000 Standard Edition SR-1A (optional—only needed for design-time experience on BizTalk Orchestration nodes)

Cluster Setup

The primary focus of this article is the installation and configuration of BizTalk Server after the base cluster hardware has been set up and the Cluster service has been installed and configured. It is assumed that at this point the following steps have been completed:

  • Base cluster hardware has been assembled.
  • The Cluster service has been installed.
  • A separate group exists for the quorum disk, and includes only the network name, IP address, and quorum disk.
    Important   Do not add additional resources to this group.

For more information, refer to the Microsoft KB articles Q243218, INF: Installation Order for SQL Server 2000 Enterprise Edition on Microsoft Cluster Server and Q259267, Microsoft Cluster Service Installation Resources, as well as the Windows Clustering Technologies Web site.

Make sure that all the necessary resources are available before starting, that you have completely read this article, and that the references are readily available.

Important   Before proceeding, test all groups for correct failover.

This article details the steps of the "integrated SQL Server and BizTalk Server cluster" deployment scenario, which is the most straightforward configuration. For other deployment designs, some steps should be omitted when configuring each cluster. The steps that will be covered in the following sections are:

  1. Create cluster groups for BizTalk Messaging, BizTalk Orchestration, and SQL Server
  2. Install MS DTC (ComClust) and configure it to be cluster aware
  3. Install Message Queuing
  4. Add a virtual Message Queuing resource to the BizTalk Messaging Group
  5. Add a Management Console for each virtual Message Queuing instance
  6. Test Message Queuing failover
  7. Install Microsoft Visio 2000 Standard Edition SR-1A (optional)
  8. Install SQL Server 2000 on the cluster
  9. Test SQL Server failover
  10. Install BizTalk Server
  11. Configure BizTalk Server as a cluster resource
  12. Test BizTalk Server failover
  13. Test XLANG Scheduler Engine failover

Create Cluster Groups for BizTalk Messaging, BizTalk Orchestration, and SQL Server

  1. On the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Cluster Administrator.
  2. On the File menu, point to New, and then click Group. The New Group window appears.
  3. In the Name box, type BizTalk Messaging Group, and then click Next.
  4. In the Preferred Owners window, move one node resource to the BizTalk Messaging Group.
    Note    This step is optional. It provides failback protection, but does not have an impact on failover protection.
  5. Click Finish.
  6. On the File menu, point to New, and then click Resource. The New Resource window appears.
  7. In the Name box, type IP address. In the Description box, type IP address for BizTalk Messaging Group. In the Resource type list, select IP address. In the Group list, select the BizTalk Messaging Group just created. Click Next.
  8. On the File menu, point to New, and then click Resource. The New Resource window appears.
  9. In the Name box, type the network name. In the Description box, type Network name for BizTalk Messaging Group. In the Resource type list, select Network Name. In the Group list, select the BizTalk Messaging Group just created. Click Next.

Repeat steps 2 through 8 to create the BizTalk Orchestration Group. Repeat steps 2 through 4 to create the SQL Server Group.

Note   An IP address and resource name are created for SQL Server during its installation, so they do not need to be created at this point.

Ee265629.bts_2002clustering_13(en-US,BTS.10).gif

Figure 13. Cluster Administrator screen

Install MS DTC (ComClust) and Configure It to Be Cluster Aware

The Microsoft Distributed Transaction Coordinator (MS DTC) needs to be cluster aware. It is recommended that this resource be placed into the BizTalk Messaging Group and not into the same group as the quorum disk. Carry out the following procedure on one computer at a time, for each computer on the cluster:

  1. Log on to one node and start Cluster Administrator.
  2. On the File menu, click Move group to. Move to another node any groups with physical disk resources in them, except the BizTalk Messaging Group.

    Make sure there are disk, IP address, and network name resources in the group you want the MS DTC resource to be created in.

  3. Copy the DTCLog folder from the \winnt\system32 folder to the physical disk for the BizTalk Messaging Group.
  4. Create a DTC resource in the group.
    1. Using the Cluster Administrator application, click the BizTalk Messaging Group.
    2. On the File menu, point to New and click Resource. The New Resource window appears.
    3. In the Name box, type MS DTC. In the Resource type list, select Distributed Transaction Coordinator. In the Group list, select BizTalk Messaging Group. Click Next.
    4. Include every computer on the cluster as a possible resource owner. Click Next.
    5. Add resource dependencies for the network name, shared disk, and IP address. Click Finish.
      Note   Leave this resource offline.
  5. Open a Command Prompt window on the first node and run comclust.exe.
  6. Open a Command Prompt window on the second node and run comclust.exe.
  7. Verify that the MS DTC resource is online.
  8. Test failover.

If there are problems configuring MS DTC, refer to Microsoft KB article Q243204, Microsoft Distributed Transaction Coordinator (MSDTC) Recovery Techniques in Windows 2000 Cluster Server.

Install Message Queuing

Carry out the following procedure on one computer at a time, for every computer on the cluster:

  1. Click Start, point to Settings, click Control Panel, and then double-click Add/Remove Programs.
  2. Click Add/Remove Windows Components.

    The Windows Component Wizard appears.

  3. Select the Message Queuing Service check box, and click Next.
Notes   Make sure you configure every computer as a Message Queuing server, not just as a dependent client.
Depending on whether you have Microsoft Active Directory® configured in your environment, choose the appropriate install option for Message Queuing. Without Active Directory, BizTalk Server must always use local queues that result in much faster performance. Using public queues allows greater flexibility and functionality.

Add a Virtual Message Queuing Resource to the BizTalk Messaging Group

Both BizTalk Messaging and BizTalk Orchestration require a local instance of Message Queuing to perform transacted reads. In a cluster resource group, the term "local" refers to the virtual server name (network name). Because BizTalk Server will be running in the context of this virtual server name, a virtual instance of Message Queuing must be installed in the BizTalk Messaging Group in order to appear as local.

Important   If this is the first time that Message Queuing has ever been installed as a cluster resource on this server, then skip this paragraph. If not, use the following procedure to ensure that the registry is completely clean before adding the virtual Message Queuing cluster resources.
If a computer was previously on another cluster with a Message Queuing resource of identical name to the one that will now be configured, there is a known issue. It is possible that the Message Queuing resource might not come online after it is configured due to residual incorrect entries in the registry from previous installations. If this is the case, make sure to delete entries beneath the following registry key for each computer that was previously configured on a different cluster:
HKEY_LOCAL_COMPUTER\SOFTWARE\Microsoft\ Message Queuing\Clustered QMs
  1. Start Cluster Administrator.
  2. Right-click the BizTalk Messaging Group, point to New, and then click Resource.
  3. In the Name box, type Message Queuing. In the Resource type box, select Message Queuing, and then click Next.
  4. In the Possible Owners window, make sure all the nodes are selected as possible owners. Click Next.
  5. In the Dependencies window, add resource dependencies for the network name and shared disk. Click Finish.
  6. Bring the resource online.
  7. Test failover.

After the virtual Message Queuing instance has been configured and brought online, the local Message Queuing instance will be automatically stopped, so there will be only one service running. An examination of the Services icon in Control Panel will show a local instance and the virtual instance of Message Queuing services. The physical files for the virtual Message Queuing instance will automatically be created on the shared disk resource under a folder called MSMQ. The startup settings do not need to be changed for the virtual Message Queuing instance. However, if the local instance of Message Queuing is also required, as is the case when any BizTalk Server component uses the local Message Queuing instance, it is necessary to create a generic application resource for the cluster that will start manually for this local Message Queuing instance, and the XLANG Schedule Restart Service must be dependent on this resource. For more information, refer to the Microsoft KB article Q310775, INFO: Using the MSMQ Service on a Windows 2000-Based Cluster, and Installing Message Queuing on a server cluster in the Windows 2000 Help.

Add a Management Console for Each Virtual Message Queuing Instance

Under normal circumstances, the correct way to manage Message Queuing queues is to open the Computer Manager from the Administrative tools menu. However, to manage a virtual instance of Message Queuing, the procedure for opening the management console is different. In this case, the management console must run in the context of the virtual server rather than that of the local computer. This can be achieved by starting the management console automatically as follows:

  1. Start Cluster Administrator.
  2. Right-click the BizTalk Messaging Group, point to New, and then click Resource.
  3. In the Name box, type Manage Virtual Message Queuing. In the Resource type list, select Generic Application, and then click Next.

    Ee265629.bts_2002clustering_14(en-US,BTS.10).gif

    Figure 14. The New Resource screen

  4. In the Possible Owners window, allow the resource to run on all servers on the cluster. Click Next.
  5. In the Dependencies window, add the following dependencies to the resource:
    • Network name
    • The Message Queuing virtual instance name previously added
  6. Click Next. The Generic Application Parameters screen appears.
  7. In the Command line box, type CMD.exe /C compmgmt.msc.
    Note   This command is run locally on each node. Change the Windows system path and drive letter if they are different on your server.
  8. In the Current directory box, type the letter of the shared disk for the BizTalk Messaging Group (J:\).
  9. Select the Allow application to interact with desktop and Use Network Name for computer name check boxes. Click Next.

    Ee265629.bts_2002clustering_15(en-US,BTS.10).gif

    Figure 15. The Generic Application Parameters screen

  10. In the Registry Replication window, click Finish.
  11. After the resource has been created, double-click the Manage Virtual Message Queuing resource to edit the Properties.

    Click the Advanced tab, clear Affect the group in the Restart section, and then select Do not restart. Click OK to accept the changes.

When this cluster resource is brought online in the cluster, it will automatically open a command window and immediately launch the Computer Management console in the context of the virtual server. Expanding the Message Queuing instance will show the virtual queues. To close the console, bring the resource offline and close the console.

Note   The Computer Management console will start every time failover occurs.

Test Message Queuing Failover

Use the Cluster Administrator application to test failover.

  1. Select the Message Queuing resource and use the Initiate Failure menu option to simulate a failure. According to the number of retry attempts configured for that resource (default is 3), the owner of the cluster resource group should change after the threshold is exceeded. When a failover occurs, all the resources in the group will go offline and move over to the other node. Each resource in the group will come online on the other node in the order the dependencies were specified.
  2. You can easily move the cluster resource group back by right-clicking the virtual Message Queuing instance and clicking Move Group. This will result in a manual failover without any retries.

Install Microsoft Visio 2000 Standard Edition SR-1A (Optional)

Microsoft Visio 2000 Standard Edition SR-1A is required for the design of XLANG schedules for BizTalk Orchestration.

Microsoft Visio 2000 only needs to be installed if XLANG schedules will be created or edited, in which case it should be installed on all nodes in the cluster that can run BizTalk Orchestration.

Install SQL Server 2000 on the Cluster

Depending on the performance requirements there are a few options for installing SQL Server in a high-availability BizTalk Server implementation. Refer to Part 1 for more information.

It is recommended that you install SQL Server into a group other than the BizTalk Messaging Group to allow for manual load balancing of SQL Server and BizTalk Server across the nodes in the cluster. Do not install SQL Server in the Quorum Group.

Integrated BizTalk Server and SQL Server

Use this option if you are confident that BizTalk Server and SQL Server can run on the same server without any performance impact. Typically, only a single instance of SQL Server is required and it can be part of the same group as BizTalk Server.

BizTalk Server on node A, SQL Server on node B

Use this option if there is a need to maximize the use of both nodes for optimal performance and if there is a concern that BizTalk Messaging will require priority on the server it is running on.

BizTalk Messaging, BizTalk Orchestration, and Message Queuing on one cluster, SQL Server on another

Although it is more expensive from a hardware perspective, some installations require this level of separation for maximum performance and high availability. Because SQL Server will run on a completely separate cluster, the optimal configuration is to have two instances running in an active/active configuration.

  • Node A will run a SQL Server instance for the Shared Queue and Orchestration Persistence databases.
  • Node B will run a SQL Server instance for the Tracking and BizTalk Messaging Management databases.
    Warning   BizTalk Server active/active cluster configurations are not supported. Note that in all the configurations presented in this article, BizTalk Server is configured in an active/passive configuration.

For this option, a second cluster instance must be set up with a unique IP address. Refer to the Microsoft KB article Q243218, INF: Installation Order for SQL Server 2000 Enterprise Edition on Microsoft Cluster Server for further information about installing SQL Server.

In this configuration, the SQL Server client utilities will still need to be installed on the BizTalk Server cluster to enable TCP connection configuration and management of the remote SQL Server instance.

Install a SQL Server instance

Make sure that all the computers on the cluster are turned on at this step, and that the external storage is turned on and is properly recognized. Before continuing, make sure you know the following:

  • Static IP address to be used for the virtual SQL Server
  • Name for the SQL Server virtual computer
  • If used, the name of the SQL Server instance(s)
  • Name and password for the domain user configured as local administrator on every computer participating on the cluster

Start installation of the SQL Server instance from the computer that currently owns the cluster resources.

Note   Use Cluster Administrator to find out which computer is currently the owner of the cluster resources.

Make sure to configure the directory for the SQL Server data files on the external shared storage.

You only need to set up the SQL Server instance once from the computer that currently owns the cluster resources. After successful installation of the SQL Server instance on the cluster, every computer will have copies of the SQL Server application files on local drives and will be configured to use data files on the external shared storage.

  1. Insert the SQL Server 2000 Enterprise CD-ROM into your CD-ROM drive, and then click SQL Server 2000 Components.
  2. Click Install Database Server, and then click Next.
  3. Click Virtual Server, and then type the name you want to use for the virtual SQL Server instance.
  4. In the Failover Clustering dialog box, type the IP address that will be used exclusively for SQL Server. Select the network that is associated with that IP address from the list.
  5. Select the SQL Server group that has a disk resource in it. It is recommended that this group be different from the BizTalk Messaging and Quorum groups.
  6. Leave all nodes selected as configured nodes for cluster definition, and then click Next.
  7. Type the user ID and password for an account that has administrative rights on all nodes.
  8. Make sure that Create a default instance is selected, and then click Next.
  9. Leave the installation paths at the default settings, start a typical installation, and then click Next. SQL Server 2000 installs the binaries to the local node, and the databases to the shared disk.
  10. Click Use the same account for each service, and then type an account that will be used to start the SQL Server service. Note that this account needs to be a domain-level account that is a member of the local administrators group.
  11. Select the appropriate authentication mode (Windows Authentication mode is the default), and then click Next.
  12. After the installation has finished on all nodes, click Finish.
  13. Apply service packs as required.

For additional information about installing SQL Server on a cluster, see the Microsoft KB article Q243218, INF: Installation Order for SQL Server 2000 Enterprise Edition on Microsoft Cluster Server.

Installing SQL Server client tools only (when SQL Server is running remotely)

Because the client tools are not required for a cluster, they should be installed on the local system drive of each node in the cluster. Start the SQL Server setup program on each node and in the Installation Selection window, choose Create a new instance of SQL Server, or install Client Tools and leave the remaining default options, making sure that in the Installation Definition window the Client Tools Only check box is selected.

Test SQL Server Failover

Use the Cluster Administrator to test failover. After the default threshold is exceeded (the default is three retries) all resources in the group should fail over to the other node and come online in the correct order. Select the SQL Server resource and use the Initiate Failure menu option to simulate failures.

Install BizTalk Server

At this point, there should be a BizTalk Server cluster resource group (the BizTalk Messaging Group) that contains at least the following resources:

  • IP address
  • Network name
  • Shared disk
  • MS DTC
  • Virtual Message Queuing
  • Manage Virtual Message Queuing

To install BizTalk Server on the first node in the cluster:

  1. Make the computer on which BizTalk Server is about to be installed the owner of the BizTalk Messaging Group resources. If there is more than one resource group, be sure to use the resource group containing MS DTC as shown above.
  2. Start Cluster Administrator, and move the BizTalk Messaging Group to node 1.
  3. Insert the BizTalk Server 2000 Enterprise Edition CD-ROM into the node 1 computer, and run Setup.exe from the root folder.
  4. On the Welcome to Microsoft BizTalk Server 2000 Setup Wizard page, click Next.
  5. On the License Agreement page, after reading the agreement, click I accept this agreement and then click Next.
  6. On the Customer Information page, in the Product key boxes, type a valid product key, leave Anyone who uses this computer selected, and then click Next.
  7. On the Destination Folder page, click Next.
  8. On the Setup Type page, leave Complete selected and click Next.
    Note   If you do not want to install BizTalk Orchestration, select a Custom installation, and select all the components except BizTalk Orchestration.
  9. On the Configure BizTalk Server Administrative Access page, leave the default information and click Next.
    Note   Do not confuse this with a cluster group, because this is a local security group.
  10. Click This account, and then type an account that is to be used to start the BizTalk service. Clear the Start service after setup completes check box, and then click Next.
    Note   It is recommended that you use the same account that is used by the Cluster service.
  11. On the Ready To Install the Program page, verify the configuration settings, and click Install.
    Note   It takes several minutes for the product files to be installed on your server.
  12. On the Welcome to Microsoft BizTalk Server 2000 Messaging Database Setup Wizard page, click Next.
  13. On the Configure a BizTalk Messaging Management Database page, click Create a new BizTalk Messaging Management database, and then under SQL Server connection parameters, type the SQL Server virtual server name (that was created previously in the SQL Server installation section) in the Server name box, type the SQL Server user name and password, and then click Next.

    Ee265629.bts_2002clustering_16(en-US,BTS.10).gif

    Figure 16. Entering parameters for a new BizTalk Messaging Management database

  14. On the Configure a BizTalk Server Group page, click Create a new BizTalk Server group (unless you already have an existing BizTalk Server group), and then click Next.
    Note   Do not confuse this with a group that is within the cluster. This is a grouping of independent BizTalk Servers that can work together to service requests, not a cluster group for failover.

    Ee265629.bts_2002clustering_17(en-US,BTS.10).gif

    Figure 17. Creating a new BizTalk Server group

  15. On the Configure a Tracking Database page, click Create a new Tracking database, and then under SQL Server connection parameters, type the SQL Server virtual server name (that was created previously in the SQL Server installation section) in the Server name box, and then click Next.

    Ee265629.bts_2002clustering_18(en-US,BTS.10).gif

    Figure 18. Entering parameters for a new tracking database

  16. On the Configure a Shared Queue Database page, click Create a new Shared Queue database, and then under SQL Server connection parameters, type the SQL Server virtual server name (that was created previously in the SQL Server installation section) in the Server name box, and then click Next.
  17. On the Verify BizTalk Server Group page, click Next.
  18. On the Completing the Microsoft BizTalk Server 2000 Messaging Database Setup Wizard page, click Finish.
  19. On the Welcome to Microsoft BizTalk Server 2000 Orchestration Persistence Database Setup Wizard page, click Next.
  20. On the Configure a Default Orchestration Persistence Database page, click Create a new default Orchestration Persistence database, and then under SQL Server connection parameters, type the SQL Server virtual server name (that was created previously in the SQL Server installation section) in the Server name box, and then click Next.
  21. On the Completing the Microsoft BizTalk Server 2000 Setup Wizard page, click Finish.
  22. On the Start menu, point to Settings and click Control Panel. Double-click Administrative Tools, and then double-click Services. The Services window appears.
  23. Double-click BizTalk Messaging Service. The BizTalk Messaging Service Properties window appears.
  24. Click the Log On tab. Verify that the startup account is a domain account with sufficient permissions. This account must be a local administrator on each node in the cluster. In addition, if BizTalk Server will need to write to Message Queuing or file shares on other network servers, there will need to be sufficient domain-level permissions to do so.
  25. Click the General tab. For Startup type select Manual. In the Service Status area, click Stop.
  26. Click OK.
  27. Double-click XLANG Schedule Restart Service. The XLANG Schedule Restart Service Properties window appears.
  28. Click the Log On tab. Set the startup account to a domain account with sufficient permissions. This account must be a local administrator on each node in the cluster. In addition, if BizTalk Server will need to write to Message Queuing or file shares on other network servers, there will need to be sufficient domain-level permissions to do so.
  29. Click the General tab. For Startup type select Manual. In the Service Status area, click Stop.
  30. Click OK.
  31. Apply BizTalk Server 2000 Service Pack 1 or later, and then reboot the node.

To install BizTalk Server on the remaining nodes in the cluster:

  1. Follow steps 1 through 12 above.
  2. On the Configure a BizTalk Messaging Management Database page, click Select an existing database, and then under SQL Server connection parameters, type the SQL Server virtual server name (that was created previously in the SQL Server installation section) in the Server name box, type the user name and password, and then click Next.
  3. On the Configure a BizTalk Server Group page, click Select an existing BizTalk Server group, and then click Next.
    Note   The first cluster node should already be listed in the group.
  4. On the Verify BizTalk Server Group page, click Next.
  5. On the Completing the Microsoft BizTalk Server 2000 Messaging Database Setup Wizard page, click Finish.
  6. On the Welcome to Microsoft BizTalk Server 2000 Orchestration Persistence Database Setup Wizard page, click Next.
  7. On the Configure a Default Orchestration Persistence Database page, click Select an existing database, and then under SQL Server connection parameters, type the SQL Server virtual server name (that was created previously in the SQL Server installation section) in the Server name box, and then click Finish.
  8. On the Completing the Microsoft BizTalk Server 2000 Setup Wizard page, click Finish.
  9. On the Start menu, point to Settings and click Control Panel. Double-click Administrative Tools, and then double-click Services. The Services window appears.
  10. Double-click BizTalk Messaging Service. The BizTalk Messaging Service Properties window appears.
  11. Click the Log On tab. Verify that the startup account is a domain account with sufficient permissions. This account must be a local administrator on each node in the cluster. In addition, if BizTalk Server will need to write to Message Queuing or file shares on other network servers, there will need to be sufficient domain-level privileges to do so.
  12. Click the General tab. For Startup type select Manual. In the Service Status area, click Stop.
  13. Click OK.
  14. Double-click XLANG Schedule Restart Service. The XLANG Schedule Restart Service Properties window appears.
  15. Click the Log On tab. Set the startup account to a domain account with sufficient permissions. This account must be a local administrator on each node in the cluster. In addition, if BizTalk Server will need to write to Message Queuing or file shares on other network servers, there will need to be sufficient domain-level permissions to do so.
  16. Click the General tab. For Startup type select Manual. In the Service Status area, click Stop.
  17. Click OK.
  18. Apply BizTalk Server 2000 Service Pack 1 or later, and then reboot the node.

Configure BizTalk Server as a Cluster Resource

The cluster configuration can proceed after BizTalk Server has been completely set up and successfully installed onto the local system drive on all the cluster nodes.

Configure the BizTalk Server Group

Use the BizTalk Server Administration application to configure the server group.

  1. On the Start menu, point to Programs, point to Microsoft BizTalk Server 2000, and then click BizTalk Server Administration. The BizTalk Server Administration window appears.
  2. Click the name of the virtual network in the cluster resource group where the BizTalk Server resource will be installed. The network name needs to be online for the next set of steps.
  3. Open the BizTalk Server Administration window on one of the inactive nodes within the cluster.
  4. Remove all of the servers that appear in the BizTalk Server group (the names of the individual cluster nodes).

    For each computer that is listed on the server group, perform the following steps:

    1. In BizTalk Server Group, click the computer name. On the Action menu, click Stop.
    2. To remove the server from the group, on the Action menu click Delete.
    3. Repeat these steps until the group is empty.
  5. Finally, click BizTalk Server Group and on the Action menu, point to New and click Server. In the BizTalk Server name box, type the virtual cluster server name. This name replaces all of the individual nodes within the cluster.
    Note   Identify the virtual network name by examining the Parameters tab on the Properties of the cluster network resource in the BizTalk Messaging Group of which BizTalk Server will become a part.

    At the end of this step only the network name should be listed under the server group.

    Ee265629.bts_2002clustering_19(en-US,BTS.10).gif

    Figure 19. The finished BizTalk Server Group

Add a cluster resource for BizTalk Messaging Service (BTSSvc)

Before you perform this procedure, it is important to double-check the following:

  • Make sure that BizTalk Messaging Service is stopped on all of the nodes before adding the resource to the group.
  • Make sure that on the Properties of the BizTalk Messaging Service of each node the startup type is set to Manual.
  • Make sure that the network name of the group where BizTalk Messaging resides is added to the BizTalk Server group using the BizTalk Server Administrator. Also verify that this is the only name in the group. To find the virtual network name, examine the Properties of the cluster network name resource in the BizTalk Server group.
  • Make sure that MS DTC is a dependency of BizTalk Messaging. It must have MS DTC running within the same group to function properly.
  1. Using the Cluster Administrator application, click the BizTalk Messaging Group, which contains the IP address and network name that BizTalk Server will use.
    Important   This group must contain the MS DTC resource.
  2. On the File menu, point to New and click Resource. The New Resource window appears.
  3. In the Name box, type BizTalk Messaging Service. In the Resource type list, select Generic Service. Make sure BizTalk Messaging is selected in the Group list. Click Next. The Possible Owners window appears.
  4. Include every computer on the cluster as a possible resource owner. Click Next. The Dependencies window appears.
  5. Add resource dependencies for:
    • Network name
    • Shared disk
    • MS DTC
    • Virtual Message Queuing
    • If the SQL Server instance is also running on the same cluster and is created within the same cluster resource group, add the SQL Server service resource to the list of dependencies.
  6. Click Next.
  7. In the Generic Service Parameters window, type BTSSvc in the Service name box. Select Use Network Name for computer name. Click Next.
  8. In the Registry Replication window, click Add.
  9. In the Registry Key window, type System\CurrentControlSet\Services\BTSSVC. Click OK, and then click Finish.
  10. After the resource has been added, right-click the BizTalk Server virtual server, and click Properties. On the Advanced tab, make sure the Affect the group check box is cleared.
    Warning   If Affect the group is selected while trying to start the service and something fails, it will force a failover loop that will be difficult to stop.
  11. BizTalk Messaging should now be able to start within the cluster. Assuming that all the dependencies have been correctly set up, you can bring the virtual BizTalk Server resource online by right-clicking it and clicking Bring Online.
    Important   By default, all configuration changes are stored in the BizTalk Server Messaging Management database. However, there are some very specific performance tuning parameters that, when used, are stored in the registry. If these registry changes are added to one node in the cluster, they will need to be replicated to all other nodes. These tuning settings are:
       - NoValidation
       - ParserRefreshInterval
       - CacheSize
       - BatchSize
    By default these registry values do not exist in the registry and should only be added when it is necessary for performance tuning. If they are added, it is important to use the registry replication features of the Cluster service to ensure that all nodes are consistent. For an explanation of how registry replication works, refer to the Microsoft KB article Q174070, Registry Replication in Microsoft Cluster Server. Registry key replication is part of the configuring of a Generic Application resource in the Cluster service. The key that must be replicated is HKEY_LOCAL_MACHINE\System\Current Control Set\Services\BTSSVC.

Repository cluster configuration

This optional step provides an additional level of protection by safeguarding the repository files during design time. To guard against a failure of the local drive of a node containing the BizTalk Server repository information, the files can be placed on a shared cluster disk resource. In addition, this configuration allows you to easily access the repository files from any of the cluster nodes. BizTalk Server and the tools provided use a feature of IIS called WebDAV to read and write the repository data.

Rather than locking IIS to a specific cluster node that could fail, the IIS instance should also be made into a virtual IIS instance that can run transparently on either cluster node. Follow these steps to install the IIS instance:

  1. Using the Cluster Administrator application, locate the first machine where BizTalk Server was installed.
  2. Move to this node the BizTalk Messaging Group that contains the shared disk resource that will hold the BizTalk Server repository.
  3. Copy the <SystemDrive>:\Program Files\Microsoft BizTalk Server\BizTalkServerRepository folder to the shared storage in the BizTalk Messaging Group.
  4. Select the BizTalk Messaging Group. On the Action menu, point to New and click Resource. The New Resource window appears.
  5. In the Name box, type IIS WebDAV. In the Resource type list, select IIS Server Instance. Make sure BizTalk Messaging is selected in the Group list. Click Next. The Possible Owners window appears.
  6. Make sure every node is a possible owner of this resource and click Next. The Dependencies window appears.
  7. Add resource dependencies for the following:
    • IP address
    • Shared disk
    • Network name
  8. Click Next.
  9. In the Parameters window, click WWW, and in the IIS Server list select Default Web Site. Click Finish.
  10. Leave the resource offline.
  11. For each computer participating on the cluster:
    1. Use the Cluster Administrator application to move the resource group containing the BizTalk Server and IIS virtual resources to the computer you are working on.
    2. On the Start menu, point to Settings and click Administrative Tools. Double-click Internet Services Manager. The Internet Information Services window appears.
    3. Expand the cluster node, and then expand Default Web Site. Right-click BizTalkServerRepository and click Properties. On the Virtual Directory tab, change the path to the folder to which you copied the files on the shared disk in step 3.

      Ee265629.bts_2002clustering_20(en-US,BTS.10).gif

      Figure 20. Setting the path to the local repository

      Important   Make sure you perform this step on each computer in the cluster. When complete, bring the IIS WebDAV resource online.
      Note   It is a good idea to rename the original BizTalkServerRepository folder on each node to easily distinguish them and avoid confusion.
  12. On the Start menu, point to Programs, point to Microsoft BizTalk Server 2000, and then click BizTalk Messaging Manager. The BizTalk Messaging Manager application appears. On the Tools menu, click Options. Make sure that Name of the BizTalk Server to connect to is the name of the BizTalk Messaging Group network name.
  13. Move the resource group to the other node and verify once again that BizTalk Messaging Manager can successfully use the virtual IIS network name.

Add a cluster resource for the IInterchange application

A document can be submitted to BizTalk Server from a remote client running a COM+ application that uses the IInterchange interface. This application must have a cluster resource associated with it, and must reside in the same cluster resource group as BizTalk Messaging Service.

  1. Using the Cluster Administrator application, click the BizTalk Messaging Group, which contains the IP address and network name that BizTalk Server will use.
  2. On the File menu, point to New and click Resource. The New Resource window appears.
  3. In the Name box, type IInterchange application. In the Resource type list, select Generic Application. Click Next. The Possible Owners window appears.
  4. Include every computer on the cluster as a possible resource owner.
  5. Add resource dependencies for:
    • Network name
    • Shared disk
    • MS DTC
    • If SQL Server is created as a resource within the same group, add SQL Server as a resource dependency.
  6. Click Next. The Generic Application Parameters window appears.
  7. In the Command line box, type

    dllhost.exe /ProcessId:{OC9B9BBE-E0F2-4485-9BE8-C40BAC8D0677}

  8. In the Current directory box, type the root directory of the shared disk resource drive in the group.
  9. In the Registry Replication window, click Finish.
  10. Select Allow application to interact with desktop and Use Network Name for computer name. Click Next.

    After the resource for the COM+ application that uses the IInterchange interface has been added to the BizTalk Messaging Group, right-click IInterchange application and click Properties. On the Advanced tab, clear Affect the Group.

    Warning   The COM+ application using the IInterchange interface runs under the account of the user currently logged on to BizTalk Server. To avoid unnecessary security issues, this user must have Cluster service administration privileges.

Add a cluster resource for the XLANG Scheduler Engine

The XLANG Scheduler Engine can be configured to reside in the same cluster resource group as BizTalk Messaging, or in a separate group. The advantage of creating a separate cluster resource group for BizTalk Orchestration is that the XLANG Scheduler Engine can optionally run on the other node in the cluster. This helps to optimize the use of both nodes in the cluster while providing the maximum performance for each component. If the XLANG Scheduler resource is placed in a different group from the BizTalk Messaging resource, you must use an application instead of a BizTalk Messaging port to start the XLANG schedules. This is because BizTalk Messaging can only start XLANG schedules that are local (that is, on the same virtual server). Refer to the following subsection about starting XLANG schedules for more details.

  1. Using the Cluster Administrator application, click the BizTalk Orchestration group, which contains the IP address and network name that BizTalk Server will use.
  2. On the File menu, point to New and click Resource. The New Resource window appears.
  3. In the Name box, type XLANG Scheduler. In the Resource type list, select Generic Application. Click Next. The Possible Owners window appears.
  4. Include every computer on the cluster as a possible resource owner.
  5. Add resource dependencies for:
    • Network name
    • Shared disk
    • Message Queuing
    • If this is the same group as BizTalk Messaging, also add MS DTC. If this is a separate group, this dependency is not required because MS DTC will automatically provide services across both nodes in the cluster.
    • If SQL Server is created as a resource within the same group, add SQL Server as a resource dependency.
  6. Click Next. The Generic Application Parameters window appears.
  7. In the Command line box, type

    dllhost.exe /ProcessId:{DFDE2592-40A4-42BC-A35E-FD0BF76CA4D5}

  8. In the Current directory box, type the root directory of the shared disk resource drive in the group.
  9. Select Allow application to interact with desktop and Use Network Name for computer name. Click Next.
  10. In the Registry Replication window, click Finish.
  11. After the XLANG Scheduler resource has been added to the BizTalk Orchestration group, right-click XLANG Scheduler and click Properties. On the Advanced tab clear Affect the Group, and select Do not restart.
    Warning   The XLANG Scheduler Engine runs under the account of the user currently logged on to BizTalk Server. To avoid unnecessary security issues, this user must have Cluster service administration privileges.

Add a cluster resource for the XLANG Schedule Restart Service (BTWSvcMgr)

The XLANG Schedule Restart Service resource is responsible for ensuring that the XLANG Scheduler Engine is started and stopped in a controlled fashion.

When it is brought online, it immediately starts the XLANG Scheduler Engine (because it is specified as a resource dependency) and then rehydrates any previously persisted XLANG schedules.

When it is brought offline, the XLANG Scheduler Engine attempts to gracefully stop all currently running XLANG schedules, in some cases persisting their state, before shutting down.

Before you perform this procedure, it is important to make sure that on the Properties of the BizTalk Messaging Service of each node, the startup type is set to Manual.

  1. Using the Cluster Administrator application, click the BizTalk Orchestration group, which contains the IP address and network name that BizTalk Server will use.
  2. On the File menu, point to New and click Resource. The New Resource window appears.
  3. In the Name box, type XLANG Schedule Restart Service. In the Resource type list, choose Generic Service. Click Next. The Possible Owners window appears.
  4. Include every computer on the cluster as a possible resource owner.
  5. Add resource dependencies for:
    • Network name
    • XLANG Scheduler Engine
  6. Click Next. The Generic Services Parameters window appears.
  7. In the Service Name box, type BTWSvcMgr, select Use Network Name for computer name, and click Next.
  8. In the Registry Replication window, click Finish.
  9. After the XLANG Schedule Restart Service has been added, right-click XLANG Schedule Restart Service and click Properties. On the Advanced tab clear Affect the Group, and select Do not restart.
  10. Test the resource by bringing it online. The XLANG Scheduler resource should also start automatically.

Important

  • To start the XLANG Scheduler Engine, always bring the XLANG Schedule Restart Service online. Because of the resource dependency that has been set up, the XLANG Scheduler resource also comes online automatically.
  • To stop the XLANG Scheduler resource correctly, bring the XLANG Scheduler Engine offline. Because of the dependency that has been set up, the XLANG Schedule Restart Service resource will be brought offline first, followed by the XLANG Scheduler resource.
  • Test starting and stopping by using this method. After the test, examine the event log for the application and make sure that there are no critical errors.
  • To check that the XLANG Schedule COM+ application is stopped and started correctly by the clustered instance, do the following:
    1. On the server that is actively running BizTalk Orchestration, open Component Services.
    2. On the Start menu, point to Settings, click Control Panel, double-click Administrative Tools, and then double-click Component Services. The Component Services window appears.
    3. Expand the COM+ applications.
    4. Highlight the cluster node server name.
    5. Check to see if there is a process ID (PID) assigned to the XLANG Schedule application. If there is, bring the XLANG Scheduler resource offline in the Cluster Administrator. This should also stop the XLANG Schedule Restart Service resource. This procedure should shut down the XLANG Schedule COM+ application and you should see the PID disappear. This indicates normal operation.
    6. If both the XLANG Schedule Restart Service and the XLANG Scheduler Engine have been brought offline successfully in the Cluster Administrator, and there is still an active PID showing in the component services for the XLANG Schedule application, then do the following.

      Right-click the XLANG Schedule COM+ application in Component Services and choose Properties. Click the XLANG tab and click Controlled Shut Down. Check the PID again. If it is still active, this may indicate that a client application is running and is starting XLANG schedules. If this is the case, stop the application and repeat the verification procedure.

Starting XLANG schedules in a cluster

If you plan to use a BizTalk Messaging port to start the XLANG schedules in a cluster, the following rules apply:

  • When referencing the XLANG schedule (.skx) file during the creation of the BizTalk Messaging port, be extremely careful to use the correct path to the location of the XLANG schedule file. It is recommended that you place the .skx file onto the shared disk that is part of the same BizTalk Messaging Group. Reference the .skx file using a drive letter such as F:\XLANG\<name>.skx. In this case, the F drive must be the shared drive in the same group as the BizTalk Server virtual resource and the XLANG Scheduler resource.
  • The XLANG Scheduler resource must be in the same group as the BizTalk Server virtual resource.
  • The same virtual Message Queuing resource should be a dependency for both the XLANG Scheduler and the BizTalk Server virtual resources.

If you wish to start an XLANG schedule when BizTalk Orchestration is running on a different resource group, this is essentially treated the same as starting it on a different server. This is true even if the resource group is active on the same cluster node as the group containing the BizTalk Server virtual resource. To start a remote XLANG schedule you must use an alternative method. Refer to the BizTalk Orchestration documentation for instructions about how to do this programmatically and for details about using the correct moniker syntax. A remote XLANG schedule can be started using just a few lines of code, and there are various approaches available. Under the BizTalk Server folder, there is an SDK folder containing code samples to programmatically start an XLANG schedule. When referencing any remote schedule you must provide a URL to the file share containing the .skx file.

When starting XLANG schedules from an application, be sure to specify the cluster virtual name and not the local node name. If an application starts a schedule under the cluster node server name, this can cause problems for the clustered instance. Applications that start XLANG schedules must either be a cluster resource or run on remote computers independent from the cluster. Starting an XLANG schedule from a non-clustered application running on a cluster node might result in having another copy of the non-clustered XLANG COM+ package started.

Keep in mind that the XLANG schedule will need to run from any node. Make sure to check the BizTalk Orchestration designs for any references to local application services or COM+ components. Make sure that any such dependencies are set up in a consistent manner on all nodes.

Warning   Prior to creating an XLANG schedule using remote activation, use Server Cluster APIs to verify that the resource group is online and the XLANG resource is running. For more information, go to the MSDN Library and search on "Server Cluster APIs."

Bring all the BizTalk Server cluster resources online

Using the Cluster Administrator, on the File menu, click Bring Online and select the following resources:

  • BizTalk Messaging Service
  • XLANG Schedule Restart Service

If any of these resources fail to come online, check the event log for both the application and the system, and double-check the following:

  • All the other resources in the group are running.
  • SQL Server is running and is accessible.
  • BizTalk Messaging, XLANG Scheduler, and XLANG Schedule Restart Service have the correct dependencies.
  • The options Use Network Name as Computer Name and Allow application to interact with desktop are selected.

Test BizTalk Server Failover

Use the Cluster Administrator application to test manual failover. Select the BizTalk Messaging Group and click Move group.

All resources in the group will switch to offline pending and then move to the other node in the cluster. Each resource will then come online in the order of dependency.

Test XLANG Scheduler Engine Failover

If BizTalk Orchestration is configured to run in a separate cluster resource group, it is necessary to independently test the BizTalk Orchestration failover. To do so, select the BizTalk Server XLANG group and click Move group.

All resources in the group will switch to offline pending and then move to the other node in the cluster. Each resource will then come online in the order of dependency.

Upgrading to Biztalk Server 2002

The following steps assume that you have configured BizTalk Server 2000 as described in this article, and it is running correctly on a cluster environment.

Note   Read the BizTalk Server 2002 installation instructions provided with the compact disc to make sure you have followed all the preliminary setup steps.
  1. Start Cluster Administrator, and move the BizTalk Messaging Group and BizTalk Orchestration Group to node 1.
  2. Bring offline all the resources related to BizTalk Server: BizTalk Messaging Service, IInterchange application, XLANG Scheduler, XLANG Schedule Restart Service.
  3. Insert the BizTalk Server 2002 compact disc into the CD-ROM drive in node 1, and run Setup.exe from the root folder.
  4. In the warning dialog box, click OK.
  5. On the Customer Information page, type your name in the User name box, type the name of your company in the Organization box, and then click Next.
  6. On the Destination Folder page, click Next to upgrade the BizTalk Server installation located in the default directory.
  7. On the Setup Type page, leave Complete, and click Next.
    Note   All existing BizTalk Server files will be removed during the upgrade process. Only the features that you select will be installed.
  8. On the Configure BizTalk Server Administrative Access page, leave the default information, and click Next.
  9. On the Microsoft BizTalk Server Service Log On Properties page, accept the default setting This account, and then type an account that is to be used to start the BizTalk service.
    Note   It is recommended that you use the same account that the Cluster service uses.
  10. On the Ready to Install the Program page, click Install.
  11. When the Welcome to the Microsoft BizTalk Server 2002 Messaging Database Setup Wizard page appears, click Next.
  12. On the Configure a BizTalk Messaging Management Database page, click Select an existing database, and then under SQL Server connection parameters, type the SQL Server virtual server name and click Next.
  13. On the warning, click Yes.
  14. On the Configure a BizTalk Server Group page, click Select an existing BizTalk Server group, and then click Next.
  15. In the warning dialog box, click Yes.
  16. On the Verify BizTalk Server Group page, click Next.
  17. On the Completing the Microsoft BizTalk Server 2002 Messaging Database Setup Wizard page, click Finish.
  18. On the Welcome to the Microsoft BizTalk Server 2002 Orchestration Persistence Database Setup Wizard page, click Next.
  19. On the Configure a Default Orchestration Persistence Database page, click Select an existing database, and then under SQL Server connection parameters, type the SQL Server virtual server name and then click Finish.
  20. On the Completing the Microsoft BizTalk Server 2002 Setup Wizard page, click Finish.
  21. On the Start menu, point to Settings and click Control Panel. Double-click Administrative Tools, and then double-click Services. The Services window appears.
  22. Double-click BizTalk Messaging Service. The BizTalk Messaging Service Properties window appears.
  23. Click the Log On tab. Verify that the startup account is a domain account with sufficient permissions. This account must be a local administrator on each node in the cluster. In addition, if BizTalk Server will need to write to Message Queuing or file shares on other network servers, there will need to be sufficient domain-level privileges to do so.
  24. Click the General tab. For Startup type select Manual. In the Service Status area, click Stop.
  25. Click OK.
  26. Double-click XLANG Schedule Restart Service. The XLANG Schedule Restart Service Properties window appears.
  27. Click the Log On tab. Set the startup account to be a domain account with sufficient permissions. This account must be a local administrator on each node in the cluster. In addition, if BizTalk Server will need to write to Message Queuing or file shares on other network servers, there will need to be sufficient domain-level permissions to do so.
  28. Click the General tab. For Startup type select Manual. In the Service Status area, click Stop.
  29. Click OK.
  30. Repeat steps 3 through 29 for node 2.
  31. On the Start menu, point to Programs, point to Microsoft BizTalk Server 2002, and then click BizTalk Server Administration. The BizTalk Server Administration window appears.
  32. Click the name of the virtual network in the cluster resource group where the BizTalk Server resource is installed. The network name needs to be online for the next set of steps.
  33. Open the BizTalk Server Administration window on one of the inactive nodes within the cluster.
  34. Remove all of the servers that appear in the BizTalk Server group that are the names of the individual cluster nodes, until only the BizTalk Server virtual server remains.

    For each computer that is listed on the server group, perform the following steps:

    1. In BizTalk Server Group click the computer name. On the Action menu click Stop.
    2. To remove the server from the group, on the Action menu click Delete.

Troubleshooting

There are some known problems that can occur while setting up BizTalk Server and configuring the cluster. This small troubleshooting guide provides some workarounds.

For updated information and late-breaking news, see the Microsoft BizTalk Server Web site and the Microsoft Support Web site, and search for BizTalk Server Knowledge Base articles.

BizTalk Server Setup Fails to Start

It has been observed that an error message appears if the following sequence of events happens:

  1. BizTalk Server is installed on a cluster from node A while that is the active node (has control of shared drives).
  2. Control of the cluster resources is transferred to node B.
  3. BizTalk Server is uninstalled from node A.
  4. Finally, the attempt is made to reinstall BizTalk Server on node A.

Two workarounds exist to either avoid or fix this problem. To avoid it, ensure that the group is local when installing. To fix the problem after it has occurred, use the Microsoft Platform Software Development Kit (SDK) to run the command msizap.exe to clean up the registry so that BizTalk Server can be installed and uninstalled again.

A Second Copy of XLANG Scheduler Is Started

A second copy of the XLANG Scheduler is started when the XLANG Monitor application is opened from a command prompt started from the Start menu. When this happens, BizTalk Server will not function correctly, and the user will have a hard time finding out which dllhost.exe process to stop.

To avoid this problem, create a cluster resource for XLANG Monitor by following these steps:

  1. Start Cluster Administrator.
  2. Right-click the BizTalk Orchestration Group, point to New, and then click Resource.
  3. In the Name box, type Command Prompt. In the Resource type list, select Generic Application, and then click Next.
  4. In the Possible Owners window, allow the resource to run on all servers on the cluster. Click Next.
  5. In the Dependencies window, add the following dependencies to the resource:
    • Network name
  6. Click Next. The Generic Application Parameters screen appears.
  7. In the Command line box, type CMD.exe
    Note   This command is run locally on each node. Change the Windows system path and drive letter if they are different on your server.
  8. In the Current directory box, type the letter of the shared directory for the BizTalk Orchestration Group.
  9. Select the Allow application to interact with desktop and Use Network Name for computer name check boxes. Click Next.
  10. In the Registry Replication window, click Finish.
  11. After the resource has been created, double-click the Command Prompt resource to edit the Properties.

    Click the Advanced tab, clear Affect the group in the Restart section, and then select Do not restart. Click OK to accept the changes.

  12. To start the XLANG Monitor, double-click the Command Prompt resource created, and type XLANGMon.exe.

A Second Copy of XLANG Monitor Is Started

A second copy of the XLANG Monitor application is started when the node it is started from is too slow. When this happens, BizTalk Server will not function correctly, and the user will have a hard time finding out which dllhost.exe process to stop.

To avoid this problem, it is recommended that you start the XLANG Monitor application from a remote, non-clustered computer.

Loss of Data Can Occur After Catastrophic Failover on BizTalk Server 2002

In BizTalk Server 2002, data from non-transactional transports can be lost during catastrophic failures such as power failures. Duplication of documents transmitted with non-transactional transports can also occur during catastrophic failures. To avoid loss of data during such failures, you must disable disk caching. However, disabling disk caching degrades the performance of BizTalk Server 2002.

In BizTalk Server 2000, the loss of data does not occur, but there might still be duplication of documents transmitted with non-transactional transports.

References

Exploring Windows Clustering Technologies

Microsoft Platform SDK

Microsoft Windows 2000 Advanced Server Security Documentation

Microsoft Windows Hardware Compatibility List

Orchestration Part 2: Transactions, Exceptions, Debugging

Step-by-Step Guide to Installing Cluster Service

SQL Server 2000 Failover Clustering White Paper

Technical White Papers for Cluster Server

Microsoft Windows 2000 Server Deployment Planning Guide, Microsoft Press, 2000

Microsoft Knowledge Base articles:
FIX: Message Queuing Logger Error Processing Causes Log Data Loss at Hardware Failures (Q254294)
How to Configure Clustered IIS Virtual Servers on Windows 2000 Advanced Server (Q248025)
How to Install the Windows 2000 Recovery Console (Q216417)
How to Obtain the Latest Windows 2000 Service Pack (Q260910)
INFO: Installation Order for SQL Server 2000 Enterprise Edition on Microsoft Cluster Server (Q243218)
INFO: Using the MSMQ Service on a Windows 2000-Based Cluster (Q310775)
Microsoft Cluster Service Installation Resources (Q259267)
Microsoft Distributed Transaction Coordinator (MSDTC) Recovery Techniques in Windows 2000 Cluster Server (Q243204)
Registry Replication in Microsoft Cluster Server (Q174070)

Show:
© 2014 Microsoft. All rights reserved.