Dave> Yes, NetApp's TCP implemention leaves much to be desired over Dave> WAN links. We had many long conversations with NetApp Dave> engineering, including tracking down a major bug with window Dave> scaling.
Do you know which versions of OnTap this referred to, and did they get any fixes into more recent versions? We're running 7.0.x on our filers, with 7.2.x on our R200s. If I *know* TCP performance will be improved, I'd work to upgrade them all to something newer.
Dave> We found a substatial improvement when switching to ICS Dave> (i.e. use multi(src,dest)(src,dest) even with single end Dave> points). Apparently when using ICS it uses a different internal Dave> network stack/interface which is much better over the WAN.
This is interesting, I've never heard of ICS. Does this work with Snapvault? Maybe I'll need to check the latest OnTap docs to see how to do this. Or could you post an example of how you set it up?
I'd love to try this out and see if it works better.
Dave> It still wasn't as good as our interim hack of proxying Dave> snapmirror connections via local Linux boxes (with their modern Dave> TCP stacks), but it ended up being good enough.
Now this sounds neat too. I should look into this since we have tons of fast opterons at our sites and it wouldn't be hard to setup a proxy for this. Do you have any pointers to how you did this, or what software you used?
Dave> WAN accelerators helped us greatly too.
They help, and we do get compression and speedup, but it's still hard to get the NetApp to actually *fill* the WAN pipe. Really frustrating.
What's worse is that LAN performance is great. Over the WAN I can *see* the sawtooth bandwidth of snapvaults when the TCP window scaling just screws up. Totally frustrating.
Thanks for your comments Dave.
John John Stoffel - Senior Staff Systems Administrator - System LSI Group Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec john.stoffel@taec.toshiba.com - 508-486-1087