Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Installing MTS and MSMQ in a Clustered Environment
Learn about applications accessing Microsoft Message Queue Server (MSMQ) or Microsoft Transaction Server (MTS) running in a clustered environment.
Anders Samuelsson
July 31, 1999
10 Min Read
Enhance functionality with cluster-enabled applications
With Windows NT becoming the preferred OS for mission-critical applications, it's essential that you provide the level of availability that a customer demands from your applications. To provide this level of availability, you'll likely look at the benefits that Microsoft Cluster Server (MSCS) can provide your applications. Once you start thinking about cluster-enabled applications, you can begin to understand how some of the new technologies that Microsoft provides with its Windows Distributed interNet Applications (DNA) architecture are integrated to work with MSCS. The article will interest both systems administrators that are looking at setting up a clustered environment and developers wanting to enhance the functionality of their applications by creating cluster-enabled applications.
What is a Cluster-enabled Application?
Everybody seems to have their own definition of a cluster-enabled application. I'll give you my version, which is the basis for this article. There are two types of applications in a clustered environment: cluster-aware applications and cluster-enabled applications. Cluster-aware applications run in the actual cluster. These can be applications that check whether the cluster is up and running, or whether a resource it needs is functioning. Cluster-enabled applications access data or other applications running in a cluster. This article focuses on cluster-enabled applications-specifically, applications accessing Microsoft Message Queue Server (MSMQ) or Microsoft Transaction Server (MTS) running in a clustered environment.
What are MTS and MSMQ?
At the Professional Developers Conference (PDC) in September 1997, Microsoft announced its distributed computing strategy called Windows DNA architecture. As part of the DNA architecture, Microsoft designed two middleware environments: MSMQ and MTS. These products will be part of most three-tier client/server application environments in the future. You'll also see MSMQ and MTS become part of future versions of NT in what Microsoft is calling COM+. You can see a first hint of this in the Windows NT Option Pack, where Internet Information Server (IIS) 4.0 requires that you first install MTS, because IIS consists of COM components and must run in an MTS environment. If you, as a developer, have not started looking into Windows DNA, and specifically MTS and MSMQ, I strongly recommend that you do so.
Microsoft has ensured that MTS and MSMQ technologies are supported and failover in a clustered environment. But when you use these technologies, you must also take the following precautions to ensure that they work in a clustered environment:
Install and configure the products in the correct order.
Make sure you use the correct versions of the software (See "MSMQ in a Cluster" later in this article).
Read the Release Notes very carefully.
MTS in a Cluster
The Distributed Transaction Coordinator (DTC) resource does not have any parameters to configure; however, you need to create dependencies on a disk resource and a network name. A dependency is a special relationship between resources in a cluster. These relationships exist to eliminate the possibility of misconfiguring a cluster. When installing MTS in a clustered environment, follow these steps:
Make sure you install MSCS on both machines in the cluster.
Using the Cluster Administrator, configure a group to contain an IP Address Resource, a Network Name Resource, and a Physical Disk Resource.
On the machine that owns the group you configured in step 2, run MTS installation (setup.exe) from the MTS installation CD-ROM. (Make sure that you install the version from the Windows NT Option Pack CD-ROM.) During installation, MTS will detect that MSCS is present on the system and ask for the name of the virtual server on which to install DTC. Select the name of the Network Name Resource you configured in Step 2. In the same dialog box, specify the location for the DTC log file on the shared disk you configured in Step 2.
When the installation has finished on the first node, Setup tells you to install MTS on the second node. Setup won't prompt you for the virtual server or log file location. Don't hit OK on the first node until the you finish the second-node installation.
After you install MTS on both nodes, reboot them.
Now that you've installed MTS in the cluster, how do clients know how to access the virtual MTS server? The process is similar to how clients access MTS objects on a single server. You'll need to follow these steps to create a proxy stub and install it on all clients wanting to access the server:
Using Transaction Server Explorer on any computer in the cluster, right-click My Computer and select Properties.
Choose Options, enter the name of the virtual sever in the Remote Server Name, and click OK.
Under Packages Installed, locate the package you want to cluster, right-click that package, and select Export.
Enter the directory where you want the package to reside and click Export.
Using Explorer, open the directory where you exported the package and find a directory called clients. Find the .exe file and run this program on all clients that want to access your MTS application.
You must install the package on both machines in the cluster. When the virtual server is owned by a server that does not have the package installed, the clients will fail when trying to connect.
When a failover occurs, the virtual MTS server will be unavailable for 30 to 45 seconds. During this time, clients can make no new connections. An MTS client application must always release all references to MTS components on the failing node, and re-instantiate the components on the second node.
MSMQ in a Cluster
If you want to run MSMQ on a cluster server and take advantage of failover, you must install the MSMQ provided on the Windows NT Server, Enterprise Edition CD-ROM. Installing the MSMQ from the Windows NT Option Pack will fail. After you install the NTS/E MSMQ, you can upgrade with the Windows NT Option Pack MSMQ. The following discussion assumes that you are familiar with MSMQ terminology. MSMQ supports failover for the following roles:
Primary Enterprise Controller (PEC)
Primary Site Controller (PSC)
Backup Site Controller (BSC)
Independent Client
Installing and configuring MSMQ in a Microsoft cluster isn't as easy as installing MTS. No one place holds all the information necessary to install and configure MSMQ in a cluster. Just remember that you must install all the bits and pieces in the correct order or you'll have to start over, beginning with installing NT again.
To install the software you need for running MSMQ in a Microsoft cluster, follow these steps in this order:
Install NTS/E and Service Pack 3 (SP3) on both nodes in the cluster.
Install and configure MSCS on both nodes.
Using Cluster Administrator, move the disks you want to use for the MSMQ installation to the Cluster Group containing the Cluster Name and Cluster IP address and make sure the group is on the first node. (Unfortunately, you have to install MSMQ in the Cluster Group-creating a separate group will fail-so the name and IP address of the MSMQ virtual server will be the same as the cluster.)
Install the NTS/E MSMQ on the first node. If you are installing a PEC, PSC, or BSC in the cluster, you also need to install SQL Server. Do not install SQL Server 6.5 or 7.0 enterprise edition before installing MSMQ. MSMQ does not recognize SQL Server 6.5 or 7.0. Let MSMQ install the limited version of SQL Server. Make sure you install on the shared disk that you defined in Step 3.
After you complete the installation on the first node, failover the group to the second node.
Start the installation on the second node. Make sure you use the same selections as you used on the first node, and click Update existing database for the MSMQ Information Store (MQIS) server.
Reboot both servers.
Install SP4 on both nodes. SP4 contains several bug fixes for MSCS and MSMQ.
You now have a working MSMQ environment. If you want to be able to run a full version of SQL Server in the cluster, you need to upgrade the limited SQL Server to SQL Server Enterprise Edition.
Be aware that the limited version of SQL Server that MSMQ installs does not have the same default settings as when you install SQL Server in the usual way. The limited version of SQL Server will install with the default sort order set to 51 (case sensitive); the regular version of SQL Server installs with default sort order 52 (case insensitive). If you want to use the MSMQ-installed database as a data store for your application, you need to perform two tasks: Change the sort order and upgrade the limited version of SQL Server to SQL Server Enterprise Edition (if you only need 10 simultaneous connections, you can stay with the limited version).
You can change the sort order in two ways. If you've already installed the limited version of SQL Server, you have to rebuild the master database. You can do this using setup.exe for SQL Server. Or, you can choose to modify the installation script for MSMQ before installing MSMQ by copying the MSMQ directory on the NTS/E CD-ROM to a disk, modifying the setupsql.ini file, and running the installation from that disk. You must change the section entitled [SortOrder] to:
SortFileName=nocase.isoSortConfigValue=52If you also want to run MTS in the cluster, you have a challenge. The MSMQ kit on the NTS/E CD-ROM doesn't like the version of MTS from the Windows NT Option Pack. If you install the Windows NT Option Pack before you start the MSMQ installation, you have to start over by installing NT, MSCS, and the NTS/E MSMQ. Then you upgrade to SQL Server Enterprise Edition. After this, you're ready to upgrade your software to the Windows NT Option Pack versions.
What Happens in the Cluster When a Failover Occurs?
During a failover, the queue will not be available for 30 to 90 seconds. The last resource in your virtual server group to come online will be the MSMQ resource. You, as developer, need to take into account the time that the resource might be unavailable. You also need to make sure that your messages are sent as MQMSG_DELIVERY_RECOVERABLE. You can't use the EXPRESS delivery method because this only stores messages in memory, and MSCS does not yet fail over memory. The RECOVERABLE delivery method stores the messages on disk, which enables the queue failover functionality.
You must also make all client and server connections to the queue recoverable. When a failover occurs, the client and server will lose contact with the queue with the error code:
MQ_ERROR_INVALID_HANDLE.You need to add code in your application to reconnect to the queue, regardless of whether you're writing or reading from the queue.
Things to Think About
So, have you started to rethink your application? Do you have a better understanding of how a cluster works? As you can see, administrators must consider several factors when running applications in a cluster, and developers must take certain steps to make the application cluster-enabled. Let's review:
Administrator:
When running MTS in a cluster, you must install and configure MTS correctly. All clients accessing an MTS application must run the client stub generated on the MTS server directing the clients to the clustered MTS.
Make sure you install the MTS package on both nodes in the cluster.
Make sure you install MSMQ in the correct order or you'll have to start over again.
Developer:
If you develop your application for MTS, make sure that when you export the client stub, that you enter the Virtual Server Name in the Remote Server Name. Then export the package and run the client stub generator on every client that will access the MTS application.
Make sure your MTS clients release all references to MTS components on the failing node. The clients need to reinstantiate the components.
If you are developing for MSMQ, make sure your messages are sent with MQMSG_DELIVERY_RECOVERABLE, and that your applications accessing the queue handle the MQ_ERROR_INVALID_HANDLE due to failover.
Generally, you as a developer are responsible for making sure that your application re-initiates lost connections. As a result, you must take into account that the resource can be down for as much as 1 minute.
Using MTS and MSMQ in a clustered environment can greatly enhance the functionality and availability of your applications. Microsoft has provided these tools and ensured that they work in a clustered environment. With the information provided in this article, you can install MTS and MSMQ and be well on your way toward providing the quality of applications that your customers demand.
About the Author
You May Also Like
