引言：一场本可避免的运维事故

2022年9月，某金融系统Oracle RAC集群的运维人员在节点二执行了常规的存储扩容操作。今年例行维护重启，系统却崩溃在启动界面，报错"/dev/mapper/rhel-root does not exist"。令人费解的是：节点二的操作为何会导致节点一崩溃？ 本文将解密这场由LVM操作引发的连锁反应灾难。

一、故障时间线：从扩容到崩溃

  1. 隐患埋下(2022-09-09)

节点二因/home空间不足，执行了危险操作：

pvcreate /dev/emcpowerm # 初始化了一个存储设备

vgextend rhel /dev/emcpowerm # 扩展到共享VG

lvextend -rl +100%free /dev/rhel/home # 吃光所有空间 风险点

未识别该设备可能是临时映射的共享存储

LVM操作引发的连锁灾难：一次VG重名导致的集群节点启动故障深度剖析_运维

2.日志爆发(2023-09-18)

LVM操作引发的连锁灾难：一次VG重名导致的集群节点启动故障深度剖析_元数据_02

DBA找主机工程师排查，判断该告警可以忽略。

日志爆发(2024-06-21)

节点一系统日志出现致命告警：

[Fri Jun 21 06:15:55 2024] Info:emcp:1853:0:0:3 Received scsi remove notification for dev sdbe index 0x38 devno 0x4300080 (67:128)
[Fri Jun 21 06:15:55 2024] sd 1853:0:0:3: [sdbe] Synchronizing SCSI cache
[Fri Jun 21 06:15:55 2024] Info:emcp:1853:0:0:4 Received scsi remove notification for dev sdbf index 0x39 devno 0x4300090 (67:144)
[Fri Jun 21 06:15:55 2024] sd 1853:0:0:4: [sdbf] Synchronizing SCSI cache
[Fri Jun 21 06:15:55 2024] Info:emcp:1853:0:0:5 Received scsi remove notification for dev sdbg index 0x3a devno 0x43000a0 (67:160)
[Fri Jun 21 06:15:55 2024] sd 1853:0:0:5: [sdbg] Synchronizing SCSI cache
[Fri Jun 21 06:15:55 2024] Info:emcp:1853:0:0:6 Received scsi remove notification for dev sdbh index 0x3b devno 0x43000b0 (67:176)
[Fri Jun 21 06:15:55 2024] sd 1853:0:0:6: [sdbh] Synchronizing SCSI cache
[Fri Jun 21 06:15:55 2024] Info:emcp:1853:0:0:7 Received scsi remove notification for dev sdbi index 0x3c devno 0x43000c0 (67:192)
[Fri Jun 21 06:15:55 2024] sd 1853:0:0:7: [sdbi] Synchronizing SCSI cache
[Fri Jun 21 06:15:55 2024] ata3: hard resetting link
[Fri Jun 21 06:15:56 2024] ata3: SATA link down (SStatus 0 SControl 300)
[Fri Jun 21 06:15:56 2024] ata3: EH complete
[Fri Jun 21 06:15:56 2024] ata4: hard resetting link
[Fri Jun 21 06:15:56 2024] ata4: SATA link down (SStatus 0 SControl 300)
[Fri Jun 21 06:15:56 2024] ata4: EH complete
[Fri Jun 21 06:15:56 2024] ata5: hard resetting link
[Fri Jun 21 06:15:56 2024] ata5: SATA link down (SStatus 0 SControl 300)
[Fri Jun 21 06:15:56 2024] ata5: EH complete
[Fri Jun 21 06:15:56 2024] ata6: hard resetting link
[Fri Jun 21 06:15:57 2024] ata6: SATA link down (SStatus 0 SControl 300)
[Fri Jun 21 06:15:57 2024] ata6: EH complete
[Fri Jun 21 06:15:57 2024] ata7: hard resetting link
[Fri Jun 21 06:15:57 2024] ata7: SATA link down (SStatus 0 SControl 300)
[Fri Jun 21 06:15:57 2024] ata7: EH complete
[Fri Jun 21 06:15:57 2024] ata8: hard resetting link
[Fri Jun 21 06:15:57 2024] ata8: SATA link down (SStatus 0 SControl 300)
[Fri Jun 21 06:15:57 2024] ata8: EH complete
[Fri Jun 21 06:15:57 2024] ata9: hard resetting link
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
  • 18.
  • 19.
  • 20.
  • 21.
  • 22.
  • 23.
  • 24.
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.

