I have a two node SQL Server 2000 cluster running on
Windows 2000 Advanced Server. It's an Active/Passive
configuration. Now we will be replacing the shared
storage system from a Dell PowerVault 220 to EMC Clarion.
Is there anyway to accomplish this without rebuilding the
whole cluster (We are only replacing the storage and not
the servers)?

Thanks
Asim.

Is there a proven way of how to do it??
I myself didnt find any document on that. But I can tell you that I
succefully did that around a month ago on >> windows 2003 <<.
However, this should work for windows 2000 too.

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?
The 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."

"Asim Mian" <anonymous (AT) discussions (DOT) microsoft.com> wrote

Thanks Loay, all of your assumptions are correct. I have
one more question. Did you also move the other resources
like Qourum disk to this new SAN? If yes, did you follow
the same steps as you mentioned for SQL Server resource?

Thanks

Asim.

Pretty much ya.
Concerning the Quorum. I would just change it to a new disk on the new SAN.
It doesnt have to be the same disk drive.
All you have to do is right click on the cluster --> properties --> quorum
tab
and switched it to a new disk on the new SAN.

I would switch the quorum first, and then start doing one resource at a
time. (print, share, sql, etc...)

--
Thanks,
Loay Shbeilat
MSCS Admin Tools STE

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

<anonymous (AT) discussions (DOT) microsoft.com> wrote

Loay, we're doing something similar but just rebuilding the raid 5
array and putting SQL Server transaction logs and the quorom on their
own separate mirrored disks. Are there any issues with changing the
size of the disk resource? Unless we partition them smaller, the new
disks would be 18gb as opposed to 12gb and 1gb now.

Gary

"Loay Shbeilat [MS]" <loays (AT) microsoft (DOT) com> wrote

If i get you right, then you will do that at a hardware level. So the same
disk drive letter would be exposed to the OS?

In theory, changing the disk size should not cause any problems. However, if
that same disk was a cluster disk and you rebuild the array and expose it
again to the OS, you need to make sure that the disk signature doesnt
change. Elsewise cluster service will not be able to pick the disk; it will
assume this is another disk exposed.

It would be great if you give me some more details on the process you will
go through.

--
Thanks,
Loay Shbeilat
MSCS Admin Tools STE

"This posting is provided "AS IS" with no warranties, and confers no
rights."
"Gary" <gary.noon (AT) tradeweb (DOT) com> wrote