NetApp Tech OnTap
     

加速低带宽链路上的复制:
SnapMirror网络压缩

对于很多公司而言 , 可用带宽是限制复制使用的主要因素。在最近对员工人数超过 1,000 名的公司所做的调查中, 44% 的公司反映带宽限制是影响其分支机构与远程办公室复制与数据保护计划的主要问题。

NetApp® SnapMirror® 精简复制软件已经成为大多数 NetApp 客户青睐的产品 , 因为其能高效使用网络带宽。其它复制产品在单个数据块改变时,会复制整个网络的文件,而 SnapMirror 则不同,其只复制变更的数据块,这样能够显著减少带宽需求。与竞争对手的解决方案相比,能够减少 50% 的管理费用,能够使用复制的数据集进行开发 / 测试、数据挖掘或其它目的,这些优势使 SnapMirror 极具吸引力。

即使 SnapMirror 拥有业经验证的高效 , 但是可用带宽不足以支持复制仍然是一个突出问题。为了更好地解决带宽有限的问题, NetApp 最近发布了 SnapMirror 网络压缩技术,其能够将带宽使用量减少 70% 或更多(取决于您的数据集的可压缩性)。

SnapMirror 网络压缩技术已经包含在 Data ONTAP® 7.3.2 中 , SnapMirror 无需支付额外费用即可使用。本文阐述了网络压缩如何工作,讨论了何时您应该(及不应该)使用,以及对于常规数据集已经取得的成效。

SnapMirror网络压缩如何工作?

借助 SnapMirror 网络压缩 , 数据只在网络中传输时被压缩 ; 源系统及目标系统中的数据保持原状。以下面的两步实现压缩传输 :

  • 在源系统上压缩
  • 在目标系统上解压缩

在源系统上 , 需要复制的数据块将被放到一个压缩引擎中对其进行压缩。压缩引擎根据存储系统上的CPU数量创建多个线程。多个压缩线程可以同时压缩数据。然后通过网络传输压缩的数据块。在目标系统上,压缩数据块在接收后会使用相同的多线程方法解压缩。解压缩的数据之后会写入适当的卷。

Functional diagram of SnapMirror network compression’ current Windows environment.

图片 1) 网络压缩功能图表

压缩与解压缩引擎可以根据用户喜好配置为 “ 保留网络带宽 ” 或在 “ 最短时间内完成传输 ” 。所有 NetAppSnapMirror 存储平台(包括 V 系列虚拟系统与 IBM N 系统)都支持 SnapMirror 网络压缩,但仅在异步运行模式下。 SnapMirror 的半同步与同步运行模式目前不支持网络压缩。

何时使用网络压缩

SnapMirror网络压缩在下列情境中非常有用:

当网络带宽成为一个限制时。 根据您的数据集 ( 查看下面的部分以了解数据集的信息 ) 的可压缩性 , 网络压缩支持您在链路中使用复制 , 而之前则无法达到或持续达到这一目标。

总的来说 , 面向灾难恢复的复制解决方案是否适用取决于您的恢复点目标 ( RPO ), 其定义了您想要恢复的时间点 ( 故障发生的时间 ) 。您复制数据必需足够快才能达到这一目标。例如,如果您的RPO是1小时,您必须能够复制每小时变更的所有数据,即使在活动高峰期间。如果您的网络带宽有限,网络压缩能够帮助您:

  • 在面对数据增长与 / 或更快的变更速度时 , 保持不变的 RPO 等级。
  • 无需购买额外带宽即可改善您的 RPO

同样的 , 如果您利用复制进行数据分发 , 网络压缩能够帮助您无需额外的带宽 , 即可持续达到现有时间目标或达到更加严苛的时间要求。

节省宝贵的网络带宽。 网络压缩能够帮助您继续执行相同的复制时间表 , 同时为其它功能保留网络带宽。

无需占据所有网络链路即可执行基线传输。 使用 SnapMirror ( 或任何复制产品 ), 您必须首先执行基线转输 , 使所有数据从源系统复制到目标系统。一旦基线就绪,并发传输只要求复制变更或新的数据。

创建基线可以成为一项宽带密集型操作。压缩支持基线传输更快完成 , 同时保留网络带宽。 (SnapMirror 提供了扼制特性,能够避免在基线传输或其它操作中,软件使网络达到饱和。 )

何时不使用网络压缩

决定是否使用 SnapMirror 网络压缩的主要因素是 CPU 资源。压缩与解压缩引擎会给源系统与目标系统的CPU都带来更多负载,因此在决定使用网络压缩时需要将这些因素考虑进去。在以下情况中,应避免使用网络压缩:

  • CPU 已经高度负载 无论在源系统或目标存储系统。因为压缩与解压缩会造成CPU使用率的增加,因此一般不推荐在CPU处理能力处于瓶颈并可能影响其它工作负载时使用压缩。
  • 当网络带宽不是限制因素时。 网络压缩必然会带来处理成本 , 在使用压缩的情况下可能限制 SnapMirror 相关的吞吐量。当网络不存在瓶颈时,以及无需为其它流量保留带宽时,您无需使用压缩。
  • 当使用 fan-in 配置时。 解压缩的成本只有压缩的 60% , 所以在大部分情况下 , 目标系统的性能不会成为一个问题。然而,如果您的配置是多个源系统同时都复制到单一的目标系统,对所有传输都启用压缩会使目标系统的处理能力无法满足需求。

