RAID 与存储阵列

1 RAID 与阵列要覆盖什么

服务器里的数据最终要落在具体器件上：3.5 英寸机械硬盘靠盘片保存数据，2.5 英寸 SATA SSD 和带 PCIe 接口的 NVMe SSD 靠闪存保存数据。它们都有容量、带宽、延迟和寿命边界，也都可能突然失联。RAID 把多块盘按规则组合，向操作系统提供逻辑存储设备，主要是在容量利用率、并行访问和部分硬盘故障容忍之间做选择。阵列还包含连接这些盘的背板、线缆、控制器、供电和管理软件，不能只把它理解成盘数相加。

设想 1 台 2U 服务器：2 颗 CPU、128 GiB 内存、8 个前置硬盘位和 2 个 25 GbE 网口。数据库程序在 CPU 上运行，内存暂存热数据，持久化请求经操作系统、存储控制路径、背板到达硬盘。网卡快，并不表示盘也快；标称 25 Gb/s 是链路比特速率，单块机械盘顺序传输可能只有约 200 MB/s，随机访问还要等待机械寻道。阵列可以让多块盘分担请求，却不能消除链路、控制器和请求模式造成的限制。

先区分 3 个目标。容量回答能存多少；性能回答特定负载下能以怎样的延迟处理多少请求；可用性回答部件失效后服务能否继续。它们不能用同 1 个数字代表。8 块盘的总原始容量，并不等于用户可用容量；持续吞吐很高，也不保证每次小写入都及时完成；允许坏掉 1 块盘，也不代表整个服务器不会停机。学习 RAID，要始终把“哪种故障、剩余什么能力、持续多长时间”连起来说。

例如 4 块 8 TB 硬盘，单盘故障可能来自电机、磁头、电子板或接口错误。镜像能让另一份副本继续提供数据，但同 1 条背板供电故障可能让 4 块盘同时消失。控制器损坏可能使数据暂时无法访问，机房进水则可能带走整台机器。RAID 的保护范围通常围绕成员盘失效展开，不能自然扩展成对整条业务链路的承诺。

本课以等容量硬盘为主建立直觉，容量使用厂商常见的十进制 TB，内存使用 GiB。1 TB 等于 10¹² B，1 GiB 等于 2³⁰ B，操作系统显示单位不同会让数字看起来变小。后续计算先扣除 RAID 冗余，再考虑文件系统、元数据和预留空间，避免把单位差异误判成容量丢失。

2 条带、镜像与校验的取舍

条带是把连续逻辑数据分成块，分布到不同成员盘。例如条带块大小为 256 KiB，逻辑数据块 A、B、C、D 可以依次落到 4 块盘上。大请求可能同时使用多块盘，小请求则可能只访问其中 1 块。这里的块大小是阵列配置概念，不能直接等同于文件系统块或硬盘物理扇区。条带有助于并行，但只有分布而没有冗余时，任意成员缺失都会使部分逻辑数据不可读。

RAID 0 就是常见的无冗余条带。4 块 8 TB 盘的理论容量是 32 TB，适合能够重新生成、且允许整体失效的临时数据。它没有单盘故障容忍能力。盘数增加会增加成员出现故障的机会，因此不能把“0”理解成最基本的保护等级。即便文件似乎分散在不同盘上，丢失部分条带也可能破坏文件系统结构，使整卷都无法正常使用。

RAID 1 使用镜像。在常见的 2 盘配置中，相同逻辑内容保留 2 份，2 块 8 TB 盘通常得到约 8 TB 理论容量。写入需要维护镜像的一致状态，读取可能由不同副本分担，具体行为由实现决定。某块盘失效后，剩余副本可以继续工作；但误删也会作为合法写入传播到副本。镜像复制的是存储状态，不会判断状态是否符合人的意图。

RAID 5 在条带中保存相当于 1 块成员盘容量的校验信息，通常至少需要 3 块盘。以 4 块 8 TB 盘为例，理论容量约为 24 TB，允许任意 1 块成员失效。校验块随条带分布，不应想成永久指定某块盘只放校验。入门时可以把校验理解成已知其余数据后能够推回缺失内容的额外信息；它并不是另存完整文件，也不等于能够识别所有静默损坏的数据校验体系。

RAID 6 保存相当于 2 块盘容量的独立校验信息，通常至少需要 4 块盘，允许任意 2 块成员失效。4 块 8 TB 盘的理论容量约为 16 TB。它为更大的故障余量付出容量和计算、访问成本。校验的数学构造留到后续课程，本课只要求记住：额外冗余必须足够独立，才能在更多未知数据出现时完成恢复。

