SQL Server Clustering and High Availability

An Overview to SQL Server Clustering
An overview to SQL Server Clustering and Deployment of SQL Server
2008 multi site cluster on Windows 2003 R2

9/1/2011
TATA CONSULTANCY SERVICES LTD.
Supreme Mandal
Systems Engineer
Associate ID 473199

Version 1.1

SQL Server clustering uses Microsoft clustering services MSCS to perform set up and make functional a
windows cluster which is required for high availability and perfect implementation of “Nines” in any mission

TATA CONSULTANCY SERVICES Page 1

critical database/application support system. MSCS was introduced as a component of Windows NT server
4.0Enterprise Edition to allow failover application if ones become unavailable.

For Configuration of SQL Server clustered environment with an objective to employ a true hot-standby
server facility (“Single Cluster / Dual Node” facility) the available failover options are below:

Stand alone server

User1 User2 User3 User4 User5

FIG, 1:- Conventional client-server environment

Objective of Clustering-- Zero Downtime Zero Loss
From Technical outlook it can be said that to achieve “Zero Downtime and zero loss” is practically
impractical which demands Cent percent dedication of each and every resource i.e. Hardware, Software,
Networking , Power, Monitoring process and overall Technicians who are responsible for managing
Windows datacenters. Thus in Real time Rules of Nines is applied to measure the accuracy of early
mentioned Technical Proverb “Zero Downtime and zero loss”

The colloquial term nines is used in engineering to indicate reliability or purity (or similar quantitative
descriptor). It is preceded by a number indicating the degree of such reliability or purity. For example, 0.999 (or
99.9 percent) pure silver would be 3 nines pure. Or, for example, electricity that is delivered without


interruptions (blackouts, brownouts or surges) 99.999 percent of the time would have 5 nines reliability.
Reliability can be considered a time-based purity.

SQL Server High Availability Options

Comparative Study of Cold /Warm/Hot Standby Solution
COLD WARM HOT


Backup / Restore Replication and Log Shipping Failover clustering and Database
Mirroring

Detach / Copy / Attach Manual detection and failover Automatic detection

Manual detection and failover Replication – since SQL Server 6.0 Automatic, fast failover

Potential for data loss Primarily used where availability is Manual failover
required in conjunction with scale out
of read activity Failover requires
custom solution

Clients must be redirected Could define subset of source database Transparent client redirection

Slowest failover – most Latency between source and copy can Zero work loss
downtime be seconds Log Shipping

Backup / Restore Basic idea: Backup, Copy, Restore Log Site redundancy
will always be supported

Log backups allow point in Database scope
time restore

Detach / Copy / Attach Database accessible but read-only

Copies entire files Users must exit for next log to be
applied

No rolling forward logs Peer-to-Peer Transactional Replication
SQL Server 2005 introduced bi-
directional transactional replication
Enables scale-out and improved
availability

Improvements in SQL Server 2008 Version

Conflict detection
• Each row has a hidden column listing originating peer node ID for change
• Distribution Agent on each node detects conflicts by comparing hidden column
New Topology Wizard makes setup/ changes easier


RTO -Recovery Time Objectives
RPO -Recovery Point Objectives

Active/Passive Failover Configuration:
SQL Server services are started on only one node of the cluster(primary node) while the other node( secondary
node) has the services configured to start manually In this case users will access the resources of only one
machine on the cluster for getting data available. The other one doesn’t serve user requests hence it is passive.

In case of failure occurs in Primary Node, MSCS starts the SQL Server services on the Secondary node
and bringing the DB online to make it available. Users will have to reconnect to access the data in the databases
running under SQL Server database engine, but the amount of time for the switch over will be considered only a
minimal disruption of service

Until Primary Node is coming back online, the secondary node will continue to provide users with
access to SQL Server and its databases.

Benefit: Because only one instance is being run on a server, no server will be required to assume two SQL
Server instances in the event of a failover, so performance should not be degraded.

