2. Business Requirements
Application / SQL Server requirements
Strategy
Harold Velazquez
Other HA Solutions
Disaster Recovery
High Availability and Disaster Recovery Solutions
How does Licensing affect your HA Strategy?

3. Business Requirements
What is your SLA for High Availability?
Average Speed to answer: Average time to respond to incidents.
Turn around time: Time required to complete the task.
Production uptime: Interrupted availability time/schedule.
Maintenance Schedule: Is there a planned, agreed-upon downtime for the SQL Server?
Acceptable Performance levels.
SQL Servers must be operational 24/7 and no Data Loss is acceptable, under any circumstances.
SLA: Service Level Agreement
RPO: Recovery Point Objective – How much data can we lose? Or what point in time can we recover the data after a failure?
RTO: Recovery Time Objective – How long does it take to recover operation?

4. Business Requirements
What is your RPO?
What is your business tolerance to data loss?
What is your RTO expectations?
How long is your business expecting to be back on business?
What are we protecting our Database systems from?
Hardware failures
Software faults
Natural Disasters
Human errors
Unpredictable events – such electrical outages, circuit disconnects.
Scheduled maintenance
SLA: Service Level Agreement
RPO: Recovery Point Objective – How much data can we lose? Or what point in time can we recover the data after a failure?
RTO: Recovery Time Objective – How long does it take to recover operation?

5. HA Technologies AlwaysOn Failover Cluster AlwaysOn Availability Group
Database Mirroring
Log Shipping (DR)
Replication (DR)
VM-based solutions

6. Failover Cluster Overview
Instance-level protection
Automatic failovers
RTO is seconds to minutes
RPO is No data loss
Shared-Disk, can be single point of failure.
Versions / Editions supported SQL Standard supports two nodes SQL Enterprise: OS limit
Use-Cases: physical protection of the server.
Nodes per cluster:

7. AlwaysOn Availability Group
FCI single point of failure
Enterprise can host multiple databases per AG, while single database per AG.
RPO is zero and RTO is seconds*
Best use case is data storage protection by having multiple copies.
Leveraging ReadOnly replicas for scalability.
AG is not supported in SQL Standard. SQL 2016 Standard supports basic AG and two nodes with no ReadOnly. SQL Enterprise supports 8 secondary replicas - including 2 synchronous secondary replicas

8. AlwaysOn Availability Group (Synchronous)

9. AlwaysOn Availability Group (Asynchronous)

10. Other technologies (HA and DR)
Log Shipping
Takes log backups on schedule applying them on secondary servers
RPO – backup schedule. RTO – Depends on the process
Replication
Replicates subset of the tables across the servers
RPO – Seconds (depending on the type)
VM-Based technology
Migrating VMs across the hosts

11. Differences between technologies at a glance
Failover Cluster
Availability Groups
Mirroring
Log Shipping
Transactional Replication
Protection Granularity
Operating System
Database Groups*
Database
Publication
Maybe makessense to go through use-cases here? Play several scenarios and evaluate technologies for them?

12. Differences between technologies at a glance
Failover Cluster
Availability Groups
Mirroring
Log Shipping
Transactional Replication
Protection Granularity
Operating System
Database Groups*
Database
Publication
RPO (Data Loss)
None
None (Sync)
Minutes
Depends on latency
Maybe makessense to go through use-cases here? Play several scenarios and evaluate technologies for them?

13. Differences between technologies at a glance
Failover Cluster
Availability Groups
Mirroring
Log Shipping
Transactional Replication
Protection Granularity
Operating System
Database Groups*
Database
Publication
RPO (Data Loss)
None
None (Sync)
Minutes
Depends on latency
RTO (Recovery Time)
Seconds-Minutes
Seconds (Sync)
Depends
N/A
Maybe makessense to go through use-cases here? Play several scenarios and evaluate technologies for them?

14. Differences between technologies at a glance
Failover Cluster
Availability Groups
Mirroring
Log Shipping
Transactional Replication
Protection Granularity
Operating System
Database Groups*
Database
Publication
RPO (Data Loss)
None
None (Sync)
Minutes
Depends on latency
RTO (Recovery Time)
Seconds-Minutes
Seconds (Sync)
Depends
N/A
Automatic Failover
Yes
Yes (Sync) No
Maybe makessense to go through use-cases here? Play several scenarios and evaluate technologies for them?

15. Differences between technologies at a glance
Failover Cluster
Availability Groups
Mirroring
Log Shipping
Transactional Replication
Protection Granularity
Operating System
Database Groups*
Database
Publication
RPO (Data Loss)
None
None (Sync)
Minutes
Depends on latency
RTO (Recovery Time)
Seconds-Minutes
Seconds (Sync)
Depends
N/A
Automatic Failover
Yes
Yes (Sync) No
Performance Overhead
Extra latency in commits
Log Backup copies
Transaction Log
Maybe makessense to go through use-cases here? Play several scenarios and evaluate technologies for them?

16. Differences between technologies at a glance
Failover Cluster
Availability Groups
Mirroring
Log Shipping
Transactional Replication
Protection Granularity
Operating System
Database Groups*
Database
Publication
RPO (Data Loss)
None
None (Sync)
Minutes
Depends on latency
RTO (Recovery Time)
Seconds-Minutes
Seconds (Sync)
Depends
N/A
Automatic Failover
Yes
Yes (Sync) No
Performance Overhead
Extra latency in commits
Log Backup copies
Transaction Log
Version/Edition
Standard - Two nodes Enterprise - OS
Enterprise Standard (two nodes)
Deprecated, and still supported in
Maybe makessense to go through use-cases here? Play several scenarios and evaluate technologies for them?

17. Differences between technologies at a glance
Failover Cluster
Availability Groups
Mirroring
Log Shipping
Transactional Replication
Protection Granularity
Operating System
Database Groups*
Database
Publication
RPO (Data Loss)
None
None (Sync)
Minutes
Depends on latency
RTO (Recovery Time)
Seconds-Minutes
Seconds (Sync)
Depends
N/A
Automatic Failover
Yes
Yes (Sync) No
Performance Overhead
Extra latency in commits
Log Backup copies
Transaction Log
Version/Edition
Standard - Two nodes Enterprise - OS
Enterprise Standard (two nodes)
Deprecated, and still supported in
Readable Secondaries
Yes. Eight replicas
Yes*
Maybe makessense to go through use-cases here? Play several scenarios and evaluate technologies for them?

18. Application / SQL Server requirements
Is SQL Server in a Virtualized environment?
What SQL Server versions are supported by the application(s)?
What are the backup and retention requirements?
What are the CPU and RAM Requirements?
Are the applications Cluster-aware?
Does the Enterprise architecture encourages decoupling databases?
Will there be a need for any SQL Server Enterprise features?
Requirements for AlwaysOn ReadOnly nodes? How many?
Your maintenance requires Online indexing?
Hot add memory and CPU?
Fine grained auditing?
Automatic Tuning?
Automatic Tuning: “Automatic tuning in SQL Server 2017 notifies you whenever a potential performance issue is detected, and lets you apply corrective actions, or lets the Database Engine automatically fix performance problems” --

19. Strategy (Part 1)
Design the provisioning of SQL Servers and databases by grouping them based on:
Performance Tiers (RTO, RPO)
Compliance requirements: Most SOX, some are PCI, others HIPPA, and the rest don’t.
Function: Financial, Departmental, Utility, Reporting
Domain (security) requirements: Some departments just want their own.
SQL Server Edition and version requirements for the application.
Identify and remove (or mitigate) single points of failures.
These grouping requirements improve operations, availability, security, and SQL Licensing, and overall a more stable SQL Server environment.

20. Strategy (Part 2) Decoupling vs Consolidating SQL Servers
Consolidation decreases licensing costs and complexity (sometimes).
Placing all of your eggs in one basket – they are easier to find. But…
Coordinating maintenance plans require acts of congress across all tenants.
New SQL Server version upgrade? All application databases have to agree on to supporting it.
Failover time is increased by the number of the databases and number of open transactions.
Decouple them! But, where do those licensing costs go?
Better performance, security management, patch management, and resource isolation.
Reduces single point of failure, surface area of attack, cumulative REDOs in AlwaysOn Synchronous replication, contention for buffer pool utilization, and spreads resource utilization across environments.

21. Disaster Recovery
RPO and RTO requirements drive the frequency of your backups (Mostly your RPO)
RTO is your promise to how long it will take bringing systems back to normal operations – Make sure you take into account your backup storage performance during times of stress…
What’s your acceptable data loss in the event of a disaster (RPO)?
Does your D/R have a Recovery Level Objective for your SQL Servers?
This is the granularity of SQL Server(s), Database(s), tables, or even filegroups.
This can speed up fulfilling your RPO promise – and may even reduce stress during a disaster! It just requires time and effort to plan.
Perform D/R Tests quarterly
(or once a year depending on your personal risk tolerance level)
Are your physical servers/VMs provisioned with the same RAM/Storage/network?

