Microsoft SQL Server 2008 R2 Unleashed- P72 ppsx

Number of nodes in a cluster—With Windows 2003 Enterprise Edition or Datacenter, you can now create up to 8 nodes in a single cluster, and with Windows 2008 Enterprise Edition or Datace

CHAPTER 20 Database Mirroring

Summary

Database mirroring is one of the most significant SQL Server features to come along in a

long time This feature has provided a way for users to get to a minimum level of high

availability for their databases and applications without having to use complex

hard-ware and softhard-ware configurations (as are needed with MSCS and SQL Server Clustering

configurations)

To mirror a database, you essentially ask for a complete copy of a database to be created

and maintained up to the last committed transaction The ease and simplicity of creating

and monitoring database mirroring will quickly make it a configuration that many people

use Adding variations to this configuration, such as enhancing data replication or

offload-ing reportoffload-ing users, adds even more availability, resilience, and scalability possible than

ever existed before And, as you have seen, it is very easy to have your applications take

advantage of database mirroring transparently In addition, Microsoft has now improved

on its overall performance and stability, coupled with three more years’ worth of

produc-tion implementaproduc-tions by companies around the globe Moving to SQL Server 2008

data-base mirroring is now more than a rock solid path

Chapter 21, “SQL Server Clustering,” delves into the complexities and significant benefits

of building high-availability solutions by using SQL Server Clustering

How Microsoft SQL Server Clustering Works

Installing SQL Server Clustering

Enterprise computing requires that the entire set of

tech-nologies you use to develop, deploy, and manage

mission-critical business applications be highly reliable, scalable,

and resilient These technologies include the network,

entire technology stack, operating systems on the servers,

applications you deploy, database management systems,

and everything in between

An enterprise must now be able to provide a complete

solu-tion in regards to the following:

Scalability—As organizations grow, so does the need

for more computing power The systems in place must

enable an organization to leverage existing hardware

and to quickly and easily add computing power as

needs demand

Availability—As organizations rely more on

informa-tion, it is critical that the information be available at

all times and under all circumstances Downtime is

not acceptable Moving to five-nines reliability (which

means 99.999% uptime) is a must, not a dream

Interoperability—As organizations grow and evolve,

so do their information systems It is impractical to

think that an organization will not have many

hetero-geneous sources of information It is becoming

increasingly important for applications to get to all

the information, regardless of its location

Reliability—An organization is only as good as its

data and information It is critical that the systems

providing that information be bulletproof

CHAPTER 21 SQL Server Clustering

It is assumed that you will provide a certain level of foundational capabilities in regard to

network, hardware, and operating system resilience The good news is that you can

achieve many of your enterprise’s demands easily and inexpensively by using Microsoft

Cluster Services (MSCS), Network Load Balancing (NLB), and SQL Server Clustering (or

combinations of them)

What’s New in SQL Server Clustering

Much of what’s new for MSCS and SQL Server Clustering has to do with the expanded

number of nodes that can be managed together and several ease-of-use enhancements in

MSCS, including the following:

Setup changes for SQL Server failover clustering—One option forces you to run

the Setup program on each node of the failover cluster To add a node to an existing

SQL Server failover cluster, you must run SQL Server Setup on the node that is to be

added to the SQL Server failover cluster instance Another option creates an

enter-prise push to nodes from the active node

Cluster nodes residing on different subnets—With Windows 2008, cluster nodes

can now reside on different network subnets across network routers You no longer

have to stretch virtual local area networks to connect geographically separated

cluster nodes This opens the door to clustered disaster recovery options

Instances per cluster—SQL Server 2008 Enterprise Edition supports up to 25 SQL

Server instances per cluster (up to 50 for a nonclustered server)

More cluster-aware applications—Many of the MS SQL Server 2008 products are

cluster aware, such as Analysis Services, Full Text Search, Integration Services,

Reporting Services, FILESTREAM, and others, making these applications more highly

available and resilient

Isolation of the quorum disk in MSCS—A shared disk partition that is not on the

same physical drive/LUN as the quorum drive must be available in an attempt to

reduce failure dependencies

Number of nodes in a cluster—With Windows 2003 Enterprise Edition (or

Datacenter), you can now create up to 8 nodes in a single cluster, and with Windows

2008 Enterprise Edition (or Datacenter), you can create up to 16 nodes

These new features and enhancements combine to make setting up SQL Server Clustering

an easy high-availability proposition They take much of the implementation risk out of

the equation and make this type of installation available to a broader installation base

