企业官网建设流程全解析

1. 为什么第七章要单独讲硬件与RAID：从一次磁盘告警说起

很多做运维的朋友跟我聊过一个共同的困惑：Linux 系统装好、服务跑起来之后，日常操作无非是敲命令、看日志、改配置，感觉硬件离自己很远。直到某天凌晨收到一条磁盘空间告警，或者更糟——服务器直接卡死、系统盘报 I/O 错误，才意识到底层硬件和磁盘阵列才是所有服务的命根子。我印象很深的一次，某台跑了两年多的业务机突然读写延迟飙升，登录上去一看，dmesg里刷满了磁盘重映射扇区的记录，单盘已经处在半残状态。当时如果这台机器做了合理的 RAID 配置，换盘重建就能平滑过渡；偏偏它是单盘直挂，最后只能停机迁移数据，折腾了整整一个通宵。

这就是我把“Linux 服务器硬件及 RAID 配置实战”单独拎出来讲的原因。这一章的核心不是教你背命令，而是让你建立一套从物理磁盘到逻辑卷、从单盘故障到阵列冗余的完整认知。它解决的是“服务器磁盘怎么选、怎么组、怎么配、坏了怎么救”这一整条链路的问题，适合刚接触服务器运维的新手，也适合那些平时只碰应用层、想补齐底层知识的老手。你不需要有深厚的硬件背景，只要会用 Linux 基本命令，跟着思路走就能把一台机器的存储骨架搭起来。

我下面讲的内容，会围绕硬件选型的判断逻辑、RAID 级别的取舍、mdadm的实操配置、故障模拟与恢复这几个主线展开。所有参数和步骤都来自实际项目里的常见做法，涉及具体数值的地方我会把计算过程写清楚，方便你直接抄作业或者按自己的场景调整。

2. 服务器硬件认知：先搞清楚你手里这台机器有什么

2.1 磁盘类型与接口：SATA、SAS、NVMe 到底怎么选

动手配 RAID 之前，得先弄明白服务器上插的是什么盘。这一步很多人跳过，结果买回来的盘和背板不兼容，或者组了阵列才发现性能瓶颈根本不在盘上。常见的服务器磁盘按接口分三类，我做个对照表，方便你快速判断。

选型的核心逻辑是按 IO 特征匹配介质。数据库的随机小 IO 多，机械盘再组 RAID 也救不了随机性能，这时候 NVMe 或者企业级 SATA 固态才是正解；而归档、备份这类顺序大 IO 场景，大容量机械盘组 RAID 5/6 性价比最高。我见过不少项目为了省钱全上机械盘跑数据库，最后靠加内存做缓存硬扛，本质上是拿应用层补硬件的坑，长期看并不划算。

还有一个容易被忽略的点是盘的固件和批次。同一批 RAID 里的盘，最好型号、容量、固件版本一致，否则重建时容易出现兼容性问题。我踩过一次坑：阵列里混插了两批不同固件的同型号盘，平时没事，一块盘坏了触发重建，结果重建到一半另一块盘因为固件差异响应超时被踢出阵列，直接双盘失效。所以采购时尽量一次性买足同批次备盘，这个经验值不少钱。

2.2 看清磁盘现状：lsblk、smartctl 与 dmesg 三件套

盘插好了，第一步不是急着组阵列，而是先摸清家底。我习惯用三个工具交叉确认：lsblk看拓扑结构，smartctl看健康状态，dmesg看内核有没有报错。

# 查看块设备树状结构，确认盘符和容量 lsblk -o NAME,SIZE,TYPE,ROTA,MODEL # 查看某块盘的 SMART 健康信息（需安装 smartmontools） smartctl -a /dev/sdb # 过滤内核日志中的磁盘相关告警 dmesg | grep -iE "error|fail|remap|ata"

lsblk里的ROTA字段很实用，值为 1 表示机械盘，0 表示固态，一眼就能区分。smartctl重点看Reallocated_Sector_Ct（重映射扇区数）和Pending_Sector（待映射扇区），这两个值只要非零就要警惕，说明盘已经在带病工作。dmesg则能抓到链路层的错误，比如 SATA 链路降速、CRC 校验错误，这类问题往往是线缆或背板接触不良，换根线可能就解决了，不一定非要换盘。

提示：新盘上架前建议先跑一遍 SMART 短自检（smartctl -t short /dev/sdX），等几分钟后看结果，能提前筛掉运输途中受损的盘。这个习惯帮我拦下过好几块“开箱即坏”的盘。

2.3 硬件 RAID 与软件 RAID 的分界线

