如何获得有关 mdadm RAID 问题的通知？

Question

我正在运行 Ubuntu 12.04 LTS。昨天我在邮箱里发现了一条消息，说我的服务器被关闭了。我继续重新启动系统，但几分钟后它没有出现，而且我没有硬件 KVM 系统来查看内核正在向终端打印什么。所以我将系统重新启动到 Linux 救援映像，我发现软件 RAID 1 阵列不同步。救援系统也开始重建RAID阵列。

到目前为止，没有证据表明任何磁盘存在硬件错误。到目前为止，SMART 状态看起来不错。

我从未收到过 mdadm 的电子邮件通知，即使在 /etc/mdadm/mdadm.conf 中打开了电子邮件通知。

该服务器还配置为将所有系统日志消息转发到日志主机，因此我检查了我的日志主机。相关部分是：

5 月 20 日 15:38:40 内核：[1.869825] md0：检测到从 0 到 536858624 的容量变化
5 月 20 日 15:38:40 内核：[1.870687] md0：未知分区表
5 月 20 日 15:38:40 内核：[1.877412] md：绑定
5 月 20 日 15:38:40 内核：[1.878337] md/raid1:md1：不干净——开始背景重建
5 月 20 日 15:38:40 内核：[1.878376] md/raid1:md1：2 个镜像中有 2 个处于活动状态
5 月 20 日 15:38:40 内核：[1.878418] md1：检测到从 0 到 3000052808704 的容量变化
5 月 20 日 15:38:40 内核：[1.878575] md：重新同步 RAID 阵列 md1
[剪辑]
5 月 20 日 15:52:33 内核：内核日志记录 (proc) 停止。
5 月 20 日 15:52:33 rsyslogd：[origin software="rsyslogd" swVersion="5.8.6" x-pid="845" x-info="http://www.rsyslog.com"] 在信号 15 上退出.

如您所见，系统（正常系统，而不是救援系统）在系统启动期间已经检测到 RAID 阵列出现问题。然后，不久之后，某个东西（不是我）停止了系统。

所以我的问题是：

1. 什么可能导致磁盘突然不同步？
2. 为什么我没有通过电子邮件通知？
3. 为什么在停止系统之前错误没有正确记录到系统日志中？可能是系统尝试登录到 syslog，但在停止 syslog 守护进程后这样做了？如果是这样，我能做些什么来防止这种情况发生？
4. 我该怎么做才能查明发生了什么？或者，如果我现在无法查明发生了什么，我该如何改进日志记录和通知，以便下次我可以进行更好的事后分析？

我的问题与正确的备份实践无关。我已经知道 RAID 不是备份等。我的问题仅是关于通知和诊断。

Answer 1

什么可能导致磁盘突然不同步？

这可能是驱动器盘片和内存中数据之间的路径中的任何硬件或软件故障。这可能意味着但不限于：驱动器头、驱动器控制器、电缆上的连接头、电缆本身（内部断线）、电缆插入驱动器上的端口、主板或子卡上的端口、主板或子卡上的控制器芯片，甚至软件（某处）出现故障。

真实的故事：我曾经有一个 RAID 镜像，它不稳定，无缘无故地掉落了一个驱动器。驱动器检查良好，盘片干净（重复 SMART 通行证没有任何结果），一切运行良好 - 直到它一次又一次地剥落。我更换了 3 美元的 SATA 电缆，问题立即消失。这个故事的寓意是：有很多地方可能会出错，如果您不检查数据路径中的每个组件，您就不能总是假设“一切都很好”。

为什么我没有收到电子邮件通知？

仅当 (a) 主动监控阵列或 (b) 询问阵列时才会出现电子邮件通知。

我的建议是：您需要让 mdadm 作为一个进程主动监控驱动器阵列。这可以通过类似（但不完全相同）的方法来完成：

mdadm --monitor --scan --syslog

您需要根据您的具体安装调整上述行。

为什么在停止系统之前错误没有正确记录到系统日志中？系统是否尝试记录到 syslog，但在停止 syslog 守护进程后才这样做？如果是这样，我可以做什么来防止这种情况发生？

可能有多种问题导致日志记录被删除。

首先，存在系统日志一般如何工作的整个问题；尽管我们已经花费了很多年的时间来使其稳健可靠，但在某些极端情况下，数据可能无法写入磁盘。这是一个众所周知的设计问题，并且已通过监督式服务管理（又名守护进程工具及其同类）积极解决。解决方案是完全绕过系统日志，并将输出写入始终具有打开文件描述符的记录器，因此不会丢失任何内容，并且记录器会尽快将输出转储到磁盘；虽然它不是 100% 有效的解决方案，但它确实显着提高了在内核崩溃或关闭之前将事件写入驱动器的可能性。

其次，内核可能发生彻底的恐慌，或者发生其他一些事件，迫使机器陷入困境。即使有故障的硬件也可能会导致问题 - 我见过 PSU 功率不足的机器会导致 Windows 8 中自发关机。更换 PSU 永久解决了关机问题。显然，内核无法采取任何措施来防止机器刚刚决定“我已经受够了”并摇摇晃晃地重新启动。

我可以做什么来查明发生了什么？或者，如果我现在无法查明发生了什么，我该如何改进日志记录和通知，以便下次我可以进行更好的事后分析？

有几种方法：

• 将日志记录放在单独的分区上。虽然这并不能保证您将获得完整的日志，但它确实有助于隔离文件系统问题，例如磁盘已满无法写入、导致重新挂载为只读的损坏等。它确实有助于解决这些问题具体案例。

• 查看远程记录重要的系统信息。同样，这并不能保证，但如果最后一个数据包能够在重新启动之前“走出大门”，并且该数据包具有有关重新启动原因的关键线索，那么它将有所帮助。

• 对于特定的关键服务，请考虑用其他内容替换系统日志的输出，例如监督式日志记录，其中专用记录器拦截输出并将其尽快写入磁盘。这提高了输出存储的可靠性。只需做一点工作，就可以使其与其他服务管理安排并存。