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.