对安装包或使群集联机的过程中遇到的问题查错。
配置和管理群集所需的包位于 High Availability Extension 提供的 High Availability
安装模式中。
按《安装和设置快速入门》中所述,检查 High Availability Extension 是否已作为 SUSE Linux Enterprise Server 15 SP1 的扩展安装在每个群集节点上,以及每台计算机上是否安装了 模式。
如第 4 章 “使用 YaST 群集模块”中所述,为了相互通讯,属于同一个群集的所有节点需要使用相同的 bindnetaddr
、mcastaddr
和 mcastport
。
检查 /etc/corosync/corosync.conf
中配置的通讯通道和选项是否对所有群集节点都相同。
如果使用加密通讯,请检查 /etc/corosync/authkey
文件是否在所有群集节点上都可用。
除 nodeid
以外的所有 corosync.conf
设置都必须相同;所有节点上的 authkey
文件都必须相同。
mcastport
进行通讯?如果用于群集节点之间通讯的 mcastport 由防火墙阻止,这些节点将无法相互可见。在分别按第 4 章 “使用 YaST 群集模块”或安装和设置快速入门中所述使用 YaST 或引导脚本执行初始设置时,防火墙设置通常会自动调整。
要确保 mcastport 不被防火墙阻止,请检查每个节点上的防火墙设置。
通常,启动 Pacemaker 也会启动 Corosync 服务。要检查这两个服务是否在运行,请使用以下命令:
root #
crm
cluster status
如果它们未运行,请执行以下命令将其启动:
root #
crm
cluster start
Pacemaker 会将其日志文件写入 /var/log/pacemaker
目录。主要的 Pacemaker 日志文件是 /var/log/pacemaker/pacemaker.log
。如果您找不到日志文件,请检查 /etc/sysconfig/pacemaker
中的日志记录设置(Pacemaker 自己的配置文件)。如果该配置文件中配置了 PCMK_logfile
,Pacemaker 将使用此参数定义的路径。
如果您需要获得一份显示所有相关日志文件的群集级报告,请参见如何创建包含所有群集节点分析的报告?以了解更多信息。
除非发生错误,否则 pacemaker-execd
守护程序不会记录重复的监视操作。记录所有重现的操作会产生太多噪音。因此,只会每小时记录一次重现的监视操作。
失败
讯息。有可能收到更多信息吗?
在命令中添加 --verbose
参数。如果多次执行该操作,调试输出会变得相当详细。请参见日志记录数据 (sudo journalctl -n
) 以获得有用的提示。
使用 crm_mon
命令。下面显示了资源操作的历史记录(选项 -o
)和处于不活动状态的资源 (-r
):
root #
crm_mon
-o -r
状态改变时,显示内容会刷新(要取消,请按 Ctrl–C)。示例可能显示如下:
Last updated: Fri Aug 15 10:42:08 2014 Last change: Fri Aug 15 10:32:19 2014 Stack: corosync Current DC: bob (175704619) - partition with quorum Version: 1.1.12-ad083a8 2 Nodes configured 3 Resources configured Online: [ alice bob ] Full list of resources: my_ipaddress (ocf:heartbeat:Dummy): Started bob my_filesystem (ocf:heartbeat:Dummy): Stopped my_webserver (ocf:heartbeat:Dummy): Stopped Operations: * Node bob: my_ipaddress: migration-threshold=3 + (14) start: rc=0 (ok) + (15) monitor: interval=10000ms rc=0 (ok) * Node alice:
http://www.clusterlabs.org/pacemaker/doc/ 上《Pacemaker Explained》(Pacemaker 说明)PDF 文件中的“How are OCF Return Codes Interpreted?”(如何解释 OCF 返回代码?)部分中介绍了三种不同的恢复类型。
要详细查看群集中的当前活动,请使用以下命令:
root #
crm
history log [NODE]
将 NODE 替换为您要检查的节点,或将它保留空白。有关更多信息,请参见第 A.5 节 “历史记录”。
使用以下命令:
root #
crm
resource list crm resource cleanup rscid [node]
如果遗漏此节点,则资源将在所有节点上清除。更多信息可以在第 8.4.3 节 “清理资源”中找到。
使用命令 crm resource list
可以显示当前资源。
要检查 OCF 脚本,请使用 ocf-tester
,例如:
ocf-tester -n ip1 -o ip=YOUR_IP_ADDRESS \ /usr/lib/ocf/resource.d/heartbeat/IPaddr
对更多参数,请多次使用 -o
。通过运行 crm
ra
info
AGENT 可获取必需参数和可选参数的列表,例如:
root #
crm
ra info ocf:heartbeat:IPaddr
运行 ocf-tester 之前,请确保资源不受群集管理。
已终止的节点可能会被视为不干净。这样就必须屏蔽它。如果 STONITH 资源不可运行或不存在,则剩余的节点将等待屏蔽发生。屏蔽超时值通常比较大,因此可能需要很长一段时间才能看到问题的明显迹象(如有)。
另一种可能的解释是仅仅是不允许资源在此节点上运行。这可能是由于未“清理”过去发生的失败所致。或者可能是先前的管理操作(即,添加了分数为负值的位置约束)所致。例如,此类位置约束是通过 crm resource migrate
命令插入的。
如果资源没有位置约束,则其放置取决于(几乎)随机节点选择。建议您始终明确表示资源的首选节点。这并不意味着您需要指定所有资源的位置自选设置。一个自选设置就能满足一组相关(共置)资源的需要。节点自选设置类似如下:
location rsc-prefers-alice rsc 100: alice
启动(或启用)操作包括检查设备的状态。如果设备未就绪,STONITH 资源将无法启动。
同时系统将要求 STONITH 插件生成主机列表。如果此列表为空,则运行无法关闭任何节点的 STONITH 资源将毫无意义。运行 STONITH 的主机的名称是从列表中滤除的,因为节点不能自我关闭。
如果要使用单主机管理设备(如无人值守设备),请确保不允许 STONITH 资源在应当屏蔽的节点上运行。使用无限负位置节点自选设置(约束)。群集会将 STONITH 资源移到其他可以启动的位置,但不会未通知您就移动。
每个 STONITH 资源都必须提供主机列表。您可以手动将此列表插入 STONITH 资源配置,也可以从设备自身(例如,从输出名称)检索。这取决于 STONITH 插件的性质。pacemaker-fenced
使用该列表来查找可以屏蔽目标节点的 STONITH 资源。只有出现在该列表中的节点 STONITH 资源才能关闭(屏蔽)。
如果 pacemaker-fenced
在运行中的 STONITH 资源提供的任何主机列表中找不到该节点,它将询问其他节点上的 pacemaker-fenced
实例。如果目标节点未显示在其他 pacemaker-fenced
实例的主机列表中,则屏蔽请求将以超时在源节点上结束。
如果广播通讯量过大,电源管理设备可能会停止运行。隔开监视操作。如果只是偶尔(最好是从不)需要屏蔽,则每隔几小时检查一次设备状态就已足够。
另外,其中的一些设备可能会拒绝同时与多方通讯。如果在群集尝试测试状态时将终端或浏览器会话保持打开状态,则这可能会产生问题。
使用 history
命令及其子命令 resource
:
root #
crm
history resource NAME1
这只会返回给定资源的完整转换日志。不过,您也可以调查多个资源,在第一个资源名称的后面追加更多的资源名称即可。
如果您遵循了某种命名约定(请参见一节),使用 resource
命令可以更轻松地调查一组资源。例如,以下命令将调查以 db
开头的所有原始资源:
root #
crm
history resource db*
查看 /var/cache/crm/history/live/alice/ha-log.txt
中的日志文件。
history
命令有两个选项:
使用 exclude
使用 timeframe
exclude
命令可让您设置附加的正则表达式用于从日志中排除特定的模式。例如,以下命令将排除所有 SSH、systemd 和内核讯息:
root #
crm
history exclude ssh|systemd|kernel.
使用 timeframe
命令可将输出限制为特定的范围。例如,以下命令将显示 8 月 23 日 12:00 到 12:30 的所有事件:
root #
crm
history timeframe "Aug 23 12:00" "Aug 23 12:30"
当您遇到 bug 或者需要进一步检查的事件时,储存所有当前设置的做法非常有用。您可以将储存的文件发送给支持人员,或者使用 bzless
进行查看。例如:
crm(live)history#
timeframe
"Oct 13 15:00" "Oct 13 16:00"crm(live)history#
session
save tux-testcrm(live)history#
session
pack Report saved in '/root/tux-test.tar.bz2'
要避免在首次启动 Hawk2 时收到有关自我签名证书的警告,请将自动创建的证书替换为您自己的证书或官方证书颁发机构 (CA) 签名的证书:
将 /etc/hawk/hawk.key
替换为私用密钥。
将 /etc/hawk/hawk.pem
替换为 Hawk2 应当提供的证书。
将文件的所有权更改为 root:haclient
并使文件可被组访问:
chown root:haclient /etc/hawk/hawk.key /etc/hawk/hawk.pem chmod 640 /etc/hawk/hawk.key /etc/hawk/hawk.pem
使用 pssh
命令可完成此任务。如果需要,请安装 pssh. 创建一个文件(例如 hosts.txt
),将要访问的所有 IP 地址或主机名都收集在其中。确保可以使用 ssh
登录到 hosts.txt
文件中列出的每台主机。如果一切准备就绪,请执行 pssh
并使用 hosts.txt
文件(选项 -h
)和交互模式(选项 -i
),如此例所示:
pssh -i -h hosts.txt "ls -l /corosync/*.conf" [1] 08:28:32 [SUCCESS] root@venus.example.com -rw-r--r-- 1 root root 1480 Nov 14 13:37 /etc/corosync/corosync.conf [2] 08:28:32 [SUCCESS] root@192.168.2.102 -rw-r--r-- 1 root root 1480 Nov 14 13:37 /etc/corosync/corosync.conf
要检查群集的当前状态,请使用程序 crm_mon
或 crm
status
之一。这将显示当前的 DC 以及当前节点已知的所有节点和资源。
这可能有几个原因:
先查看配置文件 /etc/corosync/corosync.conf
。检查群集中每个节点的多路广播或单路广播地址是否相同(使用关键字 mcastaddr
在 interface
部分中查找)。
检查您的防火墙设置。
检查您的交换机是否支持多路广播或单路广播地址。
检查节点间的连接是否已断开。这通常是错误配置防火墙的结果。这也可能是节点分裂情况(其中群集已分区)的原因。
检查日志讯息 (sudo journalctl -n
) 中是否包含以下行:
Jan 12 09:58:55 alice pacemaker-execd: [3487]: info: RA output: [...] ERROR: Could not load ocfs2_stackglue Jan 12 16:04:22 alice modprobe: FATAL: Module ocfs2_stackglue not found.
在此案例中,是因为缺少内核模块 ocfs2_stackglue.ko
。请根据安装的内核安装包 ocfs2-kmp-default
、ocfs2-kmp-pae
或 ocfs2-kmp-xen
。
在 crm 外壳中,可以使用 crm report
创建报告。此工具将会编译:
群集范围内的日志文件,
包状态,
DLM/OCFS2 状态,
系统信息,
CIB 历史记录,
内核转储报告的分析(如果安装了 debuginfo 包)。
通常需要结合以下命令运行 crm report
:
root #
crm report
-f 0:00 -n alice -n bob
该命令将提取主机 alice 和 bob 上从凌晨 0 点开始的所有信息,并在当前目录中创建名为 crm_report-日期.tar.bz2
的 *.tar.bz2
存档,例如 crm_report-Wed-03-Mar-2012
。如果您只对特定时间段感兴趣,请使用 -t
选项添加结束时间。
crm report
工具会尝试从 CIB 和 PE 输入文件去除所有敏感信息,但是,它并不是万能的。如果您还有更多敏感信息,请通过 -p
选项(请参见手册页)提供其他模式。日志文件以及 crm_mon
、ccm_tool
和 crm_verify
输出不会被清理。
以任何方式共享数据之前,请检查存档并删除不想泄露的所有信息。
使用其他选项自定义命令执行。例如,如果您有一个 Pacemaker 群集,那么您肯定想添加选项 -A
。如果还有一个用户(除 root
和 hacluster
以外)对该群集拥有权限,可使用 -u
选项并指定此用户。如果您有一个非标准 SSH 端口,请使用 -X
选项添加该端口(例如,如果端口为 3479,则使用 -X "-p 3479"
)。要了解更多选项,请参见 crm report
的手册页。
在 crm report
分析完所有相关日志文件并创建目录(或存档)后,请检查日志文件中有无大写的 ERROR
字符串。位于报告顶层目录中的最重要的文件有:
analysis.txt
比较在所有节点上都应保持一致的文件。
corosync.txt
包含 Corosync 配置文件的副本。
crm_mon.txt
包含 crm_mon
命令的输出。
description.txt
包含您节点上的所有群集包版本。另有节点特定的 sysinfo.txt
文件。它会链接到顶层目录。
可以使用此文件作为模板来描述您遇到的问题,然后将它发布到 https://github.com/ClusterLabs/crmsh/issues。
members.txt
所有节点的列表
sysinfo.txt
包含所有相关包名称及其版本的列表。此外,还有一个不同于原始 RPM 包的配置文件列表。
节点特定的文件将存储在以节点名称命名的子目录中。其中包含相应节点的 /etc
目录副本。
如果您需要简化自变量,请在配置文件 /etc/crm/crm.conf
的 report
部分设置默认值。更多信息请参见手册页 man 8 crmsh_hb_report
。
有关 Linux 上的高可用性的更多信息(包括配置群集资源以及管理和自定义高可用性群集),请参见 http://clusterlabs.org/wiki/Documentation。