Microsoft SQL Server 2008 R2 Unleashed- P59 potx

CHAPTER 18 SQL Server High Availability What’s New in High Availability In general, a couple of Microsoft SQL Server 2008 configuration options offer a very strong database engine founda

CHAPTER 18 SQL Server High Availability

What’s New in High Availability

In general, a couple of Microsoft SQL Server 2008 configuration options offer a very strong

database engine foundation that can be highly available (7 days a week, 365 days a year)

Microsoft’s sights are set on being able to achieve five-nines reliability with almost

every-thing it builds An internal breakthrough introduced with SQL Server 2005 called

“copy-on-write” technology, has enabled Microsoft to greatly enhance several of its database

high availability options

Here are a few of the most significant enhancements and new features that have direct or

indirect effects on increasing high availability for a SQL Server 2008–based implementation:

Increased number of nodes in a SQL cluster—You can create a SQL cluster of up

to 64 nodes on Windows Server Data Center 2008

Enhancements to do unattended cluster setup—Instead of having to use wizards

to set up SQL clustering, you can use the Unattended Cluster Setup mode This is

very useful for fast re-creation or remote creation of SQL clustering configurations

All SQL Server 2008 services as cluster managed resources—All SQL Server

2008 services are now cluster aware

SQL Server 2008 database mirroring—Database mirroring creates an automatic

failover capability to a “hot” standby server (Chapter 20, “Database Mirroring,”

covers this topic in detail.)

SQL Server 2008 peer-to-peer replication—This option of data replication uses a

publisher-to-publisher model (hence peer-to-peer)

SQL Server 2008 automatic corruption recovery from mirror—This

enhance-ment in database mirroring recognizes and corrects corrupt pages during mirroring

SQL Server 2008 mirroring transaction record compression—This feature

allows for compression of the transaction log records used in database mirroring to

increase the speed of transmission to the mirror

SQL Server 2008 fast recovery—Administrators can reconnect to a recovering

database after the transaction log has been rolled forward (and before the rollback

processing has finished)

Online restore—Database administrators can perform a restore operation while the

database is still online

Online indexing—The online index option allows concurrent modifications

(updates, deletes, and inserts) to the underlying table or clustered index data and

any associated indexes during index creation time

Database snapshot—SQL Server 2008 allows for the generation and use of a

read-only, stable view of a database The database snapshot is created without the

overhead of creating a complete copy of the database or having completely

redun-dant storage

Hot additions—This feature allows for hot additions to memory and CPU.

Addition of a snapshot isolation level—A new snapshot isolation (SI) level is

being provided at the database level With SI, users can access the last committed

row, using a transactionally consistent view of the database

Dedicated administrator connection—SQL Server 2008 supports a dedicated

administrator connection that administrators can use to access a running server even

if the server is locked or otherwise unavailable This capability enables

administra-tors to troubleshoot problems on a server by executing diagnostic functions or

Transact-SQL statements without having to take down the server

At the operating system (OS) level, Virtual Server 2005 has firmly established virtualization

for both development and production environments and allows entire application and

database stacks to run on a completely virtual operating system footprint that will never

bring down the physical server

NOTE

Microsoft has announced that log shipping will be deprecated soon Although it has been

functionally replaced with database mirroring, log shipping remains available in SQL

Server 2008 However, you should plan to move off log shipping as soon as you can

Keep in mind that Microsoft already has an extensive capability in support of high

avail-ability The new HA features add significant gains to the already feature-rich offering

What Is High Availability?

The availability continuum depicted in Figure 18.1 shows a general classification of

avail-ability based on the amount of downtime an application can tolerate without impacting

the business You would write your service-level agreements (SLAs) to support and try to

achieve one of these continuum categories

Topping the chart is the category extreme availability, so named to indicate that this is the

least tolerant category and is essentially a zero (or near zero) downtime requirement (that

is, sustained 99.5% to 100% availability) The mythical five-nines falls at the high end of

this category Next is the high availability category, which has a minimal tolerance for

downtime (that is, sustained 95% to 99.4% availability) Most “critical” applications

would fit into this category of availability need Then comes the standard availability

cate-gory, with a more normal type of operation (that is, sustained 83% to 94% availability)

The acceptable availability category is for applications that are deemed noncritical to a

company’s business, such as online employee benefit package self-service applications

These applications can tolerate much lower availability ranges (sustained 70% to 82%

availability) than the more critical services Finally, the marginal availability category is for

