EMC Migration from Striped LVOL's.

[Albert Smith_1]

Hey folks, I am new to the originzation that I am in and they want me to plan a EMC migration from an 8730 to a CX700. Normally not a big deal, you just bring down one fibre path (Alternate link) from the source and plug in the target and mirror your data.

However the person before me striped it on the LVM side and I am trying to figure you what is the best way of doing this data migration?

I know I can't add a fibre card and mirror the data across because I don't think you can have a mirror set in a stripe set.

Any suggestions?

Thanks...

[Geoff Wild]

Not too sure why they mirroed at the LVM level - when their already is redundancy in the frame....

Anyways...this is easy...just break the lvm mirrors from one path:

lvreduce -m 0 /dev/vgXX/lvolXX /dev/dsk/cXtXdX

Once that is done, move that fibre card to the new frame, then setup mirroring again, then reduce the old frame....

Rgds...Geoff

[Albert Smith_1]

No not mirrored at the LVM level, striped at the LVM level.

[Geoff Wild]

Oop - sorry...striped....


Can you post a vgdisplay -v and a lvdisplay -v /dev/vgXX/lvolX |head -35

If it's striped across the paths, ie, no alternate links, then you only have 2 choices:

Add a fibre card and setup new vg to copy data to.

Or, backup data, blow away vg, move fibre, recreate vg, restore data...

Rgds...Geoff

[Albert Smith_1]

Geoff,

Here is the vgdisplay -v there is a number of PV's in here so I just chopped it a little:

aad06[/dev]# vgdisplay -v /dev/vg9iupgrade |head -35
--- Volume groups ---
VG Name /dev/vg9iupgrade
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 30
Cur PV 25
Act PV 25
Max PE per PV 10000
VGDA 50
PE Size (Mbytes) 4
Total PE 53900
Alloc PE 51200
Free PE 2700
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/vg9iupgrade/lv9i01
LV Status available/syncd
LV Size (Mbytes) 204800
Current LE 51200
Allocated PE 51200
Used PV 25


--- Physical volumes ---
PV Name /dev/dsk/c2t1d0
PV Status available
Total PE 2156
Free PE 108
Autoswitch On

Here is the lvdisplay:

aad06[/dev]# lvdisplay -v /dev/vg9iupgrade/lv9i01|head -35
--- Logical volumes ---
LV Name /dev/vg9iupgrade/lv9i01
VG Name /dev/vg9iupgrade
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule striped
LV Size (Mbytes) 204800
Current LE 51200
Allocated PE 51200
Stripes 25
Stripe Size (Kbytes) 64
Bad block on
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c2t1d0 2048 2048
/dev/dsk/c2t1d1 2048 2048
/dev/dsk/c2t1d2 2048 2048
/dev/dsk/c2t1d3 2048 2048
/dev/dsk/c2t1d4 2048 2048
/dev/dsk/c2t1d5 2048 2048
/dev/dsk/c2t1d6 2048 2048
/dev/dsk/c2t1d7 2048 2048
/dev/dsk/c2t2d0 2048 2048
/dev/dsk/c2t2d1 2048 2048
/dev/dsk/c2t2d3 2048 2048
/dev/dsk/c2t2d4 2048 2048
/dev/dsk/c2t2d5 2048 2048
/dev/dsk/c2t2d6 2048 2048
/dev/dsk/c2t2d7 2048 2048
/dev/dsk/c2t3d0 2048 2048

[Sridhar Bhaskarla]

Hi Albert,

Extending mirrors and reducing mirrors won't help you in this situation. So, you are left with few options.

1. Drop the alternate link, extend it to the new array, scan the disks, create VGs and filesystems in whatever the way you like. Halt the application/database and copy the data. For raw devices, use dd.

2. Use SRDF/mirroring at the backend. Once the mirroring is done on the EMC done, split the mirrors and import the VGs from the new array.

-Sri

[Geoff Wild]

