11 群集日志记录、诊断和测试

本章介绍了可用于测试 ACSLS HA 安装、以及可用于诊断和解决系统上可能会出现的问题的各种资源。

监视整体群集操作

执行启动或切换事件期间发生的活动会在两个节点之间广泛分布。因此,所选用于在测试期间查看整体运行状况的有利时机能够在很大程度上确定在展开的事件发生时对其进行查看的能力。ha_console.sh 实用程序介绍了有关设置综合视图的过程。

建议将用于查看测试期间 HA 整体行为的显示板配置为八个 shell 窗口,其中一个节点四个窗口。

  1. 应在每个节点上保留 root 的命令 shell 以根据需要断言各种命令

  2. 每个节点设置一个窗口以显示系统 /var/adm/messages 文件的末尾。

    # tail -f /var/adm/messages
    

    Solaris Cluster 将所有提示性消息输出到此日志文件。

  3. 每个节点另外设置一个窗口以显示 acsls-rs 资源 start_stop 日志的末尾。

    # tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt
    

    此处显示了 acsls_agt.sh 启动脚本发布的所有消息。

  4. 每个节点上的第三个窗口应设置为显示 acsls-rs 探测日志的末尾。

    # tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/probe_log.txt
    

    应用程序启动后,Solaris Cluster 每分钟就会探测一次 ACSLS 资源。每次探测后都会向 Cluster 返回一个数字代码,结果会输出到 probe_log.txt 文件中。经过每次探测后,都可以看到发布到此日志的以下五个标准返回值中的任意值:

      0 -  The probe found that ACSLS is healthy and functioning normally.
      1 -  The probe may not have completed due to a functional error.
      2 -  The probe reports that ACSLS is in a transitional state.
      3 -  The ACSLS application has been intentionally placed offline.
    201 -  A condition was detected that requires fail-over action.
    

    对代码 201 的唯一响应就是 Solaris Cluster 应启动故障转移操作。ACSLS 群集运行一章中列出了提示执行此类操作的情况。Cluster 探测的所有其他返回代码均被视为提示性消息且不断言任何 Cluster 响应操作。

    用于测试的样例探测可随时通过命令行进行断言。使用 acsAgt probe

    #/opt/ACSLSHA/util/acsAgt probe 
    

上面提及的所有日志均反映了对 Solaris Cluster 可见的系统视图。 $ACS_HOME/log/ 目录中的两个附加日志提供了一个 ACSLS 应用程序级别的视图。acsss_event.log 报告 ACSLS 自应用程序启动时起所遇到的所有重要事件。acsls_start.log 中记录 SMF 遇到的所有 ACSLS 启动难题。

群集监视实用程序

Solaris Cluster 实用程序位于 /usr/cluster/bin 目录中。

  • 查看 ACSLS 资源组的当前状态: clrg list -v

  • 查看两个群集节点的当前状态:clrg status

  • 查看资源组的状态:clrs status

  • 获取关于节点、法定设备和群集资源的详细状态:cluster status

  • 获取群集配置中的详细组件列表:cluster show

  • 查看资源组中每个以太网节点的状态:clnode status -m

  • 查看每个节点上各种 acsls-rg 资源的状态:scstat -g

  • 查看心跳网络链路的运行状况:clintr status

  • 查看 IPMP 状态:scstat -i

  • 查看节点状态:scstat -n

  • 查看法定配置和状态:scstat -qclq status

  • 显示详细的群集资源,包括超时值:clresource show -v

恢复和故障转移测试

本节介绍了关于恢复和故障转移测试的状况、监视和测试。

恢复状况

有许多致命的系统状况无需执行系统故障转移即可恢复。例如,使用 IPMP 时,每个组中的一个以太网连接可能会因某种原因失败,但是通信应当通过备用路径无中断地继续。

共享磁盘阵列应当通过每台服务器上的两个不同端口连接到服务器。如果一条路径中断,磁盘 I/O 操作应当通过备用路径无中断地继续进行。

