This is part of a series on Enterprise Data Migration Strategies:
So far in this series of posts I’ve discussed the pre-work required in order to get to a position to execute on actual data moves. In this post, I’ll discuss the migration scenarios and how to ensure data integrity is maintained throughout this process. The final post in this series will talk about some of the migration tools which may be utilised.
Maintaining Integrity
Migrating data is a pretty simple task. You could simply copy the files from one volume to another; you could use replication tools like SRDF, TDMF or even the host native volume manager. However during this process, it is essential to ensure that data integrity is maintained. If something goes awry during the data move stage, the last thing you want is to be unsure of the position of the last valid copy of your data. Here’s what could go wrong:
- The copy process itself fails.
- The server crashes/reboots.
- The target storage device crashes, or becomes unreachable.
- A minor datacentre issue occurs (array failure for instance).
- A major datacentre issue occurs.
- Replication or access to a remote datacentre is lost or disrupted.
In addition, consider that a more complex migration plan will be required for hosts which have replicated storage and/or point-in-time clones or snapshots. If these form part of the business processes on the server, then chances are they will all need to be up and synchronised before the server can be accepted as migrated successfully.
Get The Business Involved
At this stage it may be a good time to re-emphasise something I’ve mentioned already, and that’s making sure you have a good relationship with your server owner. Obviously they will have been in previous discussions regarding migration, however you need to know from them exactly how the storage on their server is used. You need to be aware of any business processes which rely on snapshot or other point in time copies of data. In terms of the migration process, you should be developing a business-centric view of the migration steps, which shows at each stage of a complex migration, exactly what the currency of each instance of data is. Obviously this isn’t essential for every single server within a storage environment, but will certainly be important for the most complex configurations.
Some Typical Examples
Here are some typical migration scenarios:
- Synchronously Replicated Data. Host data is mirrored between a primary and secondary array. Replication is used for disaster recovery. Here, the migration process must maintain the DR position for the data. If it’s possible to take an outage then the mirroring can be split re-established to a new replication pair, perhaps by making the new local copy a snaphot clone. If no outage is possible and the application/server must be kept running then this won’t be an acceptable solution. In this case another method is required, for example host-based mirroring.
- Asynchronously Replicated Data. Host data is mirrored between a primary and secondary array. Replication is used for disaster recovery. In this scenario, the same issues apply as with synchronous replication, however there’s the added complication of maintaining write order/consistency during the copying or only accepting a checkpoint of the completed copy.
- Replicated Data With Local Snapshot. Data is replicated remotely with a local snapshot for instant data recovery. This option adds the extra complication of retaining a local snapshot. If the snapshot has to be retained from a specific date/time, then the snapshot itself will also require copying. Obviously the snapshot can’t then be associated with its source volume until a new copy is required as it would potentially overwrite the contents. Where possible (for example with daily snapshots), it may be possible to tie the migration to creation of the snapshot and complete the snapshot recreation after data has been moved to the new location.
- Three Site Replication. Data is replicated through an intermediate site. Here, specific vendor technology is being used to create a multi-hop configuration, perhaps for enabling a mixture of synchronous and asynchronous replication. The process in which the intermediate copy is used needs to be examined to ensure integrity can be maintained during the migration. The same previous comments apply, however consideration needs to be given to where any data recovery would take place — so if the intermediate site it not used for data recovery, then the final location needs to provide an acceptable recovery point.
Summary
Where complex replication techniques have been used then data migration needs a little extra thought to ensure consistency can always be maintained. Hopefully most servers won’t fall into the complex category, but having a list of migration scenarios to meet each configuration type is essential to making sure migrations run smoothly.
