February 1, 2005 at 11:27 am
Has anyone successfully transferred San disk resources from one cluster to another.
Our test failed this weekend. Part of our procedure was to change the disk signature of the SAN disk resources to matche what the target server had with its current San disk resources. The rename removed the disk from the cluster resources while the disk could still be seen by a node.
Jim Schellenberg
February 1, 2005 at 12:21 pm
Did you shut down the servers involved prior to making the disk changes?
Given that the cluster service keeps a track of whats going on, I wonder if having the servers up while changes were made screwed things up for you.
February 1, 2005 at 12:38 pm
The "source" cluster was shut down before the change in disk signatures took place. The change was done on the "target" server.
February 1, 2005 at 12:42 pm
Was the target server shut down also?
February 1, 2005 at 2:02 pm
The initial steps are
1. Shutdown SQL Servers on both "source" and "target" clusters
2. Get the disk signatures of both machines' disks
3. Power off both nodes in both clusters
4. Disconnect data drives from "target" cluster. Leave Quorum drive.
5. Using SAN commands, reassign "source" cluster disk resources, data only, not quorum, to "target" cluster.
6. Power up "target" cluster. Cluster manager showed original "target" cluster data drives plus additon data drives that came from "source" cluster. The "source" cluster stayed powered off.
7. Used disk manager to reassign drive letters on each node.
8. Changed disk signatures. Drives disappeared.
9. Recovery was required. There are more steps but the above give a basic description of the attempt to get the SAN resources to the "target" cluster.
February 2, 2005 at 6:22 am
Do you need to change the signatures?
If you have basic disks I am not sure that there is a guid type disk signature written that windows needs to understand.
February 2, 2005 at 6:55 am
If you are using dynamic disks then you are likely to have problems in what you are doing.
Each server has its own Windows (i.e. Access-format) database of information about dynamic disks. If you import a dynamic disk from another server the receiving server will recognise the disk as foreign. Our experience is that sometimes the server will accept the disk, while other times the disk vanishes from the disk administation GUI. In the latter case if you reboot the server the disk can be seen again.
The only solution we could find was to define disks that could move from server to server as basic disks. With a basic disk, there is no entry in the dynamic disk database, and no issues (so far) in importing a disk from another server.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
February 2, 2005 at 9:49 am
Are you required to change disk signatures with basic disks?
I checked our configuration this morning. The "source" cluster has only basic drive definitions to describe its SAN disk resources. The "target" cluster uses basic drive definitions as well for SAN disk resources although it has a 0MB size Dynamic disk that appears to be unused at this time.
February 3, 2005 at 12:42 pm
Clusters uses disk signatures to identify the disks and not the logical drives.
We used the clusterrecovery.exe utility for swapping SAN disk on our cluster. It is built into the windows 2003 resource kit and is compatible with windows 2000. We didn't have any issues using this utility. Below is the link to th ewindows 2003 resource kit. The clusterrecovery.chm document has a detailed explaination of the process.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply