作者：谷珊，帅炜，陈志阳
来源：ibm developer
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 上的根目录已满：
node1:/ # df
filesystem 1k-blocks used available use% mounted on
/dev/sda2 153786688 5732360 140242324 100% /
udev 12343540 240 12343300 1% /dev
/dev/tiam_utility 31457280 675840 30781440 3% /tiam_utility
/dev/ccc 4087074816 179636480 3907438336 5% /tiam/ccc
fuse 4087074816 179636480 3907438336 5% /meta/tiam/ccc/meta4. 查看 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 次。
该日志文件中不仅会记录操作信息，也会包括错误数据。具体可包括如下内容：
gpfs 的启、停行为；
守护进程是否在运行；
守护进程和集群是否保持连接；
记录主要进程的状况和错误信息；
记录连接或磁盘失败方面的错误；
文件系统属性的改变信息等；
5. 查看系统日志文件有什么异常：
系统日志文件位于：/var/log/messages。该文件通常都很大，因为当 linux 第一次被启动后，该系统文件就不断的在记录信息。通常我们在查看时，可通过 more 来分页显示，通过 grep 查找特定的消息或时间点。我们经常把它和 gpfs 的日志结合起来查看，通过这两个日志提供的信息来确定问题。
这里需要注意的是，如果集群中各个节点上的系统时间不一致，就很难按照时间点来查找在不同节点上的日志文件。所以我们事先同步集群环境中所有节点的系统时间是很有必要的。
以上五种检查方法只是初步的检测手段，有关其他的考虑范畴可参考 gpfs 问题诊断手册获得更多信息。
更改跟踪属性设置
如果经过上述步骤的初步检查，用户仍然觉得在日志文件中记录的信息不够详尽，不足以让用户分析出问题所在，那么这时可利用 gpfs 的跟踪 (trace) 功能得到更底层的信息，它可以帮助我们按照时间发生顺序捕获到一系列引起问题的事件，以便进一步诊断问题。通常，我们使用系统默认的跟踪设置即可。在问题诊断的初期，我们也不建议采用修改跟踪设置的方式进行检查。但当默认配置不能满足某些特殊问题的需求时，就需要根据实际需要对特定属性进行配置，以使得在相应的日志中产生更详尽的信息。因此，这一步骤不是必须做的。
跟踪是 gpfs 文件系统中一个非常重要的功能。对于开发人员来说，它可以帮助开发人员看到系统运行过程中内部的、更底层的信息，以此来找到问题并解决。对于非开发人员，一般是看不懂这些底层信息的。但掌握跟踪功能的设置，可以让我们在发现问题时，给开发或服务团队提供更准确、更有价值的日志信息。下面就简单介绍一下如何修改跟踪属性以及如何使其生效。
修改跟踪属性的方法:
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= 来修改跟踪文件保存的位置。
启动跟踪功能
完成了跟踪属性的设置后，就可以启动跟踪功能了。启动跟踪功能的命令有两种，分别为 mmtrace 和 mmtracectl 。 mmtrace 主要应用在 gpfs3.1 及之前的版本中。自从 gpfs3.2 之后， mmtrace 逐渐被 mmtracectl 所取代。因为 mmtracectl 更加便捷，它只需在一个节点上运行便可在集群中所有节点上生效，而不像 mmtrace 那样，必须在每个节点上都运行。
下面介绍 mmtrace 的使用方法。
在单一节点上简单的启动跟踪功能：
命令： mmtrace start
该命令在哪个节点上运行，就在哪个节点上生效。需要注意的是，这种启动方法在节点被重启后，会失效。
使用 mmtracectl 命令进行跟踪：mmtracectl 命令与 mmtrace 的不同之处在于它只需要在集群中的某个节点上运行，便可在集群范围内所有节点生效。这种跟踪启动方法在节点被重启后还会继续生效。
查看跟踪进程：
通过查看是否有 lxtrace 进程，可以知道跟踪进程的状态。
重现问题并截获跟踪信息
在对跟踪属性进行设置并启动跟踪功能后，就需要重现问题发生的过程。在这个过程中，gpfs 才会根据新的跟踪属性记录更详细的信息到日志文件。
在重现了问题后，可以有两种方式截获跟踪信息：
mmtrace stop：
该命令停止在当前跟踪文件中的信息记录，并停止继续跟踪；
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
结论：node2 和 node3 都处于不健康状态。
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
结论：名为 /col1 的 gpfs 文件系统出现问题。磁盘空间使用率为 6%，使用正常。
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 日志文件中查看对应时间点的情况，发现如下错误：
node3:/var/adm/ras # vi mmfs.log.latest
mon aug 9 21:13:21.867 2010: *** assert exp(!"assert on structure error")
in line 527 of file /build/ode/gpfs32/src/avs/fs/mmfs/ts/logger/logger.c
mon aug 9 21:13:21.919 2010: *** traceback:
mon aug 9 21:13:21.922 2010: 2:0x402d5d4e logassertfailed 0x14e
mon aug 9 21:13:21.929 2010: 21:0x2b614a0bcb3d clone 0x6d
mmfsd: /build/ode/gpfs32/src/avs/fs/mmfs/ts/logger/logger.c:527:
void logassertfailed(unsigned int, char*, unsigned int, int, int,
unsigned int, char*, char*):
assertion `!"assert on structure error"' failed.
mon aug 9 21:13:21.928 2010: signal 6 at location 0x2b614a02c5f5
in process 4961, link reg 0xffffffffffffffff.
mon aug 9 21:13:21.929 2010: rax 0x0000000000000000
rbx 0x00007fff423fd170
结论：在 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 能够健康工作。
——the end——
本文分享自微信公众号 - 生信科技爱好者（bioitee）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“osc源创计划”，欢迎正在阅读的你也加入，一起分享。
