How To Make Biztalk Highly Available

Transcription

1 Moving your business forward with Microsoft Services Build on proven expertise delivered straight from the source by ers NEW ZEALAND 1

2 Biztalk High Availability 2

3 Biztalk High Availability Introduction and Demo Biztalk HA Components Business Considerations Practical Issues 3

4 Introduction Biztalk 2009 Enterprise fully HA capable (every component can be made redundant, without single points of hardware failure) 2 main methods Cluster or Network Load Balanced Full HA with site redundancy is possible, with specific configurations Hyper-V Failover clustering can also be used to make Biztalk Highly Available 4

5 Small Biztalk HA Deployment 2 Biztalk Servers 2 SQL Servers Biztalk Servers can be clustered or NLB SQL Servers must be clustered 5

6 Medium Biztalk HA Deployment 2 Dedicated Receiving hosts usually clustered, if specific adapters are required 2 Dedicated processing and sending hosts 2 SQL Server in a failover cluster 6

7 Large Biztalk HA Deployment Dedicated Receive Hosts Dedicated Sending Hosts Dedicated Processing Hosts Dedicated SQL Cluster for MessageBox Dedicated Master Secret Server Cluster Dedicated SQL cluster for all other Biztalk Databases 7

8 Hyper-V Clustering 8

9 Cold Backup 1. SQL Server is logshipped 2. Biztalk configuration will be restored from scripts 9

10 Demo 10

11 Biztalk Components and Dependencies 1. SQL Server and storage 2. Biztalk Specific Databases 3. Master Secret Server 4. MS DTC (Distributed Transaction Coordinator) 5. E-SSO (Enterprise Single Sign On) 6. Receiving Hosts 7. Processing Hosts 8. Sending Hosts 9. Biztalk Components 11

12 SQL Server HA for Biztalk 1. No mirroring 2. Only Failover Clustering is supported 3. Ensure that all hardware is redundant (e.g. SAN, Network) 4. Have a separate heartbeat network interface 5. Recommendations: Dedicated to Biztalk At least 2 instances (Active-Active) one only for MessageBox Log shipping or geo-clustering for site resiliency Ensure DTC is configured correctly 12

13 Biztalk Specific Databases 1. Ensure that all custom databases use Biztalk log-shipping scripts 2. There are also special additions in the scripts for BAM 3. If the MessageBoxes are scaled out, then all of them must be logshipped in the same script. 4. Specific steps apply for the rules engine db 13

14 Master Secret Server 1. Recommended to run in clustered SQL servers 2. Ensure that all servers in cluster have the secret key restored 3. Ensure that the cluster name is used, not the server name 4. Offsite backup of the master secret file and password 14

15 MS DTC 1. Ensure that the local DTC is running on every Biztalk server 2. Ensure that at least 1 clustered DTC is present on every failover cluster 3. Ensure that the correct security settings are applied to all local and cluster DTC 4. Ensure that firewall ports are open in both directions, and for the RPC ports too 15

16 Enterprise SSO (E-SSO) 1. E-SSO must exist on every Biztalk Server and E-SSO must also be clustered on a failover Biztalk cluster. 2. On a failover clustered Biztalk server, all hosts must be clustered. 3. E-SSO must be a dependency of every clustered Biztalk host 4. Verify that all E-SSO can reach the Master Secret Server and the correct secret is retrieved (via Event Log) 16

17 Receiving Hosts 1. Except for 4 receiving host types, there should be at least 2 instances of each receiving host, and senders should be configured to reach them simultaneously. 2. For the 4 special host types, they must be failover clustered for automatic HA. They can also be configured in multiple instances, but only one should be active and manual activation required for failure. 3. The 4 host types are: FTP receiving MSMQ receiving POP3 receiving Adapters requiring ordered delivery (HL7, SAP etc) 17

18 Processing and Sending Hosts 1. Ensure that there are at least 2 of them and at least 1 is running at all times. 2. All Biztalk hosts will load balance among themselves automatically. 18

19 Other Biztalk Components 1. BAM can be installed on multiple servers, separately from Biztalk 2. EDI handlers must not be installed on clustered servers. At least 2 EDI adapters must be configured on different servers. Use a clustered file share to pickup EDI documents. 3. ESB and UDDI can be made redundant by installing and configuring on multiple servers to use the same databases. 4. Rules Engine should be configured on every host 5. Have dedicated Biztalk and SQL Management workstations (separate from servers) 19

20 Extended HA and Load Balancing 1. Geo clustering 2. Geo-NLB 3. Scaled out MessageBoxes 4. Look at business processes, not all applications may need highest redundancy, so have multiple hosts and server redundancy levels 5. Script out Biztalk installations and configurations, so that provisioning can be an automated process 20

21 Notes on Biztalk Failover Clusters 1. All Hosts on a failover cluster must be clustered 2. E-SSO must be clustered 3. Connect via Cluster name 4. IIS/FTP MUST be in shared configuration 5. Know the difference between receiving handler and receiving site 6. Try to use only for the 4 receiving hosts. All others should be NLB clustered 7. Separate Network interface for heartbeat 8. Must be within same network segment for all interfaces 9. Geographically limited by network latency 21

22 Notes on NLB Biztalk 1. Note that NLB clustering does not just mean the Windows Network Load Balancing Service. Others like ISA Server NLB, F5 BigIP, Cisco ACE etc, are also applicable 2. Geographically limited by network latency 3. Note that HTTPS must be single-affinity, unless it terminates at the load balancer 4. When writing code, ensure that there is no server state held on each server, so no need for server affinity 5. Ensure that Master Secret is always available 6. Note the difference between service and server 22

23 High Availability Scenarios The business scenario must define these levels (sample below): Level of Resilience Availability Detection Threshold Single hardware item failure RTO within 5 mins 1 min Yes Automated failover Single Datacentre/site failure Data Corruption Business Continuity (all business processes available) RTO within 8 hours Must be able to rollback and recover from 1 week s loss 5 mins No Within 5 hours of transaction completed No 24 hours NA No 23

24 Biztalk HA types Feature Resilience RTO Standard Biztalk Failover Cluster Single Hardware < 5 mins Network Load Balanced Single Hardware < 5 mins SQL Cluster Single Hardware < 5 mins Enterprise SSO / Master Secret Cluster Geo-clustering (Biztalk, SQL,E-SSO) Single Hardware Single Site failure < 5 mins < 5 mins Log shipping Single Site failure 1-8 hours Geo-NLB Single site failure < 5 mins Hyper-V Clustering Single Site failure (if Hyper-V is geoclustered) < 5 mins 24

25 Practical Considerations 1. Plan HA strategy around business process availability and continuity 2. Review entire infrastructure stack (e.g. useless to have Biztalk geo-clustered, if AD does not exist in DR site) 3. The only supported site redundancy methods are Biztalk log shipping and geo clustering/nlb 4. Note that Log Shipping and data restores does not restore external triggers and events Manual reconciliation may be required 5. For Geo-clustering, be aware of the SAN replication settings 6. Watch the throttling events and adjust as necessary 7. Plan the Operational mgmt and process for patching etc 8. Have a all-gone-to-sh** plan 25

26 References Setting up Biztalk HA =en&familyid=eb cbb-84c b4df26b Biztalk HA poster - BBE85C5-4DD4-4B28-B2F FD149&DisplayLang=en Biztalk Operations Guide - =en&familyid=46a77327-affb-4ca babbb03 26

27 Biztalk High Availability 28