Open Replicator -consistent, -force_copy switches?

Roy,

The -consistent option uses Enginuity Consistency Assist (ECA) during session activation to temporarily pause I/O so that a consistent point-in-time copy can be created across all devices participatat. It's equivalent to the symclone -consistent option, which also uses ECA during activation to create a consistent point-in-time copy. For Open Replicator, the -consistent option applies when activating hot push sessions, and when turning donor_update off.

The -force_copy option would typically only apply if you first pushed data from a smaller to a larger device, and then wanted to pull it back from the larger device to the smaller device. For example, if we pushed the contents of a 50GB control device to a 100GB remote device, we know that only the first 50% of the remote 100GB device has data, so we can safely pull back that data from the 100GB device to the 50GB device with the force_copy option. If a host wrote new data to the latter half of the 100GB device prior to pulling back with force_copy, Open Replicator would not capture that data.

Hope that helps,

- Sean

Hi Sean, that's a lot clearer thanks.

I'm still finding it hard to imagine a use-case where I would ever copy a customers data to a larger device, then specifically never write any data to that device, and then write that data back to a smaller device, but thanks for the clarification (so I don't think I can ever see a reason where I will ever use either of these switches then, as I primarily do cold pull / hot pull where an EMC customer is migrating data to a new array to decomission an old array).

Many Thanks,

Roy.

you can always match VMAX size on VNX by creating a LUN and specifying capacity in blocks

No problem Roy.

Yeah, there aren't many use cases for the -force_copy flag. One that I could think of would be a case where you're migrating from a VMAX to a VNX, and you can't match up the LUN sizes exactly, so the VNX LUNs are slightly larger. If you perform your migration via hot or cold push, then cutover the host to the VNX, but don't expand the host partition/filesystem into the "extra" space on the slightly larger LUN, and you decide you want to rollback the migration (move back to the VMAX) -- you could use Open Replicator to pull the changed data back from the VNX and then move the host back to the VMAX. This is definitely a corner case, but it would require the -force_copy option.

Thanks,

- Sean

Thanks. Both good points @Sean / @dynamox. I see those both make sense.

I do see a few rare cases along the same lines as you say Sean, as customers quite often use a migration to expand a LUN (so they might ask to migate a 500 GB LUN to a 700 GB on the new array), so I push/pull to the larger LUN as normal, and if that copy was untouched *and* something happened to the original data *and* they wanted to rollback to the old array, I guess that -force_copy could be an option (but yes, these are very rare as migration events generally involve migrating the data and then cutting over the host to the new array).

hi,

we ran into an issue where the target LUN size (new vmax) is smaller by 2 MBs compared to source LUN size (old vmax). any idea force_copy might be an option in this scenario?  we're performing hot push migration from old to new vmax array and its failing due to 2 MBs mis-match mostly by 1 or 2 cylinder mis-match.

any suggestion please?

thanks in advance,

Mallik.

why not create properly sized device ?

+1 what @dynamox said   You'd be risking data loss by using force_copy in this instance... if there is any data on the last few blocks of your source devices, that data will not be copied to the new VMAX devices.

Pretty much any block-based migration tool would have issues going to smaller target devices... there are no options with OR that will work for this. Same deal for SRDF... And even many host-based methods like LVM-based mirroring, Open Migrator, and PowerPath Migration Enabler will have the same issues. File-based copy or file-based backup & restore would be viable options.

Have you ever had to resize an existing filesystem/partition before installing Linux for dual-booting a PC? Your migration issue is similar to that... before resizing, you typically have to defrag the existing filesystem to move data out of the last blocks in the partition. Once that's done, you can shrink the partition/filesystem, which effectively deletes those blocks. It's only safe after you've defragmented; otherwise you'd potentially be deleting data. You could use a similar process with your migrations here (assuming your host platforms are capable of performing a defrag)... but personally, I'd consider this too risky for production. Your best bet would be to recreate your target LUNs to be the same size or larger than the source, or use file-based migration methods.

Thanks,

- Sean

your target device will need to be the same size or larger (might be waisting some space unless host can handle file system extension) or you are back to host based migration.