How Microsoft SQL Server Clustering Works

Put simply, SQL Server 2008 allows failover and failback to or from another node in a

cluster This is an immensely powerful tool for achieving higher availability virtually

trans-parently There are two approaches to implementing SQL Server Clustering: active/passive

or active/active modes

In an active/passive configuration, an instance of SQL Server actively services database

requests from one of the nodes in a SQL Server cluster (that is, the active node) Another

node is idle until, for whatever reason, a failover occurs (to the passive node) With a

failover situation, the secondary node (the passive node) takes over all SQL Server

resources (for example, databases and the Microsoft Distributed Transaction Coordinator

[MSDTC]) without the end user ever knowing that a failover has occurred The end user

might experience a brief transactional interruption because SQL Server Failover Clustering

cannot take over in-flight transactions However, the end user still just looks at a single

(virtual) SQL Server and truly doesn’t care which node is fulfilling requests

Figure 21.1 shows a typical two-node SQL Server Clustering configuration using

active/passive mode, in which Node 2 is idle (that is, passive)

In an active/active configuration, SQL Server runs multiple servers simultaneously with

different databases This gives organizations with more constrained hardware requirements

a chance to use a clustering configuration that can fail over to or from any node, without

having to set aside idle hardware

As previously mentioned, SQL Server Clustering is actually created within (on top of)

MSCS MSCS, not SQL Server, is capable of detecting hardware or software failures and

automatically shifting control of the managed resources to a healthy node SQL Server

2008 implements failover clustering based on the clustering features of the Microsoft

Clustering Service In other words, SQL Server is a fully cluster-aware application and

Basic Two–Node SQL Cluster

Active/Passive

Configuration

MSCS

Cluster Group Resources

MSCS

Windows 2003 EE

Windows 2003 EE

2 Processors (Xeon) Memory/Cache 4 GB

2 Processors (Xeon) Memory/Cache 4 GB

Network Public Networks

Quorum Disk

NODE 2 (Passive)

NODE 1 (Active)

MS DTC

SCSI

SCSI SCSI

Local storage

Local storage

Shared Disk

C:

C:

SQL Agent

FIGURE 21.1 A typical two-node active/passive SQL Server Clustering configuration

becomes a set of resources managed by MSCS The failover cluster shares a common set of

cluster resources (or cluster groups), such as clustered (that is, shared) disk drives

NOTE

You can install SQL Server on as many servers as you want; the number is limited only

by the operating system license and SQL Server edition you have purchased However,

MSCS (for Windows 2008) can manage only up to 16 instances of Microsoft SQL

Server Standard Edition at a time and up to 25 instances of Microsoft SQL Server

Enterprise Edition at a time

Understanding MSCS

A server cluster is a group of two or more physically separate servers running MSCS and

working collectively as a single system The server cluster, in turn, provides high

availabil-ity, scalabilavailabil-ity, and manageability for resources and applications In other words, a group

of servers is physically connected via communication hardware (network), shares storage

(via SCSI or Fibre Channel connectors), and uses MSCS software to tie them all together

into managed resources

Server clusters can preserve client access to applications and resources during failures and

planned outages If one of the servers in a cluster is unavailable due to failure or

mainte-nance, resources and applications move to another available cluster node

NOTE

You cannot do clustering with Windows 2000 Professional or older server versions

Clustering is available only on servers running Windows 2000 Advanced Server (which

supports two-node clusters), Windows 2000 Datacenter Server (which supports up to

four-node clusters), Windows 2003 Enterprise Edition and Datacenter Server, and

Windows 2008 Enterprise Edition and Datacenter Server

Clusters use an algorithm to detect a failure, and they use failover policies to determine

how to handle the work from a failed server These policies also specify how a server is to

be restored to the cluster when it becomes available again

Although clustering doesn’t guarantee continuous operation, it does provide availability

sufficient for most mission-critical applications and is the building block of numerous

high-availability solutions MSCS can monitor applications and resources, automatically

recognizing and recovering from many failure conditions This capability provides great

flexibility in managing the workload within a cluster, and it improves the overall

availabil-ity of the system Technologies that are “cluster aware”—such as SQL Server, Microsoft

Message Queuing (MSMQ), Microsoft Distributed Transaction Coordinator (MSDTC), and

file shares—have already been programmed to work within (under the control of) MSCS

CHAPTER 21 SQL Server Clustering

TIP

In previous versions of MSCS, the COMCLUST.EXE utility had to be run on each node to

cluster the MSDTC It is now possible to configure MSDTC as a resource type, assign it

