Windows 2003/SQL 2000 Cluster SAN Migration

I have a Window 2003 Ent. Server Cluster running SQL 2000. We need to move
of our current SAN to a new SAN and I don't want to do a full reinstall so I
was looking for an easy way to do it. This site
http://expertanswercenter.techtarget...981988,00.html
has an approach but it only partly work, i.e. I was able to move the quorum
just fine but not the data drives, basically on step 14 my old drives popped
right back in place with their original drive letters back. I'm guessing
its because on a Win2003 Cluster the drive signatures can't just be deleted
out of the registry like it says in step 12. So does anyone know the steps
to change/move my data drives?

Here is a copy of the steps from that site in case it goes down:
1.. In the new storage array, pre-configure your LUNs to match your
current environment. Set any LUN security or switch zoning to provide access
to an HBA in nodeB of the cluster.
2.. Insert a new HBA into NodeB in the cluster. If the server is already
dual homed, connect one HBA to a SAN port that has access to the new storage
array.
3.. Update the HBA drivers to the correct revision for the HBA connected
to the new array.
4.. Reboot nodeB, and verify access to the new LUNs via NT disk admin, or
on Win2k, under the manage disks MMC. Create an NTFS partition on the LUN
configured for the cluster quorum resource in the new array, and do a quick
format.
5.. Migrate ALL Cluster resources to nodeB.
6.. In cluster admin, create a new disk resource for the new quorum disk,
and move quorum to the new disk. The cluster will now have all application
resources on the old array, and have quorum configured for the new array.
7.. Install or move an HBA in nodeA, update the driver, and verify
connection to the new LUNs. Shut down nodeA and power it off.
8.. On nodeB, go to control panel, and stop the cluster resources
(Cludisk, and cluster service) and set the services to start manually.
9.. On nodeB, run disk administrator and document the disk labels, drive
letters, and physical disk numbers for the existing cluster resource disks.
10.. On nodeB, run the registry editor and go to HKLM/Current control
set/services/Clusdisk, and make note of the actual disk signatures assigned
to the cluster resources. Document the physicaldisk and drive numbers for
these drives. You will need this information so you don't delete the new
quorum disk signature by mistake in step 12.
11.. On NodeB run disk administrator, and create a mirror set between the
old resource disks and the new LUNs in the new array. The mirrors will now
synchronize, and should take between 50-60GB per hour to complete. Once
complete, remove the connection to the old disk array on nodeB.
12.. Reboot nodeB, go into registry editor, and delete the disk signatures
from the ClusDisk registry entry for all disks EXCEPT THE QUORUM RESOURCE!!,
if you delete the quorum disk signature by mistake, you are out of luck. Use
the information gathered in steps 9 and 10 to determine the disk signature
of the quorum disk. (If the signatures are not deleted here, you will never
be able to get back to the same drive letters as the original cluster
disks!)
13.. On nodeB, run disk administrator, and re-letter the new drives to the
original drive letters documented in step 9. Go to control panel, and reset
the cluster services to startup automatic.
14.. Reboot nodeB, and verify the cluster comes up normally.
15.. Reboot nodeA, and verify you can fail over resources to nodeA. (when
nodeA reboots, it pulls the registry info for the new cluster disks from
nodeB. The ClusDisk registry entries are rebuilt automatically by nodeB when
it was rebooted). If nodeA has troubles coming up, evict the node from the
cluster, de-install clusters from the node, and then rejoin nodeA back into
the cluster with nodeB.

Hi Opus,

I have not had anyone call me regarding a Cluster SAN migration running SQL, but you may want to post your original posting to the SQL newsgroup. WIth SQL
running on the Cluster may take a little more of planning to ensure migration is successful.

But I had a call not too long ago that was planning on moving Windows 2003 File Share Cluster that's in production from one SAN to a new SAN. Here are the
resolution steps I gave him that worked like a charm as they put it.

RESOLUTION:
Since you don't have many File Shares resources, here's what we discussed you should do:

