企业官网建设流程全解析

机房里有台跑着业务库的机器，某天硬盘灯常亮不闪，登进去看dmesg干干净净，lsblk也看不出任何异常——因为那块盘是被阵列卡接管的，操作系统压根不知道底下发生了什么。这种时候真正能救命的，是把阵列卡那一层"黑盒"打开来看。MegaRAID Storage Manager（下文统一简称 MSM）就是干这件事的：它把阵列卡上的控制器、物理盘、虚拟盘、电池、温度、事件日志全部摊开成一个图形界面，让你在 Linux 桌面上就能建阵列、换盘、看重建进度、翻历史告警。这篇东西聊的是两件事——Linux 下 MSM 软件怎么装，以及装完之后怎么真正把阵列管起来。适合手上有一台带硬 RAID 卡的服务器、被"重建卡在 30% 三天不动"或者"界面打不开但服务明明起着"这类问题折腾过的运维和开发同学，也适合刚接手机房、第一次接触硬 RAID 的新手。我会把安装包里每个组件的用途、参数为什么这么选、坑通常埋在哪一步都讲清楚。

1. 先把边界划清楚：MSM 到底管的是哪一段

1.1 硬 RAID 卡和操作系统之间的那条分界线

很多人第一次接触 MSM 会误以为它是个"磁盘管理工具"，跟fdisk、lsblk、LVM 是一类东西，这就从根上理解偏了。硬 RAID 卡的逻辑是：盘插在卡上，卡自己有一颗处理器和一块缓存，由它来决定几块盘怎么拼、坏一块怎么补、数据先写缓存还是直写盘。操作系统看到的只有卡"上交"给它的那几个逻辑卷，比如/dev/sda、/dev/sdb，至于sda底下是几块盘、做的 RAID5 还是 RAID10、有没有热备，内核一律不知情。

MSM 站的位置就在这条分界线的卡这一侧。它不改文件系统、不做分区、不碰 LVM，它只跟阵列卡上的固件对话。所以有个很典型的判断方法：lsblk能看到的东西归操作系统管，lsblk看不到但实际存在的盘，归阵列卡管，也就归 MSM 或者命令行工具管。你在一块已经被阵列卡做成 RAID5 的盘上想"加一块盘扩容"，用growpart是白费劲的，必须先在卡这一层做在线扩容（OCE），再回到系统层去扩文件系统。

把这条线划清楚之后，很多事情就顺了：MSM 装不上，八成不是 Linux 的问题，是卡、固件、驱动、Java 这几样里的某一个对不上；MSM 装上了但看不到控制器，八成是驱动没加载或者权限不够，而不是软件装错了。

1.2 图形化 MSM 和命令行的分工，别指望一个打天下

MSM 是图形界面，但它不是万能的。我自己的使用习惯是：日常巡检、建阵列、看重建进度、翻事件日志、导出日志包给厂商，用 MSM；批量操作、写脚本、无图形环境、开机自动检查，用 StorCLI 或 MegaCli。这两套工具背后对接的是同一套控制器接口，只是表现层不同。

为什么不能只用图形界面？因为服务器大多数时候是远程 SSH 进去的，很多生产机压根没装桌面环境，为了一次性看个阵列状态去装个 X11 纯属给自己找麻烦。反过来为什么不能只用命令行？因为排查故障时图形界面的信息密度更高：一块盘的状态、位置、序列号、错误计数、温度，MSM 一屏就能对照着看完，命令行得敲三四条命令拼起来看，眼睛容易漏。

我把这个分工整理成了一张表，你按场景对号入座就行：

提示：MSM 的日志打包功能非常值得记住。阵列卡出问题时，只截一张图给厂商基本等于没给，对方要的是完整的 support archive，里面包含控制器日志、事件日志、驱动版本、固件版本，一次打包能省掉好几轮来回。

1.3 三种部署形态，动手前先选定一种

MSM 不是只能"装在本机看本机"，它有三种常见形态，选错了后面全是白折腾：

第一种是本机全量安装，服务端和图形客户端装在同一台机器上，人坐在机器前或者通过远程桌面看。适合单机、实验环境、小规模。

第二种是服务端 + 远程客户端，在每台被管服务器上装 MSM 的框架服务（Framework），运维人员的笔记本或者跳板机上装图形客户端，通过网络连过去。这是中小规模机房最常见的做法，一台跳板机管几十台机器，不用每台都开图形界面。