服务器上做 RAID 有两条路：硬件 RAID 卡和 Linux 自带的软件 RAID（mdadm）。这两者的取舍是很多人纠结的地方，我把判断依据列清楚。

硬件 RAID 卡的优势是卸载 CPU 开销、带电池缓存、支持在线扩容和热备，对数据库这类写敏感场景友好，因为带 BBU（电池备份单元）的写缓存可以开启 Write-Back 模式，大幅提升写性能。缺点是成本高，而且一旦 RAID 卡故障，换卡必须同型号或者能导入外部配置，否则阵列信息可能丢失，恢复起来很麻烦。

软件 RAID 的优势是免费、灵活、盘符可移植，阵列信息写在每块盘的超级块里，换台机器把盘插上去就能重新组装，不依赖特定控制器。缺点是消耗 CPU（现代 CPU 其实影响很小）、不支持电池缓存，写性能在特定模式下不如硬件卡。

我的经验判断是：业务机、数据库机优先硬件 RAID 卡，尤其是对写延迟敏感的场景；文件服务器、备份机、测试环境用软件 RAID 完全够用，而且迁移和维护更省心。这一章后面的实操我以软件 RAID 为主线，因为它的原理透明、命令可复现，学会了再去看硬件 RAID 卡的配置界面，逻辑是相通的。

3. RAID 级别取舍：不是级别越高越好

3.1 常见 RAID 级别的容量与冗余计算

RAID 的本质是用冗余换安全、用并行换性能。不同级别对应不同的取舍，我把最常用的几个级别整理成表，容量计算以 4 块 4TB 盘为例。

容量计算的通用公式要记牢：RAID 5 可用容量 =（盘数 - 1）× 单盘容量；RAID 6 =（盘数 - 2）× 单盘容量；RAID 10 =（盘数 / 2）× 单盘容量。这里有个关键点很多人忽略——RAID 5 的写惩罚。每次写操作要读旧数据、读旧校验、算新校验、写新数据、写新校验，实际产生 4 次 IO，所以写密集场景 RAID 5 会明显拖后腿。RAID 6 更狠，写惩罚达到 6 次。这就是为什么数据库我强烈建议 RAID 10，虽然容量利用率只有 50%，但写性能是实打实的。

3.2 大容量盘时代，RAID 5 为什么越来越不推荐

早些年 500GB、1TB 的盘组 RAID 5 很常见，但现在单盘动辄 8TB、16TB，RAID 5 的风险被放大了。原因在于重建时间。一块 16TB 的盘重建，按 150MB/s 的速率算，理论时间约 16×1024×1024/150/3600 ≈ 31 小时，实际因为业务 IO 竞争往往要 40 小时以上。在这几十个小时里，阵列处于无冗余状态，剩下任何一块盘出现不可恢复读错误（URE），整个阵列就崩了。

企业级盘的 URE 率典型值是每读取 10^15 位出现一次错误，换算下来大约每读 125TB 数据遇到一个坏块。16TB 盘重建要读满整盘数据，撞上 URE 的概率并不低。所以我的建议是：单盘容量超过 4TB 的场景，优先 RAID 6 或 RAID 10，别再用 RAID 5 赌运气。RAID 6 虽然写性能差些，但能扛住重建期间的第二块盘故障，对大容量归档场景是更稳妥的选择。

3.3 热备盘与阵列布局的实战考量

热备盘（hot spare）是很多人配 RAID 时容易漏掉的一环。它的作用是：阵列里某块盘坏了，热备盘自动顶上去开始重建，不需要人工干预，缩短无冗余窗口。对于无人值守的机房或者异地服务器，热备盘几乎是必配的。

布局上有个细节：热备盘最好和阵列盘接在不同的背板或控制器通道上，避免背板整体故障时热备盘跟着一起挂。另外，全局热备盘（global spare）可以被同一控制器下的多个阵列共享，专用热备盘（dedicated spare）只服务特定阵列，盘数紧张时用全局热备更灵活。我一般建议至少留一块热备盘，盘数充裕的话按阵列数量配。

4. mdadm 软件 RAID 实操：从零组一个 RAID 10

4.1 环境准备与分区规划

假设我们有一台测试机，4 块 4TB 的 SATA 盘，盘符是/dev/sdb到/dev/sde，准备组一个 RAID 10 作为数据盘。先确认盘的状态，确保没有被挂载或已有分区。

# 确认四块盘都是干净的，没有分区表和挂载 lsblk /dev/sdb /dev/sdc /dev/sdd /dev/sde # 如果盘上有旧分区，先清理（谨慎操作，确认盘符无误） wipefs -a /dev/sdb /dev/sdc /dev/sdd /dev/sde

