![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
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 |
#3
| |||
| |||
|
|
-----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 (AT) discussions (DOT) microsoft.com> wrote in message news:1436301c41bac$9a6fce80$a001280a (AT) phx (DOT) 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 . |
#4
| |||
| |||
|
|
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 (AT) discussions (DOT) microsoft.com> wrote in message news:1436301c41bac$9a6fce80$a001280a (AT) phx (DOT) 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 . |
#5
| |||
| |||
|
![]() |
| Thread Tools | |
| Display Modes | |
| |