基于 Linux 集群环境上 GPFS 的问题诊断
作者:谷珊,帅炜,陈志阳
来源: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/meta
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 次。
该日志文件中不仅会记录操作信息,也会包括错误数据。具体可包括如下内容:
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=<desired_location>
来修改跟踪文件保存的位置。
启动跟踪功能
完成了跟踪属性的设置后,就可以启动跟踪功能了。启动跟踪功能的命令有两种,分别为 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源创计划”,欢迎正在阅读的你也加入,一起分享。
基于 Linux 集群环境上 GPFS 的问题诊断相关推荐
- linux环境下作业调度,Linux集群环境下作业调度算法的研究与实现
摘要: 集群计算环境中的作业调度接收用户提交的作业请求,并采用适当的调度策略选择计算节点资源来运行用户作业.作业调度策略决定了整个集群系统的效率,尤其是提交计算量大的作业时,良好的作业调度可以大大加快 ...
- Hadoop集群搭建07_克隆搭建Linux集群环境
通过前面的配置Linux中已经做好了准备 设置了网络 安装了JDK 关闭了防火墙 配置了域名映射 安装了mysql 为了避免出现问题 重新安装 这里我们可以先进行拍摄快照 快照 复制当前的机器的环境 ...
- linux+gpfs配置文件,GPFS 在 Linux 集群中的灾难恢复
GPFS 文件系统相关介绍 IBM General Parallel File System(GPFS) 是高性能.可扩展.并行文件系统.通过它,可以构建一个高可用.高性能的大型 Linux 计算机集 ...
- linux集群中mpi的并行计算环境简单配置,linux集群中MPI的并行计算环境简单配置(转)...
一.集群和Linux上的集群解决方案 集群计算机是指用一组联网的PC或工作站来搭建成的,提供比单个PC(节点)计算性能高得多的计算机.说其是计算机,其实是针对所提供出来的服务而言的,或者说是逻辑上来说 ...
- LINUX集群技术构建ANSYS分布式高性能计算平台
(转载请注明出处)随着仿真理论和求解技术越来越成熟,人们对产品虚拟的开发要求越来越高,系统级多体耦合和多物理场耦合计算已经成为计算机仿真的发展方向,用户不在追求单一个体在单一物理场(如结构力学,流体力 ...
- Java技术分享:集群环境下的定时任务
定时任务的实现方式有多种,例如JDK自带的Timer+TimerTask方式,Spring 3.0以后的调度任务(Scheduled Task),Quartz框架等. Timer+TimerTask是 ...
- Ubuntu下基于 Cilium CNI 的 Kubernetus集群环境搭建
Ubuntu下基于 Cilium CNI 的 Kubernetus集群环境搭建 1. 前言 2. 安装三个Ubuntu 2.1 三个机器都关闭防火墙 2.2 三个机器都关闭swap 2.3 三个机器都 ...
- Linux下安装搭建Memcached集群环境
由于项目需要,需要搭建memcached集群环境,遂开始调研相关技术 网络上有不少linux下安装memcached的教程,对于我这个linux零基础的来说,想立马在linux下安装memcached ...
- 在Linux集群上部署Spark之前准备
在Linux集群上部署Spark Spark安装部署比较简单, 用户可以登录其官方网站(http://spark.apache.org/downloads.html) 下载Spark最新版本或历史版本 ...
最新文章
- PCT-36.523
- 2021年JVM生态中哪些是流行的、热门的、趋势是什么
- Android实现自动清空,android – 删除图像后自动刷新在gridview中不...
- 面试系列 | 带你彻底搞懂 Python 装饰器
- ARMS为深绘智能系统保驾护航
- node --- 在node中使用mongoosemongoDB的安装
- Nginx编译安装和平滑升级
- android sqlite存储数据,Android之SQLite数据存储
- springmvc05 传值
- Win10设置系统保护色
- gmail登陆提示密码不正确
- was mutated while being enumerated.
- java邮箱地址正则表达式_Java 正则表达式匹配邮箱地址
- Mybatis的collection和association
- Android笔试题大全(持续更新中),安卓应用开发项目
- 聊聊自学,让你事半功倍的学习网站和工具
- ADB将外置TF储存卡融合本机ROM(内部储存)
- 实体企业直播困局该如何打破
- 心理学角度教你如何左手画圆,右手画方
- 在网页中用javascript控制wmplayer播放器