董志卫
作者董志卫2017-02-28 17:51
系统架构师, 李宁(中国)体育用品有限公司

GPFS 运维知多少

字数 9143阅读 10301评论 0赞 8

最近一段时间里社区了积累了不少有关GPFS软件日常使用的方面的问题,经过社区的大力支持,近期组织了一次有关GPFS 的活动,意在通过一次或几次活动,希望能够把社区以及其他有关GPFS的需求、疑惑、问题进行梳理、解答、交流、分享。本次活动在GPFS的应用场景,常见架构,仲裁机制,系统搭建,参数设置,集群优化,故障诊断这些方面进行了一些交流和分享。

本文将通过对GPFS 社区讨论话题结合GPFS软件整个环境,整体梳理一下GPFS 软件的诸多方面,整体了解和认识一下GPFS的使用,希望能够在后续的使用当中能够启到参考作用。

下面本文将在以下几个方面进行梳理:GPFS 发展史, GPFS常见架构, GPFS角色和概念, 集群搭建,参数设置及优化,故障诊断,GPFS应用场景和发展空间的探讨。

GPFS 发展史

IBM GPFS是一个可扩展,高性能,基于共享磁盘的并行文件系统,自从4.1后更名为IBM Spectrum Scale ,并入IBM Spectrum 产品线。本文后续有关Spectrum Scale的名字还是以GPFS( 使用习惯)为主。

Spectrum Scale的发展与演进

IBM GPFS 软件在当今软件定义存储的大背景下,与时俱进,在原有的基础之上拓展了许多功能,诸如云计算、大数据、云存储和对象存储等,并且还在持续不断的增添新功能。
使得GPFS在多种应用场景下支持的身影。

一 GPFS常见架构:

在日常的多种使用GPFS的应用场景中,主要使用的架构有以下几种方式。

GPFS架构分类:
Network-Based Client架构
Direct Attached Storage架构
Mixed NSD access架构
File Placement Optimizer (FPO)架构

参考链接
http://forum.huawei.com/enterprise/thread-386395.html

二 GPFS 角色和概念

本文将结合gpfs产品的关键字进行解释说明,对GPFS整体的逻辑概念进行梳理,希望大家有一个清晰的认识。

Cluster

GPFS群集是指多个节点的集合,他们共享同一个或者多个并行文件系统;群集里的节点可以并发访问这些文件系统里的数据

GPFS Admin LAN

用于GPFS 管理的网络

Primary/Secondary NSD Server

主和次 NSD Server

NSD(network share disk)

NSD是一个虚拟的磁盘子系统,提供对GPFS内共享磁盘全局命名的功能

Failure Group

Failure Group 是一个磁盘的集合,一个单点故障会引起集合内部的所有磁盘同时失效

Quorum

Quorum 是保障GPFS资源可用和完整性的机制。在一个GPFS系统中,如果半数以上节点GPFS守护进程正常工作,次机制就被激活。GPFS文件系统就处于可用状态。

GPFS 特殊管理功能节点

GPFS configuration Manager:
处理当节点失效时,判断是否满足Quorum,从而决定FS系统是否持续可用
为文件系统选择File Manager节点,每个文件只有一个FSM,从而保证数据的一致性。

File System Manager

  1. 处理文件系统配置的改变,例如增加删除磁盘等。Mount进程靠FSM和发请求节点共同执行。
  2. 磁盘空间分配管理:控制磁盘区域的分配,运行并发的空间分配。
  3. 信令管理功能:实现多个节点对同一文件同一区域的并发访问。
  4. Quota 管理功能:用户限额功能。

The Metadata Node

  1. 为维持文件Metadata的一致性每一个被打开的文件都有一个MetaNode,任何一个访问该文件的节点都可以对该文件进行读写,但只有MetaNode可以更新该文件的MetaData。
  2. MetaNode 是随机的,通常是访问该文件时间最长的节点担当。

GPFS 文件系统结构

一个GPFS文件系统包含一组磁盘,称为一个条带组(stripe group)。用于存储MetaData,Quota Files,GPFS recovery log,User data。这些磁盘的配置信息存放在每个磁盘的file system description area 区,FSDA也包含文件系统状态信息。

MetaData
The same as Unix file system,inode,indirect blocks ard considered Metadata

Quota Files
用于文件系统的限额功能

GPFS Recovery Log
当创建文件系统时,就自动会创建GPFS recovery logs。GPFS recovery logs一定是被复制的,并且可以通过位于FSDA内的指针找到他们。GPFS recovery logs备平均分布在所有磁盘上,通过情况下不可见的。The file system manager 为每一个访问这个文件系统的用户分配一个GPFS Recovery log。

