内容


从 IBM PowerHA 集群中的资源故障中恢复

Comments

简介

目前,有许多客户在其数据中心使用 Power 服务器,其中许多客户使用了 IBM AIX® 高可用性软件,通过灾难恢复管理让关键应用程序高度可用。本文将介绍在遇到由于错误输入而导致的任何应用程序或资源故障时,如何在不停止集群服务的情况下,使用 IBM PowerHA SystemMirror 特性让集群进入稳定状态。由于资源或应用程序中的错误输入,集群可能会进入不稳定状态,而资源组可能进入错误状态。PowerHA 提供的特性使得集群可以在更正错误输入后进入稳定状态,而且可以根据策略来激活资源,无需停止集群服务。本文将介绍资源组中包含应用程序故障的资源故障。

配置 PowerHA 集群

有关 IBM PowerHA 是什么和如何在 AIX 系统上配置 PowerHA 的详细信息,请参阅 PowerHA 简介 文章。本文将介绍如何配置包含 2 个节点的基础 PowerHA 集群。类似地,您可以创建多个集群,根据存储库磁盘来进行站点分离。基于站点的集群可以是延伸集群 (stretched cluster) 或链接集群,延伸集群位于配置链接集群的相同位置,其中数据中心位于不同的地理位置。

本文将介绍如何使用 4 节点延伸集群从集群中的应用程序故障中恢复。图 1 给出了一种 4 节点延伸集群设置。

图 1. 延伸集群的 PowerHA 集群配置

在此集群中,创建了一个网络和 3 个资源组。RG1 是非并发资源组,其他两个资源组是并发资源组。集群从 SiteANode1 创建,更改会通过验证和同步特性传播到集群中的所有节点。

以下 cltopinfo 实用程序输出显示了基本的集群信息。

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
# cltopinfo
Cluster Name:    test_cluster
Cluster Type:    Stretched
Heartbeat Type:  Multicast
Repository Disk: hdisk11 (00f601bbb83e6a40)
Cluster IP Address: 228.40.0.25
Cluster Nodes:
        Site A (siteA):
                SiteANode1
                SiteANode2
        Site B (siteB):
                SiteBNode1
                SitebNode2

There are four node(s) and one network(s) defined.

NODE SiteANode1:
        Network net_ether_01
                service_ip1     1.1.1.10
                SiteANode1        10.40.0.25

NODE SiteANode2:
        Network net_ether_01
                service_ip1     1.1.1.10
                SiteANode2        10.40.0.26

NODE SiteBNode1:
        Network net_ether_01
                service_ip1     1.1.1.10
                SiteBNode1        10.40.0.43

NODE SiteBNode2:
        Network net_ether_01
                service_ip1     1.1.1.10
                SiteBNode2        10.40.0.44

Resource Group RG1_conc
        Startup Policy   Online On All Available Nodes
        Fallover Policy  Bring Offline (On Error Node Only)
        Fallback Policy  Never Fallback
        Participating Nodes      SiteANode1 SiteANode2 SiteBNode1 SitebNode2

Resource Group RG2_conc
        Startup Policy   Online On All Available Nodes
        Fallover Policy  Bring Offline (On Error Node Only)
        Fallback Policy  Never Fallback
        Participating Nodes      SiteANode1 SiteANode2 SiteBNode1 SitebNode2

Resource Group RG1
        Startup Policy   Online On Home Node Only
        Fallover Policy  Fallover To Next Priority Node In The List
        Fallback Policy  Fallback To Higher Priority Node In The List
        Participating Nodes      SiteANode1 SiteANode2 SiteBNode1 SitebNode2
        Service IP Label                 service_ip1

将应用程序控制器脚本添加到 PowerHA

假设有一个应用程序位于服务器中的主目录中,我们需要使用 PowerHA 让该应用程序高度可用。所以我们要有一个应用程序控制器启动和停止脚本,还要有监视器脚本,用来监视集群中的应用程序。一个应用程序将被添加到资源组中的一个卷组下,而且还会在该卷组上创建一个文件系统。

在本文中,已创建的应用程序 app1 有一个启动脚本、停止脚本和监视器脚本,还有控制器 app1_test。此应用程序可通过文件系统 /fs1 和卷组 VG1 进行访问。该应用程序是资源组 RG1 下的一个资源。

以下是应用程序启动脚本、停止脚本和监视器脚本,它们在激活集群和挂载文件系统后执行基本的读/写操作。

(0) root @ SiteANode1: /home/scripts  ----------------- Start script
# cat app1_start
#!/usr/bin/ksh
/home/scripts/app1 /fs1/a /fs1/b /fs1/c /fs1/d /fs1/e > /dev/null &

(0) root @ SiteANode1: /home/scripts ----------------- Stop script
# cat  app1_stop
#!/usr/bin/ksh
ps -ef | grep -w /home/scripts/app1 | grep -v grep | awk '{print $2}' | read pid
if [ $pid ]
then
       echo "printing that app1 is stopped"
        kill -9 $pid
