Re: Windows 2003/SQL 2000 Cluster SAN Migration
- From: "Opus" <closed@xxxxxxx>
- Date: Sat, 2 Apr 2005 01:46:18 -0600
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@xxxxxxxxxxxxx> wrote in message
news:%23aTyzcuNFHA.1268@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxx> wrote in message
> news:e$ZZdhpNFHA.3704@xxxxxxxxxxxxxxxxxxxxxxx
>>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.
>>
>>
>
>
.
- References:
- Windows 2003/SQL 2000 Cluster SAN Migration
- From: Opus
- Re: Windows 2003/SQL 2000 Cluster SAN Migration
- From: Loay Shbeilat [MS]
- Windows 2003/SQL 2000 Cluster SAN Migration
- Prev by Date: Re: Print Cluster to Single Server
- Next by Date: Re: Multiple Websites, SSL, IIS, and NLB
- Previous by thread: Re: Windows 2003/SQL 2000 Cluster SAN Migration
- Next by thread: Re: Windows 2003/SQL 2000 Cluster SAN Migration
- Index(es):
Relevant Pages
|