服务器 on Zero Day Notes

机房精密空调故障，服务器集群怎么就过热降频了？

Wed, 13 Dec 2023 10:35:00 +0000

问题背景

公司自建数据中心内有 5 个标准机柜，约 30 台物理服务器（含数据库、虚拟化主机、备份存储）。机房制冷由两台 Emerson 精密空调（一主一备）提供，设定温度 22°C，温差 ±2°C。机房环境监控通过 Zabbix 采集温湿度传感器的 SNMP 数据。

故障现象

12 月 13 日上午 10:20，运维收到用户反馈：公司内部 OA 系统、ERP 系统、企业邮箱全部响应极度缓慢，页面加载时间从正常的 1-2 秒变成 30-60 秒。监控平台显示全业务 P99 延迟飙升 20-30 倍。

登录虚拟化平台 vCenter 查看宿主机：

Host: esxi-01.corp.local
CPU Usage: 35%
CPU Ready: 18% (正常应 <5%)
Memory Usage: 72%
Alarm: Host CPU thermal throttling active

CPU 热节流（Thermal Throttling）被触发！ 所有 ESXi 主机都在强制降频运行，原本 3.0GHz 的 CPU 被限制在 1.2GHz，虚拟机中的应用程序性能被严重拖慢。

排查过程

第一步：确认机房温度

跑到机房门口，开门瞬间热浪扑面——室内温度计显示 48°C！

Zabbix 监控的告警时间：

10:20:00  机房温度 = 28°C  (超过25°C阈值，未告警？)
10:25:00  机房温度 = 35°C  (仍无告警)
10:30:00  机房温度 = 45°C  (仍无告警？)
10:35:00  机房温度 = 48°C  (告警终于发出) # 延迟了15分钟！

第二步：检查空调状态

1 号精密空调——完全停机。面板无任何指示灯。2 号备用空调在运行，但出风口温度仅 28°C（正常应为 16-18°C），实际制冷能力严重不足。

第三步：分析 1 号空调停机原因

查看空调控制器日志：

1
2

2023-12-13 10:15:32 Compressor High Pressure Alarm
2023-12-13 10:15:32 System Shutdown (Safety)

压缩机高压保护——空调因室外机散热受阻导致压缩机出口压力过高，触发安全停机。

室外温度 -12°C，打开室外机检修面板——风扇叶片被一层厚厚的冰冻住了，完全无法转动。北京冬季夜间温度降到 -15°C，空调室外机底部的排水孔被冰堵住，融化的冷凝水无法排出，在风扇轴承上结冰。

第四步：为什么 2 号空调制冷不足？

2 号空调虽然在运行，但制冷剂（R410A）压力只有正常值的 60%。检查发现制冷剂管路接口处有微漏，过去半年逐步泄漏但未补充。低制冷剂量下制冷能力大打折扣——2 号空调虽然亮着灯，实际起不到"备用"的作用。

第五步：为什么 Zabbix 告警延迟了 15 分钟？

1
2
3

$ cat /etc/zabbix/zabbix_server.conf | grep -E "StartPollers|Timeout"
StartPollers=5
Timeout=30

温度传感器的 SNMP 轮询间隔为 3 分钟。关键是告警触发条件：

`1`	`Trigger: avg(机房温度, 15m) > 28°C`

触发条件使用了 avg(15m)（15 分钟均值）——温度上升期间前几分钟的低值拉低了平均值，直到均值突破 28°C 才触发告警，而实际温度已经到 48°C 了。

解决方案

紧急物理降温

打开机房所有门窗通风，搬入 2 台工业风扇辅助对流
紧急关闭非核心服务器：将测试环境和开发环境的物理机全部关机，降低整体热负载
手动除冰：用热水浇融 1 号空调室外机风扇上的冰层，清理排水孔

冰层清除后，1 号空调恢复正常运行，机房温度在 20 分钟内回落到 28°C。CPU 热节流自动解除，业务 P99 延迟逐步恢复。

后续整改

