我需要以主动-被动模式构建 2 节点集群（类似？）解决方案，即一台服务器处于主动模式，而另一台服务器处于被动（待机）模式，并不断从主动服务器复制数据。基于 KVM 的虚拟机将在主动节点上运行。
如果活动节点因任何原因不可用，我希望手动切换到第二个节点（变为主动节点，另一个变为被动节点）。
我看过这个教程：https://www.alteeve.com/w/AN!Cluster_Tutorial_2#Technologies_We_Will_Use
然而，我没有足够的勇气去相信全自动故障转移，并构建如此复杂的东西并相信它无法正常运行。裂脑情况、复杂性以某种方式失败、数据损坏等风险太大，而我的最大停机时间要求并不严重到需要立即进行自动故障转移。
我找不到有关如何构建此类配置的信息。如果您已完成此操作，请在答案中分享信息/操作方法。
或者也许可以使用 Linux 节点构建高度可靠的自动故障转移？Linux 高可用性的问题在于，人们似乎在 8 年前就对这一概念产生了浓厚的兴趣，而现在许多教程已经很旧了。这表明 HA 在实践中可能存在重大问题，一些/许多系统管理员干脆放弃了它。
如果可能的话，请分享如何构建它的信息以及你在集群运行方面的经验在生产中。
答案1
我有一个与您描述的设置非常相似的安装：一台 KVM 服务器，带有通过 DRBD 主动/被动方式建立的备用副本。为了使系统尽可能简单（并避免任何自动裂脑，即：由于我的客户干扰集群网络），我还放弃了自动集群故障转移。
该系统已使用 5 年以上，从未给我带来任何问题。我的音量设置如下：
- 用于虚拟机存储的专用 RAID 卷；
- 一个小的覆盖体积包含 QEMU/KVM 配置文件；
- 更大的虚拟磁盘卷；
- 管理整个DRBD 资源的专用阵列块设备。
我写了一些 shell 脚本来帮助我应对故障转移。你可以找到它们这里
请注意，该系统的设计是为了实现最高的性能，即使以牺牲快速快照和基于文件（而不是基于卷）的虚拟磁盘等功能为代价。
现在重建类似的主动/被动设置，我倾向于使用 ZFS 和通过 进行连续异步复制send/recv。它不是实时的、基于块的复制，但对于 90% 以上的情况来说已经足够了。
如果实时复制真的如果需要，我会在 ZVOL + XFS 上使用 DRBD；事实上，我在实验室中测试了这种设置 + 自动起搏器开关，结果非常满意。如果无法使用第三方模块（如 ZoL），我会在卷lvmthin+ XFS 上使用 DRBD 资源。
答案2
为什么不使用经过数千名用户测试并证明其可靠性的东西呢？您可以部署免费的 Hyper-V 服务器，例如 StarWind VSAN Free，并获得真正的 HA，而不会出现任何问题。查看此手册：https://www.starwindsoftware.com/resource-library/starwind-virtual-san-hyperconverged-2-node-scenario-with-hyper-v-server-2016
答案3
您可以完全设置 DRBD 并以纯手动方式使用它。这个过程一点也不复杂。您只需手动执行 Pacemaker 或 Rgmanager 集群所做的事情即可。本质上：
- 停止活动节点上的虚拟机
- 在活动节点上降级 DRBD
- 在对等节点上提升 DRBD
- 在对等节点上启动虚拟机
当然，这将要求两个节点都安装了适当的软件包，并且虚拟机的配置和定义都存在于两个节点上。
我可以保证，Linux HA 堆栈（corosync 和 pacemaker）仍在积极开发和支持。许多指南都很旧，该软件已经存在 10 年了。如果操作得当，不会出现重大问题。它没有被抛弃，但它不再是“新奇而令人兴奋的”。
答案4
我目前正在使用一个非常相似的系统。2 台服务器，一台活动服务器，一台备份服务器，它们内部都运行着一些虚拟机。数据库正在复制，文件服务器与 rsync 保持持续同步（但只有一种方式）。在紧急情况下，将为辅助服务器提供服务。曾经有过使用 Pacemaker 和 Corosync 的想法，但由于这必须是 100%，所以我没有勇气去尝试。我的想法是使用 NginX 监视服务器。这可以做到，因为我使用的是 Web 应用程序，但在你的情况下，我不知道你是否可以使用它。DRBD 对我来说是一团糟。以前的服务器都在使用它，虽然它似乎有效，但感觉就像我在试图解剖人体。
看看这个，它可能会对你有帮助：http://jensd.be/156/linux/building-a-high-available-failover-cluster-with-pacemaker-corosync-pcs
看起来并不难，事实上，在一个小环境中我已经尝试过并且成功了。易于学习，易于制作，易于维护。实际上我认为这就是你想要的。