存储与 RAID

概述 — 这个页面做什么

基础设施 ▸ 存储与 RAID（/infra/storage）是一个只读的可用性看板，把每台主机的存储健康状况汇聚到同一个屏幕上。它把两类遥测数据组装成卡片。

• RAID 控制器健康状况 — 来自遗留表 storage_status.json_data（Adaptec arcconf 采集的输出）：控制器状态（Optimal / Degraded / Failed）、温度、电池状态、逻辑卷（RAID 级别 · 状态 · 容量），以及物理磁盘图（每个插槽的状态 · 型号 · 序列号 · 容量）。
• 数据卷磁盘使用率 — 来自遗留表 server_status 中的 df-* 快照：数据卷的使用率 · 已用 · 可用，显示在卡片顶部。

其核心目的是磁盘故障的早期预警。当 RAID 阵列跌落为 Degraded，或某块物理磁盘变为 Failed／Missing 时，颜色（琥珀色／红色）会立刻让它显现出来，让您能够在第二块磁盘也损坏、整个阵列崩溃之前完成更换与重建。

本页面只覆盖实时状态（此刻的健康状况）。存储的资产台账（设备元数据、容量规划、文件区域树）归 资产 ▸ 存储与文件 所有。二者是有意分开的（参见数据来源）。

何时使用

• 例行巡检时，一眼看清每个节点的 RAID 状态。
• 服务器迟缓或收到 I/O 告警时，快速研判磁盘剩余空间与阵列状态。
• 更换磁盘前后，通过插槽图直观确认重建进度／完成情况。
• 当 基础设施 ▸ 告警 中的磁盘剩余空间告警触发，需要下钻查明受影响的是哪个卷时。

布局

主区 · 控制栏

• 标题／副标题 ＋ 刷新时间戳（Updated: HH:MM:SS）＋ 刷新按钮（手动轮询）。
• 主机筛选栏 — All 加上每台主机一个按钮。选中某台主机即筛选到该主机，并回到第 1 页。

存储卡片

每台主机渲染一张卡片。

若没有控制器信息，卡片显示 No controller data；若一张卡片都没有，则显示 No storage data.。列表按每页 10 条分页。

状态配色规则

RAID 汇总 · 逻辑卷状态（raid_tone）：

物理磁盘状态（disk_tone）：

磁盘使用率（usage_tone）：

使用方法

1. 从菜单打开 基础设施 ▸ 存储与 RAID。
2. 用顶部的主机筛选聚焦到某一台服务器，或查看 All。
3. 先扫视每张卡片页眉上的 RAID 徽标，优先处理琥珀色／红色的卡片。
4. 在有问题的卡片上，阅读物理磁盘图，找出哪个插槽处于 Failed／Missing／Rebuild。把鼠标悬停在小标签上可看到型号与序列号的工具提示。
5. 查看使用率条，判断数据卷是否正在逼近 80%／95% 的阈值。
6. 如果数据看起来已经陈旧，点击右上角的刷新。

本页面不会自动轮询。展示的数据会经过服务端 30 秒缓存，只有当您按下刷新按钮（会重新查询 /infra/storage/live）时屏幕才会更新。若让它一直开着观察趋势，请定期按刷新。

数据来源

两张表都来自遗留 MySQL（legacy 连接，只读）。应用从不写入它们。

json_data 的结构（示例）

{
  "controllers": [
    {
      "model": "Adaptec ASR-5805",
      "temperature": "41C",
      "battery_status": "Optimal",
      "status": "Optimal",
      "logical_volumes": [
        { "name": "Data", "raid_level": "6", "status": "Optimal", "size": "10.9TB" }
      ],
      "disks": [
        { "slot": 0, "status": "Online", "model": "ST4000NM0033", "serial": "Z1Z00000", "size": "3.6TB" }
      ]
    }
  ]
}

df-* 的取值结构

server_status.value 是一段 JSON，携带 p（百分比）· u（已用）· a（可用）。

{ "p": 72, "u": "7.2T", "a": "2.8T" }

主机 ↔ 别名映射

使用率是通过一张静态映射表关联的：从 storage_status.host（大写标签）映射到 server_status.server_alias（小写）。映射表中不存在的主机，退回使用小写化的主机名。

seq 窗口查询 — 避免慢扫描

server_status 是一张大型时间序列表。用 MAX(seq) … GROUP BY server_alias, part 聚合整张表会触发全表扫描。构建器（StorageStatusService::dfUsageByAlias）改为只通过索引取出最近的 3 个 seq 值，然后仅读取这些 seq 中的 df-* 行。

-- 1) 最近的 3 个 seq 值（seq 索引 → O(log N)）
SELECT DISTINCT seq FROM server_status ORDER BY seq DESC LIMIT 3;

-- 2) 仅取这些 seq 中的 df-* 行（由旧到新，后者胜出）
SELECT server_alias, part, value
  FROM server_status
 WHERE seq IN (?, ?, ?) AND part LIKE 'df-%'
 ORDER BY seq;

对每个别名优先取 df-data part；若不存在，则以使用率最高的卷（p 最大者）作为代表值。

最新的 RAID 行同样会收窄为每台主机的最新一行。

SELECT MAX(id) AS mid FROM storage_status GROUP BY host;   -- 每台主机的最新一行
SELECT * FROM storage_status WHERE id IN (?, ...) ORDER BY host;

结果以键 infr:infra:storage:v1 缓存 30 秒。这样可以抑制对遗留库的往返查询，并吸收并发访问。如果遗留库不可达，构建器会吞掉异常并返回空数组，因此页面会优雅降级为 No storage data.。

访问权限

• 查看：任何已认证用户（基础设施区域最低 user_level 1 ＝ demo）都可以查看。该路由位于 infr.auth 分组中。
• 无写入：本页面完全只读。没有任何操作会改变 RAID／磁盘状态或操纵阵列（更换／重建由 SE 在目标主机上完成）。
• 存储资产的新增／编辑（设备元数据、文件区域）在独立的 资产 ▸ 存储与文件 页面进行，其写入需要 user_level 2 或以上。

排障与常见问题

Q. 卡片显示出来了，但使用率（DATA VOL）是空的。 该主机的 alias 在最近的 seq 窗口内没有匹配到任何 df-* 数据。请确认该节点上 run_report.js 正在运行，并且主机↔别名映射正确。该映射是一张静态映射表，与 管理 ▸ 采集器 中的 run_report 配置是分开的。

Q. 磁盘图／控制器显示“No controller data”。 storage_status.json_data 的 controllers 数组为空，或解析失败。该主机可能没有 Adaptec RAID，或者 sync_adp.js（arcconf）采集正在失败。请检查 arcconf 的路径与权限。

Q. 所有内容都显示“No storage data.”。 遗留库连接失败，或 storage_status 中没有任何行。构建器在异常时返回空数组。请核验 legacy 连接（.env 的 DB_*）以及采集器的健康状况。

Q. 数值和几分钟前一模一样。 (1) 本页面不会自动轮询 — 请按刷新。(2) 服务端缓存有效期为 30 秒。(3) 从根本上说，采集器（sync_adp.js、run_report.js）在 Laravel 之外按计划运行，因此数据源的新鲜度取决于 cron 的执行周期。

Q. 出现了 Degraded 徽标 — 我该怎么办？ 在物理磁盘图中找到处于 Failed／Missing 的插槽，更换该磁盘，并确认控制器已开始自动 Rebuild。重建期间阵列对双盘故障很脆弱，因此也请一并核验您的备份态势（备份 ▸ 计划看板）。

相关内容

• 基础设施 ▸ 健康状态 — 各节点的 CPU · 内存 · 磁盘 · 服务实时状态。
• 基础设施 ▸ 服务器 — 各服务器的负载时间序列。
• 基础设施 ▸ 告警 — 磁盘剩余空间／RAID 状态的告警策略。
• 资产 ▸ 存储与文件 — 存储资产台账与文件区域树（可写入）。
• 管理 ▸ 采集器 — sync_adp.js 与 run_report.js 采集器注册表。