3 node cluster windows 2008

With the introduction of Windows Server failover clustering a multi-site cluster has become much more feasible with the introduction of cross subnet failover and support for high latency network communications. However, SQL Server has not yet embraced this functionality, which means you will still be required to span your subnet across sites in a SQL Server multi-site cluster.

For the foreseeable future you will be stuck with spanning your subnet across sites in a SQL Server multi-site cluster.

There are a few other network related issues that you need to consider as well, such as redundant communication paths, bandwidth and file share witness placement.

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. Where should I put the server that is hosting the file share? This is certainly a valid option for disaster recovery, but not so much for high availability. If the entire site fails including the Primary node and the file share witness the Secondary node in the secondary site will not come into service automatically, you will need to force the quorum online manually.

This is because it will be the only remaining vote in the cluster. One out of three does not make a majority! Now if you can live with a manual step being involved for recovery in the event of a disaster, then this configuration may be OK for you.

This is not such a good idea. Although it solves the problem of automatic recovery in the event of a complete site loss, it exposes you to the risk of a false failover. Consider this…what happens if your secondary site goes down? In this case, your primary server Node1 will go also go offline as it is now only a single node in the primary site and will no longer have a node majority.

I can see no good reason to implement this configuration as there is too much risk involved. This is the preferred configuration as it allows for automatic failover in the event of a complete site loss and eliminates any the possibility of a failure of the secondary site causing the primary node to go offline.

By having a 3 rd site host the file share witness you have eliminated any one site as a single point of failure, so now the cluster will act as you expect and automatic failover in the event of a site loss is possible. Identifying a 3 rd geographic location can be challenging for some companies, but with the advent of cloud based utility computing like Amazon EC2 and GoGrid, it is well within the reach of all companies to put a file share witness in the clouds and have the resiliency required for effective multi-site clusters.

In fact, you may consider the cloud itself as your secondary data center and just failover to the cloud in the event of a disaster. I think the possibilities of cloud based computing and disaster recovery configurations are extremely enticing and in fact I plan on doing a whole blog post on a just that in the near future.

You will want to add the Failover Clustering feature to both nodes of your cluster. This is accomplished very easily through the Add Features Wizard as shown below. Figure 1 — Add the Failover Clustering Role. 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.

Figure 2- Change the names of your network connections. 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. Figure 3- Make sure your public network is first. Your private network should only contain an IP address and Subnet mask. 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.

Figure 4 — Private network settings. Once you have your network configured, you are ready to build your cluster. Figure 5 — 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. Figure 6 — Add the cluster nodes. A multi-site cluster does not need to pass the storage validation see Microsoft article.

Figure 8 — Unselect the Storage test. Figure 9 — Confirm your selection. 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. Figure 10 — View the validation report. You are now ready to create your cluster. Figure 11 — Create your 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.

Figure 12 — Skip the validation test. 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. Figure 13 — Choose a unique name and IP address.

Figure 14 — Confirm your choices. 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. Figure 16 — Error report. 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.

First, we need to identify the server that will hold our File Share witness. Remember, as we discussed earlier, this File Share witness should be located in a 3 rd location, accessible by both nodes of the cluster. Once you have identified the server, share a folder as you normally would share a folder.

Figure 17 — Make sure you search for Computers. Figure 19 — Give the cluster computer account share level permissions. Now with the shared folder in place and the appropriate permissions assigned, you are ready to change your quorum type.

Figure 20 — Change your quorum type. Figure 22 — Choose your file share witness. Figure 24 — A successful quorum change. 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. I will also have a post on considerations for multi-node clusters of three or more nodes. We […]. Thank you for sharing. I have question can we install sql r2 failover cluster on a windows domain controller.

The domain though is used exclusively for centralized admin accounts, and because clusters need them. If you have a very active domain, you will want to put the domain controller on a different system for scalability. Note that you can no longer do this in Windows R2. If you promote a cluster node to a DC, the cluster service no longer functions properly. As soon as you remove the DC service, the cluster service functions again as normal.

I wish Microsoft would not have done this. For my scenario which is not typical , it makes sense to have the cluster and DC on the same box. I use a wordpress. I have a question. What if i have 2 sites; on primary site i have 2 nodes and on secondary i have 2 nodes with file share majority.

You really need to have a look at these articles to understand what node will come into service next. If you need site preference you do , let Microsoft know!

First — thanks for the excellent articles — they really helped me deal with the fun of installing SQL Server on a Windows R2 cluster. Depending on your licensing you should only need to license the active instances.

Now there are rules governing this process so be sure to consult microsoft documentation or give them a call. You don't normally have to have a license for a passive node in a cluster so long as the specs are the same number of CPUs for example. But again, rules are in place that determine how long a cluster can be failed over to a "passive" node before it is failed back etc. Generally people would suggest each group follows their best practice..

This equates to 6 volumes 3 in each group and another potential one for the quorum but this is not required for a majority nodeset of 3 nodes. Its a good idea to preconfigure the failover node to double RAM of the primary nodes just in case it takes both nodes. Or I setup an automatic procedure to reset the MAX memory upon failover depending on the node. Elliott Whitlow.

I think you need to understand the cluster quorum settings because for a three node cluster the only way to allow a 2 of 3 failure is the No Majority Quorum setting. Node Majority - Purely the number of nodes running, for 3 nodes you can lose 1, a loss of two means cluster down.

Node and Disk Majority - Number of nodes running plus a disk quorum, would not be recommended because as far as counts go it is still basically the same as 1. No Majority - Just a disk quorum, can handle an all but one failure but a failure of the Quorum drive for ANY reason brings the whole cluster down. Short answer, You can sustain a single node failure in a 3 node cluster in the recommended setup. I don't think 4 is ever recommended. I believe the rule is 30 days.

And you only have to license active nodes. And standard SQL is ok on enterprise windows. It will never allow a clustered SQL instance to allow for 3 possible nodes.. It checks during the install.. I am upgrading to enterprise and per my call with MS the grace period has increased to 90 days now.

I try not to go to enterprise unless I need to, basically due to costs. Here is that completed work. This is built in Blog Part 1 and 2. This is built in Blog Part 3. Figure 10 — Installation successful! This second Node is configured exactly like the first Node. Figure 32 — I add the current Cluster Node bo1-node-1 and the targeted Cluster Node bnode-2 to this process of Validation.

I am confident, as all three Cluster Nodes are configured exactly the same! Figure 43 — Moving back to Cluster Node 2 bnode