Presentation from SQL Saturday Madison, Wisconsin April 21, 2012.

1. SQL Server 2012
High Availability and DR
Joey D’Antoni
SQL Saturday #118 Madison, WI
21 April 2011

2. About Me
• @jdanton on Twitter
• Principal Architect SQL Server, Comcast Cable
• Joedantoni.wordpress.com
• Videos and Blogs at SSWUG.org
• Vice President of the Philadelphia SQL Server User
Group
– SQL Saturday #121 Philadelphia—June 9th

3. Agenda
• SQL Server 2008 to 2012—What’s Changed in HA and
DR
• Geo-Clustering
• All about Availability Groups

4. Learning Objectives
• SQL Server HA and DR
• What’s involved in SQL Clustering
• How clustering and Availability Groups work
• What’s new in 2012 HA/DR

5. Licensing (What’s New)
• The Availability Group features will require the Enterprise
Edition of SQL Server
• The licensing model for SQL Enterprise Edition has
changed. Consult your friendly Microsoft sales
representative for more details
• AlwaysOn read-only replicas will need to be licensed

6. Windows Core Support
• No GUI version of Windows
• Allows for fewer patches
• Uses PowerShell and MMCs for support

7. Windows Core

8. High Availability (HA) and Disaster
Recovery (DR) Options in SQL 2008
• Backup and Recovery
• Failover Cluster Instances (FCI)
• Mirroring
• Log Shipping
• Replication
• SAN Replication*
• Virtualization*

9. High Availability (HA) and Disaster
Recovery (DR) Options in SQL Server 2012
• Backup and Recovery
• Failover Cluster Instances (FCI)
• Mirroring
• Availability Groups (2012)
• Log Shipping
• Replication
• SAN Replication*
• Virtualization*

10. What’s new in SQL Server 2012 HA/DR
• AlwaysOn Availability Groups
• SMB Support for Failover Cluster Instances
• Multi-subnet clustering is supported
• Flexible Failover

11. SQL Server Failover Clustering
Architecture

12. SQL Failover Clustering in 2008
• SQL Clustering required 1 subnet to be used across the
whole cluster
• Cluster failover is controlled by isAlive/looksAlive
processes, which check the SQL service and run
@@servername

13. SQL Failover Clustering in 2012
• Full support for geo-distributed clusters
• SMB Storage (File Shares) Supported for FCI
• Flexible failover model based on sp_server_diagnostics
• TempDB on Non-shared Disk Resource
– Makes PCI-based Solid State Drive an option

14. Quorum
It’s not just bad cologne
anymore

15. Quorum
Are you
there?
Why Yes I
am here

16. Understanding Quorum
• There are a several slides on this topic—it is critical!
– In a nutshell, you cluster has to be able to talk to itself to keep the
cluster service up in running
– This applies to both SQL Server Failover Cluster Instances and
AlwaysOn Availability Groups

17. Quorum
• Quorum is critical—contains master copy of the cluster’s
configuration
• Serves as a tiebreaker if network communications
between cluster nodes fail
• If Quorum fails—cluster is shut down until it’s restored

18. Quorum Models
• Node and Disk Majority (Default)
• Node Majority
• No Majority (Quorum Disk Only)
• Node and File Share Majority (Good for Geo Clusters)

19. Quorum Failure Tolerance
Number of Nodes 2 3 4 5 6 7
Node Majority 0 1 1 2 2 3
Node and Disk/File Share Majority 1 2 2 3 3 4
• Assuming Disk is Up Calculation is: Cluster Up = RoundUp(Total # of
Nodes/2)
• Assuming Disk is Down Calculation is: ClusterUp = RoundUp (Total # of
Nodes/2)-1

20. Why Do Clusters Failover?
• Initiated by failures
in hardware or
software
• Checked by
isAlive/LooksAlive
processes (in
2008R2 and below)

21. Flexible Failover—New for 2012
• Replaces looksAlive/isAlive functionality in SQL Clusters
(and is used for Availability Groups)
• Now runs sp_server_diagnostics
– Accepts two parameter
• HealthCheckTimeout (Default 60 sec/Minimum 15 sec)
• Failover Condition Level

22. Flexible Failover Policies for
Clusters
Level Condition Description
No automatic • Indicates that no failover or restart will be
0
failover or restart triggered automatically on any failure conditions.
Failover or restart
1 • SQL Server service is down.
on server down
• SQL Server instance is not responsive (Resource
Failover or restart
DLL cannot receive data from
2 on server
sp_server_diagnostics within the
unresponsive
HealthCheckTimeout settings).
Failover or restart
• System stored procedure sp_server_diagnostics
3 (Default) on critical server
returns ‘system error’. (Critical errors > 20)
errors
Failover or restart
• System stored procedure sp_server_diagnostics
4 on moderate server
returns ‘resource error’. (Moderate errors > 17)
errors
Failover or restart
• System stored procedure sp_server_diagnostics
5 on any qualified
returns ‘query_processing error’. (Deadlock)
failure conditions