User Data
The remaining space is allocated from the block allocation map as needed and is used for user data and directories.

总结:有了以上GPFS 各个角色和概念的介绍,对于GPFS的规划,使用都会带来相应的工作便利。

三 群集搭建:

在日常工作当中,时常要进行GPFS群集的搭建工作,下面对整个群集的过程进行一个梳理,便于参考步骤执行,有一个清晰的顺序。

  1. 根据需求选择GPFS响应版本的软件,使用支持的操作系统(参照官方文档)
  2. 根据需求规划群集拓扑,定义角色
  3. 准备硬件,安装OS和必须软件,做信任配置,
  4. 编译,安装软件
  5. 创建集群,接受License,设置参数,设置数据网络和管理网络
  6. 准备磁盘,编写nsd profile,格式化NSD
  7. 创建文件系统,设置参数
  8. 根据经验优化具体的参数设置
  9. 测试(是否正常访问,是否高可用,读写等)
  10. 完毕,书写文档,总结经验

群集的搭建流程大致是上面10个步骤,但是因具体环境或多或少的有所变化,在此附上一篇在IBM AIX上构建一个双节点IBM GPFS 集群小文,敬请参考:
https://www.ibm.com/developerworks/cn/aix/library/au-aix-building-two-node-gpfs-cluster/

四 参数设置和优化

所谓参数优化设置都是要结合具体环境而定,那么在此我们不做太具体的参数设置,而是根据以往经验和最佳参考实践进行梳理和总结,由于笔者经验问题,很难做到面面俱到。
下面我们将分几个方面针对GPFS的群集搭建过程当中常见的场景进行介绍和梳理

优化分类

1. 操作系统

下面主要结合Linux 操作系统应用场景进行设置。

Linux: sysctl net.core.somaxconn=
Linux: sysctl net.core.netdev_max_backlog=250000
Linux: sysctl net.ipv.neigh..mcast_solicit=9 and/or net.ipv.neigh..ucast_solicit=9
Linux: sysctl vm.min_free_kbytes=an order of magnitude of 5-6% of the total amount of physical memory
Linux: modprobe.conf ib_ipoib send_queue_size=8192 recv_queue_size=8192 (specific to IB)
Linux: IPoIB should use datagram mode instead of connected
Linux: net.ipv4.tcp_sack = 1
Enable Flow Control - In large GPFS clusters we have found that enabling flow control can improve performance. Typically flow control is enabled on the host and on the network switches. Indications of network flow control issues in GPFS include seeing log getData waiters or long NSD I/O waiters.
推荐:
网络:使用10GB 以太网和infiniband 网组网,支撑高网络io需求
存储:使用多个同级别存储,分散IO,并发读写能力高,存储端可以配置ssd进行性能热点

2. GPFS群集参数

GPFS: socketMaxListenConnections=maximum number of nodes in a cluster
GPFS: idleSocketTimeout=0
GPFS: failureDetectionTime=60
GPFS: minMissedPingTimeout=60
GPFS: tscWorkerPool=128
GPFS: maxReceiverThreads=number of logical CPUs on the node
GPFS: tokenMemLimit=1G
GPFS: work1Threads=100
GPFS: worker3Threads=40
GFFS: maxMBpS=2400
GPFS: maxStatCache=60000
GPFS: pagepool=4-8GB
GPFS: maxFilesToCache=1000

推荐:
设置管理网络和数据网络独立,相互不影响。
设置failgroup,保证数据的高可用

3 . 高可性设计

GPFS 可用性机制
GPFS 的数据完整性一方面是由以上提到的数据安全机制来保证,另外也通过一套可用性判断机制来完全保证数据完整性与系统安全。 GPFS 提供三套不同的 quorum 机制来判断系统当前的状态,其中 File Descriptor Quorum 是系统内置的,不能做配置,另外两种 node quorum 和 tiebreaker quorum 方式只能二者选其一,使用那种方式要基于我们的系统环境与可靠性分析。

• File system Descriptor Quorum,File system Descriptor 顾名思义即描述文件系统信息的数据。我们在几个不同的 failure-group 的磁盘上创建 GPFS 文件系统时,会把文件系统的配置信息(简写为 FD)的拷贝写到多个磁盘上,以实现冗余备份。FD quorum 的机制即通过判断含有 FD 磁盘的在线情况来判断当前系统是否正常,当超过半数的含有 FD 的磁盘掉线时,就判断为系统故障,将会自动关闭文件系统。
Node Quorum 是通过主机状态的来判断系统可用性的机制。GPFS 文件系统集群中,可以设置多个主机节点为 Quorum node。Node Quorum 的机制是通过判断 Quorum node 的状态来判断系统是否正常,当超过半数的 Quorum node 在线时,判断系统为正常,反之,将关闭文件系统。
Tiebreaker quorum 是通过磁盘的状态来判断系统的可用性。我们可以设置系统通过监视指定的一些磁盘作为 Tiebreaker Disk。当超过半数的 Tiebreaker Disk 掉线时,则判断系统故障,将自动关闭文件系统。Tiebreaker 最多只能配置两个用来监控磁盘状态的 quorum 主机,当 2 台 quorum 主机都宕机的话,GPFS 系统也将会关闭。其优势在于节点数较少时可用性较高,但节点数较多的情况建议采用 Node quorum 模式。
根据以上三种判断机制,GPFS 自动判断系统的状态,当异常发生时自动关闭系统以保护系统和数据的完整性。

