An high available BizTalk infrastructure is strongly dependent on the underlying HA SQL Server infrastructure.
Nowadays, you can install HA SQL Server on Azure IaaS leveraging the AlwaysOn Availability Group feature but unfortunately this configuration is not supported by BizTalk. So we opted for the use of a third-party solution that allows us to create an SAN-less SQL Server Failover Cluster. In this session, we will walk through the main steps to create a BizTalk High Available infrastructure on Azure IaaS, the problems we faced and the numbers we collected.
High available BizTalk infrastructure on Azure IaaS
1. Sponsored & Brought to yo
High available BizTalk
infrastructure on Azure IaaS
Massimo Crippa & Salvatore Pellitteri
https://twitter.com/mas_que_crippa
https://be.linkedin.com/in/massimocrippa
https://twitter.com/pellittsa
https://it.linkedin.com/pub/salvatore-pellitteri/2a/184/719
3. Who are we?
Salvatore Pellitteri
Developer Team Manager @Msys
• MS Application Integration MVP
• SQL / BI / Integration Architect
@pellittsa
https//pellitterisbiztalkblog.wordpress.com
Massimo Crippa
Integration Architect @CoditCompany
• BizTalk D/I
• SOA and API Management
@mas_que_crippa
http://www.codit.eu/blog
5. Do or do not, there is no try
BizTalk Server virtual machines on Azure
DO NOT offer a High Availability solution when
using SQL Server Cluster.
https://msdn.microsoft.com/en-us/library/jj248689.aspx
7. High available – What?
• A system design approach and service implementation that ensures a level of
operational performance.
• Minimize the time that your service is down or unavailable.
8. High available – Why?
• Ensure the data availability
• Protect against HW and SW failure. The cost of downtime is rising
• Perform maintenance tasks in controlled way
• The HA cost is decreasing (if you’re not aiming to the five 9s)
9. High available – Where?
Physical Virtual Cloud
The cloud is convenient and it significantly reduce the time to productivity
Cloud
14. The main steps
Network Subnet
Availability
Set
Domain
SQL
Server
Cluster DataKeeper SQL Server MSDTC Client Access
BizTalk SSO
Configuration
BizTalk Setup
15. Azure IaaS – Subnets
• Setup virtual network
• Configure virtual network address spaces (subnets)
• Azure network and on-premises network interaction
• Static IP addresses
• VMs with multiple NICs
• Consider static IP addresses
16. Azure IaaS – Availability Set
You should ALWAYS specify an availability set when
creating more than one virtual machine for the same
purpose. AD-AVAIL-SET
Domain Controller
Domain Controller
SQL-AVAIL-SET
SQL Server
SQL Server
BT-AVAIL-SET
BizTalk Server
BizTalk Server
18. DataKeeper Cluster Edition
• At this moment Microsoft Azure
doesn't provides any storage
option that allow to build a
failover cluster.
• SIOS DataKeeper Cluster Edition
software is the key.
• Integration with failover cluster
service
20. SQL Server Installation
No special installation
1. Run cluster preparation on the first node
2. Run cluster preparation on the second node
3. Run cluster completion from one of the nodes
21. Client access setup
What normally occurs
Node 1 Node 2
Switch
DNS
1) Node 1 deregisters its mac
address on the switch
2) Cluster resources move
3) Node 2 registers its
mac address on the switch
4) Node 2 updates its IP on
DNS
22. Client access setup
• On Microsoft Azure you cluster service cannot interact with switches
• It is as if the IP addresses were active simultaneously on all nodes
• You have to configure an Internal Load Balancing (ILB)
23. Client access setup
Up to 150 configured ports per IP
• 1 port for SQL Server (1433)
• 1 port for RPC (135)
• 21 ports for SSO (Dynamic RPC)
• 44 ports for DTC (Dynamic RPC)
24. Client access setup
To complete:
• Configure the cluster
listener
• Fix MsDtc dynamic ports
# This script should be run on the primary cluster node after the internal load balancer is created
# Define variables
$ClusterNetworkName = "Cluster Network 1" # the cluster network name
$IPResourceName = "SQL IP Address 1 (BTLABSQLCLU)" # the IP Address resource name
$CloudServiceIP = "10.0.0.250" # IP address of your Internal Load Balancer
Import-Module FailoverClusters
Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple
@{"Address"="$CloudServiceIP";"ProbePort"="59999";
SubnetMask="255.255.255.255";"Network"="$ClusterNetworkName";"OverrideAddressMatch"=1;"EnableDhcp"=0}
25. Enterprise SSO Setup
Clustered configuration of EntSSO master secret server
• Procedure is not simple
• Follow the article “https://msdn.microsoft.com/en-us/library/aa561823.aspx”
• Set "Use Network Name for computer name“ (not mentioned!)
26. BizTalk Setup
• Standard setup procedure
• All you need is described on “http://www.microsoft.com/en-
us/download/details.aspx?id=35552”
29. Test scenario
SQL Server nodes
• 7GB RAM
• 4 core
BizTalk Server nodes
• 7GB RAM
• 4 core
BizTalk Test Scenario
Domain Controller 1
SQL Server + SSO
Cluster Node 1
SQL Server + SSO
Cluster Node 2
BizTalk Server 1 BizTalk Server 2
30. Test scenario
BizTalk solution
1) Schemas generation
2) Debatching for the input schema
3) Each orchestration instance execute
an insert on a SQL table
4) Submit input file instance that
generates 1000 and 10000
orchestration instances
33. Takeaways
• Does it works? Yes!
• Support > No (Not yet) > Come on MSFT!!
• Datakeeper Support > Yes !! (http://www.sys-con.com/node/3320313)
• What’s next ?
https://support.microsoft.com/en-us/kb/2721672
After publishing the article, some have asked me information about performance of DataKeeper, so I thought it would be interesting to include this slide in this presentation.
From the performance point of view, DataKeeper synchronous mirroring is going to add less than 20% overhead in terms of write throughput.
This slide shows a test run with three different configurations.
First without any replication technology, then using DataKeeper and finally activating SQL Server Always On availability group.
Without any replication technology, the platform has performed over than 1 million inserts per second.
The same job with DataKeeper sync turned on was doing over 900,000 inserts per second.
In comparison, when they turned on Always On Availability Group they could only get less than 300,000 inserts per second. This is obvious if you think Always On Availability Group implements a communication very intense at the application level.