RAID 10 先形成镜像组，再在组之间条带化。常见的 4 盘配置是 2 组镜像，每组 2 块 8 TB 盘，理论容量约为 16 TB。它可以承受每组各坏 1 块，却无法承受同组 2 块都坏。因此“最多可以坏 2 块”缺少关键条件，应当写成具体失效组合。更多盘组成的 RAID 10 同样需要检查镜像成员关系，不能只看剩余盘的总数。

表中 S 是成员有效容量，N 是盘数；混用不同容量时，传统布局往往按较小成员容量参与组织，不能直接套用原始容量之和。实际可用容量还会减少。布局名称只描述组织规则，不承诺某个固定吞吐倍数；控制器能力、队列深度、缓存策略和负载形态都需要单独测量。

3 重建、降级与写入惩罚

阵列失去成员但仍可提供数据时，通常处于降级状态。RAID 1 可以从剩余镜像读取；RAID 5 遇到落在失效成员上的数据，需要读取其他成员并利用校验恢复。此时业务可能仍然成功，冗余余量却已经减少，部分访问也会变慢。监控如果只记录“卷能否挂载”，就会漏掉最需要处理的时间窗口。

安装替换盘后，重建把缺失的数据或冗余内容写到新成员上。镜像重建主要从健康副本复制，校验阵列通常要从多个存活成员读取并计算缺失内容。重建会消耗磁盘读写、接口带宽和处理资源，恰好与前台业务争用这些资源。故障前看起来空闲的阵列，重建时可能迅速接近饱和。

写入惩罚用于描述维护冗余带来的额外后端工作。以 RAID 5 的某次小块覆盖为例，常见的读改写路径需要读取旧数据与旧校验，计算变化，再写入新数据与新校验。这个简化模型涉及 2 次读取和 2 次写入，说明 1 次逻辑写入可能引出多次成员访问。它不是所有实现、所有请求都固定执行的公式；缓存合并、完整条带写入以及不同算法会改变实际路径。

RAID 6 的小写入还需要维护更多校验，RAID 10 则主要把数据写往镜像成员。比较时必须同时给出请求大小、读写比例和是否要求持久化。连续写入大文件与数据库持续覆盖 8 KiB 页面，即便逻辑带宽相同，也可能有很不一样的成员访问次数和尾延迟。只拿盘数乘单盘顺序速度，会忽略最主要的工作量。

写入完成的含义也需要明确。数据可能只到达控制器缓存，还没有进入断电后能保存的介质。带有有效掉电保护的写缓存能够在约定范围内保护未落盘数据；保护失效时，有些系统会切换成更保守的写入策略，性能随之下降。CPU 旁的普通 DRAM、控制器缓存和 SSD 内部缓存属于不同位置，不能因为设备都带“缓存”就认定它们具有相同的持久性。

重建还会集中读取平时很少访问的区域，暴露潜伏的不可读扇区或另一块盘的问题。在已用尽冗余的阵列中，额外读取失败可能造成部分数据不可恢复，具体影响取决于布局与实现。定期巡检、介质检查和一致性检查有助于提前发现问题，但检查本身也占用资源；它们不能保证未来没有故障，更不能代替独立备份。

4 动手：估算一次重建窗口

先做纸面估算，再决定测什么。假设某服务器使用 6 块 8 TB SATA 机械盘组成 RAID 6，单盘接在 6 Gb/s SATA 链路上，背板连接到主板上的存储适配器，适配器经 PCIe 接入系统。阵列理论容量为 32 TB。这里的 6 Gb/s 是链路标称速率，不能直接当作每块机械盘的重建速度，更不能当作整个重建流程的有效进度。

我们假设此次实现需要重建完整的 8 TB 成员空间，有效进度相当于每秒完成 100 MB 的目标成员内容。最基础估算是 T = D ÷ B：8 × 10¹² B ÷ (100 × 10⁶ B/s) = 80000 s，约为 22.2 h。这个 B 是实际重建有效速率，已经包含其他成员读取、目标写入及竞争的结果；若只测到某块源盘的读取速度，不能直接代入。

如果前台业务占用增大，使有效速率下降到 50 MB/s，估算时间就变成约 44.4 h。反过来，200 MB/s 对应约 11.1 h。真正需要重建的范围因实现不同，可能与已分配区域有关，也可能接近完整成员容量，所以必须从设备文档和实测确认 D 的含义。不能看见文件只用了 20% 就认定重建时间也只要原来的 20%。

