Microsoft has announced that some of the most widely anticipated availability options being introduced with SQL Server 2012, including AlwaysOn Availability Groups, will only be available with the Enterprise Edition of SQL. The cost of SQL Server Enterprise is $27,496 for any server that has up to 4 physical processors vs. $7,172 for Standard Edition. If you plan on taking advantage of the “Read-Only” replica, you can double the cost of the solution ($54,992) since you have to license both the source and the target server. When you start talking about that kind of money, you begin to wonder if there is an alternative to AlwaysOn Availability Groups.

The good news is that Microsoft still allows you to build 2-node clusters using SQL Server Standard Edition, and since this is generally deployed in an active-passive configuration you do not have to license the standby server. So for $7,172 you can build a pretty robust 2-node SQL cluster, assuming you have an enterprise class SAN that you can use to store your cluster data.

What’s that you say, you don’t have a SAN? Or you’d rather build a solution that eliminates the SAN as a single point of failure and instead allows you to use data replication to keep the data in sync between cluster nodes the way that AlwaysOn Availability Groups allows you to? Or perhaps you want to use take advantage of the speed offered by local attached SSD drives such as those offered by Fusion-IO, but yet don’t want to give up on availability?

You’ll be glad to know that for the cost of a single copy of SQL Server 2012 Standard Edition and the very affordable addition of SteelEye DataKeeper Cluster Edition, you’ll be able to deploy 2-node SQL Server 2012 Standard Edition clusters with data replication for about half the cost of a 2-node SQL Server Enterprise Edition AlwaysOn Availability Group and about ¼ of the price of a AlwaysOn Availability Group with read-only targets.

Not only will you be able to save money, but if you answer yes to any of the following questions, AlwaysOn Availability Groups probably wasn’t the best solution for you to begin with and you would be better served by Windows Server Failover Clustering and DataKeeper Cluster Edition.

• Am I concerned about the cost of SQL Server Enterprise Edition?
• Do I use replication or log shipping?
• Do I need to support Lync Server or other applications that use distributed transactions?
• Do I need to ensure that SQL Agent jobs such as database backups, optimizations, DTS and others continue to run regardless of the node in service?
• Do I need to ensure that SQL login accounts are kept in sync between cluster nodes?
• Do I want to minimize my administrative burden?

The following chart summarizes your SQL Server 2012 availability options, including the 3^rd option which is to build a traditional SQL cluster using Windows Server Failover Clustering with DataKeeper Cluster Edition.

As you can see, Failover Clustering with DataKeeper Cluster Edition is not only going to save you money, it also is going to help you overcome some of the inherent limitations of AlwaysOn Availability Groups.

About the only thing you can’t do with the DataKeeper solution is to have read-only targets. As I mentioned earlier, read-only targets requires a second SQL license, so to have that feature will cost you minimally $54,938. If you really must have read-only targets you’ll be glad to know that you can mix AlwaysOn Failover Clusters with DataKeeper and AlwaysOn Availability Groups if you like. Basically you would wind up with a 2-node SQL failover cluster with DataKeeper and a single standalone SQL Server acting as a read-only target for an AlwaysOn Availability Group. In that case, you would still need two copies of SQL Server Enterprise Edition, one for the cluster and one for the read-only target.

I demonstrated this solution at Tech-Ed 2011 in Atlanta last year and got a lot of really positive feedback. This particular demonstration shows a 2-node multisite cluster, but the same concept can be applied to single site clusters.

http://clusteringformeremortals.com/2011/05/15/sql-server-denali-hadron-multisite-cross-subnet-failover-video-demonstration/

If you have any questions about this article please leave me a comment, I’d be glad to discuss it with you further.

Microsoft recently released a patch that allows you to specify whether or not a cluster node can vote in in a majority quorum model. This is particularly useful in a multisite cluster configuration that consists of an even number of nodes.

http://support.microsoft.com/kb/2494036

Consider the following…

I have a two node cluster in a local site high availability and I wish to extend it to a 3^rd location and add a single node for disaster recovery. Sound like a great plan as a multisite cluster is just about the most robust DR plan you can implement. However, you will not be able to take advantage of one of the best features of a multisite cluster – automatic recovery in the event of a site loss. If you were to lose your primary site the DR site only contains one cluster node (see Figure 1). This is just one vote out of three in the cluster so a majority cannot be obtained and Node3 will not come online automatically. The only way to make Node3 come online is to force the quorum online, which kind of defeats the purpose of multisite cluster by requiring human intervention for a failover to happen.

Figure 1 – In a typical 3 node multisite cluster if you lose the primary site the DR site cannot obtain majority so failover never occurs.

The only “safe” way to have automatic failover in a multisite cluster is to have an equal number of nodes in each site and to have a file share witness in a 3^rd location with connectivity back to both the primary site and the DR site. This concept is a little difficult to grasp at first, so let me attempt to explain through illustrations.

