snapmirror : working with Riverbed WAN optimizers

[holahan]

Hi:

I currently have filers (FAS6290s) running snapmirrors to and from remote filers...transmitting tool data and DR backups.

My WAN network setup includes Riverbed Steelheads at both ends of the WAN connection.

My issue concerns the syntax of the snapmirror.conf file; I have compression and multipath enabled.

The multipath is not truly configured a multipath, meaning it only has the source and destination in the config syntax:

source_c=multi(source_filer,destination_filer)

source_c:volume1 destination_filer:volume1 compression=enable,kbs=5200,restart=always 00 00 * *

source_c:volume2 destination_filer:volume2 compression=enable,kbs=5200,restart=always 05 00 * *

.....<etcetera>...

From discussions from my WAN engineer he sees no optimization being performed on the snapmirror transfers.

According to him (and references within Riverbed documentation) compressed data and multipath data is not

optimized by these WAN Steelheads.

Does anyone know if this is correct? Is this fix simply removing the compression option and removing the multipath syntax?

In addition to the multipath, netapp allows the syntax to have  just one source/destination entry....but what is the purpose for

using the multipath setup if I really do not use 2 separate sources and do not use 2 separate NIC ports on the destination filer?

Thanks,

Joe

[ekashpureff]

Joe -

Given the compression on the NetApp there isn't much room for the Riverbeds to do further optimization.

You may save some CPU on the filers by turning off the compression and let the Riverbeds do the work.

Snapmirror over multiple connections may be configured as single or multi mode.

Multi gives increased bandwidth using both connections.

Single gives failover in the event of primary path failure.

I hope this response has been helpful to you.

At your service,

Eugene E. Kashpureff, Sr.
Independent NetApp Consultant http://www.linkedin.com/in/eugenekashpureff
Senior NetApp Instructor, IT Learning Solutions http://sg.itls.asia/netapp
(P.S. I appreciate 'kudos' on any helpful posts.)

[holahan]

Yes, you confirm what I have been thinking about offloading the compression to the Riverbed units.

About the multi versus failover.....The single (failover) syntax still requires 2 source paths defined in the snapmirror.conf

I just was wondering if having only one source defined in the multi syntax if there is any advantage?

The syntax I had in my snapmirror.conf:

source_c=multi(source_filer,destination_filer)
source_c:s00 destination_filer:s00 kbs=5000,restart=always 00 00 * *
source_c:s01 destination_filer:s01 kbs=5000,restart=always 05 00 * *
source_c:s02 destination_filer:s02 kbs=5000,restart=always 10 00 * *

So with only one source/pair defined; is the multi syntax effectively ignored?

Is there any adavantage to this syntax setup?

thanks for your info.

Joe

[Darkstar · Accepted solution]

you should definitely let Riverbed do the optimization and disable compression on the filer. We have seen instances of SnapMirror updates being optimized by 85%(!) by using Riverbed between the sites. I doubt NetApp can do that much with compression alone, AND it's easier on the CPUs.

As to multi- vs. single path, this only makes a difference if the two paths are each speed-limited on their own, i.e. if you have for example 2 WAN providers. Then you can effectively add the capacity together. It makes no difference if you only have one path anyway (e.g. 2x5mb/s multipath or 1x10mb/s singlepath makes no difference at all)

[holahan]

Yea, I have come to that conclusion.

I removed compression from my most important replicas and receive affirmative reports from the WAN engineer of significant optimization on the Riverbed Steelheads.

And I have taken the multi(..., ...) out of the configuration file as well. 

Thanks to you (and the guys above) for confirming my thoughts on compression.

regards,

Joe

---

@Darkstar wrote:

you should definitely let Riverbed do the optimization and disable compression on the filer. We have seen instances of SnapMirror updates being optimized by 85%(!) by using Riverbed between the sites. I doubt NetApp can do that much with compression alone, AND it's easier on the CPUs.

As to multi- vs. single path, this only makes a difference if the two paths are each speed-limited on their own, i.e. if you have for example 2 WAN providers. Then you can effectively add the capacity together. It makes no difference if you only have one path anyway (e.g. 2x5mb/s multipath or 1x10mb/s singlepath makes no difference at all)

---

[richard_payne]

It wouldn't surprise me if the RiverBed were smart enough to see the stream is already compressed and ignore it, since compressing it again probably wouldn't save anything and in fact may inflate the traffic.

It would be intereting to know which mechanism gets 'better' thoughput. Snapmirror compression or use of the Riverbeds. I know we use the Revierbed for WAN accel and I've wanted to try the experement but never had a chance to setup it up (that and our filers are busy to start with so SM compression isn't really an option in most cases anyway).

--rdp