hi all
is there a limit, on the netapp side of things, that would prevent snapmirror traffic from increasing beyond 30mbits/sec ?
No. We generally get snapmirror to go higher then 200MB / sec.
-Blake
On Tue, Apr 22, 2008 at 3:14 PM, Mailing Lists lists@up-south.com wrote:
hi all
is there a limit, on the netapp side of things, that would prevent snapmirror traffic from increasing beyond 30mbits/sec ?
-- eats the blues for breakfast, does unix for rent, plays harp for food, will play the flute for kicks rides for the freedom scrapes for the challenge
Not by default. You can set a throttle on a snapmirror relationship or you can adjust your snapmirror tcp window size for all snapmirror operations. ----- Original Message ----- From: Mailing Lists To: toasters@mathworks.com Sent: Tuesday, April 22, 2008 6:14 PM Subject: snapmirror speed limit ?
hi all
is there a limit, on the netapp side of things, that would prevent snapmirror traffic from increasing beyond 30mbits/sec ?
-- eats the blues for breakfast, does unix for rent, plays harp for food, will play the flute for kicks rides for the freedom scrapes for the challenge
Mailing> is there a limit, on the netapp side of things, that would Mailing> prevent snapmirror traffic from increasing beyond 30mbits/sec
Are you going over a LAN or WAN connection to the remote side? And if over the WAN, how long is your ping RTT time? The longer the WAN link, the poorer SnapMirror/SnapVault works, even though they say they have a 2mb TCP Window Size by default.
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
On either the source or destination storage system, enter the following command: snapmirror throttle n [system:] path n is the new maximum transfer rate in kilobytes per second. A value of zero (0) disables throttling. system is the destination storage system. Use this variable if you are executing the command on the source storage system. path is the destination path. The path can be the /volume_name or /vol/ volume_name/qtree_name
- from the ONTAP Data Protection Online Backup and Recovery manual
"John Stoffel" john.stoffel@taec.toshiba.com Sent by: owner-toasters@mathworks.com 04/23/2008 08:58 AM
To "Mailing Lists" lists@up-south.com cc toasters@mathworks.com Subject Re: snapmirror speed limit ?
Mailing> is there a limit, on the netapp side of things, that would Mailing> prevent snapmirror traffic from increasing beyond 30mbits/sec
Are you going over a LAN or WAN connection to the remote side? And if over the WAN, how long is your ping RTT time? The longer the WAN link, the poorer SnapMirror/SnapVault works, even though they say they have a 2mb TCP Window Size by default.
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
Kelley Green wrote:
On either the source or destination storage system, enter the following command: *snapmirror throttle **/n [system:] path/* /n /is the new maximum transfer rate in kilobytes per second. A value of zero (0) disables throttling. /system /is the destination storage system. Use this variable if you are executing the command on the source storage system. /path /is the destination path. The path can be the //volume_name /or /vol//volume_name///qtree_name/
i know about the limits in the conf file, mine dont have limits there, was wondering why i cant get better than 80mbits/sec luezman> limits there, was wondering why i cant get better than Bluezman> 80mbits/sec
How fast is your WAN, and what is the RTT time from Ping across it? Basically, snapvault/snapmirror sucks for WAN work, no matter what NetApp says.
But I also agree it's a hard problem which TCP isn't really setup to handle well due to it's Window Size defaults. Even with Snapmirror setup to a 2mb window size by default, which should be enough for my WAN link, I can still see the data transfer being a sawtooth, instead of a smoother line.
John
-
Bill Holland -
Blake Golliher -
Bluezman -
John Stoffel -
Kelley Green -
Mailing Lists