这个交互把有效速率作为输入，让你观察容量与窗口之间的比例关系。提高重建优先级有机会缩短窗口，却可能挤压业务；降低优先级有机会改善前台响应，却会延长冗余不足的持续时间。优先级与有效速率并非线性对应，因此界面不会把“优先级 50%”直接换算成“速度 50%”。真正的策略要用业务延迟和进度共同约束。

实际动手应选择有备份、允许破坏的测试环境，记录盘型号类别、容量、布局、固件或软件版本、写缓存保护状态和前台负载。先测正常状态，再按实现支持的方式模拟成员离线，确认告警与降级状态，最后接入替换成员观察重建。不要在承担唯一数据副本的机器上临时拔盘试验，也不要依靠盘位灯颜色猜测成员身份。必须核对槽位、序列号与逻辑成员映射。

采样时同时记录已完成百分比、经过时间、业务吞吐、p95 与 p99 延迟、成员错误计数。p99 表示约 99% 请求的延迟不超过该值，是观察慢请求尾部的常见指标。用最近 30 min 的进度估算剩余时间，比只看起步阶段更有意义，但仍要保留负载波动余量。最终交付应包含实测范围，例如“相同负载下约 20–30 h”，并写明测试条件，避免把 22.2 h 当成设备保证。

5 硬件 RAID 与软件 RAID 边界

硬件 RAID 通常由专用控制器组织成员盘，向操作系统呈现逻辑盘。控制器可能安装在 PCIe 插槽上，也可能集成在主板相关模块中；机箱背板负责连接，带扩展功能的背板还会影响共享带宽和故障范围。控制器可提供缓存、掉电保护和管理接口，但它本身也成为需要监控、维护和准备恢复办法的部件。

软件 RAID 由操作系统中的软件组织成员，通常通过能够直通成员设备的存储适配器访问硬盘。计算使用主机 CPU，管理状态可以与系统工具结合，迁移也常能避开对某款专用控制器的依赖。不过它仍然依赖驱动、启动环境、成员元数据和正确配置。现代 CPU 能做校验，并不等于软件方案无需性能评估；高负载下还要观察处理资源与 I/O 是否相互竞争。

采用 NVMe SSD 时，数据通常经 PCIe 通道访问，而 SATA、SAS 盘有各自的连接体系。服务器有多少盘位、主板提供多少通道、插槽电气宽度是多少、适配器支持什么设备，都会限制可实施的布局。外形能够装入不代表协议能够兼容；也不能因为机器标注支持热插拔，就假定任意接口、任意操作系统配置都允许带电移除。

选型重点是让责任可验证。系统能否看到每块盘的健康信息？掉电保护失效是否告警？控制器损坏后能否找到兼容替换设备并导入阵列？软件系统重装后能否识别成员，启动盘失效时从哪里恢复配置？恢复步骤如果只掌握在某个人记忆里，硬件与软件方案都会留下同样的运维缺口。

还要确认文件系统或上层存储是否自己管理冗余和数据校验。把多个保护层直接叠加，可能造成容量浪费、错误信息不透明和恢复路径复杂。应当按上层系统的要求暴露物理盘或逻辑盘，并明确由哪层负责冗余、完整性检查和故障替换。对端到端校验、写入原子性和复杂文件系统恢复，本课只建立问题边界，后续再深入。

6 常见坑：把 RAID 当备份

RAID 主要帮助系统在某些成员故障后继续访问当前数据；备份则需要保留能够独立恢复的数据副本，通常还要有历史版本。管理员误删目录、程序把有效内容覆盖成空值、恶意软件加密文件时，阵列会努力保存这次写入。镜像和校验都不会自动知道“昨天的数据才是想要的”。因此阵列健康与数据正确是 2 个不同问题。

同机快照可以为误操作恢复提供方便，但若快照与原数据依赖同一组盘、同一控制器或同一管理权限，就仍然共享故障范围。备份设计要考虑副本所在位置、保留时间、访问权限和恢复工具。异机副本减少整机故障影响，异地副本减少场地故障影响，受保护的历史版本帮助处理延迟发现的错误；这些作用不能由增加本地 RAID 级别来自动获得。

热备盘也常被误解。热备是可被系统接管用于替换故障成员的备用设备，能减少等待人工装盘的时间；它本身通常不会提高当前布局允许同时失效的成员数。RAID 5 配 1 块热备，并不会立刻获得 RAID 6 的双成员故障容忍。系统必须先识别故障并完成足够的重建，才能重新获得原有冗余。