1. Remove the disk dependency fro each of the File Share resources.
2. Delete the Physical Disk resource.
3. Set Cluster Service to Manual on all 3 nodes.
4. Set the Cluster Disk Driver to Disabled in Device manager on all 3 nodes.
5. Move all 3 servers over to the new location.
6. Attach to the new SAN.
7. Bring up one node at a time to ensure disk and drive letters match up on all 3 nodes.
8. Use DUMPCFG to re-stamp the Quorum disk with the previous signature that was used which is ed440bf1.
9. Ensure all 3 nodes can copy an delete a small file to the root of each drive.
10. Make sure all nodes are powered down except for one, on the one powered on enable the Cluster Disk Driver and set the Cluster Service back to
Automatic and reboot.
11. Add the first Physical Disk resource and it will be in an Offline state, before bringing it Online go to the Properties and on the Advanced tab uncheck "Affect
the group".
12. Bring that Physical Disk Online.
13. If it come Online fine, then take it back Offline go to the Properties and on the Advanced tab check "Affect the group" and add the Physical Disk as a
dependency on all the File Share resources that needs it.
14. Repeat steps 11-13 for all the File Share resources.
15. Once everything is Online on one node, then begin to power on one node at a time and repeat step 10.

--
Hope this helps,
Mike Rosado
Windows 2000 MCSE + MCDBA
Microsoft Enterprise Platform Support
Windows NT/2000/2003 Cluster Technologies

====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
<http://www.microsoft.com/info/cpyright.htm>

-----Original Message-----
> Reply-To: "Opus" <closed@msn.com>
> From: "Opus" <closed@msn.com>
> Subject: Windows 2003/SQL 2000 Cluster SAN Migration
> Date: Fri, 1 Apr 2005 02:54:08 -0600
>
> I have a Window 2003 Ent. Server Cluster running SQL 2000. We need to move
> of our current SAN to a new SAN and I don't want to do a full reinstall so I
> was looking for an easy way to do it. This site
> http://expertanswercenter.techtarget...981988,00.html
> has an approach but it only partly work, i.e. I was able to move the quorum
> just fine but not the data drives, basically on step 14 my old drives popped
> right back in place with their original drive letters back. I'm guessing
> its because on a Win2003 Cluster the drive signatures can't just be deleted
> out of the registry like it says in step 12. So does anyone know the steps
> to change/move my data drives?
>
> Here is a copy of the steps from that site in case it goes down:
> 1.. In the new storage array, pre-configure your LUNs to match your
> current environment. Set any LUN security or switch zoning to provide access
> to an HBA in nodeB of the cluster.
> 2.. Insert a new HBA into NodeB in the cluster. If the server is already
> dual homed, connect one HBA to a SAN port that has access to the new storage
> array.
> 3.. Update the HBA drivers to the correct revision for the HBA connected
> to the new array.
> 4.. Reboot nodeB, and verify access to the new LUNs via NT disk admin, or
> on Win2k, under the manage disks MMC. Create an NTFS partition on the LUN
> configured for the cluster quorum resource in the new array, and do a quick
> format.
> 5.. Migrate ALL Cluster resources to nodeB.
> 6.. In cluster admin, create a new disk resource for the new quorum disk,
> and move quorum to the new disk. The cluster will now have all application
> resources on the old array, and have quorum configured for the new array.
> 7.. Install or move an HBA in nodeA, update the driver, and verify
> connection to the new LUNs. Shut down nodeA and power it off.
> 8.. On nodeB, go to control panel, and stop the cluster resources
> (Cludisk, and cluster service) and set the services to start manually.
> 9.. On nodeB, run disk administrator and document the disk labels, drive
> letters, and physical disk numbers for the existing cluster resource disks.
> 10.. On nodeB, run the registry editor and go to HKLM/Current control
> set/services/Clusdisk, and make note of the actual disk signatures assigned
> to the cluster resources. Document the physicaldisk and drive numbers for
> these drives. You will need this information so you don't delete the new
> quorum disk signature by mistake in step 12.
> 11.. On NodeB run disk administrator, and create a mirror set between the
> old resource disks and the new LUNs in the new array. The mirrors will now
> synchronize, and should take between 50-60GB per hour to complete. Once
> complete, remove the connection to the old disk array on nodeB.
> 12.. Reboot nodeB, go into registry editor, and delete the disk signatures
> from the ClusDisk registry entry for all disks EXCEPT THE QUORUM RESOURCE!!,
> if you delete the quorum disk signature by mistake, you are out of luck. Use
> the information gathered in steps 9 and 10 to determine the disk signature
> of the quorum disk. (If the signatures are not deleted here, you will never
> be able to get back to the same drive letters as the original cluster
> disks!)
> 13.. On nodeB, run disk administrator, and re-letter the new drives to the
> original drive letters documented in step 9. Go to control panel, and reset
> the cluster services to startup automatic.
> 14.. Reboot nodeB, and verify the cluster comes up normally.
> 15.. Reboot nodeA, and verify you can fail over resources to nodeA. (when
> nodeA reboots, it pulls the registry info for the new cluster disks from
> nodeB. The ClusDisk registry entries are rebuilt automatically by nodeB when
> it was rebooted). If nodeA has troubles coming up, evict the node from the
> cluster, de-install clusters from the node, and then rejoin nodeA back into
> the cluster with nodeB.
>
>
>