22. How does Licensing affect your HA Strategy?
First, the phrase “This is not legal advice” disclaimer comes to mind. Please consult a Microsoft Licensing specialist for your environment.
Physical Operating System vs Virtual Operating System.
Single Instance SQL Servers vs Multiple Instance SQL Servers.
Windows Server 2012 Datacenter edition is the right edition to use and allows running unlimited virtual instances with each license on a single server (p4).
Windows Server 2012 Standard edition will entitle you to run one instance in the physical OSE and two instances in the virtual OSE with each license.
SQL Server Licensing: Physical vs VM Core
Database Consolidations reduce your licensing

23. How does Licensing affect your HA Strategy?
Single Instance SQL Servers vs Multiple Instance SQL Servers
Database Consolidations reduce your licensing

24. How does Licensing affect your HA Strategy?
License Mobility within Server Farms.
“Licenses must be assigned to a server for at least 90 days before you are allowed to reassign it to a different server” (p23)
Each Server, physical or virtual must be licensed properly regardless of its workload and whether is primary or secondary.
Database Consolidations reduce your licensing
SQL Server Licensing Guide 2014

25. Licensing VMs – per Core, SQL Server 2012 Virtualization Licensing Guide
Database Consolidations reduce your licensing

26. Licensing VMs – per Core, SQL Server 2012 Virtualization Licensing Guide
Database Consolidations reduce your licensing
When hyper-threading is turned on, a core license is required for each thread supporting a virtual core. In
the example below, hyper-threading is enabled for the physical processor supporting a VM. Since hyperthreading
creates two hardware threads for each physical core, a total of 8 core licenses would be required
in this scenario. (p5)

27. Terms to consider Lessons Learned Service-level agreements
Recover point objectives
Recovery time objectives
Maximum time to recover
Maximum tolerable downtime
Baselining the current workload
Baselining the existing vSphere implementation
Estimating growth rates
I/O requirements (I/O per sec, throughput, latency)
Storage options (disk type/speed, RAID, flash cache)
Software versions (vSphere, Windows, SQL Server)
Licensing (may determine architecture)

28. AVAILABILITY = MTBF / (MTBF + MTTR)
Downtime per year
Downtime per month
Downtime per week
Downtime per day
90% ("one nine")
36.5 days
72 hours
16.8 hours
2.4 hours
95% ("one and a half nines")
18.25 days
36 hours
8.4 hours
1.2 hours
97%
10.96 days
21.6 hours
5.04 hours
43.2 minutes
98%
7.30 days
14.4 hours
3.36 hours
28.8 minutes
99% ("two nines")
3.65 days
7.20 hours
1.68 hours
14.4 minutes
99.5% ("two and a half nines")
1.83 days
3.60 hours
50.4 minutes
7.2 minutes
99.80%
17.52 hours
86.23 minutes
20.16 minutes
2.88 minutes
99.9% ("three nines")
8.76 hours
43.8 minutes
10.1 minutes
1.44 minutes
99.95% ("three and a half nines")
4.38 hours
21.56 minutes
5.04 minutes
43.2 seconds
99.99% ("four nines")
52.56 minutes
4.38 minutes
1.01 minutes
8.64 seconds
99.995% ("four and a half nines")
26.28 minutes
2.16 minutes
30.24 seconds
4.32 seconds
99.999% ("five nines")
5.26 minutes
25.9 seconds
6.05 seconds
864.3 milliseconds
% ("six nines")
31.5 seconds
2.59 seconds
604.8 milliseconds
86.4 milliseconds
% ("seven nines")
3.15 seconds
milliseconds
60.48 milliseconds
8.64 milliseconds
% ("eight nines")
milliseconds
milliseconds
6.048 milliseconds
0.864 milliseconds
% ("nine nines")
milliseconds
milliseconds
milliseconds
milliseconds

29. Related Resources and Links
The magic nines:
Licensing Windows Server 2012 for use with virtualization technologies B75A-A5B B/WindowsServer2012VirtualTech_VLBrief.pdf
Official SQL Server on vSphere Best Practices Guide olutions/sql-server-on-vmware-best-practices-guide.pdf
AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solution by Using Failover Cluster Instances and Availability Groups 9F26- FEF9550EFD44/Building_a_HA_and_DR_Solution_using_AlwaysON_SQL_F CIs_and_AGs%20v1.docx
Distributed Availability Groups groups/windows/distributed-availability-groups