另一种坑是混淆健康告警。盘的介质错误、链路重置、温度过高和控制器超时可能表现为相似的 I/O 失败。看到某槽位离线就立刻反复换盘，可能忽略坏线缆或背板问题。应保留事件时间、设备身份和错误类型，把多盘同时失联与单盘介质错误分开分析；在冗余不足时拔错健康成员，会把可恢复故障变成数据丢失。

备份的有效性最终取决于恢复。定义恢复点目标 RPO，即最多能接受丢失多长时间的数据；定义恢复时间目标 RTO，即最多能接受多久不可用。然后实际恢复到隔离环境，确认数据可读、应用可启动、权限与密钥可用。RAID 重建时间、备份恢复时间和业务恢复时间往往不同，方案不能只填其中最短的数字。

7 案例：重建期尾延迟雪崩

某台 2U 数据库服务器使用 8 块 8 TB 机械盘组成 RAID 6，配有 128 GiB 内存和 10 GbE 网络。业务以 8 KiB 随机读写为主，正常时 p99 为 25 ms，峰值吞吐约 800 次请求/s。某块盘离线后，替换盘立即开始高优先级重建。业务吞吐最初只略有下降，值班人员以为影响有限；随后 p99 升到 900 ms，客户端大量超时并重试。

关键并不在网络标称带宽。重建持续读取存活成员，前台请求等待介质服务的时间变长；数据库持久化写入也需要等待，连接被占用更久。超时重试继续增加进入系统的请求，排队增长，更多请求超过截止时间。吞吐指标可能暂时没有明显下降，用户感受到的慢请求比例却已经恶化。缓存命中较高的平均延迟还可能掩盖这部分变化。

定位时先把故障、重建启动、延迟变化与重试增长放到相同时间轴。观察成员忙碌情况、队列等待、重建进度和控制器错误，再对照 CPU、内存与网络状态。如果 CPU 很空闲、网卡带宽很低，而成员设备持续忙碌且等待上升，就有理由优先检查存储争用；这仍是证据方向，需要通过受控调整验证，不能只凭某个利用率数字下结论。

处置先控制请求放大：限制不必要的重试、降低非关键批处理并发、让进入系统的请求量回到可服务范围。随后根据设备支持情况降低重建优先级，观察 p99 是否恢复，并重新估算完成时间。必要时将部分读取转移到已经验证可用的副本。每次只做能够解释的调整，保留前后指标；不要为了暂时改善吞吐关闭持久化保障或随意切换不受保护的写缓存。

这个案例的验收不是“重建终于完成”。还要确认重建结束后阵列恢复预期冗余、业务延迟回落、错误计数没有持续增长，并验证告警确实覆盖降级和进度停滞。后续容量规划应预留故障期间的服务能力，压测也要包含降级与重建场景。正常状态跑满的配置，通常缺少应对故障后台工作的余量。

8 把阵列设计写进可靠性方案

可靠性方案先写工作负载：数据量及增长、读写比例、请求大小、随机或顺序访问、峰值并发，以及写入何时必须持久化。再写服务目标，例如在约定业务负载下 p99 不超过 100 ms，单成员故障后仍能提供核心服务。阈值是场景要求，不能照搬示例。目标越具体，布局选择、设备数量和重建策略就越容易验证。

接着给出容量账本。以 8 块 8 TB 盘的 RAID 6 为例，原始容量 64 TB，理论阵列容量 48 TB；若额外配置 1 块专用热备，就需要第 9 个盘位，不能把它算进这 48 TB。之后继续扣除文件系统开销与业务预留，并说明增长到什么程度要扩容。扩容是否支持在线进行、持续多久、期间有什么风险，也应在采购前查清楚。

然后写故障矩阵。单盘坏了由谁收到告警，多久识别、多久替换；控制器坏了用什么设备导入，配置存在哪里；整机不可用时服务转移到哪里；误删时恢复哪个时间点。每种故障都对应检测、处置、恢复和验收。不要只写“支持高可靠”，也不要把 RAID 6 的双盘容忍扩大成“任意 2 个部件失效都安全”。

监控需要跨层连接：业务侧记录超时率与 p99，系统侧记录 I/O 等待与设备队列，阵列侧记录成员状态、介质错误、缓存保护和重建进度。告警应该指向行动，例如“降级超过约定时间仍无替换安排”或“持续有业务请求但重建进度停滞”。单纯每天发送健康截图，无法确保有人在危险窗口内采取措施。

