容错设计概述：从概念到级别，一次讲透
这一章，我们聊聊容错设计。说白了，就是让系统在出问题的时候，还能继续干活。
我见过很多系统，设计时只考虑“正常运行”，一旦某个硬盘坏了，整个业务就挂了。这种设计，在审计眼里是过不了关的。我自己以前就踩过这个坑——给一个金融系统设计存储时，觉得单机双控就够用了，结果存储控制器固件bug，两台控制器一起重启，业务中断了半小时。从那以后，我再也不敢轻视容错设计了。
容错的基本概念
容错，不是说不让故障发生。故障一定会发生，这是物理定律。容错的意思是：故障发生了，系统还能正常工作，或者至少不会完全瘫痪。
你想想看，一个存储系统，硬盘总会坏，网络总会断，电源总会跳闸。真正的设计目标，是让这些故障对上层应用“透明”。
容错 vs 高可用 vs 灾备
- 容错：组件故障时，系统功能完全不受影响，用户无感知。
- 高可用：故障后允许短暂中断，但能自动恢复，一般要求99.999%（每年5分钟停机）。
- 灾备：故障后切换到远程站点，允许分钟级甚至小时级中断。
这里有个关键点：容错是最严格的。它要求系统内部没有单点故障，任何单个组件挂掉，整个系统仍旧提供服务。审计时，我最喜欢问一个问题：“如果这块硬盘坏了，业务能看到吗？”如果回答“能看到”，那容错就没做到位。
冗余策略：硬件冗余
冗余是实现容错最直接的手段。说白了，就是“多准备几套”。
硬件冗余分几个层级，我一个个说。
磁盘级冗余
RAID 是最经典的磁盘冗余。但不同 RAID 级别的容错能力差别很大：
| RAID级别 | 容错能力 | 空间利用率 | 我常用的场景 |
|---|---|---|---|
| RAID 1 | 允许1块盘故障 | 50% | 系统盘、日志盘 |
| RAID 5 | 允许1块盘故障 | (N-1)/N | 普通数据卷 |
| RAID 6 | 允许2块盘故障 | (N-2)/N | 关键数据、大容量卷 |
| RAID 10 | 允许镜像组内1块盘故障 | 50% | 高性能数据库 |
我的习惯：只要盘数超过8块，我必用RAID 6。因为RAID 5在重建时如果遇到第二块盘故障（比如重建过程中另一块盘也挂了），数据就全完了。审计时，RAID 5的“单盘容错”往往被审计师视为风险点。
控制器和路径冗余
硬盘冗余了，但控制器、电源、风扇、线缆这些呢？我见过有存储系统RAID 6配了双控，但两个控制器共用一块主板上的电源模块，结果电源烧了，整套系统都歇菜了。
硬件冗余要做到全路径冗余：
- 控制器：双控制器，支持故障切换（Active-Active或Active-Passive）
- 电源：双电源模块，每一路都能单独带载
- 风扇：N+1冗余，坏一个风扇不影响散热
- 主机通道：使用多路径软件，每个卷至少映射两条路径
记住：容错是“链式反应”的。一个环节的冗余被打破，整条链就断了。我曾经审计过一个项目，客户说他们的存储是全冗余的，结果我发现——两个控制器的网络接口卡都插在同一台交换机上。交换机一挂，两个控制器都没法访问了。这叫“单点故障”，在审计报告里是要打红字的。
冗余策略：软件冗余
硬件冗余成本高，而且复杂。实际上，很多容错能力是靠软件实现的。我甚至认为，软件冗余才是现代存储系统的核心。
数据副本
除了RAID，还可以通过数据副本来容错。比如：
- 三副本策略：数据写三份到不同的节点或硬盘，允许任意两副本同时故障。这是很多分布式存储的标配。
- 纠删码 (Erasure Coding)：比如EC 4+2，把数据切成4份，生成2份校验码，存到6块盘上。允许任意2块盘故障，空间利用率高达66.7%。
三副本 vs 纠删码
- 三副本：读性能好，写延迟低，适合高频访问的热数据
- 纠删码：空间利用率高，但读写计算开销大（需要CPU计算校验），适合冷数据或温数据
我自己的规则：热点数据保留三副本，7天前的数据自动转成纠删码。
故障检测与自愈
软件冗余不仅仅是数据的冗余，还包括故障检测和自愈。没有检测，冗余等于没有。
我曾经被一个存储专家问住：“你的系统里，数据副本是否一致？”后来我养成了一个习惯：所有存储系统都必须开启定期校验。说白了，就是后台自动扫描数据块，计算校验和，对比副本是否一致。如果发现不一致，自动用好的副本修复坏的。
我建议你在生产环境至少配置：
# 示例：ceph 的 scrubbing 配置（错误修复参数）
osd scrubs per second = 1
osd deep scrub interval = 604800 # 每周一次深度校验
osd deep scrub stride = 131072 # 每次校验128KB
# 校验和检查
osd objectstore = bluestore
bluestore checksum algorithm = crc32c
注意，校验频率太高会影响性能，频率太低又可能让坏数据长期存在。我一般设定每周一次深度校验，每次扫描速度控制在1MB/s以内，不影响白天业务。
容错级别
容错不是非黑即白的。从审计的角度，我们通常把容错能力分成几个级别。
| 级别 | 描述 | 典型实现 | 审计重点关注 |
|---|---|---|---|
| L0 - 无容错 | 任何组件故障都可能导致服务中断 | 单硬盘、单控制器 | 直接不合格 |
| L1 - 单点容错 | 允许单个组件故障，不影响服务 | RAID 1/5, 双控Active-Passive | 检查故障切换速度 |
| L2 - 多点容错 | 允许两个或以上组件同时故障 | RAID 6, 三副本, EC 4+2 | 检查重建时间与写入性能 |
| L3 - 自治愈 | 故障自动检测、自动修复，无需人工介入 | 分布式存储自愈, Ceph PG repair | 检查自愈触发条件与SLA |
嗯，这里要注意。很多厂商宣传自己的产品支持L3，但实际上自愈只在特定条件下触发。比如有些存储的“自愈”需要管理员手动点击确认按钮——这严格来说不算自愈。我经历过一次，客户发现硬盘故障后等了48小时，等管理员上班后才开始修复，业务早就降级了。
审计关键点：容错级别不是越高越好。全冗余会引入额外成本、复杂度和性能开销。审计时我通常问：“你选的容错级别，是否匹配业务RPO/RTO？”RPO（恢复点目标）要求接近0时，必须用同步复制或三副本；RTO（恢复时间目标）要求在分钟级时，容错级别必须包含自动故障切换，不能依赖人工运维。
容错级别的选择，其实是一个成本与风险的平衡。我自己的原则很简单：
- 核心交易系统：L2及以上，最好L3
- 日志、监控：L1就可以，偶尔中断数分钟可以接受
- 冷数据备份：L0都行，只要备份集本身无损坏
最后，把这一章的核心逻辑整理成一张图，方便你理解层级关系。
OK，这张图把容错设计的脉络理清楚了。从目标出发，到三大实现手段，最终落到容错级别的选择。你在实际审计或设计时，可以拿着这张图一层层往下检查——目标定了没？手段选了没？级别匹配了没？
容错设计不是堆砌冗余就完事了，它更需要系统化的思考。这一章讲的是理念和框架，下一章我们会深入到具体的审计维度，看看审计师在检查容错设计时，到底会盯哪些细节。
小建议：如果你是做审计的，第一次审查存储系统时，可以从“任何一个组件故障，业务是否受影响”这个问题入手。如果回答“是”，就可以直接打标记了。