Drawback: Because only one instance of SQL Server is being run on the virtual server, one server will always
be in standby mode and idle. This means that you are not getting the most out of the money you used for the
hardware.


User1 User2 User3

FIG, 2:- Single Cluster Single Node (Active/Passive) Environment


Active/Active Failover Configuration:
SQL Server is installed and started both nodes in the cluster. In this configuration two virtual servers are
configured on the cluster to allow both SQL Server nodes to provide database access to their own respective
data, to users. In a nutshell, both Windows servers in the cluster are operating as individual servers and can be
addressed individually for accessing SQL Server data.

If one node fails other will grab Control of the shared databases and continue to provide services to users. In
this case the single remaining node in the cluster will operate both virtual servers allowing each of SQL server
nodes to access their data even though one is no longer available. Basically in Active/Active Configuration
requires that each SQL Server be configured as primary, specifying the other node of the cluster is secondary.

Configuring an Active/Active failover scenario using MSCS requires a little more work than Active/Passive.
But it allows for better utilization of server hardware because both machines are able to serve users and one of
them takes the full load if something happens to its partner node.

Remember one thing that MSCS has very stringent H/W requirements, so before proceed to set up with
Microsoft recommended HCL (hardware compatibility list) in line with Windows and SQL server version you
are going to apply. But the best configuration is to use two identical servers with identical H/W peripherals,
BIOS version etc.

Benefit: With this configuration, you are fully using all of your hardware. Rather than having one server that is
operational and another that is in standby mode waiting for a failover, both servers are operational, which
allows you to get us out of the machines you have purchased.

Drawbacks: If failover occurs and one server is running both SQL Server instances, performance can be
adversely affected. However, this slower performance is probably better than the virtual server totally being
down. An additional drawback is that this configuration requires more licenses to be purchased than with an
Active/Passive cluster. Because the cluster is running two active instances of SQL Server, you will be required
to purchase the licenses for two separate server machines, which depending on your situation, may be a
deterrent.


Top 3 Challenges to implement a Cluster

1.] CPU
CPU resource usage is one of the top three areas you have to plan for when creating clustered environments.
The old practice of sizing your CPUs so they are at a utilization rate of 60 percent to 80 percent still holds true,
but this utilization rate now has to account for a failover. This means that if you keep your individual nodes at
60 percent to 80 percent utilization they may not be able to handle the workload of failover instances. What
does this mean?
To truly size clustered servers for failover, you need to make sure that the total CPU utilization rate after worse-
case failover scenarios never goes above 80 percent, even if your normal day-to-day CPU must remain below
40% to account for possible failover scenarios.

2.] Memory
As with CPU resource usage, memory is very important to account for in failover clustering. Administrators
must account for the memory usage of their applications after a failover. Memory intensive applications such as
SQL Server 2008 will use as much memory on their own server as possible and often when failover occurs, the
SQL Server 2008 instance that has failed over will have performance issues as it contends with the established
instance use of memory.

Note: SQL Server 2008 has been improved over earlier versions of SQL Server and now has the ability to
utilize dynamic memory in clustered environments.

When configuring SQL Server on a clustered server in a multi-node environment, database administrators are
advised to set the max server memory configuration setting to leave memory free in case of failovers. It is also
recommended that database administrators set the min server memory configuration setting to prevent the failed
over instance from assuming all of the memory on the new node and affecting the performance of the
established instance.

3.] Disk Drives
Often, when creating multi-node clusters, administrators face the issue of not having enough disk drive letters.
In a Windows environment, resource groups are given different drive letters on the clustered nodes. As the
number of resource groups increases due to having multiple instances of SQL Server 2008 installed or due to
the design practice of using multiple file groups for a database, the 26-drive letter limit is severely restricted as
the number of nodes increase in a multi-node environment. Database administrators must work closely with
server administrators who often build the Windows clusters before SQL Server 2008 is installed to assure that


enough drive letters are available and that the sizes of the drives behind the drive letters are large enough to
accommodate their database size.