最后安排演练和变更记录。演练验证恢复步骤、备件匹配和备份可恢复性；变更记录保存槽位映射、布局参数、版本和策略。更换磁盘、调整重建速率、更新控制器固件都会改变运行条件，必须重新确认相关结论是否仍成立。可靠性方案的价值在于让下一位接手的人可以照着操作，并知道何时需要停止操作、升级处理。

9 从阵列走向数据库原理（S41）

阵列向上提供逻辑块读写，数据库向用户提供记录、查询与事务。块设备能够继续工作，不代表数据库就能在任意断电时保持业务规则正确。例如转账涉及多个页面，阵列无法从块写入中理解“扣款与入账必须共同完成”。它也不能替数据库决定哪些更新已经提交，哪些更新需要撤销。

数据库因此需要自己的恢复机制。后续 S41 会讨论日志、事务和页面组织，本课先抓住接口边界：数据库可能要求某些日志先持久化，再确认提交；操作系统和存储路径需要正确传递相应要求。若某层把尚未得到可靠保护的数据当成已经持久化，上层恢复承诺就可能落空。RAID、文件系统与数据库各有职责，它们必须通过一致的持久化语义衔接。

阵列布局也会影响数据库看到的性能。相同的逻辑写入，在镜像与校验布局中可能触发不同的成员工作量；数据文件、日志与检查点又会形成不同访问模式。把日志和数据划成同 1 组物理盘上的不同逻辑卷，管理上更清楚，却不一定带来独立的性能或故障隔离。要判断是否独立，必须追踪到底层盘、控制器和供电，而不能只看卷名。

进入 S41 前，应能够解释 3 件事：阵列为什么能在某些盘失效后读出数据；为什么重建会影响正常业务；为什么仍然需要数据库恢复与独立备份。你不必现在推导双校验算法，也不必研究控制器固件内部流程。先把容量公式、故障组合、时间窗口和持久化边界说准确，后续学习数据库日志与恢复时，就能分清问题发生在哪一层。

放进方案里

为 1 台承载内部资料库的 2U 服务器编写存储条目：主机配置 128 GiB 内存、2 个 10 GbE 网口，提供 12 个前置盘位；拟用 8 块 8 TB 硬盘组成 RAID 6，另配 1 块热备。写清原始成员容量为 64 TB，理论阵列容量为 48 TB，热备占用额外盘位，业务配额还要扣除格式化开销并保留增长余量。附上背板、适配器和槽位连接关系，确认接口兼容及管理工具能够定位成员。

业务条目记录主要为小块随机读写，给出峰值请求量、持久化要求和可接受的 p99。测试必须覆盖正常、单成员离线与重建 3 种状态。先用 8 TB 和实测有效速率估算重建窗口，再记录高峰负载下的变化范围；如果前台延迟超标，明确允许降低哪些批处理并发，以及谁可以调整重建优先级。调整后同时检查业务响应和剩余窗口。

恢复条目分别处理成员损坏、控制器损坏、整机失联和误删。为每项列出告警接收人、备件位置、恢复步骤与验收证据；换盘前核对序列号和槽位，重建后确认冗余恢复。独立备份保留历史版本，按业务约定填写 RPO 与 RTO，并通过隔离恢复证明资料能打开、权限能恢复、数据库能启动。

交付时提供容量表、故障矩阵、压测曲线与恢复记录。验收重点包括降级告警是否到达、重建期间延迟是否达标、进度停滞能否发现，以及备份恢复是否满足目标。另附热备接管记录，核验其容量不小于成员有效容量、接口兼容且确实加入重建；保存接管前后的成员序列号、状态与时间戳。验收还需确认缓存掉电保护有效，保护失效时能够告警并按设计切换写入策略，保留事件日志及策略查询结果作为证据。若测试未通过，应缩减承载量或调整设计，并把未解决的限制写进运行约束，不能用“已配置 RAID 6”代替可靠性结论。

10 小结：下一步数据库原理（S41）

RAID 用条带、镜像和校验组织多块盘，在容量、性能与成员故障容忍之间取舍。布局决定允许失效的组合，重建决定冗余不足窗口持续多久，实际业务决定额外后台工作是否会造成排队和超时。选型要同时检查盘、链路、控制器、缓存保护和恢复路径。

带着 3 个问题进入 S41：写入返回成功时数据到达了哪里？多个页面的更新如何共同完成？断电重启后如何识别已提交的事务？阵列提供底层存储能力，数据库将在这个基础上组织日志、事务和恢复。