Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Nine Tips to Enterprise-proof MSMQ : Page 3

MSMQ is a transformational development tool, but it's not without reliability and performance problems. Help enterprise-proof your MSMQ installations with these nine tips.


advertisement
Increasing Reliability
The preceding section discussed MSMQ availability only in cases where higher availability is a factor in increasing performance. This section describes several other ways of making an MSMQ messaging platform more reliable. The following tips don't involve changes to code, but are very useful ways of making MSMQ a more reliable messaging platform. Tip 7: Avoid Active Directory and Public Queues
When using MSMQ with public queues, the local MSMQ service communicates with the MSMQ directory service running on one of the AD domain controllers—the directory service catalogs settings for all the public queues in the domain. In my experience, there are countless problems with the directory services becoming inoperable—and that prevents access to the public queues (You just have to hope your applications aren't using the queues when this happens). In contrast, private queues do not interact with the domain-wide directory service; only the local MSMQ service knows about the private queue. As such, you must reference private queues using direct format names.

Another problem with when using MSMQ with AD integration is that the local MSMQ service cannot start when it is unable to reach one of the domain-wide directory services. This is true even if you aren't using any public queues. To fix this problem, elect to install MSMQ without Active Directory integration during the install process of MSMQ. If you are trying to increase the availability of your MSMQ installations, I generally recommend using direct format names with private queues after installing MSMQ without Active Directory integration. You will be thankful you chose this route. Unfortunately, my experience has been that even when you install MSMQ without Active Directory integration, as recommended above, public queues and AD integration functionality returns. While Microsoft Support has not confirmed this behavior, I have witnessed it on several occasions. A recent call to Microsoft revealed a registry key apparently specifically intended to prevent issues of this nature—it prevents MSMQ from using AD integration. To add this value to your registry, add a DWORD entry named AlwaysWithoutDS under the subkey: HKEY_LOCAL_MACHINHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ \Parameters\Setup. Set the value to 1. Adding the key should prevent MSMQ from ever attempting to use AD's Directory Services functionality and will lead to a more stable MSMQ installation.

Tip 8: Clustering and Load-balancing MSMQ
Using Microsoft's Windows Clustering tool, queues will failover from one machine to another if one of the queue server machines stops functioning normally. The failover process moves the queue and its contents from the failed machine to the backup machine. Microsoft's clustering works, but in my experience, it is difficult to configure correctly and malfunctions often. In addition, to run Microsoft's Cluster Server you must also run Windows Server Enterprise Edition—a costly operating system to license. Together, these problems warrant searching for a replacement. One alternative to using Microsoft's Cluster Server is to use a third-party IP load-balancing solution, of which several are commercially available. These devices attach to your network like a standard network switch, and once configured, load balance IP sessions among the configured devices. To load-balance MSMQ, you simply need to setup a virtual IP address on the load-balancing device and configure it to load balance port 1801. To connect to an MSMQ queue, sending applications specify the virtual IP address hosted by the load-balancing device, which then distributes the load efficiently across the configured machines hosting the receiving applications. Not only does this increase the capacity of the messages you can process (by letting you just add more machines to the server farm) but it also protects you from downtime events caused by failed servers.



To use a hardware load balancer, you need to create identical queues on each of the servers configured to be used in load balancing, letting the load balancer connect the sending application to any one of the machines in the group. To add an additional layer of robustness, you can also configure all of the receiving applications to monitor the queues of all the other machines in the group, which helps prevent problems when one or more machines is unavailable. The cost for such queue-monitoring on remote machines is high (it's almost always more efficient to read messages from a local queue) but the additional level of availability may be worth the cost. Tip 9: Set Message Store Quotas

 
Figure 4. Setting Message Store Quotas: Windows 2000 Server instructions describe how to enable a machine quota to limit the size of the MSMQ messages store.
MSMQ has limitations is limited in on the number and size of the messages it can store on a machine. In most instances, MSMQ versions 1.0 and 2.0 can store no more than about 1.6 GB of messages on a machine. There are ways of overcoming this size limitation, but the your main goal should be to protect MSMQ from problems that arise when the message store size exceeds the amount of space allowed on the machine. When that happens, using a standard MSMQ installation, the MSMQ service will become unresponsive and, if stopped, will not start.

Using machine quotas, you can set a limitation on the size of the message store (see Figure 4 for instructions on configuring a quota for this purpose). Setting such a limit prevents The limitation will prevent MSMQ from receiving any messages until adequate storage space becomes available—the messages queue up on the sending machine. While this does not solve the problem in a way that makes your application more reliable, it helps makes MSMQ more stable in such circumstances. With MSMQ still running, you can purge queues or retrieve messages from queues on the machine until the message store has returned to a manageable size. MSMQ is an amazingly flexible tool that can provide reliable message queuing, but like any other tool, proper configuration is essential in reaching acceptable performance and availability goals. The suggestions in this article cover only a fraction of the tunable characteristics of MSMQ. If you begin using MSMQ at an enterprise level, I encourage you to browse the additional resources listed in the Related Resources section of this article.



Michael S. Jones is the Director of Systems Architecture for Passport Health Communications, Inc., a national healthcare technology provider connecting hospitals, physician clinics and outpatient centers with payer and patient information to facilitate and improve their revenue cycle process. Michael, his wife, and three children live in Franklin, Tennessee where he spends his spare time reading and enjoying time with his family outdoors. .
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date