Cluster Considerations:-
It is advantageous to have a clustered SQL Server environment in terms of high availability; however, high
availability does come with certain tradeoffs.

First, it is typically very expensive to create a clustered SQL Server environment. This is because the
nodes in the clustering need to conform to the hardware compatibility list for clustered nodes.
Second, complex network is required for setup, and the machines need to be close to identical, along
with a required shared disk subsystem for the database files. A storage area network (SAN) is a decent
choice for this subsystem, but a SAN is not required and is an expensive option.
Third, if you are running an Active/Active cluster, you will need a SQL license for each processor for
each machine running an instance of SQL Server in the cluster.
Finally, local clustering is typically confined to the same geographic area; a natural disaster could
potentially leave your cluster useless. In that event, you would need to convert to your disaster recovery
site for continued operations. It is possible to set up geographically dispersed SQL Server clusters, but
the setup is much more complex and expensive.

Best Practices before setting up a Cluster:-
Case I
Operating Systems - Windows Server 2003

You should spend more time designing and planning your clustered environment than actually creating
the clustered environment.
All hardware used for the clustered environment must be on the Windows 2003 Clustering HCL as a
unit and not as individual pieces.
Each cluster node should have identical hardware
If creating a clustered environment with more than 2 nodes, you should consider making one of the
nodes a passive node and configure it as the primary failover node.
Determine all virtual names and IP addresses during the planning phase
Be sure to account for future additional space during the configurations of the drives and drive letters
Use a standard drive letter for the local drives and quorum drives across all clustered nodes in your
environment
It is recommended that you utilize two separate (virtual or physical) networks in a clustered
environment. One network for the public and one for the private. Be sure to use separate network cards
for the Public and Private networks and not a single multi-port network card.
Use static IP addresses for both the Public and Private networks with the Private network using a private
class A, B, or C address.
Make sure the shared disk array is configured properly, running, and can be seen by all nodes before
installing your cluster.


Make sure your Quorum drive is fault tolerant.
Create unique virtual server names of 15 characters or less.
Be sure to disallow automatic fail-back to avoid the “ping-pong” effect resource bouncing back and
forth when one node constantly fails and comes back up.

Case II
Database - SQL Server 2008
Microsoft recommends installing Analysis Services clustered installations in a single group with its own
disk and IP resources and not on a resource group that has the database engine installed on it.
While the Enterprise Edition of SQL Server 2005 supports 25 instances on a clustered node, Standard
Edition only supports 16, you will need to understand that each instance needs its own resource group
and you will need to utilize the Majority Node Set model. It is usually not best practice to install more
than a few instances on a clustered node in order to achieve scalability and performance goals.
SQL Server 2005 requires the .NET Framework on all nodes of the cluster and while the installation
wizard will install the .NET Framework on all nodes, it is usually recommended that you install the
.NET Framework on each node before attempting the actual installation process in order to speed up the
install process.
It is usually recommended that you create four different domain groups when creating a cluster. One for
each
of the following: SQL Server 2005 service, SQL Server 2005 Agent service, Full-Text Search service,
and Analysis Services.
Clustered SQL Server 2005 nodes should not have other applications installed on them
Since you can only have one default instance in a clustered environment, it is better to simply name all
instances in your environment for standardization purposes.
Do not delete or rename the default cluster group, or remove any of the resources from this group and do
not delete for rename any resources from the SQL Server 2005 resource group.
If using replication in a clustered environment, place the snapshot folder on a network share that all
nodes can read and write to.
Be sure to test the failover of all nodes before going into production

Over and above Advantage and disadvantages of SQL server Cluster is like below:-

Advantage of SQL Server Clustering:-
The downtime during failover period is reduced to minimum.
The response is automatic when the server fails and you don’t need to adjust anything manually.
Upgrades can be performed without hampering the work of the client and forcing other users to
logoff during that period.
Enormous reduction in downtime is possible with clustered SQL server when compared with the
other routines servers.
No need to rename the servers while clustering because whenever the failover occurs, the users or
client machines will not feel any change in the performance in spite of the system failure.
Once the primary server is fixed you can quickly return back to it without wasting much time.


