Replication - It's Not Just For Data Protection Page 2 - EnterpriseStorageForum.com

Replication - It's Not Just For Data Protection Page 2

When it comes to migration efforts, one of the variants (see the initial list of options at the top of this article) seems more appropriate. When deciding Synchronous or Asynchronous, my vote for most applications is asynchronous since it can be used over any distance and operates in the "background" with minimal overhead. Since synchronous mirroring must guarantee that both copies are always the same, the technology will introduce I/O latency where data is not serviced on the production platform in as timely a manner. This also addresses the second qualifier (hardware versus software) - since almost all synchronous solutions are hardware-based. Hardware solutions are invariably much more expensive. The third replication decision (to-disk or to-tape) doesn't really apply to migration projects, as we obviously want the data on the storage systems of the new platform. So, for migration - we want a software-based, asynchronous replication technology that can move data in the background while users continue to work.

Past that, there are probably two features that might help us differentiate between those offerings. First, it should be noted that the replication technology will focus on either partitions or on files/directories. While both would work, my suggestion is files/directories. Obviously, selecting the root-directory would equate to the partition approach - but the difference is flexibility. Partition-based replication technologies tend to require like partitions on the other server - so a 100GB partition on the source will require a 100GB partition on the target. This will limit your options if one of your goals is to migrate to a larger file system for consolidation purposes. Whereas with file/directory-based solutions, if you have 40GB of data on that 100GB volume, you simply replicate to 40GB of free space on the target server. With many products, this may also allow you to send data from E:, F:, and G: on the original platform to one big H: on the target (a very nice feature when migrating to NAS/SAN or server-consolidation projects).

The second differentiating feature is fail-over. In the larger-scheme of things, recognize that you are purchasing this replication software, so (after the migration is done) why not use the same technology to provide one of those data-protection solutions that we discussed earlier (high availability or disaster recovery)? The software is already paid for, you have acquired the knowledge on using the tool, and the platform that you just migrated from would seem to be an ideal disaster-recovery alternative. In the more tactical sense, you may also choose to "Fail-Over" the new platform for a fast, test-migration before actually rolling it into permanent use as the new production resource.

If I were going to give any more advice on replication, it would be to look for a company that is focused exclusively on replication technologies. Many replication products have changed ownership through acquisition and are now part of larger suites of protection software. Remember that even though replication can provide a much more graceful approach to your upcoming migration project (and the protection of your weekends), it is still a very significant "one-time" event for the server (or at most, an annual event) - so make sure that the software is mature and proven enough that it will handle all of your data, and permissions and nuances of your particular applications' files.

In closing, recognize that while replication can provide robust disaster recovery and high availability solutions, it can also be used as a flexible and effective data movement tool. The tool provides multiple copies of the data in your environment - what you do with alternate data sets is up to you. Put simply, to protect the productivity of your users, replicate for High Availability. To protect the data during a catastrophe, replicate for Disaster Recovery. To protect your weekends, replicate for Migration and Consolidation.

About the Author
Jason Buffington has been working in the networking industry since 1989, with a majority of that time being focused on data protection. He currently serves as the Director of Technical Marketing for NSI Software, enabling High Availability and Disaster Recovery solutions.

He can be reached at jbuffington@nsisoftware.com


Page 2 of 2

Previous Page
1 2
 

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 

Storage Daily
Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date