怎么配置不同nvme厂商的高温门限告警

交流互助区
1

问题描述

怎么配置不同nvme厂商的高温门限告警？目前代码好像不支持

尝试过的解决方案

image
image1120×834 57.8 KB

把这个挪到POLICY_144d.sr里面是否可行？

2

答案内容由AI生成，仅供参考：
:white_check_mark: 结论：是否可将配置挪到 POLICY_144d.sr？

:white_check_mark: 可以，但必须保留 ReplicaDrive 和 Component 的核心定义在 PROTOCOL 中，仅迁移 ThresholdSensor 和 Event 的门限值。

建议操作：

  1. 不要完全删除 PROTOCOL 中的 ThresholdSensor_NvMeTemp，仅保留结构框架。
  2. 在 POLICY_144d.sr 中覆盖具体门限值。
  3. 确保 ReplicaDrive 的 SerialNumber 仍指向 bmc.dev.NVMe.ProductInfo.SerialNumber，避免丢失序列号信息。
  4. 测试验证：
    • 不同厂商 NVMe 插入后是否加载正确门限。
    • Redfish 告警是否包含序列号。
    • Web UI 是否正常显示温度告警。
点击此处查看详细分析解答

如何配置不同 NVMe 厂商的高温门限告警

当前系统在 openUBMC 平台上对 NVMe 磁盘的温度告警门限管理存在一定的限制：默认的高温告警门限（如 UpperNoncritical、UpperCritical）被静态定义在 PROTOCOL_X.sr 文件中（例如 14140224_PROTOCOL_0.sr），无法根据 NVMe 磁盘的厂商动态定制。

用户提出的问题——“是否可以通过将告警配置从 PROTOCOL 文件移动到 POLICY 文件以实现分厂商配置高温门限”——是当前社区讨论和尝试解决的核心方案之一。

:magnifying_glass_tilted_left: 问题核心分析

当前限制：

  • 高温告警配置（如 ThresholdSensor_NvmeTemp、Event_NVMeTempHighMinor）位于：
    vpd/vendor/Huawei/TianChi/SEU/14140224_PROTOCOL_0.sr
  • 此文件为 通用协议配置文件，适用于所有 NVMe 设备，不区分厂商。
  • 不同 NVMe 厂商的磁盘（如 Samsung、Intel、Micron）具有不同的工作温度容限，统一的门限可能导致误报或漏报。

尝试方案：

将 ThresholdSensor_NvmeTemp 和相关告警事件（如 Event_NVMeTempHighMinor）从 PROTOCOL_X.sr 移动到厂商专用的 POLICY_XXXX.sr 文件中（如 14140224_POLICY_144d.sr）

:white_check_mark: 可行性分析：理论可行，但存在关键挑战

项目 可行性 说明
POLICY 支持厂商级配置 :white_check_mark: POLICY_*.sr 文件（如 14140224_POLICY_144d.sr）支持按 NVMe 厂商（Vendor ID）加载，已用于 调速策略（CoolingRequirement），具备分厂商加载能力。
ThresholdSensor 可定义在 POLICY 中 :white_check_mark: openUBMC 支持在 POLICY 中声明传感器和事件对象，技术上可以迁移。
与 Redfish 接口的兼容性 :warning: 存在风险 Component 对象（如 ReplicaDrive）被多个 Redfish 接口依赖。若在 PROTOCOL 和 POLICY 中重复定义或缺失，会导致 序列号无法显示（SerialNumber 为空） 或告警信息不完整。
Component 对象依赖问题 :cross_mark: 主要障碍 如[文档 chunk 1]所述：
Component 对象在北向接口中被大量使用，不适合在 PROTOCOL 和 POLICY 中分别配置，否则会引发配置冲突或统计错误。

:hammer_and_wrench: 实际案例参考

1. 已有尝试（来自文档 chunk 1）：

  • 社区已尝试将 ThresholdSensor_NvmeTemp 和告警事件从 PROTOCOL_X.sr 拆分到 POLICY 文件中。
  • 结果：
    • 成功实现了 按厂商加载不同温度门限。
    • 但，后续测试发现告警中 NVMe 盘的序列号（SerialNumber）丢失。
    • 原因是：ReplicaDrive 对象的 SerialNumber 字段在 POLICY 中未正确继承。


修改后告警（无序列号） vs 修改前（有序列号）

:white_check_mark: 推荐解决方案

方案一：分层配置 + 动态继承（推荐）

将 门限配置 拆分至 POLICY，但保留 Component 和 ReplicaDrive 的主定义在 PROTOCOL 中，通过 引用或继承机制 实现动态配置。

