DRBD 文档（在将 DRBD 与 Pacemaker 集群集成部分）建议应在 Pacemaker 集群中禁用 DRBD：
如果您正在使用 DRBD OCF 资源代理，建议您将 DRBD 启动、关闭、升级和降级专门推迟到 OCF 资源代理。这意味着您应该禁用 DRBD 初始化脚本：
chkconfig drbd off.
在 systemd 下，这相当于systemctl disable drbd.service.
尽管有此建议，但启用 DRBD 有什么害处吗？这个想法是启用 DRBD，但禁用 Corosync 和 Pacemaker，以便在集群节点发生故障并重新启动后，它将继续接收 DRBD 同步的数据，但否则将保持“被动”状态。这应该允许在故障节点重新进入集群之前对其进行分析，但同时实时数据仍保存在两个集群节点上。建议背后的理由是什么？
那么在操作系统级别禁用 DRBD 服务的目的是一切都由起搏器控制。如果两个服务（例如，PCMK 和您的操作系统）正在尝试启动/停止/提升/降级等，那么您就有脑裂的风险。对于受控的集群环境，一切都应该由集群资源管理器（在本例中为起搏器）处理，以避免集群节点之间的混淆。在脑裂或类似情况下，您的 CRM 将使用 STONITH 或隔离或使用其他节点上配置的仲裁来解决它。
使用集群资源管理器时，任何资源都应该由资源管理器控制。从集群资源管理器外部启用/禁用的任何资源都是潜在的混淆源，对于管理员和资源管理器本身都是如此。
已经有两个答案清楚地表明这是一个坏主意以及为什么，但也许一些关于它如何对您出错以及如何使用 Pacemaker 解决这些问题的细节将有助于说服您和/或其他人不这样做。
首先，Pacemaker 记录和说明资源故障。资源在从节点“禁止”之前的默认失败计数是资源失败超时窗口内的三个，默认情况下永远不会超时。因此，如果您的 DRBD 资源（或与此相关的任何其他资源）连续失败 3 次，则通过使用强（无限）“负位置约束”将其从其当前活动节点禁止，这意味着该资源可以在任何地方运行但其当前活动节点。一旦该规则到位，资源要么尽可能移动到其他地方，要么停止直到其故障得到解决。
所以你可以看到，Pacemaker 可以自己优雅地处理这些故障。
您需要了解 Pacemaker 是什么以及它的行为方式，以了解为什么管理它强制执行 Pacemaker 外部状态的资源是不好的。起搏器是一个有限状态系统。它依赖于对其管理的资源的完全控制，以便它可以从故障中优雅地恢复，并确保资源在它们应该在的地方停止或启动。
考虑一次只能在一个节点上运行的简单资源，以免它变成“裂脑”并创建不同的数据集——这几乎是可能发生的最糟糕的事情，因为这几乎肯定会导致数据丢失或需要大量操作人员注意防止数据丢失。
Pacemaker 控制此资源，并在节点“Able”上启动软件实例。好心的管理员发现服务是在 Able 上启动的，但是它的 systemd 单元文件被“禁用”了。该管理员启用单元文件，以便服务将在重新启动时“返回”，不知道 Pacemaker 已经在处理这个问题。systemd 单元文件被配置为在失败时重新启动资源，就像许多一样。
一旦 Pacemaker 尝试将此资源从 Able 迁移到集群“Baker”中的第二个节点，该资源就会遇到停止故障，因为该服务已被终止，但不知何故它仍然活着，而我们正处于僵尸末日之中。由于无法停止资源，因此无法在 Baker 上启动它而不会导致脑裂情况。随着 systemd 和 Pacemaker 争夺控制权，资源在停止和启动之间波动。最终，Pacemaker “放弃”该资源并将其置于“非托管模式”，这意味着不会对该资源执行任何启动或停止操作。
所以在那种情况下，Systemd 赢了，因为它比 Pacemaker“更愚蠢、更坚持”。对于不熟悉 Pacemaker 和 Systemd 行为的管理员来说，这是非常难以理解的，因为它看起来就像 Pacemaker 到处都失败了——而实际上它正在按照条件做它应该做的事情在眼前。
还要考虑到上述情况在该条件下具有最好的结局。考虑到最轻微的基础设施故障，集群将成为裂脑，并且该资源在两个节点上都处于活动状态。
顺便说一句，在这种情况下，通过 STONTIH 进行防护可以防止集群发生裂脑，但 STONITH 是集群稳定性的最后手段，而上述情况几乎可以将其作为首选手段。和往常一样，您需要 STONITH 才能使集群做好生产准备。