fi

(0) root @ SiteANode1: /home/scripts --------------- Monitor scripts 
# cat app_mon1
#!/usr/bin/ksh
ps -ef | grep -w /home/scripts/app1  | grep -v grep | awk '{print $2}'| read pid
if [ $pid ]
then
        return 0
fi
return 1

这一节将演示如何将应用程序控制器和监视器脚本添加到 PowerHA 集群中。

  1. 添加应用程序控制器

使用 smit 命令打开 PowerHA 的 System Management Interface Tool (SMIT)。在命令提示符上运行 smit hacmp 命令。在显示的 Cluster Applications and Resource SMIT 屏幕上,选择

Cluster Applications and Resource → Resource → Configure User Applications (Scripts and Monitors) → Application Controller Scripts → Add Application Controller Scripts。

图 2 显示了添加应用程序控制器脚本的屏幕。第一个字段 是必填的,因为它询问控制器名称。应用程序控制器名称由用户定义。第二个字段 用于添加启动脚本,第三个字段 用于添加停止脚本。监视器脚本尚未添加,所以没有显示它。监视器脚本可在创建应用程序控制器之后或之前添加。

图 2. 添加应用程序控制器脚本的 SMIT 屏幕
  1. 添加应用程序控制器的监视器脚本

使用 smit hacmp 命令打开 SMIT 界面,选择以下选项来打开 Add a Custom and Application Monitor 屏幕。

Cluster Applications and Resource → Resource → Configure User Applications (Scripts and Monitors) → Application Monitors → Configure Custom Application Monitors → Add a Custom Application Monitor。

图 3. 添加应用程序监视器的 SMIT 屏幕

下一节将介绍如何输入图 3 中显示的参数,同时创建一个应用程序监视器。

  • Monitor Name – 此参数是用户定义的,添加的监视器可以监视应用程序控制器脚本。
  • Application Controller to Monitor – 添加图 1 中创建的应用程序控制器。
  • Monitor Mode – 这是选中的模式,其中将执行应用程序控制器的监视。
  • Monitor Method – 您需要提供监视器脚本的完整路径。
  • Stabilization Interval – 用于设置用户定义的事件间隔,稳定间隔设置为 30 秒。稳定间隔时间是如果应用程序正常启动,集群进入稳定状态和资源进入在线状态需要等待的时间,但如果由于任何故障导致应用程序未启动,则会重新启动应用程序。
  • Restart Count – 将会重新启动应用程序控制器,如果未分配重新启动计数,则会故障转移到下一个节点。这里提到的重新启动计数为 3,所以如果应用程序未能在 3 次重新启动后进入稳定状态,应用程序将会故障转移到下一个优先级节点。在这种情况下,资源组将进入这个特定节点上的 ERROR 状态,集群将进入 UNSTABLE 状态,而且如果资源组处于 ERROR 状态,集群将进入 RP_FAILED 状态。
  1. 将创建的应用程序添加到资源组中

使用 smit hacmp 命令打开 SMIT 界面,选择以下选项来打开 Change/Show Resources and Attributes for a Resource Group 屏幕。

Cluster Applications and Resources → Resource Groups → Change/Show Resources and Attributes for a Resource Group。

系统会询问选择将应用程序和文件系统添加到哪个资源组。

图 4. 集成到资源组的应用程序和文件系统的资源组选择

在这里,应用程序和文件系统将被添加到资源组 RG1

图 5. 向 RG1 添加资源和属性的 SMIT 屏幕

所以要理解应用程序的集群恢复特性,需要将应用程序控制器 app1_test 添加到资源组 RG1 中。此应用程序位于文件系统 /fs1 和卷组 VG1 下。

  1. 从故障中恢复集群

为了理解如何从应用程序故障中恢复,我们将在所有节点上的启动脚本中更改应用程序的路径。最初,启动脚本位于 /home/scripts 中,现在将更改一个启动脚本的路径来引发应用程序故障。

实际启动脚本

(0) root @ SiteANode1: /home/scripts  ----------------- Start script
# cat app1_start
#!/usr/bin/ksh
/home/scripts/app1 /fs1/a /fs1/b /fs1/c /fs1/d /fs1/e > /dev/null &

更改启动脚本的应用程序脚本路径

0) root @ SiteANode1: /home/scripts  ----------------- Start script
# cat app1_start
#!/usr/bin/ksh
/home/test/app1 /fs1/a /fs1/b /fs1/c /fs1/d /fs1/e > /dev/null &

在启动集群服务后,由于脚本的错误输入和重新启动计数,系统将不断重新启动应用程序控制器。这可在 /var/hacmp/log/hacmp.out 文件中看到,由于应用程序控制器的这个错误输入,集群不会进入稳定状态。在上述脚本中具有错误路径时,应用程序将无法进入稳定状态。

