High available BizTalk infrastructure on Azure IaaS
Download as PPTX, PDF0 likes3,243 views
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.
Ad
More Related Content
What's hot (20)
Viewers also liked (17)
Ad
Similar to High available BizTalk infrastructure on Azure IaaS (20)
Ad
More from BizTalk360 (20)
Recently uploaded (20)
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
- 2. High Available BizTalk on Azure IaaS #IntegrationMonday
- 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
- 4. Agenda A. High availability WWW B. Scenarios C. Procedure D. Demo E. Tests and Conclusion
- 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
- 6. The WWW of HA
- 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
- 10. Scenarios
- 11. Mini and Micro SAN-less solutions Two scenarios
- 12. Who is the culprit? AZURE IaaS >> Disk resource Why not Always On AG ? >> MSDTC > it’s the blocking problem
- 13. How to
- 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
- 17. Failover Cluster • Two NICs or not ? • Cluster quorum configuration
- 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”
- 27. BizTalk HA on Azure IaaS
- 28. Some tests
- 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
- 31. Test results
- 32. Key takeaways
- 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
- 34. Thank you!and may the Force be with you
Editor's Notes
- #20: 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.