第三种是只装 CIM Provider，把阵列卡的信息通过标准的 CIM/WBEM 接口暴露出去，由第三方监控平台统一采集。适合已经有监控体系、只想要数据不想要界面的场景。

我第一次部署就吃过这个亏：在跳板机上装了完整 MSM 想连服务器，结果服务器上什么都没装，客户端自然是连不上的。记住一句话：被管的那一端必须有服务或 Provider 在跑，图形客户端只是"遥控器"。

2. 装之前的核对清单：少一样都会在启动阶段翻车

2.1 卡型号、固件、驱动，三个版本要对得上

MSM 装不上或者装上了打不开，绝大多数根因在版本不匹配上，而且这个错很难从报错信息里直接看出来。我建议动手之前按顺序核对三件事：

第一，确认卡的具体型号。同一代产品下往往有高端、中端、入门几个系列，支持的 RAID 级别、缓存大小、能否在线扩容都不一样，MSM 的版本支持范围也不一样。用lspci | grep -i raid可以大致看出控制器型号，更准确的做法是看dmesg里驱动加载时打印的那几行，通常会带上芯片代号。

第二，确认固件版本。固件和 MSM 之间是有兼容矩阵的，太老的固件配新版 MSM，可能出现"能连上但某些页面空白"的诡异现象。固件版本可以在卡的自检界面（开机时进阵列卡配置界面）里看，也可以用命令行工具查。

第三，确认内核驱动版本。用modinfo查当前加载的驱动模块版本，和厂商支持列表里列的版本区间对一下。内核升级之后驱动没跟着更新，是最常见的"昨天还好好的今天打不开了"。

这三样我不建议凭记忆，建议当场敲命令记下来，写进部署文档里。因为半年后再来一次同样的故障，你会非常感谢当时记下来的那三行版本号。

2.2 依赖库和 Java 运行时，这是最大的隐形门槛

MSM 的图形客户端是用 Java 写的，这是它最容易被低估的前置条件。老版本对 Java 版本卡得很死，版本高了低了都可能起不来：高了报方法找不到，低了报类版本不支持。安装包有时会自带一份 JRE 在安装目录下，有时要求用系统的 Java，不同发行版、不同版本的 MSM 行为不一样。

判断方法很直接：装完之后启动客户端，如果窗口一闪就没了，或者命令行启动时报UnsupportedClassVersionError、NoClassDefFoundError，几乎可以锁定是 Java 的问题。这时候去安装目录下看看有没有自带的jre子目录，有就用它自带的，别去动系统的 Java 环境，避免把一个服务的问题扩散成整个机器的问题。

除了 Java，还有几样基础依赖要确认：libXp、libXm这类老图形库在新版发行版上经常缺；字体包缺失会让界面变成一堆方块；32 位兼容库在纯 64 位系统上默认没有，而部分组件是 32 位的。装之前先跑一遍依赖检查，比装完再补要省事得多。

2.3 端口、防火墙和强制访问控制

MSM 的服务端要监听端口，客户端靠这个端口连过来。默认情况下图形客户端走一个固定端口，CIM Provider 走标准的管理端口。这两类端口在服务器本地防火墙开着的时候会被拦，表现就是"服务明明起来了，netstat也能看到监听，但客户端连不上"。

我见过最浪费时间的一次排查，是同事确认服务在跑、端口在听、telnet也通，就是客户端连不上，最后发现是系统自带的强制访问控制策略把服务进程限制住了。这类问题的排查顺序应该是：服务状态 → 本地监听 → 本机回环连通 → 跨机连通 → 安全策略，一层层往外推，别一上来就怀疑软件装坏了。

注意：如果你的环境有统一的防火墙策略，别自己去改整机策略，走变更流程申请放行具体端口。为了一个管理工具把整机防火墙关掉，是典型的用小便利换大风险。

3. Linux 下 MSM 的完整安装实操

3.1 安装包结构拆解：里面到底装了几样东西

从厂商支持站点按卡型号下下来的 MSM 安装包，通常是一个.tar.gz，解开之后是一个目录，目录里有个disk子目录（有的版本叫Linux或直接就是 rpm 集合），里面躺着若干个包。这些包各司其职，搞清楚它们分别是什么，后面出问题才知道该查哪个日志：

