1. 为什么第七章要单独讲硬件与RAID从一次磁盘告警说起很多做运维的朋友跟我聊过一个共同的困惑Linux 系统装好、服务跑起来之后日常操作无非是敲命令、看日志、改配置感觉硬件离自己很远。直到某天凌晨收到一条磁盘空间告警或者更糟——服务器直接卡死、系统盘报 I/O 错误才意识到底层硬件和磁盘阵列才是所有服务的命根子。我印象很深的一次某台跑了两年多的业务机突然读写延迟飙升登录上去一看dmesg里刷满了磁盘重映射扇区的记录单盘已经处在半残状态。当时如果这台机器做了合理的 RAID 配置换盘重建就能平滑过渡偏偏它是单盘直挂最后只能停机迁移数据折腾了整整一个通宵。这就是我把“Linux 服务器硬件及 RAID 配置实战”单独拎出来讲的原因。这一章的核心不是教你背命令而是让你建立一套从物理磁盘到逻辑卷、从单盘故障到阵列冗余的完整认知。它解决的是“服务器磁盘怎么选、怎么组、怎么配、坏了怎么救”这一整条链路的问题适合刚接触服务器运维的新手也适合那些平时只碰应用层、想补齐底层知识的老手。你不需要有深厚的硬件背景只要会用 Linux 基本命令跟着思路走就能把一台机器的存储骨架搭起来。我下面讲的内容会围绕硬件选型的判断逻辑、RAID 级别的取舍、mdadm的实操配置、故障模拟与恢复这几个主线展开。所有参数和步骤都来自实际项目里的常见做法涉及具体数值的地方我会把计算过程写清楚方便你直接抄作业或者按自己的场景调整。2. 服务器硬件认知先搞清楚你手里这台机器有什么2.1 磁盘类型与接口SATA、SAS、NVMe 到底怎么选动手配 RAID 之前得先弄明白服务器上插的是什么盘。这一步很多人跳过结果买回来的盘和背板不兼容或者组了阵列才发现性能瓶颈根本不在盘上。常见的服务器磁盘按接口分三类我做个对照表方便你快速判断。接口类型典型转速/介质顺序读写量级适用场景注意事项SATA机械 7200rpm / 固态机械约 150-200MB/s固态约 500MB/s冷数据、备份、预算有限的业务盘接口便宜但机械盘随机 IO 弱不适合高并发数据库SAS机械 10K/15K rpm机械约 200-250MB/s传统企业级业务、虚拟化宿主机需 SAS 控制器盘和背板要匹配热插拔支持好NVMe固态单盘可达 3-7GB/s高并发数据库、缓存层、日志盘走 PCIe 通道注意主板通道数和散热选型的核心逻辑是按 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|atalsblk里的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 自带的软件 RAIDmdadm。这两者的取舍是很多人纠结的地方我把判断依据列清楚。硬件 RAID 卡的优势是卸载 CPU 开销、带电池缓存、支持在线扩容和热备对数据库这类写敏感场景友好因为带 BBU电池备份单元的写缓存可以开启 Write-Back 模式大幅提升写性能。缺点是成本高而且一旦 RAID 卡故障换卡必须同型号或者能导入外部配置否则阵列信息可能丢失恢复起来很麻烦。软件 RAID 的优势是免费、灵活、盘符可移植阵列信息写在每块盘的超级块里换台机器把盘插上去就能重新组装不依赖特定控制器。缺点是消耗 CPU现代 CPU 其实影响很小、不支持电池缓存写性能在特定模式下不如硬件卡。我的经验判断是业务机、数据库机优先硬件 RAID 卡尤其是对写延迟敏感的场景文件服务器、备份机、测试环境用软件 RAID 完全够用而且迁移和维护更省心。这一章后面的实操我以软件 RAID 为主线因为它的原理透明、命令可复现学会了再去看硬件 RAID 卡的配置界面逻辑是相通的。3. RAID 级别取舍不是级别越高越好3.1 常见 RAID 级别的容量与冗余计算RAID 的本质是用冗余换安全、用并行换性能。不同级别对应不同的取舍我把最常用的几个级别整理成表容量计算以 4 块 4TB 盘为例。RAID 级别最少盘数可用容量4×4TB容错能力读性能写性能典型场景RAID 0216TB无坏一块全丢最高最高临时数据、缓存绝不用于生产RAID 124TB两块盘时坏一块高中系统盘、小容量高可靠场景RAID 5312TB坏一块高中低写惩罚文件服务器、读多写少业务RAID 648TB坏两块高低双校验写惩罚大容量归档、重建风险高的场景RAID 1048TB每组坏一块最高高数据库、高并发业务容量计算的通用公式要记牢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、16TBRAID 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 104.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会自动处理二是后期换盘时直接整盘替换操作更简单。当然如果你的场景需要在一部分盘上留空间做其他用途那就先分区再用分区做成员但要注意分区类型标记为fdLinux raid autodetect。安装mdadm工具# Debian/Ubuntu 系 apt install -y mdadm # RHEL/CentOS 系 yum install -y mdadm4.2 创建 RAID 10 阵列并验证创建 RAID 10 的命令如下--level10指定级别--raid-devices4指定成员盘数--chunk512指定条带大小单位 KB。mdadm --create /dev/md0 --level10 --raid-devices4 \ --chunk512 /dev/sdb /dev/sdc /dev/sdd /dev/sdechunk这个参数值得说道说道。它决定了一个条带块的大小直接影响 IO 分布。大块顺序 IO 场景如视频、备份用大 chunk512KB-1MB能让单次 IO 尽量落在同一块盘上减少跨盘寻址小随机 IO 场景如数据库用小 chunk64KB-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) finish12.3min speed10000K/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: UUIDxxxx-xxxx TYPExfs # 写入 fstab echo UUIDxxxx-xxxx /data xfs defaults 0 0 /etc/fstab还有一个关键步骤很多人漏掉保存阵列配置到配置文件否则重启后阵列可能不会自动组装。# 扫描当前阵列配置并写入 /etc/mdadm/mdadm.confDebian 系 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 常见问题速查表现象可能原因排查与处理阵列创建后容量不对RAID 级别或成员盘数配错mdadm --detail核对 Raid Level 和 Array Size重启后阵列未自动组装mdadm.conf 未更新或 initramfs 未重建重新扫描配置并更新 initramfs重建速度极慢重建限速或业务 IO 竞争调高 speed_limit_max错峰操作重建中途失败新盘有坏道或固件问题查 dmesg 和 smartctl换盘重试阵列降级但无盘报错线缆或背板接触不良检查链路 CRC 错误换线换槽位挂载失败提示未知文件系统文件系统损坏或阵列未组装先确认阵列状态再尝试 xfs_repair6.3 硬件与 RAID 配置的检查清单最后给一份上架前的检查清单照着过一遍能避开大部分低级错误。盘的健康状态用 SMART 确认无重映射扇区阵列级别按 IO 特征选数据库 RAID 10、归档 RAID 6chunk 大小按 IO 类型调随机小 IO 用小 chunk热备盘至少配一块fstab 用 UUID 挂载mdadm.conf 保存并更新 initramfs监控覆盖阵列状态和 SMART 指标重要数据在阵列之外另有备份。这套流程走下来一台机器的存储底座就算搭稳了。后面无论上面跑什么服务至少底层不会成为那个半夜把你叫醒的短板。我个人在实际操作中的体会是硬件和 RAID 这块知识看十遍文档不如亲手组一次阵列、模拟一次故障、走一遍恢复流程。演练时流的汗都是生产环境里省下的泪。