nonproduction custom applications, such as marketing mailing label applications that can

tolerate significant downtime (that is, sustained 0% to 69% availability) Again, remember

that availability is measured by the planned operation times of the application

CHAPTER 18 SQL Server High Availability

Extreme Availability

Characteristic

Availability Continuum

Availability Range

Near zero downtime!

Availability Range describes the percentage of time relative to the “planned” hours of operations

8,760 hours/year | 168 hours/week | 24 hours/day 525,600 minutes/year | 7,200 minutes/week | 1,440 minutes/day

(99.5%-100%) 1.8 days/yr–5.26 min/yr

High Availability Minimal downtime (95%-99.4%)

18 days/yr–2.0 days/yr

Standard Availability With some downtime

Acceptable Availability Non-critical Applications (70%-82%)

Marginal Availability Non-production Applications (up to 69%)

FIGURE 18.1 Availability continuum

NOTE

Another featured book from Sams Publishing, called Microsoft SQL Server High

Availability, can take you to the depths of high availability from every angle This

land-mark offering provides a complete guide to high availability, beginning with ways to

gather and understand your HA requirements, assess your HA needs, and completely

build out high-availability implementations for the most common business scenarios in

the industry Pick up this book if you are serious about achieving five-nines of reliability

Achieving the mythical five-nines (that is, a sustained 99.999% availability) falls into the

extreme availability category (which tolerates between 5.26 minutes and 1.8 days of down

time per year) In general, the computer industry calls this high availability, but we push

this type of near-zero downtime requirement into its own extreme category, all by itself

Most applications can only dream about this level of availability because of the costs

involved, the high level of operational support required, the specialized hardware that

must be in place, and many other extreme factors

The Fundamentals of HA

Every minute of downtime you have today translates into losses that you cannot well

afford You must fully understand how the hardware and software components work

together and how, if one component fails, the others will be affected High availability of

an application is a function of all the components together, not just one by itself

Therefore, the best approach for moving into supporting high availability is to work on

shoring up the basic foundation components of hardware, backup/recovery, operating

system upgrading, ample vendor agreements, sufficient training, extensive quality

assur-ance/testing, rigorous standards and procedures, and some overall risk-mitigating

strate-gies, such as spreading out critical applications over multiple servers By addressing these

first, you add a significant amount of stability and high-availability capability across your

hardware/system stack In other words, you are moving up to a necessary level before you

completely jump into a particular high-availability solution If you do nothing further

from this point, you have already achieved a portion of your high-availability goals

Hardware Factors

You need to start by addressing your basic hardware issues for high availability and fault

tolerance This includes redundant power supplies, UPS systems, redundant network

connections, and ECC memory (error correcting) Also available are “hot-swappable”

components, such as disks, CPUs, and memory In addition, most servers are now using

multiple CPUs, fault-tolerant disk systems such as RAID, mirrored disks, storage area

networks (SANs), Network Attached Storage (NAS), redundant fans, and so on

Cost may drive the full extent of what you choose to build out However, you should start

with the following:

Redundant power supplies (and UPSs)

Redundant fan systems

Fault-tolerant disks, such as RAID (1 through 10), preferably “hot swappable”

ECC memory

Redundant Ethernet connections

Backup Considerations

After you consider hardware, you need to look at the basic techniques and frequency of

your disk backups and database backups For many companies, the backup plan isn’t what

it needs to be to guarantee recoverability and even the basic level of high availability At

many sites, database backups are not being run, are corrupted, or aren’t even considered

necessary You would be shocked by the list of Fortune 1000 companies where this occurs

Operating System Upgrades

You need to make sure that all upgrades to your OS are applied and also that the

configu-ration of all options is correct This includes making sure you have antivirus software

installed (if applicable), along with the appropriate firewalls for external-facing systems

CHAPTER 18 SQL Server High Availability

Vendor Agreements Followed

Vendor agreements come in the form of software licenses, software support agreements,

hardware service agreements, and both hardware and software service-level agreements

Essentially, you are trying to make sure you can get all software upgrades and patches for

your OS and for your application software at any time, as well as get software support,

hardware support agreements, and both software and hardware SLAs in place to guarantee

a level of service within a defined period of time

Training Kept Up to Date

Training is multifaceted in that it can be for software developers to guarantee that the

code they write is optimal, for system administrators who need to administer applications,

and even for end users themselves to make sure they use the system correctly All these

types of training play into the ultimate goal of achieving high availability

