基于 Linux 集群环境上 GPFS 的问题诊断

　　GPFS 是 IBM 提供的一种共享文件系统。由于 GPFS 的复杂性，使得人们在使用时会遇到各种类型的问题。对于 GPFS 的使用者，掌握基本的诊断方法，不仅可以帮您快速解决一些并不严重的问题及时恢复 GPFS 正常运行起来，同时，对于 IBM 直接提供支持的用户，本文介绍一些初步问题诊断方法可以帮助您快速提交问题报告给 IBM 服务团队，从而加速解决问题的过程。本文基于作者对 GPFS 测试和使用的经验，按照由易到难的诊断步骤和方法进行讲解，总结了一些在诊断 GPFS 问题上的经验和建议，同时结合一些实例按照文中介绍的诊断方法进行问题诊断，供读者参考。

　　GPFS 的概述

　　GPFS 是 IBM 公司提供的一个共享文件系统，它允许所有的集群节点可以并行访问整个文件系统。GPFS 允许客户共享文件，这些文件分布在不同节点的不同硬盘上，GPFS 还提供了 UNIX 文件系统接口并且支持 UNIX 文件系统的工具，用户可以在 Linux 集群中像使用普通文件系统一样使用 GPFS 文件系统，能够很好地应用在 Linux/UNIX 集群中。

　　在 GPFS 的长期运行中可能会出现一些问题，本文主要针对在使用 GPFS 中常见问题的一些诊断方法进行探讨。

　　问题诊断步骤与方法

　　初步检查

　　在装有 GPFS 文件系统的环境中出现问题时，我们在求助 IBM Service 团队前，可先自行进行些初步检查。既可以快速修复一些简单问题，也可向 Service 人员提供更详尽的问题描述信息来协助他们加快解决问题。我们一般有下面的几种常见检查方法。

　　1. 首先检查该问题仅仅出现在一个节点还是多个节点上并明确问题节点 :

　　通常判断某节点是否有问题的方法如下：

　　在 GPFS 集群中的某个可访问节点上运行 mmgetstate – a，该命令可以显示集群中所有节点的状态，只要不是”active”状态的节点，都不是健康的节点。如下例所示，可见节点 node2 和 node3 都出现了问题：

　node1:~　#　mmgetstate　-a　
　
　Node　number　Node　name　　　　GPFS　state　
　——————————————　
　　　　1　　　node1　　　　　　active　
　　　　2　　　node2　　　　　　arbitrating　
　　　　3　　　node3　　　　　　down　

　　2. 查看 GPFS 文件系统是否出现了问题：

　　因为所有文件系统必须在被挂载后才能使用，因此我们可以通过 df 命令来查看集群环境中某节点上所有文件系统的情况。正常情况下，通过 df 命令查看时，每个文件系统后都会显示相应的挂载点。当不能正常显示时，就表明该文件系统出现了问题。从下例中我们可以看到 /tiam/col1 文件系统出现了问题：