这里我倾向于直接用整盘做 RAID 成员，而不是先分区。原因有两个：一是整盘使用没有分区表对齐的烦恼，mdadm会自动处理；二是后期换盘时直接整盘替换，操作更简单。当然，如果你的场景需要在一部分盘上留空间做其他用途，那就先分区再用分区做成员，但要注意分区类型标记为fd（Linux raid autodetect）。

安装mdadm工具：

# Debian/Ubuntu 系 apt install -y mdadm # RHEL/CentOS 系 yum install -y mdadm

4.2 创建 RAID 10 阵列并验证

创建 RAID 10 的命令如下，--level=10指定级别，--raid-devices=4指定成员盘数，--chunk=512指定条带大小（单位 KB）。

mdadm --create /dev/md0 --level=10 --raid-devices=4 \ --chunk=512 /dev/sdb /dev/sdc /dev/sdd /dev/sde

chunk这个参数值得说道说道。它决定了一个条带块的大小，直接影响 IO 分布。大块顺序 IO 场景（如视频、备份）用大 chunk（512KB-1MB），能让单次 IO 尽量落在同一块盘上，减少跨盘寻址；小随机 IO 场景（如数据库）用小 chunk（64KB-128KB），让 IO 更均匀地分散到多块盘，提升并行度。默认值 512KB 对通用场景够用，数据库场景我会调到 128KB 甚至 64KB。

创建后立刻查看阵列状态：

cat /proc/mdstat # 输出示例： # md0 : active raid10 sde[3] sdd[2] sdc[1] sdb[0] # 8388608 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU] # [=>...................] resync = 5.2% (436000/8388608) finish=12.3min speed=10000K/sec

刚创建时阵列会做一次初始同步（resync），[UUUU]表示四块盘都在线。同步期间可以正常使用，但性能会受影响，生产环境建议在业务低峰期创建。同步完成后用mdadm --detail看详细信息：

mdadm --detail /dev/md0

重点看State（应为 clean）、Raid Level、Array Size、Chunk Size和每块盘的State（应为 active sync）。容量核对一下：4 块 4TB 盘组 RAID 10，可用容量应该是 8TB 左右，如果显示 16TB 说明级别配错了。

4.3 文件系统创建与挂载持久化

阵列建好后要格式化文件系统。数据盘我一般用 XFS，大文件和高并发场景表现稳定；如果是小文件多或者需要快照，可以考虑 ext4 或 btrfs。

# 创建 XFS 文件系统 mkfs.xfs /dev/md0 # 创建挂载点并挂载 mkdir -p /data mount /dev/md0 /data # 查看挂载结果和可用容量 df -h /data

持久化挂载要写进/etc/fstab，但千万别直接写/dev/md0，因为阵列组装顺序变化时盘符可能漂移。正确做法是写 UUID：

# 获取文件系统 UUID blkid /dev/md0 # 输出类似：/dev/md0: UUID="xxxx-xxxx" TYPE="xfs" # 写入 fstab echo 'UUID=xxxx-xxxx /data xfs defaults 0 0' >> /etc/fstab

还有一个关键步骤很多人漏掉：保存阵列配置到配置文件，否则重启后阵列可能不会自动组装。

# 扫描当前阵列配置并写入 /etc/mdadm/mdadm.conf（Debian 系） mdadm --detail --scan >> /etc/mdadm/mdadm.conf # RHEL 系路径是 /etc/mdadm.conf # 更新 initramfs，确保开机时能识别阵列 update-initramfs -u # Debian/Ubuntu dracut -f # RHEL/CentOS

注意：mdadm.conf里记录的是阵列 UUID 和成员盘信息，换盘重建后要重新扫描更新，否则下次重启可能因为成员盘列表过期导致组装失败。这个坑我在一次换盘后重启时踩过，机器直接进了紧急模式，排查了半天才发现是配置文件没更新。

5. 故障模拟与恢复：把演练做在出事之前

5.1 手动标记故障盘并观察降级状态

配好阵列不算完，真正的价值在于故障发生时你能从容处理。我强烈建议在测试环境做一次完整的故障演练，把流程走熟。模拟一块盘故障：

# 将 /dev/sdc 标记为故障 mdadm /dev/md0 --fail /dev/sdc # 查看阵列状态，应显示降级 cat /proc/mdstat # md0 : active raid10 sde[3] sdd[2] sdb[0] # 8388608 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]

[UU_U]里的下划线就表示有一块盘失效，阵列进入 degraded（降级）状态。此时数据仍然可读可写，但已经没有完整冗余了。接着把故障盘移除：

mdadm /dev/md0 --remove /dev/sdc

移除后可以物理拔盘（支持热插拔的背板），换上新盘。新盘插上后先确认被系统识别（lsblk能看到新盘符），然后加入阵列：

# 假设新盘是 /dev/sdc mdadm /dev/md0 --add /dev/sdc

加入后阵列自动开始重建，/proc/mdstat里会显示重建进度。重建期间业务可以继续跑，但性能会下降，尽量避开高峰期操作。

5.2 重建进度监控与常见卡顿排查

重建是个耗时过程，监控进度用：

watch -n 5 cat /proc/mdstat

如果发现重建速度异常慢（比如只有几 MB/s），常见原因有几个。一是重建限速，内核默认对重建速率有限制，可以临时调高：

# 查看当前限速（单位 KB/s） cat /proc/sys/dev/raid/speed_limit_max cat /proc/sys/dev/raid/speed_limit_min # 临时调高最大重建速率到 200MB/s echo 200000 > /proc/sys/dev/raid/speed_limit_max

二是业务 IO 竞争，重建和业务抢磁盘带宽，这时候要么错峰，要么接受慢速。三是盘本身有问题，新盘如果有坏道，重建会反复重试甚至失败，这时候要看dmesg和smartctl确认。我遇到过一次重建卡在 30% 不动，查下来是新盘固件有 bug，换了块盘才解决。

5.3 阵列信息恢复与紧急组装

最坏的情况是系统重装或者换机器，阵列信息还在盘上但系统不认识。这时候用mdadm --assemble手动组装：

# 扫描所有盘上的阵列信息 mdadm --examine --scan # 按扫描结果组装（--scan 会自动读取配置） mdadm --assemble --scan # 如果自动组装失败，指定成员盘强制组装 mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd /dev/sde

如果连超级块都读不出来，那基本只能靠数据恢复工具了，这也是为什么我一直强调重要数据要有阵列之外的第二份备份。RAID 解决的是硬件故障导致的服务中断，不是误删、勒索、机房事故的万能药。3-2-1 备份原则（3 份数据、2 种介质、1 份异地）该做还得做。

6. 实操心得与避坑清单

6.1 那些文档里不会写的经验

做了这么多台机器的存储配置，有几个心得是踩坑踩出来的，写在这里给后来人省点时间。

第一，新盘上架先做全盘写测试。用badblocks -w或者fio跑一遍全盘写，能提前暴露盘的隐性缺陷。这个过程对新盘是“烤机”，虽然耗时（4TB 盘大概几小时），但比上线后重建时才发现坏道强太多。我现在的习惯是采购回来的盘先在测试机上烤一遍再上生产。

第二，RAID 成员盘不要跨控制器混用。软件 RAID 虽然不依赖特定卡，但如果成员盘分散在不同控制器上，某个控制器故障可能导致多块盘同时掉线，超出冗余能力。尽量让同一阵列的盘接在同一背板或控制器下。

第三，监控要覆盖阵列状态。/proc/mdstat的变化、SMART 的关键指标、dmesg的磁盘错误，都应该纳入监控告警。我见过阵列降级了半个月没人发现，直到第二块盘也坏了才炸出来，那时候已经回天乏术。简单的做法是写个脚本定时检查mdadm --detail的State字段，非clean就告警。

第四，换盘后记得更新 mdadm.conf 并重建 initramfs。前面提过这个坑，换盘重建完成后，成员盘的 UUID 列表变了，配置文件不更新的话下次重启可能组装失败。养成换盘后执行mdadm --detail --scan > /etc/mdadm/mdadm.conf再update-initramfs -u的习惯。

6.2 常见问题速查表

6.3 硬件与 RAID 配置的检查清单

最后给一份上架前的检查清单，照着过一遍能避开大部分低级错误。盘的健康状态用 SMART 确认无重映射扇区；阵列级别按 IO 特征选，数据库 RAID 10、归档 RAID 6；chunk 大小按 IO 类型调，随机小 IO 用小 chunk；热备盘至少配一块；fstab 用 UUID 挂载；mdadm.conf 保存并更新 initramfs；监控覆盖阵列状态和 SMART 指标；重要数据在阵列之外另有备份。

这套流程走下来，一台机器的存储底座就算搭稳了。后面无论上面跑什么服务，至少底层不会成为那个半夜把你叫醒的短板。我个人在实际操作中的体会是，硬件和 RAID 这块知识，看十遍文档不如亲手组一次阵列、模拟一次故障、走一遍恢复流程。演练时流的汗，都是生产环境里省下的泪。