跳转到主内容

常见问题解答: ADR FS/ADR 引擎 / BRE 性能问题

Views:
23
Visibility:
Public
Votes:
0
Category:
data-ontap-8
Specialty:
dp
Last Updated:

可不使用  

适用于

块复制引擎( BRE )

解答

三级块复制引擎性能问题: :

SnapMirror 和卷移动等 Data ONTAP 产品使用块复制引擎 (BRE ) 将数据从源传输到目标。有时,产品可能无法按预期方式运行。这可能是由于各种原因造成的,例如配置问题、客户端问题或包括传输引擎在内的某个软件模块中的错误。本文探讨了可能会导致性能低下的一些因素、并探讨了对其进行分类的工具。虽然本文重点介绍 BRE ,但这里提到的许多因素也适用于 LRSE 。

可能影响 BRE 性能的因素

以下是可能影响转印引擎性能的许多因素:

  • 系统上的预存在负载
  • 系统上的客户端负载
  • 同时尝试传输 / 卷移动的数量
  • 传输类型—初始化或更新。这将分别对应于卷移动的基准或更新阶段。
  • 系统配置、包括存储系统类型、磁盘类型、聚合中的磁盘数量或聚合中的卷数量

请记住,这些因素可能适用于 SnapMirror 关系的源以及目标或卷移动。

