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
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 managementThe 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
This was first published in August 2006
Storage Management Strategies for the CIO
Join the conversationComment
Share
Comments
Results
Contribute to the conversation