installation folders are unique to the instance of SQL Server 2008

  • Hi,

    I'm going through the document "SQLServer2008FailoverCluster" and from that documnet:

    Important: If you specify nondefault installation directories, make sure that the installation folders are unique to this instance of SQL Server. None of the directories in this dialog box should be shared with directories from other instances of SQL Server. The data directories should be located on the shared cluster disk for the failover cluster

    Currently, we have 3 node active/active/passive cluster setup for SQL Server 2005. On node1, we have one instance and on node3, we have 4 instances and node2 is passive.

    On node3, We have a Backup group, which has the disk resource K and we keep all the 4 instances database backups on the same disk Z.

    Is this NOT supported in SQL Server 2008 according to above statement. Please correct me if I understand incorrectly? Because we are planning to perform in-place upgrade to SQL Server 2008.

    Thanks

  • I don't think that statement applies to what you are asking which is basically about a backup drive and NOT the drives that hold the data files for SQL.

    In a three node cluster, or even a two node, only one resource group can have the Z:\ drive, so it would be unavailable to the other nodes. I think you should have a backup drive that is tied to the resource group for the SQL server, that guarantees that it will always be available.

    Better yet, don't backup to a local drive, backup to a file server so you don't have to worry about local drives at all..

    Is any of that clear?

    CEWII

  • We have a common backup group, which has a Z drive in it, for all all the instances on node3. The Z drive it NOT tied to a single SQL Group.

  • Ok, so what happens to backups when the SQL servers on Node 3 failover to Node 2 or Node 1?

    CEWII

  • Our cluster is configured as below:

    SQL Server instances on node3 can only failover to node2 (passive) and SQL Server instances on node1 can only failover to node2(passive) but node3 cannot failover to node1 & node1 cannot failover to node3

    on node1, we have one backupgroup1 (has Z drive) and node3, we have one backupGroup2(has T drive)

    Ok, so what happens to backups when the SQL servers on Node 3 failover to Node 2 or Node 1?

    The backupGroup1 moves to node2 when the SQL servers on Node 1 failover to Node 2

    The backupGroup2 moves to node2 when the SQL servers on Node 3 failover to Node 2

    On node3, we have 4 instances and have 4 SQL Groups in cluster administrator. We do not have enough drive letters to keep separate backup drive in each SQL group. So we went with common back drive by creating a separate backupgroup.

    Thanks

  • That is a lot clearer.. I would probably have switched to backing up to a file server instead of local drives, but that is me..

    CEWII

  • That is a lot clearer.. I would probably have switched to backing up to a file server instead of local drives, but that is me..

    Disk Z & Disk K are NOT local drives. They are also Shared Drives..

    Thank you

  • So they exist on a SAN or are they on some kind of local storage array? I'm trying to get your topology in mind..

    CEWII

  • So they exist on a SAN or are they on some kind of local storage array? I'm trying to get your topology in mind..

    Yes, the backup disks also exist on SAN. Here is the topology:

    Node1 (Active): Node1 has one SQL Server instance

    Groups Disks SQL instance

    SQLGroup1 D, E, F, T INS1

    BackupGroup1 Z

    Node3 (Active): Node3 has Four SQL Server instances

    Groups Disks SQL instance

    SQLGroup2 G, H, U INS2

    SQLGroup2 I, J, V INS3

    SQLGroup2 L, M, W INS4

    SQLGroup2 N, O, X INS5

    BackupGroup2 K

    Thanks

  • I have to admit I would spend some time and re-architect the whole drive layout. You could reduce the number of drives used from 18 (that is what is looks like, not sure whether to count INS1, 2, 3, 4, 5 as drives) to 4 (in addition to C and Q) and still maintain the existing spindle seperation.. The solution uses mount points.

    Here is a link to the MSDN article on it:

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

    CEWII

Viewing 10 posts - 1 through 9 (of 9 total)

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