　node1:/　#　df　
　Filesystem　　　　　　1K-blocks　　　Used　　Available　　Use%　　Mounted　on　
　/dev/sda2　　　　　　153786688　　8750488　　137224196　　　6%　　　/　
　udev　　　　　　　　4088080　　　　212　　　4087868　　　　1%　　　/dev　
　df:　`/tiam/col1′:　Stale　NFS　file　handle　
　/dev/tiam_utility　　　　31457280　　2754816　　28702464　　　9%　　　/tiam_utility　
　/dev/col2　　　　　　602931200　　29118208　　573812992　　　5%　　/tiam/col2　
　/dev/col3　　　　　　619646976　　33665024　　585981952　　　6%　　/tiam/col3　

　　需要注意的是，要在 GPFS 集群系统中的每个节点上都进行检查。

　　3. 查看磁盘空间是否满了：

　　不少情况下 GPFS 发生问题，都是因为空间满了造成的。因为如果空间满了后 GPFS 就会停止工作。所以在进一步查看问题之前，确认磁盘空间是否已满是十分重要的一步。同样，也可用 df 命令进行检查，它可以检查文件系统的已用磁盘空间、空闲磁盘空间和使用率等情况。并且需要在每个节点上都进行检查。从下例中可以看出节点 1 上的根目录已满：

　　4. 查看 GPFS 的日志：

　　在出现 GPFS 问题时，第一个需要查看的日志文件就是 mmfs.log，它位于 /var/adm/ras 目录下。每当重启一次 GPFS，都会产生一个新的 mmfs.log 文件，通过在文件名中增加时间戳的显示来进行区分。例如：

　node1:/var/adm/ras　#　ls　-al　mmfs*　
　-rw-r–r–　1　root　root　5124　Nov　11　05:53　mmfs.log.2009.11.11.05.05.38.　node1　
　-rw-r–r–　1　root　root　3007　Nov　12　03:37　mmfs.log.2009.11.11.05.53.09.　node1　
　-rw-r–r–　1　root　root　2710　Nov　12　03:42　mmfs.log.2009.11.12.03.37.19.　node1　
　-rw-r–r–　1　root　root　2143　Nov　12　06:10　mmfs.log.2009.11.12.03.43.41.　node1　
　-rw-r–r–　1　root　root　3280　Nov　18　14:00　mmfs.log.2009.11.12.06.10.29.node1　
　lrwxrwxrwx　1　root　root　　36　Nov　12　06:10　mmfs.log.latest　->　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　mmfs.log.2009.11.12.06.10.29.node1　
　lrwxrwxrwx　1　root　root　　36　Nov　12　03:43　mmfs.log.previous　->　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　mmfs.log.2009.11.12.03.43.41.node1　

　　该日志文件中不仅会记录操作信息，也会包括错误数据。具体可包括如下内容：

　　GPFS 的启、停行为；

　　守护进程是否在运行；

　　守护进程和集群是否保持连接；

　　记录主要进程的状况和错误信息；

　　记录连接或磁盘失败方面的错误；

　　文件系统属性的改变信息等；

　　5. 查看系统日志文件有什么异常：

　　系统日志文件位于：/var/log/messages。该文件通常都很大，因为当 Linux 第一次被启动后，该系统文件就不断的在记录信息。通常我们在查看时，可通过 more 来分页显示，通过 grep 查找特定的消息或时间点。我们经常把它和 GPFS 的日志结合起来查看，通过这两个日志提供的信息来确定问题。

　　这里需要注意的是，如果集群中各个节点上的系统时间不一致，就很难按照时间点来查找在不同节点上的日志文件。所以我们事先同步集群环境中所有节点的系统时间是很有必要的。

　　以上五种检查方法只是初步的检测手段，有关其他的考虑范畴可参考 GPFS 问题诊断手册获得更多信息。

　　更改跟踪属性设置

　　如果经过上述步骤的初步检查，用户仍然觉得在日志文件中记录的信息不够详尽，不足以让用户分析出问题所在，那么这时可利用 GPFS 的跟踪 (trace) 功能得到更底层的信息，它可以帮助我们按照时间发生顺序捕获到一系列引起问题的事件，以便进一步诊断问题。通常，我们使用系统默认的跟踪设置即可。在问题诊断的初期，我们也不建议采用修改跟踪设置的方式进行检查。但当默认配置不能满足某些特殊问题的需求时，就需要根据实际需要对特定属性进行配置，以使得在相应的日志中产生更详尽的信息。因此，这一步骤不是必须做的。

　　修改跟踪属性的方法

　　mmchconfig trace=”trace_class trace_level [trace_class trace_level]…”

　　或者：

　　mmtracectl –set –trace=”trace_class trace_level [trace_class trace_level]…”

　　例如：mmtracectl –set –trace=”tm 2 thread 1 vnode 5″

　　在众多的跟踪属性中，我们究竟要修改哪些默认值是要根据实际情况决定的。对于不同的问题，会需要不同方面的属性。

　　使修改生效的方法：

　　1. 在修改属性命令后增加 – i 参数，意思是马上生效。如：mmtracectl –set –trace=”tm 2 thread 1 vnode 5″ -i

　　2. 重启整个 GPFS

　mmshutdown　–　a　
　mmstartup　-a　

　　查看当前跟踪属性的设置

　　通过 mmfsadm showtrace 或者 mmlsconfig 命令，可以查看当前跟踪属性的设置情况。例如：运行上面的修改跟踪属性的命令后，可以通过 mmfsadm showtrace 或者 mmlsconfig 命令进行确认，看相应属性的修改是否生效。

　node1:~　#　mmlsconfig　
　Configuration　data　for　cluster　node1:　
　—————————————　
　clusterName　node1　
　clusterId　12402633003866146335　
　clusterType　lc　
　autoload　yes　
　minReleaseLevel　3.2.1.6　
　dmapiFileHandleSize　32　
　cnfsSharedRoot　/tiam_utility/cnfs　
　cnfsReboot　yes　
　pagepool　1G　
　maxFilesToCache　20000　
　maxMBpS　500　
　worker1Threads　144　
　prefetchThreads　144　
　dmapiMountTimeout　120　
　envVar　LC_ALL=””　LC_CTYPE=”en_US.UTF-8″　
　assertOnStructureError　yes　
　trace　tm　2　thread　1　vnode　5　
　traceFileSize　0　
　cnfsNFSDprocs　128　
　nfsPrefetchStrategy　1　
　
　File　systems　in　cluster　node1:　
　——————————–　
　/dev/tiam_utility　
　
　node1:~　#　mmfsadm　showtrace　
　Current　trace　levels:　
　(　省略　)　
　　　thread　:　1(operations　in　Thread　class)　
　　　　　tm　:　2(token　manager)　
　　　　　ts　:　0　　(Tiger　Shark　specific　code)　
　　　　user1　:　0　　(Used　for　miscellaneous　tracing　and)　
　　　　user2　:　0　　(debugging　purposes)　
　　　　vnode　:　5(vnode　layer　of　VFS　kernel　support)　
　(　省略　)　

　　mmchconfig　trace=DEFAULT　<-i>　
　　例如：　
　node1:~　#　mmchconfig　trace=DEFAULT　-i　
　　　　　mmchconfig:　Command　successfully　completed　

　　默认的跟踪文件保存路径：

　　如果没有特别的指定，默认的跟踪文件被保存在 /tmp/mmfs 目录下。例如：

　node1:/tmp/mmfs　#　ls　-al　trc*　
　-rw-r–r–　1　root　root　406110912　Jan　19　14:52　trcfile.100119.14.52.05.node1　
　-rw-r–r–　1　root　root　1073686504　Jan　20　06:02　trcfile.100120.06.02.35.node1　
　-rw-r–r–　1　root　root　361915888　Jan　20　15:54　trcfile.100120.15.54.10.node1　

　　可以通过 mmchconfig dataStructureDump=<desired_location> 来修改跟踪文件保存的位置。

　　启动跟踪功能

　　完成了跟踪属性的设置后，就可以启动跟踪功能了。启动跟踪功能的命令有两种，分别为 mmtrace 和 mmtracectl。mmtrace 主要应用在 GPFS3.1 及之前的版本中。自从 GPFS3.2 之后，mmtrace 逐渐被 mmtracectl 所取代。因为 mmtracectl 更加便捷，它只需在一个节点上运行便可在集群中所有节点上生效，而不像 mmtrace 那样，必须在每个节点上都运行。

　　下面介绍 mmtrace 的使用方法。

　　在单一节点上简单的启动跟踪功能：

　　命令：mmtrace start

　　该命令在哪个节点上运行，就在哪个节点上生效。需要注意的是，这种启动方法在节点被重启后，会失效。

　　使用 mmtracectl 命令进行跟踪：

　　mmtracectl 命令与 mmtrace 的不同之处在于它只需要在集群中的某个节点上运行，便可在集群范围内所有节点生效。这种跟踪启动方法在节点被重启后还会继续生效。

　　通过查看是否有 lxtrace 进程，可以知道跟踪进程的状态。

　　重现问题并截获跟踪信息

　　在对跟踪属性进行设置并启动跟踪功能后，就需要重现问题发生的过程。在这个过程中，GPFS 才会根据新的跟踪属性记录更详细的信息到日志文件。

　　在重现了问题后，可以有两种方式截获跟踪信息：

　　1. mmtrace stop:

　　该命令停止在当前跟踪文件中的信息记录，并停止继续跟踪；

　　2. mmtrace:

　　该命令停止在当前跟踪文件中的信息记录，但同时产生一个新的跟踪文件继续跟踪记录。以此来保证跟踪文件不会由于过多的信息而被重写，从而丢掉有用的信息。

　　有些时候，在截获跟踪信息的同时，还需要通过额外的设置产生一些 internaldump 文件来帮助分析 GPFS 相关的问题。默认情况下，是不会生成 internaldump 文件的。命令如下：

　　mmchconfig traceGenDump=yes – i

　　案例分析

　　在基于 Linux 操作系统平台、GPFS 文件系统的集群运行过程中，出现了问题。该集群环境信息如下：

　　有 3 个节点，分别命名为：node1, node2, node3；

　　有 3 个 GPFS 文件系统，分别命名为：/col1, /col2, /col3；

　　在 CNFS 客户机上有 9 个挂载点，NFS 客户端通过 CNFS IP 同时往 3 个 GPFS 文件系统中传送数据；

　　诊断过程

　　1. 首先查看各节点状态 :

　node1:~　#　mmgetstate　-a　
　Node　number　Node　name　　　　GPFS　state　
　——————————————————————　
　　　　1　　　node3　　　　　arbitrating　
　　　　2　　　node2　　　　　arbitrating　
　　　　3　　　node1　　　　　active　

　　2. 查看 GPFS 集群配置是否正确状态

　　GPFS 的管理命令 mmlscluster 会显示当前 GPFS 集群的配置信息，从中可以判断 GPFS 的配置是否正确

　ianode1:~　#　mmlscluster　
　
　GPFS　cluster　information　
　========================　
　GPFS　cluster　name:　　　　　node3　
　GPFS　cluster　id:　　　　　　12402633012462803091　
　GPFS　UID　domain:　　　　　　node3　
　Remote　shell　command:　　　　/usr/bin/ssh　
　Remote　file　copy　command:　/usr/bin/scp　
　
　GPFS　cluster　configuration　servers:　
　———————————–　
　Primary　server:　　node3　
　Secondary　server:　node2　
　
　Node　Daemon　node　name　IP　address　　Admin　node　name　　　Designation　
　————————————————————————————　
　　1　　　　　node3　　　　172.31.1.3　　　　node3　　　　　　　　quorum-manager　
　　2　　　　　node2　　　　172.31.1.2　　　　node2　　　　　　　　quorum-manager　
　　3　　　　　node1　　　　172.31.1.1　　　　node1　　　　　　　　quorum-manager　

　　3. 查看 GPFS 文件系统与磁盘空间使用情况：

　node1:/tmp/mmfs　#　df　
　Filesystem　　　　　　1K-blocks　　　Used　Available　Use%　Mounted　on　
　/dev/sda2　　　　　　153786688　　8750488　137224196　　6%　/　
　udev　　　　　　　　　　4088080　　　　212　　4087868　　1%　/dev　
　df:　`/col1′:　Stale　NFS　file　handle　
　/dev/tiam_utility　　　31457280　　2754816　28702464　　9%　/tiam_utility　
　/dev/col2　　　　　　602931200　29118208　573812992　　5%　/col2　
　/dev/col3　　　　　　619646976　33665024　585981952　　6%　/col3　