• 图形客户端包：提供那个 Java 界面，如果只想要命令行，这个可以不装。
• 框架服务包：后台常驻进程，负责和控制器固件通信，是所有形态的基础，必装。
• CIM Provider 包：把阵列信息翻译成标准管理接口，接第三方监控时才需要。
• 命令行工具包：StorCLI 或 MegaCli，即使你打算主要用图形界面，也强烈建议装上，出故障时图形界面往往第一个失效。

解压之前先校验一下包的完整性，尤其是通过中转、U 盘拷贝过来的包。我遇到过包在传输过程中损坏、解压没报错但 rpm 安装时报签名异常的情况，白折腾一小时。

# 解压 tar -zxvf MSM_linux_x64_install-*.tar.gz # 进入解压目录，先看清楚里面有什么，不同版本目录名不同 cd MSM_linux_x64_install-*/ ls -R | head -50 # 校验完整性（如果有提供校验值） sha256sum MSM_linux_x64_install-*.tar.gz

这里我特意写了ls -R | head -50而不是直接给一个固定路径，因为不同版本的目录结构差异很大，照着某个博客里的路径硬抄是最容易踩空的做法。先看清结构，再决定敲什么。

3.2 RPM 安装与脚本安装，两条路各有取舍

进入disk目录后一般有两条路。一条是直接rpm -ivh逐个装，好处是你能精确控制装哪些不装哪些，出问题也能定位到具体某个包；另一条是执行目录下的安装脚本，好处是它会自动处理依赖顺序，坏处是交互式提示多、默认装全套。

cd disk ls *.rpm # 路线一：手动按顺序装，框架服务是最底层，先装它 rpm -ivh framework-*.rpm rpm -ivh MegaRAID_Storage_Manager-*.noarch.rpm rpm -ivh storcli-*.rpm # 路线二：有安装脚本的话 chmod +x install.sh ./install.sh

我个人的偏好是手动装。原因很实际：脚本装失败的时候，报错信息往往被吞在脚本里，你只看到"安装失败"四个字，不知道是哪个包的问题；手动逐个装，哪一步红了一片看得清清楚楚。而且生产环境很多时候只想要框架服务和命令行工具，不想要图形界面那一大坨依赖，手动装可以精准裁剪。

装完先别急着启动，确认一下安装目录。常见位置在/opt/MegaRAID/下面，进去看看有几个子目录，客户端、命令行工具、日志目录分别在哪。这个目录结构你以后会频繁用到：查日志、找命令行工具的绝对路径、给脚本写死路径，都靠它。

# 确认安装结果 ls -l /opt/MegaRAID/ # 命令行工具验证，能打出控制器信息就说明装对了 /opt/MegaRAID/storcli/storcli64 /c0 show # 或者旧版本 /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -Lall -aALL

3.3 启动服务、验证端口、首次登录

框架服务启动方式取决于版本和发行版。老一些的版本用 init 脚本，新一些的走 systemd：

# systemd 路径 systemctl start vivaldiframeworkd systemctl status vivaldiframeworkd # 老版本 init 脚本路径 /etc/init.d/vivaldiframeworkd start # 验证端口监听 ss -lntp | grep -E '3071|5988|5989'

服务起来之后，在有图形环境的机器上启动客户端。如果服务端和客户端是同一台机器，直接命令行敲客户端启动脚本即可；如果是远程，客户端启动后会让填主机名或 IP、用户名密码，这个认证走的是被管服务器上的系统账号，所以你需要一个在那台机器上有相应权限的账号。

首次登录成功后，界面左侧会列出这台机器上的控制器，点进去能看到物理盘拓扑和虚拟盘列表。如果只看到一个加了红叉或者灰色的控制器图标，说明服务起来了但和固件通信失败了，直接跳到第 6 章看排查。

3.4 开机自启与多机批量部署

管理类服务我一般都会设成开机自启，因为它的作用是"出事时能看到"，而不是"平时主动用"，如果每次重启都忘了起，真出事那天你会发现界面打不开。

systemctl enable vivaldiframeworkd systemctl is-enabled vivaldiframeworkd

多机部署时别一台台手敲。我的做法是写一个幂等脚本：检查是否已安装、未装则装、装完起服务、起完做一次连通性自检、把版本信息追加到统一的清单文件里。这个清单文件在后期做固件统一升级时价值巨大——你能一眼看出哪几台还停在老版本上。