23. What is Stretch Clustering
• Also known as Geo-Clustering

24. Geo Cluster

25. Geo-Distributed Clustering
• Requires SAN replication ($$$$)
• Two of everything
• Requires really fast network connection
• Requires some trickery at the network/DNS level for
connectivity
• Witness Disk (Quorum)
– Can be physical (SAN) disk, or cluster file share

26. Geo-distributed Failover Clustering
• Was available in SQL 2008, but easier to implement in
2012
• Won’t be used by most organizations due to cost and
complexity

27. Review—DR Options in SQL 2008
• Mirroring
– Allowed automatic failover, but only one target
– Mirror target is unreadable
• Log Shipping
– Allowed multiple targets, but failover a manual process, requiring a
connection string change
• Replication

28. AlwaysOn Availability Groups

29. AlwaysOn Requirements
• Windows Enterprise (Clustering is a requirement)
• SQL Server Enterprise Edition
• Windows Cluster
• No shared storage is required
• Quorum Disk (File Share if multi-site or local storage)

30. SQL Server Failover Clustering
Architecture--Review

31. AlwaysOn Architecture

32. Flexible AG Failover
• Similar to how a failover clustered instance fails over
• Connects to instance every 30 seconds to perform health
check
• Also, similar quorum model to Windows Failover
Clustering

33. AlwaysOn Architecture-Advanced

34. Allows for SAN-Less HA/DR
• This is not a huge thing for SQL Server in larger
organizations, but big win for medium sized businesses
• Allows much easier native SQL DR in Virtual
Environments

35. Considerations for Availability Groups
• All SQL servers (including the secondary in the
DR site) in the same Windows domain
• All the databases must be in FULL recovery
model
• The unit of failover (for local HA, as well as DR)
is at the AG level, i.e., group of databases – not
the instance

36. Failover Scenarios
Synchronous- Synchronous-
Asynchronous- commit mode with commit mode with
commit mode manual-failover automatic-failover
mode mode
Automatic failover No No Yes
Manual failover No Yes Yes
Forced failover Yes Yes No

37. Read Only Replicas
• Can have up to 4 (1 synch, 3 asynch)
• SQL Client 2012 will allow for this routing specifically
• Can take backups from read-only copies*
– Copy Only Backups (only full copy, does not affect primary log)
– Can backup primary log from replica
• Indexing must be same on replicas
• Bad queries can affect status of replica

38. Read-only vs Read Intent
• Read only replica databases are open to any client that
can connect to SQL Server
• Read Intent routing is used for the Application Intent
functionality in the SQL 2012 client
• Read intent routing automatically directs connections to
either the primary or listener to a secondary replica

39. Client Connections

40. Client Connections in This Model
• Availability Group Listener
– Works just like a failover clustering instance (single
instance, single IP)
– Creates a VCO (AD Virtual Computer Object)—similar to a cluster
virtual object
• Read-only Connections
– Requires 2012 native ODBC client

41. Backups
• You can determine whether the current replica is the
preferred backup replica by calling the
sys.fn_hadr_backup_is_preferred_replica function
• This checks for replica status
• Allows for post-failover backup jobs to run unchanged in
the event of a failure
• Logic is:
If (top-priority replica is local) Run backup job
Else Exit with success

42. Client Connections
• Always specify Multi-Subnet Failover=True in listener
connection
• From Books Online
“will significantly reduce failover time
for single and multi-subnet AlwaysOn
topologies.”
• SQL Server Failover Cluster Instances as well

43. SQL Clusters and Always On
• SQL Failover Clusters can be members of an Availability
Group
• FCI can only be configured for manual failover
• Only one (the active) node can own the Always On
Replica

44. Differences—SQL FCI and Availability
Groups
Replicas within an availability
Nodes within an FCI
group
Uses WSFC cluster Yes Yes
Protection level Instance Database
Storage type Shared Non-shared
Direct attached, SAN, mount points,
Storage solutions Depends on node type
SMB
Readable secondaries No Yes
· WSFC quorum
· WSFC quorum
Applicable failover policy · FCI-specific
settings · Availability group settings
· Availability group settings3
Failed-over resources Server, instance, and database Database only

45. Turning On AlwaysOn

46. Availability Groups Demo

47. Summary
• Lots of Change in the HA/DR Space
• Licensing also changes—talk to your MS rep
• SQL Server Failover Clusters still a good HA option
• AlwaysOn Availability Groups add a lot more flexibility to
DR

48. Contact Info
• Twitter: @jdanton
• jdanton1@yahoo.com
• Blog: joedantoni.wordpress.com