Hi Opus,

I have done this before and it works fine :-) Plz try the following steps -
Assumptions (if any of those assumptions are not there, then plz advice and
i will try to find the appropriate solution)
1) The machines will not change
2) The storage will be changed
3) the 2 SANs will be accessible to the cluster at the same time, for the
migration purpose. After the migration you can pull out the old storage.
4) assume the Old disk drive is O: and the New disk Drive is N:


Steps I followed:
1) Backed the disks up :)
2) Backed the disk signatures/geometry. You can use "confdisk.exe" to do
that.
3) On the new SAN create a new partition that you will use for the SQL. Name
the disk N:\
4) Create a new Disk Resource for the new disk and have that in the SQL
group.
5) Offline the SQL resource (so that no one would be writing to the disk
anymore)
6) Keep the disk resources online.
7) using a copy utility replicate the data from the old drive to the new
drive, make sure to copy the correct ACL's/attributes/etc...
The " /o " switch with xcopy does copy the ACL's. You can also ntbackup then
restore the data. Use whatever tool you are comfortable with to replicate
the data.
8) Now Add the new disk as a dependency for the SQL resource. The SQL
resource at this point of time will have 2 disk dependencies: Disk O: and
Disk N:
9) Go to disk management. Rename the Old disk drive from O: to X:
10) Rename the New disk drive from N: to O:
11) back to cluster administrator, rename the resource from "Disk O:" to
"Disk X:"
12) rename the resource from "Disk N:" to "Disk O:"
13) remove the "Disk X:" dependency from the SQL resource. Now it should
only have one disk dependency "disk O:"
14) I would go to the advanced properties of the SQL resource, and set it to
"Do not restart". (just in case things dont go well, you dont want the
resource failing back in forth between the nodes)
15) try to online the SQL resource


Does it work?
Then go back to Advanced tab in properties and set it to "Restart"


Does it fail?
Go the event viewer and check the system and the application events. Does it
shed any light on the problem?



--
Thanks,
Loay Shbeilat
MSCS Admin Tools STE

"This posting is provided "AS IS" with no warranties, and confers no
rights."

"Opus" <closed@msn.com> wrote in message
news:e$ZZdhpNFHA.3704@TK2MSFTNGP12.phx.gbl...
>I have a Window 2003 Ent. Server Cluster running SQL 2000. We need to move
>of our current SAN to a new SAN and I don't want to do a full reinstall so
>I was looking for an easy way to do it. This site
>http://expertanswercenter.techtarget...981988,00.html
>has an approach but it only partly work, i.e. I was able to move the quorum
>just fine but not the data drives, basically on step 14 my old drives
>popped right back in place with their original drive letters back. I'm
>guessing its because on a Win2003 Cluster the drive signatures can't just
>be deleted out of the registry like it says in step 12. So does anyone
>know the steps to change/move my data drives?
>
> Here is a copy of the steps from that site in case it goes down:
> 1.. In the new storage array, pre-configure your LUNs to match your
> current environment. Set any LUN security or switch zoning to provide
> access to an HBA in nodeB of the cluster.
> 2.. Insert a new HBA into NodeB in the cluster. If the server is already
> dual homed, connect one HBA to a SAN port that has access to the new
> storage array.
> 3.. Update the HBA drivers to the correct revision for the HBA connected
> to the new array.
> 4.. Reboot nodeB, and verify access to the new LUNs via NT disk admin, or
> on Win2k, under the manage disks MMC. Create an NTFS partition on the LUN
> configured for the cluster quorum resource in the new array, and do a
> quick format.
> 5.. Migrate ALL Cluster resources to nodeB.
> 6.. In cluster admin, create a new disk resource for the new quorum disk,
> and move quorum to the new disk. The cluster will now have all application
> resources on the old array, and have quorum configured for the new array.
> 7.. Install or move an HBA in nodeA, update the driver, and verify
> connection to the new LUNs. Shut down nodeA and power it off.
> 8.. On nodeB, go to control panel, and stop the cluster resources
> (Cludisk, and cluster service) and set the services to start manually.
> 9.. On nodeB, run disk administrator and document the disk labels, drive
> letters, and physical disk numbers for the existing cluster resource
> disks.
> 10.. On nodeB, run the registry editor and go to HKLM/Current control
> set/services/Clusdisk, and make note of the actual disk signatures
> assigned to the cluster resources. Document the physicaldisk and drive
> numbers for these drives. You will need this information so you don't
> delete the new quorum disk signature by mistake in step 12.
> 11.. On NodeB run disk administrator, and create a mirror set between the
> old resource disks and the new LUNs in the new array. The mirrors will now
> synchronize, and should take between 50-60GB per hour to complete. Once
> complete, remove the connection to the old disk array on nodeB.
> 12.. Reboot nodeB, go into registry editor, and delete the disk
> signatures from the ClusDisk registry entry for all disks EXCEPT THE
> QUORUM RESOURCE!!, if you delete the quorum disk signature by mistake, you
> are out of luck. Use the information gathered in steps 9 and 10 to
> determine the disk signature of the quorum disk. (If the signatures are
> not deleted here, you will never be able to get back to the same drive
> letters as the original cluster disks!)
> 13.. On nodeB, run disk administrator, and re-letter the new drives to
> the original drive letters documented in step 9. Go to control panel, and
> reset the cluster services to startup automatic.
> 14.. Reboot nodeB, and verify the cluster comes up normally.
> 15.. Reboot nodeA, and verify you can fail over resources to nodeA. (when
> nodeA reboots, it pulls the registry info for the new cluster disks from
> nodeB. The ClusDisk registry entries are rebuilt automatically by nodeB
> when it was rebooted). If nodeA has troubles coming up, evict the node
> from the cluster, de-install clusters from the node, and then rejoin nodeA
> back into the cluster with nodeB.
>
>

