# 存储界面还显示"可用 50%"，ERP却已经躺平 4 小时——一次 SSD 性能层写满的生产事故复盘

> **导语**：一台混闪存储的 SSD 性能层被"搬家"的数据灌满，冷热分层自动停摆，LUN 触发自我保护直接离线；跟着一起下线的，还有跑在它上面的ERP和虚拟机。而故障当下，存储管理界面上那条容量条，依然平静地显示着"可用 50%"。
>
> 这不是某个品牌的缺陷，而是**分层存储的一个通用陷阱**。把它完整写出来，希望后来的人少踩一次。

## 一、事件速览

| 项目 | 内容 |
| --- | --- |
| 故障等级 | T1 - 严重事故 |
| 故障发生 |  11:48（热数据层触发容量报警，ERP部分服务器停机） |
| 业务中断 | 13:18（LUN 脱机，ERP全线停止服务） |
|ERP恢复 | 17:16（重启ERP服务） |
| 业务完全恢复 | 20:10（接口服务恢复）→ 21:08（积压单据处理完毕） |
| 影响范围 | ERP无法登录；门店调拨异常、发票系统、影像系统等多个系统不可用 |
| 涉及设备 | 联想 DM7000H 混闪存储（FabricPool 冷热分层），及挂载该存储的多台虚拟机 |
| 直接原因 | 热数据层（SSD 性能层）写满，超过保护阈值，LUN 自动离线 |
| 一句话教训 | **"存储可用容量"和"性能层水位"是两个完全不同的数字，只看前者等于闭眼开车。** |

## 二、故障经过：一场 9 个半小时的连锁反应

### 缘起：一场被拉长的虚拟机迁移

存储替换项目的新集群搭建完成，开始按规划做虚拟机迁移。由于老存储（DM3000）性能偏低，迁移周期被严重拉长。

做完之后大家看了一眼存储状态：**"未见异常"**。这四个字，是后面所有问题的伏笔——因为当时看的，是**卷级/池级的逻辑可用容量**，而不是 SSD 性能层的真实水位。

同一天凌晨，按运维惯例给虚拟机**统一打了快照**。快照 + 迁移落地的全量数据写入，两股流量叠加，成为压垮性能层的最后一根稻草。

### 爆发：11:48

11:48，热数据层触发容量报警，ERP消息服务器、应用服务器相继停机，监控平台采集失败告警，一线反馈门店调拨异常。

在此期间，存储管理界面显示的**存储容量可用 50%**——这个数字极具误导性，它让第一时间的判断偏向了"存储空间还很富裕，应该不是存储的问题"。

### 定位：LUN 脱机 ≠ 空间不足的表象

接到多个业务报障后，排查确定故障点为**存储 LUN 脱机**。查看卷信息：总容量 38.9TB、已用 18.5TB，**可用容量仅剩 33.8GB**。

请注意这三个数字是互相打架的：38.9TB 的总量、18.5TB 的已用，理论上应该还剩 20TB 左右的可用空间，但实际只剩 33.8GB。**当容量口径开始互相打架时，说明你看的不是同一层的东西**——这是本次事故里最值得记住的一个信号。

### 反复：12:57 恢复 → 13:18 再次离线

在供应商工程师指导下，**临时恢复**了存储连接状态，重启ERP相关业务，12:57 业务短暂恢复。

但根本问题没有解决：**热数据层依然满着，分层依然停摆**。13:18，存储在毫无悬念地再次触发保护机制，ERP业务二次停机。

> **这里有第一个血的教训**：只要触发保护机制的根因（性能层水位）没有真正下降，任何"恢复连接、重启业务"的处置都只是把故障往后推迟 20 分钟。真正要做的第一件事，是**腾出热数据空间**。

### 抢救：从 ESXi 侧绕过 vCenter

雪上加霜的是，**虚拟机本身也跑在这台存储上**。存储 LUN 脱机后，虚拟化平台无法登录，等于"用来救火的水管，本身就接在着火的这栋楼上"。

最终方案是绕开 vCenter，**直接登录 ESXi 主机**，手动迁移虚拟机文件并在目标主机重新注册，先把部分虚拟机迁到另一台存储（宏杉）上，释放性能层空间。迁移出一部分数据后，vCenter 恢复登录，再回到 vCenter 正常迁移。

这一步能走通，靠的是团队对 ESXi 底层操作的熟悉度——**建议每一个跑虚拟化的团队，都提前演练一次"vCenter 挂掉后用 ESXi 直接迁移虚拟机"的流程**，不要等到真出事时现学。

### 收尾：ERP起来了，业务还没好

17:16 ERP服务重启成功，看起来"恢复了"。但一线的调拨异常并没有消失。19:13，排查定位到**与前端对接的接口服务异常**，而部署这个服务的虚拟机，同样跑在这台存储上。

