Hướng dẫn học Microsoft SQL Server 2008 part 117 pot

After installing SQL Server 2008 failover clustering, the nodes that run the SQL Server resource perform two types of checks: ■ LooksAlive: Every five seconds, it checks whether the SQL

Windows failover clustering is not designed to do the following:

■ Provide continuous connectivity: During the failover process, any active SQL Server client connections are broken Therefore, all noncommitted transactions need to be performed again unless the transactions are handled within the application If the application is cluster-aware, the failover is completely transparent

■ Protect data: Implementing SQL Server 2008 failure clustering does not obviate the need to take backups or run consistency checks (DBCC CHECKDB) Because failover clustering does not protect data, it is still necessary to run backups and restore them on another server, runDBCC CHECKDB, etc

■ Protect a shared disk array from failing: Failover clustering is not designed to pro-tect against a disk failure It is recommended to combine failover clustering with hardware redundancy such as SAN to provide data loss protection

■ Prevent hack attacks

■ Prevent network failures

■ Protect the server from other potential disasters, such as power outages

■ Provide load balancing: Failover clustering is not like network load balancing It does not provide any automatic balancing, although DBAs can manually balance the load using Cluster Administrator

Microsoft SQL Server 2008 failover clustering is part of an entire strategy needed to help reduce downtime Having a failover cluster does not mean that you have a complete high-availability solution.

How SQL Server 2008 failover clustering works

The clustered nodes use a heartbeat signal to check whether each node is alive, at both the Windows

and SQL Server levels At the Windows level, the cluster nodes are in constant communication, thereby

validating the health of all the nodes After installing SQL Server 2008 failover clustering, the nodes that

run the SQL Server resource perform two types of checks:

■ LooksAlive: Every five seconds, it checks whether the SQL Server service is running

■ IsAlive: Every 60 seconds, it runs a simple Transact-SQL commandSELECT

@@servernameagainst the SQL Server to determine whether the server can respond

If theLooksAlivecheck fails, then theIsAlivecheck is performed immediately If theIsAlive

check fails, then, by default, it will try to restart the SQL Server 2008 resource on the same node once

If it fails to restart, then it will failover the SQL Server 2008 group to another node and restart it on

the other node During failover, Windows Clustering Services stops the SQL Server service on the

current node and starts it on the failover node SQL Server goes through the recovery process to start

the databases on the failover node After the SQL Server service is started and themasterdatabase is

recovered, the SQL Server resource is considered to be online

The LooksAlive and IsAlive setting should not be touched, and the query select

@@servername that IsAlive runs against the SQL Server cannot be changed.

Even after a SQL Server resource is online, it may not be ready to accept connections yet, as user

databases may still be in recovery Just like in a stand-alone SQL Server recovery, the length of the

recovery process depends on how much activity needs to be rolled forward and rolled back on startup.

SQL Server 2008 has two important features, fast recovery and instant file initialization, that can reduce

these delays Fast recovery makes the database available after theREDOphase and during theUNDO

phase before it completes Instant file initialization allows initializing the data files instantly without

filling the space with zeros This feature helpsTEMPDBinitialization time, as it is recreated every time

SQL Server is started

The fast recovery feature is available only in SQL Server 2008 Enterprise Edition SQL

Server 2008 Standard edition does not let users access the database until recovery

completes both of the REDO and UNDO phases.

Instant file initialization is available in all editions of SQL Server 2008 To use this feature, assign the

Windows Perform Volume Maintenance Tasks security privilege to the SQL Server 2008 service account.

SQL Server 2008 failover clustering topologies

SQL Server 2008 failover clustering supports many topologies, as shown in Figure 48-2

FIGURE 48-2

SQL Server 2008 failover cluster topologies

Single-instance cluster

N+1 cluster

∗ indicates the active node

N+M cluster

Multiple-instance cluster

Inst1

Inst3

Inst1

∗

∗

∗

Inst2

Inst1

∗

∗

■ Single-instance cluster: Replaces the Active/Passive terminology A single-instance cluster has

only one active instance of SQL Server owned by a single cluster node, and all other nodes of

the cluster are in a wait state Another node is enabled either in the event of a failure on the