1 号空调加装低温套件：包含加热带（防止排水孔结冰）和变速风扇控制器
2 号空调补充制冷剂：查找泄漏点并修复，补充制冷剂至标称压力
Zabbix 告警规则修正：

# 改为：最近一次温度值（非均值）超过28°C立即告警
Trigger: last(机房温度) > 28°C

# 增加温度变化率告警
Trigger: (last(机房温度) - last(机房温度, 60s)) > 3

根因分析

直接原因：精密空调室外机排水孔在冬季严寒天气下结冰堵塞，风扇被冻住 → 压缩机高压报警停机 → 室内温度快速上升 → 服务器自动降频保护。

深层原因：

精密空调缺少低温环境适配（未安装低温套件）
备用空调制冷剂泄漏，关键时刻无法满负荷运行
Zabbix 温度告警使用 15 分钟均值，延迟了紧急告警
机房缺乏温度传感器的多点冗余部署

预防措施

精密空调低温套件：冬季前安装加热带、变速风扇等低温适配组件
备机制冷能力保障：每季度检测备机制冷剂压力，确保备机随时可用
实时温度告警：告警规则改用 last() 实时值 + 变化率双触发
多点温感冗余：机柜顶部、中部、底部各部署温度传感器
冬季巡检 SOP：11 月-3 月每月检查室外机排水孔和风扇轴承结冰情况
应急演练：机房温度异常应急预案（工业风扇、开门通风、关非核心设备）

总结

机房空调故障是运维能遇到的最"低技术含量"但又最致命的事故之一——不需要什么高深的网络协议或分布式系统知识，它就是物理世界的一个设备坏了。但它的破坏力是全局性的：一台空调停机，30 台服务器的 CPU 全部被迫降频，所有业务线的性能同时崩盘。在运维的世界里，对物理基础设施的监控不能有任何侥幸——温度告警的延迟、备机制冷剂的泄漏，都可以被"看起来正常"的表象掩盖，直到故障真正爆发。

记一次服务器内存硬件故障导致的不定时宕机

Wed, 12 Jul 2023 11:55:00 +0000

问题背景

公司一台运行 MySQL 8.0 的物理服务器（Dell PowerEdge R740xd，128GB DDR4 ECC 内存），作为生产环境的主库。该机器上线约 18 个月，之前从未出现过硬件问题。

故障现象

7 月初开始，这台 MySQL 服务器出现不定时宕机——平均每 2-3 天一次，时间毫无规律：一次是凌晨 3:00，一次是下午 2:30，一次是上午 10:15。宕机后服务器完全无响应，Ping 不通，只能通过 iDRAC 远程控制台强制重启。

每次宕机后检查系统日志：

1
2

$ journalctl -b -1 --no-pager | tail -50
-- Reboot --

宕机前的日志中没有任何异常记录——没有 OOM Killer，没有 kernel panic 堆栈（默认不输出到串口），没有硬件错误的 edac 报告。系统像是被直接拔了电源一样，没有任何临终遗言。

排查过程

第一轮：怀疑温度和电源

通过 iDRAC 查看系统事件日志（SEL）：

SEL Record:
  Date/Time: 2023-07-10 02:58:14
  Sensor: CPU1 Temp
  Type: Temperature
  Description: Upper Non-Critical going high (85°C)

CPU 温度确实偏高（85°C），但还在正常运行范围内（Tcase max 约 95°C）。清理了服务器内部灰尘并更换了散热硅脂后，CPU 温度降到 65°C——但宕机仍然发生。

第二轮：怀疑内核崩溃（kdump 无输出）

配置 kdump 来捕捉内核崩溃时的内存转储：

1
2

yum install kexec-tools
systemctl start kdump

下一次宕机后检查 /var/crash/——kdump 没有生成任何转储文件。这说明崩溃的类型非常底层，连内核的 crashkernel 都无法正常加载。

第三轮：启用 MCE 详细日志

怀疑是硬件层面的错误触发，在 /etc/default/grub 中添加内核参数：