　　4. 在问题节点上查看系统日志文件 /var/log/message，发现如下错误：

　node3:/　#　vi　/var/log/messages　
　Aug　9　21:13:21　node3　mmfs:　Error=MMFS_FSSTRUCT,　ID=0x94B1F045,　
　　　　　Tag=6319986:　Invalid　disk　data　structure.　　
　　　　　　Error　code　107.　Volume　col3　　.　Sense　Data　
　Aug　9　21:13:21　node3　mmfs:　Error=MMFS_FSSTRUCT,　ID=0x94B1F045,　
　　　　　　　　　Tag=6319986:　　6B　00　10　00　00　00　01　00　
　…　…　
　Aug　9　21:13:21　node3　last　message　repeated　14　times　
　Aug　9　21:13:21　node3　mmfs:　Error=MMFS_FSSTRUCT,　ID=0x94B1F045,　
　　　　　　　　Tag=6319986:　　00　00　00　00　
　Aug　9　21:13:21　node3　mmfs:　Error=MMFS_FSSTRUCT,　ID=0x94B1F045,　Tag=6319986:　　
　Aug　9　21:13:21　node3　mmfs:　mmfsd:　Error=MMFS_GENERIC,　ID=0x30D9195E,　Tag=6319987　
　Aug　9　21:13:21　node3　mmfs:　Generic　error　in　
　　　　　/build/ode/gpfs32/src/avs/fs/mmfs/ts/logger/Logger.C　line　527　　
　　　　　　　　retCode　0,　reasonCode　0　
　Aug　9　21:13:21　node3　mmfs:　Tag=6319987　　!”Assert　on　Structure　Error”　

