为什么在 Data ONTAP 7- 模式下报告的 LUN 延迟高于卷延迟?
适用场景
- Data ONTAP 7-模式
- 逻辑单元(LUN)
- ISCSI
- FCP
- R2T (准备传输)
- XFER_RDY (传输就绪)
问题解答
- 通常会发现、为iSCSI (和FCP)测量的延迟远远高于底层卷、而在卷级别测量的操作计数则高于在所含LUN上测量的延迟。
- 这是因为卷延迟(WAFL延迟)只是LUN延迟的一部分、因此与LUN延迟相比、卷延迟更低是预期行为。
- 本文重点介绍LUN延迟明显高于卷延迟的情形。
- 造成这种显著延迟差异的主要原因是、在WAFL/Volume层、操作大小限制为64 KB。如果客户端必须发送有效负载大于64 KB的操作、则必须将此有效负载细分为多个卷操作。由于此WAFL端限制、每个iSCSI会话或FCP登录都将协商设置、指定一个PDU (协议数据单元)中可发送的数据量。因此、卷延迟仅表示处理一个64 KB PDU所需的时间、但LUN延迟可能用于测量多个64 KB PDU的总处理时间。
- LUN延迟(iSCSI延迟或FCP延迟)是从完全收到命令的第一个PDU开始计算的、直至将响应的最后一个PDU发送到ONTAP的输出队列为止。
- 在7-模式ONTAP中、这种方法以严格的 串行方式工作。
操作大小为256 KB的iSCSI写入示例:
- 客户端发出第一个64 KB PDU
- ONTAP接收PDU、然后在处理第一个64 KB写入后、将R2T发 送回客户端
- 客户端收到R2T、然后发送第二个64 KB PDU
- ONTAP接收PDU、然后在处理第二次64 KB写入后、将另一个R2T发送回客户端
- 客户端收到R2T、然后发出第三个64 KB PDU
- ONTAP接收PDU、然后在处理第三次64 KB写入后、将另一个R2T发送回客户端
- 客户端收到R2T、然后发出第四个64 KB PDU
- ONTAP接收PDU、然后在处理第四次64 KB写入后、将iSCSI写入响应发送到客户端、此时ONTAP结束了对LUN延迟的测量
卷延迟仅适用于一个64 KB PDU处理、例如步骤 2 、4、 6 和 8所花费的时间
每次处理64 KB PDU之间花费的时间是网络往返时间、其中还包括客户端处理时间、客户端发送下一个64 KB PDU所用的时间、 例如 2 到 4、 4到 6以及6到 8之间的时间
LUN延迟适用于整个256 KB iSCSI写入处理、包括4个64 KB PDU处理(卷延迟)加上3个网络往返时间(RTT)
FCP与iSCSI R2T有一个类似的术语、称为XFER_RDY
在7-模式ONTAP中、
如果LUN延迟明显高于卷延迟* ROunup (OperationSize / 64KB)、
则表示R2T (或FCP的Xfer_RDY)需要很长时间才能到达客户端、或者客户端需要很长时间才能发送下一个PDU。
这表示客户端与存储之间的数据路径较慢。
这可能是:- 拥塞
- 低带宽
- 数据包丢失
- 等等
示例:
- 对读取容量为256 KB的客户端的卷层和LUN层的操作和延迟进行比较
- 以iSCSI协议为例、但也使用相同的适用场景FCP
要区分这两种情形:
- 卷延迟
System1> stats show volume:myvol volume:myvol:total_ops:132/s volume:myvol:avg_latency:5ms volume:myvol:read_ops:5/s volume:myvol:read_data:1923b/s volume:myvol:read_latency:3ms volume:myvol:write_ops:186/s volume:myvol:write_data:1876b/s volume:myvol:write_latency:6ms volume:myvol:other_ops:0/s volume:myvol:other_latency:0ms
- LUN延迟
system1>lun stats -o -i 1 Read Write Other QFull Read Write Average Queue Partner Lun Ops Ops Ops kB kB Latency Length Ops kB 0 351 0 0 0 44992 11.35 3.00 0 0 /vol/tpcc/myvol 0 233 0 0 0 29888 14.85 2.05 0 0 /vol/tpcc/myvol 0 411 0 0 0 52672 8.93 2.08 0 0 /vol/tpcc/myvol