Move SQL Server cluster between SANs

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 2 weeks ago on >> windows 2003 <<.
Assumptions:
1) The machines will not change
2) The storage will be changed
3) the 2 SANs will be accessible to the cluster for the migration purpose.
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. Whatever 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."
"Bjorn Mobak" <anonymous@.discussions.microsoft.com> wrote in message
news:1436301c41bac$9a6fce80$a001280a@.phx.gbl...
> Hi.
> I'm in the process of migrating from a HP XP SAN to an
> EVA5000. The big issue is how to transfer the SQL Server
> disks.
> My plan is to give the cluster access to disks on both
> nodes. Change the Quorum drive to the EVA quorum disk.
> Then the fun part starts.
> Is there a proven path for how to move the SQL Server
> disks onto the new SAN?
> Thanks for any suggestions.
> Bjorn Mobak
> Avinor AS
> Norway
Great!
I have switched SAN and it went smooth as silk.
The only scare was to change the soft-zoning on the
fabric. Haven't done that before :-)
Thank you.
Bjorn

>--Original Message--
>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 2 weeks ago on >> windows 2003 <<.
>Assumptions:
>1) The machines will not change
>2) The storage will be changed
>3) the 2 SANs will be accessible to the cluster for the
migration purpose.
>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. Whatever 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."
>"Bjorn Mobak" <anonymous@.discussions.microsoft.com> wrote
in message
>news:1436301c41bac$9a6fce80$a001280a@.phx.gbl...
>
>.
>
|||happy to hear that :-)
Thanks,
Loay Shbeilat
MSCS Admin Tools STE
"This posting is provided "AS IS" with no warranties, and confers no
rights."
"Bjorn Mobak" <anonymous@.discussions.microsoft.com> wrote in message
news:1925901c41c25$17b5bad0$a301280a@.phx.gbl...
> Great!
> I have switched SAN and it went smooth as silk.
> The only scare was to change the soft-zoning on the
> fabric. Haven't done that before :-)
> Thank you.
> Bjorn
> you that I
> migration purpose.
> Drive is N:
> use "confdisk.exe" to do
> use for the SQL. Name
> that in the SQL
> writing to the disk
> drive to the new
> ACL's/attributes/etc...
> also ntbackup then
> replicate the data.
> resource. The SQL
> dependencies: Disk O: and
> from O: to X:
> from "Disk O:" to
> resource. Now it should
> resource, and set it to
> resource failing back
> to "Restart"
> application events. Does it
> confers no
> in message
|||Make sure you are using all the latest HBA drivers, EVA software, Secure Path software and switch firmware, else you'll run into stability problems with EVA5000s.