Disadvantage of SQL Server Clustering:-
Expensive when compared to other alternatives of failover as stand-by servers and log shipping will
cost you more.
Setup time is more when compared to other options.
Maintenance will be more when it is compared to other options.
You need to hire experienced network administrators and database administrators to handle the
clustering.

Clustered Environment Health Checks Clustered Environment Health Checks

Clustered Environment Health Checks


Significant Technical Jargons in Clustering:-
1.] Cluster Node: Cluster node is the central head in clustering which uses MSCS Windows 2000
datacenter edition can host 4 nodes at a time where as Advanced Server edition able to 2 nodes a time

2.] Shared Disk Resources: where we can place SQL Server data files (.MDF) and log files (.LDF)
so that in case of failure it will be shared by another node without interrupting (or slightest)

3.] Private Disk Resources: SQL Server Executables (system files / DLL) will be installed there it
will also be shared by both node in case of failure

4.] Heartbeat: Keep alive message generated by each node to its pair after every 5 seconds which in case
execute a more deeper “IsAlive” check after every 60 seconds to verify whether it is there or not thus issuing
select @@servername, verifying the response .if it fails then failure will be recorded and another node will take
charge with slight interruption. Heartbeat message will be executed in private LAN. Failing to response the
heart beat will cause cluster failover occurrence.

5.] SQL Server Virtual IP Address: Frontend Applications i.e. web application (preferably
ASP.NET) or Desktop application (preferably C#.NET) will connect this IP Address whenever they want to
connect the Database. This application will access the only database resource irrespective to which node they
are accessing in case of failure

6.] SQL Server Virtual Network Name: Frontend application will connect this virtual network
name irrespective to specific SQL Server node over the Network.

7.] SQL Server Resources: SQL Server resources like SQL Server database engine, SQL Server
Agent, SQL server Full text search is always shared by both nodes

8.] Quorum Disk: reserved for the cluster services to keep track of cluster services and MSDTC also
shared by both nodes, this disk is not for storing any data, log files it is denoted by Q disk.

9.] Windows Network Name & IP Address: It is required in case of public LAN where
external or outsiders will access the data. It is also important if the server is connected to DHCP server to get
the IP Addresses.

Schematic design in next page describing those above mentioned jargons in brief


Users

What is SAN
Storage Area Network (SAN), the network infrastructure is typically Fiber Channel (FC), although some
organizations use Gigabit Ethernet as well. The data transfer mechanism used by SANs is block Small
Computer Systems Interface (SCSI). This is well-suited to SQL Server, because the database application
expects block access to data, which is not easily supplied using NAS. Utilizing SAN software, multiple volumes
can be created and “presented” to the servers, utilizing the storage space on the SAN, as shown in Figure


Server 1

DB 1

Server 2

DB 2

SAN Disk Array SAN Controller
DB 3

Server 3

Storage Area Networks


SQL Server 2008 multi-site cluster on Windows
Server 2003 R2
Undoubtedly, Failover Clustering is the best choice to reduce system downtime and provide higher application
availability for the whole instance of SQL Server within a site; however, a failover cluster does not protect
against disk failure and requires a SAN.”

What if you could have all of the benefits that Ross outlines and also protect against disk failure and eliminate
the need for a SAN? Well, the good news is that is exactly what you can do by implementing a Microsoft SQL
Server 2008 multi-site cluster on Windows Server 2008. SQL Server 2008 multi-site cluster may be a little bit
of a misnomer. It does not necessarily need to be deployed across geographically dispersed locations. The
servers could be located in the same rack, same room, same building or across continents; it really doesn’t
matter. The important thing is that you are eliminating your storage as a single point of failure and if you choose
to locate your cluster nodes in different physical locations then you also have built in site resiliency.

