为什么在通过 FibreChannel ( SFFCs )目标访问的 SolidFire 卷上观察到高写入延迟?
不可不使用
适用场景
SolidFire 光纤通道
问题解答
问题是什么?
据观察, FC 启动器和 SolidFire FibreChannel 节点之间的 FibreChannel 交换机结构中的某些情况可能导致写入 I/O 延迟高于预期平均延迟。
谁是暴露者?
要使卷暴露于此问题中、必须满足以下所有条件:
- 必须通过 SolidFire FibreChannel 目标访问卷。iSCSI 目标不受此问题的影响。
- 集群必须运行以下某个 Element OS 版本:
- 钠 -11.1.
- 钠 -11.3
- 钠 -11.5
- 钠 -11.7
- 钠 -11.8
暴露在问题上并不能证明问题已发生。 曝光只是先决条件。
什么是症状?
暴露的卷可能会突然显著降低写入性能、并且平均写入延迟会突然增加。 写入延迟会持续增加、并且在采取缓解措施之前可能会逐渐恶化。
读取延迟不受影响。
如果发现此问题的症状,如何恢复写入性能?
为了从影响最小的到影响最强的缓解措施:
- 您可以在整个集群中一次连接到一个 FC 节点的“信舌”(链路断开 / 链路连接)交换机端口以缓解此问题。
示例:在双节点集群中、需要关闭连接到 FC 节点的总共 8 个 FC 交换机端口并再次进行备份。 您可以通过以下方法执行此操作:关闭交换机端口、等待几秒钟、然后一次将其恢复联机一个、直到重置所有 8 个端口。 您也可以将拉线 / 重新插入 FC 节点,但实际上执行起来通常会比较困难。 - NetApp 支持工程师可以将客户支持隧道与内部缓解脚本结合使用来重置节点的 FC 链路。 通过这种方式缓解问题还可以为 NetApp 支持工程师提供附加日志记录、用于积极确认延迟问题的根本原因实际上是此 KB 中讨论的问题。
- 同时重新引导一个 FC 节点也可以缓解此问题。 如果选择了此选项、则必须特别注意确保任何重新引导的节点完全联机并再次运行、并且主机多路径驱动程序已在任何后续节点重新引导之前重新建立通过重新引导节点的路径连接。
注:务必了解,在为集群解决问题后、并不意味着已消除了该问题的严重性。 症状可能会再次出现,并且在集群升级到不受此问题影响的 Element 软件版本之前,还需要附加缓解措施。
问题的根本原因是什么?
已确定 SF FC 实施所基于的 4.14 Linux 内核附带的 qla2xxx 目标驱动程序 v10.00.01-k 中的缺陷会导致在某些情况下不正确地完成 SCSI 任务中止命令。 这些格式错误的完成导致在 QLogic QLE2672 FibreChannel 适配器上运行的固件中出现资源泄漏。 随着时间的推移、 FibreChannel 适配器运行所需的资源变得稀少或耗尽、从而导致资源分配效率低下或无法为 SCSI 写入命令提供服务。 这些效率低下会导致某些写入命令的延迟很高、并对平均写入性能产生重大影响。
如果不升级到已修补的元素发行版,是否可以避免此问题?
从镁 -12.0 开始的元件版本中已消除了此缺陷。
如果不升级到包含不正确的中止完成错误修补程序的元素发行版、就无法保证此问题的重复发生。 但是,可以采取一些合理的措施来减少启动程序的中止活动、从而延迟由于资源泄露而引发此问题的时间。
确保最小 SCSI 任务中止的方法:
- 始终确保遵循 NetApp 支持建议的所有最佳实践
- 确保禁用 ESX/VMware “ smartd 轮询”。
- 确保在整个 FibreChannel Fabric 中不会出现递增信号或协议错误。 应通过更换 SFP 和 / 或电缆或部署其他缓解措施来诊断和纠正任何显示故障症状的交换机端口、以纠正不断增加的错误情况。
- 对于 Cisco 交换机,应考虑使用 "show interface" 和 "show hardware internal FC-mac" 中的计数器。 Cisco 在此处记录了这些计数器:解决 SAN 交换问题。
- 有关 Brocade 交换机的信息、请参见 Brocade SAN 交换机 PortTerrShow 计数器解释。
追加信息
在此处添加您的文本。