High availability is a hot phrase in the IT industry, but do you know what it means and how to accomplish it? IT professionals attempt to implement high availability every day by buying a lot of expensive hardware and software without tackling the real problem. Many people, both in technology jobs and in management, believe that high availability is a canned technology solution that they can put in place and forget about. But technology is only a small piece of the puzzle called high availability.
True high availability combines people and processes with technology. Although you can build highly available solutions without one of these components, attention to all three lets you provide enterprise-class availability even in the smallest environments. Without the people in place to manage the solution, along with processes designed to ensure that systems remain highly available, the technology won't be up to the task.
How do you measure availability? IT professionals define availability as
A = (F - (D + R))/F
where A is availability, F is mean time between failures, D is mean time to detect failure and decide on a remedy, and R is mean time to repair. The factors you have the most control over are the mean time to repair, mean time to detect a failure, and mean time to decide on a remedy. To detect a failure, you need technology and trained personnel. A highly trained person can prevent some failures and can detect others before they cause any problems, implementing remedies so that the system doesn't go offline at all. This preventative maintenance encompasses strong code-deployment processes that deliver baseline performance numbers for an operations team to monitor against. One of the most crucial abilities for a DBA is knowing when the system is performing as expected and when something abnormal is occurring. If load-testing processes aren't in place, you can derive performance numbers only by observing the application after it's in production, which can give you false results if an application experiences problems from the instant it's deployed. The performance-testing results of an application make DBAs better equipped to rapidly diagnose problems in production.
The only factor you can't control is the mean time between failures—it's entirely unpredictable. Therefore, your investments in high availability should be in people and processes to reduce detection and decision-making time and in the technology to reduce detection and repair time.
You should take away this set of rules from any discussion of high availability:
- Business needs dictate high availability.
- People manage and maintain high-availability solutions.
- Processes ensure those solutions will work.
- Technology provides physical support for high-availability needs.
The simple diagram that Figure 1 shows summarizes these rules. Without the people and processes, you're missing the vital core of high availability.
SQL Server High Availability
Availability is often measured in terms of "nines"—your system's percentage of yearly uptime. For four nines (99.99 percent), you can't be offline for more than 52 minutes per year. Five nines means that you can't be offline for more than 5.26 minutes per year. And six nines gives you an offline margin of just 32 seconds per year. Depending on your business definition, this downtime might include scheduled downtime. As you try to achieve more "nines" of availability, your processes must improve along with your technology solutions.
By leveraging three core technologies in SQL Server 2000—failover clustering, log shipping, and replication—you can achieve five nines of availability. I mention another aspect of availability in the sidebar "Disaster Recovery Means Availability, Too."
Any discussion of high availability needs to start with the editions of SQL Server you can use. To achieve highly available configurations, you must use the Enterprise Edition of SQL Server 2000. Only Enterprise Edition supports failover clustering and log shipping. Although it's possible to achieve high availability with the Standard Edition, you're limited to using replication and custom log shipping. Let's look at these three core technologies for availability.