32
Clustering versus Always On Support: the battle Peter Borremans, Integration Domain Lead & Architect @PeterBorremans

Clustering versus Always On Support: the battle (Peter Borremans @ Codits BizTalk 2016 Launch Event)

  • Upload
    codit

  • View
    396

  • Download
    2

Embed Size (px)

Citation preview

Clustering versus Always On Support:the battle

Peter Borremans,Integration Domain Lead & Architect

@PeterBorremans

Agenda

• Why do you need HA?• SQL Clustering• SQL Always On Introduction• BizTalk 2016 and Always On• The choice

2

“Why Application Level HA?”

“We use VMWare HA”

3

VMWare HA

4

➔ Regular snapshots needed to cover software faults➔ Finding a valid snapshot and restoring it takes time➔ Data Loss

➔ Protection against hardware failures

➔ No patching without downtime possible

➔ No protection if patching goes wrong

HA with Clustering or Always On

5

➔ Specific knowledge required

➔ Protection against hardware and software failures (SQL)

➔ Application level awareness

➔ Data protection

➔ Patching node by node (no downtime)

➔ Patching gone bad can be fixed

Service level – Plan!

6

RPO

• Recovery point objective

RTO

• Recovery time objective

SQL Clustering

7

BizTalk HA on a SQL Cluster

➔ Only HA solution until and including BTS 2013 R2

➔ Based on Windows Failover Clustering

➔ Shared storage necessary➔ Single copy of data

➔ Single instance and network name

8

BizTalk SQL Clustering

9

Active Node Passive Node

Instance 1 (Tracking)

Instance 2 (Runtime)

Shared Storage

BizTalk SQL Clustering

10

Active Node Passive Node

Shared Storage

Instance 1 (Tracking)

Instance 2 (Runtime)

Passive Node Active Node

BizTalk SQL Clustering

11

Active Node Active Node

Shared Storage

Instance 1 (Tracking)

Instance 2 (Runtime)

Cluster & Licensing

➔ True passive => no license

➔ SQL Standard Edition can be used for a 2 node failover cluster

12

SQL Always On

13

Concepts

Availability GroupAutomatic Failover

Availability Replicas

Availability

Databases

Always On

Secondary Backups

Readable Secondaries

Windows Server Failover Cluster

Listener

Primary Replica

Asynchronous Commit

BizTalk HA with Always On

➔ New since BizTalk 2016

➔ Windows Failover Clustering is still used!➔ SQL Group Listener

➔ Local storage is sufficient

15

Always On Shared storage

➔ No shared storage required

➔ Use a FileShare witness location for quorum

16

BizTalk 2016 Always On Support - Why?

➔ Microsoft Azure IaaS does not support shared storage➔ This excludes SQL Clustering

➔ This excludes Application level HA for BizTalk Server

➔ SQL Always On is supported in Azure IaaS➔ Application level HA for BizTalk Server

17

BizTalk SQL Always On

18

Primary Replica Secondary Replica

Instance 1

Instance 3

Local Storage

Instance 2

Instance 4 Instance 3

Instance 2

Instance 4

Instance 1

Local Storage

Secondary Replica Primary Replica

Always On AG protection

➔ A database is protected (by moving log blocks)➔ Sync mode

➔ Async mode

➔ Multiple databases can exist in one group

➔ Group concept opens features as in clustering➔ Virtual identity (listener)

➔ Programs should talk to a listener

➔ No shared resources! (storage for example)

19

Failover

➔ Manual failover➔ Failover to an ASYNC secondary might cause data loss!

➔ Failover to a SYNC secondary will never cause data loss.

➔ Automatic failover

➔ BizTalk Server requires SYNC mode

20

BizTalk on SQL Always On

21

BizTalk with Always On support

➔ BizTalk 2016

➔ SQL 2016

➔ Windows➔ Windows 2012 R2 with hotfix #3090973

➔ Windows 2016

22

Software requirements

Why 4 SQL Instances per node?

➔ MSDTC➔ No distributed transactions in one SQL Server Instance

➔ Spread databases across instances

➔ Instances can be on the same server (VM)

➔ 4 listeners

23

BizTalk Instances with Always On

Instance # Instance Name Databases

1 Authentication SSODB

2 Management BizTalkMgmtDb

3 Runtime BizTalkMsgBoxDbBizTalkRulesEngineDbBAMPrimaryImportBAMStarSchemaBAMAlertsApplication

4 Tracking BizTalkDTADb

24

BizTalk 2016 Always On Limitations

➔ Replicate Logins and SQL Agent jobs

➔ Modify SQL Agent jobs to run on primary

➔ No Read-Only routing➔ Backups on primary

➔ SQL Server Analysis Services and SQL Server Integration Services do not participate in Availability Groups➔ BAM depends on this

25

Licensing

➔ “Advanced availability” (Always On) requires a SQL enterprise license

➔ If the secondary is truly passive (no reports, backups, …) no license is required

➔ A licensed primary only covers one passive secondary (if additional secondary's are added, these should be licensed)

26

Licensing 2

➔ Basic Availability Group on Standard Edition➔ https://msdn.microsoft.com/en-

us/library/mt614935.aspx?f=255&MSPPError=-2147217396

➔ Maximum 2 replicas (one primary / one secondary)

➔ No read access on secondary

➔ Only one DB per AG => ugly setup

➔ Cannot be upgraded to advanced AG

➔ Basic AG support a Group Listener

27

Choose…

28

Make your choice

29

Clustering Always On

Cost + -

Complexity of the setup - -

Preference by DBAs - +

Shared Storage - +

BizTalk version support + -

Azure IaaS HA support - +

HA for SSIS / SSAS + -

Remember…

30

ConceptsNo solution is ‘best’

Evaluate the required Service Level

Choose the technology fit for purpose

Involve necessary skills

Thank you!

Keep in touch. Call or mail. Ask questions. Happy to help.

[email protected]

+32 473 337 335

@PeterBorremans

www.linkedin.com/in/peterborremans