ZFS-HA 池因元数据损坏而发生故障

ZFS-HA 池因元数据损坏而发生故障

我按照 Github 上的详细描述设置了 ZFS-HA(参见这里)。经过大量测试后,我使用 RAIDZ3 中的 5x12 磁盘将该设置投入生产,并使用 HBA 控制器将其连接到两个节点。这运行得非常顺利,直到昨晚,两个存储池中的一个在运行过程中突然出现故障,并显示“池元数据已损坏”。scrub此时,我只能推测是什么原因造成的,两个池都在 Pacemaker 中设置了 SCSI 隔离,并且在投入生产之前我测试的所有故障情况下,磁盘预留都运行正常。最近发生的唯一重大事件是两次没有 UPS 支持的完全断电(即:电源从一刻到下一刻都断了)。但是,损坏的真正原因也可能是完全不同的东西。

现在的情况是,我无法再使用这个池了(请参阅本问题末尾的import输出)。到目前为止,我所有拯救池的意图都失败了:zpool import

# zpool import -f tank
cannot import 'tank': one or more devices is currently unavailable

# zpool import -F tank
cannot import 'tank': one or more devices is currently unavailable

这让我有点困惑,因为它并没有真正说明唯一的选择就是摧毁这个池(这将是对一个受到致命破坏的池的预期反应)。

# zpool clear -F tank
cannot open 'tank': no such pool

我还手动删除了所有 SCSI 保留,例如:

# DEVICE=35000c5008472696f
# sg_persist --in --no-inquiry --read-reservation --device=/dev/mapper/$DEVICE
# sg_persist --in --no-inquiry --read-key --device=/dev/mapper/$DEVICE
# sg_persist --out --no-inquiry --register --param-sark=0x80d0001 --device=/dev/mapper/$DEVICE
# sg_persist --out --no-inquiry --clear --param-rk=0x80d0001 --device=/dev/mapper/$DEVICE
# sg_persist --in --no-inquiry --read-reservation --device=/dev/mapper/$DEVICE

我进一步尝试从磁盘架上移除 A/C,以清除可能残留在桌子上的任何临时信息。

坦白说,我没什么选择了。我唯一剩下的选择就是-X——zpool import在所有其他措施都失败后,我会尝试这个选择。

所以我的问题是,你以前遇到过类似的事情吗?更重要的是,你找到解决这个问题的方法了吗?如果你能提供任何建议,我将不胜感激。

=========