此外,用户还可以询问网络带宽不饱和的原因。这是因为传输引擎不受网络带宽瓶颈的影响。瓶颈通常位于源存储系统或目标存储系统上。(如果网络出现瓶颈并已饱和、用户可以对关系启用网络压缩。

下面将详细讨论上述因素:

系统上的预存在负载:

块复制引擎从源聚合读取数据块、通过网络将数据块发送到目标聚合、然后将其写入目标聚合。这需要备用 CPU 周期才能取得合理的进展。由于 SnapMirror 还使用相同的传输引擎、因此可以使用运行 SnapMirror 性能的数据来查找 CPU 利用率。例如,在 FAS6280 上、单个传输会占用源和目标上可用 CPU 的 25% 、八个同步传输会占用源上 50% 的 CPU 、目标上 55% 的 CPU 。因此,系统上的预先存在负载可能会对 BRE 客户端的进度产生重大影响,例如卷移动和 SnapMirror 。建议在执行 SnapMirror 传输或执行卷移动之前,控制器 CPU 的利用率保持在 50% 以下。TR-4075 是 DataMotion 的卷移动最佳实践指南,适用于卷最佳实践和优化

Data ONTAP 内部负载:

Data ONTAP 内部流量与客户端流量无关、也会导致 TE 性能下降。

以下是其中的一些示例:

  • 扫描仪通信量:内部扫描仪通信量可以生成系统负载并导致 CPU 负载增加,从而减少传输引擎可用的 CPU 数量。它还可能导致传输引擎的节流机制启动、进一步降低性能。
  • System Kahuna 用法:如果存储系统在 Kahuna 花费大量时间,则其他系统进程将无法运行。因此,即使整体 CPU 利用率较低但 KaHuna 使用率较高、但 TE 工作负载可能无法获得足够的 CPU 周期来运行。这将降低该系统上可以实现的 TE 吞吐量。

客户端负载:

SnapMirror 和卷移动被视为后台作业。在客户端工作负载的情况下,底层传输引擎会回滚。传输引擎维护一个节点范围内的读取和写入令牌池。这些令牌限制了传输引擎(跨所有传输)可以同时发送到 WAFL 的消息数。系统会跟踪发送到 WAFL 的操作数以及 WAFL 处理消息之前的平均等待时间(这适用于发送到 AFL 的所有操作、不包括由 TEE 本身发送的操作)。如果这两个值跨越预定义的阈值、传输引擎将减少可用令牌的数量、从而有效地降低客户端可用的吞吐量( SnapMirror 和卷移动)。例如,在 FAS6280 上的集群模式 Data ONTAP 8.2 中、八个同步传输可以在卸载系统上实现总吞吐量为 1134 MB/ 秒。当源节点上有 60 万个客户端 IOPS 时、 IOPS 最高可达 75 K 时、 IOPS 可达 289 MB/ 秒、 IOPS 最高可达 120 K 时、可达 206 MB/ 秒这些 IOPS 级别分别对应于无任何 SnapMirror 流量的 CPU 利用率为 66.5% 、 75.8% 和 86.5% 、 SnapMirror 流量分别为 75.6% 、 81.3 %和 86.5 %。因此,系统上的客户端负载可能会对 SnapMirror 和卷移动所实现的吞吐量产生重大影响。

此限制机制的一个副作用是即使存在内部非复制 WAFL 流量,传输引擎也会关闭。当节点上有大量扫描仪活动时尤其如此。这会导致 SnapMirror 和卷的吞吐量降低。

注意: BRE 限制仅在 CPU 层测量,而不是在磁盘层测量。如果源聚合或目标聚合处于繁忙状态,则会导致性能下降。建议在非高峰利用率时间进行传输,否则可能会出现不适当的客户端延迟。

同时传输的数量:

所实现的聚合吞吐量取决于同步传输的数量。对于传输引擎、在 Data ONTAP 8.2 中、 FAS6280 (大文件)上进行一次传输的吞吐量为 546 MB/ 秒。对于八个同步传输,此峰值约为 926MB/ 秒。相反,如果同时启动八个 SnapMirror 传输(或卷移动)、则每个传输将分别获得约 118 MB/ 秒的吞吐量。因此,即使聚合吞吐量可能很高、同时启动大量传输也会导致各个传输的吞吐量低于一次仅执行一次传输。

SnapMirror 是传输引擎的另一个客户端、就像卷移动一样。在同一节点上运行卷与 SnapMirror 一起移动可能会降低单个传输的速度,如果卷移动和 SnapMirror 在同一聚合上使用卷,则会产生更明显的影响。降级情况将与上述情况类似。

阶段 / 传输类型:

SnapMirror 有两个阶段:初始化和更新。类似地,卷移动会执行基线传输、然后执行多个更新传输。基线传输的传输速率通常比更新传输的传输速率高。例如,在 FAS6280 上、单个流基线传输可以实现 546 MB/ 秒的传输速率、而更新传输速率则可以达到 275 MB/ 秒的传输速率。因此,在完成基准传输后、卷移动吞吐量下降是正常的(并且预期的)。

系统配置

系统配置可能会对卷移动所实现的吞吐量产生重大影响。以下是需要考虑的一些因素:

  • 聚合中的磁盘数—如果聚合没有足够的磁盘、则对该聚合的读写访问将会减慢。(是否有一个文档用于提供聚合所需的磁盘数量?)
  • 同一聚合上的大量卷可能会降低对特定卷的访问速度。即使该特定卷未看到较高的更改率、但同一聚合中的其他卷也会发生这种情况。
  • 聚合中的坏磁盘或故障磁盘可能会降低对整个聚合的访问速度。
  • SATA 磁盘的响应时间超过 SAS 磁盘的响应时间。在某些情况下, SATA 磁盘响应时间可能是 SAS 磁盘响应时间的两倍。这可能会对卷移动的性能产生重大影响。
  • 节点上的客户端通信(即使未定向到有问题的卷)也可能导致传输引擎重新关闭。这是因为内部回退算法会监控节点级别的统计信息(因为节点上只有一个文件系统)、而不是卷或聚合级别的统计信息。
  • 陈旧或零碎的文件系统可以增加从文件系统读取或写入所需的时间。通过查看读链长度和写链长度,可以从 StaticT 中观察到这一点。碎片文件系统通常具有较小的读取和写入链长度。
  • WAN 与 LAN 。与通过 LAN 复制数据相比、通过 WAN 复制数据的吞吐量较低。其中一些原因可能是往返延迟时间较长、数据包丢失率较高以及 WAN 上可用带宽降低。例如,在 Data ONTAP 8.2 中、通过一个 OC-12 链路 (622 Mbps) 在 FAS6280 上运行 8 个并发 SnapMirror 初始化传输、并有 50 毫秒的往返延迟、实现了 73 Mbps 的聚合吞吐量。LAN 上的相应吞吐量为 926Mbps 。

在性能实验室中获得的结果是在“理想”条件下使用 SAS 磁盘获得的。此设置中没有磁盘瓶颈。除了专门测量客户端流量影响的测试外、在执行性能运行时节点上没有客户端流量。因此,特定设置的性能可能与实验中的吞吐量不匹配。

提高 BRE 性能:

以下一节将特别讨论如何提高 Bre 的性能:

  • 在客户端负载较低和内部扫描仪通信量较低的时间安排传输。这将防止激活 TE 的内部回退机制。但是,必须牢记所需的 RPO 。
  • 正确调整系统大小。应该有足够的 CPU 预留空间来执行 CPU 工作负载(理想情况下为 50% 的 CPU 保留空间)。此外,请记住平台可以支持的最大吞吐量。更改速率和可用于复制的可用时间应少于此时间。如有关系统配置的一节所述,必须正确配置系统以达到最大吞吐量。有关设置的详细信息,请参见适用于集群模式 Data ONTAP 8.2 的 SnapMirror 配置和最佳实践指南
  • 如果文件系统是旧的或分段的,请尝试对其进行碎片整理。

    注:这可能会导致扫描仪流量增加、并可能在扫描仪运行时实际降低 TE 吞吐量。

    如果扫描仪导致 KaHuna 使用率过高或导致 TE 退后、请降低扫描速度。
    注:此操作仅应在 NGS 监督下执行、并作为缓解特定问题的临时措施。
  • 暂时禁用 TE 的节流机制。请运行以下命令来执行此操作:
    注意:此操作只能在 NGS 监督下执行、并作为缓解特定问题的临时措施。

    在源节点和目标节点上、 运行以下命令:
    node run local -command 'priv set diag; setflag repl_throttle_enable 0; printflag repl_throttle_enable

    确保看到‘repl_throttle_enable = 0x0

    以重新启用节流:
    node run local -command 'priv set diag; setflag repl_throttle_enable 1; printflag repl_throttle_enable'
    确保看到‘repl_throttle_enable = 0x1
  • 提高传输引擎性能的另一种方法是限制客户端吞吐量。例如,如果客户端吞吐量导致复制过度关闭,则可以对关键复制工作负载执行此操作。限制客户端吞吐量的步骤在“集群模式 Data ONTAP 8.2 System Administration Guide for Cluster Administrators ”的“使用存储 QoS 管理系统性能”一节中列出

  • 如果复制流量正在 WAN 上传输、则可以为这些 SnapMirror 策略启用网络压缩。网络压缩有助于在网络成为瓶颈时获得更好的吞吐量。此功能预计可从 Data ONTAP 8.3 和更高版本中获得。

数据收集和调试:

要根本原因 VolMove 缓慢问题、请从系统获取 perfstat 数据。可以从以下格式的外部源运行 perfstat :

 perfstat8 --verbose --time 5 --nodes=<node names> 

这将收集统计信息并将其保存到本地文件中。运行perfstat --help该命令以获取其他详细信息。

perfstat 的 statt 部分包含有关以下内容的信息:

  • CPU 利用率和 KaHuna CPU 利用率。
  • 磁盘利用率、磁盘响应时间以及磁盘读取和写入链长度。

"PL Stopwatch Counters" 部分包含有关传输引擎性能的以下直方图:

  • writer_throttled:已对写入器进行节流的次数以及时间。
  • physdiff_throttled:发件人被限制的次数以及时间。这是转印引擎内部的 Z 轴回退。它不包括任何网络限制。
  • buffer_read_wait_token:发件人在向 WAFL 发送读取消息之前等待物理差异令牌的时间。
  • buffer_wafl_read_blocks:读取发件人上的一组块( 16 或 32 个、具体取决于平台)所需的时间。

请查看 repl_counters 统计信息命令以确定受限令牌的百分比。

perfstat 提供的数据和计数器可以指示系统是否按预期运行(尽管运行缓慢)、或者系统存在其他问题。

要随时获取某些相关计数器,请运行以下statistics show命令:

statistics show -object repl_stopwatches -instance *throttled -raw
statistics show -object repl_stopwatches -instance buffer_read_wait_tokens -raw
statistics show -object repl_stopwatches -instance writer_data_waiting -raw
statistics show -object repl_stopwatches -instance buffer_wafl_read_blocks -raw

这些计数器分别显示:如果系统被限制、源上读取令牌的直方图、目标上写入令牌的直方图以及源上容器文件读取延迟的直方图。