Re: Windows 2003/SQL 2000 Cluster SAN Migration

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@xxxxxxxxxxxxxxxxxxxxxxxxx>
> 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@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.
> > >
> > >
> >
> >
> >
>


.

Relevant Pages

  • Phisical disk resource
    ... I'm setting up a 2 node cluster under 2003 ent. ... is working but I am not able to bring the shared disk ... INFO FmpPropagateResourceState: resource a94c4968- ... INFO Physical Disk: ...
    (microsoft.public.windows.server.clustering)
  • Re: Windows 2003/SQL 2000 Cluster SAN Migration
    ... Isin't the W2K3 Cluster Server Recovery tool designed to ... > 4) assume the Old disk drive is O: and the New disk Drive is N: ... > 4) Create a new Disk Resource for the new disk and have that in the SQL ... >>just fine but not the data drives, basically on step 14 my old drives ...
    (microsoft.public.windows.server.clustering)
  • Re: Clustering Newbie - SAN Advice
    ... You are right to observe that we probably don't want cost of full-blown SAN ... piggy backing them on some sort of shared disk array. ... The disks in the array doesn't need anything special. ... single-instance cluster. ...
    (microsoft.public.sqlserver.clustering)
  • Re: Unable to start the cluster service when creating a new 2 node
    ... existing cluster and could no form a new cluster. ... node 1 as possible host for resource 6add91be-f8ae-4fb7-b78d-2488c502ad0a. ... FmpAddPossibleNodeToList for restype Physical Disk ... [DiskArb] ...
    (microsoft.public.windows.server.clustering)
  • Re: Error installing SQL 2005 on a cluster
    ... I had created an "Unused Drives" resource group to keep my unused physical ... disk resources from becoming corrupted but hadn't brought them online. ... On a 32bit cluster it's usually C or D. If all ...
    (microsoft.public.sqlserver.clustering)