Thank you both for the replies, but I ended up using Loay since I was
already almost completed and it worked perfect!

THANKS!!!



"Loay Shbeilat [MS]" <loays@microsoft.com> wrote in message
news:%23aTyzcuNFHA.1268@TK2MSFTNGP14.phx.gbl...
> Hi Opus,
>
> I have done this before and it works fine :-) Plz try the following
> steps -
> Assumptions (if any of those assumptions are not there, then plz advice
> and i will try to find the appropriate solution)
> 1) The machines will not change
> 2) The storage will be changed
> 3) the 2 SANs will be accessible to the cluster at the same time, for the
> migration purpose. After the migration you can pull out the old storage.
> 4) assume the Old disk drive is O: and the New disk Drive is N:
>
>
> Steps I followed:
> 1) Backed the disks up :)
> 2) Backed the disk signatures/geometry. You can use "confdisk.exe" to do
> that.
> 3) On the new SAN create a new partition that you will use for the SQL.
> Name the disk N:\
> 4) Create a new Disk Resource for the new disk and have that in the SQL
> group.
> 5) Offline the SQL resource (so that no one would be writing to the disk
> anymore)
> 6) Keep the disk resources online.
> 7) using a copy utility replicate the data from the old drive to the new
> drive, make sure to copy the correct ACL's/attributes/etc...
> The " /o " switch with xcopy does copy the ACL's. You can also ntbackup
> then restore the data. Use whatever tool you are comfortable with to
> replicate
> the data.
> 8) Now Add the new disk as a dependency for the SQL resource. The SQL
> resource at this point of time will have 2 disk dependencies: Disk O: and
> Disk N:
> 9) Go to disk management. Rename the Old disk drive from O: to X:
> 10) Rename the New disk drive from N: to O:
> 11) back to cluster administrator, rename the resource from "Disk O:"
> to "Disk X:"
> 12) rename the resource from "Disk N:" to "Disk O:"
> 13) remove the "Disk X:" dependency from the SQL resource. Now it should
> only have one disk dependency "disk O:"
> 14) I would go to the advanced properties of the SQL resource, and set it
> to "Do not restart". (just in case things dont go well, you dont want the
> resource failing back in forth between the nodes)
> 15) try to online the SQL resource
>
>
> Does it work?
> Then go back to Advanced tab in properties and set it to "Restart"
>
>
> Does it fail?
> Go the event viewer and check the system and the application events. Does
> it shed any light on the problem?
>
>
>
> --
> Thanks,
> Loay Shbeilat
> MSCS Admin Tools STE
>
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>
> "Opus" <closed@msn.com> wrote in message
> news:e$ZZdhpNFHA.3704@TK2MSFTNGP12.phx.gbl...
>>I have a Window 2003 Ent. Server Cluster running SQL 2000. We need to
>>move of our current SAN to a new SAN and I don't want to do a full
>>reinstall so I was looking for an easy way to do it. This site
>>http://expertanswercenter.techtarget...981988,00.html
>>has an approach but it only partly work, i.e. I was able to move the
>>quorum just fine but not the data drives, basically on step 14 my old
>>drives popped right back in place with their original drive letters back.
>>I'm guessing its because on a Win2003 Cluster the drive signatures can't
>>just be deleted out of the registry like it says in step 12. So does
>>anyone know the steps to change/move my data drives?
>>
>> Here is a copy of the steps from that site in case it goes down:
>> 1.. In the new storage array, pre-configure your LUNs to match your
>> current environment. Set any LUN security or switch zoning to provide
>> access to an HBA in nodeB of the cluster.
>> 2.. Insert a new HBA into NodeB in the cluster. If the server is already
>> dual homed, connect one HBA to a SAN port that has access to the new
>> storage array.
>> 3.. Update the HBA drivers to the correct revision for the HBA connected
>> to the new array.
>> 4.. Reboot nodeB, and verify access to the new LUNs via NT disk admin,
>> or on Win2k, under the manage disks MMC. Create an NTFS partition on the
>> LUN configured for the cluster quorum resource in the new array, and do a
>> quick format.
>> 5.. Migrate ALL Cluster resources to nodeB.
>> 6.. In cluster admin, create a new disk resource for the new quorum
>> disk, and move quorum to the new disk. The cluster will now have all
>> application resources on the old array, and have quorum configured for
>> the new array.
>> 7.. Install or move an HBA in nodeA, update the driver, and verify
>> connection to the new LUNs. Shut down nodeA and power it off.
>> 8.. On nodeB, go to control panel, and stop the cluster resources
>> (Cludisk, and cluster service) and set the services to start manually.
>> 9.. On nodeB, run disk administrator and document the disk labels, drive
>> letters, and physical disk numbers for the existing cluster resource
>> disks.
>> 10.. On nodeB, run the registry editor and go to HKLM/Current control
>> set/services/Clusdisk, and make note of the actual disk signatures
>> assigned to the cluster resources. Document the physicaldisk and drive
>> numbers for these drives. You will need this information so you don't
>> delete the new quorum disk signature by mistake in step 12.
>> 11.. On NodeB run disk administrator, and create a mirror set between
>> the old resource disks and the new LUNs in the new array. The mirrors
>> will now synchronize, and should take between 50-60GB per hour to
>> complete. Once complete, remove the connection to the old disk array on
>> nodeB.
>> 12.. Reboot nodeB, go into registry editor, and delete the disk
>> signatures from the ClusDisk registry entry for all disks EXCEPT THE
>> QUORUM RESOURCE!!, if you delete the quorum disk signature by mistake,
>> you are out of luck. Use the information gathered in steps 9 and 10 to
>> determine the disk signature of the quorum disk. (If the signatures are
>> not deleted here, you will never be able to get back to the same drive
>> letters as the original cluster disks!)
>> 13.. On nodeB, run disk administrator, and re-letter the new drives to
>> the original drive letters documented in step 9. Go to control panel, and
>> reset the cluster services to startup automatic.
>> 14.. Reboot nodeB, and verify the cluster comes up normally.
>> 15.. Reboot nodeA, and verify you can fail over resources to nodeA.
>> (when nodeA reboots, it pulls the registry info for the new cluster disks
>> from nodeB. The ClusDisk registry entries are rebuilt automatically by
>> nodeB when it was rebooted). If nodeA has troubles coming up, evict the
>> node from the cluster, de-install clusters from the node, and then rejoin
>> nodeA back into the cluster with nodeB.
>>
>>
>
>

