摘要

  • RFC 7147 将 iSCSI 协议级别放进单条会话的属性表，保留了发起端与目标端协商的真实作用范围。
  • 级别 2 证明的是会话协议状态，不是某条 SCSI 任务完成、数据持久化或应用接受结果的凭据。

设备不会和自己协商

管理面板往往想给整台设备贴一个结论：兼容、当前、受支持。但 iSCSI 设备不是只有一段对话。它可以包含多个实例、节点、端口、会话和 TCP 连接。每条会话都连接一个发起端和一个目标端。协议键是在这一对端点之间协商的，另一条会话可能面对不同的对端，也可能产生不同的状态。

RFC 7147 的意义就在于把这种范围写进管理模型。它发表于 2014 年 4 月，取代 RFC 4544，并按 RFC 7143、RFC 7144 更新 iSCSI 管理信息库。新增的两个只读属性位于会话属性表：iscsiSsnProtocolLevel 和 iscsiSsnTaskReporting。前者记录“为本会话协商的 iSCSI 协议级别”；后者记录与 SCSI 目标协商的任务完成报告语义。

把数值挂在会话行上，不只是数据表设计。若把它汇总成设备级徽标，一个发起端的协商就会被误读为所有连接的共同能力。RFC 7147 沿着协议自己的边界组织数据：协议级别属于具体会话，管理视图也应保留这个归属。

协商创造条件，不替代执行证据

RFC 7144 规定，使用该文档描述的功能必须协商 iSCSIProtocolLevel 的值“2”。但它同时明确指出，这一协商是使用相应 SCSI 能力的必要条件，并非充分条件。实现仍可能拒绝某一项任务管理功能。发起端必须处理目标返回的 SCSI 响应；查询 MIB 不能代替那条响应。

所以，面板上的“级别 2”不能简化为“所有功能可用”。它说明的是更窄也更可靠的一件事：这条会话的两端同意采用相应协议级别。之后还要看具体实现是否支持所需功能、请求是否真正发出、目标如何响应，以及主机或应用怎样解释结果。协议状态和业务结果之间仍有多道边界。

另一个新属性 TaskReporting 也体现了同样的边界。它用位集合表示任务完成报告的协商语义，包括 RFC 3720 的基线行为，以及 ResponseFence、FastAbort 等选择。它描述目标怎样报告任务完成，不证明某条任务已经执行、数据已经落盘，或应用已接纳结果。

管理树保留了不同层次

MIB 从 iSCSI 实例开始，下面才是节点、端口、会话和连接。每个非标量对象先按实例索引。实例可以表示设备的物理或虚拟分区。RFC 7147 特别说明，实例并不取代 SNMP 上下文；它只是让分区映射到一个或多个上下文时，不必逐条重复配置节点、端口和会话记录。

这棵树让几类问题各自有位置：会话表观察 iSCSI 协商状态，TCP MIB 说明传输连接，SCSI MIB 可以承载 SCSI 层属性，主机和应用则有自己的成功标准。管理工具可以把这些视图串起来，但一个字段不会把它们变成同一份证明。

“运行代码优先”在这里是一条朴素的工程原则：规范之所以重要，是因为发起端和目标端实现它、完成协商并交换命令；MIB 之所以重要，是因为操作人员能观察运行系统中的规定状态。不过，观测仍然只属于某个层次和某个时间点。要判断操作是否成功，证据必须继续走到 SCSI 响应和真正使用结果的消费者。

这项数字能回答什么

按会话记录级别，有助于解释为什么通向同一存储系统的两条路径表现不同。它可以支持兼容性排查、变更审查和故障定位，也能发现真实协商与配置预期不一致。正因为它范围精确，才不该被折叠成整台设备的一张标签。

RFC 7147 定义了管理对象，却没有告诉我们有多少厂商实现它们、运维人员多久采集一次，或客户怎样使用这些数据。一次读取还需要连同会话身份和采样时间保存；如果会话已经重建，旧样本不能证明当前路径的状态。要证明一条存储命令成功，仍须关联 SCSI 响应、主机记录和应用结果。

结论并不复杂：协议级别属于产生它的那条会话。RFC 7147 为这个约定安排了独立记录；至于某次操作究竟发生了什么，要由下一层证据回答。

来源