ACSLS 包括由 Solaris 服务管理工具 (Service Management Facility, SMF) 监视的多项软件服务。作为用户 acsss,可以通过命令 acsss status 列出每项 acsss 服务。这些服务包括 PostgreSQL 数据库、WebLogic Web 应用服务器和 ACSLS 应用程序软件。如果任意给定服务在 Solaris 系统上失败,则 SMF 应当自动重新引导该服务且不需要执行系统故障转移。

acsls 服务本身包括由父进程 acsss_daemon 监视的许多子进程。要列出 ACSLS 子进程,请使用 psacs 命令(以 acsss 用户身份)。如果任何子进程因任何原因而中止,则父进程应当立即重新引导该子进程并恢复正常运行。

恢复监视

查看系统资源(例如磁盘 I/O 和以太网连接)的恢复的最佳位置是系统日志 /var/adm/messages

SMF 为它监视的每项软件服务维护着一个特定的日志。此日志显示启动、重新启动和关闭事件。要获取服务日志的完整路径,请运行命令 svcs -l service-name。可以使用 acsss 命令 $ acsss status 列出 ACSLS 服务。可以使用命令
$ acsss p-status
列出子进程。

要查看任何 ACSLS 子进程的恢复,可以监视 acsss_event.log ($ACS_HOME/ACSSS/log/acsss_event.log)。此日志显示涉及任何 ACSLS 子进程的所有恢复事件。

恢复测试

冗余网络连接应当由 Solaris IPMP 逻辑自动重新启动。与共享磁盘阵列之间的任何中断的数据连接都应当由 Solaris 在冗余数据路径上自动重新启动。由 Solaris 服务管理工具 (Service Management Facility, SMF) 控制的服务应当由 SMF 自动重新启动。

对于涉及实际故障转移事件的测试,您应当知道文件 $ACS_HOME/acslsha/pingpong_interval 中定义的属性设置。不管可能触发故障转移事件的状况是什么,如果在指定的 pingpong_interval 内已发生了一次故障转移事件,则 Solaris Cluster 将不会启动故障转移操作。

要查看或动态更改乒乓 (pingpong) 间隔,请转到 /opt/ACSLSHA/util 目录并运行 acsAgt pingpong

# ./acsAgt pingpong
Pingpong_interval
   current value:  1200 seconds.
   desired value: [1200] 300
Pingpong_interval : 300 seconds.

使用以下任意或所有技术评估 HA 安装的恢复能力:

  1. 在 ACSLS 正常运行时,从活动节点上的每个 IPMP 组断开一个以太网连接。使用 # scstat -i 监视状态。

    观察 /var/adm/messages 中的反应。此过程应当不会中断 ACSLS 运行。

  2. 确保将 Cluster 的 Failover_mode 设置为 HARD。在 ACSLS 正常运行时,断开从活动服务器到共享磁盘资源的一个光纤或 SAS 连接。

    观察 /var/adm/messages 中的反应。此过程应当不会中断 ACSLS 运行。

    对每个冗余的 I/O 连接重复此测试。

  3. 通过终止 acsss_daemon 突然终止 ACSLS。使用 pkill acsss_daemon

    运行 svcs -l acsls 以定位服务日志。

    acsss_daemon 停止时查看此日志的末尾,观察到此服务由 SMF 自动重新启动。如果使用 acsls shutdown 停止 acsls,应当会看到类似的操作。

  4. 使用 SMF 禁用 acsls 服务。

    这可以 root 用户身份使用 svcadm disable acsls 来执行,也可以 acsss 用户身份使用 acsss disable 来执行。

    因为 SMF 负责此关闭事件,所以不会尝试重新启动 acsls 服务。这是预期的行为。acsls 服务必须在 SMF 下重新启动。以 root 用户身份使用命令 svcadm enable acsls。或以 acsss 用户身份使用命令 acsss-enable

  5. 关闭 acsdb 服务。

    acsdb 用户身份找到 .acsls_env 文件的初始位置。

    $ su acsdb
    $ . /var/tmp/acsls/.acsls_env
    

    现在,使用以下命令突然禁用 PostgreSQL 数据库:

    pg_ctl stop \
         -D $installDir/acsdb/ACSDB1.0/data \
         -m immediate
    

    此操作应当会关闭数据库并且还会导致 acsls 进程关闭。运行 svcs -l acsdb 以定位 acsdb 服务日志。

    在关闭数据库时,查看 acsdb 服务日志和 acsls 服务日志的末尾。您应当会看到,当 acsdb 服务关闭时,它还会关闭 acsls 服务。这两项服务应当由 SMF 自动重新启动。

  6. 在 ACSLS 正常运行时,以 acsss 用户身份运行 psacs 来获取在 acsss_daemon 的控制下运行的子进程的列表。

    停止这些子进程中的任意一个。检查 acsss_event.log 以确认子进程已重新启动并且调用了一个恢复过程。