One of the most common questions and points of confusion about SQL Server 2008 and Windows Server 2008
failover clustering is support for failing across subnets. Yes, Windows Server 2008 Failover Clustering does
support failing between subnets for most applications, however, SQL Server 2008 is not one of those
applications. As far as I know, SQL Server 2008 R2 will also not support failing between subnets when it is
released. My understanding is that the SQL team is working on support for cross-subnet failover, but it will be
supported sometime after SQL Server 2008 R2 is released. So, for the time being, you will have to span your
subnet if you wish to separate your nodes geographically.

Now that you have determined to deploy a multi-node SQL server cluster, here are the steps you will need to
follow.


Configured Failover Cluster Manager GUI on Windows 2008 R2 should look like this.

Figure 1 – After adding the second DataKeeper resource

Clustering MSDTC
IMPORTANT NOTE – There is a hotfix that is required in order to support DTC with 3rd party disk resources.
Please see the following KB article and apply the hotfix to all cluster nodes. SQL 2008 is very dependent upon
MSDTC, so it is highly recommended that you cluster the MSDTC resource before you cluster your SQL
resource. The following articles are provided for your reference for configuration and management of your
MSDTC resource.

You will start by opening the Failover Cluster Manager GUI and then choose “Configure a Service or
Application”.


Figure 2– Creating a MSDTC resource

You will then choose “Distributed Transaction Coordinator” and click next


Figure 3 – Choose your Service or Application

Give the MSDTC resource a name and unique IP address. These should be unique to MSDTC and not the same
as you will use later when you create your SQL resource.


Figure 4 – Choose a Name and IP address

Choose the volume where you will store the data for the MSDTC resource. In our case we are choosing the
replicated F drive.


Figure 5 – Choose a dedicated volume for the MSDTC resource

Confirm your information and click next to continue.


Figure 6 – Click next to configure the DTC resource

Congratulations, you have successfully configured the DTC resource. Click Finish.


Figure 7– A successfully configured DTC resource

We are just about ready to begin the installation of the first node of the SQL Server Cluster, however, there is
one thing we need to do in preparation – Slip Stream SQL 2008 SP1 onto the SQL Server 2008 RTM install
media.

Slip stream SQL SP1 onto your SQL 2008 install media
What I have discovered is that SQL Server 2008 will not install on Windows Server 2008 R2 without first
slipstreaming SQL Server 2008 SP1 onto your SQL 2008 install media. Here is a great article that describes
how to slipstream SQL Server 2008 RTM and Service Pack 1. After I read that article and successfully
slipstream SP1 onto SQL 2008 RTM, I found the following Microsoft KB article that describes the same
procedure. You may get an error that looks like the following if you try to install SQL without first
slipstreaming SP1 onto the media.

There was an error setting private property ‘RequireKerberos’ to value ’1′


Installing your first cluster node
Now that you have your SQL Server 2008 SP1 installation media ready to go, you are ready to install your first
SQL node. There is one major “gotcha” when it comes to installing SQL on a multi-node cluster. In order for
you to install SQL on a multi-node cluster, you must first pass the Windows Server 2008 Failover Cluster
validate process. Unfortunately, a multi-site cluster is exempt from passing the storage related test, so you never
are able to actually “pass” the validation as far as SQL is concerned. It took a little investigation on my part, but
what I have come to find is that there is a command line parameter that allows you to skip the validation test on
the SQL 2008 installation. Here is the command line.

Setup /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster

To launch the SQL setup, open a Command window, browse to your SQL 2008 with SP1 install directory and
type the command as shown below.

Figure 7.1– If everything goes as planned, you should see the screen below. Click OK to continue.


Figure 7.2– Enter your product key and click Next


Figure 8 – Enter your product key

Accept the license agreement and click next


Figure 9 – Set up Wizard License Acceptance Screen

Click Install to install the Setup Support Files


At the end of the Setup for the Support Files you will receive a warning. Click on Show details and you will see
the message below. You can click Next, ignoring this message since it is expected in a multi-site or non-shared
storage cluster.