active node or during a manual failover for maintenance

■ Multiple-instance cluster: Replaces the Active/Active terminology and has more than one SQL Server instance SQL Server 2008 Enterprise Edition supports up to 25 instances on the same cluster, and SQL Server 2008 Standard Edition is limited to 16 instances on the same cluster Although 25 instances is the maximum number supported (in the Enterprise Edition),

I have not seen any cluster with that many instances I have seen a two-node cluster with 13 SQL Server instances, and that cluster had many performance issues because it was not prop-erly designed and did not have enough resources for all the instances The maximum number

of instances will be limited to the resources (processor and memory) on the cluster nodes

A multiple-instance cluster is sometimes misunderstood to represent some kind of load-balancing solution for SQL Server 2008 However, this is not true, as the different instances have distinct sets of databases, and there is no shared state between the SQL Server 2008 instances.

■ N+1 cluster: Has N active nodes and one passive node For example, if you need three

SQL Server 2008 failover clustering instances, then the best scaling solution would require a four-node cluster Three of the four nodes would run one SQL Server 2008 failover clustering instance, while the fourth node would provide the failover This configuration enables each

of the SQL Servers to use the maximum resources on each node, still providing failover in case one node goes down SQL Server 2008 Enterprise Edition supports up to 16 nodes on

a Windows Server 2008 failover cluster, and SQL Server 2008 Standard Edition is limited to two nodes

■ N+M cluster: A variation of the N+1 cluster that has more than one passive node, which

could be used in the event of failover The N+M cluster has N nodes hosting applications and

M passive nodes that are spare

Enhancements in SQL Server 2008 Failover

Clustering

SQL Server 2008 failover clustering has a lot of enhancements compared to previous versions of SQL

Server failover clustering:

■ Reliable setup experience: The setup process in SQL Server 2008 failover clustering has changed significantly The fragile remote execution has been removed, which means there is no need for Task Scheduler on remote nodes By removing the remote execution, Microsoft has simplified the installation process and eliminated the possibility of installation failures due to Task Scheduler issues

■ Integrated OS and SQL checks: Before actually installing a SQL Server 2008 failover cluster-ing instance, the setup executes many OS and SQL rules on all the cluster nodes to determine whether any common issues can cause the setup to fail If an issue is found, then it clearly displays the issue along with recommendations This enables failures to be corrected and the setup to continue This feature eliminates more than 50 percent of failed installations that Microsoft has seen with previous versions of SQL Server failover clustering

■ Multiple drive selection: SQL Server 2000 and 2005 failover clustering allows the selection

of only one drive for the databases during setup After setup, additional drives need to be added, which requires taking the SQL Server resource offline, thereby introducing downtime

With SQL Server 2008 failover clustering, the setup allows selecting multiple drives and specifying different drives for SQL Server data files, log files, tempdb, and backup

■ Independent of MSDTC: Unlike SQL Server 2005, a SQL Server 2008 failover clustering

installation does not require configuring MSDTC as a clustered resource

SQL Server 2008 setup checks for MSDTC and displays a warning if it does not find it

run-ning on the node where setup is runrun-ning If you are not using distributed transactions, then

you do not need to configure MSDTC and can safely ignore this warning People have varying opinions

about MSDTC Some believe that MSDTC should be configured as a clustered resource before installing

SQL Server 2008 failover clustering — perhaps because of their experience with SQL Server 2005,

which required this Or maybe they saw the warning and interpreted it as a requirement However, if it

were mandatory, then the setup would display a failure and not a warning.

To configure MSDTC as a clustered resource, a unique IP address resource, a unique Network Name

resource, and a unique shared disk (min size 500 MB) are required Why waste these resources if you

know you won’t be using distributed transactions? If at a later date you need distributed transactions,

then you can configure MSDTC at that time.

Full-text and replication installed as part of the database engine: There is no option

to uncheck full-text and replication on a cluster This is really nice, as in previous versions

of SQL Server failover clustering it was very difficult, if not impossible, to add full-text and

replication after the installation on a cluster Full-text has undergone considerable changes

and is integrated within the SQL Server service itself This means that full-text service is no

