Red Hat Training

A Red Hat training course is available for RHEL 8

第 7 章 诊断并修正 GFS2 文件系统的问题

以下流程描述了一些常见的 GFS2 问题,并提供了有关如何解决它们的信息。

7.1. GFS2 文件系统对节点不可用(GFS2 撤回功能)

GFS2 withdraw 功能是 GFS2 文件系统的数据完整性功能,可防止因为硬件或者内核软件造成潜在的文件系统损坏。如果 GFS2 内核模块在任何指定集群节点中使用 GFS2 文件系统时检测到不一致的情况,它会从该文件系统中撤回(withdraw),并使它在相应的节点上不可用,直到卸载并重新挂载该节点(或者被探测到有问题的机器被重启)。所有其他挂载的 GFS2 文件系统在那个节点中仍能完全正常工作。(GFS2 撤回功能没有内核的 panic 严重,内核 panic 会导致该节点被隔离。)

可能导致 GFS2 撤回的主要原因:

  • 内节点一致性错误
  • 资源组一致性错误
  • 日志一致性错误
  • Magic number 元数据一致性错误
  • 元数据类型一致性错误

因为不一致性导致 GFS2 撤回的一个示例是,文件内节点的不正确的块计数。当 GFS2 删除一个文件时,它会系统性地删除该文件引用的所有数据和元数据块。在完成后,它会检查内节点的块计数。如果块计数不是 1(1 代表所有剩下的都是磁盘内节点),这表示文件系统不一致,因为内节点的块数量与该文件使用的实际块不匹配。在很多情况下,问题可能是由硬件故障造成的(内存、主板、HBA、磁盘驱动器、电缆等出问题)。也可能是由内核的程序漏洞(另一个内核模块意外覆盖 GFS2 内存)或者实际文件系统损坏(由 GFS2 错误导致)造成的。

在大多数情况下,从 GFS2 文件系统中恢复的最佳方法是重新引导或者隔离该节点。撤回的 GFS2 文件系统将给您一个将服务重新定位到集群的另一个节点的机会。重新定位服务后,您可以重新引导节点或使用这个命令强制进行隔离。

pcs stonith fence node
警告

不要尝试使用 umountmount 命令手动卸载和重新挂载文件系统。您必须使用 pcs 命令,否则 Pacemaker 会检测到文件系统服务已消失,并隔离节点。

导致撤回的一致性问题可能会导致无法停止文件系统服务,因为它可能导致系统挂起。

如果重新挂载后问题仍然存在,您应该停止该文件系统服务以从集群中的所有节点卸载文件系统,然后在按照以下流程重启服务前使用 fsck.gfs2 命令执行文件系统检查。

  1. 重新引导受影响的节点。
  2. 在 Pacemaker 中禁用非克隆文件系统服务,以从集群中的每个节点卸载文件系统。

    # pcs resource disable --wait=100 mydata_fs
  3. 从集群的一个节点对文件系统设备运行 fsck.gfs2 命令,来检查和修复文件系统损坏。

    # fsck.gfs2 -y /dev/vg_mydata/mydata > /tmp/fsck.out
  4. 通过重新启用文件系统服务从所有节点中重新挂载 GFS2 文件系统:

    # pcs resource enable --wait=100 mydata_fs

您可以使用文件系统服务中指定的 -o error=panic 选项挂载文件系统来覆盖 GFS2 撤回功能。

# pcs resource update mydata_fs “options=noatime,errors=panic”

当指定这个选项时,所有会导致系统撤回的错误都是强制造成一个内核 panic。这样可停止节点的通讯,从而可以隔离该节点。这对于长时间无人值守、而无需监控或干预的集群特别有用。

GFS2 撤回的内部工作原理是,断开锁定协议以确保以后所有的文件系统操作都会出现 I/O 错误。因此,当发生撤回时,通常会在系统日志中看到来自设备映射器的 I/O 错误。