![iSCSI 到 NetApp FAS:写入负载延迟较高](https://linux22.com/image/664387/iSCSI%20%E5%88%B0%20NetApp%20FAS%EF%BC%9A%E5%86%99%E5%85%A5%E8%B4%9F%E8%BD%BD%E5%BB%B6%E8%BF%9F%E8%BE%83%E9%AB%98.png)
问题
Linux iSCSI 启动器在写入 NetApp FAS 目标并公开一堆 LUN 时,服务时间过长。在哪里查找原因以及如何解决此问题?
再生产
我正在使用sysstat 包中的iostats
数据sa
来计算“await”——特定请求的平均等待时间:
dd if=/dev/urandom of=test bs=8K count=1000000 & iostat -xdm 5 sdy dm-26
[...]
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sdy 0.00 1115.60 0.10 47.50 0.00 7.94 341.68 1.63 34.05 2.00 9.52
dm-26 0.00 0.00 0.10 2032.90 0.00 7.94 8.00 328.10 161.39 0.05 9.52
在这种情况下,“await”的预期值将比 测量的值低一个数量级iostats
。上述样本时间段内传输的 10 秒网络流量为可在 CloudShark 上使用.dm-26
是承载文件系统(单磁盘 NSS 卷)的设备映射器设备,指的是sdy
“物理”设备。
环境
发起方和目标位于同一子网中。发起方主机的 IP 为 192.168.20.72,目标是 192.168.20.33,流量交换为 1GbE,启用了巨型帧(并通过网络跟踪确认正在使用),启用了 iSCSI 即时数据(并且根据所述跟踪正在使用),未启用摘要。
iSCSI 会话信息:
iscsiadm -m session -P 3
iSCSI Transport Class version 2.0-870
version 2.0-873.suse
Target: iqn.1992-08.com.netapp:sn.151745715
Current Portal: 192.168.20.33:3260,2003
Persistent Portal: 192.168.20.33:3260,2003
**********
Interface:
**********
Iface Name: default
Iface Transport: tcp
Iface Initiatorname: iqn.2015-06.de.example.dom:01:gw-cl-07
Iface IPaddress: 192.168.20.72
Iface HWaddress: <empty>
Iface Netdev: <empty>
SID: 1
iSCSI Connection State: LOGGED IN
iSCSI Session State: LOGGED_IN
Internal iscsid Session State: NO CHANGE
*********
Timeouts:
*********
Recovery Timeout: 120
Target Reset Timeout: 30
LUN Reset Timeout: 30
Abort Timeout: 15
*****
CHAP:
*****
username: <empty>
password: ********
username_in: <empty>
password_in: ********
************************
Negotiated iSCSI params:
************************
HeaderDigest: None
DataDigest: None
MaxRecvDataSegmentLength: 262144
MaxXmitDataSegmentLength: 65536
FirstBurstLength: 65536
MaxBurstLength: 65536
ImmediateData: Yes
InitialR2T: No
MaxOutstandingR2T: 1
************************
Attached SCSI devices:
************************
Host Number: 3 State: running
scsi3 Channel 00 Id 0 Lun: 0
Attached scsi disk sdb State: running
scsi3 Channel 00 Id 0 Lun: 1
Attached scsi disk sdc State: running
scsi3 Channel 00 Id 0 Lun: 10
Attached scsi disk sdl State: running
scsi3 Channel 00 Id 0 Lun: 11
Attached scsi disk sdm State: running
scsi3 Channel 00 Id 0 Lun: 12
Attached scsi disk sdn State: running
scsi3 Channel 00 Id 0 Lun: 13
Attached scsi disk sdo State: running
scsi3 Channel 00 Id 0 Lun: 14
Attached scsi disk sdp State: running
scsi3 Channel 00 Id 0 Lun: 15
Attached scsi disk sdq State: running
scsi3 Channel 00 Id 0 Lun: 16
Attached scsi disk sdr State: running
scsi3 Channel 00 Id 0 Lun: 17
Attached scsi disk sds State: running
scsi3 Channel 00 Id 0 Lun: 18
Attached scsi disk sdt State: running
scsi3 Channel 00 Id 0 Lun: 19
Attached scsi disk sdu State: running
scsi3 Channel 00 Id 0 Lun: 2
Attached scsi disk sdd State: running
scsi3 Channel 00 Id 0 Lun: 20
Attached scsi disk sdv State: running
scsi3 Channel 00 Id 0 Lun: 21
Attached scsi disk sdw State: running
scsi3 Channel 00 Id 0 Lun: 22
Attached scsi disk sdx State: running
scsi3 Channel 00 Id 0 Lun: 23
Attached scsi disk sdy State: running
scsi3 Channel 00 Id 0 Lun: 24
Attached scsi disk sdz State: running
scsi3 Channel 00 Id 0 Lun: 25
Attached scsi disk sdaa State: running
scsi3 Channel 00 Id 0 Lun: 26
Attached scsi disk sdab State: running
scsi3 Channel 00 Id 0 Lun: 27
Attached scsi disk sdac State: running
scsi3 Channel 00 Id 0 Lun: 28
Attached scsi disk sdad State: running
scsi3 Channel 00 Id 0 Lun: 3
Attached scsi disk sde State: running
scsi3 Channel 00 Id 0 Lun: 4
Attached scsi disk sdf State: running
scsi3 Channel 00 Id 0 Lun: 5
Attached scsi disk sdg State: running
scsi3 Channel 00 Id 0 Lun: 6
Attached scsi disk sdh State: running
scsi3 Channel 00 Id 0 Lun: 7
Attached scsi disk sdi State: running
scsi3 Channel 00 Id 0 Lun: 8
Attached scsi disk sdj State: running
scsi3 Channel 00 Id 0 Lun: 9
Attached scsi disk sdk State: running
其他观察
出于某种原因,dm
每当写入请求合并到请求队列中时,映射到“物理”LUN 的设备都会显示等待时间显著增加。但我的问题实际上是关于底层设备上的等待 - NetApp FAS 应该将所有写入请求放入其 NVRAM 并立即确认,即使是同步写入,因此我永远不会看到超过 5ms 的等待时间,只要网络链路没有饱和(事实并非如此)并且 NVRAM 没有背压(事实并非如此 - FAS 当前没有处理任何其他负载)。
对于读取操作,即使是随机读取,“等待”时间也相当短。以下是 10 秒 sysstat 数据的可视化,数据来自以下间隔:iozone
正在运行随机读/写测试(单线程自动的启用 O_DSYNC、8K 块大小的测试运行)显示效果:
图的前半部分是随机读取,运行速度约为 2-4 kIOPS,延迟约为 3ms。在后半部分,工作负载切换到随机写入,await 上升到 >10ms,IOPS 下降到 ~100(负载受延迟限制且为单线程,因此 IOPS 与延迟成反比)
由于某种原因,在分析上述网络流量捕获时,Wireshark 的 SCSI“服务响应时间”统计功能无法识别大多数调用,write
只发现 19 个请求并报告 3 毫秒的平均服务响应时间,而我预计大约有 500 个调用和类似于 34 毫秒等待的平均 SRT 值。
使用的 Linux 是 SuSE SLES 11 SP3,内核 3.0.101-0.47.55-default。
答案1
评论太长;
我不是 Linux 专家,但在 Windows 中我禁用TCP 大量发送卸载在 NIC 上,因为它会产生延迟。它发送的数据包较少,但较大,但对于关键 IO 不建议这样做。
官方解释;
TCP Large Send Offload 选项允许 AIX TCP 层构建长度最多为 64 KB 的 TCP 消息,并通过 IP 和以太网设备驱动程序在一次调用中将其发送到堆栈下方。然后,适配器将消息重新分段为多个 TCP 帧以进行传输。在线路上发送的 TCP 数据包要么是 1500 字节帧(最大传输单元 (MTU) 为 1500)或最多 9000 字节帧(MTU 为 9000)(巨型帧)。
答案2
我将根据进一步的信息编辑此答案。首先,我们需要确定 Netapp 是否也观察到了等待,还是只有主机观察到了等待。如果主机看到服务时间较长,但 NAS 声称服务时间较短,则可能是 NAS 端口和服务器的 SCSI 堆栈之间存在问题。
您运行的是哪个版本的 Data ONTAP?7 模式还是 CDOT?LUN OS 设置和 igroup OS 设置是什么?有了这些信息,我可以为您提供可在 Netapp 上使用的命令,以检查存储观察到的延迟。