to a resource group, and then have it automatically configured on all cluster nodes

MSCS is relatively sensitive to the hardware and network equipment you put in place For

this reason, it is imperative that you verify your own hardware’s compatibility before you

go any further in deploying MSCS (check the hardware compatibility list at http://msdn

microsoft.com/en-us/library/ms189910.aspx) In addition, SQL Server failover cluster

instances are not supported where the cluster nodes are also domain controllers

Let’s look a little closer at a two-node active/passive cluster configuration As you can see

in Figure 21.2, the heartbeat (named ClusterInternal in this figure) is a private network

set up between the nodes of the cluster that checks whether a server is up and running

(“is alive”) This occurs at regular intervals, known as time slices If the heartbeat is not

functioning, a failover is initiated, and another node in the cluster takes over for the failed

node In addition to the heartbeat private network, at least one public network (named

ClusterPublic in this figure) must be enabled so that external connections can be made

to the cluster Each physical server (node) uses separate network adapters for each type of

communication (public and internal heartbeat)

Active/Passive

Configuration

CLUSTER 1

(NODE 1)

CLUSTER 2

(NODE 2)

Windows 2003 EE

Windows 2003 EE

2 Processors (Xeon) Memory/Cache 4 GB

2 Processors (Xeon) Memory/Cache 4 GB

Network ClusterPublic

SCSI

SCSI SCSI

Local storage

Local storage

S: Shared Disk

Q: Quorum Disk

C:

C:

FIGURE 21.2 A two-node active/passive MSCS cluster configuration

The shared disk array is a collection of physical disks (SCSI RAID or Fibre

Channel–connected disks) that the cluster accesses and controls as resources MSCS

supports shared nothing disk arrays, in which only one node can own a given resource at

any given moment All other nodes are denied access until they own the resource This

protects the data from being overwritten when two computers have access to the same

drives concurrently

The quorum drive is a logical drive designated on the shared disk array for MSCS This

continuously updated drive contains information about the state of the cluster If this drive

becomes corrupt or damaged, the cluster installation also becomes corrupt or damaged

NOTE

In general (and as part of a high-availability disk configuration), the quorum drive

should be isolated to a drive all by itself and be mirrored to guarantee that it is

avail-able to the cluster at all times Without it, the cluster doesn’t come up at all, and you

cannot access your SQL databases

The MSCS architecture requires there to be a single quorum resource in the cluster that is

used as the tie-breaker to avoid split-brain scenarios A split-brain scenario happens when

all the network communication links between two or more cluster nodes fail In these

cases, the cluster may be split into two or more partitions that cannot communicate with

each other MSCS guarantees that even in these cases, a resource is brought online on only

one node If the different partitions of the cluster each brought a given resource online,

this would violate what a cluster guarantees and potentially cause data corruption When

the cluster is partitioned, the quorum resource is used as an arbiter The partition that

owns the quorum resource is allowed to continue The other partitions of the cluster are

said to have “lost quorum,” and MSCS and any resources hosted on nodes that are not

part of the partition that has quorum are terminated

The quorum resource is a storage-class resource and, in addition to being the arbiter in a

split-brain scenario, is used to store the definitive version of the cluster configuration To

ensure that the cluster always has an up-to-date copy of the latest configuration

informa-tion, you should deploy the quorum resource on a highly available disk configuration

(using mirroring, triple-mirroring, or RAID 10, at the very least)

Starting with Windows 2003, a more durable approach of managing the quorum disks

with clustering was created, called majority node set It all but eliminates the

single-point-of-failure weakness in the traditional quorum disk configuration that existed with

Windows 2000 servers However, even this approach isn’t always the best option for many

clustered scenarios

The notion of quorum as a single shared disk resource means that the storage subsystem

has to interact with the cluster infrastructure to provide the illusion of a single storage

device with very strict semantics Although the quorum disk itself can be made highly

available via RAID or mirroring, the controller port may be a single point of failure In

addition, if an application inadvertently corrupts the quorum disk or an operator takes

down the quorum disk, the cluster becomes unavailable

CHAPTER 21 SQL Server Clustering

This situation can be resolved by using a majority node set option as a single quorum

resource from an MSCS perspective In this set, the cluster log and configuration

informa-tion are stored on multiple disks across the cluster A new majority node set resource

ensures that the cluster configuration data stored on the majority node set is kept

consis-tent across the different disks

The disks that make up the majority node set could, in principle, be local disks physically