20:10 接口服务恢复，调拨业务恢复。21:08，积压的业务单据通过临时开发的自动推送工具处理完毕。

**从 SAP 恢复到"一线业务真正恢复"，中间又隔了将近 3 小时。**

## 三、根因剖析：分层存储里"看不见的三个水位"

### 1. 先说清楚这套存储是怎么工作的

这台存储配置了 FabricPool 冷热数据自动分层：

- **性能层（SSD AGGR，本次配置 16.5TB）**：存放"热数据"，承担绝大部分读写 IO；
- **容量层（HDD / 对象存储）**：存放"冷数据"，成本低、容量大；
- **冷热判定**：由存储内部的散热扫描程序完成，判断数据多久没被访问过，够"冷"就下沉到容量层。

架构本身没有任何问题，这是主流且成熟的设计。**问题出在——很多人把它理解为"SSD 是缓存，写满了会自动挤出去"，而实际上它是"有硬容量上限的一层，而且下沉是有节奏、有条件的"。**

### 2. 数据是怎么把 SSD 层灌满的

近期的虚拟机迁移，把大量数据写入了 LUN2，而 LUN2 是**新建的、数据全新的**——新写入的数据默认全是"热"的，必须先落在性能层。

于是出现了一个简单的算术题：

- 性能层容量：**16.5TB**
- 短期内需要写入的热数据：**20+TB**
- 结果：**装不下**

### 3. 为什么"来不及"下沉：三个时间常数

很多人会想："满了不是会自动往 HDD 层沉吗？" 对，但下沉有三个时间/条件常数，每一个都拖慢了你得救的速度：

- **最小冷却期是 2 天**。存储判定"冷"的依据是数据连续未访问的时长，而这个值有下限。也就是说，**今天写进来的数据，最快也要两天后才有资格下沉**。（不同分层策略的默认值不同，实际默认值可能远大于 2 天，本次现场已被调整为接近最小值的 2 天。）
- **散热扫描每天只跑一次**。数据"够冷"之后还要等扫描程序发现它。所以从写入到真正搬走，实际耗时常常是 3～4 天，而不是 2 天。
- **任何访问都会重置热图**。备份、杀毒扫描、索引重建、批量快照——只要读了一次，这个数据块就"回热"，冷却期重新计时。**本次事故中，"迁移落地 + 凌晨批量打快照"正好把这两个条件都占满了。**

### 4. 补刀：分层阀门会主动关闭

更关键的一点：**分层不是永远开着的**。存储里有一个"填充度阈值"，当性能层使用率超过它时，分层会被限制甚至停止。而本次现场，**这个阈值是 98%**。

于是链条闭合了：

1. 迁移 + 快照把 20+TB 热数据灌进 16.5TB 的性能层；
2. 冷却期 + 每日一次扫描让下沉速度跟不上写入速度；
3. 性能层使用率冲到 **99% 以上**，超过 98% 的分层停顿线，**冷数据也沉不下去了**；
4. 性能层彻底写满，存储的数据保护机制触发，**LUN 自动离线**；
5. 挂载该 LUN 的虚拟机全部异常停机，业务全线中断。

厂家工程师的答复也印证了这条链路：**"由于热数据层写满，导致 LUN 自动离线。"**

顺带一个容易被忽略的细节：**即使手动强制冷却数据，也必须给性能层留出至少 2% 的空间**。也就是说，性能层不是可以"压到 100%"的。

### 5. 灵魂拷问：为什么界面显示"可用 50%"？

这是本次事故里最有价值的一个认知点。

存储管理界面显示的"可用 50%"，看的是**卷/LUN 层面的逻辑容量**（38.9TB 总量里还剩一半）。但真正引爆故障的，是**SSD 性能层物理介质的水位**——16.5TB 的盘里塞了 20TB 的预期写入。

**逻辑容量健康，物理性能层爆炸**，两个指标同时成立，一点不矛盾。而大多数人的监控和告警，只盯着前者。

## 四、十个坑，踩过的都懂

**坑 1：用"卷可用空间"判断存储健康度。**
分层存储里，卷级可用容量和性能层水位是两套账。真正需要盯的是**性能层的使用率**。本次事故中，卷界面显示可用 50%，性能层却已 99%。

**坑 2：把 SSD 性能层当成"无限缓存"。**
它不是缓存，是硬容量。**性能层有多大，短期内能接多少新数据就是多少**，超了就是超了。

**坑 3：大批量数据搬迁没有分批、没有限速、没有提前算账。**
一次虚拟机迁移、一次全量备份、一次批量快照，都可能瞬时产生几十 TB 的"热数据"。搬迁前必须算一道题：**这批数据量 ÷ 性能层容量 = 几倍？** 本次是 20+TB ÷ 16.5TB ≈ 1.3 倍，超载。