泳池布局/配置:

   pool: tank
     id: 1858269358818362832
  state: FAULTED
 status: The pool metadata is corrupted.
 action: The pool cannot be imported due to damaged devices or data.
        The pool may be active on another system, but can be imported using
        the '-f' flag.
   see: http://zfsonlinux.org/msg/ZFS-8000-72
 config:

        tank                   FAULTED  corrupted data
          raidz3-0             FAULTED  corrupted data
            35000c5008472696f  ONLINE
            35000c5008472765f  ONLINE
            35000c500986607bf  ONLINE
            35000c5008472687f  ONLINE
            35000c500847272ef  ONLINE
            35000c50084727ce7  ONLINE
            35000c50084729723  ONLINE
            35000c500847298cf  ONLINE
            35000c50084728f6b  ONLINE
            35000c50084726753  ONLINE
            35000c50085dd15bb  ONLINE
            35000c50084726e87  ONLINE
          raidz3-1             FAULTED  corrupted data
            35000c50084a8a163  ONLINE
            35000c50084e80807  ONLINE
            35000c5008472940f  ONLINE
            35000c50084a8f373  ONLINE
            35000c500847266a3  ONLINE
            35000c50084726307  ONLINE
            35000c50084726897  ONLINE
            35000c5008472908f  ONLINE
            35000c50084727083  ONLINE
            35000c50084727c8b  ONLINE
            35000c500847284e3  ONLINE
            35000c5008472670b  ONLINE
          raidz3-2             FAULTED  corrupted data
            35000c50084a884eb  ONLINE
            35000c500847262bb  ONLINE
            35000c50084eb9f43  ONLINE
            35000c50085030a4b  ONLINE
            35000c50084eb238f  ONLINE
            35000c50084eb6873  ONLINE
            35000c50084728baf  ONLINE
            35000c50084eb4c83  ONLINE
            35000c50084727443  ONLINE
            35000c50084a8405b  ONLINE
            35000c5008472868f  ONLINE
            35000c50084727c6f  ONLINE
          raidz3-3             FAULTED  corrupted data
            35000c50084eaa467  ONLINE
            35000c50084e7d99b  ONLINE
            35000c50084eb55e3  ONLINE
            35000c500847271d7  ONLINE
            35000c50084726cef  ONLINE
            35000c50084726763  ONLINE
            35000c50084727713  ONLINE
            35000c50084728127  ONLINE
            35000c50084ed0457  ONLINE
            35000c50084e5eefb  ONLINE
            35000c50084ecae2f  ONLINE
            35000c50085522177  ONLINE
          raidz3-4             FAULTED  corrupted data
            35000c500855223c7  ONLINE
            35000c50085521a07  ONLINE
            35000c50085595dff  ONLINE
            35000c500855948a3  ONLINE
            35000c50084f98757  ONLINE
            35000c50084f981eb  ONLINE
            35000c50084f8b0d7  ONLINE
            35000c50084f8d7f7  ONLINE
            35000c5008539d9a7  ONLINE
            35000c5008552148b  ONLINE
            35000c50085521457  ONLINE
            35000c500855212b3  ONLINE

编辑:

服务器为 2x Dell PowerEdge R630,控制器为 Broardcom SAS HBA 的 DELL OEM 版本(应类似于 SAS 9300-8e),此池中的所有 60 个磁盘均为 Seagate ST6000NM0034。机箱为 Quanta MESOS M4600H。

编辑2:

操作系统是 CentOS 7

ZFS 是 zfs-0.7.3-1.el7_4.x86_64

答案1

最后我求助于-X的选项import。这通过以 2GB/s 的速度读取所有磁盘约 36 小时来锻炼。之后,没有出现错误消息,文件系统已安装并且现在再次完全可访问。到目前为止,没有检测到任何数据不一致(zfs scrub仍在运行)。感谢您的所有回复。

然而,对于未来的读者,我想传递警告关于-X手册页中的选项:此选项对于您的池的健康极其危险,只能作为最后的手段使用。

答案2

似乎上游没有太多的选择(这是来自Oracle Solaris ZFS 故障排除和池恢复文档中指出,这zpool import -F是你唯一的选择,除非聘请 ZFS 专家来真正调查元数据是如何损坏的):

如果无法通过上面描述的池恢复方法恢复池,则必须从备份副本中恢复池及其所有数据。

我不认为 OpenZFS 联盟能带来多少改变现状的成果。这确实是个令人悲伤的消息。

PS 这与池出现这种情况的原因无关,但您不认为创建 10 个磁盘宽的阵列本身就是问题吗?即使有 2 个以上的备用磁盘。冷数据等等,你知道的。

答案3

硬件详情是什么?服务器、磁盘、机箱和控制器的品牌和型号。

我将禁用所有 HA 功能并专注于一个系统上的工作。

  • 将一个节点置于待机状态:pcs cluster standby或者仅禁用起搏器。

  • 在您将要处理的节点上手动导入池:

    zpool import tank -d /dev/mapper/并观察结果。

dmesg另外,完成此操作后您会看到什么?

答案4

为了将来参考,当所有其他方法都失败时,您可以尝试以下命令:

zpool import -F“pool-name”,然后按顺序输入 -FX,然后输入 -T。(首先备份原始媒体。)

PS. T 代表终结者。

相关内容