LUN migration within the storage using veritas volume manager

[veera-lav]

Hi,

Can any one know, howt to migrate a lun to another lun in HP XP24K storage. i am  using windows 2008 server running veritas storage foundation 5 and volumes are replicating using VVR.

i need to do it online or offline but at the end the replication should not corrupt after migrating the lun.

config details are:

one a disk group created with 6 ldevs ( 2 for .MDF files, 3 ldevs for .LDF files, 1 ldev for SRL volume - using MS SQL 2008)

i want to migration 3 LDEVS which is using for .LDF files

Please help on this....

thanks,

Veera

[mikebounds]

Add the new LUNs to the diskgroup and add a mirror in VEA (or whatever tool you normally use to manage SFW) to the volume(s) on the old LUN and select new LUN and when mirror has finishing syncing, remove mirror on original LUN - this is fine to do online and will not effect replication as replication is at a volume level (not LUN level).  The SRL is just another volume so the same method should work fine on the SRL.  You may also have to move DCMs if there are DCMs on the LUNs you are migrating - you MAY be able to drag and drop in VEA for these, but if not then just create another DCM (choose add log) on the new LUN and then remove DCM on old LUN.  If you have more than one volume on each LUN, then you need to add & remove mirror for all the volumes.

When all old LUNs are empty, you can remove LUNs from the diskgroup

If you provide the output of vxprint and the names of the 3 Harddisks you want to migrate off, then I can check it all looks ok.

Mike

[veera-lav]

mike....

the output is attached. i want to migrate the 3 luns for SHRILIFE-DG and they are two replications 1.dc-hyd 2. dc-dr. whether the DCM is also required to move?

these three disks are going to move from SAS disk to SSD disk (Harddisk36, Harddisk37, Harddisk46)

[mikebounds · Accepted solution]

Looking at this output it would be easier to use Evacuate Disk - see extract from SFW Admin:

The Evacuate Disk command moves the entire contents of a healthy disk to the

free space on another dynamic disk. If there is a failed volume on the original

disk, the volume cannot be moved, and an error message will appear.

Note: Dynamic disks belonging to a Microsoft Disk Management Disk Group do

not support the Evacuate Disk command.

To evacuate a disk

1 In the left pane, right-click the disk you wish to evacuate.

2 Select Evacuate Disk.

3 The Evacuate Disk dialog will appear. Select either Auto Assign destination

 disk or Manually assign destination disk. If you chose Manually assign

destination disk, assign the destination disk by selecting one disk from the

display.

You may also check Disable Track Alignment to disable track alignment on

the destination disk.

4 Click OK to evacuate the disk.

I think there is more of a performance hit doing an evacuate, rather than mirror method, but mirror method is not possible for all disks - see analysis below:
 

Disks Harddisk36, Harddisk37, Harddisk46 have internal names as follows in diskgroup  SHRILIFE-DG:

Disk2 dm Harddisk36   Disk2        -        139588722-        -        -       -

Disk3 dm Harddisk37   Disk3        -        139588722-        -        -       -

Disk4 dm Harddisk46   Disk4        -        139588722-        -        -       -

You should be able to use vxprint -th to show you a meaningfull order of VM objects, but this doesn't work (on 5.0 and 5.1 - I haven't tested this in 6.0 yet)

With manually doing this ordering you get:

v  RegRep       -            ENABLED  409600   -        ACTIVE   -       -

 pl RegRep-01    RegRep       ENABLED  409600   -        ACTIVE   -       -

  sd Disk1-02     RegRep-01    ENABLED  409600   0        -        -       -

 pl RegRep-02    RegRep       ENABLED  8        -        ACTIVE   -       -

  sd Disk2-02     RegRep-02    ENABLED  8        0        -        -       -

 pl RegRep-03    RegRep       ENABLED  8        -        ACTIVE   -       -

  sd Disk3-02     RegRep-03    ENABLED  8        0        -        -       -

v  SHRILIFEDB   -            ENABLED  557842432-        ACTIVE   -       -

 pl SHRILIFEDB-01 SHRILIFEDB   ENABLED  557842432 -        ACTIVE   -       -

  sd Disk2-01     SHRILIFEDB-01   ENABLED  139460608 0        -        -       -

  sd Disk3-01     SHRILIFEDB-01   ENABLED  139460608 0        -        -       -

  sd Disk5-01     SHRILIFEDB-01   ENABLED  139460608 0        -        -       -

  sd Disk6-01     SHRILIFEDB-01   ENABLED  139460608 0        -        -       -

 pl SHRILIFEDB-02 SHRILIFEDB   ENABLED  512      -        ACTIVE   -       -

  sd Disk2-03     SHRILIFEDB-02   ENABLED  512      0        -        -       -

 pl SHRILIFEDB-03 SHRILIFEDB   ENABLED  512      -        ACTIVE   -       -

  sd Disk3-03     SHRILIFEDB-03   ENABLED  512      0        -        -       -

v  SHRILIFELOG  -            ENABLED  138412032-        ACTIVE   -       -

 pl SHRILIFELOG-01 SHRILIFELOG  ENABLED  138412032 -        ACTIVE   -       -

  sd Disk4-01     SHRILIFELOG-01   ENABLED  138412032 0        -        -       -

 pl SHRILIFELOG-02 SHRILIFELOG  ENABLED  512      -        ACTIVE   -       -

  sd Disk2-04     SHRILIFELOG-02   ENABLED  512      0        -        -       -

 pl SHRILIFELOG-03 SHRILIFELOG  ENABLED  512      -        ACTIVE   -       -

  sd Disk3-04     SHRILIFELOG-03   ENABLED  512      0        -        -       -

I have shown relevent objects in bold which shows these 3 LUNs contain:

1. 2 DCMs from RegRep volume (very small size of 8)
2. Half of the SHRILIFEDB volumes and both the DCM (slightly larger at 512 as volumes is larger than RegRep) - ithe other half of  SHRILIFEDB volume is on (Disk5 and Disk6)
3. SHRILIFELOG volume and its 2 DCMs

As only half the SHRILIFEDB volume is on disks you are migrating, you can't use mirror as you don't want to move the other disks (Disk5 and Disk6 which are Harddisk47 and Harddisk48).

So if you use Evacuate Disk, then all objects including DCMs should be moved to your new LUNs.

Mike

[veera-lav]

Thanks a lot for your valuable solution and suggetion.

As this is critical migration for me and you have done a good analysis. thnx

Veera