Hi,

We have a 2 BT , 1 SQL configuration for the BizTalk Environment. BizTalk 2013 VMs and SQL 2012 VM provisioned from the gallery.  Since there is a limitation on having a highly available SQL tier (for BizTalk) on Azure, we are evaluating a possible replacement of the Azure setup with a on-premise setup which will guarantee highly available environment(as the SQL tier will be highly available too and with the SSO service). Wanted to know your thoughts on the below topics.

1) Is the BizTalk 2013 Azure (IaaS) used widely in production scenarios today (given the limitation for HA). If yes, what could be the mitigating solution

2) Is the roadmap for Microsoft (BizTalk Server related) going to address this scenario. 

Appreciate your inputs in this regard which would help us to make an informed decision to switch back to on-premise.

Thanks,

The biggest driver here is the time frame of the SLA you need to meet.

If it's measured in seconds to a few minutes, then a tightly managed on-prem solution using Windows Clustering and multiple BizTalk Hosts computers is still the way to go since it provides the fastest fail-over and most granular control.

However, if your SLA is more flexible, say 10-15 minutes...ish, an Azure setup will likely meet all scenarios.  This is through a combination of Windows recovery features and Azure Availability Groups.

There are some very narrow cases that aren't too well addressed using the standard tools, but in practice, they just don't happen anymore.

Theoretically since SQL Always-ON or database mirroring is not supported with BizTalk, SQL Server Azure virtual machines do not support Failover Cluster Instances.

But ensure by selecting Availability Set your virtual machine will be deployed to different fault domains and update domain thus ensuring that your application is available during network failures, hardware failures, and any planned downtime. This increases the case of server/service high availability. And with these features unavailability of the server in Azure is very less.

But if youre one of those customers you still want to ensure they dont let any chance of failure (or dont afford for any failure) and still look to implement failover Cluster Instances, then simple answer is SQL Server Azure virtual machines do not support Failover Cluster Instances. If you ask about mitigation plan, then ensure you have selected Availability Set while provisioning the servers.

To answer to you couple of specific questions:

1) Is the BizTalk 2013 Azure (IaaS) used widely in production scenarios today (given the limitation for HA). If yes, what could be the mitigating solution - Ican't answer BizTalk as Iaas is widely used, this question has to be asked to Microsoft directly. And regarding the mitigation plan, as mentioned provisional your server across fault domains and update domain minimize the down time or increases the high availability.

2) Is the roadmap for Microsoft (BizTalk Server related) going to address this scenario.   -  As of now SQL Always-ON or database mirroring are not supported for BizTalk and roadmap remains same.

Thanks for your inputs John.

During the Azure outage on Novemebr 19, 2014 many of our Azure servers crashed irreparably. Microsoft support informed us that we need to spin up new servers as they could not recover the crashed ones. With this incident, we are a bit wary on having the setup on Azure (IaaS).

Regards,

Ujjwal

Hi Ashwin,

Thanks for your inputs. We have used Availability sets. But when there is a downtime on a SQL server, then the whole BizTalk environment will be down as there is only a single machine for SQL. Hence availability set truly doesnt provide 'high availability' for the SQL tier.

Regards,

Ujjwal

Hi Ujjwal,

I hope lesson would have learnt during Azure outage like that of Novemebr-2014. for something like this I would consider that similar to failure of the server farm and switch to disaster recovery (DR) servers.

As SQL Server virtual machines on Azure for BizTalk do not support Failover Cluster Instances, only option to increase the high availability is by ensuring that the servers are provisioned across fault domains and update domain by selecting Availability sets.

But when there is a downtime on a SQL server As said downtime of a SQL server with Availability sets is very minimal (still possible, but less) and these are only supported option as of now. And if you cant afford/foresee managing your integration during that downtime then Iaas is not the option for you at least as of now.

During the Azure outage on Novemebr 19, 2014 many of our Azure servers crashed irreparably.

I was not aware of that, but such an event can happen on-prem as well.  Were they in Availability Sets?

One way to address that specific problem would be having a 'backup' cloud service in another Azure Data Center.

Hi John, 

No, at the time of the Azure outage, they were not in the availability set. But after the outage, we lost one of the PROD servers. We spun up a new server, installed the applications and then put the servers on availability set.

Yeah, like you've pointed out, we are planning to have a DR environment on Azure.

Regards,

Ujjwal

Hi Ashwin,

W.r.t HA, SQL still is a single point of failure in the current Azure BizTalk (IaaS), as even if you put your SQL machine on an availability set, there is no automatic failover unliek the BizTalk tier which which failover to a large extent to continue message processing on the alive Node.

Having said that, it would be great to see Microsoft's roadmap to address this limitation as such for BizTalk 2013 IaaS.

Regards,

Ujjwal

Hi Ashwin,

W.r.t HA, SQL still is a single point of failure in the current Azure BizTalk (IaaS), as even if you put your SQL machine on an availability set, there is no automatic failover unliek the BizTalk tier which which failover to a large extent to continue message processing on the alive Node.

Having said that, it would be great to see Microsoft's roadmap to address this limitation as such for BizTalk 2013 IaaS.

HI Ujjwal,

I think you can also get help from Microsoft support (http://support.microsoft.com/) directly,

open up a case with Microsoft Support  http://support.microsoft.com/ they can help with the issues.

Microsoft support engineers will evaluate it seriously, and they will give positive response about this issue.

Best regards,

Angie

W.r.t HA, SQL still is a single point of failure in the current Azure BizTalk (IaaS), as even if you put your SQL machine on an availability set

Well, yes and no.

Considering the types of failures that happen, the significant majority are covered by Azure either by default or with the addition of Availability Sets so the databases are not a traditional 'single point of failure'.

I still maintain that the most significant difference is the recovery time in that an on-prem Windows Cluster will recover very quickly while a failure on Azure may take time in the minutes.  That can be a deal-breaker for some SLA's, but not all.  The situation is essentially identical to using Hyper-V Failover instead of Windows Clustering.

For some perspective, over the past several years, I'd say 80-90% of failure on the database level have been failure at the storage/SAN layer, meaning not the hardware, not Windows and not SQL Server.

W.r.t HA, SQL still is a single point of failure in the current Azure BizTalk (IaaS), as even if you put your SQL machine on an availability set

Well, yes and no.

Considering the types of failures that happen, the significant majority are covered by Azure either by default or with the addition of Availability Sets so the databases are not a traditional 'single point of failure'.

I still maintain that the most significant difference is the recovery time in that an on-prem Windows Cluster will recover very quickly while a failure on Azure may take time in the minutes.  That can be a deal-breaker for some SLA's, but not all.  The situation is essentially identical to using Hyper-V Failover instead of Windows Clustering.

For some perspective, over the past several years, I'd say 80-90% of failure on the database level have been failure at the storage/SAN layer, meaning not the hardware, not Windows and not SQL Server.

• Marked as answer by Angie xuMicrosoft contingent staff, Moderator 8 hours 54 minutes ago