attached to the nodes themselves or disks on a shared storage fabric (that is, a collection of

centralized shared storage area network [SAN] devices connected over a switched-fabric or

Fibre Channel–arbitrated loop SAN) In the majority node set implementation that is

provided as part of MSCS in Windows Server 2003 and 2008, every node in the cluster uses

a directory on its own local system disk to store the quorum data, as shown in Figure 21.3

If the configuration of the cluster changes, that change is reflected across the different

disks The change is considered to have been committed (that is, made persistent) only if

that change is made to a majority of the nodes (that is, [Number of nodes configured in

the cluster]/2) + 1) In this way, a majority of the nodes have an up-to-date copy of the

data MSCS itself starts up only if a majority of the nodes currently configured as part of

the cluster are up and running as part of MSCS

If there are fewer nodes, the cluster is said not to have quorum, and therefore MSCS waits

(trying to restart) until more nodes try to join Only when a majority (or quorum) of

nodes are available does MSCS start up and bring the resources online This way, because

the up-to-date configuration is written to a majority of the nodes, regardless of node

fail-ures, the cluster always guarantees that it starts up with the most up-to-date configuration

With Windows 2008, a few more quorum drive configurations are possible that address

various voting strategies and also support geographically separated cluster nodes

The “majority node set” resource uses the

private network cluster connection between

nodes to transfer data to the shares

Majority Node Set - Quorum disk option

Heartbeat (private network)

quorum

Node A

quorum

Node B

quorum

Node C

quorum

Node D

FIGURE 21.3 A majority node set

CHAPTER 21 SQL Server Clustering

In Windows Server 2008 failover clustering, you have four choices on how to implement

the quorum:

One option is to use Node majority; a vote is given to each node of the cluster, and

the cluster continues to run as long as a majority of nodes are up and running

A second option is to use both the nodes and the standard quorum disk, a common

option for two-node clusters Each node gets a vote, and the quorum, now called a

witness disk, also gets a vote As long as two of the three are running, the cluster

continues The cluster can actually lose the witness disk and still run

A third option is to use the classic/legacy model and assign a vote to the witness disk

only This type of quorum equates to the well-known, tried-and-true model that has

been used for years

A fourth option is, of course, to use the majority node set (MNS) model with a file

share witness

We describe only the standard majority node set approach here

TIP

A quick check to see whether your hardware (server, controllers, and storage devices)

is listed on Microsoft’s Hardware Compatibility List will save you headaches later See

the hardware pre-installation checklist at http://msdn.microsoft.com/en-us/library/

ms189910.aspx

Extending MSCS with NLB

You can also use a critical technology called Network Load Balancing (NLB) to ensure that

a server is always available to handle requests NLB works by spreading incoming client

requests among a number of servers linked together to support a particular application A

typical example is to use NLB to process incoming visitors to your website As more

visi-tors come to your site, you can incrementally increase capacity by adding servers This

type of expansion is often referred to as software scaling, or scaling out Figure 21.4

illus-trates this extended clustering architecture with NLB

By using both MSCS and NLB clustering technologies together, you can create an n-tier

infrastructure For instance, you can create an n-tiered e-commerce application by

deploy-ing NLB across a front-end web server farm and use MSCS clusterdeploy-ing on the back end for

your line-of-business applications, such as clustering your SQL Server databases This

approach gives you the benefits of near-linear scalability without server- or

application-based single points of failure This, combined with industry-standard best practices for

designing high-availability networking infrastructures, can ensure that your

Windows-based, Internet-enabled business will be online all the time and can quickly scale to meet

MSCS with Network Load Balancing

Network Load Balancing Servers (NLB)

MSCS Cluster

n

Clients

•

•

•

2 1

FIGURE 21.4 An NLB configuration

demand Other tiers could be added to the topology, such as an application-center tier

that uses component load balancing This further extends the clustering and scalability

reach for candidate applications that can benefit from this type of architecture

How MSCS Sets the Stage for SQL Server Clustering

Figure 21.5 shows an Excel spreadsheet that documents all the needed Internet Protocol

(IP) addresses, network names, domain definitions, and SQL Server references to set up a

two-node SQL Server Clustering configuration (configured in an active/passive mode)

CLUSTER1 is the first node, CLUSTER2 is the second node, and the cluster group name is

CLUSTER >GROUP (simple naming is used here to better illustrate the point) The public

network name is ClusterPublic, and the internal heartbeat network name is

ClusterInternal This spreadsheet has also been included in the download files on the

CD for this book It’s a good idea to fill out this spreadsheet before you start installing and

configuring your servers