Thin friendly migration methods

[Richard Siemers]

We're in the process of migrating AIX, ESX and Windows systems to 3Par T800 from Clariion CX600s. All the new target LUNs are thin provisioned and we want to preserve that "thin" as much as possible.

ESX migrations have been easy as pie. We opted to use a 500 gb thin provisioned LUN as a standard "datastore", and our ESX admin has been using native Vmware tools to migrate the VMs over to the new storage converting them to ESX thin provisioned in the process.

AIX migrations are getting done using the native AIX volume manager. We have discovered that we can install the 3par ODM definitions and MPIO works without a reboot despite 3par docs requiring a reboot. The volume manager method is NOT thin provision friendly and appears to be copying every block, even empty ones. I'm told a future version of 3par code will permit us reclaim blocks of 0s from these LUNs, someday.

Windows x32/x86 and x64 migrations have been done with good'ole robocopy when we can take an outage on the system. Unfortunately, we have cases where we can't stay down that long and needed a hot online method. EMC has the answer with their Open Migrator LM software, as an EMC customer you should be able to get your hands on this gem for free (maybe not after they read this). This software requires a reboot to install it, and a reboot to finish the migration, but the data sync in between is hot and online with your server apps active. Best of all... you have the option of doing a full block by block replication OR a "Sparse Copy" which only copies the blocks in use by the NTFS file system... in other words this converts THICK to THIN.

Windows IA64 is not supported by EMC with the Open Migrator Tool. There is evidence in the help files and knowledge base that it can be installed and works... however RPQ is required to be supported. That was enough to scare us away from using it, so for these hosts we were limited to offline robocopies.

We looked briefly at solutions like Vicom and Cisco's DMM which are both san appliances that will migrate the data for you while the host is online, however both options were metered services starting at about $30k and implementation/training wouldn't fit into our time line.

I would like to hear how other companies are handling their migrations.

[ahalsell]

I'm about 2 days away from doing just this.

My plan is to use the AIX pvmigrate command to move the back-end LUNs and then:

cat /dev/zero > zero.txt;rm zero.txt

And let the array do the rest.


If zero_detect weren't in place, I don't know of a totally non-disruptive way to do this.

We discussed at one point mounting the new LUN side-by-side, rsyncing, then stopping IO on the original, rsyncing again, then flipping the mount over.

That's messy and time-consuming, but it should at least minimize the time you've got to be 'down.'

[Richard Siemers]

How does rsync detect and react to changes? Does it copy the entire file over it's checksum changed, or does it break files up into sections and checksum portions of the file? Depending on how that works, it my be an ideal situation for a filesystem loaded with many small files... but not as good for a file system with just a few very large files (like databases).

Another way to look at your upcoming migration could be to zero your empty space now, turn on zero_detect, pvmigrate, turn off zero_detect and be done.

If you want to zero your free space while your production app is running, you need to be careful not to completely fill the filesystem, especially if the app adds or grows files at random. There is a 3PAR Thin Conversion Guide for *NIX that has a good solution to this. Basically they loop through creating 1 gig (or any size you like) zero files. They also claim it's more resource friendly to break it up instead of dumping one huge file. Here i the script 3PAR recommends:

Code: Select all

[root@rhel5 /] # mkdir /vcpvv600/zerofree 
[root@rhel5 /] # for ((i=0;i<7;++i)) do 
> echo Generating file /vcpvv600/zerofree/$i ... 
> nice dd if=/dev/zero of=/vcpvv600/zerofree/$i bs=1k count=1m 
> done 

Generating file /vcpvv600/zerofree/0 ... 
1048576+0 records in 
1048576+0 records out 
Generating file /vcpvv600/zerofree/1 ... 
1048576+0 records in 
1048576+0 records out 
...

Once the zeroing process completes, verify that all of the free space has be written with zeros:

[root@rhel5 /] # df –T /vcpvv600 
Filesystem   Type   1K-blocks   Used Available Use% Mounted on 
/dev/mapper/vg--f2t-vcpvv600 ext3   9978408   9978408   0 100% /vcpvv600

Finally, delete the files of zeros:

[root@rhel5 /] # rm –rf /vcpvv600/zerofree

Here is a copy of the full document for anyone interested, seems to be missing from their support site at this time.

luf2t-wp-09.1[1].pdf

3PAR Thin Conversion: Linux and Unix

(76.32 KiB) Downloaded 4063 times

Back when I originally wrote this thread, I was on 2.24 and Thin reclamation didn't exist yet. It is nice to go back and recover this wasted space. A lot has changed in the past year and a half. I am looking forward to the next 3 years to seeing the T10 SBC-3 standards ratified and deployed which will introduce new SCSI commands to unmap and reclaim storage automatically.

[ahalsell]

That's good stuff.

I was hoping to find a doc like that, but my account seems to have very limited access to docs.

I was planning to ask our buddy Bob if there was a doc like this, but it slipped my mind entirely.

Thanks




Rsync compares and transfers at a sub-file level. I'm not sure what the default block size for the rsync algorithm, but it can be tuned with "-B"