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