非常差的优化:Riverbed-Test-Appliance和NetApp SnapMirror复制

实际上,我们正在testingRiverbed Steelheads,以便在两个站点之间使用SnapMirror加速复制

站点之间的距离为100公里。 连接:150Mbit MPLSnetworking

系统:使用ONTAP 7.3.4的FAS6080(源)和FAS3160(目的地)

SnapMirrorconfiguration如下(snapmirror.conf):

FAS6080 =多(10.128.85.43,10.128.136.15)(10.128.33.68,10.128.136.15)

FAS6080:/ vol / M0P_DB / sapdata FAS3160:/ vol / sm_M0P_DB_dbp_test / sapdata kbs = 15360,wsize = 4194304 15 2,6,10,14,18,22 * *

而NetApp上的networking:

mvif:flags = 0xa2d08863 mtu 1500 ether 02:a0:98:0f:30:fe(启用虚拟接口)

mvif-1604:flags = 0x6948863 mtu 1500 inet 10.128.85.43 netmask 0xffffff00 broadcast 10.128.85.255 partner mvif-1604(not in use)ether 02:a0:98:0f:30:fe(启用虚拟接口)

mvif-1610:flags = 0x6948863 mtu 1500 inet 10.128.33.68 netmask 0xffffffc0广播10.128.33.127伙伴mvif-1610(未使用)ether 02:a0:98:0f:30:fe(启用虚拟接口)

有没有人有一个想法,如果有一个特殊的configuration,我忘了为了优化复制?

问题是我以前有8Mb / s的复制速度,现在是16Mb / s … Peek是20! 这还不够,我找不到它来自哪里

在此先感谢您的帮助!

你在用什么河床模型?

  1. 对于Riverbed来说,一般的经验法则是不要做应用程序级的压缩。 让河床去做吧。
  2. 在优化stream量时,如果保留默认设置,河床将尝试使用磁盘进行重复数据删除。 与此相关的问题是Riverbed使用SATA,除了大多数顶端系统外,这为复制等高吞吐量业务创造了瓶颈。 此外,这种stream量通常不是非常可重复的,所以它基本上抹去了你的磁盘caching不好。

我们遇到了Equallogic复制的类似情况。 进入你的path中的规则,并设置你的SAN所在的子网,只进行内存caching(确保这是高于你的optimazie所有规则,所以它首先适用)。 这应该会加快你的复制。 为了获得更好的吞吐量,你基本上放弃了一些数据的减less。