我在使用 pacemaker/corosync（2 节点）集群时遇到问题Ubuntu（12.04 / 14.04 / 16.04 和 18.04），找不到其他人描述此问题。有两个资源：res_ip（虚拟 IP）和 res_apache（apache2）。这些只是资源的示例。任何类型的共存/共置资源都会出现此问题。
res_apache 与 res_ip 共置，以使 apache 始终在“活动”服务器上运行，该服务器可通过虚拟 ip 访问。有些情况下，res_ip 发生故障并重新启动，这会导致 res_apache 也重新启动（如预期的那样），并留下一个故障计数。
问题： 尝试清理资源 res_ip (crm 资源清理 res_ip）导致Apache 软件基金会（这取决于 res_ip）重新启动，但我不知道为什么。
在 CentOS 上执行相同的命令不会导致 Web 应用程序的运行中断。该命令仅清除失败计数。
附件 node1_corosync.log.extract.txt 显示 res_ip 被识别为停止（第 951 行）因此依赖的 res_apache 被重新启动。清理命令在那个时间（15:18:17）左右运行，因此我假设检查资源是否正在运行是由清理命令发起的。它不应该处于“停止”状态，因此不会重新启动依赖的资源 res_apache。
我需要再次指出的是，我发现所有 Ubuntu 版本都存在这个问题，但在 CentOS 上没有，并且资源类型并不重要。
有人知道为什么会发生这种情况吗（并且只发生在 Ubuntu 中）？
日志文件和配置：https://1drv.ms/u/s!Av4S568oLfJmgZtQ6pcE40FOKN8yDg?e=IOHKX8
答案1
（您应该在您使用的任何软件（您在那里尝试过吗？）的邮件中，首先寻找并提供帮助！）下面摘录自 clusterlab 邮件列表，答案来自 Redhat 人员（尽管它可能因集群版本而异）......
当我调用“pcs resource cleanup Res1”时，这将导致 Res2 一侧的服务中断（即停止 Res2……）我的假设（未经证实）是，起搏器将首先通过调用监视器来检测资源的当前状态，然后决定是否有任何操作要执行。但从读取日志文件来看，我会认为 Res1 暂时从 cib 中移除并重新插入。这会导致停止 Res2，直到 Res1 确认状态为“已启动”。
正确，删除资源的操作历史记录是起搏器触发对当前状态的重新探测的方式。
根据我对文档的理解，可以通过使用 kind=Optional 配置顺序约束来避免此行为。但我不确定这是否会导致任何其他不应有的副作用。（例如，停止时按相反顺序）
kind=可选约束仅适用于两个操作都需要在同一转换中完成的情况。即，如果单个集群检查发现 Res1 和 Res2 都需要启动，则 Res1 将在 Res2 之前启动。但完全有可能 Res2 可以在较早的转换中启动，而 Res1 仍处于停止状态，而较晚的转换启动 Res1。同样，当停止时，如果两者都需要停止，则 Res2 将首先停止。
在您最初的场景中，如果您的主/从资源仅在启动后才绑定到 IP，则 kind=Optional 将不可靠。但如果主/从资源绑定到通配符 IP，则顺序实际上并不重要 - 您可以保留共置约束并删除顺序。
另一种解决方法似乎是将依赖资源设置为非托管，执行清理，然后将其重新设置为托管。
如果您必须保留强制排序，这就是我所推荐的。
我想知道，如果不需要改变状态，那么“pcs resource failcount reset”是否可以在不执行任何操作的情况下解决问题。但我记得我们已经不时尝试过这种方法，有时这种失败的资源在故障计数重置后不会启动。（但我不确定，也没有时间尝试重现。）
不，在较新的 Pacemaker 版本中，crm_failcount --delete 相当于 crm_resource --cleanup。（pcs 调用这些来实际执行工作）
是否有更深入的见解可以帮助全面理解这个问题？
这是当前 CIB 实现的一个副作用。Pacemaker 的策略引擎通过检查资源在 CIB 中的操作历史记录来确定资源的当前状态。清理会删除操作历史记录，从而使当前状态未知，从而强制重新探测。作为副作用，任何依赖项都不再满足其约束，直到重新探测完成。
理论上可以实现“清除旧故障”选项，该选项将清除资源的失败计数并仅删除失败操作的操作历史记录条目，只要这样做不会改变当前状态确定即可。但这会相当复杂，将资源设置为不受管理是一种简单的解决方法。
>