如果只有一个节点上的脚本中存在错误路径,资源组会尝试在这个特定节点上上线,但完成 3 次重新启动计数后,它会故障转移到下一个节点(依据图 3 中设置的重新启动计数),如果下一个节点的应用程序中的所有配置都是正确的,集群将会保持稳定,资源组将在该节点上上线。

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
# clRGinfo
-----------------------------------------------------------------------------
Group Name                   State            Node
-----------------------------------------------------------------------------
RG1_conc            ONLINE           SiteANode1
                    ONLINE           SiteANode2
                    ONLINE           SiteBNode1
                    ONLINE           SitebNode2

RG2_conc            ONLINE           SiteANode1
                    ONLINE           SiteANode2
                    ONLINE           SiteBNode1
                    ONLINE           SiteBNode2

RG1                 ERROR           SiteANode1@siteA
                    OFFLINE         SiteANode2@siteA
                    OFFLINE         SiteBNode1@siteB
                    OFFLINE         SiteBNode2@siteB


(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_RP_RUNNING
Current state: ST_RP_RUNNING
Current state: ST_RP_RUNNING
Current state: ST_RP_RUNNING

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_BARRIER
Current state: ST_BARRIER
Current state: ST_BARRIER
Current state: ST_BARRIER

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_BARRIER
Current state: ST_BARRIER
Current state: ST_BARRIER
Current state: ST_BARRIER

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_CBARRIER
Current state: ST_CBARRIER
Current state: ST_CBARRIER
Current state: ST_CBARRIER

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
#  clcmd lssrc -ls clstrmgrES| grep state
Current state: ST_UNSTABLE
Current state: ST_UNSTABLE
Current state: ST_UNSTABLE
Current state: ST_UNSTABLE

该资源组下的应用程序也不会启动

(0) root @ SiteANode1: /usr/es/sbin/cluster/utilities
# ps -ef| grep app1
    root 16187668 15598018   0 10:13:36  pts/0  0:00 grep app1

因此,在这种情况下,应用程序 app1 启动失败,原因在于所提及的启动脚本中错误的应用程序路径。所以,Cluster Manager 将在 /var/hacmp/log/hacmp.out 文件中报告事件故障,如图 6 所示。所以依据 hacmp.out 消息,需要手动干预。现在手动更改启动脚本中的路径,以便从 RG 恢复到 ERROR 状态,将集群恢复到 UNSTABLE 或 RP_FAILED 状态。

0) root @ SiteANode1: /home/scripts  ----------------- Start script
# cat app1_start
#!/usr/bin/ksh
/home/scripts/app1 /fs1/a /fs1/b /fs1/c /fs1/d /fs1/e > /dev/null & ---- >  correct path .
图 6. 可在 hacmp.out 日志中查看应用服务器故障消息

手动更改脚本后,HACMP 会提供从故障恢复的特性,该特性将在集群实用程序下运行一个 clruncmd 脚本。PowerHA 还为 SMIT 提供了脚本故障恢复选项。在命令提示符上运行 smit hacmp 命令,选择以下选项。

Problem Determination Tools → Recover From PowerHA SystemMirror Script Failure。

在这里,用户可以依次选择所需的节点。

图 7. 从 PowerHA 脚本故障恢复的 SMIT 屏幕

从脚本故障恢复的选项将运行 /usr/es/sbin/cluster/utilities/clruncmd 命令,这会向所选节点上的 Cluster Manager Daemon 发送一条消息。这会使集群能够在该节点上进入稳定状态,如果脚本是正确的,资源组也将在该节点上上线。解决这个问题后,就可以在 /var/hacmp/log/hacmp.out 文件中看到已完成的事件。如果所有节点上的资源组都进入 ERROR 状态,则意味着所有节点上都存在错误的输入。因此,在这种情况下,必须在纠正所有节点上的错误输入后,手动将资源组上线,就好像资源组在一个节点上处于 ERROR 状态,从集群脚本故障中恢复可在更正错误输入后让它进入正确状态。

如果某个脚本由于提供给 PowerHA 的输入错误而发生故障,Cluster Manager 将在 hacmp.out 中报告故障。更正错误输入后,可重新使用 Cluster Manager 让集群进入 STABLE 状态。RECOVERY FROM SCRIPT FAILURE OPTION 将运行 PowerHA 的 clruncmd 实用程序,这会向一个选定集群上的 Cluster Manager Daemon 发送一条消息,从而让集群进入稳定状态,如果资源组由于提供给资源的输入错误而进入 ERROR 状态,也会让资源组进入正确状态。用户需要在 hacmp.out 文件中看到错误后手动更改错误输入。因此,从脚本故障恢复集群,将让集群进入正确状态,事件将会在 hacmp.out 中完成。

结束语

如果错误输入导致资源或应用程序出现故障,本文可帮助用户从所导致的集群故障中恢复。客户可在纠正提供给资源的错误输入后,让集群进入稳定状态,让资源组进入可访问的状态。

参考资料


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=AIX and UNIX
ArticleID=1014528
ArticleTitle=从 IBM PowerHA 集群中的资源故障中恢复
publish-date=09082015