Database Reference
In-Depth Information
Designing a High Availability Strategy
The process of designing a high availability strategy mixes art, science, and politics all together. It is an iterative
process of collecting and often adjusting requirements, setting the right expectations and building a solution that fits
into the budget.
Requirements
gathering
is the first stage of the process. Like a backup strategy, you have to deal with RPO and
RTO metrics. Usually, you can get them from the Service-Level Agreement (SLA). Alternatively, if those metrics were
not present in the SLA, you should work with the system's stakeholders to define them.
■
system availability requirements are usually measured in “groups of nines.” For example, five-nines,
or 99.999 percent availability, means that system should be available 99.999 percent of time, which translates to
5.26 minutes of downtime per year. Four-nines, or 99.99 availability, translates to 52.56 minutes of downtime per year.
three-nines, or 99.9 percent availability, allows 8.76 hours of downtime annually.
Note
Working with stakeholders is a tricky process. While stakeholders usually want zero downtime and data loss, it is
neither technically possible nor financially feasible. For example, neither of the existing high availability technologies
can provide zero downtime. There is always some period of time when a system is inaccessible during the failover
process.
Zero data loss, on the other hand, is achievable, but it comes at a cost. Synchronous commit in database
mirroring or AlwaysOn Availability Groups add overhead and extra latency to the transactions that modify the data.
In some cases, with high-end OLTP systems, such overhead is not acceptable.
■
Note
you need to take the performance sla into consideration when designing a high availability strategy.
In either case, budget is the most critical factor to consider. Implementing a high availability strategy always
leads to additional expenses. In most cases, you need to buy new servers and network and storage equipment. These
purchases, in turn, require extra rack space and use more AC power for the new hardware and for air conditioning it.
Moreover, you need to have the manpower available to implement and maintain the solution.
The budget places constraints on what you are able to achieve. It is impossible to implement 99.999 or even
99.99 availability in a system if the budget does not allow you to buy the required hardware and software licenses. You
should work together with the system's stakeholders, and either adjust the requirements and expectations, or obtain
the extra budget when needed.
Another important action is defining the scope of the high availability solution. For example, it is very important
to understand if the required availability level must be achieved around the clock, or just during business hours.
Another important question to resolve is if the solution should be geographically redundant. That requirement can
dramatically increase the complexity and cost of the solution.
It is very important not to start the implementation until you have collected and analyzed all of the requirements,
including budget constraints. Taken together, the requirements will dictate what technology or technologies you will
be able to use for the implementation.
Table
31-2
compares high availability technologies available in different versions and editions of SQL Server.
