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.com/eac/knowledgebaseAnswer/0,295199,sid63_gci981988,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.


.

Relevant Pages

  • Re: Correcting corrupt $MFT on shared clustered disk.
    ... against a cluster disk. ... handles against the disk. ... After digging into it I figured out I didn't need the extended maintenance mode and figured out the rest of the article. ... If I assign drives for different areas, I figure we'll eventually end up with the same problem we had before: some areas running out of space and others with space to spare. ...
    (microsoft.public.windows.server.clustering)
  • Re: Correcting a corrupted $MFT on a shared clustered disk
    ... Also, the problem I'm having is on the smaller basic disk, the GPT one is ... When I do run chkdsk, are there any special issues with the cluster? ... The three drives are a 500MB for the quorum, ...
    (microsoft.public.windows.server.general)
  • SUMMARY: changed WWID on cluster member boot disk
    ... disk and quorum disk of a single-member cluster, ... I could no longer boot from the cluster disks, ... the pre-cluster stand-alone system disk; ... the root1_domain on LUN containing the member boot disk was found ...
    (Tru64-UNIX-Managers)
  • Re: Correcting a corrupted $MFT on a shared clustered disk
    ... Phase 1 went through pretty fast, it found and corrected the 60 or so corrupted attribute & orphaned records that the read-only chkdsk passes were detecting. ... Also, the problem I'm having is on the smaller basic disk, the GPT one is ... are there any special issues with the cluster? ... The three drives are a 500MB for the quorum,> and two ...
    (microsoft.public.windows.server.general)
  • Re: Correcting a corrupted $MFT on a shared clustered disk
    ... Also, the problem I'm having is on the smaller basic disk, the GPT one is ... for the CHKDSK, or is it something that's only going to get worse? ... are there any special issues with the cluster? ... The three drives are a 500MB for the quorum, ...
    (microsoft.public.windows.server.general)
Loading