One of the more entertaining debates in storage today is Replication – whether asynchronous or synchronous, hardware-based or software-based, to-disk or to-tape. And in almost all cases, the goal is for data protection (often referred to as High Availability (HA) or Disaster Recovery (DR)).
The problem is that this actually minimizes the overall benefit of replication to merely “data protection solutions.” High availability and disaster recovery are part of a bigger picture – that of Business Continuity (BC), and BC is about continuing business operations in all situations. HA and DR are to address unexpected outages to the computing environment, but what about planned outages like Migration projects?
Over the past twelve years, I have been involved in too many migration projects, and have learned that it doesn’t matter whether you are migrating from Windows NT4 to 2000, from an older server to a new one, or from direct-storage to NAS/SAN – the rules of migration still apply:
- The project starts after-hours on Friday (since the users cannot be on the system).
- There is, almost always, a specific step that is thought of as the “Point of No Return,” where some non-reversible change will be done. At that phase, you are committed to completion.
- And, if the project is not looking successful by Saturday evening, then the recovery process must begin to ensure that the old system is back on-line by Sunday night.
These conditions are particularly true for “in-place” upgrades (i.e. where the OS is upgraded on the system rather than the data being moved to a new hardware platform) where the point of no return is shortly after starting the upgrade. If it doesn’t complete, you better have a current back-up.
When these conditions are considered as a whole, it translates the term “Migration Project” into “Lost Weekend.” And if the project is sizable, it translates as “Lost 3-Day Weekend.” This reality was my wife’s biggest complaint about I/T as a profession (not withstanding the Saturday urgent pager interruptions and the stellar pay).
But, does it really have to be that way?
Replication technology is now widely available as a reliable method for providing a second (and even third) copy of your data – in a non-impacting manner to your production environment. Typically, we look at replication technology (in its many forms) only for data protection. In actuality though, replication can be thought of as a tool.
Instead of starting the migration project on Friday night, why not installing the new platform on Monday afternoon and then beginning replication from the existing platform? If the replication takes two days (in a controlled or throttled environment), then the new platform will be ready for production by Wednesday. Then, simply spend Thursday and Friday redirecting users (via login-scripts or mappings). First, re-direct some test users and when successful, everyone else. If there is a problem, you can find out immediately – and the original platform is still available and on-line.
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 email@example.com