此时emcpowerm设备被存储系统移除，DBA找主机工程师排查，判断该告警可以忽略。

3. 崩溃时刻(2025年重启后)

当节点一重启时，屏幕输出错误：无法进入操作系统。

LVM操作引发的连锁灾难：一次VG重名导致的集群节点启动故障深度剖析_运维_03

系统陷入救援状态，这是一次有计划的重启维护，应用IP，已经投产至RAC的另外一个节点，故业务无影响！

二、根源分析：VG重名引发的元数据污染

致命陷阱：跨节点共享VG名称

节点

卷组名

物理卷(PV)

状态

节点一

rhel

/dev/sda, /dev/sdb...

生产环境

节点二

rhel

/dev/sda, /dev/emcpowerm

混入存储设备

当节点二将emcpowerm加入rhel卷组时：

LVM操作引发的连锁灾难：一次VG重名导致的集群节点启动故障深度剖析_元数据_04

  1. LVM元数据被修改为：
VG rhel {
  PV /dev/sda        # 节点本地磁盘
  PV /dev/emcpowerm  # 未知共享设备
}
  • 1.
  • 2.
  • 3.
  • 4.
  1. 该元数据通过共享存储自动同步到节点一
  2. 当emcpowerm设备离线时：
  • 节点一启动需激活rhel VG
  • 系统要求访问所有PV(包括已丢失的emcpowerm)
  • 因缺少PV导致VG激活失败 → 根文件系统无法挂载

规避文件系统与数据库块的边界冲突,这种 “预留少量空间” 的操作，本质是保守型运维思想的体现—— 通过牺牲极小的空间(通常 1%-5%)，规避文件系统、数据库引擎、存储系统等多层级的潜在风险，优先保障数据文件的稳定性和可扩展性。历史上，部分数据库版本(如 Oracle 9i/10g 早期版本)或存储系统(如老旧 RAID 阵列)存在 “整数倍大小文件” 的兼容性问题,这一习惯源于老 DBA 对 “数据库崩溃往往源于细节” 的经验认知，属于 “预防性运维” 的典型实践。

三、紧急救援：三招挽回系统

当系统陷入dracut紧急模式时，通过组合拳恢复：

1. 强制激活可用PV
# 跳过丢失设备，部分激活VG
vgchange --partial -ay rhel
  • 1.
  • 2.
2. 重建initramfs镜像
# 注入LVM修复模块
dracut --force --add lvm \
       /boot/initramfs-$(uname -r).img \
       $(uname -r)
  • 1.
  • 2.
  • 3.
  • 4.
3. 清理元数据污染
# 移除"幽灵设备"
vgreduce --removemissing --force rhel
# 彻底清除无效PV
pvremove /dev/emcpowerm --force --force
  • 1.
  • 2.
  • 3.
  • 4.

四、根治措施：从架构层面杜绝隐患

VG命名规范(核心防御)
# 为每个节点分配唯一VG名
vgrename rhel rhel_$(hostname -s)

# 更新fstab和启动配置
sed -i 's/rhel-root/rhel_node1-root/' /etc/fstab
grub2-mkconfig -o /boot/grub2/grub.cfg
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.

结语：教训背后的架构启示

此次故障的根本原因是存储资源标识的边界模糊——同一个VG名称在不同节点被混用，使局部操作产生全局影响。在分布式系统中需牢记：

"无名之害，甚于猛虎"

  1. 永远为资源赋予节点标识(如vg_节点1)
  2. 存储设备需全链路指纹跟踪(WWN→udev→LVM)
  3. LVM操作前执行跨节点一致性检查

通过实施文中的防御措施，可使您的集群避免此类"隔山打牛"式的灾难。记住：在运维领域，命名的规范性直接决定系统的健壮性！