**坑 4：批量快照不计入容量账。**
快照会让"已经不活跃"的数据重新活跃起来，而且会显著增加性能层占用。**本次统一打快照，就是那根稻草。** 大批量快照要做容量评估，不要按惯例"顺手全打一遍"。

**坑 5：两个阈值没人管——起分层 50%、停分层 98%。**
性能层的使用率达到阈值后，冷数据才会开始下沉；超过上限阈值，分层又会被停掉或者限制。这次 98% 的上限阈值意味着**留给存储自我调节的余量只有 2%**，稍有波动就直接击穿。这个参数需要结合业务写入特征重新评估。

**坑 6：vCenter 与生产系统同池部署。**
vCenter 跑在同一台存储上，导致故障时"管理面"和"数据面"一起挂，既无法通过 vCenter 迁移虚拟机，也无法通过它查看集群状态，**恢复难度成倍上升**。管理组件必须与它所管理的工作负载隔离。

**坑 7：第一次处置只"临时恢复连接"，没有消除根因。**
12:57 恢复、13:18 二次离线。**只要性能层水位没有真正下降、保护机制还在，恢复连接等于白做。** 应急处置的第一步应该是"腾空间"，而不是"重启业务"。

**坑 8：业务恢复只看了"主系统"。**
SAP 17:16 恢复，但依赖同一台存储的接口服务和后端单据处理还挂着，一线体感依然是"系统坏了"。**恢复时必须按业务链路挨个系统过一遍**，而不是主系统起来就宣布恢复。

**坑 9：没有主动监控，靠一线报障才发现。**
存储支持 SNMP，也有官方管理软件可以做细颗粒度监控（包括卷使用率等指标），但本次故障前**没有部署对热数据层水位的告警**，第一个发现异常的是门店。

**坑 10：单存储、单活、无容灾。**
一台存储的容量事故，掀翻了一整条核心业务链。**SAP 这种核心系统，必须评估多活/容灾架构**，数据库和应用都要考虑。

## 五、现场应急 SOP（可直接抄）

按本次实际处置顺序整理，遇到同类故障可以直接照着做：

1. **先看性能层，不看卷容量。**登录存储底层查看聚合（AGGR）使用率，确认是不是性能层写满；同时核对卷信息的各项容量数字是否自相矛盾。
2. **立刻止住写入。**暂停会大量产生新热数据的任务：虚拟机迁移任务、批量备份、批量快照计划。
3. **腾空间优先于重启业务。**把非关键虚拟机迁出，把大容量 LUN 的数据迁移到其他存储；手动强制冷却冷数据时，**必须给性能层留至少 2% 余量**。
4. **临时关闭数据保护机制时要有保护网。**本次由厂家临时关闭了"热数据层写满即自动离线"的保护，目的是争取迁移窗口。**但这属于临时措施，必须同步建立人工盯守**，且迁移完成后尽快恢复。
5. **vCenter 不可用时走 ESXi 直连。**直接登录 ESXi 主机，迁移虚拟机文件并在目标主机重新注册，先把管理平台救活。
6. **业务恢复按链路逐项确认。**主系统 → 接口服务 → 上游/下游系统 → 积压数据，一项都不能漏。
7. **处理积压单据。**量大时不要靠人工硬扛，可以临时写自动推送工具批量下发。
8. **容量参数复核后再调优。**冷却周期调至最小值不能解决根本问题，必须同时腾出物理空间。

## 六、整改措施与长效运营

### 1. 监控：把"看不见的水位"变成告警

- 联合厂家制定存储监控方案，**重点监控热数据层使用率**，而不是只看总容量；
- 启用存储的 **SNMP** 能力接入现有监控平台；
- 安装官方存储管理软件（本次为 Unified Manager），做**更细颗粒度**的监控，例如按卷的使用率；
- 建议监控线：**SSD 性能层按 90% 预警、95% 严重**；总可用容量（SSD + HDD，本次为 73TB）统一按 90% 作为监控红线。

### 2. 参数与配置：把性能层留出余量

- 冷却周期可在高级权限下调整，**最低 2 天**（不同策略默认值不同，最长可到 183 天）。调小能加快下沉，但**前提是物理层还有空间**，否则调参毫无意义；
- 分层填充度阈值（起分层 / 停分层区间）需要重新评估，**不要把所有余量都留给 98% 这条线**；
- 大容量 LUN 的划分建议**按虚拟机实际使用需求配置，不建议一次性划特别大的 LUN**——LUN 划得越大，单次事故的爆炸半径越大；
- 卷的置备模式（精简/厚置备）要在虚拟化层和存储层对齐口径。

### 3. 容量口径对齐：别再让两个数字打架

