13 存储保护和 SBD #
SBD(STONITH 块设备)通过共享块存储(SAN、iSCSI、FCoE 等)进行消息交换来为基于 Pacemaker 的群集提供节点屏蔽机制。此方法可以将屏蔽机制隔离开来,使其不受固件版本更改的影响或不依赖于特定固件控制器。SBD 需要在每个节点上安装一个检查包,以确保能确实停止行为异常的节点。在某些情况下,还可以通过无磁盘模式运行 SBD,以便使用不含共享存储的 SBD。
群集引导脚本提供了一种自动设置群集的方式,并可让您选择使用 SBD 作为屏蔽机制。有关详细信息,请参见安装和设置快速入门。但是,手动设置 SBD 可为您提供个别设置的更多选项。
本章介绍 SBD 背后的概念。它将指导您完成 SBD 所需组件的配置,防止您的群集在发生节点分裂情况下出现可能的数据损坏。
除了节点级别屏蔽,您还可以使用额外的存储保护机制,例如 LVM 排它激活或 OCFS2 文件锁定支持(资源级别屏蔽)。它们可以保护您的系统,以防出现管理或应用程序故障。
13.1 概念概述 #
SBD 是 Storage-Based Death(基于存储区的终止)或 STONITH Block Device(STONITH 块设备)的缩写。
High Availability 群集堆栈的最高优先级是保护数据完整性。此项保护通过防止对数据存储进行未协调的并行访问来实现。群集堆栈会使用几种控制机制来实现此目标。
但是,如果在群集中选出数个 DC,则可能导致网络分区或软件故障。这种节点分裂情况可能会导致数据损坏。
可防止节点分裂情况的主要方法是通过 STONITH 实现节点屏蔽。如果使用 SBD 作为节点屏蔽机制,当发生节点分裂情况时,无需使用外部关机设备即可关闭节点。
- SBD 分区
在所有节点都可访问共享存储的环境中,设备的某个小分区会格式化,以用于 SBD。该分区的大小取决于所用磁盘的块大小(例如,对于块大小为 512 字节的标准 SCSI 磁盘,该分区大小为 1 MB;块大小为 4 KB 的 DASD 磁盘需要 4 MB 大小的分区)。初始化过程会在设备上创建消息布局,配置最多 255 个节点的消息槽。
- SBD 守护程序
配置完相应的 SBD 守护程序后,在每个节点上使其上线,然后启动其余群集堆栈。它在所有其他群集组件都关闭之后才终止,从而确保了群集资源绝不会在没有 SBD 监督的情况下被激活。
- 消息
此守护程序会自动将分区上的消息槽之一分配给其自身,并持续监控其中有无发送给它自己的消息。收到消息后,守护程序会立即执行请求,如启动关闭电源或重引导循环以进行屏蔽。
另外,此守护程序会持续监控与存储设备的连接情况,如果无法连接分区,守护程序会自行终止。这就保证了它不会从屏蔽消息断开连接。如果群集数据驻留在不同分区中的同一个逻辑单元,一旦与存储设备的连接中断,工作负载便会终止,因此不会增加故障点。
- 检查包
只要使用 SBD,就必须确保检查包正常工作。新式系统支持硬件检查包,此功能需由软件组件来“激发”或“馈送数据”。软件组件(在此案例中为 SBD 守护程序)通过将服务脉冲定期写入检查包来“供给”检查包。如果守护程序停止向检查包反馈信号,硬件将强制系统重启动。这可防止出现 SBD 进程本身的故障,如失去响应或由于 I/O 错误而卡住。
如果激活了 Pacemaker 集成,仅仅只是大多数设备丢失将不会触发自我屏蔽。例如,假设您的群集包含三个节点:A、B 和 C。由于网络分隔,A 只能看到它自己,而 B 和 C 仍可相互通讯。在此案例中,有两个群集分区,一个因节点占多数(B 和 C)而具有法定票数,而另一个则不具有 (A)。如果在大多数屏蔽设备无法访问时发生此情况,则节点 A 会自我屏蔽,而节点 B 和 C 将会继续运行。
13.2 手动设置 SBD 的概述 #
手动设置基于存储的保护时必须执行以下步骤:必须以 root
身份执行这些步骤。在开始执行之前,请查看第 13.3 节 “要求和限制”。
根据您的情况,可将 SBD 与一到三个设备搭配使用,或以无磁盘模式使用。有关概述,请参见第 13.4 节 “SBD 设备数量”。有关详细的设置,请参见:
13.3 要求和限制 #
最多可将三个 SBD 设备用于基于存储的屏蔽。使用一到三个设备时,必须可从所有节点访问共享存储。
群集中的所有节点上,共享存储设备的路径都必须永久且一致。使用稳定的设备名称,如
/dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345
。可通过光纤通道 (FC)、以太网光纤通道 (FCoE) 甚至 iSCSI 来连接共享存储。
共享存储段不得使用基于主机的 RAID、LVM 或 DRBD*。DRBD 可能已分割,这会导致 SBD 发生问题,因为 SBD 中不能存在两种状态。不能将群集多设备(群集 MD)用于 SBD。
但是,建议使用基于存储区的 RAID 和多路径,以提高可靠性。
可以在不同群集之间共享某个 SBD 设备,只要共享该设备的节点数不超过 255 个。
屏蔽不适用于非对称 SBD 设置。使用多个 SBD 设备时,所有节点都必须在所有 SBD 设备中有一个插槽。
使用多个 SBD 设备时,所有设备都必须具有相同的配置,例如具有相同的超时值。
对于具有两个以上节点的群集,还可以在无磁盘模式下使用 SBD。
13.4 SBD 设备数量 #
SBD 支持最多使用三个设备:
- 一个设备
最简单的实施。适用于所有数据位于同一个共享存储的群集。
- 两个设备
此配置主要用于如下环境:使用基于主机的镜像,但是没有第三个存储设备可用。SBD 在丢失对某个镜像分支的访问权后不会自行终止,这样群集便可继续运行。不过,由于 SBD 掌握的情况不够全面,无法检测到存储区的不对称分裂,因此,当只有一个镜像分支可用时,它不会屏蔽另一方。如此一来,就无法在存储阵列中的一个关闭时对第二个故障自动容错。
- 三个设备
最可靠的配置。它具有从一个设备中断(可能是因为发生故障或进行维护)的情况中恢复的能力。只有当一个以上设备失去连接并且有必要时,SBD 才会自行终止,具体取决于群集分区或节点的状态。如果至少有两个设备仍然可访问,便能成功传输屏蔽消息。
此配置适用于存储未限制为单个阵列的更为复杂的环境。基于主机的镜像解决方案可以每个镜像分支拥有一个 SBD(不自我镜像),并在 iSCSI 上有一个额外的决定项。
- 无磁盘
如果您想要建立一个不含共享存储的屏蔽机制,则此配置十分有用。在此无磁盘模式下,SBD 会使用硬件检查包来屏蔽节点,而不依赖于任何共享设备。不过,无磁盘 SBD 不能处理双节点群集的节点分裂情况。此选项仅适用于具有两个以上节点的群集。
13.5 超时计算 #
使用 SBD 作为屏蔽机制时,必须考虑所有组件的超时,因为它们之间相互依赖。使用多个 SBD 设备时,所有设备都必须具有相同的超时值。
- 检查包超时
此超时在初始化 SBD 设备期间设置。它主要取决于存储延迟。必须可在此时间内成功读取大多数设备。否则,节点可能会自我屏蔽。
注意:多路径或 iSCSI 设置如果 SBD 设备驻留在多路径设置或 iSCSI 上,则应将超时设置为检测到路径故障并切换到下一个路径所需的时间。
这还意味着
/etc/multipath.conf
中max_polling_interval
的值必须小于watchdog
超时。msgwait
超时此超时在初始化 SBD 设备期间设置。它定义了将消息写入到 SBD 设备上的某个节点槽后经过多长时间视为已传递。该超时应设置的足够长,让节点有时间检测到它是否需要自我屏蔽。
但是,如果
msgwait
超时较长,被屏蔽的群集节点可能会在屏蔽操作返回之前就重新加入群集。可以按SBD_DELAY_START
中的过程 13.4 所述,在 SBD 配置中设置 步骤 3 参数来减少此情况。- CIB 中的
stonith-timeout
此超时在 CIB 中作为全局群集属性设置。它定义了等待 STONITH 操作(重引导、打开、关闭)完成的时间。
- CIB 中的
stonith-watchdog-timeout
此超时在 CIB 中作为全局群集属性设置。如果未显式设置,则默认值为
0
,此值适用于 SBD 与一到三个设备搭配使用的情况。对于无磁盘模式下的 SBD,此超时不得为0
。有关细节,请参见过程 13.8 “配置无磁盘 SBD”。
如果您更改检查包超时,则需要同时调整另外两个超时。以下“公式”表达了这三个值之间的关系:
Timeout (msgwait) >= (Timeout (watchdog) * 2) stonith-timeout >= Timeout (msgwait) + 20%
例如,如果将检查包超时设置为 120
,请将 msgwait
超时至少设置为 240
,将 stonith-timeout
超时至少设置为 288
。
如果您使用 crm 外壳提供的引导脚本设置群集并初始化 SBD 设备,系统会自动考虑这些超时之间的关系。
13.6 设置检查包 #
SUSE Linux Enterprise High Availability 随附了几个内核模块,用于提供特定于硬件的检查包驱动程序。对于生产环境中的群集,我们建议使用硬件特定的检查包驱动程序。不过,如果没有与您的硬件匹配的检查包,则可以将 softdog
用作内核检查包模块。
SUSE Linux Enterprise High Availability 使用 SBD 守护程序作为“供给”检查包的软件组件。
13.6.1 使用硬件检查包 #
查找给定系统的正确检查包内核模块并非没有意义。自动探测常常会失败。因此,加载许多模块后才会加载正确的模块。
下表列出了一些常用检查包驱动程序。但这不是完整的受支持驱动程序列表。如果您的硬件未在下面列出,您还可以在 /lib/modules/KERNEL_VERSION/kernel/drivers/watchdog
和 /lib/modules/KERNEL_VERSION/kernel/drivers/ipmi
目录中查看选项列表。或者,您可以咨询您的硬件或系统供应商,获取特定于系统的检查包配置细节。
硬件 | 驱动程序 |
---|---|
HP | hpwdt |
Dell、Lenovo (Intel TCO) | iTCO_wdt |
Fujitsu | ipmi_watchdog |
IBM Power 上的 LPAR | pseries-wdt |
IBM z/VM 上的 VM | vmwatchdog |
Xen VM (DomU) | xen_xdt |
VMware vSphere 上的 VM | wdat_wdt |
通用 | softdog |
有些硬件供应商交付的系统管理软件(例如 HP ASR 守护程序)会使用检查包来进行系统重置。如果 SBD 使用了检查包,请禁用此类软件。不能有其他任何软件在访问检查包计时器。
要确保加载正确的检查包模块,请执行如下操作:
列出已随内核版本安装的驱动程序:
#
rpm -ql kernel-VERSION | grep watchdog
列出内核中当前加载的任何检查包模块:
#
lsmod | egrep "(wd|dog)"
如果返回了结果,请卸载错误的模块:
#
rmmod WRONG_MODULE
启用与您的硬件匹配的检查包模块:
#
echo WATCHDOG_MODULE > /etc/modules-load.d/watchdog.conf
#
systemctl restart systemd-modules-load
测试是否已正确加载 检查包模块:
#
lsmod | grep dog
校验检查包设备是否可用且可正常工作:
#
ls -l /dev/watchdog*
#
sbd query-watchdog
如果检查包设备无法使用,请检查模块名称和选项。可以考虑使用其他驱动程序。
校验检查包设备是否可正常工作:
#
sbd -w WATCHDOG_DEVICE test-watchdog
重引导计算机,以确保不存在冲突的内核模块。例如,如果您在日志中发现
cannot register ...
消息,就表示存在这样的冲突模块。要避免加载此类模块,请参见 https://documentation.suse.com/sles/html/SLES-all/cha-mod.html#sec-mod-modprobe-blacklist。
13.6.2 使用软件检查包 (softdog) #
对于生产环境中的群集,建议使用硬件特定的检查包驱动程序。不过,如果没有与您的硬件匹配的检查包,则可以将 softdog
用作内核检查包模块。
Softdog 驱动程序假设至少有一个 CPU 仍然在运行。如果所有 CPU 均已阻塞,则 softdog 驱动程序中应该重引导系统的代码永远都不会执行。相反地,即使所有 CPU 均已阻塞,硬件检查包也仍然会继续工作。
启用 softdog 检查包:
#
echo softdog > /etc/modules-load.d/watchdog.conf
#
systemctl restart systemd-modules-load
测试是否已正确加载 softdog 检查包模块:
#
lsmod | grep softdog
13.7 设置 SBD 与设备 #
进行该设置必须执行以下步骤:
在开始之前,请确保要用于 SBD 的一个或多个块设备满足在第 13.3 节中指定的要求。
设置 SBD 设备时,您需要考虑几个超时值。有关详细信息,请参见 第 13.5 节 “超时计算”。
如果节点上运行的 SBD 守护程序更新检查包计时器的速度不够快,节点会自行终止。设置超时后,请在您的特定环境中予以测试。
要将 SBD 与共享存储搭配使用,必须先在一到三个块设备上创建消息布局。sbd create
命令会将元数据头写入指定的一个或多个设备。它还会初始化最多 255 个节点的消息槽。如果不带任何其他选项执行该命令,该命令将使用默认超时设置。
确保要用于 SBD 的一个或多个设备未保存任何重要数据。执行 sbd create
命令时,会直接重写指定块设备的大约第一个 MB,而不会发出其他请求或进行备份。
决定要将哪个块设备或哪些块设备用于 SBD。
使用以下命令初始化 SBD 设备:
#
sbd -d /dev/disk/by-id/DEVICE_ID create
要将多个设备用于 SBD,请指定
-d
选项多次,例如:#
sbd -d /dev/disk/by-id/DEVICE_ID1 -d /dev/disk/by-id/DEVICE_ID2 -d /dev/disk/by-id/DEVICE_ID3 create
如果您的 SBD 设备驻留在多路径组上,请使用
-1
和-4
选项调整要用于 SBD 的超时。如果初始化了多个设备,则必须为所有设备设置相同的超时值。有关详细信息,请参见 第 13.5 节 “超时计算”。所有超时均以秒为单位指定:#
sbd -d /dev/disk/by-id/DEVICE_ID -4 180
1-1 90
2create
检查已写入设备的内容:
#
sbd -d /dev/disk/by-id/DEVICE_ID dump
Header version : 2.1 UUID : 619127f4-0e06-434c-84a0-ea82036e144c Number of slots : 255 Sector size : 512 Timeout (watchdog) : 5 Timeout (allocate) : 2 Timeout (loop) : 1 Timeout (msgwait) : 10 ==Header on disk /dev/disk/by-id/DEVICE_ID is dumped正如您看到的,超时数也存储在报头中,以确保所有参与的节点在这方面都一致。
初始化 SBD 设备之后,编辑 SBD 配置文件,然后启用并启动相应的服务以让更改生效。
打开
/etc/sysconfig/sbd
文件。搜索以下参数:SBD_DEVICE。
该参数指定要监控和要用于交换 SBD 讯息的设备。
编辑此行,用您的 SBD 设备替换 /dev/disk/by-id/DEVICE_ID:
SBD_DEVICE="/dev/disk/by-id/DEVICE_ID"
如果您需要在第一行中指定多个设备,请使用分号分隔设备(设备顺序无关紧要):
SBD_DEVICE="/dev/disk/by-id/DEVICE_ID1;/dev/disk/by-id/DEVICE_ID2;/dev/disk/by-id/DEVICE_ID3"
如果无法访问 SBD 设备,守护程序将无法启动,导致群集无法启动。
搜索以下参数:SBD_DELAY_START。
启用或禁用延迟。如果
msgwait
很长,但群集节点引导速度很快,请将 SBD_DELAY_START 设置为yes
。将此参数设置为yes
可在引导时延迟 SBD 启动。虚拟机有时候需要此项延迟。默认延迟时长与
msgwait
超时值相同。或者,您可以指定一个整数(以秒为单位),而不是yes
。如果启用 SBD_DELAY_START,还必须检查 SBD 服务文件,以确保
TimeoutStartSec
的值大于 SBD_DELAY_START 的值。有关详细信息,请参见https://www.suse.com/support/kb/doc/?id=000019356。使用
csync2
将配置文件复制到所有节点:#
csync2 -xv
有关详细信息,请参见第 4.7 节 “将配置传输到所有节点”。
将您的 SBD 设备添加到 SBD 配置文件之后,启用 SBD 守护程序。SBD 守护程序是群集堆栈的关键部分。当群集堆栈正在运行时,需要运行该守护程序。因此,每次群集服务启动时,sbd
服务也会作为依赖项启动。
在每个节点,启用 SBD 服务:
#
systemctl enable sbd
每次群集服务启动时,SBD 会与 Corosync 服务一起启动。
使用
--all
选项同时在所有节点上重启动群集服务:#
crm cluster restart --all
此操作会自动触发 SBD 守护程序的启动。
重要:发生 SBD 更改后重启动群集服务如果任何 SBD 元数据发生更改,则必须再次重启动群集服务。要在重启动期间使关键群集资源保持运行状态,请考虑先将群集置于维护模式。有关详细信息,请参见第 28 章 “执行维护任务”。
下一步是测试 SBD 设备,请参见过程 13.6。
以下命令会从 SBD 设备转储节点槽及其当前消息:
#
sbd -d /dev/disk/by-id/DEVICE_ID list
现在,您应该会看到曾随 SBD 启动的所有群集节点都列在此处。例如,如果您拥有双节点群集,消息槽对于两个节点都应显示
clear
:0 alice clear 1 bob clear
尝试将测试消息发送到节点之一:
#
sbd -d /dev/disk/by-id/DEVICE_ID message alice test
此节点会在系统日志文件中确认收到了该消息:
May 03 16:08:31 alice sbd[66139]: /dev/disk/by-id/DEVICE_ID: notice: servant: Received command test from bob on disk /dev/disk/by-id/DEVICE_ID
这就确认了 SBD 确实在节点上正常运行,并已准备好接收消息。
在最后一步中,您需要调整群集配置,请参见过程 13.7。
启动外壳,并以
root
用户或同等身份登录。运行
crm configure
。输入以下内容:
crm(live)configure#
property stonith-enabled="true"
1crm(live)configure#
property stonith-watchdog-timeout=0
2crm(live)configure#
property stonith-timeout="40s"
3此为默认配置,因为不支持没有 STONITH 的群集。而如果出于测试目的停用了 STONITH,请确保再次将此参数设置为
true
。如果未显式设置,此值默认为
0
,适用于 SBD 与一到三个设备搭配使用的情况。要计算 stonith-timeout,请参见第 13.5 节 “超时计算”。如果将 SBD 的
stonith-timeout
超时值设置为40
秒,则适合将msgwait
值设置为30
。配置 SBD STONITH 资源。您无需克隆此资源。
对于双节点群集,在节点分裂情况下,两个节点都会按预期向对方发出屏蔽。为防止两个节点几乎同时被重置,建议应用以下屏蔽延迟来帮助其中一个节点甚至是首选节点在屏蔽竞争中胜出。对于具有两个以上节点的群集,无需应用这些延迟。
- 优先级屏蔽延迟
priority-fencing-delay
群集属性默认处于禁用状态。配置延迟值后,如果另一个节点发生故障且其总资源优先级更高,针对该节点的屏蔽将延迟指定的时间。这意味着在节点分裂情况下,更重要的节点将在屏蔽竞争中胜出。可以用优先级元属性配置重要资源。在计算时,将对每个节点上运行的资源或实例的优先级值求和来进行计算。升级后的资源实例的优先级为配置的基础优先级加 1,因此它的优先级值比任何未升级的实例都高。
#
crm configure property priority-fencing-delay=30
即使使用了
priority-fencing-delay
,我们也仍然建议使用pcmk_delay_base
或pcmk_delay_max
(如下所述)来解决节点优先级恰好相同的所有情况。priority-fencing-delay
的值应显著大于pcmk_delay_max
/pcmk_delay_base
的最大值,最好是最大值的两倍。- 可预测的静态延迟
此参数用于在执行 STONITH 操作之前添加静态延迟。为防止发生节点分裂时双节点群集的两个节点同时重置,请为不同的屏蔽资源配置不同的延迟值。可以用可实现更长屏蔽延迟的参数标记首选节点,使其在任何屏蔽竞争中都胜出。要成功实现此目的,每个节点都必须有两个原始 STONITH 设备。在下面的配置中,如果出现节点分裂情况,alice 会胜出并得以留存:
crm(live)configure#
primitive st-sbd-alice stonith:external/sbd params \ pcmk_host_list=alice pcmk_delay_base=20
crm(live)configure#
primitive st-sbd-bob stonith:external/sbd params \ pcmk_host_list=bob pcmk_delay_base=0
- 动态随机延迟
此参数用于为屏蔽设备上的 STONITH 操作添加随机延迟。pcmk_delay_max 参数不会针对特定节点实施静态延迟,而是为包含屏蔽资源的任何屏蔽添加随机延迟,以防止双重重置。与 pcmk_delay_base 不同,此参数可对针对多个节点的统一屏蔽资源指定。
crm(live)configure#
primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30
警告:pcmk_delay_max 可能无法防止节点分裂情况下的双重重置。pcmk_delay_max 的值越低,仍会发生双重重置的可能性就越高。
如果您的目标是有可预测的幸存者,请使用优先级屏蔽延迟或可预测的静态延迟。
使用
show
查看所做的更改。使用
commit
提交更改,然后使用quit
退出 crm 实时配置。
资源启动后,群集就会成功配置为在出现需要屏蔽的节点时使用 SBD。
13.8 设置无磁盘 SBD #
SBD 可在无磁盘模式下操作。在此模式下,当发生以下情况时,将使用检查包设备来重置节点:失去仲裁、任何受监控的守护程序发生故障且未恢复、Pacemaker 决定需要屏蔽节点。无磁盘 SBD 基于节点的“自我屏蔽”,具体取决于群集的状态、仲裁和某些合理的假设。CIB 中不需要 STONITH SBD 原始资源。
无磁盘 SBD 依赖于重新生成的成员资格和仲裁丢失来实现屏蔽。Corosync 流量必须能够通过所有网络接口(包括回写接口),并且不得被本地防火墙阻止。否则,Corosync 将无法重新生成新成员资格,可能导致出现节点分裂情况,而无磁盘 SBD 屏蔽无法处理该情况。
不要将无磁盘 SBD 用作双节点群集的屏蔽机制。请仅对包含三个或更多节点的群集使用无磁盘 SBD。无磁盘模式下的 SBD 无法处理双节点群集的节点分裂情况。如果您想对双节点群集使用无磁盘 SBD,请按第 14 章 “QDevice 和 QNetd” 中所述使用 QDevice。
打开文件
/etc/sysconfig/sbd
并使用以下项:SBD_PACEMAKER=yes SBD_STARTMODE=always SBD_DELAY_START=no SBD_WATCHDOG_DEV=/dev/watchdog SBD_WATCHDOG_TIMEOUT=5
由于未使用共享磁盘,因此不需要
SBD_DEVICE
条目。此参数缺失时,sbd
服务不会为 SBD 设备启动任何观察程序进程。如果需要在系统引导时延迟启动 SBD,请将
SBD_DELAY_START
更改为yes
。默认延迟时长为SBD_WATCHDOG_TIMEOUT
值的两倍。或者,您可以指定一个整数(以秒为单位),而不是yes
。重要:无磁盘 SBD 和 QDevice 的SBD_WATCHDOG_TIMEOUT
如果您将 QDevice 和无磁盘 SBD 搭配使用,
SBD_WATCHDOG_TIMEOUT
值必须大于 QDevice 的sync_timeout
值,否则 SBD 将会超时并无法启动。sync_timeout
的默认值为 30 秒。因此,请将SBD_WATCHDOG_TIMEOUT
设置为更大的值,例如35
。在每个节点,启用 SBD 服务:
#
systemctl enable sbd
每次群集服务启动时,SBD 会与 Corosync 服务一起启动。
使用
--all
选项同时在所有节点上重启动群集服务:#
crm cluster restart --all
此操作会自动触发 SBD 守护程序的启动。
重要:发生 SBD 更改后重启动群集服务如果任何 SBD 元数据发生更改,则必须再次重启动群集服务。要在重启动期间使关键群集资源保持运行状态,请考虑先将群集置于维护模式。有关详细信息,请参见第 28 章 “执行维护任务”。
检查是否已自动设置 have-watchdog=true 参数:
#
crm configure show | grep have-watchdog
have-watchdog=true运行
crm configure
并在 crm 外壳上设置以下群集属性:crm(live)configure#
property stonith-enabled="true"
1crm(live)configure#
property stonith-watchdog-timeout=10
2crm(live)configure#
property stonith-timeout=15
3此为默认配置,因为不支持没有 STONITH 的群集。而如果出于测试目的停用了 STONITH,请确保再次将此参数设置为
true
。对于无磁盘 SBD,此参数不能为零。它定义了经过多长时间之后可以假定屏蔽目标已自我屏蔽。请使用以下公式计算此超时:
stonith-watchdog-timeout >= (SBD_WATCHDOG_TIMEOUT * 2)
如果将 stonith-watchdog-timeout 设置为负值,Pacemaker 会自动计算此超时,并将它设置为 SBD_WATCHDOG_TIMEOUT 值的两倍。
此参数必须留出足够长的时间让屏蔽完成。对于无磁盘 SBD,请使用以下公式计算此超时:
stonith-timeout >= stonith-watchdog-timeout + 20%
重要:无磁盘 SBD 超时使用无磁盘 SBD 时,如果
stonith-timeout
值小于stonith-watchdog-timeout
值,则失败的节点可能会停滞在UNCLEAN
状态,并阻止对活动资源进行故障转移。使用
show
查看所做的更改。使用
commit
提交更改,然后使用quit
退出 crm 实时配置。
13.9 测试 SBD 和屏蔽 #
要测试 SBD 在节点屏蔽方面是否按预期工作,请使用以下其中一种或所有方法:
- 手动触发节点屏蔽
要针对节点 NODENAME 触发屏蔽操作,请执行以下操作:
#
crm node fence NODENAME
经过 stonith-watchdog-timeout 时间之后,检查节点是否已屏蔽,并且其他节点是否将该节点视为已屏蔽。
- 模拟 SBD 失败
识别 SBD inquisitor 的进程 ID:
#
systemctl status sbd
● sbd.service - Shared-storage based fencing daemon Loaded: loaded (/usr/lib/systemd/system/sbd.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2018-04-17 15:24:51 CEST; 6 days ago Docs: man:sbd(8) Process: 1844 ExecStart=/usr/sbin/sbd $SBD_OPTS -p /var/run/sbd.pid watch (code=exited, status=0/SUCCESS) Main PID: 1859 (sbd) Tasks: 4 (limit: 4915) CGroup: /system.slice/sbd.service ├─1859 sbd: inquisitor [...]通过终止 SBD inquisitor 进程模拟 SBD 失败。在我们的示例中,SBD inquisitor 的进程 ID 是
1859
:#
kill -9 1859
节点主动自我屏蔽。经过 stonith-watchdog-timeout 时间之后,其他节点注意到该节点丢失并将其视为已自我屏蔽。
- 通过监控操作失败触发屏蔽
对于正常配置,如果资源的停止操作失败,将会触发屏蔽。要手动触发屏蔽,可以产生一个资源停止操作失败。或者,可以临时更改资源监控操作的配置,产生监控失败,如下所示:
为资源监控操作配置
on-fail=fence
属性:op monitor interval=10 on-fail=fence
让监控操作失败(例如,如果资源与某个服务相关,则可通过终止相应的守护程序来实现)。
此失败会触发屏蔽操作。
13.10 其他存储保护机制 #
除了通过 STONITH 进行节点屏蔽之外,还可使用其他方法在资源级别实现存储保护。例如,SCSI-3 和 SCSI-4 使用永久预留,而 sfex
提供锁定机制。这两种方法将在下面的小节中介绍。
13.10.1 配置 sg_persist 资源 #
SCSI 规范 3 和 4 定义了永久保留。其属于 SCSI 协议功能,可用于 I/O 屏蔽和故障转移。此功能在 sg_persist
Linux 命令中实施。
用于 sg_persist
的所有后备磁盘都必须与 SCSI 磁盘兼容。sg_persist
仅适用于 SCSI 磁盘或 iSCSI LUN 等设备。
不要将它用于 IDE、SATA 或不支持 SCSI 协议的任何块设备。
继续之前,请检查您的磁盘是否支持永久保留。使用以下命令(用您的设备名称替换 DEVICE_ID):
#
sg_persist -n --in --read-reservation -d /dev/disk/by-id/DEVICE_ID
结果显示您的磁盘是否支持永久保留:
支持的磁盘:
PR generation=0x0, there is NO reservation held
不支持的磁盘:
PR in (Read reservation): command not supported Illegal request, Invalid opcode
如果您收到错误消息(如上面所示),请用 SCSI 兼容的磁盘替换旧磁盘。否则请执行如下操作:
使用磁盘的稳定设备名称创建原始资源
sg_persist
:#
crm configure
crm(live)configure#
primitive sg sg_persist \ params devs="/dev/disk/by-id/DEVICE_ID" reservation_type=3 \ op monitor interval=60 timeout=60
创建
sg_persist
原始资源的可升级克隆:crm(live)configure#
clone clone-sg sg \ meta promotable=true promoted-max=1 notify=true
测试设置:升级资源后,您可以在运行主实例的群集节点上挂载磁盘分区并将数据写入其中,但无法在运行次要实例的群集节点上写入数据。
使用磁盘分区的稳定设备名称为 Ext4 添加文件系统原始资源:
crm(live)configure#
primitive ext4 Filesystem \ params device="/dev/disk/by-id/DEVICE_ID" directory="/mnt/ext4" fstype=ext4
在
sg_persist
克隆和文件系统资源之间添加以下顺序关系和共置约束:crm(live)configure#
order o-clone-sg-before-ext4 Mandatory: clone-sg:promote ext4:start
crm(live)configure#
colocation col-ext4-with-sg-persist inf: ext4 clone-sg:Promoted
使用
show changed
命令检查所有更改。提交更改。
有关详细信息,请参见 sg_persist
手册页。
13.10.2 使用 sfex
确保激活排它存储 #
此部分将介绍另一种低级别机制:sfex
,可将对共享存储区的访问以排它的方式锁定于一个节点。请注意,sfex 不会替代 STONITH。由于 sfex 需要共享存储,因此建议将上述 SBD 节点屏蔽机制用于存储的另一个分区。
按照设计,sfex 不能与需要并发的工作负载(例如 OCFS2)配合使用。其可作为传统故障转移型工作负载的一层保护。实际效果与 SCSI-2 保留类似,但更具一般性。
13.10.2.1 概览 #
在共享存储环境中,存储区的一个小分区专门设置为存储一个或多个锁。
在获取受保护资源之前,节点必须先获取保护锁。此顺序由 Pacemaker 强制实施。sfex 组件可确保即使 Pacemaker 遇到节点分裂情况,也不会多次授予锁。
这些锁必须定期刷新,这样某个节点的终止才不会永久性地阻止此锁,其他节点仍可继续操作。
13.10.2.2 设置 #
以下内容可帮助您了解如何创建用于 sfex 的共享分区以及如何为 CIB 中的 sfex 锁配置资源。单个 sfex 分区可存放任意数量的锁,并需要为每个锁分配 1 KB 的存储空间。默认情况下,sfex_init
将在分区上创建一个锁。
sfex 的共享分区应和要保护的数据位于同一逻辑单元上。
共享的 sfex 分区不得使用基于主机的 RAID 或 DRBD。
可以使用 LVM 逻辑卷。
创建用于 sfex 的共享分区。记下此分区的名称,并用它替换下面的
/dev/sfex
。使用以下命令创建 sfex 元数据:
#
sfex_init -n 1 /dev/sfex
校验元数据是否正确创建:
#
sfex_stat -i 1 /dev/sfex ; echo $?
此操作应返回
2
,因为当前未保存锁。
sfex 锁通过 CIB 中的资源表示,其配置如下:
crm(live)configure#
primitive sfex_1 ocf:heartbeat:sfex \ params device="/dev/sfex" index="1" collision_timeout="1" \ lock_timeout="70" monitor_interval="10" \ op monitor interval="10s" timeout="30s" on-fail="fence"
要通过 sfex 锁保护资源,请在要保护 sfex 资源的资源之间创建强制顺序和放置约束。如果要保护的资源 ID 是
filesystem1
:crm(live)configure#
order order-sfex-1 Mandatory: sfex_1 filesystem1
crm(live)configure#
colocation col-sfex-1 inf: filesystem1 sfex_1
如果使用组语法,请将 sfex 资源添加为组内的第一个资源:
crm(live)configure#
group LAMP sfex_1 filesystem1 apache ipaddr
13.11 更多信息 #
有关细节,请参见man sbd
。