Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Data migration products: Proceed with caution, page 2

Host-based data migration products are the best choice for moving mission-critical data. While there are only a few products in this category, they vary significantly.

Server-to-remote server data migrations
Migrating data at a block level from the source server to a remote target server introduces a different set of issues:

  • Creating the initial copy of the data on the target server
  • Synching the data once the initial copy is in place
  • Going forward to the target server
  • Falling back to the source server
  • Shutting down the application to switch between servers

How the initial copy of the data is created on the target server depends on three variables: distance, bandwidth and the amount of data. When the target server is close, there's a minimal amount of data to move and ample network bandwidth between the source and target servers; creating and synchronizing the data between the source and target servers is no big deal. However, it becomes an issue when you need to migrate a large amount of data over a limited bandwidth network connection; each product offers a way to accomplish this objective.

Symantec's Veritas Volume Replicator uses checkpoint initialization, replicated volume group (RVG), storage replicator log (SRL) and replication link (RLINK) to move large amounts of data from the source to the target server by creating a full hot block-level backup to tape. The SRL is used to map changes during the backup; Veritas Volume Replicator places a check-start pointer in the SRL when the backup begins and a check-end pointer at the end of the backup. The tapes with the backup are then sent to the target server and the data is restored there.

Once restored, Veritas Volume Replicator on the source server communicates with the target server and sends over the two SRLs it owns: the one created during the backup and the one with all data since the completion of the backup. The target server's copy of Veritas Volume Replicator first replays the SRL created during the backup to create a consistent but out-of-date backup on the target server. It then replays all entries created in the SRL since the end of the backup to create an up-to-date copy of data at the remote site.

At that point, Veritas Volume Replicator's asynchronous feature can be used to keep the data in a near-real-time state, or its synchronous feature can keep the data in a real-time state between the two servers until the final switchover is complete. Veritas Volume Replicator can also be reconfigured so that the data is then synchronously or asynchronously replicated from the target server to the source server in case there's a need to fall back to the original configuration.

Both Topio's TDPS and Softek's TDMF-IP include an option to create the initial copy of data at the remote site. TDPS' offline synchronization feature takes a baseline of the blocks to be moved, starts copying them to tape and then tracks any changes to the blocks going forward. Unlike Symantec's Veritas Volume Replicator, after the backup is restored on the target server, TDPS transmits only the final state of the changed blocks on the source server after all updates are applied.

Softek TDMF-IP's Courier Transport option allows users to create a copy of the primary data on some type of portable media. This media is then physically transported to the target server and restored there. Issuing a smart resync command then identifies all the differences between the blocks on the target and source servers, and sends only the changes to the target server.

Capturing only the deltas on the blocks between the source and target servers results in a configuration where all changes since the initial copy of the data were made aren't restored, a deficiency that neither Softek nor Topio views as an issue. Topio and Softek consider their products' objective to be data migration, not replication. As a result, a recoverable image of the data on the target server needs to exist just prior to the moment of switching over from the source to the target server.

For users with large bandwidth connections and large amounts of data, Softek TDMF-IP offers the option to multithread the streams of data. Using this option, users can identify and create multiple logical groups of volumes and then assign each one its own time and network connection for migrating the data. The "gotcha" with multithreading multiple volumes is that it consumes a lot of network bandwidth, so users need to be cautious about when they run these types of migration jobs. The risk can be mitigated within TDMF-IP by setting network consumption limits for each network stream that can be changed dynamically to interoperate with various production schedules.

Migration management
The way a product manages the migration of the data should also be considered. The Softek and Symantec products give users some flexibility in executing and managing data migrations. An administrator may log on to the server locally and kick off the data migration or use a central console to initiate the migration. Topio's TDPS requires that users have a Windows host available to load the management component of their software. In instances where the migration is occurring on that Windows server or from one Windows server to another, no external workstation is needed; but when migrating data on Unix servers, a Windows host must be available to manage the data migration.

Choosing the right host-level, block-based data migration software tool for your migration objectives is complicated but vitally important. For apps that need to be constantly running, block-based data migration tools are usually the best fit because they're agnostic to the source volume's file systems and database, yet maintain their integrity in the exact same state on the target volume. But application interruptions, from seconds to minutes or longer, do happen. It's imperative to have a tested and working back out plan in place before using any of these migration products.

About the author:
Jerome M. Wendt is a storage analyst specializing in the field of open-systems storage and SANs. He has managed storage for small- and large-sized organizations in this capacity.

This article first appeared in Storage magazine's August 2006 issue.

Click here to return to Data migration products: Proceed with caution, page 1

Dig Deeper on Storage migration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.