　　结论：在 8 月 9 日 21 点 13 分左右，节点 3 上出现断言错误。

　　5. 根据系统日志中出错的时间，在最新的 GPFS 日志文件中查看对应时间点的情况，发现如下错误：

　　结论：在 8 月 9 日 21 点 13 分左右，由于不合法的数据结构导致遇到断言错误。

　　6. 更改跟踪属性的设置：

　　由于目前的信息无法满足 GPFS 开发人员分析出该问题的缘由，所以根据开发人员的建议需要启动跟踪功能并设置一些特定的参数，具体内容如下：

　　增加跟踪文件的大小，使得它不会被很快的写满后被覆盖 : mmtracectl –set –trace-file-size=800M ；

　　在结构性错误发生时产生断言，由此可以自动捕获 GPFS 跟踪信息：mmchconfig assertOnStructureError=yes ；

　　每次在 GPFS 重启后，自动启动跟踪功能：TRACE_RECYCLE=”global” ；

　　7. 启动跟踪功能：

　　在集群中任一节点上运行命令：mmtracectl –start

　　8. 重现问题并截获跟踪信息：

　　重新把系统运行起来直到 GPFS 再次遇到问题。此时在节点上执行 mmtrace stop 命令，这样就可以捕获到当问题发生时的详细的跟踪信息。

　　结束语

　　根据上面介绍的 GPFS 常见问题的诊断方法，我们可以在 GPFS 发生问题后进行相应检查，尽快查到问题所在恢复或者提供给相应技术人员更快解决，保证 GPFS 能够健康工作。