locked
Moving an Instance from non-clustered to clustered? RRS feed

  • Question

  • Hello,

    There is a non-clustered SQL 2008 R2 instance on Windows 2008 R2 (node1). There is also another identical server (node2). The app owner wants us to make the existing instance clustered while keeping the instance name and minimum downtime. What would be the best way to do that?

    If we are allowed to change the instance name, I would;

    - Install "Failover Clustering" feature

    - Config SAN

    - Install a new named-clustered sql insance

    - Copy databases, replication setup etc.

    - Remove the local(non-clustered) instance

     

    But, I can not think how we can keep the same instance name without removing the existing instance first.

    Any idea?

     

    Thanks,

     

    Kuzey

    Wednesday, September 22, 2010 8:15 PM

Answers

  • I think the challenge here is not wanting to make any modifications in the application connection string. However, you need to understand that when you create a Windows and SQL Server cluster, you will be creating two entries in both Active Directory and DNS for the Windows virtual server name and the SQL Server virtual server name (an additional entry for each SQL Server clustered instance will be created). Here's what you can do
     
    1) Install the new SQL Server clustered instances on the new Windows cluster. You can have the same configuration as you had before - one default instance and 4 named instances  - but with a different virtual server name
    2) Update the DNS entry of your existing hostname running the existing SQL Server instances to point to the virtual IP address of the SQL Server virtual server name. The challenge here is creating a SQL Server virtual server name that has the same hostname as the old server for the named instances. This will be dependent on how you configure the SQL Server named instances on your cluster
     
    If you're thinking of clustering a non-clustered Windows Server 2008 R2 machine, you can't just do that directly. You have to create the Windows cluster first before you can install the SQL Server failover cluster. So, with Node 2, you can create a single-node Windows cluster (not recommended as you'll never know if you'll hit any issues with the Windows cluster), install SQL Server Failover Cluster on the active node and, then, add a node in the SQL Server 2008 Failover cluster. Once all the SQL Server Failover Cluster instances have been installed and working, ask your system administrators to update the existing DNS entries to point to the virtual IP addresses. For minimal downtime, configure database mirroring between the instances. Once you are ready to failover, that's the time you change the DNS entries

    bass_player http://bassplayerdoc.blogspot.com/
    Thursday, September 23, 2010 10:44 PM

All replies

  • "how we can keep the same instance name without removing the existing instance first."

    Are you sure you are bound by the instance name and not the server name (or the virtual server name) . Its likely that you are using a default instance and continue to use that.

    On clusters each of the sql instance has its own IP and CAN listen on 1433. SO if you have a named instance listning on 1433 .. you need not specify the instance name.

    What the above means is virtual_server1\instance1 (listening on 1433) can be addressed as virtual_server1.

     

    Thursday, September 23, 2010 12:02 AM
    Answerer
  • Actually, there are one default and 4 named instances. All need to be clustered.
    Thursday, September 23, 2010 1:13 AM
  • The number of instances does NOT changes anything. Each of these instances could be listenign on thier respective 1433 port and be addressed by their virtual server name (wo specifying the instance name) as if they were default instances (in case thats what you want).

    btw - one thing that you should keep in mind is .. all these 5 instances once clustered will have their own unique network name. Ensure your app are compatible with that. That would be one big change once you move to clusters.

    Thursday, September 23, 2010 2:51 AM
    Answerer
  • I think the challenge here is not wanting to make any modifications in the application connection string. However, you need to understand that when you create a Windows and SQL Server cluster, you will be creating two entries in both Active Directory and DNS for the Windows virtual server name and the SQL Server virtual server name (an additional entry for each SQL Server clustered instance will be created). Here's what you can do
     
    1) Install the new SQL Server clustered instances on the new Windows cluster. You can have the same configuration as you had before - one default instance and 4 named instances  - but with a different virtual server name
    2) Update the DNS entry of your existing hostname running the existing SQL Server instances to point to the virtual IP address of the SQL Server virtual server name. The challenge here is creating a SQL Server virtual server name that has the same hostname as the old server for the named instances. This will be dependent on how you configure the SQL Server named instances on your cluster
     
    If you're thinking of clustering a non-clustered Windows Server 2008 R2 machine, you can't just do that directly. You have to create the Windows cluster first before you can install the SQL Server failover cluster. So, with Node 2, you can create a single-node Windows cluster (not recommended as you'll never know if you'll hit any issues with the Windows cluster), install SQL Server Failover Cluster on the active node and, then, add a node in the SQL Server 2008 Failover cluster. Once all the SQL Server Failover Cluster instances have been installed and working, ask your system administrators to update the existing DNS entries to point to the virtual IP addresses. For minimal downtime, configure database mirroring between the instances. Once you are ready to failover, that's the time you change the DNS entries

    bass_player http://bassplayerdoc.blogspot.com/
    Thursday, September 23, 2010 10:44 PM