The previous installment of our Windows Server 2003-based high availability solutions series discussed Microsoft Distributed Transaction Coordinator (MSDTC), which extends the scope of transactional capabilities to multiple, potentially independent systems.
|Message Queuing has become a popular option to ensure reliability. Because it uses a queue-based infrastructure, which provides message store and delivery mechanism as well as other features, applications stay up — even when the target or intermediary systems are not.|
Unsure About an Acronym or Term?
As we pointed out, combining its functionality with server clustering results in synergistic benefits and increases overall resiliency and fault tolerance. Another widely popular technology that can be leveraged in a similar manner is Message Queuing. This article will look at the general characteristics of Message Queuing and describe its clustered implementation.
Message Queuing is a middleware application. Its primary purpose is to facilitate asynchronous communication between applications operating in a distributed, potentially heterogeneous environment. This is accomplished by employing a queue infrastructure, which provides message store and delivery mechanism that is supplemented by additional features, such as routing, acknowledgments and journals that ensure reliability, even in cases when target or intermediary systems are temporarily unreachable. Queues are categorized as either system or application, depending on whether they perform system-level services (provisioned automatically by the Message Queuing software) or to support client applications (created via custom code or by an administrative support group). The latter category can be further subdivided into public, with queue metadata published in Active Directory, and private, where configuration must be obtained directly from the computer on which the queue resides.
Microsoft implementation of Message Queuing (MSMQ) has been available as an optional component of the operating system since the release of the Windows Server 2000 product line, coinciding with version 2.0. We will look at its successor, which is bundled with Windows XP Professional and Windows Server 2003. The latest rendition, v4.0, has been included in Windows Vista. To install MSMQ on your computer, launch the Windows Component Wizard via the “Add/Remove Windows Components” section of the “Add or Remove Programs” Control Panel applet, highlight Application Server entry in the list of components, click on the Details … command button, and pick Message Queuing from the list of available entries. To review installation options, click on the Details … command button again. This will display another dialog box, from which you will be able to add any of the following:
- Active Directory Integration: Included by default, it allows publishing, viewing and configuring of MSMQ metadata in Active Directory. One of its benefits is the capability to obtain MSMQ information via LDAP forest-wide searches, rather than requesting it directly from a target server. Other capabilities include support for message encryption, dynamic routing and cross-platform integration.
- Common: Required for the basic functionality of MSMQ, it is automatically selected within the Windows Component Wizard interface whenever MSMQ component is installed.
- Downlevel Client Support: It accommodates legacy clients running earlier versions of MSMQ software by enabling them to interact with queues published in Active Directory (assuming the AD Integration feature is enabled) via the MSMQ 3.0 component installed on a Windows Server 2003 domain controller.
- MSMQ HTTP Support: By creating an IIS extension specific to MSMQ, it leverages Internet Information Services and HTTP communication for exchanging messages across MSMQ infrastructure.
- Routing Support: It assists with relaying messages across distributed, domain-based (available only with public queues and relying on MSMQ Setting Active Directory object) network environments.
- Triggers: MSMQ can invoke arbitrary actions (carried out by an executable or a COM component), based on the content of messages arriving at a designated queue.
After selecting a desired set of subcomponents that you want to become available in the clustered MSMQ implementation, continue with the wizard to its completion, and repeat this procedure on every cluster node that will be designated as a possible owner of the MSMQ Resource. Bear in mind that this rule does not apply to Downlevel Client Support, which is not supported in clustered implementation. One easily discernible change that results from the installation is the addition of the MSMQ subnode under the Services and Applications node in the Computer Management console.
From here, you can configure MSMQ-specific properties as well as manipulate system and application queues. If you included Active Directory Integration in your setup, you should also be able to view and manage MSMQ settings via individual msmq nodes hosted by objects representing cluster nodes in Active Directory Users and Computers — after you enable “Users, Groups, and Computers as containers” and “Advanced Features” options in its View menu.
Keep in mind, however, that these objects represent MSMQ configuration associated with physical servers, rather than with virtual servers composed of clustering resources. Hence, they are not relevant within the context of this discussion. Note also that if you intend to incorporate MSMQ in external transactions, you must first create a Distributed Transaction Coordinator resource. For more information on its clustered implementation, refer to the previous article in this series.
Once you have finished setting up all desired components, launch Cluster Administrator pointing to one of cluster nodes, and select a group that will provide MSMQ functionality. The group must represent a virtual server, which implies that its content should include at least one Physical Disk containing the msmqstorage folder hosting any subsequently created queues and a Network Name (with its IP Address dependency) resources. There is no requirement, however, to co-locate it in the same group with the MSDTC resource. Next, run the New Resource wizard with Message Queuing as the Resource type and an arbitrarily chosen name, specifying possible owners and assigning both of its dependencies. A brief examination of the Properties dialog box of the resulting resource will reveal the configuration options are limited strictly to generic clustering settings. Thus, the management of its message queuing characteristics must involve either Computer Management or Active Directory Users and Computers console.
Since the first of these approaches requires a direct connection to the virtual server associated with our cluster group (which hosts the Message Queuing component), you might simplify your administrative tasks by adding the console as another of its resources. This is easily accomplished by leveraging capabilities of the Generic Application resource (discussed here). As indicated earlier, use the New Resource wizard, but select Generic Application entry in the Resource type listbox. Next, assign an arbitrary name and possible owners (these should be the same nodes that you selected before). Specify the Network Name and MSMQ resource as dependencies. On the “Generic Application Parameters” page of the wizard, configure entries according to the following list:
- “Command Line” textbox —
- “Current Directory” textbox —
- “Allow application to interact with desktop” checkbox — enabled
- “Use Network Name for computer name” checkbox — enabled
As the result, you will end up with an interactive instance of Computer Management console pointing to the virtual server as its target and running concurrently with the underlying MSMQ component, which it will then follow on every subsequent failover from one node to another. Complete the configuration by clicking Finish once you reach the “Registry Replication” page of the wizard.
Next: Managing MSMQ