A 查错 #
用户可能会遇到奇怪而不易理解的问题,特别是刚开始尝试使用 High Availability 时。不过,有一些实用程序可用来仔细地观察 High Availability 的内部进程。本章将推荐各种解决方案。
A.1 安装和前期阶段的步骤 #
对安装软件包或使群集联机的过程中遇到的问题查错。
- 是否安装了 HA 软件包?
配置和管理群集所需的软件包位于 High Availability Extension 提供的
High Availability
安装模式中。按《安装和设置快速入门》中所述,检查 High Availability Extension 是否已作为 SUSE Linux Enterprise Server 15 SP3 的扩展安装在每个群集节点上,以及每台计算机上是否安装了 模式。
- 所有群集节点的初始配置是否相同?
如第 4 章 “使用 YaST 群集模块”中所述,为了相互通讯,属于同一个群集的所有节点需要使用相同的
bindnetaddr
、mcastaddr
和mcastport
。检查
/etc/corosync/corosync.conf
中配置的通讯通道和选项是否对所有群集节点都相同。如果使用加密通讯,请检查
/etc/corosync/authkey
文件是否在所有群集节点上都可用。除
nodeid
以外的所有corosync.conf
设置都必须相同;所有节点上的authkey
文件都必须相同。- 防火墙是否允许通过
mcastport
进行通讯? 如果用于群集节点之间通讯的 mcastport 由防火墙阻止,这些节点将无法相互可见。在分别按第 4 章 “使用 YaST 群集模块”或安装和设置快速入门中所述使用 YaST 或引导脚本执行初始设置时,防火墙设置通常会自动调整。
要确保 mcastport 不被防火墙阻止,请检查每个节点上的防火墙设置。
- 每个群集节点上是否都启动了 Pacemaker 和 Corosync?
通常,启动 Pacemaker 也会启动 Corosync 服务。要检查这两个服务是否在运行,请使用以下命令:
root #
crm
cluster status如果它们未运行,请执行以下命令将其启动:
root #
crm
cluster start
A.2 日志记录 #
- 可以在哪里找到日志文件?
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)。示例可能显示如下:
例 A.1︰ 停止的资源 #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? section.
- 如何查看日志?
要详细查看群集中的当前活动,请使用以下命令:
root #
crm
history log [NODE]将 NODE 替换为您要检查的节点,或将它保留空白。有关更多信息,请参见第 A.5 节 “历史记录”。
A.3 资源 #
- 如何清理我的资源?
使用以下命令:
root #
crm
resource list crm resource cleanup rscid [node]如果遗漏此节点,则资源将在所有节点上清除。更多信息可以在第 8.4.4 节 “清理资源”中找到。
- 如何列出当前已知的资源?
使用命令
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
A.4 STONITH 和屏蔽 #
- 我的 STONITH 资源为什么不启动?
启动(或启用)操作包括检查设备的状态。如果设备未就绪,STONITH 资源将无法启动。
同时系统将要求 STONITH 插件生成主机列表。如果此列表为空,则运行无法关闭任何节点的 STONITH 资源将毫无意义。运行 STONITH 的主机的名称是从列表中滤除的,因为节点不能自我关闭。
如果要使用单主机管理设备(如无人值守设备),请确保不允许 STONITH 资源在应当屏蔽的节点上运行。使用无限负位置节点自选设置(约束)。群集会将 STONITH 资源移到其他可以启动的位置,但不会未通知您就移动。
- 为什么尽管我有 STONITH 资源,却没有发生屏蔽?
每个 STONITH 资源都必须提供主机列表。您可以手动将此列表插入 STONITH 资源配置,也可以从设备自身(例如,从输出名称)检索。这取决于 STONITH 插件的性质。
pacemaker-fenced
使用该列表来查找可以屏蔽目标节点的 STONITH 资源。只有出现在该列表中的节点 STONITH 资源才能关闭(屏蔽)。如果
pacemaker-fenced
在运行中的 STONITH 资源提供的任何主机列表中找不到该节点,它将询问其他节点上的pacemaker-fenced
实例。如果目标节点未显示在其他pacemaker-fenced
实例的主机列表中,则屏蔽请求将以超时在源节点上结束。- 我的 STONITH 资源为什么会偶尔失败?
如果广播通讯量过大,电源管理设备可能会停止运行。隔开监视操作。如果只是偶尔(最好是从不)需要屏蔽,则每隔几小时检查一次设备状态就已足够。
另外,其中的一些设备可能会拒绝同时与多方通讯。如果在群集尝试测试状态时将终端或浏览器会话保持打开状态,则这可能会产生问题。
A.5 历史记录 #
- 如何从发生故障的资源中检索状态信息或日志?
使用
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'
A.6 Hawk2 #
- 替换自我签名证书
要避免在首次启动 Hawk2 时收到有关自我签名证书的警告,请将自动创建的证书替换为您自己的证书或官方证书颁发机构 (CA) 签名的证书:
将
/etc/hawk/hawk.key
替换为私用密钥。将
/etc/hawk/hawk.pem
替换为 Hawk2 应当提供的证书。重启动 Hawk2 服务以重新装载新证书:
root #
systemctl
restart hawk-backend hawk
将文件的所有权更改为
root:haclient
并使文件可被组访问:chown root:haclient /etc/hawk/hawk.key /etc/hawk/hawk.pem chmod 640 /etc/hawk/hawk.key /etc/hawk/hawk.pem
A.7 杂项 #
- 如何在所有群集节点上运行命令?
使用
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
部分中查看)。检查您的防火墙设置。
检查您的交换机是否支持多路广播或单路广播地址。
检查节点间的连接是否已断开。这通常是错误配置防火墙的结果。这也可能是节点分裂情况(其中群集已分区)的原因。
- 为什么不能挂载 OCFS2 设备?
检查日志消息 (
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
。
A.8 更多信息 #
有关 Linux 上的高可用性的更多信息(包括配置群集资源以及管理和自定义高可用性群集),请参见 http://clusterlabs.org/wiki/Documentation。