June 2, 2010 at 7:27 am
Hello,
I would like to ask you what is the correct procedure when moving volumes to new storage.
Our configuration:
- 2-node cluster with SQL Server 2008 Enterprise x64 on Windows Server 2008 Enterprise x64 w/o Hyper-V
- 2 SQL instances (VSQL1, VSQL2), one productional and one for testing purposes
- each SQL instance uses 3 volumes for databases, transactional logs and backup volume (R:, S:, T: used by VSQL1; U:, V:, W: used by VSQL2)
- 2 volumes for MS DTC (M:) and quorum (Q:)
- system databases (master, model, msdb and tempdb) are stored on volumes with other user databases (R: and U:)
- in each cluster group there are these resources:
for instance VSQL1:
"Server Name" - VSQL1
"Disk Drives" - R:, S:, T:
"File Share Resources" - VSQL1: \\?\GLOBALROOT\Device\RsFx0103\<localmachine>\VSQL1
"Other Resources" - Analysis Services (VSQL1), SQL Server (VSQL1), SQL Server Agent (VSQL1)
and analogously for instance VSQL2.
We want move only these 8 volumes from HP MSA2000 to HP EVA4400 (IP adresses and other settings will be left intact), so when I create 5 vdisks and map them to 2 hosts, what are the next steps to successfully move data from the old storage to the new one? What a I have to do in Failover Cluster Management and in SQL Server Management Studio? What about NTFS permissions on new volumes? Is it possible just to copy all files to new volumes and assign same letters to new volumes?
Thank you for your help.
June 2, 2010 at 8:44 am
presumably you are currently presenting these over iSCSI?
You would need agreed downtime for your cluster there's no getting away from that.
I would create the new LUNS and attach them to the active node with a temp drive letter then copy all the data and preserve any file\folder permissions. Once all the data has been copied remove old LUN resources from cluster administrator and then from the machines themselves. You dont need to destroy the LUNs just unpresent them from nodes and they will still be intact.
Present the new LUNs to both nodes and Change the drive letters on the new LUNs and map them back into cluster administrator (check your dependencies), then try and start SQL Server. It should be fairly easy to achieve but depending on how much data you have as to how long it takes!
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
June 2, 2010 at 9:07 am
Those volumes will be presented over fibre channel.
Thanky you very much for your answer, I will try this solution on my simulating SQL cluster in VMware Infrastructure 3 first. 🙂
June 2, 2010 at 11:20 am
pavleesseck (6/2/2010)
I will try this solution on my simulating SQL cluster in VMware Infrastructure 3 first. 🙂
good man, was gonna be my next suggestion 😉
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
July 9, 2010 at 5:39 am
Here are the steps I followed:
1) Map all volumes for quorum, DTC, data, transaction logs and backup.
2) Online, initialize and format all volumes.
3) In Failover Cluster Management, add the disks.
4) Change the disk for witness disk in "Configure Cluster Quorum Settings".
5) Take coresponding services or applications offline (SQL Server) in Failover Cluster Management, node "Services and Applications", then bring online disks they contain.
6) Move the new disk to another service or application.
7) Assign temporary letter for the new disk.
8) Copy the content of old disk to the new one, preserving file permissions (e.g. "XCOPY M: X: /E /F /K /O").
9) Edit dependencies for resources that use the old disk.
10) Remove old disk from the group (SQL Server).
11) Unassign the old letter from disk and take offline this disk.
12) Assign this letter to the new disk instead of the temporary letter.
13) Bring the service online.
By completing these steps the SQL Server is working, no errors have appeared.
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply