![正确启动丢失或错误故障的基于软件的 RAID1](https://linux22.com/image/771769/%E6%AD%A3%E7%A1%AE%E5%90%AF%E5%8A%A8%E4%B8%A2%E5%A4%B1%E6%88%96%E9%94%99%E8%AF%AF%E6%95%85%E9%9A%9C%E7%9A%84%E5%9F%BA%E4%BA%8E%E8%BD%AF%E4%BB%B6%E7%9A%84%20RAID1.png)
总结 有没有办法正确启动丢失或发生故障的基于软件的 RAID1(不是由用户首先导致的故障)?
需要明确的是,无需硬盘即可启动基于软件的 RAID1如果在重新启动之前,您正确地使驱动器失效。我知道这很主观,但这似乎不是一个合理的解决方案,也不是一个可接受的答案。例如:一个设施断电,硬盘驱动器在断电的同时发生故障。尝试使用未“正确”故障的降级硬盘驱动器进行启动将导致系统进入紧急模式。
我已经阅读了这里和其他论坛的许多帖子,它们都建议您在所有分区上安装 grub,或者手动重建 grub、添加nofail
选项/etc/fstab
或其他看似简单的解决方案;但事实是,这些建议都没有起作用。
虽然我已经接受了这个不可能的事实,但这件事还是有些不太容易解决。所以,我想看看是否有其他人遇到过这个问题或有解决方案。
我的环境:
我有一块较旧的主板,不支持 UEFI,所以我必须启动传统模式/MBR。
操作系统:
cat /etc/redhat-release
Red Hat Enterprise Linux Workstation release 7.6 (Maipo)
核心:
uname –r
3.10.0-957.el7.x86_64
mdadm:
mdadm –version
mdadm – v4.1-rc1 2018-03-22
我的 RAID 是跨三个驱动器的 RAID1。(sda,sdb,sdc
)并且有 4 个分区
md1 - /boot
md2 - /home
md3 - /
md4 - swap
我已经在所有分区上安装了 grub,并确保所有启动分区都有启动标志。 所有在相应分区旁边的启动字段中
fdisk /dev/sd[a,b,c]
显示-- 和 -- (作为单独的命令,结果为“成功安装”)。*
grub2-install /dev/sd[a,b,c]
复制问题:
- 关闭系统电源,将所有驱动器分配给 RAID,并使 RAID 完全正常运行。
- 移除硬盘
- 电源系统启动
结果:
系统将通过 grub 启动。Gdm 将尝试显示登录屏幕,但大约 20 秒后,它将失败并进入紧急控制台。“正常”系统缺少许多部分。例如,/boot 和 /etc 不存在。似乎没有显示任何内核崩溃消息或问题dmesg
。
再次强调,这里的关键是:RAID 必须完全组装,关闭电源并移除驱动器。如果您正确故障驱动器并将其从 RAID 中移除,那么您可以在没有驱动器的情况下启动。
例子:
mdadm --manage /dev/md[1,2,3,4] --fail /dev/sda[1,2,3,4]
(作为单独的命令)
mdadm --manage /dev/md[1,2,3,4] --remove /dev/sda[1,2,3,4]
(作为单独的命令)
我知道这似乎微不足道,但我还没有找到一个可行的解决方案来启动具有降级 RAID1 的系统。您可能会认为这应该是一个简单的问题,有一个简单的解决方案,但事实并非如此。
任何帮助、意见或建议都将不胜感激。
答案1
启动发生故障的 MD RAID1 阵列肯定是可能的 - 至少如果 BIOS 跳过发生故障的磁盘(如果没有,您可以简单地从幸存的磁盘手动启动)。
对于您的具体问题,您可能会遇到此问题漏洞。摘录(但阅读所有错误报告是个好主意):
RHEL 7.6 dracut-iniqueue 脚本的默认值为 180 秒(如 RDRETRY 变量中所定义),高于 systemd 根挂载服务(90 秒)。当根位于降级的软件 RAID1 设备上时(用户被转移到紧急 shell),这可能会导致系统无法启动。请参阅 https://bugzilla.redhat.com/show_bug.cgi?id=1451660#问题示例。请注意,这种情况仅当 RAID 设备认为自己处于健康状态,但在启动过程中意外发现阵列降级时才会发生。
在启动时传递“rd.retry=30”可修复阵列启动降级问题,因为阵列在 systemctl root mount 服务超时之前被强制启动。此外,较长的 dracut rd.retry 超时与 dracut.cmdline(7) 手册页不一致,手册页中规定超时应为 30 秒。
...
附加信息:我将问题追溯到 mdadm --incremental、dracut 超时(rd.retry)和 systemctl 默认超时如何交互:
- mdadm --incremental 不会启动/运行意外发现降级的阵列;
- dracut 应在超过 2/3 超时值后强制启动阵列。按照当前 RHEL 默认设置,该时间是 180/3*2 = 120 秒;
- systemctl 预计最多 90 秒内挂载根文件系统。如果不成功,它会中止 dracut 脚本并转到紧急 shell。90 秒低于 dracut 超时,这意味着 dracut 没有机会强制启动阵列。降低 rd.retry 超时(按照手册页的建议设置)可使 dracut 强制启动阵列,从而使 systemctl 服务成功。
作为错误应该在最近的 RHEL/CentOS 7 版本中已修复,我强烈建议您更新系统(如果可以)。否则,请尝试将其rd.retry=30
作为内核启动选项传递。