我有几个问题试图了解ha.cf以及集群如何在更新上采取行动。
例如，当创build一个新的群集时，我通常：
虽然我通常上/下节点，资源上/下，我以后从来没有实际添加一个新的节点。
只是为了“有趣”，我决定运行一个新的服务器，它只在ha.cf中的集群中指定一个节点，然后启动心跳。
这台机器成功地join了群集，并将其本身添加到群集中的每个其他节点….我感到困惑的是，即使我closures所有节点，并重新启动原来的2个节点，他们都仍然有第三个服务器群集但脱机，尽pipe第三个不在原始2节点的ha.cf文件中。
即使我编辑ha.cf并改变一些无意义的值或者触摸文件，重启服务器和集群，它仍然存在。 所以我的结论是CIB优先于ha.cf，但是，我没有得到的是为什么/如何。
我真的在寻找最佳实践 – 如果任何一台机器都有足够的ha.cf来“搞定”，那么在CRM中做一切事情呢？ 是ha.cf浪费时间，还是应该使用它更多？
试着不要这么模糊 – 我只是在寻找我应该在CRM中做什么，以及我应该在ha.cf中做什么？
谢谢，
会
我真的希望自己能看到一个好的答案。
我所能做的只是赞同你的经验：在这种情况下唯一真正的心跳function是启动起搏器CRM系统。 这（如你所知）维护自己的节点和状态数据库，在我的系统上是/var/lib/heartbeat/crm/cib.xml 。 /etc/ha.d的文件通知heartbeat ，但不是crm 。
我运行了许多故障转移对，其中大部分已经过了超过500天，其中一些已经接近1000天，其中大部分已经存活了任何故障转移和故障恢复; 所以我只能假设我正在做一件事。 我的做法实际上并不在于ha.cf ，而是除了让HA启动CRM所需要的东西外几乎没有任何东西存在。
对不起，我没有什么更具体的指向你的。
显然，您在群集消息传递层Heartbeat v3之上运行了群集资源pipe理器Pacemaker。 你可以在这里find更多的信息。 例如，老版本的Heartbeat要求用户将ping节点configuration添加到ha.cf，这在Pacemaker的pingd资源代理中不再需要。
资源代理的作用是对其提供的服务进行抽象，并向集群提供一致的视图，这使得集群可以不知道其pipe理的资源。 群集不需要了解资源是如何工作的，因为它在给定启动，停止或监视命令时依赖于资源代理来做正确的事情。
所以你应该区分configuration，并检查以下内容
/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等
在你仍然活跃的节点上。 这将closures您的群集资源。
/etc/init.d/heartbeat stop
在您的备用节点（您创buildCIB的节点）上。 这将启动本地Heartbeat实例和Pacemaker，并等待其他群集节点检入。
/etc/init.d/heartbeat start
在你的另一个节点上。 这将启动本地Heartbeat实例和Pacemaker，自动获取CIB，并启动应用程序。
/etc/init.d/heartbeat start
亲切的问候