#!/bin/bash # 简化示例，实际用要加上错误处理 PKG_DIR=/tmp/msm/disk rpm -q MegaRAID_Storage_Manager >/dev/null 2>&1 || rpm -ivh $PKG_DIR/*.rpm systemctl restart vivaldiframeworkd systemctl is-active vivaldiframeworkd && echo "$(hostname) OK" >> /var/log/msm_rollout.txt

注意：批量操作一定要先在一台非关键机器上跑通完整流程，包括失败回滚。我见过批量脚本里写死了服务名，结果那批机器版本较老、服务名不一样，脚本"执行成功"但服务根本没起来，等到要排查故障时才发现半个机房的 MSM 都是死的。

4. 用 MSM 建阵列：参数怎么定不是拍脑袋

4.1 RAID 级别选择与可用容量的算法

建阵列第一步是选 RAID 级别，这一步被玄学化的程度最高。我把实际用得到的几个级别和它们的容量算法列清楚，你按公式算，别凭感觉。

RAID0：容量 = 单盘容量 × 盘数，无冗余，一块坏全丢，只在纯临时数据、可重建的场景用。 RAID1：容量 = 单盘容量（两块盘互为镜像），冗余度最高，成本也最高，适合系统盘。 RAID5：容量 = (盘数 − 1) × 单盘容量，允许坏一块，是性价比折中点。 RAID6：容量 = (盘数 − 2) × 单盘容量，允许坏两块，大容量盘（单盘 8T 以上）时代我越来越倾向用 RAID6。 RAID10：容量 = (盘数 ÷ 2) × 单盘容量，性能好、重建快，代价是一半容量。

举个具体例子：8 块 4TB 盘。RAID5 是 7 × 4 = 28TB 可用；RAID6 是 6 × 4 = 24TB 可用；RAID10 是 4 × 4 = 16TB 可用。看起来 RAID5 最划算，但要注意一个关键问题：大容量盘的重建窗口太长。一块 4TB 盘重建动辄十几个小时，这期间如果再坏一块，RAID5 就是全丢，RAID6 还能扛住。所以我的经验是：单盘 2TB 以下、盘数不超过 8，RAID5 可以放心用；单盘 4TB 以上，除非业务对容量极度敏感，否则优先 RAID6。

实际可用容量还要再打个折：文件系统本身有开销，卡上可能有少量元数据占用，再加上你总要留 10%~20% 的余量给性能。所以我给容量规划的口径是"算出来的裸容量打八折"，宁可一开始觉得宽裕，也别半年后被迫做在线扩容——扩容步骤本身的风险远高于一开始多买两块盘。

4.2 条带大小、读写策略与缓存，三个真正影响性能的开关

MSM 建虚拟盘的时候会问几个参数，很多人直接点默认下一步，这是性能差距的主要来源。

条带大小（Stripe Size）决定了一次写操作会被切分到几块盘上。经验区间是这样的：数据库这类以小随机 IO 为主的负载，64KB 到 256KB 比较稳；大文件顺序读写、视频素材、备份归档，256KB 到 1MB 更合适；虚拟化混合负载，256KB 是个不太会错的选择。这个参数不是越大越好也不是越小越好，它要和你的文件系统块大小、上层 IO 大小匹配，匹配不上就会出现"一次逻辑写被拆成两次物理读"的放大效应。

写策略有直写和回写两种。直写是数据直接落盘，安全但慢；回写是先写卡上缓存、立即告诉系统写完了，快但依赖缓存有电池或电容保护。所以这里有一条硬规则：缓存没有电池或掉电保护单元，就不要开回写，一次意外断电就是数据不一致。有保护单元的话，直接开"始终回写"，这是硬 RAID 卡相对软 RAID 最大的性能优势所在。

读策略有预读和不预读。顺序读多的场景开预读，纯随机读的场景关了反而更干脆。这个参数调错了影响不大，但知道了可以少一次试错。

参数选完之后，MSM 会问你要不要立刻初始化。快速初始化只是把阵列的元数据写一遍，几秒钟完成，数据区不清零；完整初始化会把整块盘写一遍零，耗时按容量算，几个 TB 要几个小时。我的做法是：新盘第一次建阵列做完整初始化，一是让所有扇区都被写过一遍，能提前暴露坏道，二是避免盘上残留的旧数据被误读；已经用过的盘重建阵列，快速初始化就够。

