BizTalk Server with SQL Server AlwaysOn
•Als PPTX, PDF herunterladen•
1 gefällt mir•2,303 views
This document discusses connecting BizTalk Server to SQL AlwaysOn databases and building a highly available BizTalk Server 2016 environment using SQL Server 2016 availability groups. It begins with an overview of SQL AlwaysOn databases and how they provide high availability and disaster recovery. It then covers how to connect BizTalk Server to an AlwaysOn database using the WCF-SQL adapter and inline SQL. The remainder discusses building a BizTalk Server 2016 highly available environment in Azure using SQL Server 2016 availability groups.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie BizTalk Server with SQL Server AlwaysOn
Ähnlich wie BizTalk Server with SQL Server AlwaysOn (20)
Mehr von BizTalk360
Mehr von BizTalk360 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
BizTalk Server with SQL Server AlwaysOn
- 1. BizTalk Server with SQL Availability On Databases Mark Brimble /brimblemark https://nz.linkedin.com/in/markbrimble
- 2. BizTalk Server with SQL Server AlwaysON Mark Brimble © Datacom 2017 2
- 3. © Datacom 2016 3
- 6. © Datacom 2016 6
- 7. Premises for this talk BizTalk Server can connect to SQL AlwaysON databases in some scenarios. Highly available BizTalk Server 2016 can be built using SQL 2016 availability groups.
- 8. Questions © Datacom 2016 8 • What are SQL AlwaysOn databases? • How do you connect to SQL AlwaysOn databases using BizTalk Server? • How do build a BizTalk 2016 Server to use SQL 2016 availability groups
- 9. What are SQL AlwaysON databases? Disasters happen 9
- 10. What are SQL AlwaysON databases? © Datacom 2016 10
- 11. SQL AlwaysON vs Traditional Failover Cluster © Datacom 2016 11
- 12. How do you connect to a Always On Database ? BizTalk Server WCF-SQL Adapter
- 13. How do you connect to a Always On Database ? BizTalk Server WCF-SQL Adapter "System.Transactions.TransactionManagerCommunicationException: Communication with the underlying transaction manager has failed. ---> System.Runtime.InteropServices.COMException: The MSDTC transaction manager was unable to push the transaction to the destination transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers.”
- 15. Idempotent HTTP Method Idempotent OPTIONS yes GET yes HEAD yes PUT yes POST no DELETE yes PATCH no © Datacom 2016 15
- 16. How do you connect to an Always On Database ? In Line SQL Provider=SQLOLEDB;Server=A_LSTN;database=Flights;Integrated Security=SSPI; UserId = <UserName>; Password=<Password>; ApplicationIntent=ReadOnly
- 18. BizTalk 2016 HA with SQL 2016 HA with SQL Availability groups Demo Building BizTalk 2016 HA environment in Azure © Datacom 2016 18
- 19. SQL Server 2016 AlwaysOn support • New for BizTalk 2016 • Provides supported multi-node BizTalk deployment in Azure • Modern, consistent HA/DR capabilities • No more log shipping or active/passive clustering as HA solution © Datacom 2016 19
- 22. Building BizTalk 2016 HA environment in Azure SQL Server 2016 in Azure now supports multiple IPs over one ILB The documentation is not correct.
- 23. Building BizTalk 2016 HA environment in Azure Building the SQL Listener
- 24. © Datacom 2016 24
- 25. © Datacom 2016 25
- 26. © Datacom 2016 26
- 27. © Datacom 2016 27
- 28. © Datacom 2016 28
Hinweis der Redaktion
- In this talk we are going to tell you how you can use BizTalk Server with SQL Server AlwaysON databases.
- BizTalk has been our integration tool of choice for the last 12 years Colin and I have written a book about it.
- I love BizTalk and for many years I have written blogs about integration.
- BizTalk Server can be used with SQL 2016 Always On database.
- The Always On Availability Groups feature is a high-availability and disaster-recovery solution first introduced in SQL Server 2012. This is an alternative to traditional failover clustering, database mirroring or log-shipping.
- The Always On Availability Groups feature is a high-availability and disaster-recovery solution first introduced in SQL Server 2012. This is an alternative to traditional failover clustering, database mirroring or log-shipping.
- In our simple example let’s consider a flights database that we want make highly available with DR. For SQL AlwaysOn you create an availability group that enables data synchronization between the primary flights database and the secondary flights database. If it is synchronous then if a transaction occurs it must be committed to the secondary flights database before it is committed to the primary database. A SQL listener must be created some that clients do not have to know whether a failover has occurred. Additionally secondary databases can be made available for read-only access.
- To provide high availability for the BizTalk Server databases, use Windows Server Failover Clustering to configure two database computers that are running SQL Server to create a server cluster. One is active and the other is passive. The Enterprise Single Sign-On master secret server is also clustered so that if a failover occurs the it moves as well. In addition with this option you have to set up log shipping to another SQL Server to achieve disaster recovery.
- Can I use a BizTalk WCF-SQL send adapter with a SQL 2012 Always on Database? I think the answer is no unless you are prepared to accept the risk of duplicates and/or lost messages. Let me explain why.
- When BizTalk Server and SQL Server are installed on separate computers and you are using the WCF-SQL adapter, it is recommended that you use a Distributed Transaction Coordinator (MS DTC) to handle the transactions between the computers. SQL Server 2012 and 2014 AlwaysOn feature does not support MSDTC transactions. “Cross-database transactions and distributed transactions are not supported by AlwaysOn Availability Groups or by database mirroring. This is because transaction atomicity/integrity cannot be guaranteed.
- Wow! That means if I enable MSDTC on a SQL2012 database that uses availability groups it does not work. If MSDTC cannot be turned on then the WCF-SQL adapter cannot use MSDTC ( i.e. you must set the useAmbientTransaction to false.). How safe is that? Most of the experts say don’t do it. If you do do it you, I think you must have logic that is able to handle duplicates so you can always send again. You must ensure that your SQL transaction is idempotent and I don’t know how to test if this is safe. At the end of the day I think your safest choice is not use the SQL Availability On with the BizTalk WCF-SQL adapter. In summary I think your choices are (in order of preference): – Disable AlwaysOn Availability Groups / Mirroring on SQL server if you need to connect to this SQL server which has this enabled – Disable transactions and implement logic to be able to handle duplicates . – Disable transactions and handle the duplicates or lost messages with custom logic (e.g. Send twice and compare and implement error handling). You need to write your own DTC handling this which is probably very complicated. – Disable transactions and live with risk of duplicates or lost messages without handling duplicates. What do you think?
- “denoting an element of a set which is unchanged in value when multiplied or otherwise operated on by itself”
- The SQL call is in a C# library. This is called from an expression shape in an orchestration.
- In the final part of the talk I will focus on what I think is one of the most important improvements in BizTalk 2016 namely high availability improvements with SQL 2016 availability groups.
- BizTalk for a long time has had a dependency on active-passive clustering of SQL and log shipping to meet high availability and disaster recovery requirements. This has hindered deployment of production instances of BizTalk Server to Azure because active-passive SQL clustering is not supported. This release enables you to use SQL 2016 Availability Groups to achieve HA and DR without active passive clustering or log shipping. Let’s start by looking at the SQL Server 2016 architecture that I built to show you the HA possibilities of SQL server 2016.
- Deploying Always on Availability groups requires six things; 1. Windows 2012 R2 (KB3090973) or Windows 2016 Servers with Failover clustering. 2. SQL 2016 3. 4 Instance (on premises) 4. Primary and Secondary replica 5. AG with MSDTC & Listener 6. Modification SQL agent jobs
- Deploying Always on Availability groups requires six things; 1. Windows 2012 R2 (KB3090973) or Windows 2016 Servers Failover clustering. 2. SQL 2016 3. 4 Instance (on premises) 4. Primary and Secondary replica 5. AG with MSDTC & Listener 6. Modification SQL agent jobs
- The MSDN article states that “in Azure Virtual Machines, ILB does not support multiple IP addresses”. This is no longer correct and means that the minimum number of SQL server required in Azure is two the same as for on-premise.
- Setting up the Availability groups is the same as for the on-premises build but to create the SQL Listener you must create an Azure Load balancer. I have shown multiple IPs on one Internal Load balance, ILB, that can only be created using a powershell script.