GPFS 可靠性分析与如何设计
基于上面阐述的 GPFS 可用性机制,我们可以看出 GPFS 是通过上述的三种 quorum 机制来检查资源是否超过半数状态正常来判断系统状态好坏。我们在设计 GPFS 文件系统集群的时候需要注意最好保证各种资源数都为 2N+1 个(N 是指数量),也即数量为奇数,来获得系统最大的可用性。

Filesystem Descriptor (FD)Quorum 的设计。我们在一般的生产系统中都会使用两组不同的 failure group 的磁盘来创建一个文件系统,以实现数据的冗余保护,但是丢失一个 failure group 的磁盘实际不影响数据的完整性,但是由于 FD quorum 2N+1 的机制,文件系统仍将会关闭,所以我们在创建一个 GPFS 文件系统时,可以通过增加一个很小的本地的磁盘作为第三个 failure group。以实现 2N+1 的冗余设计。本地的磁盘可以设置为只保存 GPFS 文件系统信息(FD),实际不参与数据读写。(同一个 failure group 的磁盘是指有可能同时坏掉的磁盘,比如来自同一个存储的磁盘或连在同一个适配器上的磁盘)
Node Quorum 如果采用了 2N+1 个 Quorum Node,那么这个系统就能容忍 N 个主机节点的离线,所以如果主机节点小于 5 个采用此种方法都不是很经济,此时建议采用 Tiebreaker quorum 机制。
Tiebreaker quorum 只能配置两个 quorum 主机,但是只要 tiebreaker 磁盘在线,只有一个 quorum 主机状态正常,系统也能正常工作,同时也意味着必须有一台 quorum 主机在线。如果是主机节点数较多的情况,采用此种机制其可靠性不如 Node quorum。

参考链接:
https://www.ibm.com/developerworks/cn/aix/library/au-gpfsplan/

4.NSD设计
使用同等级别存储io或lun方面,避免短板,加宽条带化,增加并发读写能力。设置多个nsd server,设置nsd 顺序,均衡io

5.文件系统

根据以往的经验结合IBM官方建议,文件系统块大小设置可以参考以下内容:

在创建文件系统时,生产系统一般建议以下主要几个参数 -m2 -M2 -r2 -R2 ,当然根据具体需要增大某个值,其他参数并不是可以保持默认,根据情况再做适当调整。

总结:
以上这些参数的设置均不是绝对,而是结合以往历史经验参考设置,切记不可完全对号入座,根据实际情况进行适当调整。

五 故障诊断

故障诊断对于日常运维显得尤为重要,那么有一个清晰的问题处理流程,那么在问题出现时就不会过于慌乱,有条不紊进行GPFS 群集方面使用的问题。
GPFS 日常监控:

  1. IBM TPC软件 支持GPFS4.1 及以后版本
  2. 使用Dstat集成GPFS的插件
  3. 基于snmp的如zabbix监控
  4. Mmpmon监控性能
  5. 使用IBM提过的监控自定义脚本诸如:getio_s.ksh,gpfs_perf.pl,netperf,collect_stats

gpfs常用的诊断工具大多还是基于本身自带的一些tools,常用的命令有:
mmcluster,mmgetstate -aLs,mmlsconfig all,mmlnsd -aXv,mmchdisk ,mmlicense,mmdf,mmfsadm,mmdiag,mmrestripe,gpfs.snap 等等

下面我将结合着以往的实际经验,在问题诊断流程方面做一下梳理:

故障诊断流程:

  1. 网络是否正常
  2. 集群状态是否正常
  3. nsd磁盘状态是否正常
  4. 查看gpfs 日志
  5. 查看操作系统日志
  6. 具体日志报错参考手册和经验
  7. 收集故障信息给二线进行支持 当需要IBM支持的时候,IBM经常会让我们收集snap信息,具体方式如下: The command to collect GPFS Snap is "gpfs,snap" , this is very generic but very helpful.
# gpfs.snap

