I was recently approached by a client about what options they had for configuring BizTalk across their global enterprise. They really wanted to avoid idle servers and spread their processing load over their global enterprise as much as possible. They also wanted to have failover capabilities in case they lost their primary datacenter.
I thought a lot about this and had some ideas, but it was immediately clear to me that ultimately SQL Server is the critical point of failure in a BizTalk deployment. I've used a few approaches in the past to address this, such as the typical Log Shipping method that is outlined in the BizTalk documentation, but I wanted to push further.
As I thought about the options for this particular situation I reach out to Tim Wieman, one of the extremely knowledgeable BizTalk guys at Microsoft, for advice. Tim outlined four major approaches; three of which I was aware of and one that was new and quite innovative. Further he outlined them much more elegantly than I had been able to.
Log Shipping to Warm Standby
This approach is the most traditional for BizTalk and the one I have used most often. The spare servers are certainly a cost and the downside is that the lag time between the log shipping can result in lost data. The plus side is that it is quite simple, very widely used and understood, and can have you up and running again in a very short time (certainly within the uptime requirements of the vast majority of enterprises).
Independent BizTalk Groups
This approach involves having two separate BizTalk Groups, each doing some processing, for separate applications. They don't run the same sets of applications (but they can if you want to do load balancing through another mechanism) which means that they are both slightly underutilized, but this is probably the best option for a lot of shops. If you include load balancing from a hardware option you get the added benefit of getting full utilization of your infrastructure. There are some downsides, however. For one your tracking data may need to be aggregated from the two groups. If your tracking doesn't have as stringent of uptime requirements I think you might be able to apply the same tracking profile in each group and be able to avoid the aggregation step.
Geographically separated servers in the same group
This is one potential approach and I have heard of it being done. The real downside is the latency between the BizTalk servers and the SQL Server running the databases. This can be solved by high speed dedicated links (the only time I saw this used the two datacenters were actually in the same city). The weak link here though is the SQL Server. Lose your SQL Server and you've lost BizTalk for the most part. If your connection is fast enough, however, you can log ship across it and get some pretty good redundancy.
BizTalk Database Stretch Failover Cluster
Also known as a Geo-Cluster this approach addresses the core issue of BizTalk geographic redundancy directly, the SQL Server. This is the option I had not really heard of before. The key to this is SAN mirroring, which must be synchronous and support atomic synchronous writes. This is a very expensive approach as it requires both fast networks (fiber speeds) and vendor specific mirroring features in your SAN. I was extremely interested in this approach and looked into it more to find that iSCSI is one way in which this is performed by some SANs.
The remote SAN would have its own database server in the remote datacenter you would also put some BizTalk servers in your Group in the redundant location. This remote SQL Server would be a passive node in the cluster. The BizTalk servers need not be running (as in Host Instances started) before the cutover and you could use either SCOM or some other monitoring solution to enable those servers when the cluster fails over (or even windows cluster). This does represent the ultimate in failover capability with a minimum of down time, but as previously mentioned it would be very expensive. There would also be some time required to determine the right failover settings for the cluster so as to avoid false failovers.
I definitely have more work to do in this area and hope to write more about it in the future, but there is at least one more option than I hadn't thought too much about. The SAN failover also raises the possibility of redundant SAN in a single location (or a nearby datacenter) and this raises some great possibilities for customized solutions.
Subscribe