跳转到主内容

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

Views:
82
Visibility:
Public
Votes:
0
Category:
fas-systems
Specialty:
Perf
Last Updated:

适用场景

  • ONTAP 9
  • R2T (准备传输)
  • XFER_RDY (传输就绪)

问题解答

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

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

示例:
  • 对读取容量为256 KB的客户端的卷层和LUN层的操作和延迟进行比较
  • 以iSCSI协议为例、但也使用相同的适用场景FCP
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需要很长时间才能到达
    • 这样、即使卷延迟较低、也会对性能产生发生原因影响

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

 

如何区分这两种情形?

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延迟

 

如何解决高LUN延迟问题?

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

 

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.