Note: The purpose of above command is to collect the snap on one node in the cluster,preferably the problematic one.
If the cluster is experiencing problems as a whole use -a flag

# gpfs.snap -a

Note1: -a flag only recommended for smaller clusters as it collects the logs for all of the nodes in the cluster.
Note2: -d option can specify the Output Directory but the default is /tmp/gpfs.snapOut.
==> Another recommendation is collect an mmfsadm dump waiters
/usr/lpp/mmfs/bin/mmfsadm dump waiters > gpfs.waiters
/usr/lpp/mmfs/bin/mmfsadm dump all > gpfs.dump.all
/usr/lpp/mmfs/bin/mmfsadm dump kthreads > gpfs.dump.kthreads
==> Another file you need to check is log file /var/adm/ras/mmfs.log.latest
This information will greatly assist development in reviewing performance or problematic issues in GPFS.

在这里我们列举一下,在GPFS的日常使用过程当中,经常或者遇到最多的问题,在此提供一些故障原因或解决参考建议。

  1. GPFS软件安装配置问题
    参考:
    选择支持操作系统版本
    安装必须的操作系统组件
    有的编译安装需要指定操作系统版本类型

  2. GPFS软件版本升级
    参考:
    滚动升级群集了集群节点版本,不影响正常整体使用
    条件允许的话可以关闭集群统一升级

  3. 如何动态添加磁盘到GPFS文件系统
    参考:
    使用支持盘符类型,盘符大小和以前最好保持一致
    编写NSD文件,使用支持的书写格式,版本不一致支持的类型不同

  4. GPFS 磁盘错误
    参考:
    没有配置failgroup,使用mmfsck和mmchdisk ,确实不行就需要考虑备份恢复
    有failgroup,如果NSD磁盘处于down状态,很多时候需要mmchdisk 或mmdelnsd 删除再从新添加修复

  5. GPFS NSD Failure Group 异常
    参考:
    如果nsd 所在nsd filegroup 异常,需要使用mmchdisk fs_name change -d nsd_name …方法修改为正确的failgroup id

  6. 群集节点故障或从新安装处理
    参考:
    群集中节点GPFS不能修复,那么备份正常节点集群配置,修改角色信息,从集群中提出故障节点,重新安装软件,添加至群集,修改参数配置和角色。

  7. GPFS网络异常以及网络调整
    参考:
    诊断是个别节点问题还是整体网络问题
    查看OS网络和物理硬件状态
    管理网络问题和数据网络问题
    修改节点ip或者添加允许通讯网络

8.删除或添加GPFS群集节点
参考:
删除:协助该节点文件系统,关闭节点,集群中提出节点
添加:安装软件,配置信任,集群添加节点,授权license

9.GPFS文件系统使用异常
参考:
没有挂载,不能正常访问
文件系统没有默认策略,没有指定数据池,空间写入异常
节点挂载出现stale file handle ,重启该故障节点或安装版本补丁或者是fs文件系统磁盘异常修复
参数设置不合理,没有设置复制等

10.群集部分或个别节点性能异常
参考:
版本兼容问题
数据网络异常
使用mmfsadm 和mmdiag 进行诊断
使用gpfs.snap 配合其他日志信息收集必要信息供二线诊断

11.集群如何能够均衡IO
参考:
NSD 设置io server顺序太集中
磁盘添加或删除后没有重新条带化mmrestripe

GPFS应用场景和发展空间的探讨

本次活动也在GPFS未来应用场景和未来发展方面进行了探讨:

  1. GPFS软件软件本身还是不错的,IBM全球知识共享库据说都是用GPFS文件系统进行搭建的,足以可以说明软件本身的健壮性和支持的规模力度,市场在变,新功能增添的速度也很快,导致在很多细节处理的很不到位,影响整体的使用体验。

  2. 前景不乐观,GPFS在4.11之后与时俱进的增加了云计算、大数据、云存储和对象存储等功能,但这些并不是GPFS所擅长的,新功能与专业软件和专业存储是有差距的,在传统的Server SAN方面也在在被竞争对手追赶,4.2.2.0之后好不容易增加了iSCSI功能,但问题很多,Oracle数据库方面12C R2依旧不支持Power linux,而AIX江河日下

总结:
本篇小文基于本次活动内容(GPFS 应用场景及日常运维管理交流),从软件发展历史,应用场景,群集概念,常用架构,群集搭建,日常监控,故障诊断以及针对GPFS软件当今现状和未来发展空间进行梳理,希望给大家一个相对清晰明了的认识,为日常的GPFS方面的工作带来便利,文章内容由于笔者经验有限不能涵盖全部内容,敬请谅解。感谢大家积极参与。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

8

添加新评论0 条评论

Ctrl+Enter 发表