topic Re: Storage migration in Operating System - HP-UX

Storage migration

aruns_s — Fri, 29 Feb 2008 03:20:09 GMT

We have got a requirement to migrate 8TB of data from one storage box to another..At present, we have got small sized luns (9GB) which need to be migrated to higher Luns - 70/80GB.Total volume of data adds upto 8TB.what is the best way to do this migration.I believe we should go for a third party tool. What would be the approx. time if I use cp /dd/ pvmove

Thanks in advance

Re: Storage migration

TTr — Fri, 29 Feb 2008 04:09:04 GMT

The approximate time to copy data using cp/dd/tar etc is about 1 hour per TB. But this can vary greatly depending on your server, how many I/O channels you have to your SAN, if the reads and the writes are on separate channels, how fast are your disk arrays, how fast are your LUNs, how many concurrent copying jobs, etc. You should run a small test, say copy 10 - 20 GB and extrapolate. Also test how many concurrent copys your environment can tolerate.

Re: Storage migration

Don Mallory — Sat, 01 Mar 2008 03:04:37 GMT

You could use something like EMC SAN Copy, but it's expensive.

pvmove only works in the same VG, and only if you set your max extents per PV higher than the current size of the disk at VG creation time. Otherwise, any volume you add will only be the size of the current max PE * max PE / PV size.

Backup and recover is an option, but means 2 copies.

If you can have both sets of LUNs presented, why not use rsync?

Using rsync -av --stats --progress --delete /source/ /dest/, the first run will take some time, and it tends to run out of memory if you do runs of > 2.5million files, but after that, it's a mirroring tool, you can continue to run it nightly and at the flip time, shut down services, one last rsync and you're done.

The --delete deletes files on the destination as they are removed from the source.

Don't run more than 2 at the same time, it spawns 3 processes per run, (monitor, source, dest).

It's in the iExpress bundle, but a newer version is available from the porting and archiving centre.

http://hpux.ece.ualberta.ca/hppd/hpux/Networking/Admin/rsync-2.6.9/

If it's a database, you're out of luck either way.

By the way, this is what I'm doing for 4TB of file services. The largest shared area is 3.7million files and 1.3TB in size.

I've broken the rsync into groups and it's scripted and cron'ed to run nightly for updates. For this size, it take about 37 minutes per night to do a refresh job, including data copies. For busy days, it peaks at an hour.

Re: Storage migration

radkol — Sun, 02 Mar 2008 08:15:31 GMT

Hi,

May be it's a good idea to assign new LUNs to the same system, add them in the same volume group, crate PVG over new luns and make mirror of existing LV to new PVG, once ready , you can
reduce mirrors with old Luns and take out them out of VG.
That's all, even you can do it on-line wihtout outage.

Hope this help.
If you need more details, please ask.
Cheers

Re: Storage migration

Mark Grant — Mon, 03 Mar 2008 07:02:29 GMT

I just did something similar to what radkol (above) suggests and it works fine if you have created your volume groups in the first place to allow enough disks in the volume group.

You don't actually need the PVG's that he/she mentions, just mirror LV's and then break the mirror afterwards. I did this on productions systems online.