Replication is becoming an ever more important component in the protection and recovery of applications. Anecdotal evidence already suggests that 50% or more of all SAN and NAS storage systems ship with some form of replication software while many more organizations use replication in its other forms (application, appliance or host-based). But regardless of what form of replication software that organizations buy, they are many times unaware of the subtle ways in which replication software products differentiate themselves.
Replication software is the same in that all four forms of it – appliance-based, application-based, host-based and storage array-based – share the trait of replicating data from one device to another. But this is where the similarities can end and differences begin.
Each replication software product possesses unique characteristics. This may make one offering more suitable for some implementations and less than ideal or even completely unusable in others. Therefore it is imperative that users understand how the underlying replication software (in whatever manner it is implemented) functions so they can select the proper one for their organization.
In this first of two blog entries, I will look at seven factors that every user should consider when evaluating any replication software solution:
- Continuous versus scheduled replication. How frequently the replication software replicates data from point A to point B can vary widely by product. Some replicate continuously and synchronously which means that any time an application writes new data, the write has to complete at both point A and point B before the application can continue processing. This keeps the data in sync at both locations (hence the name synchronous replication) but it can result in degraded application performance if point B is a substantial distance away.
Some replicate continuously but asynchronously. This means the write to point A is completed before the data is replicated to point B. The upside is that this form of replication can support long replication distances between sites without impacting the performance of the primary application. The danger is that the replicated data at point B gets out of synch with point A (albeit only slightly) so some data loss can occur.
Finally some replication software replicates data only at scheduled times – once a day, every 4 hours, every 15 minutes or whatever. Less data may need to be replicated and this method also eliminates the need for application writes to complete at both locations. However there is a greater chance for data loss and for more data to be lost should there be an interruption in replication.
- Efficiency of data transfer. How efficiently the replication software transfers data from point A to point B is a point that is often overlooked. Replication software may not compress or deduplicate the data before it is sent or, if it does, may use only a very rudimentary form of these technologies.
Depending on the amount of data that needs to be replicated and how quickly it needs to be replicated, it is quite possible the replication software may fill existing network pipes with too much data and negatively affect other production processes. This situation may force organizations to purchase an appliance that can optimize this traffic for network replication or obtain a replication solution that provides this bandwidth optimization as part of how it does replication.
- Block versus file. Whether a replication software product supports block or file replication does not make it “good” or “bad” but it is one of the determining factors as to whether or not a product is one that should remain in contention.
Replicating at the block level means that the replication software only replicates blocks of data on the disk so it is mostly agnostic as to what application data is being stored on this disk. While many of these replication software products integrate with specific applications, it is only to provide checkpoints for recovery purposes.
Conversely, file system based replication products are very aware of the data that they are replicating. This allows them to be choosier in the data that they replicate (down to the directory level) but it may preclude them from replicating certain kinds of data such as databases or email data stores.
In a perfect world, organizations will want to select a replication software product that supports both block and file replication so they can implement whatever form of replication that their environment needs.
Check back next week for the last four considerations when choosing a replication software product!
Part 2 – 7 Considerations when choosing a replication software product.