Figure 10 – The warning is expected in a multi-site or non-shared storage cluster

Choose the features you would like to install and click next. Leave the “Shared Feature” directory set to the C
drive as the SQL binaries should not be installed on the replicated volume.


Figure 11 – Choose your features to be installed.

On the next screen, you will choose a network name for your SQL Server. This will be the name that all of the
clients will connect to. Assuming this is the default instance; leave the Instance ID and Instance root directory
set to the defaults. Do not move the instance root directory to the replicated volume.


Figure 12 – Choose your SQL Network Name

It is recommended that you have separate domain accounts for SQLServer and SQLAgent. You can take the
time to create these accounts now if you have not already done so. These accounts require no special
permissions, as this install process will give them the permissions that they require.


Figure 13 – Confirm you have enough disk space and click next to continue.


Figure 14 – Choose the default settings to allow a new cluster resource group named “SQL Server
(MSSQLSERVER)” to be created.


Figure 15 – Allow the wizard to create a new cluster resource group for you

Choose a replicated volume that is still available, in our case the E: drive. Click Next to continue.


Figure 16 – Choose your replicated volume

Now you will choose the IP address you want associated with the SQL cluster resource. You could leave it set
to use DHCP if you wish.


Figure 17 – Choose your SQL cluster IP address

Choose your security settings and click next


Figure 18 – Add any SQL Server administrators and choose your authentication mode and then click Next


Figure 19 – Choose your Error and Usage Reporting options and click Next


Figure 20 – You will once again see some warnings related to the validation process. You can ignore those messages
as they are to be expected in a multi-site SQL Server cluster.


Figure 21 – Click Install to begin the installation process


Figure 22 – If everything installs as expected, you should see the following screens.

.


Figure 23 – Click next then Close to finish the installation


Figure 24 – Congratulations, you have successfully installed the first node of your multi-site SQL Server Cluster.
Now we will install the second node of the cluster.

Install the second cluster node
Installing the second cluster node is similar to installing the first node. We need to run SQL Setup once again
from the command line so that we can skip the Validate process. So, from the 2nd node, open up your command
prompt and run the following command.

1. Install SQL 2008 SP1 (merged setup) on the 2nd node using the following command:

Setup /SkipRules=Cluster_VerifyForErrors /Action=AddNode
/INSTANCENAME=”MSSQLSERVER”

*Note: This assumes you installed the default instance on the 1st node


Figure 25 – Command line cluster node managemaent


Figure 26 – That will launch the install wizard as shown below. Click OK to continue.


Figure 27 – Enter your product key and click next.


Figure 28 – Accept the license terms and click Next


Figure 29 – Click install to install the Setup Support files


Figure 30 – You can once again ignore the warning that some cluster validation tests have been skipped. This is to
be expected in a multi-site cluster and non-shared storage clusters.

.


Figure 31 – Verify you are adding the node to the right instance and click Next


Figure 32 – Add the passwords to the service accounts and click Next


Figure 33 – Choose your Error and Usage Reporting options and click Next


Figure 34 – Once again, ignore the warning about the skipped operations.


Figure 35 – Click Install to begin the installation process.

If everything goes as expected, you should see the following screen.


Figure 35 – Now that you have a fully functional two node cluster,


Figure 36 – you probably should testing things out by doing some manual switchovers. Right click on the resource
and choose “Move to node SECONDARY”.


Figure 37 – If everything is configured properly, your Failover Cluster GUI should look as follows.

References:-


TechNet Library http://technet.microsoft.com/en-us/ms376608

http://technet.microsoft.com/en-us/library/cc770748(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc771540(WS.10).aspx

Microsoft Support Center http://support.microsoft.com/kb/978476

-:END:-


SQL Server Clustering and High Availability

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to SQL Server Clustering and High Availability (20)

More from ► Supreme Mandal ◄ (8)

Recently uploaded (20)

SQL Server Clustering and High Availability