`1`	`GRUB_CMDLINE_LINUX="... mce=3 mcelog=1 console=ttyS0,115200"`

通过 iDRAC 的串口重定向功能捕获下一次宕机时的输出。一周后再次宕机，iDRAC 串口日志中终于抓到了关键信息：

[Hardware Error]: CPU:0 (7-86-6) MC0_STATUS[-|CE|MiscV|AddrV|-|-|CECC]: 0x9c20400001080136
[Hardware Error]: Error Addr: 0x00000006f3c82540
[Hardware Error]: MC0 Error: ECC error at CPU:0, channel:1, DIMM: A2
[Hardware Error]: cache level: L2, tx: GEN, mem-tx: RD
Kernel panic - not syncing: Fatal machine check on current CPU

Machine Check Exception (MCE)——CPU 检测到了无法纠正的 ECC 内存错误（Uncorrectable ECC Error），触发了内核 Panic。

关键信息：

错误位置：CPU:0, Channel:1, DIMM: A2
错误类型：ECC 不可纠正错误
错误地址：0x00000006f3c82540（刚好落在 MySQL 的 buffer pool 内存区域）

第四轮：确认内存故障模式

虽然 ECC 内存能纠正单比特错误，但当同一个字节出现超过 1 个比特错误时就超过了 ECC 的纠错能力，触发不可纠正错误。而这种偶发性多比特错误通常意味着内存条即将彻底损坏。

# 之前的edac日志其实有单比特可纠正错误的记录，只是没触发MCE
$ grep -i "corrected error" /var/log/messages | grep "DIMM A2"
Jul 03 05:12:14 server kernel: EDAC MC0: 1 CE memory read error on CPU:0 channel:1 slot:A2
Jul 03 19:44:32 server kernel: EDAC MC0: 1 CE memory read error on CPU:0 channel:1 slot:A2
Jul 05 11:37:05 server kernel: EDAC MC0: 1 CE memory read error on CPU:0 channel:1 slot:A2

DIMM A2 早在 7 月 3 日就开始出现可纠正错误（CE）——只是没人关注 edac 日志。CE 累积到无法纠正时就变成了 MCE 导致宕机。

解决方案

停机更换内存：联系 Dell 售后，确认 DIMM A2 故障，申请 RMA 更换
更换后验证：通过 memtest86+ 对新内存条做全量检测（pass > 3 次）
重启应用：确认 MySQL 恢复正常，buffer pool 完整性校验通过

更换内存条后，服务器恢复稳定运行，至今未再宕机。

根因分析

直接原因：DIMM A2 内存条硬件老化导致偶发性不可纠正的 ECC 错误，触发 MCE，内核 Panic 使系统直接宕机。kdump 无法捕获 MCE 级别的 Panic 因为内核已经在极端底层崩溃。

深层原因：可纠正错误（CE）的 edac 日志没有被纳入监控告警体系，内存条在"带病工作"了一周后才演变为不可纠正错误导致宕机。

预防措施

EDAC 监控告警：通过 Zabbix 监控 /sys/devices/system/edac/mc/mc*/ce_count，单条 DIMM 的 CE 数量 >10 即告警
iDRAC 告警集成：将 Dell iDRAC 的 SNMP Trap 接入监控系统，硬件可纠正错误立即触发
定期硬件巡检：每季度对所有服务器的 SEL 日志和 ECC 统计做一次全面巡检
建立硬件故障响应流程：CE 告警 → 24 小时内确认 → 48 小时内安排更换窗口
关键服务冗余：MySQL 主库升级为主从架构，让单机故障不至于导致完全不可用

总结

硬件故障不是"会不会发生"的问题，而是"什么时候发生"的问题。ECC 内存的可纠正错误（CE）是硬件健康的"矿工金丝雀"——当它开始频繁出现时，意味着那条内存条离彻底损坏不远了。这次故障的教训不是 ECC 不够强，而是 CE 的 edac 日志沉默了一整周而没有人关注。在运维中，比监控"已经宕机"更重要的是监控"即将宕机"的信号。