实施步骤：

  1. 保留在 PROTOCOL_X.sr 中定义：
    "ReplicaDrive": {
  "SerialNumber": "<=bmc.dev.NVMe.ProductInfo.SerialNumber>",
  "Model": "<=bmc.dev.NVMe.ProductInfo.Model>",
  ...
}
  2. 在 POLICY_144d.sr（厂商专属）中定义：
    "ThresholdSensor_NvmeTemp": {
  "UpperNoncritical": 88,    // Samsung 特定门限
  "UpperCritical": 90,
  "PositiveHysteresis": 2
}
  3. 在 PROTOCOL 中通过变量引用 POLICY 配置：
    "Event_NVMeTempHighMinor": {
  "Condition": "<=/ThresholdSensor_NvmeTemp.UpperNoncritical"
}

    系统会根据当前 NVMe 厂商自动加载对应的 POLICY，动态填充门限值。

方案二：引入 Sensor Policy Binding 机制（长期建议）

定义新的配置机制，例如：

"SensorPolicyBinding": {
  "VendorId": "144d",
  "SensorRef": "ThresholdSensor_NvmeTemp",
  "PolicyFile": "14140224_POLICY_144d.sr"
}

BMC 在初始化时根据 NVMe 的 ManufacturerId 动态绑定对应的传感器策略。

:counterclockwise_arrows_button: 当前 openUBMC 支持情况

功能 支持状态 说明
按厂商加载 POLICY :white_check_mark: 通过 14140224_POLICY_*.sr 实现
分厂商调速策略 :white_check_mark: 已支持，参考 CoolingRequirement
分厂商温度告警门限 :warning: 部分支持 可实现，但需解决 Component 继承问题
Redfish 告警中显示序列号 :cross_mark:（当前配置下） 若 Component 移出 PROTOCOL，则 SerialNumber 丢失

:white_check_mark: 结论：是否可将配置挪到 POLICY_144d.sr？

:white_check_mark: 可以，但必须保留 ReplicaDrive 和 Component 的核心定义在 PROTOCOL 中，仅迁移 ThresholdSensor 和 Event 的门限值。

建议操作：

  1. 不要完全删除 PROTOCOL 中的 ThresholdSensor_NvmeTemp，仅保留结构框架。
  2. 在 POLICY_144d.sr 中覆盖具体门限值。
  3. 确保 ReplicaDrive 的 SerialNumber 仍指向 bmc.dev.NVMe.ProductInfo.SerialNumber，避免丢失序列号信息。
  4. 测试验证：
    • 不同厂商 NVMe 插入后是否加载正确门限。
    • Redfish 告警是否包含序列号。
    • Web UI 是否正常显示温度告警。

:books: 参考资料

  • [文档 chunk 4]：14140224_PROTOCOL_X.sr 中告警配置示例
  • [文档 chunk 1]：POLICY 中 SerialNumber 为空的问题分析
  • [KG] bmc.dev.NVMe.ProductInfo：提供 SerialNumber、Manufacturer 等关键信息
  • mctpd 文档：支持 NVMe over MCTP，用于获取 SMART 和温度数据

:light_bulb: 提示：可通过 bmc.dev.NVMe.ProductInfo 接口读取 NVMe 的 ManufacturerId，作为 POLICY 加载的依据。

如需具体 .sr 文件修改示例，可提供目标 NVMe 厂商和期望门限，我可协助生成配置模板。

3
  1. 告警跟着NVME的配置走，配在同一个地方
  2. 拷贝的时候记得拷贝全，你这个应该是有soft文件的
4

1、把vpd\vendor\Huawei\TianChi\SEU\14140224_PROTOCOL_0.sr和vpd\vendor\Huawei\TianChi\SEU\14140224_PROTOCOL_0_soft.sr的ThresholdSensor_NvmeTemp拷贝到不同厂商的policy sr中，那会不会两者冲突？

2、如果把PROTOCOL中的ThresholdSensor_NvmeTemp删了会不会有其他影响？

3、这个华为有已经验证过的方案吗？

5

不同的文件中都配置不会有冲突，对象是带Position后缀的，保证不同sr的Position不同就不会有对象冲突，但可能会有重复：比如传感器对象的SensorName都一样，查询传感器会有多个重名传感器

若实际只是需要配置告警，并不需要配置传感器，那么Event对象中配置依赖ThresholdSensor的属性若能非常明确地确定告警的门限值和迟滞量，可以Event对象自己固定配置，则不需要ThresholdSensor，也能解决问题1中的重复传感器问题