Availability, Scalability and DR for BizTalk Server


Recently, I had to talk to a customer of mine explaining setting up of optimal BizTalk infrastructure. It was almost a 101 conversation regarding BizTalk Availability, Scalability and Disaster Recovery. That’s when I realized that there is not really a unified a concise view of these concepts anywhere on the Internet. Here a stab that I took at it for a really short, crisp, 5 minute view of the topic.

 

BizTalk Server comprises of the front end application servers that perform the processing and the backend SQL Servers that hold the in-flight messages and configurations for the server. In order to ensure a highly available solution, both these tiers need to be considered.

 

High Availability

SQL Server tier

The high availability at the database tier can be achieved by using SQL clustering and is very standard in terms of configuration. The below link explains this in details. http://msdn.microsoft.com/en-us/library/aa559920.aspx

 

BizTalk Server tier

This link discusses the BizTalk Groups feature in further detail. http://msdn.microsoft.com/en-us/library/aa559010(BTS.70).aspx

Secondly, the BizTalk Server tier can constitute of multiple “Hosts”. The BizTalk Hosts run as windows services and allow segregating the processing of different logical components in the solution. Hence allowing process and memory separation on the server for these different solution components. These hosts can reside on multiple servers within the group hence inheriting the high availability features provided by the groups.

In certain cases, the hosts cannot run on multiple groups – for instance a host that is responsible for running ports that receive file inputs from FTP. In this case, if the host is running on multiple servers, all the servers will be trying to get the same resource (file). In order to avoid such scenarios, the hosts can be clustered in active/passive mode. The below links discuss more about Hosts and their clustering.

 

Scalability

Scaling of BizTalk servers can again be done on either the SQL tier or the BizTalk Server tier depending on where the bottlenecks are present in a given infrastructure. The BizTalk message box is usually the most used database and that can be scaled by adding multiple message box databases as detailed on this link  (https://msdn.microsoft.com/en-us/library/cc296848(v=bts.10).aspx).

Scaling for the BizTalk Server tier essentially means adding a new BizTalk server to the group so that it can start sharing the load immediately. This can be done without bringing down any of the existing servers in the group. Also, we can choose to configure only selected hosts on the new server. Hence ensuring that we augment the capacity only at the place where it is absolutely required in the solution.

 

Disaster Recovery

The BizTalk databases form an important part of disaster recovery since they hold all the in-flight messages. BizTalk server provides its own log shipping routines that allow log shipping the BizTalk databases to be replicated on the DR site. This link provides more information on the same. (https://social.technet.microsoft.com/wiki/contents/articles/5363.biztalk-server-disaster-recovery.aspx)

Comments (2)

  1. Nickolay says:

    Hi,
    Most of the links are leading to nowhere.
    Can you please update links?

    1. SanketBa says:

      Thanks for pointing it out. Most of the links were old and removed from MSDN. I have updated these with the new relevant links.

Skip to main content