简介： 灾难恢复是当前存储技术领域的热点之一。GPFS (General Parallel File System) 作为一个支持多节点的并行文件系统，在其长期运行过程中可能遇到各种问题（软件问题和硬件问题）而造成其中的某些节点不能正常工作。GPFS 提供了强大的功能来进行灾难恢复，以确保数据安全。本文根据 GPFS 的容灾特性提出了两种灾难恢复 ( disaster recovery) 的解决方案。一是将问题节点从 GPFS 集群中移除，使 GPFS 集群在剩下的健康节点上继续工作；二是重新安装配置问题节点，再对原有 GPFS 集群进行恢复，使其健康运行。采用这两种解决方案都可以快捷地恢复 GPFS 系统，从而保证整个 GPFS 集群正常的工作。最后，以实例的形式给出了详细的实现步骤以及实例分析。
GPFS 文件系统相关介绍
IBM General Parallel File System(GPFS) 是高性能、可扩展、并行文件系统。通过它，可以构建一个高可用、高性能的大型 Linux 计算机集群。GPFS 提供了强大的灾难恢复功能。从而，通过 GPFS 可以构建高可用的 Linux 集群。
GPFS 文件系统
GPFS 是一个并行的共享磁盘文件系统，它保证在资源组内的所有节点可以并行访问整个文件系统。GPFS 允许客户共享文件，而这些文件可能分布在不同节点的不同硬盘上。它提供了标准的 UNIX 文件系统接口。GPFS 能够很好的支持 UNIX 文件系统的工具，用户可以在 Linux 集群中像使用普通文件系统一样使用 GPFS 文件系统。它可以很好的应用在 Linux 集群中。
GPFS 节点可能发生的问题
GPFS 是由多个节点组成的集群系统，我们在 GPFS 长期运行过程中，可能有软件问题，比如集群中某个节点 GPFS 文件系统崩溃；也可能有硬件问题，比如系统磁盘坏掉，这样就会导致集群中某个节点不能工作。这些问题在 GPFS 集群长期运行过程中都是很可能遇到的问题，在遇到这种问题后，我们执行“mmgetstate – a”就会发现问题节点的状态不正常。状态“active”表示正常，其他状态都是异常。
node1:~ # mmgetstate -a
Node number Node name GPFS state
------------------------------------------
1 node1 active
2 node2 active
3 node3 unknown
用户针对这种情况都想尽快能够恢复整个集群的正常工作，把坏掉的节点尽快恢复工作。
GPFS 文件系统的灾难恢复（容灾特性）
GPFS 文件系统提供了很多特性可以来支持 GPFS 文件系统在发生问题时能够很好的进行灾难恢复使整个集群继续工作。首先 GPFS 是一个支持多节点的并行式文件系统，整个集群采用网络共享磁盘的方式，当其中任何一个节点发生问题时，其它节点能够及时接管问题节点的任务，从而保证整个集群能够继续工作。这样保证在集群中的其它节点健康的情况下可以及时接管问题节点的任务，我们可以尽快对问题节点进行恢复。
Linux 集群中 GPFS 灾难恢复方法及相关命令简介
我们通常在采用 GPFS 的 Linux 集群中某个节点发生硬件或者文件系统崩溃而不能正常工作时，那么整个集群中就会出现问题的节点。为了使原来的集群的所有节点都能健康的工作，我们可以有两种方法：一是把坏掉的节点从原有的集群中移除掉；二是把坏掉的节点的硬件问题解决之后重装该节点，并重新添加进 GPFS 集群中。下面我们来分别介绍两种方案。
方案一：通过移除 GPFS 问题节点来恢复
方案描述：
如果集群中有节点的硬件或者软件发生严重问题时，我们可以先把该节点从整个集群中移除掉，这样集群中就没有这个坏掉的节点，我们可以通过“mmgetstate – a”得到所有的节点都是“active”的状态。
方案流程 :
我们要从集群中移除掉坏掉的节点，就要改变记录整个 GPFS 集群配置信息的文件，把坏掉节点的信息删除，使 GPFS 集群中都没有坏掉节点的信息，这样这个坏掉节点就能够删除掉了。如下图所示，我们可以看到图中，本来三个节点的 GPFS 集群中，第三个节点坏了，我们把该问题节点移除后就成为一个只包含两个健康节点的集群。
图 1. 移除 GPFS 问题节点流程图
![GPFS 在 Linux 集群中的灾难恢复-LMLPHP]( "GPFS 在 Linux 集群中的灾难恢复-LMLPHP")
方案二：通过重装问题节点来恢复
方案描述：
当然还有另外一种方法就是，无论问题节点是发生硬件或者文件系统崩溃，我们在把硬件问题首先解决后，重装这个节点并把它加入我们的 GPFS 集群中来。下面我们对这种方案的实现进行介绍。
方案流程：
首先对原 GPFS 集群中配置信息文件 mmsdrfs 进行备份，对问题节点重装，把原有的 GPFS 配置信息文件还原到原来节点上面，使这个记录 GPFS 节点信息的配置文件能够生效我们需要对 GPFS 集群进行刷新。如图 2 所示，从图中我们可以看到第三个节点重装后，恢复 mmsdrfs 文件在坏掉之前的状态后重新加进集群后，形成三个节点的集群。
图 2. 恢复问题节点流程图
![GPFS 在 Linux 集群中的灾难恢复-LMLPHP]( "GPFS 在 Linux 集群中的灾难恢复-LMLPHP")
通过这两种方法后原有的 GPFS 集群中就会没有问题节点，集群以健康状态工作。而且最重要的一点是我们在移除节点或者重装节点之后，都能立即接管本来 GPFS 集群中的任务，顺利进行下去。
mmsdrfs 配置文件
我们无论是采取上述两种方案中的哪一种，都需要对 mmsdrfs 这个文件进行更新。下面对 mmsdrfs 这个文件进行简单的介绍。mmsdrfs 是一个很重要的文件，是整个 GPFS 文件系统的配置文件。它位于每个节点的 /var/mmfs/gen/ 目录下，这个文件保存了整个 GPFS 集群里所有节点的配置信息。mmsdrfs 里面第一个记录是一个随机生成的数字。当 GPFS 集群中的节点或者文件系统发生改变，在 mmsdrfs 文件里面这个数字都会有相应的改变。在 mmsdrfs 里面还记录了 GPFS 集群配置首要节点和 GPFS 集群配置次要节点。如果我们要改变 GPFS 中的节点那么首先要改变这个配置文件中关于节点的信息。所以我们在节点发生严重问题联系不到，不能直接执行“mmdelnode – a”的情况下，我们可以通过改变 mmsdrfs 文件，删除文件中包含问题节点的部分。
灾难恢复相关命令简介
对于 mmsdrfs 文件的操作，我们往往要用到 mmsdrrestore 和 mmsdrbackup 这两个命令。mmsdrrestore 是在 GPFS 集群灾难恢复中一个很重要的命令，可以用来恢复 GPFS 集群中指定节点的配置文件。我们在灾难恢复时主要是恢复 mmsdrfs 这个 GPFS 的重要配置文件。下面我给大家举例 mmsdrrestore 命令使用。如果我想恢复 GPFS 集群中 node1 上面的 GPFS 配置文件 /var/mmfs/gen/mmsdrfs。我们可以执行下面的命令。
mmsdrrestore – p node1 – F /var/mmfs/gen/mmsdrfs
还有一个命令 mmrefresh 同样也是在 GPFS 集群灾难恢复中比较常用的命令。它一般在集群中一些配置信息进行了更新之后，我们需要对整个 GPFS 集群进行刷新使新的配置文件生效。如果我们想要在整个 GPFS 集群中的所有节点上面执行，可以执行下面的命令：
mmrefresh – f
实例
下面我们以一个安装 GPFS 文件系统的 Linux 集群为例，如果集群中有一个节点的硬件发生问题，或者该节点的 GPFS 文件系统彻底坏掉，我们该怎么样来修复。下面我们分别应用上面提到的两种方案。
实验环境
安装 GPFS 的 Linux 集群，在本文中以三个节点为例，分别为 node1,node2 和 node3。
灾难模拟
通过把 GPFS 集群中某一节点的网线拔掉，使得集群中其它节点不能访问该节点的方式来模拟灾难的发生。我们假设环境中问题节点是 node3，需要被修复。可以利用 mmlscluster 和 mmgetstate 命令分别查看当前集群环境的节点数目和节点状态，如下：
node1:~ # mmlscluster
GPFS cluster information
========================
GPFS cluster name: node1
GPFS cluster id: 12402633003865615606
GPFS UID domain: node1
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
GPFS cluster configuration servers:
-----------------------------------
Primary server: node1
Secondary server: node2
Node Daemon node name IP address Admin node name
Designation
---------------------------------------------------------------------
1 node1 172.31.1.1 node1
quorum-manager
2 node2 172.31.1.2 node2
quorum-manager
3 node3 172.31.1.3 node3
quorum-manager
node2:/var/mmfs/gen # mmgetstate -a
Node number Node name GPFS state
------------------------------------------
1 node1 active
2 node2 active
3 node3 unknown
方案一：通过移除 GPFS 问题节点来恢复
方法一：首先我们尝试利用 mmdelnode 命令移除问题节点：
这个命令是集群内所有节点的 GPFS 都正常，能够联系到所有节点的情况下才会成功。但是当集群中有节点的 GPFS 或者硬件发生问题时，这个命令将无法成功，我们可以看到这个命令会失败。如下：
node1:~ # mmdelnode -N node3 Verifying GPFS is stopped on all affected nodes ...
mmdelnode: GPFS cluster configuration server node node3cannot
be removed.
mmdelnode: Command failed. Examine previous error messages to
determine cause.
这时需要我们利用 mmsdrfs 配置文件进行问题节点的移除。
方法二：在方法一失败的情况下我们利用 mmsdrfs 配置文件移除问题节点：
第一步是备份健康节点上的 mmsdrfs 配置文件：
首先到健康节点 node1 或 node2 中，把原来的 mmsdrfs 备份。如下：
node1:/var/mmfs/gen # cp mmsdrfs mmsdrfs.old
第二步是修改 mmsdrfs 配置文件：
把原来的 mmsdrfs 配置文件中包含问题节点内容的部分去掉，该配置文件中主要有两部分和节点相关的信息，首先第一个部分是其中关于成员节点部分，第二部分是 GPFS 和其他存储管理软件 TSM 相结合的部分，关于 TSM 的具体内容本文不详细讨论。这两部分内容我在下面的实例中以粗体标出，大家如果要删减可以照此操作。当删除节点是首要集群配置服务器或者次要集群配置服务器时，在文件第一句还会包括相关信息。当然删除之前不要忘记备份原文件。具体的 mmsdrfs 配置文件修改内容如下：
%%9999%%:00_VERSION_LINE::6:3:90::lc:node1:node2:1:/usr/bin/ssh:/usr/bin/scp:
12402633008479124940:lc2:1575927244::node2:0:0:0:0::::::
…
… %%home%%:20_MEMBER_NODE::3:3:node3:172.31.1.3:node3:manager::::::node3:node3:10 21:3.2.1.16:Linux:Q:0:N:9.11.96.125:E::::
%%home%%:70_MMFSCFG::1:# :::::::::::::::::::::::
%%home%%:70_MMFSCFG::2:# WARNING: This is a machine generated file. Do not
edit! ::::::::::::::::::::::
%%home%%:70_MMFSCFG::3:# Use the mmchconfig command to change configuration
parameters. :::::::::::::::::::::::
…
…
~%DSM%%:910_HSMDATA:%%home%%:28::::::::::::::::::::::::
~%DSM%%:910_HSMDATA:%%home%%:29::::::::::::::::::::::::
~%DSM%%:910_HSMDATA:%%home%%:42::::::::::::::::::::::::
把 mmsdrfs 文件中这些部分去掉之后，下面就需要对集群当中的信息进行及时的刷新，以使新的配置信息生效。
第三步是刷新集群信息：
执行如下命令使新的配置信息生效：
node1:/var/mmfs/gen # mmrefresh – f
最后一步我们要验证问题节点是否被移除成功：
利用 mmlscluster 和 mmgetstate 命令分别查看移除问题节点后的集群环境的节点数目和节点状态，如下：
node1:/var/mmfs/gen # mmlscluster
GPFS cluster information
========================
GPFS cluster name: node1
GPFS cluster id: 12402633003868883952
GPFS UID domain: node1
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
GPFS cluster configuration servers:
-----------------------------------
Primary server: node1
Secondary server: node2
Node Daemon node name IP address Admin node name
Designation
---------------------------------------------------------------------
1 node1 172.31.1.1 node1
quorum-manager
2 node2 172.31.1.2 node2
quorum-manager
node2:/var/mmfs/gen # mmgetstate -a
Node number Node name GPFS state
------------------------------------------
1 node1 active
2 node2 active
我们可以看到当前集群环境中只要两个节点，并且状态都为健康。问题节点 node3 已经被成功的从集群环境中移除掉。删除节点后不会影响我们正在进行的 NFS 传输文件等其他操作。
方案二：通过重装问题节点来恢复
当 GPFS 节点出现硬件问题或者系统崩溃后，修复后我们只能对问题节点进行重装。重新安装好 GPFS 之后，把健康节点上面的原来保存好的配置文件 mmsdrfs 复制到新安装好的节点上面，下面我们可以用 mmsdrrestore 来恢复新安装节点的 GPFS 配置文件。在执行这条命令前我们需要首先把所有节点上面的 GPFS 停掉，然后执行如下命令：
node3:~ # mmsdrrestore -F /var/mmfs/gen/mmsdrfs -N node1
Tue Dec 19 00:51:03 UTC 2009: mmsdrrestore: Processing node node3
Tue Dec 19 00:51:04 UTC 2009: mmsdrrestore: Processing node node1
mmsdrrestore: Command successfully completed
node3:~ # mmrefresh – f
然后同样的对GPFS 集群进行刷新，使最新的GPFS配置文件生效。
执行方案二前，我们执行mmlscluster看到的集群情况如下：
node2:/var/mmfs/gen # mmlscluster
GPFS cluster information
========================
GPFS cluster name: node1
GPFS cluster id: 12402633003868883952
GPFS UID domain: node1
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
GPFS cluster configuration servers:
-----------------------------------
Primary server: node1
Secondary server: node2
Node Daemon node name IP address Admin node name
Designation
---------------------------------------------------------------------
1 node1 172.31.1.1 node1
quorum-manager
2 node2 172.31.1.2 node2
quorum-manager
node2:/var/mmfs/gen # mmgetstate -a
Node number Node name GPFS state
------------------------------------------
1 node1 active
2 node2 active
执行方案二后，我们看到的集群情况如下：
node3:~ # mmlscluster
GPFS cluster information
========================
GPFS cluster name: node1
GPFS cluster id: 12402633003868883952
GPFS UID domain: node1
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
GPFS cluster configuration servers:
-----------------------------------
Primary server: node1
Secondary server: node2
Node Daemon node name IP address Admin node name
Designation
---------------------------------------------------------------------
1 node1 172.31.1.1 node1
quorum-manager
2 node2 172.31.1.2 node2
quorum-manager
3 node3 172.31.1.3 node3
quorum-manager
我们可以看到第三个节点的信息已经被添加进去。节点重新添加进去后可以及时接管 GPFS 现在正在进行的各项工作。
总结
基于 GPFS 的灾难恢复特性，在 GPFS（Linux 集群）某些节点发生硬件或软件问题时，我们能够很快的以文章介绍的两种方案进行灾难恢复，保证整个 GPFS 的所有节点在 Linux 集群中以健康的状态工作。
简介： 灾难恢复是当前存储技术领域的热点之一。GPFS (General Parallel File System) 作为一个支持多节点的并行文件系统，在其长期运行过程中可能遇到各种问题（软件问题和硬件问题）而造成其中的某些节点不能正常工作。GPFS 提供了强大的功能来进行灾难恢复，以确保数据安全。本文根据 GPFS 的容灾特性提出了两种灾难恢复 ( disaster recovery) 的解决方案。一是将问题节点从 GPFS 集群中移除，使 GPFS 集群在剩下的健康节点上继续工作；二是重新安装配置问题节点，再对原有 GPFS 集群进行恢复，使其健康运行。采用这两种解决方案都可以快捷地恢复 GPFS 系统，从而保证整个 GPFS 集群正常的工作。最后，以实例的形式给出了详细的实现步骤以及实例分析。
GPFS 文件系统相关介绍
IBM General Parallel File System(GPFS) 是高性能、可扩展、并行文件系统。通过它，可以构建一个高可用、高性能的大型 Linux 计算机集群。GPFS 提供了强大的灾难恢复功能。从而，通过 GPFS 可以构建高可用的 Linux 集群。
GPFS 文件系统
GPFS 是一个并行的共享磁盘文件系统，它保证在资源组内的所有节点可以并行访问整个文件系统。GPFS 允许客户共享文件，而这些文件可能分布在不同节点的不同硬盘上。它提供了标准的 UNIX 文件系统接口。GPFS 能够很好的支持 UNIX 文件系统的工具，用户可以在 Linux 集群中像使用普通文件系统一样使用 GPFS 文件系统。它可以很好的应用在 Linux 集群中。
GPFS 节点可能发生的问题
GPFS 是由多个节点组成的集群系统，我们在 GPFS 长期运行过程中，可能有软件问题，比如集群中某个节点 GPFS 文件系统崩溃；也可能有硬件问题，比如系统磁盘坏掉，这样就会导致集群中某个节点不能工作。这些问题在 GPFS 集群长期运行过程中都是很可能遇到的问题，在遇到这种问题后，我们执行“mmgetstate – a”就会发现问题节点的状态不正常。状态“active”表示正常，其他状态都是异常。
node1:~ # mmgetstate -a
Node number Node name GPFS state
------------------------------------------
1 node1 active
2 node2 active
3 node3 unknown
|
用户针对这种情况都想尽快能够恢复整个集群的正常工作，把坏掉的节点尽快恢复工作。
GPFS 文件系统的灾难恢复（容灾特性）
GPFS 文件系统提供了很多特性可以来支持 GPFS 文件系统在发生问题时能够很好的进行灾难恢复使整个集群继续工作。首先 GPFS 是一个支持多节点的并行式文件系统，整个集群采用网络共享磁盘的方式，当其中任何一个节点发生问题时，其它节点能够及时接管问题节点的任务，从而保证整个集群能够继续工作。这样保证在集群中的其它节点健康的情况下可以及时接管问题节点的任务，我们可以尽快对问题节点进行恢复。
Linux 集群中 GPFS 灾难恢复方法及相关命令简介
我们通常在采用 GPFS 的 Linux 集群中某个节点发生硬件或者文件系统崩溃而不能正常工作时，那么整个集群中就会出现问题的节点。为了使原来的集群的所有节点都能健康的工作，我们可以有两种方法：一是把坏掉的节点从原有的集群中移除掉；二是把坏掉的节点的硬件问题解决之后重装该节点，并重新添加进 GPFS 集群中。下面我们来分别介绍两种方案。
方案一：通过移除 GPFS 问题节点来恢复
方案描述：
如果集群中有节点的硬件或者软件发生严重问题时，我们可以先把该节点从整个集群中移除掉，这样集群中就没有这个坏掉的节点，我们可以通过“mmgetstate – a”得到所有的节点都是“active”的状态。
方案流程 :
我们要从集群中移除掉坏掉的节点，就要改变记录整个 GPFS 集群配置信息的文件，把坏掉节点的信息删除，使 GPFS 集群中都没有坏掉节点的信息，这样这个坏掉节点就能够删除掉了。如下图所示，我们可以看到图中，本来三个节点的 GPFS 集群中，第三个节点坏了，我们把该问题节点移除后就成为一个只包含两个健康节点的集群。
图 1. 移除 GPFS 问题节点流程图
方案二：通过重装问题节点来恢复
方案描述：
当然还有另外一种方法就是，无论问题节点是发生硬件或者文件系统崩溃，我们在把硬件问题首先解决后，重装这个节点并把它加入我们的 GPFS 集群中来。下面我们对这种方案的实现进行介绍。
方案流程：
首先对原 GPFS 集群中配置信息文件 mmsdrfs 进行备份，对问题节点重装，把原有的 GPFS 配置信息文件还原到原来节点上面，使这个记录 GPFS 节点信息的配置文件能够生效我们需要对 GPFS 集群进行刷新。如图 2 所示，从图中我们可以看到第三个节点重装后，恢复 mmsdrfs 文件在坏掉之前的状态后重新加进集群后，形成三个节点的集群。
图 2. 恢复问题节点流程图
通过这两种方法后原有的 GPFS 集群中就会没有问题节点，集群以健康状态工作。而且最重要的一点是我们在移除节点或者重装节点之后，都能立即接管本来 GPFS 集群中的任务，顺利进行下去。
mmsdrfs 配置文件
我们无论是采取上述两种方案中的哪一种，都需要对 mmsdrfs 这个文件进行更新。下面对 mmsdrfs 这个文件进行简单的介绍。mmsdrfs 是一个很重要的文件，是整个 GPFS 文件系统的配置文件。它位于每个节点的 /var/mmfs/gen/ 目录下，这个文件保存了整个 GPFS 集群里所有节点的配置信息。mmsdrfs 里面第一个记录是一个随机生成的数字。当 GPFS 集群中的节点或者文件系统发生改变，在 mmsdrfs 文件里面这个数字都会有相应的改变。在 mmsdrfs 里面还记录了 GPFS 集群配置首要节点和 GPFS 集群配置次要节点。如果我们要改变 GPFS 中的节点那么首先要改变这个配置文件中关于节点的信息。所以我们在节点发生严重问题联系不到，不能直接执行“mmdelnode – a”的情况下，我们可以通过改变 mmsdrfs 文件，删除文件中包含问题节点的部分。
灾难恢复相关命令简介
对于 mmsdrfs 文件的操作，我们往往要用到 mmsdrrestore 和 mmsdrbackup 这两个命令。mmsdrrestore 是在 GPFS 集群灾难恢复中一个很重要的命令，可以用来恢复 GPFS 集群中指定节点的配置文件。我们在灾难恢复时主要是恢复 mmsdrfs 这个 GPFS 的重要配置文件。下面我给大家举例 mmsdrrestore 命令使用。如果我想恢复 GPFS 集群中 node1 上面的 GPFS 配置文件 /var/mmfs/gen/mmsdrfs。我们可以执行下面的命令。
mmsdrrestore – p node1 – F /var/mmfs/gen/mmsdrfs |
还有一个命令 mmrefresh 同样也是在 GPFS 集群灾难恢复中比较常用的命令。它一般在集群中一些配置信息进行了更新之后，我们需要对整个 GPFS 集群进行刷新使新的配置文件生效。如果我们想要在整个 GPFS 集群中的所有节点上面执行，可以执行下面的命令：
mmrefresh – f |
实例
下面我们以一个安装 GPFS 文件系统的 Linux 集群为例，如果集群中有一个节点的硬件发生问题，或者该节点的 GPFS 文件系统彻底坏掉，我们该怎么样来修复。下面我们分别应用上面提到的两种方案。
实验环境
安装 GPFS 的 Linux 集群，在本文中以三个节点为例，分别为 node1,node2 和 node3。
灾难模拟
通过把 GPFS 集群中某一节点的网线拔掉，使得集群中其它节点不能访问该节点的方式来模拟灾难的发生。我们假设环境中问题节点是 node3，需要被修复。可以利用 mmlscluster 和 mmgetstate 命令分别查看当前集群环境的节点数目和节点状态，如下：
node1:~ # mmlscluster
GPFS cluster information
========================
GPFS cluster name: node1
GPFS cluster id: 12402633003865615606
GPFS UID domain: node1
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
GPFS cluster configuration servers:
-----------------------------------
Primary server: node1
Secondary server: node2
Node Daemon node name IP address Admin node name
Designation
---------------------------------------------------------------------
1 node1 172.31.1.1 node1
quorum-manager
2 node2 172.31.1.2 node2
quorum-manager
3 node3 172.31.1.3 node3
quorum-manager
node2:/var/mmfs/gen # mmgetstate -a
Node number Node name GPFS state
------------------------------------------
1 node1 active
2 node2 active
3 node3 unknown
|
方案一：通过移除 GPFS 问题节点来恢复
方法一：首先我们尝试利用 mmdelnode 命令移除问题节点：
这个命令是集群内所有节点的 GPFS 都正常，能够联系到所有节点的情况下才会成功。但是当集群中有节点的 GPFS 或者硬件发生问题时，这个命令将无法成功，我们可以看到这个命令会失败。如下：
node1:~ # mmdelnode -N node3 Verifying GPFS is stopped on all affected nodes ... mmdelnode: GPFS cluster configuration server node node3cannot be removed. mmdelnode: Command failed. Examine previous error messages to determine cause. |
这时需要我们利用 mmsdrfs 配置文件进行问题节点的移除。 |
方法二：在方法一失败的情况下我们利用 mmsdrfs 配置文件移除问题节点：
第一步是备份健康节点上的 mmsdrfs 配置文件：
首先到健康节点 node1 或 node2 中，把原来的 mmsdrfs 备份。如下：
node1:/var/mmfs/gen # cp mmsdrfs mmsdrfs.old |
第二步是修改 mmsdrfs 配置文件：
把原来的 mmsdrfs 配置文件中包含问题节点内容的部分去掉，该配置文件中主要有两部分和节点相关的信息，首先第一个部分是其中关于成员节点部分，第二部分是 GPFS 和其他存储管理软件 TSM 相结合的部分，关于 TSM 的具体内容本文不详细讨论。这两部分内容我在下面的实例中以粗体标出，大家如果要删减可以照此操作。当删除节点是首要集群配置服务器或者次要集群配置服务器时，在文件第一句还会包括相关信息。当然删除之前不要忘记备份原文件。具体的 mmsdrfs 配置文件修改内容如下：
%%9999%%:00_VERSION_LINE::6:3:90::lc:node1:node2:1:/usr/bin/ssh:/usr/bin/scp: 12402633008479124940:lc2:1575927244::node2:0:0:0:0:::::: … … %%home%%:20_MEMBER_NODE::3:3:node3:172.31.1.3:node3:manager::::::node3:node3:10 21:3.2.1.16:Linux:Q:0:N:9.11.96.125:E:::: %%home%%:70_MMFSCFG::1:# ::::::::::::::::::::::: %%home%%:70_MMFSCFG::2:# WARNING: This is a machine generated file. Do not edit! :::::::::::::::::::::: %%home%%:70_MMFSCFG::3:# Use the mmchconfig command to change configuration parameters. ::::::::::::::::::::::: … … ~%DSM%%:910_HSMDATA:%%home%%:28:::::::::::::::::::::::: ~%DSM%%:910_HSMDATA:%%home%%:29:::::::::::::::::::::::: ~%DSM%%:910_HSMDATA:%%home%%:42:::::::::::::::::::::::: |
把 mmsdrfs 文件中这些部分去掉之后，下面就需要对集群当中的信息进行及时的刷新，以使新的配置信息生效。
第三步是刷新集群信息：
执行如下命令使新的配置信息生效： node1:/var/mmfs/gen # mmrefresh – f |
最后一步我们要验证问题节点是否被移除成功：
利用 mmlscluster 和 mmgetstate 命令分别查看移除问题节点后的集群环境的节点数目和节点状态，如下：
node1:/var/mmfs/gen # mmlscluster GPFS cluster information ======================== GPFS cluster name: node1 GPFS cluster id: 12402633003868883952 GPFS UID domain: node1 Remote shell command: /usr/bin/ssh Remote file copy command: /usr/bin/scp GPFS cluster configuration servers: ----------------------------------- Primary server: node1 Secondary server: node2 Node Daemon node name IP address Admin node name Designation --------------------------------------------------------------------- 1 node1 172.31.1.1 node1 quorum-manager 2 node2 172.31.1.2 node2 quorum-manager node2:/var/mmfs/gen # mmgetstate -a Node number Node name GPFS state ------------------------------------------ 1 node1 active 2 node2 active |
我们可以看到当前集群环境中只要两个节点，并且状态都为健康。问题节点 node3 已经被成功的从集群环境中移除掉。删除节点后不会影响我们正在进行的 NFS 传输文件等其他操作。
方案二：通过重装问题节点来恢复
当 GPFS 节点出现硬件问题或者系统崩溃后，修复后我们只能对问题节点进行重装。重新安装好 GPFS 之后，把健康节点上面的原来保存好的配置文件 mmsdrfs 复制到新安装好的节点上面，下面我们可以用 mmsdrrestore 来恢复新安装节点的 GPFS 配置文件。在执行这条命令前我们需要首先把所有节点上面的 GPFS 停掉，然后执行如下命令：
node3:~ # mmsdrrestore -F /var/mmfs/gen/mmsdrfs -N node1 Tue Dec 19 00:51:03 UTC 2009: mmsdrrestore: Processing node node3 Tue Dec 19 00:51:04 UTC 2009: mmsdrrestore: Processing node node1 mmsdrrestore: Command successfully completed node3:~ # mmrefresh – f |
然后同样的对GPFS 集群进行刷新，使最新的GPFS配置文件生效。
执行方案二前，我们执行mmlscluster看到的集群情况如下：
node2:/var/mmfs/gen # mmlscluster
GPFS cluster information
========================
GPFS cluster name: node1
GPFS cluster id: 12402633003868883952
GPFS UID domain: node1
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
GPFS cluster configuration servers:
-----------------------------------
Primary server: node1
Secondary server: node2
Node Daemon node name IP address Admin node name
Designation
---------------------------------------------------------------------
1 node1 172.31.1.1 node1
quorum-manager
2 node2 172.31.1.2 node2
quorum-manager
node2:/var/mmfs/gen # mmgetstate -a
Node number Node name GPFS state
------------------------------------------
1 node1 active
2 node2 active
执行方案二后，我们看到的集群情况如下：
node3:~ # mmlscluster
GPFS cluster information
========================
GPFS cluster name: node1
GPFS cluster id: 12402633003868883952
GPFS UID domain: node1
Remote shell command: /usr/bin/ssh
Remote file copy command: /usr/bin/scp
GPFS cluster configuration servers:
-----------------------------------
Primary server: node1
Secondary server: node2
Node Daemon node name IP address Admin node name
Designation
---------------------------------------------------------------------
1 node1 172.31.1.1 node1
quorum-manager
2 node2 172.31.1.2 node2
quorum-manager
3 node3 172.31.1.3 node3
quorum-manager
|
我们可以看到第三个节点的信息已经被添加进去。节点重新添加进去后可以及时接管 GPFS 现在正在进行的各项工作。
总结
基于 GPFS 的灾难恢复特性，在 GPFS（Linux 集群）某些节点发生硬件或软件问题时，我们能够很快的以文章介绍的两种方案进行灾难恢复，保证整个 GPFS 的所有节点在 Linux 集群中以健康的状态工作。