Re: Windows 2003/SQL 2000 Cluster SAN Migration
- From: "Cyberstorme" <Cyberstorme@xxxxxxxxxxxxxxxxxxxxxxxxx>
- 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@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.
> >
> >
>
>
>
.
- Follow-Ups:
- Re: Windows 2003/SQL 2000 Cluster SAN Migration
- From: Mike Rosado [MSFT]
- Re: Windows 2003/SQL 2000 Cluster SAN Migration
- 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: ftp on 2003 cluster
- Next by Date: more problems with clustering
- 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
|