4.3 热备盘、初始化与重建的节奏控制

热备盘分全局热备和专用热备。全局热备可以被这台机器上任意一个阵列使用，专用热备只服务指定的那个阵列。单阵列的机器用全局热备就够了，多阵列的机器建议每个阵列配一个专用热备，避免"A 阵列坏了盘，全局热备顶上去，结果 B 阵列再坏就没盘可顶"。

热备盘有个细节容易被忽略：热备盘的容量必须大于等于阵列里最大那块盘的容量，否则顶不上去。换盘升级容量的过程中，经常出现新旧盘混插、热备盘反而成了最小盘的情况，配的时候一定要看一眼。

重建（Rebuild）是可以限速的。默认情况下卡会全力重建，这会抢走大量 IO 带宽，业务侧感受就是"突然卡顿十几个小时"。MSM 里可以调重建速率，我一般的做法是业务高峰期限到 30% 左右，夜间放开。文件名里带rebuild或者rate的那个选项就是它。这里有个取舍要讲清楚：限速意味着重建窗口变长，窗口越长二次故障概率越高，所以限速是权宜之计，不能当常态，业务低峰期该放开就放开。

5. 日常运维：从"能看见"到"能提前知道"

5.1 事件日志和告警通道，先把通知打通

MSM 最有价值的页面其实不是阵列配置页，是事件日志页。它记录的是控制器层面的所有事件：盘的插拔、预测性故障、温度越限、电池学习、重建起止。这些事件在操作系统层面是完全看不到的，但对判断"这块盘还能撑多久"至关重要。

日志里的关键字段是预测性故障（Predictive Failure）。这个标记的意思是：盘的 SMART 自检报告了异常增长的重分配扇区或者寻道错误，卡判断它大概率要坏了，建议更换。看到这个标记就不要等它彻底坏掉再换——RAID 的价值在于主动换盘，而不是等盘挂了再被动重建。我的习惯是看到预测性故障，当天就排更换计划。

告警要打通，别指望"每天上去看一眼"。MSM 支持配置邮件通知和标准的管理协议告警，配一次能用很久。配置的时候注意三点：SMTP 服务器地址要填被管服务器能访问到的，别填本机回环；收件人别只填一个人，至少两个人；测试通知要真发一封确认收到，别配置完就不管了。

提示：告警阈值建议自己下调一档。默认的"盘坏了才告警"太晚，"预测性故障告警"要开，"重建开始/完成告警"要开，"电池进入学习周期"的告警建议关掉——那是正常维护行为，开着只会制造噪音，久而久之所有人都不看告警邮件了。

5.2 巡检、一致性检查和电池学习周期

巡检（Patrol Read）是卡自己定期把阵列上所有扇区扫一遍，发现读错误就尝试修复。这个功能默认是开的，一般不用管，但要知道它在跑，因为它会占用 IO。如果业务对延迟极其敏感，可以把它安排在低峰时段。

一致性检查（Consistency Check）是主动去校验 RAID5/6 的校验位和数据是否一致。为什么需要？因为一次意外掉电、一次写缓存丢失，就可能造成校验位和数据对不上，这种不一致平时看不出来，等到真的坏一块盘、需要靠校验位重建的时候，才发现重建出来的数据是错的——那个时刻就彻底没救了。所以一致性检查要定期做，我的节奏是每月一次，同样安排在低峰，先限速跑。

电池学习（Learn Cycle）是可充电池的定期容量校准，做完之后卡的写策略会临时从回写降级为直写，性能短暂下降。如果你的盘阵用了电池而不是超级电容，就一定会遇到这个周期性降级。知道这是正常行为，就不会在性能告警的时候瞎折腾。超级电容方案没有这个问题，这是新硬件相对老硬件的一个实际优势。

5.3 无图形环境怎么补：StorCLI 常用命令

服务器没装桌面，或者图形客户端连不上，这时候就靠命令行。下面这些是我用得最频繁的，建议收藏：