Even if you could mirror, you can't:

Max PV 30
Cur PV 25

Not enough room in VG to add disks...

So, you will need to create a new volume group on the CX700, and migrate data manually....unless, you setup SRDF, and have EMC migrate (copy) the data to the new frame, then all you do is:

halt your packages
vgexport the existing vg's(create map files first: vgexport -s -v -p -m /tmp/vgXX.map)
move the fibre cables
recreate the the vg's:

mkdir vgXX
mknod /dev/vgXX/group c 64 0xHH0000

XX - vg number
HH - minor number in hex

vgimport -s -v -m /tmp/vgXX.map /dev/vgXX

You will also have to re-compile your cluster binary - as (if this is a 2 node cluster) your lock disk will have changed...

Rgds...Geoff

[Albert Smith_1]

I think we will take the safe route and backup the data and recover it. I don't think there is any additional funds to purchase additional fibre controllers.

[Geoff Wild]

You should ask EMC about SRDF - they did that for us on some of our migrations - at no cost. You don't need additional fibre cards that way - just a bit of down time - but a lot less then if you were to restore from tape...

Rgds...Geoff

[Albert Smith_1]

True. But I think the one thing I want to do is remove the LVM stripe, which I can't do unless I backup and recover the system.

[Geoff Wild · Accepted solution]

Yes, you're right - to remove stripe, might as well as do the restore...that way you will have it the way you want it - and will make a future migration easier...just a tip - increase the MAXPV in the new vg you create - make it like 128.

Rgds...Geoff

[Geoff Wild]

Albert,

Please read:

http://forums1.itrc.hp.com/service/forums/helptips.do?#28

I noticed that you have assigned points to 0 of 28 responses of your questions.

You can also close your threads.

How many points should I assign to replies?
Every response to your question is eligible to earn between 1-10 points. No need to worry about running out of points - when a truly awesome reply rolls in that deserves a 10, you will be able to assign it a 10! However, be careful to assign points based on the value that a reply truly provides. Use the following scale as a guideline:



o N/A: The answer was simply a point of clarification to my original question

o 1-3: The answer didn't really help answer my question, but thanks for your assistance!

o 4- 7: The answer helped with a portion of my question, but I still need some additional help!

o 8-10: The answer has solved my problem completely! Now I'm a happy camper!


Although assigning points is not mandatory, it is a key component of a strong, interactive community, and it is STRONGLY ENCOURAGED. Others have taken time to help you, so please take a moment to give them credit for their assistance!

Thanks...Geoff

[Bill Costigan]

Have you thought about pvmove?

I don't know if striping will muck things up. I know extent striping would be no problem.

As long as you can still add a single PV, you can add a PV from the CX to the volume group and then pvmove the data from one of the old PVs to the new one. Once the old PV is empty, remove it from the VG with vgreduce and add a second PV from the CX. Continue this process until all the PVs have been migrated.

[Albert Smith_1]

What we decided to do, was purchase additional fiber cards and plug them in to the CX700, present the volumes and create the VG's and LVOL's properly. Then mount the new LVOL's. Then perform a cp -prH from the source to the new. Then unmount both (old and new mountpoints) then mount the new LVOL's under the old mountpoints and restart services.

[Geoff Wild]

Actually, for speed, vxdump/vxrestore is much faster then cp...:

vxdump -0 -f - -s 1000000 -b 16 /oracle | (cd /zmnt/oracle ; vxrestore rf -)

/oracle is existing, and /zmnt/oracle is a temp mount to the new disks...once done, unmount them both, then mount the new to /oracle....etc for each file system...


Rgds...Geoff

[Albert Smith_1]

actually for speed I did:

cd /source
tar -cvf - . | ( cd /target; tar -xvf - . )

Went like a champ.

[Albert Smith_1]

I added a second controller and copied the data with tar

cd /source
tar -cvf - . | ( cd /target; tar -xvf - . )

Went like a champ.