Académique Documents
Professionnel Documents
Culture Documents
Part 1
Network Considerations
All Microsoft failover clusters must have redundant network communication paths. This
ensures that a failure of any one communication path will not result in a false failover and
ensures that your cluster remains highly available. A multi-site cluster has this requirement as
well, so you will want to plan your network with that in mind. There are generally two things
that will have to travel between nodes: replication traffic and cluster heartbeats. In addition to
that, you will also need to consider client connectivity and cluster management activity. You
will want to be sure that whatever networks you have in place, you are not overwhelming the
network or you will have unreliable behavior. Your replication traffic will most likely require
the greatest amount of bandwidth; you will need to work with your replication vendor to
determine how much bandwidth is required.
With your redundant communication paths in place, the last thing you need to consider is
your quorum model. For a 2-node multi-site cluster configuration, the Microsoft
recommended configuration is a Node and File Share Majority quorum. For a detailed
description of the quorum types, have a look at this article.
The most common cause of confusion with the Node and File Share Majority quorum is the
placement of the File Share Witness. Where should I put the server that is hosting the file
share? Lets look at the options.
Next you will want to have a look at your network connections. It is best if you rename the
connections on each of your servers to reflect the network that they represent. This will make
things easier to remember later.
You will also want to go into the Advanced Settings of your Network Connections (hit Alt to
see Advanced Settings menu) of each server and make sure the Public network is first in the
list.
Your private network should only contain an IP address and Subnet mask. No Default
Gateway or DNS servers should be defined. Your nodes need to be able to communicate
across this network, so make sure the servers can communicate across this network; add static
routes if necessary.
Once you have your network configured, you are ready to build your cluster. The first step is
to Validate a Configuration. Open up the Failover Cluster Manager and click on Validate a
Configuration.
The Validation Wizard launches and presents you the first screen as shown below. Add the
two servers in your cluster and click Next to continue.
A multi-site cluster does not need to pass the storage validation (see Microsoft article). Toskip
the storage validation process,click on Run only the tests I select and click Continue.
You will be presented with the following confirmation screen. Click Next to continue.
If you have done everything right, you should see a summary page that looks like the
following. Notice that the yellow exclamation point indicates that not all of the tests were
run. This is to be expected in a multi-site cluster because the storage tests are skipped. As
long as everything else checks out OK, you can proceed. If the report indicates any other
errors, fix the problem, re-run the tests, and continue.
You are now ready to create your cluster. In the Failover Cluster Manager, click on Create a
Cluster.
The next step asks whether or not you want to validate your cluster. Since you have already
done this you can skip this step. Note this will pose a little bit of a problem later on if
installing SQL as it will require that the cluster has passed validation before proceeding.
When we get to that point I will show you how to by-pass this check via a command line
option in the SQL Server setup. For now, choose No and Next.
The next step is that you must create a name for this cluster and IP for administering this
cluster. This will be the name that you will use to administer the cluster, not the name of the
SQL cluster resource which you will create later. Enter a unique name and IP address and
click Next.
Note: This is also the computer name that will need permission to the File Share Witness as
described later in this document.
Congratulation, if you have done everything right you will see the following Summary page.
Notice the yellow exclamation point; obviously something is not perfect. Click on View
Report to find out what the problem may be.
Figure 15 View the report to find out what the warning is all about
If you view the report, you should see a few lines that look like this.
Dont fret; this is to be expected in a multi-site cluster. Remember we said earlier that we will
be implementing a Node and File Share Majority quorum. We will change the quorum type
from the current Node Majority Cluster (not a good idea in a two node cluster) to a Node and
File Share Majority quorum.
would share a folder. In my case, I create a share called MYCLUSTER on a server named
DEMODC.
The key thing to remember about this share is that you must give the cluster computer name
read/write permissions to the share at both the Share level and NTFS level permissions. If
you recall back at Figure 13, I created my cluster and gave it the name MYCLUSTER. You
will need to make sure you give the cluster computer account read/write permissions as
shown in the following screen shots.
Now with the shared folder in place and the appropriate permissions assigned, you are ready
to change your quorum type. From Failover Cluster Manager, right-click on your cluster,
choose More Actions and Configure Cluster Quorum Settings.
On the next screen choose Node and File Share Majority and click Next.
In this screen, enter the path to the file share you previously created and click Next.
Figure 23 Click Next to confirm your quorum change to Node and File Share Majority
Assuming you did everything right, you should see the following Summary page.
Now when you view your cluster, the Quorum Configuration should say Node and File
Share Majority as shown below.
Figure 25 You now have a Node and File Share Majority quorum
The steps I have outlined up until this point apply to any multi-site cluster, whether it is a
SQL, Exchange, File Server or other type of failover cluster. The next step in creating a
multi-site cluster involves integrating your storage and replication solution into the failover
cluster. This step will vary from depending upon your replication solution, so you really need
to be in close contact with your replication vendor to get it right. In Part 2 of my series, I will
illustrate how SteelEye DataKeeper Cluster Edition integrates with Windows Server Failover
Clustering to give you an idea of how one of the replication vendors solutions works.
Other parts of this series will describe in detail how to install SQL, File Servers and Hyper-V
in multi-site clusters. I will also have a post on considerations for multi-node clusters of three
or more nodes.
Step-by-Step: Configuring a 2-node multi-site cluster on Windows Server 2008 R2
Part 2
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.
Now click Create Job. That will launch the Create Job wizard.
Give your job a name and description. These can be anything you like.
Network adapter the network where the replication traffic will travel
Figure 4 Choose you source server and network to use for replication
Network adapter the network where the replication traffic will travel
Compression Level If you have a 100 Mbps or faster network for replication, leave
it set to none. If you have a WAN that is less that 100 Mbps, you may benefit from
enabling compression. Settings somewhere in the middle tend to give you the best
performance of compression vs. CPU overhead associated with enabling compression.
Maximum bandwidth you can think of this as a poor mans QOS. If you want to
ensure that replication never exceeds a certain threshold of your WAN capacity, you
can put a limiter on the amount of bandwidth it can consume. Unless you have a good
reason to set it, it is better off leaving it set to 0.
Now if you take a look at your DataKeeper GUI, it will look similar to the following.
Once you have created your mirror, you need to make your mirror available in the Microsoft
Cluster Available Storage. There are a few ways to do this, but the most straight forward
way is to use the Windows PowerShell CLI. Below is an example that shows how to take the
existing mirror we just created on the E drive and add it to the cluster Available Storage,
move it to the PRIMARY node and bring it in-service
Import-Module FailoverClusters
Add-ClusterResource -Name DataKeeper Volume E
-ResourceType DataKeeper Volume -Group Available
Storage
Get-ClusterResource DataKeeper Volume E | SetClusterParameter VolumeLetter E
Move-ClusterGroup Available Storage -Node primary
Start-ClusterResource DataKeeper Volume E
For more information on PowerShell and the available commands for use with Failover
Clustering, check out this great blog post from Symon Perriman of the Microsoft Failover
Clustering Team.
http://blogs.msdn.com/clustering/archive/2008/12/20/9243367.aspx
You are now going to repeat the above steps to add any additional mirrors that you will use
in your cluster. In our case, we are going to create a mirror of the F drive and use it to cluster
the MSDTC. After you have added your additional mirrors and added them to Available
Storage, your DataKeeper GUI should look something like this.
Figure 8 After adding the second Job for the MSDTC resource
And your Failover Cluster Manager GUI should look like this.
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 howfix to all cluster
nodes. http://support.microsoft.com/kb/978476
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.
http://technet.microsoft.com/en-us/library/cc770748(WS.10).aspx
http://technet.microsoft.com/en-us/library/cc771540(WS.10).aspx
You will start by opening the Failover Cluster Manager GUI and then choose Configure a
Service or Application.
You will then choose Distributed Transaction Coordinator and click Next
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.
Choose the volume where you will store the data for the MSDTC resource. In our case we are
choosing the replicated F drive.
Congratulations, you have succesfully configured the DTC resource. Click Finish.
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
I followed the instructions detailed in the first article and copied my SQL 2008 with SP1 install to the
C:\ drive of both nodes in my cluster. In the instructions below, I will do the installation from the local
disk of each 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.
If everything goes as planned, you should see the screen below. Click OK to continue.
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.
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.
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.
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.
Confirm you have enough disk space and click Next to continue.
Choose the default settings to allow a new cluster resource group named SQL Server
(MSSQLSERVER) to be created.
Figure 21 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.
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.
Add any SQL Server administrators and choose your authentication mode and then click Next
Choose your Error and Usage Reporting options and click Next
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.
If everything installs as expected, you should see the following screens. Click Next then
Close to finish the installation.
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.
That will launch the install wizard as shown below. Click OK to continue.
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.
Verify you are adding the node to the righ instance and click Next.
Choose your Error and Usage Reporting options and click Next
Now that you have a fully functional two node cluster, you probably should testing things out
by doing some manual switchovers. Right click on the resource and choose Move to node
SECONDARY.
If everything is configured properly, your Failover Cluster GUI should look as follows.
Conclusion
I believe that SQL clusters with replicated storage make a lot of sense. Storage has always
been a single point of failure of traditional clusters. You can eliminate that single point of
failure by deploying a SQL Server cluster with replicated storage from SteelEye or any other
Microsoft Multi-Site Cluster replication partner. I hope you found this article informative. If
you have any questions or suggestions, please add your comments!