I read with great interest a recent article by InfoWorld contributing editor Matt Prigge titled, “When WAN optimization really boosts network performance.” In general, I agree with the bulk of Matt’s comments — storage vendors are getting better at replication over long distance, some WAN optimization products don’t benefit from every type of replication — and I agree 100% with his statement that anyone considering replication acceleration should try it on their own network with their own data.
As far as deduplication goes, however, I disagree that most SAN platforms have deduplication; even fewer have the ability to maintain deduplication during replication. With the exception of the arrays that were purpose-built for deduplication, typically as a backup target, most primary arrays replicate the full dataset. This will change in the future, but today it is rare among the most common products. This is a difficult conversation because most vendors and customers automatically believe they are deduplicated and compressed, and as a result, they will receive no additional benefit from replication acceleration.
The truth is that it is not uncommon for an additional 20-30% savings over the deduplication already provided. Typically this comes from either a level of granularity that the array doesn’t have, or, more commonly, the accelerator has the benefit of seeing data from multiple arrays and applications that have redundancy between them.
For the TCP optimizations, I agree 100%. Every array will let you modify the Window Size. Some arrays even support more advanced TCP options. What the arrays don’t do is deal with problem networks. Having a large Window Size is great until the MPLS network starts dropping packets or reordering packets to the extent that the receiving array thinks there is loss. When you add latency (distance) to this, the problem is exacerbated and you end up moving 7 Mbps over a 100 Mbps connection. With customers moving to MPLS, or even an Internet VPN, this is a serious problem that the arrays really can’t solve. Replication acceleration can help tremendously with this, typically letting the customer who sees 7 Mbps actually use the entire 100 Mbps WAN.
At the end of the day it isn’t just about deduplication, or Window Size, it is about the entire suite of enhancements that you get from acceleration. Whether it’s deduplication, WAN quality repair, or protocol optimization, all of these things combine across replication applications to improve performance and help customers meet their RPO.
My message every day to customers, partners, and our own sales team, is all about RPO. If you aren’t meeting your RPO it doesn’t matter if your data is deduplicated or optimized by the array, your replication is broken. If a replication accelerator fixes your problems and you are meeting your RPO, does it matter which feature made it happen? I have seen customers repair problems that prevented an initial synchronization, customers that had replication jobs that previously took 10 days to complete reduced to just hours, and customers that could move data over the distance desired while actually increasing the distance between their primary and DR site.
If you can’t meet your RPO, or you have bandwidth issues, or you can’t protect all of the data in your data center, or if you want to move your DR site farther away, replication acceleration can usually help and you should try it on your own network with your own data.