longer installed as a separate service; rather, it is part of the SQL Server 2008 engine itself

Therefore, there is no full-text resource in a SQL Server 2008 cluster group after the setup

is completed Also, when upgrading a SQL Server 2005 failover cluster to SQL Server 2008,

full-text resource is removed during the upgrade

■ Positioned to enable Sysprep and slipstream: With previous versions of SQL Server, this

was not even possible With the new SQL Server 2008 setup architecture, Microsoft will be

able to add this frequently requested feature in the future The slipstream feature is made

available in SQL Server 2008 Service Pack 1 This feature provides the capability to merge

RTM and patches (service packs and cumulative updates) and perform a single install Sysprep

is still not supported in RTM or SP1

■ High availability with Add/Remove node operations: Starting with SQL Server 2008,

adding or removing a node from the SQL Server 2008 failover clustering instance does not

affect the node on which SQL Server 2008 is running This increases the availability of the

SQL Server 2008 failover clustering instance

■ Reduced downtime with rolling upgrade and patching: For the first time, SQL Server

2008 failover clustering allows rolling upgrade and patching, which significantly increases SQL

Server availability In client tests, in-place SQL Server 2008 failover clustering rolling upgrade

processes incurred an average of approximately two to three minutes of downtime This is a

huge improvement compared to previous versions of SQL Server

■ Integration with Windows Server 2008 failover clustering features: SQL Server 2008

failover clustering depends on Windows failover clustering, and with the introduction of

Win-dows Server 2008, numerous features have been added SQL Server 2008 failover clustering is

integrated with Windows Server 2008 features, offering the following key benefits:

■ Certified cluster solution not required: All the components need to be logoed for

Win-dows Server 2008 and the cluster needs to pass all the Cluster Validation tests included in

Windows Server 2008 failover cluster If any of the cluster validation tests fail, SQL Server

2008 failover clustering will detect it before the actual install, and setup will proceed only

after the issue is fixed and all the cluster validation tests have passed

If you are implementing SQL Server 2008 failover clustering on a Windows Server 2003 failover cluster, then you still need a certified cluster solution in the Windows Server Catalog.

■ Domain groups not required for setup: To install SQL Server 2005 failover clustering, you first needed to ask your network administrator to create a domain group and place the SQL service accounts in that group Only then could you proceed with installing SQL Server 2005 failover clustering Now there is no need for domain groups in order to install SQL Server 2008 failover clustering on Windows Server 2008 You may instead choose to opt for Service Security IDs (SIDs) SIDs is a Windows Server 2008 feature This means that installing SQL Server 2008 failover clustering on Windows Server 2003 still requires domain groups

■ DHCP and IPv6 are supported by SQL Server 2008: The new features of Windows Server 2008 failover clustering, such as DHCP support and IPv6, are supported by SQL Server 2008 Although DHCP is supported in Windows Server 2008 failover clustering, I still recommend using static IP addresses

■ Node support: SQL Server 2008 failover clustering supports the maximum number of nodes (16) supported by Windows Server 2008 failover clustering

SQL Server 2008 failover clustering does not support having OR dependency between IP addresses (that is, nodes in different subnets) even though Windows Server 2008 failover clustering supports it This basically leaves the same support for geographically dispersed clusters in SQL

Server 2008 failover clustering on Windows Server 2008 as SQL Server 2005 failover clustering on

Win-dows Server 2003.

SQL Server 2008 Failover Clustering Setup

There are two options for installing a SQL Server 2008 failover clustering instance:

■ Integrated installation

■ Advanced/Enterprise installation Integrated installation consists of two steps:

1 Create a single-node SQL Server 2008 failover cluster — During this step, setup is run on the

first node of the cluster to create a single-node SQL Server 2008 failover clustering instance

After this step, the SQL Server 2008 service is up and running and is ready to accept client connections A single-node SQL Server 2008 failover cluster is a fully functional cluster except that it does not provide high availability, as it has only one cluster node

2 Add the nodes — During this step, setup is run again on each additional cluster node that

needs to be added to the single-node failover cluster

Advanced/Enterprise installation also consists of two steps:

1 Prepare step — During this step, all cluster nodes are defined and prepared After this step,

SQL Server 2008 is not functional and cannot accept client connections

2 Complete step — After the prepare step is run, the complete step is run on the cluster node

that owns the shared disk to complete the SQL Server 2008 failover clustering instance and make it operational After this step, SQL Server 2008 service is fully functional

Either option can be used to install a multi-node SQL Server 2008 failover cluster.

Integrated installation is the most popular option for installing SQL Server 2008 failover clustering,

espe-cially when an operational SQL Server 2008 failover clustering instance is needed after installing on the

node Additional nodes can be added at any time without causing any downtime

Planning SQL Server 2008 failover clustering

Before installing a new SQL Server 2008 failover clustering instance, I highly recommend spending

a significant amount of time on planning to achieve a high-availability solution Just installing a SQL

Server 2008 failover cluster does not guarantee a high-availability solution It is just one component of

your solution

Because a SQL Server 2008 failover cluster runs on top of a Windows Server failover cluster, ensure that

you have a fully functional Windows Server failover cluster and that there are no errors in the Windows

event logs (Application and System logs) on any cluster nodes

Refer to the following Microsoft’s whitepapers for creating and configuring the Windows

Server failover cluster.

A step-by-step guide for a Windows Server 2003 failover cluster: www.microsoft.com/downloads/

details.aspx?familyid=96F76ED7-9634-4300-9159-89638F4B4EF7&displaylang=en

A step-by-step guide for a Windows Server 2008 failover cluster: www.microsoft.com/

windowsserver2008/en/us/clustering-resources.aspx

A SQL Server 2008 failover clustering instance can run on either a Windows Server 2003

SP2 or Windows Server 2008 failover cluster SQL Server 2008 failover clustering is not

supported on Windows Server 2000 If you are installing a new Windows failover cluster, I recommend

implementing a Windows Server 2008 failover cluster because it has more enhancements than a

Windows Server 2003 failover cluster For example, with a Windows Server 2008 failover cluster,

you no longer need to purchase a certified cluster solution Now you can build your own cluster

with the hardware you might already have purchased To be supported, all cluster components must

be individually certified for Windows Server 2008, and the cluster must pass all tests in the Cluster

Validation Wizard.

Once you have a fully functional Windows Server failover cluster, make sure that you have everything

you need to install a SQL Server 2008 failover clustering instance

A single SQL Server 2008 failover clustering instance requires the following:

■ Unique IP address: This is the SQL Server IP address that the clients will use to connect to

the SQL Server SQL Server 2008 allows using multiple IP addresses on separate networks,

but it does not allowORdependency even though Windows Server 2008 failover clustering

supportsORdependency SQL Server 2008 supportsANDdependency This means that if

multiple IP addresses are used, then all IP addresses must be online in order for SQL Server

to be online If any one of the IP addresses goes offline, then SQL Server will go offline, too

As mentioned earlier, a SQL Server 2008 failover cluster installed on a Windows Server 2008

failover cluster supports DHCP A dedicated IP is still recommended, though

■ Unique network name: This is the SQL network name that the clients will use to connect

to the SQL Server If this is a named instance of SQL Server, then you also need the instance

name For example, consider SQL2008\INST1, where SQL2008 is the SQL network name and

INST1 is the instance name Clients will need to use SQL2008\INST1 to connect to this SQL

Server named instance

■ At least one unique shared disk: This shared disk will be used for storing the SQL Server databases Ideally, you should have at least three shared disks: one for data files, one for log files, and a third fortempdbfiles For important databases, you may want to have separate drives for their log files I do not recommend using the Quorum drive for storing SQL Server databases If you are planning to have multiple SQL Server instances, then each instance will need its own dedicated shared disk SQL Server failover clustering instances cannot use the same shared disk, as it is possible to do with stand-alone SQL Server instances Also, each shared disk needs a drive letter

■ Mount points: With large databases (usually databases that are more than a terabyte in size) and with multiple SQL Server instances, multiple disks are usually needed, and it is very easy to run out of drive letters In such situations, you can use mount points, as SQL Server 2008 failover cluster supports mount points A mount point is a drive that is mapped

