HPE Storage Users Group

run statrcopy -hb and you will see the exact throughput. and it will aggregate all your RC links. You will see current and average tput and then will see round trip latency

Would you mind, either on-list or off-list, telling me a bit more about your IP connectivity? I am getting ready to procure WAN connectivity for 3PAR to 3PAR async replication. WAN optimizers are pricey, especially if one wants redundancy at both ends. At first glance the devices would likely not pay for themselves based on my connectivity costs alone. My link would only be for replication data, not typical remote office activities. Are there other reasons to use a WAN optimizer if you can afford the capacity you need unaccelerated?

We have 300mbs MPLS connection between data centers and other location is about 600 miles away and the latency on the WAN run solid at 24ms. That WAN is dedicated to DR replication. I am not a network person, but we are Cisco end to end. We use single RCIP port per controller node on each end so we have 4 ports running. Since we have numerous locations other locations we have a decent sized Cisco WAAS farm in each data center that does acceleration for more than just the SAN replication. We have fought our share of issues with HP (since their heartbeat for polling replication is buried in the data flows and also polls every 2 seconds, both f which are stupid design choices), but our QOS policy for the DR pipe gives the SAN the highest priority class (DB log shipping and Exchange replication are lower and consume far less pipe). After 7 months of working support issues we finally have it working well. We get 80-90MB/sec through the WAN because the accelerators on average gives us a 3-5X improvement on RCIP traffic. We also have seen bursts of 120+MB/sec which means our 300mb pipe often looks like closer to a 1gb pipe. 3.1.2 MU2 P24 is essential for fixing replication issues around large volumes and the scan times to process each replicated volume.

Also one thing to keep in mind is our numbers are based on the fact that I replicate over 500 volumes in 265 RC groups. The 3par is not all that great replicating a volume at a time and shines when you have all 20 (max concurrent volumes that can replicate at a time) going at once. When the RC is less busy and say only a few volumes are going at a time the array can not feed the pipe fast enough. One factor is that RC works off snaps and if you snap to NL drives and they are over-subscribed then the latency of the NL will impact your RC performance.

As for the accelerator what our network folks have determined is there are 2 methods to optimization, one is cache the other compression, for use cache has had little or no impact, but all our gains are on the compression side with optimization.

Thanks for all this additional info, very helpful.