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

LUN延迟

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 Counter Value -------------------------------- -------------------------------- avg_read_latency 215ms read_data 85.25MB read_ops 333

卷延迟

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/Volume层、操作大小限制为64 KB。
• 如果客户端必须发送有效负载大于64 KB的操作、则必须将此有效负载细分为多个卷操作。
• 由于此WAFL大小限制、每个iSCSI会话或FCP登录都会协商设置、指定一个PDU (协议数据单元)中可发送的数据量。
• 因此、卷延迟仅表示处理一个64 KB PDU所需的时间、但LUN延迟可能用于测量多个64 KB PDU的总处理时间。
• LUN延迟(iSCSI延迟或FCP延迟)是从完全收到命令的第一个PDU开始计算的、直至将响应的最后一个PDU发送到ONTAP的输出队列为止。 

ONTAP 9

• ONTAP 9对这种读取和写入的序列化处理方式进行了优化

  • 最多可以同时处理16个64 KB并行PDU、这意味着在大多数情况下、LUN延迟不应受网络往返影响
    • 它可以并行运行、但并不一定意味着所有PDU都会始终并行运行、对于相同的256 KB iSCSI写入示例：
      • 最小 LUN延迟等于64 KB PDU处理时间(卷延迟)
      • 最大 LUN延迟等于 4 * 64 KB PDU处理时间(卷延迟)+ 3个网络往返的总和
      • LUN延迟介于 最小值 和 最大值之间
    • 对于某些旧版本的ONTAP 9、SAN写入无法并行运行

考虑到所有这些因素、对于ONTAP 9、在两种主要情形下、LUN延迟明显高于LUN延迟

• PDU未并行运行
  • 只要卷延迟较低、此操作就不会对性能产生任何发生原因影响
• 网络或客户端速度较慢、因此确认R2T/XFER_RDY以及下一个PDU需要很长时间才能到达
  • 这样、即使卷延迟较低、也会对性能产生发生原因影响

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

如何解决高LUN延迟问题？

请参阅文章 How to address network延迟in a SAN Environment - Resolution Guide (如何解决SAN环境中的网络延迟问题-解决指南)。