Mirror diff size disks

[Lynn Hsu_2]

Hi,
We plan to replace two FC10 enclosures by 2 JBODs. Each FC10 has 10 18GB disks, configured as PVG1 and PVG2 respectively. They are mirrored to each other with PVG-strict/distributed policy. Each JBOD has 10 36GB disks. Can I add the 2 JBODs to the HP server (11.11) as 2nd and 3rd mirror? Can UX-mirror take different size disks to mirror? What will be the best way to replicate data while system is running? Perforamce degradation?

[Mel Burslan · Accepted solution]

after proper LUN allocation and pvcreate, you can extend your vg to include these new volumes. Then introduce them as new and separate PVGs. Then you can replicate your current volumes onto these devices, one at a time as 2nd and 3rd mirrors. When completed you can strip the original and 1st mirror copy off of the vg. While mirroring, there of course is a performance penalty as the OS does the mirroring work, but for 180GB of data, unless you are running a K-class machine or older, this should not be a fearsome degradation of performance.
pvmove is another way of moving from one physical volume to another buts its performance penalty is few times more than that of mirroring.
Also, even though this requires down time on the application end, vxdump|vxrestore is the fastest way that you can accomplish moving of your data.
HTH

[Lynn Hsu_2]

Mel,
Thanks for your help. Just want to make sure when 18GB disks mirror to 36GB disks,
the other 18GB on the new disk still usable? My impression is that by using distributed policy, only the original allocated extends will work, the rest will
be no use...

Lynn

[TwoProc]

Well, MAYBE. Sometimes(most times?) when a volume group is created with its first disk all other disks must be that size or *smaller* to be able to utilize all of the space on each disk. I've made it work before by adding the largest disks to the volume groups FIRST, then the smaller ones later, but I *THINK* I may have gotten away with it the other way around only once (and I don't know why, or if I don't really remember it that way). I do seem to remember having trouble trying to do this very thing in the past and not being able to use the full size of the new larger disks. I think that all of the newer disks in the case you've mentioned will come up, but only with 18g usable on each physical volume.

So, I don't think you'll be able to do it, unless you call getting only half of the space you thought you were getting a success.

[Lynn Hsu_2]

Is there any way to replicate data (all /vg01/lvol1) while system and application still running and make full 36g
usable?

Lynn

[Mel Burslan]

Lynn,

together with being an unsupported tool, there is something called vgmodify (available by asking to your HP account support engineer) which has a spotty success rate. Using this utility, you *MAY BE* able to modify the max PEs per PV setting of your VG. In which case you can make use of the whole 36G. Otherwise, I don't believe you have any other option that, recreating the VG with these new drives, utilizing full 36G capacity and have down time to replicate data using vxdump|vxrestore, which should not be outrageously bad.

[TwoProc]

Well, if you have a test system you can learn on...

I'm thinking you could create a new vg with one of the new sized disks in it.

Then, take the smaller size disks from a known vg with known lvs and pvs and vgreduce them from their vg.

Then, vgextend the new vg onto the disk taken from the old vg.

Then create your new lv's WITH EXACTLY the same size factors on the same disks that you moved over, in order, and repeat for all pv's, moving them one at a time to the new vg making sure that the each disk comes over with the lv boundaries laying on the same extents as they were in the old vg (extent sizes must match the old vg or you're hosed).

Then creating the lv's from where you know they should now reside on the pv's. Repeating until all back, but in the new vg.

Now, add the rest of the new disks by vgextending them into the new vg.

Now, mirror the old lv's onto the new disk space from the pv's having the new 36G disks, and that should do it.

This should be do-able and - pretty straight forward (though lengthy) - but any screw ups and you've hosed your data.

So, a backup would be required first.
Also understanding and perfection of the technique on a test system before proceeding forward would be required. This is pretty tricky if you've not been exposed to this stuff much before, so make sure you're pretty good at it before attempting.

[Lynn Hsu_2]

Mel and John,
Thanks for pointing directions. I'll test
it out on a test system.

Sincerely,

Lynn

[Kyris]

Lynn,

Perhaps I am missing the point here!!!
If u have an 18GB disk and want to mirror this to a 36GB, then, from my experience the extra space on the 36GB will NOT be visible to the system.
I am working on the K class systems..

kyris

[Jayasuntar]

Hi Lynn,

Please make sure that this time atleast u r specifiyng the max pe per pv, and pe size while creating the new vg as per john's advice. So that next time u will not face the same problem.

#vgcreate -e (pe / pv
) -s (pe size) vgname pv_path

All the best

regards

Jay

[Lynn Hsu_2]

Good info. Thanks!