to a folder and is assigned a drive path instead of a drive letter Therefore, you can surpass the 26 drive-letter limitation by using mount points When using mount points, note the following:

■ Make sure that each mount point appears as a cluster resource

■ The root disk must be added as a dependency for the mount points

■ Each mount point must be added as a SQL Server dependency Failure to do this may result in data corruption during failover

■ Do not use the root directory of the mounted drive to store SQL Server databases Instead, create another folder on the root directory and then place the databases in that directory

Similarly, do not install SQL Server 2008 on the root directory of the mounted drive

Otherwise, SQL Server may not start

■ SQL Server service accounts: Each SQL Server clustered service account needs a domain account For security reasons, it is best to use a separate domain account for each SQL Server service account Table 48-1 lists the required permissions for SQL Server service accounts

Best Practice

Do not give domain administrator or local administrator rights to SQL Server service accounts It is neither

necessary nor recommended

The Lock Pages in Memory policy is disabled by default This policy determines which accounts can

use a process to keep data in physical memory, thereby preventing the system from paging the data

to virtual memory on disk This policy should be enabled on 32-bit SQL Server 2008 only when you

need to use AWE memory On 64-bit SQL Server 2008, only Enterprise Edition can use the Lock Pages

in Memory policy On 64-bit SQL Server 2008, enable Lock Pages in Memory only after thorough

testing

TABLE 48-1

Security Requirements for SQL Server Service Accounts

1 For 32-bit SQL Server, Lock Pages in Memory is required for a SQL Server service account only if you are using

Address Windowing Extensions (AWE) memory.

2 This is required only if you want to use ‘‘instant file initialization.’’

■ Domain groups: If you are installing a SQL Server 2008 failover cluster on Windows Server

2003, you need domain groups for the SQL Server service accounts The domain groups

control access to registry keys, files, SQL Server objects, and other cluster resources SQL

Server service accounts must be manually added to domain groups before the setup There is

no rule as to how many domain groups need to be created Some clients choose to use one

domain group for all the SQL Server service accounts for simplicity, while others use separate

domain groups for each SQL Server service account for security isolation It is recommended

to add the domain groups to the local permissions on the cluster nodes and not give the local

permissions directly to the SQL Server service accounts If you are installing a SQL Server

2008 failover clustering instance on a Windows Server 2008, you can now use Service SIDs

instead of domain groups Service SIDs functionality was introduced in Windows Vista and

Windows Server 2008 It allows the provisioning of access control lists (ACLs) to resources

and permissions directly to a Windows service

■ Domain controller: A SQL Server 2008 failover clustering instance needs a domain controller

and is not supported on a cluster node that is a domain controller It is recommended to have

redundant domain controllers, as a single domain controller is a single point of failure; and in

a high-availability solution we want to eliminate all single points of failure

■ Installation media: The SQL Server 2008 failover clustering feature is available in Enterprise

Edition, Developer Edition, Enterprise Evaluation Edition, and Standard Edition Developer

and Enterprise Editions have the same features, but Developer Edition can be used for

devel-opment purposes only Enterprise Evaluation Edition is used for short-term testing, as it

expires after 180 days Standard Edition and Enterprise Edition can be used for production

purposes

■ Standard Edition is limited to only two nodes, whereas Enterprise Edition supports the maximum of 16 nodes on a Windows Server 2008 failover cluster Also, Enterprise Edition supports up to 25 instances of SQL Server 2008 on the same cluster, while Standard Edition is limited to 16 instances Apart from these limitations, SQL Server 2008 Standard Edition does not have a lot of high-availability features such as fast recovery, online index-ing, online restore, data compression, backup compression, and many more features that are available only in SQL Server 2008 Enterprise Edition and are very important for highly available clustering solutions

■ SQL Server 2008 failover clustering is supported on x86, x64, and IA64 platforms The platform for SQL Server 2008 will depend on the Windows Server platform If you have

a Windows Server 2008 x64 failover cluster, then you need SQL Server 2008 x64 SQL Server 2008 x32 failover clustering is not supported on Windows Server 2008 x64 Sim-ilarly, if you have a Windows Server 2008 IA64 cluster, then you will need SQL Server

