I recently went through my second implementation of BizTalk360 and ran into a feature that I wasn’t previously aware of. Typically I have installed BizTalk360 on a BizTalk Server itself which posses a bit of a risk if you only install it on one BizTalk Server and that BizTalk Server happens to be offline.
My current environment consists of a multi-node cluster (an actual cluster with Failover Cluster Services). I recently asked the question to Saravana Kumar if this was the way to go when looking for a redundant monitoring solution. He indicated that my idea would work and is completely supported however I may want to look into a new feature called Monitoring Service High Availability. When using this feature, BizTalk360 itself is maintaining its state by storing it in the database. In my case, One node will be active and the second node will be passive – much like a service being managed by Windows Failover clustering.
To access this feature click on the Settings link in the top right hand corner of the screen.
Next, click on the Monitoring Service High Availability link.
Even though the BizTalk360 Service is actively running on both Servers (in my case), BizTalk360 is designating one of the servers as being the primary.
We have the ability to change the primary server by selecting it and then clicking on the Bring Server Active button.
Instantly our primary will switch to becoming a secondary and vice-versa. This was very quick. Much quicker than I have experienced failing over a service using Windows Failover Clustering.
The next test is to take our primary Service (or Server Offline). To do this I will just stop the BizTalk360 service. By doing so I am simulating what would occur if our service stopped or we lost our entire primary server. To make this test even more real I am going to enable a test alert, make sure I receive the first alert and then stop the BizTalk360 Service. My expectation is that my second node will become primary and I should receive another test alert. This time the alert will be generated from the newly activated node.
Below I have configured an existing alarm to function in TEST MODE.
I have received my alert as expected.
I will now stop the BizTalk360 Service on Node 1.
If I navigate back to the Monitoring Services High Availability screen I find that my “Node 2” is now the active server and my “Node 1” is no longer participating as it is offline.
If I check my inbox, I find that I continue to receive these “TEST Alerts” from BizTalk360. This time the alerts are coming from my 2nd Node.
If we now go back to my 1st Node and start the BizTalk360 Service, we will discover that BizTalk360 has recognized that the service is back online but is in a passive state.
Conclusion
I have been around Windows Fail-over Clustering for quite some time and am comfortable working within that environment. The BizTalk environments that I have used in the past also tend to leverage Windows Failover Clustering in order to support Cluster Host Instances for adapters such as S/FTP, POP3 and Database Polling. Using Windows Failover Clustering is an option for ensuring BizTalk 360 is online and redundant, but it is not a pre-requisite. As I have demonstrated in this post; BizTalk360 provides this functionality out of the box. This is great news, especially for those who have multi-node BizTalk environments but do not have (or need) Windows Failover Clustering. This allows you piece of mind in the event one of your BizTalk Servers goes offline, that you can have BizTalk360 installed on another node your coverage will not be interrupted. Kudos to the BizTalk360 team for building such an important feature and making it very easy to use!