以下将对于网络压缩带来的实际工作负载与对 CPU 资源的影响提供更多详细信息。

网络压缩如何更好地处理典型数据集
我们选择了三种不同的数据集来计算在实验室环境下 SnapMirror 网络压缩的性能 , 它们是 : Exchange 数据库、 Oracle® 数据库及主目录数据。我们对每种数据进行了8卷( 50GB )的数据量传输,对压缩比与 CPU 使用率两个方面进行考察。

Oracle 数据是最易压缩的 , 可实现 3.5:1 的压缩比 , 其次是主目录数据 , 比为 2.7:1 , Exchange 为 1.5:1 。如下表 1 所示,所需带宽的减少(保持持续时间不变)与压缩比大略是成正比的。

1 面向常规负载的压缩比与带宽节省。

数据集 压缩比 带宽节省
Exchange 1.5:1 34%
主目录 2.7:1 60%
Oracle
3.5:1
70%

每种数据集对于 CPU 成本的影响取决于您是否保持传输时间不变或是否加快传输。

  • 保持传输时间不变。 如果传输时间保持与不采用压缩时一致 , 压缩处理的成本通常都比较少。例如 , 一个数据集可进行 2 : 1 的压缩 , 在不采用网络压缩的情况下 , 使用 100Mb/ 秒的带宽 , SnapMirror 更新需要花费 1 小时 , 而在采用网络压缩的情况下 , 相同的传输用时 , 仅需 50Mb/ 秒的带宽。因为网络传输带宽降低,CPU使用率由于网络处理也会降低,这是因为压缩的CPU使用率有所增加所致。在处理 Oracle 数据库时, CPU 成本只需原来的 14% ,而所需带宽则减少超过了 70% 。
  • 缩短传输时间。 如果传输可以使用所有可用带宽且采用 SnapMirror 压缩 , CPU 成本将会更高。例如 , 与上述相同 , 一个进行 2 : 1 压缩的数据集 , 在不压缩的情况下 , 采用 100Mb/ 秒的带宽 , 不压缩传输将花费 1 小时 , 而采用网络压缩 , 时间可以缩短至 30 分钟。任务使用全部带宽所以更快完成,网络处理成本就会更高,压缩处理也要占据一半的用时。如果CPU利用率太高,您可以使用 SnapMirror 扼制(每次传输时使用或全部使用)来调整吞吐量,以使 CPU 使用率不会太高。下图说明了压缩对于三种数据集的总传输时间的影响。

Reduction in transfer time for different data sets.’ current Windows environment.

2 面向不同数据集的传输用时节省。 CPU 成本减少从 38% ( Exchange )到 55% ( Oracle )。总数据传输量在所有测试中是相同的。 Storage 系统为一台 FAS3070 ,使用单一 155Mb/ 秒网络连接。

  • 另一个影响 CPU 成本的因素是数据集的压缩比。如果一个数据集可以实现高压缩比,与低压缩比的数据相比,其网络压缩并传输所带来的影响较小。反之,如果您不限制传输带宽,一个高压缩比数据集可能在完成大量压缩任务时占据全部带宽,使CPU使用率增加。例如,以 100Mb/ 秒的带宽传输压缩比为 3.5:1 的 Oracle 数据,您的存储系统必须以 350Mb/ 秒的速率来压缩数据,而传输压缩比为 1.5:1 的 Exchange 数据,您只需 150Mb/ 秒的压缩 / 解压速率。

结论

在网络带宽有限的情况下 , SnapMirror 网络压缩将带来巨大优势 , 带宽在过去可能是一个限制因素 , 但是现在却无需考虑这一点就可完成复制。如果您已经是一位 SnapMirror 用户,你只需升级至 Data ONTAP 7.3.2 (或更高版本)就可充分利用网络压缩带来的优势。

利用 SnapMirror 网络压缩 , 数据传输时间、网络带宽压缩与 CPU 成本之前相互关联。如下图3所示,减少传输时间必然会消耗更多的网络带宽与系统CPU资源。

Relationship between transfer time, bandwidth utilization, and storage system CPU overhead.’ current Windows environment.

3 传输时间、带宽使用率与存储系统 CPU 成本之间的关系。

为了您的环境获得更多优势 , 请注意本文中列出的指导方针。在大规模实施网络压缩之前,您需要规划少量实验性传输来评估您的数据集的可压缩性,以及对源系统与目标系统所造成的CPU成本。

 想要获得有关SnapMirror网络压缩的建议?

您可以在 NetApp 网上社区上提问、交流想法及分享心得。

Srinath Alapati

Srinath Alapati
NetApp
技术营销工程师

Srinath于2004年加入NetApp,成为数据保护团队的成员已有超过2年的时间。他在IT、管理服务器与存储基础设施方面拥有超过10年的经验。Srinath已经撰写或与别人合著了多份关于SnapMirror、MetroCluster、VMware®与Exchange的技术报告,并在各类技术大会上发言。他还是NetApp IT的灾难恢复实施部门的核心团队成员。

Explore