Loay/Mike,

Isin't the W2K3 (backward ported) Cluster Server Recovery tool designed to
make this task easier? We have used the tool is a Test environment to move a
cluster to a SAN. It works very well. The tool enables you to use a GUI
without having to worry about the intricasies of executing the CUI commands
to re-establish the dependencies, signatures etc.

"Loay Shbeilat [MS]" wrote:

> Hi Opus,
>
> I have done this before and it works fine :-) Plz try the following steps -
> Assumptions (if any of those assumptions are not there, then plz advice and
> i will try to find the appropriate solution)
> 1) The machines will not change
> 2) The storage will be changed
> 3) the 2 SANs will be accessible to the cluster at the same time, for the
> migration purpose. After the migration you can pull out the old storage.
> 4) assume the Old disk drive is O: and the New disk Drive is N:
>
>
> Steps I followed:
> 1) Backed the disks up :)
> 2) Backed the disk signatures/geometry. You can use "confdisk.exe" to do
> that.
> 3) On the new SAN create a new partition that you will use for the SQL. Name
> the disk N:\
> 4) Create a new Disk Resource for the new disk and have that in the SQL
> group.
> 5) Offline the SQL resource (so that no one would be writing to the disk
> anymore)
> 6) Keep the disk resources online.
> 7) using a copy utility replicate the data from the old drive to the new
> drive, make sure to copy the correct ACL's/attributes/etc...
> The " /o " switch with xcopy does copy the ACL's. You can also ntbackup then
> restore the data. Use whatever tool you are comfortable with to replicate
> the data.
> 8) Now Add the new disk as a dependency for the SQL resource. The SQL
> resource at this point of time will have 2 disk dependencies: Disk O: and
> Disk N:
> 9) Go to disk management. Rename the Old disk drive from O: to X:
> 10) Rename the New disk drive from N: to O:
> 11) back to cluster administrator, rename the resource from "Disk O:" to
> "Disk X:"
> 12) rename the resource from "Disk N:" to "Disk O:"
> 13) remove the "Disk X:" dependency from the SQL resource. Now it should
> only have one disk dependency "disk O:"
> 14) I would go to the advanced properties of the SQL resource, and set it to
> "Do not restart". (just in case things dont go well, you dont want the
> resource failing back in forth between the nodes)
> 15) try to online the SQL resource
>
>
> Does it work?
> Then go back to Advanced tab in properties and set it to "Restart"
>
>
> Does it fail?
> Go the event viewer and check the system and the application events. Does it
> shed any light on the problem?
>
>
>
> --
> Thanks,
> Loay Shbeilat
> MSCS Admin Tools STE
>
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>
> "Opus" <closed@msn.com> wrote in message
> news:e$ZZdhpNFHA.3704@TK2MSFTNGP12.phx.gbl...
> >I have a Window 2003 Ent. Server Cluster running SQL 2000. We need to move
> >of our current SAN to a new SAN and I don't want to do a full reinstall so
> >I was looking for an easy way to do it. This site
> >http://expertanswercenter.techtarget...981988,00.html
> >has an approach but it only partly work, i.e. I was able to move the quorum
> >just fine but not the data drives, basically on step 14 my old drives
> >popped right back in place with their original drive letters back. I'm
> >guessing its because on a Win2003 Cluster the drive signatures can't just
> >be deleted out of the registry like it says in step 12. So does anyone
> >know the steps to change/move my data drives?
> >
> > Here is a copy of the steps from that site in case it goes down:
> > 1.. In the new storage array, pre-configure your LUNs to match your
> > current environment. Set any LUN security or switch zoning to provide
> > access to an HBA in nodeB of the cluster.
> > 2.. Insert a new HBA into NodeB in the cluster. If the server is already
> > dual homed, connect one HBA to a SAN port that has access to the new
> > storage array.
> > 3.. Update the HBA drivers to the correct revision for the HBA connected
> > to the new array.
> > 4.. Reboot nodeB, and verify access to the new LUNs via NT disk admin, or
> > on Win2k, under the manage disks MMC. Create an NTFS partition on the LUN
> > configured for the cluster quorum resource in the new array, and do a
> > quick format.
> > 5.. Migrate ALL Cluster resources to nodeB.
> > 6.. In cluster admin, create a new disk resource for the new quorum disk,
> > and move quorum to the new disk. The cluster will now have all application
> > resources on the old array, and have quorum configured for the new array.
> > 7.. Install or move an HBA in nodeA, update the driver, and verify
> > connection to the new LUNs. Shut down nodeA and power it off.
> > 8.. On nodeB, go to control panel, and stop the cluster resources
> > (Cludisk, and cluster service) and set the services to start manually.
> > 9.. On nodeB, run disk administrator and document the disk labels, drive
> > letters, and physical disk numbers for the existing cluster resource
> > disks.
> > 10.. On nodeB, run the registry editor and go to HKLM/Current control
> > set/services/Clusdisk, and make note of the actual disk signatures
> > assigned to the cluster resources. Document the physicaldisk and drive
> > numbers for these drives. You will need this information so you don't
> > delete the new quorum disk signature by mistake in step 12.
> > 11.. On NodeB run disk administrator, and create a mirror set between the
> > old resource disks and the new LUNs in the new array. The mirrors will now
> > synchronize, and should take between 50-60GB per hour to complete. Once
> > complete, remove the connection to the old disk array on nodeB.
> > 12.. Reboot nodeB, go into registry editor, and delete the disk
> > signatures from the ClusDisk registry entry for all disks EXCEPT THE
> > QUORUM RESOURCE!!, if you delete the quorum disk signature by mistake, you
> > are out of luck. Use the information gathered in steps 9 and 10 to
> > determine the disk signature of the quorum disk. (If the signatures are
> > not deleted here, you will never be able to get back to the same drive
> > letters as the original cluster disks!)
> > 13.. On nodeB, run disk administrator, and re-letter the new drives to
> > the original drive letters documented in step 9. Go to control panel, and
> > reset the cluster services to startup automatic.
> > 14.. Reboot nodeB, and verify the cluster comes up normally.
> > 15.. Reboot nodeA, and verify you can fail over resources to nodeA. (when
> > nodeA reboots, it pulls the registry info for the new cluster disks from
> > nodeB. The ClusDisk registry entries are rebuilt automatically by nodeB
> > when it was rebooted). If nodeA has troubles coming up, evict the node
> > from the cluster, de-install clusters from the node, and then rejoin nodeA
> > back into the cluster with nodeB.
> >
> >
>
>
>

