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.iso
SortConfigValue=52
If 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.