Quality Assurance Done Well

Testing as much as possible—and doing it in a very formal way—is a great way to

guaran-tee a system’s availability Dozens of studies over the years have clearly shown that the

more thoroughly you test (and the more formal your QA procedures), the fewer software

problems you will have Many companies foolishly skimp on testing, which has a huge

impact on system reliability and availability

Standards/Procedures Followed

Standards and procedures are interlaced tightly with training and QA Coding standards,

code walkthroughs, naming standards, formal system development life cycles, protection

of tables from being dropped, use of governors, and so on all contribute to more stable

and potentially more highly available systems

Server Instance Isolation

By design, you may want to isolate applications (such as SQL Server’s applications and

their databases) away from each other to mitigate the risk of such an application causing

another to fail

Plain and simple, you should never put applications in each other’s way if you don’t have

to The only things that might force you to load up a single server with all your

applica-tions would be expensive licensing costs for each server’s software and perhaps hardware

scarcity (strict limitations to the number of servers available for all applications) A classic

example occurs when a company loads up a single SQL Server instance with between two

and eight applications and their associated databases The problem is that the applications

are sharing memory, CPUs, and internal work areas, such as tempdb Figure18.2 shows an

overloaded SQL Server instance that is being asked to service seven major applications

(Appl 1 DB through Appl 7 DB)

The single SQL Server instance in Figure 18.2 is sharing memory (cache) and critical

inter-nal working areas, such as tempdb, with all seven major applications Everything runs fine

Windows 2003

SQL Server 2008

High Risk: Single SQL Server Instance

OS/SQL Binaries

C:

SCSI

D:

E:

F:

Master DB MSDB DB Temp DB Appl 1 DB Appl 2 DB Appl 3 DB Appl 4 DB Appl 5 DB Appl 6 DB Appl 7 DB

FIGURE 18.2 High risk: Many applications sharing a single SQL Server 2008 instance

until one of these applications submits a runaway query, and all other applications being

serviced by that SQL Server instance come to a grinding halt Most of this built-in risk

could be avoided by simply putting each application (or perhaps two applications) onto

their own SQL Server instance, as shown in Figure 18.3 This fundamental design

approach greatly reduces the risk of one application affecting another

Windows 2003

SQL Server 2008

Memory/Cache 8GB RAID Disk Array

Master DB TempDB

C:

SCSI

D:

E:

F:

Appl 1 DB Appl 5 DB

Windows 2003

SQL Server 2008

Memory/Cache 8GB RAID Disk Array

Master DB TempDB

C:

SCSI

D:

E:

F:

Appl 2 DB Appl 3 DB

Windows 2003

SQL Server 2008

Memory/Cache 8GB RAID Disk Array

Master DB TempDB

C:

SCSI

D:

E:

F:

Appl 4 DB Appl 6 DB Appl 7 DB

FIGURE 18.3 Mitigated risk: Isolating critical applications away from each other

Many companies make this fundamental error The trouble is that they keep adding new

applications to their existing server instance without a full understanding of the shared

resources that underpin the environment It is often too late when they finally realize that

they are hurting themselves “by design.” You have now been given proper warning of the

risks If other factors, such as cost or hardware availability, dictate otherwise, then at least

it is a calculated risk that is entered into knowingly (and is properly documented as well)

Building Solutions with One or More HA Options

When you have the fundamental foundation in place, as described in the preceding

section, you can move on to building a tailored software-driven high-availability solution

Which HA option(s) you should be using really depends on your HA requirements The

following high-availability options are used both individually and, very often, together to

achieve different levels of HA:

Microsoft Cluster Services (non–SQL Server based)

SQL clustering

Data replication (including peer-to-peer configurations)

Log shipping

Database mirroring

All these options are readily available “out of the box” from Microsoft, from the Windows

Server family of products and from Microsoft SQL Server 2008

It is important to understand that some of these options can be used together, but not all

go together For example, you might use Microsoft Cluster Services (MSCS) along with

Microsoft SQL Server 2008’s SQL Clustering to implement the SQL clustering database

configuration, whereas, you wouldn’t necessarily need to use MSCS with database

mirror-ing

Microsoft Cluster Services (MSCS)

MSCS could actually be considered a part of the basic HA foundation components

described earlier, except that it’s possible to build a high-availability system without it (for

example, a system that uses numerous redundant hardware components and disk

mirror-ing or RAID for its disk subsystem) Microsoft has made MSCS the cornerstone of its