Figure 2- With an even number of nodes in both locations and the file share witness in the primary site a loss of the primary site would not result in a failover as the Alternate Site would only have 2 out of 5 votes, not a majority.

Figure 3 – If the file share witness was moved to the Alternate Site a failure of the WAN would cause a false failover as the Alternate Site would form a majority and come online.

Figure 4 – with the file share witness in a 3rd location failover will occur if the Primary Site is lost and false failovers are avoided in the case of connectivity failure between the Primary and Alternate Site.

As you can see, figure 4 represents the only reasonable configuration which supports automatic failover. However, this assumes that there are an equal number of nodes in each location. If you are stuck with the original 3-node configuration you are stuck as adding a file share witness does not help as you can never achieve a majority in the alternate site…until today! Microsoft release a patch that basically allows you to specify whether or not a node gets to vote or not. So what this means is you can build a 3-node cluster as illustrated in Figure 1, yet take advantage a file share witness in a 3^rd location as illustrated in Figure 4. By simply telling one of the nodes in the Primary Site to note vote in the cluster you will allow the Alternate Site to form a majority with the file share witness and come online. Assuming connectivity to your 3^rd location and Alternate Site is relatively reliable there really is no downside to the configuration shown in Figure 5.

Figure 5 – by disabling the vote on Node2 you can deploy a 3-node multisite cluster with a file share witness and safely support automatic failover to the DR site. The same concept can be applied to any cluster with an odd number of nodes.

While this is a great solution, you still need that 3^rd location for the file share witness. If you don’t have that 3^rd location you will just have to settle for a manual switchover and keep the file share witness in the primary site if you have an even number of nodes.

The PreventQuorum switch is also included as part of this hotfix which will also be of interest to people deploying multisite clusters. Well explore that option in a future article.

Get the hot fix here…

A hotfix is available to let you configure a cluster node that does not have quorum votes in Windows Server 2008 and in Windows Server 2008 R2

http://support.microsoft.com/kb/2494036

Introduction

The following are the high level steps required to turn an existing 2-node File Server cluster into a 3-node multisite cluster using SteelEye DataKeeper Cluster Edition. The same steps can be applied to most cluster resource types including Hyper-V, DHCP, Generic Service, etc. However, if you are working with a SQL Server cluster the steps will be slightly different as adding a node to the cluster is done through the SQL installation process and not the Failover Cluster Manager.

These instructions assume you have at least base level knowledge of Windows Server Failover Clustering and some familiarity with SteelEye DataKeeper Cluster Edition. Also, these instructions do not address any changes which may be required to support cross subnet failover utilizing the new “OR” functionality introduced in Windows Server 2008 R2. For further information on deploying multisite clusters refer to the following resources:

• http://support.microsoft.com/kb/947048/en-us
• http://download.microsoft.com/download/8/C/2/8C21BAFE-3432-48D1-962A-F7A9DD54A2AC/Multi-Site%20Clustering%20with%20Windows%20Server%202008%20Enterprise.pptx
• http://www.microsoft.com/windowsserver2008/en/us/failover-clustering-multisite.aspx

Step 1 – Start with a traditional shared storage cluster

Step 2 – Remove any Physical Disk resources from the clustered service

Step 3 – Delete the Cluster Disk from Available Storage

Step 4 – Bring the shared volume Online on all cluster nodes

Step 5 – Verify that the volumes brought online all have the same drive letter across cluster nodes. At this time Disk Management may not display the drive letters but you should be able to verify the drive letters through Windows Explorer.

Step 6 – Change your Quorum type to node majority (if you will have an odd number of nodes) or Node and File Share Majority (if you have an even number of nodes).

Step 7 – Delete the volume resource that is in Available Storage

Step 8 – Create your mirror

Step 9 – Add the remote Node to the cluster*

* IMPORTANT NOTE
If you are using Windows Server 2008 R2 SP1 , you must not do this step through the Failover Cluster Manager GUI. Changes were made in SP1 to support symmetric storage however these changes actually make deploying multisite clusters more complicated in some circumstances. If you are using SP1 and want to add a node to a multisite cluster that is using a 3^rd party storage class resource like DataKeeper, the only way to add a node without causing the cluster disks resources to be added back into the cluster (which really causes a mess to clean up) is to use PowerShell to add the node as described here http://technet.microsoft.com/en-us/library/ee461047.aspx

Step 10 – Add the DataKeeper Volume Resource

Step 11 – Change the DataKeeper Volume Parameters to associate it with the replicated volume

Step 12 – Redefine the cluster dependencies

Step 13 – Test your new multisite cluster

Keep in mind that only a shared source or the current target of a mirror can come online; you cannot bring a shared target online if it is not the current target of the mirror. In an unexpected failure Windows will follow the preferred owners list until it finds a node that is available to come online. In a manual Online if you try to bring a node Online that is not a shared source or a current target the Online will fail and the current node will remain online. Check the DataKeeper GUI to verify which node is currently the target of the mirror.