Win 2003 High Availability Solutions, Message Queuing

Thursday Jan 24th 2008 by Marcin Policht

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.

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.

Discuss this article in the ServerWatch discussion forum

Unsure About an Acronym or Term?
Search the ServerWatch Glossary

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 — mmc compmgmt.msc
  • "Current Directory" textbox — %windir%system32
  • "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

Managing MSMQ

Discuss this article in the ServerWatch discussion forum

Unsure About an Acronym or Term?
Search the ServerWatch Glossary

To manage a clustered instance of MSMQ with Active Directory Users and Computers, you must ensure its Network Name resource has the "Enable Kerberos Authentication" setting (on the Parameters tab of its Properties dialog box) turned on. This will not only automatically create a computer account representing the virtual server in Active Directory, but it will also generate its msmq subnode as soon as the MSMQ resource is brought online. Although the Cluster Service automatically handles these activities, by default, its account is allowed (by virtue of having the right to "Add workstations to domain," just like any regular domain user) to repeat them only 10 times. To eliminate this restriction, the account must be granted the privilege to "Create Computer Objects" as well as posses sufficient permissions in the Active Directory container where new objects are placed.

If you intend to implement an MSMQ Triggers component, start by installing it using the Add or Remove Programs Control Panel applet (described earlier) on every cluster node. Once this initial step is completed, the MSMQ Triggers resource type will automatically appear as a new resource type in the list of options of New Resource wizard. Launch the wizard within the context of the cluster group that hosts previously created MSMQ resource, select it from the list, and specify its name. Complete the creation by choosing the same possible owners as before and its dependencies, which include the MSMQ resource and its associated Network Name. This arrangement ensures that triggers will continue providing services to the MSMQ component running on the virtual server following a failover.

Unlike with the MSDTC, which is limited to a single instance per cluster, it is possible to have multiple, simultaneously running independent MSMQ resources on the same cluster. Each of them should reside in a separate group; however, if you decide to introduce such an arrangement, you might need to adjust the memory management mechanism on each node (to avoid problems described in the MS Knowledge Base article 940960), by increasing the system view space memory pool size (designating kernel memory dedicated for message queuing support). This involves creating SystemViewSize entry of DWORD data type under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management registry key, with the value derived by adding 16 (representing the default pool size of 16 MB) to the outcome of multiplying 4 (equivalent to 4 MB of the memory pool required by each MSMQ instance) by the total number of MSMQ cluster resources.

When working with MSMQ clustered resource, the same general principles that apply to its standard, non-virtual equivalent must be followed. For example, you can use the MSMQ node in our Generic Application-based Computer Management console to interact with existing system and application queues, create new public and private ones (referenced using the NetworkNameQueueName and NetworkNameprivate$QueueName notation, respectively), examine their content, and configure such parameters as routing or security.

This concludes our overview of various resource types available in Windows Server 2003 based clustering implementations. Next, we will discuss generic properties of cluster groups and their resources, which have significant impact on failover or failback behavior.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved