October 2011 Blog Posts


EDIT 11/10/2011 I only posted this yesterday but I wanted to fix up some possibly confusing/misleading statements.

One of the problems we see with BizTalk Enterprise build outs is that in some scenarios and with some limitations there is no out of the box way to get complete High Availability if you don’t have a hardware load balancer.  For example, if you have BizTalk webservices you’ll want NLB. If your don’t have a hardware load balancer in the datacenter you’ll install Windows NLB on IIS. Ok great, but now that you have Windows NLB installed on the BizTalk nodes, you won’t be able to cluster the BizTalk hosts which run the FTP, SMTP, MSMQ or Database readonly extract  receive locations. If you have two active hosts receiving using any of those, you will end up with duplicate messages. The above assumes that you have only two BizTalk Enterprise nodes, not four. If you had four (or more), you could Windows NLB two nodes, and cluster two nodes.

We have a product that solves this conundrum. http://www.burch.com.au/home/Products

Due to unavoidable limitations in the protocols, the BizTalk adapters for FTP, POP3 and MSMQ require Microsoft Clustering Services to achieve high availability and avoid the processing of duplicate messages. There are two drawbacks to this.

1. The complexity of configuring and maintaining Microsoft Clustering Services on the BizTalk nodes.

2. Microsoft Clustering Services cannot coexist with Windows Network Load Balancing (NLB).

Burch Consulting offers an alternative.

The BTS Monitor and Failover Service is a product that removes the need to cluster the BizTalk Server nodes whilst still achieving full redundancy. It works like this: A windows service monitors the primary node A and turns on the failover host (containing the FTP/POP3 receive locations) on Node B in case of failure on Node A. This windows service ensures that only one node is ever processing FTP/POP3 messages and ensures high availability in case of failure. Because this utility allows only one node to be active, the possibility of receiving duplicate messages is removed. This windows service runs actively on both nodes concurrently to provide high availability to the failover process.

In addition to the above mentioned protocols this component can provide HA for database (SQL Server or Oracle) receive locations which perform READ ONLY data extracts.