BizTalk Server environments are normally as critical as the most critical system they integrate with; this normally means highly critical, in this scenarios high availability and disaster recovery are very important topics. If BizTalk is critical then the monitoring/operations software that looks after BizTalk environment becomes even more critical. Considering this we included support for … Continue reading High Availability and Disaster Recovery of BizTalk360
BizTalk Server environments are normally as critical as the most critical system they integrate with; this normally means highly critical, in this scenarios high availability and disaster recovery are very important topics. If BizTalk is critical then the monitoring/operations software that looks after BizTalk environment becomes even more critical. Considering this we included support for Disaster Recovery and High Availability out of the box starting from version 6.0 of BizTalk360.
High Availability of BizTalk360
To achieve high availability of any service we need to guarantee that each of the components in the solution is running at least in two machines (instances). For a BizTalk environment you normally need two BizTalk Servers and a two node SQL Cluster as shown in the below diagram.
For BizTalk360 the pre-requisites for achieving high availability are the same. I have represented this in a new diagram just to identify where the BizTalk360 components are installed. BizTalk and BizTalk360 can coexist in the same servers without any problem.
To setup the environment in a highly available fashion you could have BizTalk360 installed in at least 2 BizTalk Servers.
In version 6.0 of BizTalk360 we introduced a feature that helps setting up High Availability by allowing multiple instances of monitoring services running simultaneously. The internal logic within the monitoring service will do heartbeat/health check and make sure at least one instance of the monitoring service is running at any one point in time. Customers can take advantage of this features without any complex set up’s like Windows clustering.
BizTalk360 consist of 3 core pieces, the front-end web console, the middle tier monitoring service and the database to store configuration values and other events we collect like monitoring data. It’s important we look at HA at each level, so that all the components are secured.
Web Console HA
The web console is by nature highly available as long as it is installed in multiple servers, additionally to provide a sense of a single web console you should put a Network Load Balancer in front of all the BizTalk Servers and make access to them seamless (the same concept as for making a highly available receive location hosted in IIS).
Monitoring Service HA
The monitoring service is where the innovation in version 6.0 comes into play, this service is a regular windows service and you could obviously decide to use Windows Clustering to guarantee high availability. But since that can be quiet a complex setup with several implications in terms of hardware, setup and configuration we introduced this ability to allow only one monitoring service to execute against one BizTalk360 database, this in practice allows you to simply have to install the monitoring service in more than one server to guarantee high availability.
The database high availability and disaster recovery plans go as for any normal database, and you can host it in a SQL Cluster and use SQL Log Shipping to handle fast recovery.
Disaster Recovery of BizTalk360
Planning and delivering a disaster recovery scenario can be quiet challenging, when working at Microsoft I have only seen a hand full of customers doing all the recommended steps. The typical scenario in simple terms is like this, you will have a replica of your production system in your DR data centre. This includes the same amount of BizTalk Servers, SQL Servers and configuration. The process that guarantees that the disaster recovery environment is able to take over as the main environment is the log shipping process. Windows bare metal backups or maintaining up to date processing servers is what is used for the stateless layer of BizTalk.
You will have two SQL Clusters with 2 nodes each, one cluster is in the main data centre and the other one is in the DR data centre. When running in normal production 2 BizTalk Servers work off the primary SQL Cluster and BizTalk log shipping is in place to guarantee that backups are copied and restored automatically to the DR SQL Cluster and are able to provide a rapid recovery while at the same time providing a highly available environment.
In a case of disaster the plan says that the DR SQL Cluster where the BizTalk Log Shipping is configured to will become the main one as per the procedure
. The 2 BizTalk Servers at the DR site will be updated to use the new main SQL Cluster by applying the documented procedure. And up until now we are talking purely about BizTalk Server disaster recovery procedures.
So the question now is to understand how to setup BizTalk360 so that it fits in the overall DR plan described above. To address that we first need to understand what is BizTalk360 comprised of in simple terms. We have 3 core components to look after in a BIzTalk360 Disaster Recovery scenario:
- web console
- monitoring service
So in that unwanted day where you do have to apply disaster recovery or better yet on the day you are testing your disaster recovery plan what do you have to do?
So back to the scenario. All your assets are already in the DR site, the web console is installed in the 2 DR BizTalk Servers as well as the monitoring service (if this was not the case you could install them on any server on your DR site and the result would be the same) and your BizTalk360 database logs have been shipped to the DR site. What needs to be done first is making the BizTalk360 database online and ready by making the log shipping database the primary and followed by updating some reference data in BizTalk360 configuration files and the BizTalk environments table in case you are also applying DR to your BizTalk environment.
So here are the places you need to update:
- %ProgramFiles(x86)%\Kovai Ltd\Web\Web.config change the connection string to the BizTalk360 database
- %ProgramFiles(x86)%\Kovai Ltd\Service\BizTalk360.Monitor.exe.config change the connection string to the BizTalk360 database
- Use the SQL Server Management Studio to go to the BizTalk360 database and select the table b360_admin_BizTalkEnvironment for editing and update the location of the management database for the affected environments
After this BizTalk360 and BizTalk Server should all start running successfully in the DR site.
Quick recap, for BizTalk High availability:
- Install the web console and monitoring service in at least two servers
- Host your database in a SQL Server cluster
for Disaster Recovery
- use log shipping or simply restore from backup the BizTalk360 database
- Install the web console and monitoring service in a disaster recovery server
- Change the BizTalk360 reference data to point to your Disaster Recovery SQL Server
As you can see from this explanation high availability and disaster recovery for BizTalk360 are very easy to achieve. Just a word of advice, do plan for disaster and test your disaster recovery plans regularly.