☰

我还建议进行以下测试：

tag-icon • tag-icon linux best-practices heartbeat pacemaker
我还建议进行以下测试：

在尝试理解 ha.cf 以及集群如何获取更新时，我遇到了一些问题。

例如，在创建新集群时，我通常：

  1. 在节点 1 - 节点 x 上的 ha.cf 中设置一些默认选项
  2. 启动集群。
  3. 在任意节点运行crm，配置资源。

虽然我通常会启动/关闭节点、启动/关闭资源，但我从未在以后真正添加过新节点。

只是为了“好玩”，我决定运行一个新服务器，该服务器在其 ha.cf 中仅指定集群中的一个节点，然后启动心跳。

该机器成功加入集群，并将自身添加到集群中的其他每个节点......让我感到困惑的是，即使我关闭所有节点，并重新启动原来的2个节点，它们仍然有集群中的第三台服务器，但是处于离线状态，尽管第三台服务器不在原来的2个节点的ha.cf文件中。

即使我编辑 ha.cf 并更改一些无意义的值/或触摸文件，重新启动服务器和集群，它仍然存在。所以我的结论是 CIB 优先于 ha.cf，但我不明白为什么/如何。

我真的在寻找最佳实践 - 任何机器是否都应该在 ha.cf 中拥有足够的内容来“启动它”，然后在 CRM 中执行所有操作？ha.cf 是否浪费时间，或者我应该更多地使用它？

尽量不要这么含糊 - 我实际上只是在寻找我应该在 CRM 中做什么，以及我应该在 ha.cf 中做什么？

谢谢，

会

答案1

我真的希望亲自看到一个好的答案。

我真正能做的就是赞同你的经验：在这些情况下，heartbeat 的唯一实际功能是启动 CRM 子系统 pacemakerd。它（如你所知）维护着自己的节点和状态数据库，在我的系统上是。inform/var/lib/heartbeat/crm/cib.xml中的文件，但不是。/etc/ha.dheartbeatcrm

我正在运行多个故障转移对来执行各种任务，其中大多数已经运行了 500 多天，有些已经运行了近 1000 天，而且大多数都经历了多次故障转移和故障恢复；所以我只能假设我做的是正确的。我的做法不是真的撒谎ha.cf，而是除了让 HA 启动 CRM 所需的东西之外，几乎什么都不放。

很抱歉，我没有更具体的信息可以提供给您。

答案2

显然，您在集群消息传递层 Heartbeat v3 上运行集群资源管理器 Pacemaker。您可以找到更多信息这里。例如，旧版本的 Heartbeat 要求用户将 ping 节点配置添加到 ha.cf，而使用 Pacemaker 中的 pingd 资源代理则不再需要这样做。

资源代理的作用是抽象它提供的服务并向集群提供一致的视图，这使得集群可以对其管理的资源一无所知。集群不需要了解资源的工作原理，因为它依靠资源代理在收到启动、停止或监控命令时执行正确的操作。

因此，您应该区分配置，并在您的

/etc/ha.d/ha.cf

mcast ...
bcast eth..
#disables automatic joining <== Do you have "autojoin any", here ?
autojoin none
node node1 node2
# for enabling Pacemaker under Heartbeat 3.04
pacemaker respawn
#and check manpage to track deprecated directives (baud, auto_failback, stonith, etc.)

我还建议进行以下测试：

  • 你重读好的心跳服务吗？

    杀死-HUP $ GoodHeartbeatPID

  • CRM 需要提交（cib.xml（又名集群信息库）由此命令生成）

    crm_verify-L-V

    cib 提交 $yourconf

  • 还请检查您的主机 /etc/hosts、DNS 等。

小心重启命令

在仍处于活动状态的节点上。这将关闭您的集群资源。

 /etc/init.d/heartbeat stop

在备用节点（即创建 CIB 的节点）上。这将启动本地 Heartbeat 实例和 Pacemaker，并等待其他集群节点签入。

/etc/init.d/heartbeat start

在另一个节点上。这将启动本地 Heartbeat 实例和 Pacemaker，自动获取 CIB，并启动应用程序。

/etc/init.d/heartbeat start

亲切的问候

相关内容