This week DCIG sent out surveys to over 20 different midrange array storage vendors that inquired as to how they implemented replication software on their midrange array controllers. However some have asked why DCIG is doing a separate Buyer’s Guide on midrange array replication software and not just including this feature as part of its upcoming broader 2011 Midrange Array Buyer’s Guide that is due to be released next spring. So in this blog entry I’d like to provide the three reasons as to why DCIG felt a separate Buyer’s Guide on replication software was necessary.
First, 100% of organizations buy midrange arrays for their storage capacity but at best only 50% use the replication feature on midrange arrays. Every organization that buys a midrange array is going to use the storage capacity available on it. However the percentage of organizations that utilize the replication feature is at best 50%.
The 50% number is arrived at based upon discussions that I have had with numerous storage vendors. They report that about 50% of their customers who buy a midrange array also license its replication feature. However the bigger question is, “What percentage of those customers who license the replication feature also use this feature and to what extent?” No one has really been able to provide a good answer to that question.
Second, replication software is implemented in many different ways. Most individuals who are moderately acquainted with replication software recognize that there are three broad ways that replication software can be implemented: asynchronous replication, synchronous replication and snapshots. But even within those three categories, there are different ways each of these features are implemented.
For instance, asynchronous replication can be implemented as either “continuous asynchronous replication” where every write I/O is copied, cached and then replicated to another midrange array or “periodic asynchronous replication” where a snapshot of one or more volumes is taken on a predefined schedule and then that snapshot replicated to another midrange array.
Both of these implementations fall under the broader “asynchronous replication” classification but with each of these implementations, there are different attributes to evaluate and certain features that you are giving up or gaining depending on which version of asynchronous replication is implemented on the storage array.
Snapshots are equally tough to define. In the case of snapshots, we found there are at least five different ways that snapshots can be implemented on storage arrays that can impact how long it takes for the snapshot to complete, how much overhead it introduces on the midrange array while the snapshot is occurring and then what you can do with the snapshot after it is complete.
The five different ways that snapshots may be implemented include:
- Two forms of differential snapshots – “allocate-on-write” and “copy-on-write”. An allocate-on-write locks downs blocks of data until all snapshots pointing to those blocks are no longer referenced while a copy-on-write snapshot creates a snapshot of changes to stored data every time new data is entered or existing data is replaced.
- Two forms of full snapshots – split mirror and full copy. A “split mirror” snapshot references all the data on a set of mirrored volumes and, every time a snapshot is created, one of the volumes and all of its blocks of data are split off from the other volume. Conversely, a “full copy” snapshot references all the data on a volume and, every time a snapshot is created, the snapshot of the volume is created by copying all of the blocks on the volume to another.
- A replica. This is a snapshot that is something of a cross between asynchronous replication and a snapshot where a snapshot is taken and then the blocks of data are copied to another midrange arrays.
Of the three categories of replication software, synchronous replication has ironically become probably one of the simplest forms of replication to understand since its definition has not changed that much since its introduction. Every write I/O is copied at the source with the write to the source and target needing to be first completed and confirmed before application processing can continue.
Third, organizations are using the various forms of replication software to protect and recover their virtual environments. DCIG just completed its research for a Virtual Server Backup Software Buyer’s Guide that will be released in a few weeks. In doing that research it became apparent that more backup software products are integrating with midrange arrays in order to manage the snapshot feature present on them and off load the processing associated with the backup from the host to the storage array.
It is for these three reasons that DCIG decided that a separate Buyer’s Guide on Midrange Array Replication Software was appropriate. It is important to understand that this Buyer’s Guide will complement and not replace the Midrange Array Buyer’s Guide as it will assist those organizations who are looking to purchase a midrange array and then leverage it for purposes other than just storing data. So when this Buyer’s Guide is used in conjunction with the Midrange Array Buyer’s Guide, organizations can make the most appropriate buying decision for their environment.
Have a Happy Thanksgiving!