跳转到主内容

为什么报告的 LUN 延迟高于卷延迟?

Views:
5
Visibility:
Public
Votes:
0
Category:
fas-systems
Specialty:
perf
Last Updated:

适用于

  • ONTAP 9
  • 集群模式 ONTAP 8.x
  • R2T (准备传输)
  • Xfer_RDY (传输就绪)

解答

通常会发现,为 iSCSI (和 FCP )测量的延迟远远高于底层卷的延迟,卷级别的操作计数高于为所含 LUN 测量的操作计数。

注意:卷延迟( WAFL 延迟)只是 LUN 延迟的一部分,因此,与 LUN 延迟相比,卷延迟较低是预期行为,本文重点介绍 LUN 延迟明显高于卷延迟的情形

示例:

  • 对卷中的操作和延迟进行了比较 具有 256 KB 读取的客户端的层和 LUN 层
  • iSCSI 协议作为示例,但 FCP 也是如此

卷延迟

cluster1::*> statistics show -object lun -instance /vol/vol_linux/lun1 -counter read_data|avg_read_latency|read_ops -raw
Object: lun
Instance: /vol/vol_linux/lun1
Start-time: 10/26/2020 00:55:36
End-time: 10/26/2020 00:55:36
Scope: svm_linux
Number of Constituents: 2 (complete_aggregation)
   Counter                            Value
   -------------------------------- --------------------------------
   avg_read_latency                       215ms
   read_data                           85.25MB
   read_ops                           333
3 entries were displayed.

LUN 延迟

cluster1::*> statistics show -object volume -instance vol_linux -counter iscsi_read_data|iscsi_read_latency|iscsi_read_ops -raw

Object: volume
Instance: vol_linux
Start-time: 10/26/2020 01:00:10
End-time: 10/26/2020 01:00:10
Scope: svm_linux

   Counter                            Value
   -------------------------------- --------------------------------
   iscsi_read_data                        85.25MB
   iscsi_read_latency                       50034us
   iscsi_read_ops                        1332

注意: 卷操作是 LUN 操作的 4 倍,因为 LUN 操作大小为 256 KB ,而卷操作大小仅为 64 KB

 

造成这种显著延迟差异的主要原因是,在 WAFL/ 卷层,操作大小限制为 64 KB 。如果客户端必须发送有效负载大于 64 KB 的操作,则必须将有效负载细分为多个卷操作。由于此 WAFL 端限制,每个 iSCSI 会话或 FCP 登录都将协商设置,并指定可在一个 PDU (协议数据单元)中发送的数据量。因此,卷延迟仅表示处理一个 64 KB PDU 所需的时间,但 LUN 延迟可能是测量多个 64 KB PDU 的总处理时间。

LUN 延迟( iSCSI 延迟或 FCP 延迟)是指从完全收到命令的第一个 PDU 到将响应的最后一个 PDU 发送到 ONTAP 的输出队列的时间。 

7- 模式 ONTAP

  • 在 7- 模式 ONTAP 中,此操作采用严格序列化的方式,例如,操作大小为 256 KB 的 iSCSI 写入
    • 此工作流如下所示:

      1. 客户端发送第一个 64 KB PDU
      2. ONTAP 会接收 PDU ,然后在处理完第一个 64 KB 写入后,它会向客户端发送一个 R2T
      3. 客户端接收 R2T ,然后发送 第二个 64 KB PDU
      4. ONTAP 会收到 PDU ,然后在处理第二个 64 KB 写入后,再向客户端发送另一个 R2T
      5. 客户端接收 R2T ,然后发送 第三个 64 KB PDU
      6. ONTAP 会收到 PDU ,然后在处理完第三个 64 KB 写入后,再向客户端发送另一个 R2T
      7. 客户端接收 R2T ,然后发送 第四个 64 KB PDU
      8. ONTAP 会收到 PDU ,然后在处理第四个 64 KB 写入后,它会向客户端发送 iSCSI 写入响应,即 ONTAP 结束 LUN 延迟的测量 
    • 卷延迟仅适用于单个 64 KB PDU 处理,例如步骤 2468 中花费的时间

    • 每个 64 KB PDU 处理之间花费的时间是网络往返时间,其中还包括客户端处理时间,客户端发送下一个 64 KB PDU 所需的时间,例如 24 之间46之间以及 68 之间的时间

    • LUN 延迟适用于整个 256 KB iSCSI 写入处理,包括 4 个 64 KB PDU 处理(卷延迟)加上 3 个网络往返

    • FCP 与 iSCSI R2T 有类似的术语,称为 Xfer_RDY

    • 在 7- 模式 ONTAP 中,如果 LUN 延迟明显高于卷延迟 * ROUNUP (操作大小 /64KB ),则表示 R2T (或 FCP 的 XFER_RDY )需要很长时间才能访问客户端,或者客户端需要很长时间才能发送下一个 PDU 。它表示客户端与存储之间的数据路径速度较慢。示例:

      • 拥塞
      • 低带宽
      • 数据包丢失
      • 等)。

集群模式 Data ONTAP

  • 集群模式 Data ONTAP 可通过这种序列化方式进行优化 读取和写入的处理

    • 最多可以同时处理 16 个并行 64 KB PDU ,这意味着在大多数情况下, LUN 延迟不应受网络往返影响

    • 它可以并行运行,但并不一定意味着所有 PDU 始终并行运行,对于相同的 256 KB iSCSI 写入示例:

      • LUN 延迟的最小值等于 64 KB PDU 处理时间(卷延迟)

      • LUN 延迟的最大值等于 4 * 64 KB PDU 处理时间(卷延迟) + 3 次网络往返的总和

      • LUN 延迟介于 最小 值和 最大值之间

    • 对于某些旧版本的集群模式 Data ONTAP ,无法并行运行 SAN 写入

 

考虑到所有这些因素,对于集群模式 Data ONTAP , LUN 延迟明显高于 LUN 延迟的主要情形有两种

  • PDU 不会并行运行
    • 只要不影响性能,就不会造成任何影响 卷延迟较低
  • 网络或客户端速度较慢,因此需要执行此操作 要确认和 R2T/Xfer_RDY ,需要很长时间 下一个 PDU 才会收到
    • 即使卷如此,也会对性能造成影响 延迟较低

注意: 在这两种情况下,只要卷延迟仍然较低,就不应将其视为存储性能问题

 

如何区分这两种情形?

qos statistics workload/volume latency show 可用于区分这两种情形:

示例:

cluster1::*> qos statistics workload latency show -workload vol_linux-wid22068

Workload            ID    Latency   Network    Cluster       Data       Disk        QoS    NVRAM      Cloud 

---------------   ------ ---------- ---------- ----------    ---------- ---------- ---------- ---------- ----------

Vol_linux-wid22068   -     210ms    8ms     1ms      181ms    18ms     0ms    2ms        0ms    

  • PDU 不会并行运行
    • 未发出明显延迟 Network
  • 网络或客户端速度较慢,因此需要执行此操作 要确认和 R2T/Xfer_RDY ,需要很长时间 下一个 PDU 才会收到
    • 大多数高延迟来自 Network

注:

  • 在 QoS 延迟细分中 Network ,表示外部组件(如网络或客户端)引入的延迟
  • 只要中的延迟不高 Network,即使 LUN 延迟明显高于底层卷延迟,也无需担心 LUN 延迟

其他信息

附加信息 _text