pvmove and online disk migration

[Adam Garsha]

Is it ok, acceptable, common to use pvmove to migrate data from one physical disk to another while the logical volumes and filesystems are active and mounted? Comments welcome.

Background: I need to move a subset of data to a different storage array, using pvmove looks like I could do this "under the hood" and incrementally.

[James R. Ferguson · Accepted solution]

Hi Adam:

Yes, it is acceptable to use 'pvmove' to migrate data while things are active.

*However*, do not interrupt or otherwise cause 'pvmove' to be interrupted during its execution. Killing a 'pvmove' can leave orphaned logical extents.

Regards!

...JRF...

[Adam Garsha]

If performance goes in the toilet, is there a way to stop or pause a pvmove?

Will performance likely go in the toilet? is there a way to tell pvmove to take-it-easy/throttle?

I guess I am wondering if by default pvmove is going to as aggressively-as-possible move blocks or whether it will move blocks in a "background-style" manner.

Thanks.

[Adam Garsha]

P.S. I am not talking about database luns here. "Just" app server luns.

[Adam Garsha]

P.S. points will come.

[James R. Ferguson]

Hi (again) Adam:

If a performance impact is a concern, schedule the action for a "quiet" time.

A 'pvmove' is roughly equivalent to a mirror operation. In fact, 'pvmove' and MirrorDisk/UX share common LVM code. You get 'pvmove' for free but pay extra for the MirrorDisk ability.

Regards!

...JRF...

[Thomas J. Harrold]

I have used pvmove *many* times, and appreciate it's simplicity over mirrordisk to migrate data.

A few years ago, HP's "official" stance was that they recommended mirrordisk/ux over pvmove. (build mirror that includes your new volume, allow sync, then reduce the mirror copy where your data was originally located).

I guess the advantage of mirrordisk, is that there is ALWAYS at least one copy of every extent, so even if a mirrodisk operation is interrupted, you still have NO risk to your data.

Given that, I still like pvmove for quick data moves. If you have extremely large LVs to move, and you are concerned about availability, look at using mirrordisk.

-tjh

[Bill Hassell]

mirroring will accomplish the same task but not as simply as pvmove. Mirroring will make a copy of all your data in the background, but once completed, you still have to reduce the mirror by carefully specifying the LUN to be removed. Both pvmove and mirror sync perform the task as an 'atomic' task, that is, once an extent is ready to mirror or pvmove, *ALL* access to that extent is frozen, the copy is made, then the copied data is verified and finally, the extent is freed for further access. If the filesystem is very busy, this will definitely have an impact, and will also have an impact on anything connected to the same I/O channels. There is no low impact option -- the task is critical so it proceeds without interruption. Becasue it is 99% disk I/O and almost no CPU time, things like nice and renice will have no effect.