clus-tering capabilities, and MSCS is utilized by applications that are cluster enabled A prime

example of a cluster-enabled technology is Microsoft SQL Server 2008

MSCS is the advanced Windows operating system configuration that defines and manages

between 2 and 16 servers as “nodes” in a cluster These nodes are aware of each other and

can be set up to take over cluster-aware applications from any node that fails (for example,

a failed server) This cluster configuration also shares and controls one or more disk

subsystems as part of its high-availability capability Figure 18.4 illustrates a basic

two-node MSCS configuration

CHAPTER 18 SQL Server High Availability

Windows 2008 R2

Enterprise Edition

Node B

Windows 2008 R2

Enterprise Edition

Local Binaries

C:

SCSI

D:

Shared Disk

FIGURE 18.4 Basic two-node MSCS configuration

MSCS is available only with Microsoft Windows Enterprise Edition and Data Center

oper-ating system products Don’t be alarmed, though If you are looking at a high-availability

system to begin with, there is a great probability that your applications are already

running with these enterprise-level OS versions

MSCS can be set up in an active/passive or active/active mode Essentially, in an

active/passive mode, one server sits idle (that is, is passive) while the other is doing the

work (that is, is active) If the active server fails, the passive one takes over the shared disk

and the cluster-aware applications instantaneously

SQL Clustering

If you want a SQL Server instance to be clustered for high availability, you are essentially

asking that this SQL Server instance (and the database) be completely resilient to a server

failure and completely available to the application without the end user ever even

notic-ing that there was a failure (or at least with minimal interruption) Microsoft provides this

capability through the SQL Clustering option SQL Clustering is built on top of MSCS for

its underlying detection of a failed server and for its availability of the databases on the

shared disk (which is controlled by MSCS) SQL Server is said to be a

“cluster-aware/enabled” technology

A SQL Server instance that is clustered can be created by actually creating a virtual SQL

Server instance that is known to the application (the constant in the equation) and then

Windows 2008 Enterprise Edition

SQL

Connections

SQL Server 2008 (physical) SQL A

SQL B

Windows 2008 Enterprise Edition SQL Server 2008 (physical)

SQL Server 2008 (Virtual SQL Server)

Local Binaries

C:

Local Binaries

C:

SCSI

D:

Master DB Temp DB Appl 1 DB

FIGURE 18.5 Basic SQL Clustering two-node configuration (active/passive)

two physical SQL Server instances that share one set of databases In an active/passive

configuration, only one SQL Server instance is active at a time and just goes along and

does its work If that active server fails (and with it, the physical SQL Server instance), the

passive server (and the physical SQL Server instance on that server) simply takes over

instantaneously This is possible because MSCS also controls the shared disk where the

databases are The end user and application never really know which physical SQL Server

instance they are on or whether one failed Figure 18.5 illustrates a typical SQL Clustering

configuration built on top of MSCS

CHAPTER 18 SQL Server High Availability

Setup and management of this type of configuration are much easier than you might

think More and more often, SQL Clustering is the method chosen for most

high-availabil-ity solutions Later in this chapter, you see that other methods may also be viable for

achieving high availability (based on the application’s HA requirements) Chapter 21,

“SQL Server Clustering,” covers this topic in more detail

Extending the clustering model to include Network Load Balancing (NLB) pushes this

particular solution even further into higher availability—from client traffic high

avail-ability to back-end SQL Server high availavail-ability Figure 18.6 shows a four-host NLB

cluster architecture acting as a virtual server to handle the network traffic coupled with a

two-node SQL cluster on the back end This setup is resilient from top to bottom

The four NLB hosts work together, distributing the work efficiently NLB automatically

detects the failure of a server and repartitions client traffic among the remaining servers

The following apply to SQL Clustering in SQL Server 2008:

Full SQL Server 2008 Services as cluster-managed resources—All SQL Server

2008 services, including the following, are cluster aware:

SQL Server DBMS engine

SQL Server Agent

SQL Server Full-Text Search

Analysis Services

Integration Services

Notification Services

Reporting Services

Service Broker

Front-End LAN

Back-End LAN

SQL Cluster (virtual) (IP 100.122134.32)

Instance data

SQL A

Local Binaries

CL Node A

(IP 100.122.134.33)

SQL B Local Binaries scsi

scsi

CL Node B (IP 100.122.134.34)

FIGURE 18.6 An NLB host cluster with a two-node server cluster