Have you played with Juniper or Riverbed WAN expander/accelerator devices? Have used them successfully with SM and high latency connections.
Budget allowing ... But may be less PIA than manual scripting plus additional benefits they offer.
Christopher
-----Original Message----- From: John Stoffel john.stoffel@taec.toshiba.com Sent: Wednesday, June 04, 2008 15:07 To: Glenn Walker ggwalker@mindspring.com Cc: John Stoffel john.stoffel@taec.toshiba.com; lists@up-south.com lists@up-south.com; Blake Golliher thelastman@gmail.com; Fox, Adam Adam.Fox@netapp.com; toasters@mathworks.com toasters@mathworks.com Subject: RE: snapshot copy
Glenn> You can always try adjusting the wsize of the snapmirror Glenn> connection over WAN. Could help...
Nope, doesn't help. The default snapmirror tcp_window_size is already 2mb, which *should* be enough for my site, but doesn't do a damm thing to help.
Again, if you have a WAN link with high latency and high bandwidth, snapmirror/snapvault both suck in my experience. Which is why I'm spending my time doing lrep's by hand to rebuild DR snapvaults.
Friggin sucks...
Christopher> Have you played with Juniper or Riverbed WAN Christopher> expander/accelerator devices? Have used them successfully Christopher> with SM and high latency connections. Budget allowing
Yes, we have tested them and other vendors and are now using WAN accelerators. They do make a difference, though if you need to move 1tb or more across the WAN, it's much faster to use lrep_reader and bbcp, or even dump to tape and fedex overnight.
I'll probably do that with my 4tb volume.
Christopher> ... But may be less PIA than manual scripting plus Christopher> additional benefits they offer.
Unfortunately, WAN acceleration devices are not the end all that their vendors claim. You need to benchmark them in *your* environment with live data (ideally) to determine if they will be worth the investment.
For us, they were, but it's still not enough when I need to move lots of data across the WAN.
John
-
Christopher Mende -
John Stoffel