故障转移状况

Solaris Cluster 软件会监视 Solaris 系统,查找将导致系统故障转移事件的致命状况。这些状况包括用户启动的故障转移(acsAgt nodeSwitchclrg switch)、活动节点的系统重新引导,或者活动节点上的任何系统挂起、致命内存故障或不可恢复的 I/O 通信。Solaris Cluster 还会监视为特定应用程序设计的 HA 代理。发生下列任一状况时,ACSLS HA Agent 将请求执行系统故障转移事件:

  • 活动节点与逻辑主机之间的 TCP/IP 通信中断。

  • 未挂载 $ACS_HOME 文件系统。

  • 未挂载数据库备份文件系统 ($ACS_HOME/.../backup)。

  • $ACS_HOME/acslsha/ha_acs_list.txt 文件中特定 ACS 的相应磁带库之间的通信中断,该 ACS 的预期状态为联机,否则 switch lmu 将不可行或不成功。

故障转移监视

每时每刻,您都可以使用 # clrg status 监视各个节点的故障转移状态。

还可以通过查看 start_stop_log 的末尾来监视故障转移活动:

# tail -f /var/cluster/logs/DS/acsls-rg/acsls-rs/start_stop_log.txt

在执行诊断性故障转移操作时,查看 (tail -f) 两个节点上的 /var/adm/messages 文件可能比较有用。请参见监视 ACSLS 群集运行

故障转移测试

  1. 用于启动 Cluster 故障转移事件的样例命令是 acsAgt nodeSwitch

    # acsAgt nodeSwitch
    

    也可以使用等效的 Cluster 命令:

    # clrg switch -n <node name> acsls_rg
    

    此操作应当会关闭 ACSLS 应用程序并将操作从活动服务器切换到备用系统。选项 -M -e 指示群集服务器在新节点上启用 SMF 服务。请参见监视 ACSLS 群集运行

  2. 活动节点上的系统重新引导应当启动到备用节点的即时 HA 切换。

    此操作的结果应当是 ACSLS 在新的活动节点上运行。在备用节点上,当备用系统作为活动节点承担其新角色时,观察 /var/adm/messages 文件的末尾。还可以定期运行命令 # clrg status

  3. 使用 init 5 关闭活动服务器节点的电源并检验系统故障转移。

  4. 拔掉活动服务器节点与共享磁盘存储阵列之间的两条数据线,并检验到备用节点的系统切换。

  5. 假定策略文件 ha_acs_list.txt 中列出了一个给定的磁带库,请断开活动服务器节点与该磁带库之间的两条以太网通信线路。

    检验到备用节点的系统故障转移。

其他测试

如果镜像引导驱动器是可热插拔的,则可以禁用其中一个引导驱动器并确认系统仍然可以完全正常运行。在禁用一个引导驱动器的情况下,重新引导系统来检验节点是否可从备用引导驱动器上启动。针对两个节点上的每个引导驱动器重复此操作。

从活动节点上移除任一电源,系统应当能够使用备用电源保持完全正常运行。