2008 IA64

SQL Server 2008 prerequisites

Before actually starting the SQL Server 2008 failover cluster setup, the following SQL Server 2008

pre-requisites need to be installed on all the cluster nodes:

■ Microsoft NET Framework 3.5 SP1

■ Microsoft Windows Installer (MSI) 4.5

■ Microsoft Windows hotfix 937444 for FILESTREAM (only for Windows Server 2003 cluster) The first two prerequisites (.NET Framework and MSI) are located in the installation media

under theredistfolder under the respective platforms For example, NET Framework 3.5 SP1

(dotNetFx35setup.exe) for the x64 platform is located in theSQL Server 2008 Developer

Binaries\x64\redist\DotNetFrameworksfolder Microsoft NET Framework 3.5 SP1 needs to

be pre-installed on all platforms except for Windows Server 2003 Itanium (IA64) For Windows Server

2003 IA64, install NET Framework 2.0 SP2, which is also located in the installation media

If you are installing a SQL Server 2008 failover cluster on a Windows Server 2003, you need to download hotfix 937444 from http://support.microsoft.com/kb/937444 and install it on all cluster nodes prior to installing SQL Server 2008 failover clustering.

Best Practice

To minimize downtime, I recommend the following: Install the prerequisites on passive cluster nodes

(meaning nodes where no services are running) first, reboot the node, failover the services to a recently

updated cluster node, and then install them on the remaining passive cluster node For example, say you

have a three-node Windows Server 2008 failover cluster with SQL1 and SQL2 running on Node1 and Node2,

respectively First install the prerequisites on the passive node (Node3), reboot Node3, and then move either

continued

SQL1 or SQL2 to Node3 Suppose you move SQL2 to Node3, install the prerequisites on Node2, and reboot

Then move SQL1 to Node2, install the prerequisites on Node1, and reboot This technique will minimize

the downtime and give you more control over moving the services from one node to another Each failover

will incur a downtime of approximately 15 seconds, but because you are controlling the failover, you can

schedule it properly

Apart from the prerequisites listed previously, I highly recommend installing the latest SQL Server 2008

Setup Support files This will enable you to take advantage of known setup fixes that are available and avoid

any known issues To install the latest SQL Server 2008 Setup Support files, download the latest cumulative

update for SQL Server 2008 and install it Note that installing the cumulative update before installing SQL

Server 2008 installs only the latest SQL Server 2008 Setup Support files and not the full cumulative update

The next time you are installing SQL Server 2008, setup will see the latest setup support files and use them

As the slipstream feature is available in SQL Server 2008 Service Pack 1 (SP1), you can slipstream SP1 with

SQL Server 2008 RTM and install both of them in a single installation This approach is even better than

installing the latest cumulative update, as with a slipstream install of SQL Server 2008+ SP1 you proactively

have the fixes not only to the setup but also in other components of SQL Server 2008

There is no need to reboot the cluster node after installing each prerequisite To minimize the number

of reboots, apply all the prerequisites on the cluster node and then reboot it once

Creating a single-node SQL Server 2008 failover cluster

After you have finished planning and have applied the prerequisites, you are ready to install a SQL

Server 2008 failover cluster As discussed earlier, a SQL Server 2008 failover cluster setup performs local

installation; it has removed remote execution So the first step is to create a single-node SQL Server

2008 failover cluster Here are the step-by-step instructions:

1 Launch the SQL Server Installation Center on the cluster node that owns the shared disk

resources that you want to use for SQL Server 2008 databases To launch the SQL Server

Installation Center, double-clicksetup.exeon the root of the SQL Server 2008

installa-tion media

2 The following message will be displayed if Microsoft NET Framework 3.5 is not installed:

SQL Server 2008 Setup requires Microsoft NET Framework 3.5 to be

installed Download and install NET Framework from

http://www.microsoft.com/net/ and then rerun Setup

OK

3 Click OK and install all the prerequisites that were discussed in the previous section.

4 Once all the prerequisites are installed, SQL Server Installation Center, shown in Figure 48-3,

will be displayed