That is correct, yeta lot of times it depends on each customer's enviornment and the complexity of the SAN migration. But all in all, it works pretty nicely if you can
have both SANs hooked up to the Cluster at the same time.

305793 How to Replace a Disk That Is on a Windows 2000 or a Windows 2003 Server
http://support.microsoft.com/?id=305793

--
Hope this helps,
Mike Rosado
Windows 2000 MCSE + MCDBA
Microsoft Enterprise Platform Support
Windows NT/2000/2003 Cluster Technologies

====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
====================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
<http://www.microsoft.com/info/cpyright.htm>

-----Original Message-----
> From: "=?Utf-8?B?Q3liZXJzdG9ybWU=?=" <Cyberstorme@discussions.microsoft.com>
> Subject: Re: Windows 2003/SQL 2000 Cluster SAN Migration
> Date: Mon, 4 Apr 2005 10:55:02 -0700
>
> Loay/Mike,
>
> Isin't the W2K3 (backward ported) Cluster Server Recovery tool designed to
> make this task easier? We have used the tool is a Test environment to move a
> cluster to a SAN. It works very well. The tool enables you to use a GUI
> without having to worry about the intricasies of executing the CUI commands
> to re-establish the dependencies, signatures etc.
>
> "Loay Shbeilat [MS]" wrote:
>
> > Hi Opus,
> >
> > I have done this before and it works fine :-) Plz try the following steps -
> > Assumptions (if any of those assumptions are not there, then plz advice and
> > i will try to find the appropriate solution)
> > 1) The machines will not change
> > 2) The storage will be changed
> > 3) the 2 SANs will be accessible to the cluster at the same time, for the
> > migration purpose. After the migration you can pull out the old storage.
> > 4) assume the Old disk drive is O: and the New disk Drive is N:
> >
> >
> > Steps I followed:
> > 1) Backed the disks up :)
> > 2) Backed the disk signatures/geometry. You can use "confdisk.exe" to do
> > that.
> > 3) On the new SAN create a new partition that you will use for the SQL. Name
> > the disk N:\
> > 4) Create a new Disk Resource for the new disk and have that in the SQL
> > group.
> > 5) Offline the SQL resource (so that no one would be writing to the disk
> > anymore)
> > 6) Keep the disk resources online.
> > 7) using a copy utility replicate the data from the old drive to the new
> > drive, make sure to copy the correct ACL's/attributes/etc...
> > The " /o " switch with xcopy does copy the ACL's. You can also ntbackup then
> > restore the data. Use whatever tool you are comfortable with to replicate
> > the data.
> > 8) Now Add the new disk as a dependency for the SQL resource. The SQL
> > resource at this point of time will have 2 disk dependencies: Disk O: and
> > Disk N:
> > 9) Go to disk management. Rename the Old disk drive from O: to X:
> > 10) Rename the New disk drive from N: to O:
> > 11) back to cluster administrator, rename the resource from "Disk O:" to
> > "Disk X:"
> > 12) rename the resource from "Disk N:" to "Disk O:"
> > 13) remove the "Disk X:" dependency from the SQL resource. Now it should
> > only have one disk dependency "disk O:"
> > 14) I would go to the advanced properties of the SQL resource, and set it to
> > "Do not restart". (just in case things dont go well, you dont want the
> > resource failing back in forth between the nodes)
> > 15) try to online the SQL resource
> >
> >
> > Does it work?
> > Then go back to Advanced tab in properties and set it to "Restart"
> >
> >
> > Does it fail?
> > Go the event viewer and check the system and the application events. Does it
> > shed any light on the problem?
> >
> >
> >
> > --
> > Thanks,
> > Loay Shbeilat
> > MSCS Admin Tools STE
> >
> > "This posting is provided "AS IS" with no warranties, and confers no
> > rights."
> >
> > "Opus" <closed@msn.com> wrote in message
> > news:e$ZZdhpNFHA.3704@TK2MSFTNGP12.phx.gbl...
> > >I have a Window 2003 Ent. Server Cluster running SQL 2000. We need to move
> > >of our current SAN to a new SAN and I don't want to do a full reinstall so
> > >I was looking for an easy way to do it. This site
> > >http://expertanswercenter.techtarget...981988,00.html
> > >has an approach but it only partly work, i.e. I was able to move the quorum
> > >just fine but not the data drives, basically on step 14 my old drives
> > >popped right back in place with their original drive letters back. I'm
> > >guessing its because on a Win2003 Cluster the drive signatures can't just
> > >be deleted out of the registry like it says in step 12. So does anyone
> > >know the steps to change/move my data drives?
> > >
> > > Here is a copy of the steps from that site in case it goes down:
> > > 1.. In the new storage array, pre-configure your LUNs to match your
> > > current environment. Set any LUN security or switch zoning to provide
> > > access to an HBA in nodeB of the cluster.
> > > 2.. Insert a new HBA into NodeB in the cluster. If the server is already
> > > dual homed, connect one HBA to a SAN port that has access to the new
> > > storage array.
> > > 3.. Update the HBA drivers to the correct revision for the HBA connected
> > > to the new array.
> > > 4.. Reboot nodeB, and verify access to the new LUNs via NT disk admin, or
> > > on Win2k, under the manage disks MMC. Create an NTFS partition on the LUN
> > > configured for the cluster quorum resource in the new array, and do a
> > > quick format.
> > > 5.. Migrate ALL Cluster resources to nodeB.
> > > 6.. In cluster admin, create a new disk resource for the new quorum disk,
> > > and move quorum to the new disk. The cluster will now have all application
> > > resources on the old array, and have quorum configured for the new array.
> > > 7.. Install or move an HBA in nodeA, update the driver, and verify
> > > connection to the new LUNs. Shut down nodeA and power it off.
> > > 8.. On nodeB, go to control panel, and stop the cluster resources
> > > (Cludisk, and cluster service) and set the services to start manually.
> > > 9.. On nodeB, run disk administrator and document the disk labels, drive
> > > letters, and physical disk numbers for the existing cluster resource
> > > disks.
> > > 10.. On nodeB, run the registry editor and go to HKLM/Current control
> > > set/services/Clusdisk, and make note of the actual disk signatures
> > > assigned to the cluster resources. Document the physicaldisk and drive
> > > numbers for these drives. You will need this information so you don't
> > > delete the new quorum disk signature by mistake in step 12.
> > > 11.. On NodeB run disk administrator, and create a mirror set between the
> > > old resource disks and the new LUNs in the new array. The mirrors will now
> > > synchronize, and should take between 50-60GB per hour to complete. Once
> > > complete, remove the connection to the old disk array on nodeB.
> > > 12.. Reboot nodeB, go into registry editor, and delete the disk
> > > signatures from the ClusDisk registry entry for all disks EXCEPT THE
> > > QUORUM RESOURCE!!, if you delete the quorum disk signature by mistake, you
> > > are out of luck. Use the information gathered in steps 9 and 10 to
> > > determine the disk signature of the quorum disk. (If the signatures are
> > > not deleted here, you will never be able to get back to the same drive
> > > letters as the original cluster disks!)
> > > 13.. On nodeB, run disk administrator, and re-letter the new drives to
> > > the original drive letters documented in step 9. Go to control panel, and
> > > reset the cluster services to startup automatic.
> > > 14.. Reboot nodeB, and verify the cluster comes up normally.
> > > 15.. Reboot nodeA, and verify you can fail over resources to nodeA. (when
> > > nodeA reboots, it pulls the registry info for the new cluster disks from
> > > nodeB. The ClusDisk registry entries are rebuilt automatically by nodeB
> > > when it was rebooted). If nodeA has troubles coming up, evict the node
> > > from the cluster, de-install clusters from the node, and then rejoin nodeA
> > > back into the cluster with nodeB.
> > >
> > >
> >
> >
> >
>