起搏器复合体资源共置

起搏器复合体资源共置

我正在为我们的主数据库和从数据库开发一个起搏器项目,以执行基于 IP 的故障转移。将有两个 IP 资源,一个用于主数据库,一个用于从数据库,它们必须一起移动。我意识到我下面标记的不是一个完整的解决方案,但要求如下:

  1. ip_dbmaster 只能在 db1 或 db21 上运行
  2. ip_dbslave 只能在 dbslave1 或 dbslave2 上运行
  3. 当 ip_dbmaster 在 db1 上时,ip_dbslave 必须在 dbslave1 上。当 ip_dbmaster 在 db2 上时,ip_dbslave 必须在 dbslave2 上
  4. 在运行 ip_dbmaster 和 ip_dbslave 之前,执行一些“操作”(shell 脚本操作、一些扩展的健康检查)。只有“操作”成功后才进行迁移
  5. 与上文相同,除了资源迁移

这是我的基本配置:

node $id="75463ec2-702c-427b-965b-b7ffb7814008" db1
node $id="a1f2d612-2d9f-4872-bf24-024f5bece3ce" dbslave2
node $id="d1d42f67-e4f2-4c71-950f-07d94ac01f8d" dbslave1
node $id="f243d865-c1a1-4d52-9100-b0d36a08207c" db2
primitive ip_dbmaster ocf:heartbeat:IPaddr2 \
  params ip="10.153.114.100" cidr_netmask="24"
primitive ip_dbslave ocf:heartbeat:IPaddr2 \
  params ip="10.153.114.101" cidr_netmask="24"
location loc-ip-dbmaster-1 ip_dbmaster \
  rule $id="loc-ip-dbmaster-1-rule" 200: #uname eq db1
location loc-ip-dbmaster-2 ip_dbmaster \
  rule $id="loc-ip-dbmaster-2-rule" 0: #uname eq db2
location loc-ip-dbmaster-3 ip_dbmaster \
  rule $id="loc-ip-dbmaster-3-rule" -inf: #uname eq dbslave2
location loc-ip-dbmaster-4 ip_dbmaster \
  rule $id="loc-ip-dbmaster-4-rule" -inf: #uname eq dbslave1
location loc-ip-dbslave-1 ip_dbslave \
  rule $id="loc-ip-dbslave-1-rule" 200: #uname eq dbslave1
location loc-ip-dbslave-2 ip_dbslave \
  rule $id="loc-ip-dbslave-2-rule" 0: #uname eq dbslave2
location loc-ip-dbslave-3 ip_dbslave \
  rule $id="loc-ip-dbslave-3-rule" -inf: #uname eq db1
location loc-ip-dbslave-4 ip_dbslave \
  rule $id="loc-ip-dbslave-4-rule" -inf: #uname eq db2
property $id="cib-bootstrap-options" \
  dc-version="1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd" \
  cluster-infrastructure="Heartbeat" \
  expected-quorum-votes="2" \
  stonith-enabled="false" \
  symmetric-cluster="false"

到目前为止,#1 和 #2 运行良好。#3 似乎有点类似于主机托管,但我不知道从哪里开始或如何设置依赖关系。我看到了一个规则引擎,但我还没有完全弄清楚。对于 4-5,我不知道这是否可以通过 pacemaker 完成,或者我是否必须编写外部脚本来处理这部分。

我的目标是能够做到这一点:

crm resource move ip_dbmaster db1

让一切顺其自然。我会满足于

dbfailover db2

...我是否必须对 Pacemaker 外部的一些内容进行编码,或者是否可以将其内置。

感谢你的帮助!

答案1

首先,我要说的是,在过去十年中,我设置了不少集群,但我从未见过像您所描述的那样存在依赖关系的集群。通常,人们会这样设置它,即所提供的服务不依赖于哪个主机处于活动状态和哪个主机处于待机状态,并且您不关心哪个主机拥有资源,只要它在其中一个主机上启动即可。

我能想到的唯一实现方法是将从属节点实现为主节点启动的资源,例如通过 SSH 连接到从属节点以运行 IPaddr2 和您需要的其他资源。可能使用带有身份文件和 authorized_keys 条目的 SSH 公钥身份验证,以便主节点可以在从属节点上运行命令而无需密码。

因此,这需要创建一个“slaveIPaddr2”资源脚本,该脚本只需包装如下命令:

HOST=`hostname`
exec ssh -i /path/to/ssh-identity dbslave$${HOST#db} /path/to/IPaddr2 "$@"

然后将ip_dbslave资源更改为“slaveIPaddr2”而不是“IPaddr2”作为要运行的资源。

至于迁移前后要运行的脚本,这些脚本听起来就像是组成资源组的普通多资源脚本,并使用“group”和“order”配置项进行优先排序。例如,创建“master_pre”(要在主服务器上运行的“before”脚本)、“slave_pre”、“master_post”等资源,然后使用“order”指定它们以适当的顺序运行(master_pre、slave_pre、ip_dbmaster、ip_dbslave、master_post、slave_post)。在这里,您可能还需要使用 SSH 包装器包装从属项,以便有效地将它们视为我上面提到的单个主机。

听起来你希望在尝试迁移之前运行“pre”脚本,而不是作为启动资源的一部分?除非你告诉它,或者当前运行服务的节点发生故障,否则 Pacemaker 不会迁移服务。如果节点发生故障,你的服务无论如何都会关闭,因此没有理由检查以避免迁移。因此,如果你担心在告诉它迁移时阻止迁移,最好的答案可能是制作一个“迁移”脚本来运行你的预服务检查,并且只有在测试成功时才继续执行迁移请求。

如果您想通过#4 实现这一目标,那么我不知道在进行迁移之前,如何在 Pacemaker 中测试集群中的其他主机,那么很可能必须进行强制执行的外部检查。

通过“group”和“order”指令可以轻松运行除IPaddr2之外的其他资源。

相关内容