本次故障中"虚拟化显示 23.52TB、存储显示 15.5TB"的差异，根本原因是：

- **虚拟化层虚拟机磁盘是厚置备（Thick Provisioned）**：先占位，即使没写满也占住空间；
- **存储 LUN 默认是精简置备（Thin Provisioned）**：按实际写入计费。

**两个口径都对，但看的人必须知道自己在看哪一个。** 建议统一以**存储侧实际占用**为准做大容量核算，同时在监控上明确标注每个指标的口径。

### 4. 架构：消灭单点

- **管理面隔离**：vCenter 等虚拟化管理组件，不要与核心生产工作负载共用同一台存储；
- **核心系统多活**：评估并建设 SAP 多活架构，避免单节点故障导致业务中断，且要**同时覆盖数据库层和应用层的容灾**；
- **容量与性能分层规划**：本次整改后，SSD 性能层利用率回落到 **17%**、HDD 层 **10%**。HDD 层余量充足，可以承载更多虚拟机；但**性能层要持续盯**，一旦热数据增长趋势明显，应提前扩容性能层。

### 5. 团队能力

- 邀请厂家工程师培训**存储自动分层工作原理**，让运维团队真正理解"冷却期、散热扫描、填充度阈值"这三个概念；
- 演练一次 **vCenter 不可用场景下的虚拟机迁移恢复**；
- 把本次形成的应急 SOP 纳入变更与应急预案文档。

## 七、复盘 Checklist

换任何一套分层存储（全闪 + 容量层、混闪、FabricPool、自动分层卷），都可以拿这张表过一遍：

- [ ] 我知道这套存储的**性能层物理容量**是多少 TB；
- [ ] 我的监控里，**性能层使用率**是独立的告警项，而不只是卷使用率；
- [ ] 我知道分层**最小冷却期**是多少天，以及散热扫描的**运行频率**；
- [ ] 我知道分层的**起分层阈值**和**停分层阈值/填充度阈值**分别是多少；
- [ ] 虚拟机迁移、全量备份、批量快照之前，我做过**容量冲击评估**；
- [ ] 批量快照有**分批、限量**策略，不是"全量顺手打一遍"；
- [ ] vCenter / 管理组件**不与核心生产负载共用同一存储**；
- [ ] 我有能力在 vCenter 不可用时，**直接通过 ESXi 迁移虚拟机并重新注册**；
- [ ] 我的应急预案里，**"腾空间"排在"重启业务"之前**；
- [ ] 业务恢复清单是**按链路**列的，包含接口服务与积压数据处理；
- [ ] 核心系统有**多活 / 容灾**评估结论，且数据库与应用都在考虑范围内；
- [ ] 虚拟化层与存储层的**容量口径已对齐并写明**。

## 八、结语

这次事故的技术根因，一句话就能说完：**热数据层写满了，存储选择了保护自己，代价是业务停机。**

但真正值得记住的不是这句话，而是那三个反直觉的点：

1. **"可用 50%" 是真话，但它回答的不是"存储还能不能扛"这个问题。** 指标选错了，比没有指标更危险。
2. **分层是"有节奏的搬运"，不是"实时的卸载"。** 冷却期、扫描频率、阈值，三者共同决定了它永远追不上突发写入。
3. **"业务恢复了"和"SAP 起来了"是两件事。** 恢复动作要做完整条链路才算结束。

存储不会自己告诉你它快撑不住了，除非你主动去问正确的那个问题。

---



导语：一台混闪存储的 SSD 性能层被"搬家"的数据灌满，冷热分层自动停摆，LUN 触发自我保护直接离线；跟着一起下线的，还有跑在它上面的ERP和虚拟机。而故障当下，存储管理界面上那条容量条，依然平静地显示着"可用 50%"。

存储界面还显示"可用 50%"，ERP却已经躺平 4 小时——一次 SSD 性能层写满的生产事故复盘

科技执委、数字化中心副总

数据库

运维

存储故障根因是SSD性能层写满而非容量不足，监控需聚焦热数据层水位而非卷可用空间，冷热分层存在冷却期与扫描延迟，应急应先腾空间再重启业务，建议按90%阈值预警并定期演练vCenter故障恢复流程。

对象存储

数据迁移

数据保护

存储管理

数据处理

服务器

虚拟化

虚拟机

容灾

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

存储界面还显示"可用 50%"，ERP却已经躺平 4 小时——一次 SSD 性能层写满的生产事故复盘-腾讯云开发者社区-腾讯云

存储界面还显示"可用 50%"，ERP却已经躺平 4 小时——一次 SSD 性能层写满的生产事故复盘

存储界面还显示"可用 50%"，ERP却已经躺平 4 小时——一次 SSD 性能层写满的生产事故复盘

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