Installing two SQL clusters with a shared failover partner

  • I'm trying to locate information regarding the two node clustering capabilities of SQL 2008 Standard Edition.

    What I'd like to do is install two active/passive SQL clusters using the same physical server as the passive node for both SQL clusters. This would be a three-node Windows cluster, with two two-node SQL clusters installed.

    It seems like it should be possible, as SQL 2008 SE supports two-node clustering, but I can't find anything definitive that answers the question.

    Does anyone out there have information about this?

    Thanks!

  • I'm fairly certain you cannot do exactly what you are asking. Different clusters cannot share a machine. Either the machine belongs to one cluster or the other.

    But...Why not just have a 3 or 4 node cluster ? You make the decision for one of the nodes to not be utilized unless a failover occurs.

    I currently have 5 of my 6 nodes operating in a cluster with 6 instances running on it. One of my nodes will remain empty as a designated failover for the applications that "say" they require having a passive node to be supported...cough...OCS....cough....

    db

    PS If you have any more questions please ask.

  • Sorry , I also did not answer the other part of your question. You are limited to 2 nodes with SQL 2008 Standard. You can have 16 nodes with Enterprise assuming you are running on top of Windows 2008.

    The page below has the information.

    http://msdn.microsoft.com/en-us/library/cc645993.aspx

    db

  • I appreciate the response, but I don't think you understand what I was asking. I don't want to share a machine between two clusters.

    I want to make a three node cluster of Windows EE servers. On that cluster, I want to install two two-node SQL SE clustered instances.

    In my case, I would install an instance "JDE" as a SQL failover clustered application on SERVER1 and SERVER3. Then I would install an instance "Siebel" as a SQL failover clustered application on SERVER2 and SERVER3 in the same cluster. This way, the two SQL servers are running on SERVER1 and SERVER2. If either one fails, it will move to SERVER3. That's the plan, anyway.

    Both SQL clusters would be two-node clusters, on a three-node Windows cluster.

    There's an article at experts-exchange http://www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/SQL-Server-2005/Q_23641304.html

    indicating that it can be done, but I was hoping to find a more reputable source.

    I'll just have to try it and see.

  • Sorry i misunderstood. The way you said it seemed odd.

    You can absolutely do what you want to do. Say you had 3 nodes (A,B,C) and 2 clustered SQL instances.(S1,S2).

    You would just choose where to install the binaries for S1 & S2.

    So for example A & B would have the binaries for S1 installed.

    B & C would have the binaries for S2 installed.

    That way each SQL instance would have 2 possible homes.

    But on a side note why not just go ahead and install the binaries for S1 & S2 on A,B & C that way, just in case , you have another failover location. You could during normal times not allow the 3rd node to be an owner of the SQL instance but in an emergency you could just check a box and fail it there (strange patching error or something...).

    db

  • Err. your SE part of the question escaped me again. I need to stop replying this early in the morning. In my opinion based on the wording of the installation steps you should be able to do what you want with standard edition. Because when you install the instance the first time it actually says install a cluster. and then you would only add it to one more node. During all of the steps of installation SQL is actually talking to and checking the other nodes. And then you would run the install a cluster again and add it to the other node. so you would have 2 clustered resources on 2 nodes. that should fall under the limitations on SE SQL.

    db

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply