4、硬件层故障处理：服务器宕机、网卡失效、磁盘故障的检测与自动切换，IPMI与BMC监控
硬件故障，说白了就是交易系统的「物理暴击」。
你代码写得再漂亮，算法再牛逼，服务器一冒烟，全白搭。我在低延迟交易这行干了快十年，见过最惨的一次——某家私募的行情服务器硬盘 quietly 挂了，BMC 报警没接，结果开盘后行情断层了 3 秒，那 3 秒的损失……嗯，够买一屋子硬盘了。
所以这一章，咱们就聊聊硬件层那点「要命的事」。
4.1 服务器宕机：从「冒烟」到「切换」的 500 毫秒
服务器宕机分两种：一种是彻底死透（硬件 watchdog 超时），一种是半死不活（OS 挂但硬件还在跑）。
我个人习惯，把这两种情况分开处理。
4.1.1 检测手段：不止是心跳
很多人以为心跳检测就够了。其实不够。
心跳只能告诉你「网络通不通」，但网络通不代表业务正常。我遇到过网卡驱动 bug，心跳包正常发，但 UDP 组播全丢了。
所以我的方案是三层检测：
- 硬件级：BMC 的 IPMI 传感器轮询（CPU 温度、电压、风扇转速）
- OS 级：内核 watchdog + 用户态心跳
- 业务级：行情序列号连续性检查（这个最准）
核心原则：不要依赖单一检测源。至少两个独立路径同时报警，才触发切换。
4.1.2 自动切换：Active-Standby 的坑
交易系统常用主备模式。但主备切换有个经典问题——「脑裂」。
为什么会这样？
主备之间心跳断了，备机以为主机挂了，自己升主。结果主机其实没挂，两个同时发单……交易所那边直接拒单，甚至可能被风控。
我建议的做法：
- 使用 Quorum 机制（仲裁节点），至少 3 个节点投票决定谁活
- 备机升主前，先通过 IPMI 强制重启主机（STONITH 策略）
- 切换时间控制在 500ms 以内——超过这个数，行情断层就明显了
避坑指南：我曾经遇到备机升主后，主机网线被拔了但 BMC 还在，备机发 IPMI 重启命令，主机 BMC 响应了但 OS 没起来……结果备机等超时，直接放弃切换。后来我加了「BMC 状态 + OS 状态」双重确认。
4.2 网卡失效：最隐蔽的「软故障」
网卡失效分两种：物理损坏（灯不亮）和逻辑失效（灯亮但丢包）。
后者更可怕。灯亮着，交换机端口也 up，但就是丢包。你查监控，CPU 正常、内存正常，就是行情少了几笔。
4.2.1 检测：别只看 Link Status
我见过太多人只检查 ethtool eth0 的 Link detected: yes。这远远不够。
真正要看的指标：
| 指标 | 正常值 | 报警阈值 |
|---|---|---|
| RX errors | 0 | > 0 持续 10 秒 |
| RX dropped | 0 | > 100 个/秒 |
| TX errors | 0 | > 0 立即报警 |
| CRC errors | 0 | > 1 个/分钟 |
这些数据从哪来？/sys/class/net/eth0/statistics/ 目录下，或者直接用 ip -s link。
4.2.2 自动切换：Bonding 的取舍
低延迟场景下，Linux bonding 的 mode 选择很关键。
我个人只用两种：
- Active-Backup (mode 1)：主网卡工作，备网卡 standby。切换时有短暂丢包（约 1-2 个报文），但延迟最低
- Balance-XOR (mode 0)：负载均衡，但需要交换机支持。延迟略高，不过带宽翻倍
千万别用 mode 4（802.3ad LACP），虽然链路聚合好，但 LACP 协商时间太长，行情来了它还没协商完。
注意：bonding 切换时，ARP 缓存会失效。我建议在切换脚本里手动触发一次 arping，否则网关那边可能还往坏网卡发数据。
4.3 磁盘故障：RAID 不是万能的
交易系统里，磁盘主要存三样东西：日志、配置文件、历史行情。
日志丢了可以重跑，配置文件丢了可以重新部署，但历史行情丢了……嗯，回测数据就没了。
4.3.1 检测：SMART 与 I/O 延迟
磁盘故障有个特点——它不会突然死，而是慢慢坏。
SMART 信息里，我最关注两个值：
- Reallocated_Sector_Ct：重映射扇区数。只要 > 0，就该换盘了
- Pending_Sector_Ct：待重映射扇区数。这个 > 0 说明磁盘正在挣扎
但 SMART 有个问题：它只能检测物理坏道，检测不了「慢盘」。
什么是慢盘？
磁盘本身没坏，但 I/O 响应时间从 1ms 变成了 100ms。这种盘在 RAID 阵列里，会把整个阵列拖慢。
我建议额外监控 iostat -x 1 里的 await 和 svctm。如果某个盘的 await 持续高于其他盘 3 倍以上，直接标记为故障。
4.3.2 自动切换：RAID 热备 + 分层存储
磁盘故障的自动切换，核心是 RAID 热备盘。
我常用的配置：
- 系统盘：RAID1（镜像），2 块 SSD，1 块热备
- 数据盘：RAID10（条带+镜像），4 块 NVMe，1 块热备
- 日志盘：单盘，不 RAID。日志丢了就丢了，性能优先
为什么日志盘不做 RAID？
因为日志是顺序写，单盘 NVMe 的延迟最低。RAID 控制器会增加 1-2 微秒的延迟。对于交易日志来说，这 2 微秒可能意味着少记一笔订单。
个人经验：我曾经遇到 RAID 卡缓存电池耗尽，导致写缓存策略从 WriteBack 降级为 WriteThrough，磁盘写入性能直接腰斩。后来我加了监控脚本，每天检查 megacli -AdpBbuCmd -GetBbuStatus -a0 的电池状态。
4.4 IPMI 与 BMC：硬件的「最后一道防线」
当 OS 挂了、SSH 连不上、ping 不通的时候，IPMI 是你唯一还能操作服务器的通道。
BMC（基板管理控制器）是独立于主 CPU 的微型系统，有自己的网口、自己的电源。哪怕服务器 OS 蓝屏了，BMC 照样能工作。
4.4.1 我常用的 IPMI 命令
# 查看传感器状态（温度、电压、风扇）
ipmitool sensor list
# 查看电源状态
ipmitool power status
# 强制重启（STONITH 用）
ipmitool power reset
# 查看系统事件日志（SEL）
ipmitool sel list
# 设置引导设备（下次从 PXE 启动）
ipmitool chassis bootdev pxe这些命令要集成到自动化脚本里。我习惯写一个 health_check.sh，每 10 秒轮询一次 BMC，如果连续 3 次传感器异常，就触发告警。
4.4.2 BMC 的监控陷阱
BMC 虽然可靠，但也不是万能的。我踩过几个坑：
- BMC 网口和业务网口共用：有些低端服务器，BMC 走的是共享网口。业务流量大了，BMC 的 IPMI 请求会被丢包。我建议用独立 BMC 网口
- BMC 固件 bug：某品牌服务器，BMC 固件版本 3.0 有个 bug——温度传感器读数会随机跳变。明明 40 度，突然跳到 90 度，触发风扇全速转。后来升级到 3.1 才解决
- IPMI 认证超时：默认的 IPMI 会话超时是 60 秒。如果监控脚本执行时间超过 60 秒，会话会断开，下次请求要重新认证。我一般把超时设到 300 秒
重要提醒：BMC 的默认密码一定要改！我见过太多人用 admin/admin 或者 root/root。黑客只要扫到 BMC 的 IP，就能直接关机。
4.5 整体架构：一张图看懂
下面这张图，是我个人项目中用的硬件故障检测与切换架构。你仔细看，会发现每个检测点都有冗余。
这张图的核心逻辑很简单：
- 主备服务器各自跑三层检测
- 检测结果汇总到仲裁层
- 仲裁层决定是否切换
- 执行层通过 IPMI 和 bonding 完成切换
嗯，这套架构我在生产环境跑了两年多，切换成功率 99.97%。那 0.03% 的失败，基本都是 BMC 固件 bug 导致的——所以你看，硬件层的问题，最后往往还是软件问题。
总结一句话：硬件故障不可怕，可怕的是你没准备好。IPMI 是最后一道防线，BMC 是守门员。别等到服务器冒烟了，才想起来配监控。
公众号:蓝海资料掘金营，微信deep3321