SC=/opt/MegaRAID/storcli/storcli64 # 控制器总览：固件、驱动、温度、告警数 $SC /c0 show # 所有虚拟盘 $SC /c0 /vall show # 所有物理盘（含状态、错误计数、盘位） $SC /c0 /eall /sall show # 重建进度 $SC /c0 /vall show rebuild # 创建 RAID5（4 块盘，走 252 号接口的 0-3 槽位） $SC /c0 add vd type=raid5 drives=252:0-3 # 把某块盘设为热备 $SC /c0 /e252 /s4 add hotsparedrive # 手动开始重建 $SC /c0 /v0 start rebuild # 调重建速率（按百分比） $SC /c0 set rebuildrate=30

MegaCli 的老命令对照也记一下，因为有些老机器上只有 MegaCli：

MC=/opt/MegaRAID/MegaCli/MegaCli64 $MC -LDInfo -Lall -aALL # 虚拟盘信息 $MC -PDList -aALL # 物理盘信息 $MC -AdpAllInfo -aALL # 控制器信息 $MC -FwTermLog -Dsply -aALL # 固件日志，排查疑难杂症用

把这些命令包成一个巡检脚本，输出关键字段，接到现有监控里，比每天手动看界面高效得多。脚本里要抓的字段不多：控制器状态、虚拟盘状态、物理盘状态、是否有预测性故障计数增长、重建是否在进行、温度。这六项就能覆盖九成以上的硬件隐患。

6. 常见问题与排查实录

6.1 服务起不来、界面连不上，按这个顺序查

症状一：systemctl start直接失败。先看systemctl status的详细输出，再看服务自己的日志文件（一般和安装目录同级的log目录里）。最常见的三个原因是：端口被占用、Java 环境异常、配置文件权限不对。权限问题容易被忽略——服务通常以特定用户运行，配置文件属主被改成别的用户后，服务启动时读不到配置就会静默退出。

症状二：服务起来了，客户端连不上。顺序是：本机ss -lntp看到监听吗？监听的是 127.0.0.1 还是 0.0.0.0？前者说明只监听本地，远程当然连不上。本机能连吗？本机能连说明服务没问题，是网络或防火墙拦了。跨机能连吗？用nc -vz试端口，通不通一目了然。最后才怀疑强制访问控制策略。

症状三：能连上，但界面一片空白或者只有一半功能。这就是版本不匹配的典型症状。客户端和服务端版本差太多，某些接口对不上，界面就渲染不出来。解决办法是统一版本：要么把客户端降到跟服务端同版本，要么把服务端升上去，别指望"凑合用"。

6.2 看不到控制器、看不到盘，问题往往不在软件

控制器图标是灰的或者带红叉。说明服务在跑但和固件通信失败。先用命令行工具验证一下：如果storcli /c0 show也报错，那就是驱动层或者固件层的问题，跟 MSM 无关，重装 MSM 一百遍也没用。这时候查dmesg里驱动加载的日志，查modinfo的版本，查固件版本是否在支持列表里。

能看到控制器，但物理盘列表是空的。大概率是权限问题。命令行工具和 MSM 服务读取控制器信息需要相应权限，普通用户跑不出来很正常，用 root 或者有权限的账号再试一次。

盘的状态显示"未配置的好盘"（Unconfigured Good）。这不是故障，是新盘或者被拔插过的盘处于待配置状态，需要手工把它加进阵列或者设为热备。这是新手最容易误判成"坏盘"的一种状态，看到这个词先去查状态说明，别急着报修。

换盘之后不自动重建。检查三件事：新盘的容量是否够、新盘是不是被设成了热备（有时候替换盘进来是 Unconfigured Good 而不是自动顶替）、阵列是否配置了自动重建。手动触发一次重建就能解决。

6.3 问题速查表

注意：遇到阵列异常，第一件事永远是先备份能备份的数据，而不是先动手修。重建、扩容、换盘这些操作都有二次故障风险，在没有备份的情况下做，本质是在赌。这个顺序我踩过坑之后再也没有改过。

最后分享一个我一直在用的习惯：每台带阵列卡的机器，交付时在/root/raid-info.txt里存一份当场的完整状态快照——控制器型号、固件版本、驱动版本、虚拟盘配置、每块盘的槽位和序列号、MSM 版本。这份文件在半年后排查问题时，价值远超任何文档，因为它是"这台机器健康时长什么样"的唯一证据。出故障时把当前状态和它一对比，哪块盘换过、哪个版本动过、配置改没改，一目了然。