我们正在寻找一种方法来提高我们的一个服务器（Apache/MySQL/Virtualmin 设置）的可靠性。到目前为止，在过去的六个月里，我们已经对那台服务器进行了各种可能的 clusterfuck（DNS 故障、DDOS、Dom0 故障、网络中断、DomU 故障……；在美好的第 2 天），而所有问题都得到了解决在不到一天的时间里，它仍然令人担忧——该主机上大约有 50 个客户网站，每次服务器宕机时它们都会让我们感到窒息（服务器的可用性仍然超过合同保证的 99%，但是……你请记住服务器有 5 次停机，而不是 360 天）。
到目前为止的计划：
主机将位于不同的（Hetzner，顺便说一句）数据中心，因此我们的带宽相当有限（100 MBit 上行链路，并且至少应该为实际用户留下一些带宽......）并且数据加密更多或少一个固定的要求。
DRBD 本身在 WAN 上的扩展性很差，也不提供加密。DRBD 代理声称可以解决带宽问题（但不是加密问题，据我所知），但从我读到的内容来看，它实在是太贵了，每年 5000 美元太多了（我很确定这不仅仅是什么我们正在通过该服务器赚钱）。
另一方面，根据我的个人经验，OpenVPN/SSH 隧道不够可靠，无法保证我们不会有错误警报触发不必要的故障转移（更不用说降低硬盘性能的开销）。
那么......有什么替代方案？还是我只是忽略了什么？
编辑：澄清一下，我更喜欢文件系统/块设备级别的复制。应用程序级复制是可能的，但我宁愿运行一个复制解决方案，而不是为每个应用程序运行一个。
我需要为 Apache 网站设置两节点 Web 集群。我有 Hyper-V 基础设施，只有两个节点。重点是负载平衡和高可用性。
我安装并配置了两个带有 CentOS 7、Pacemaker 集群、MariaDB 10 的虚拟机。我在 Pacemaker 中配置了主/从 ocf::percona:mysql 资源。
接下来我需要一个用于网站内容的共享存储。我在双主模式下创建了 DRBD 磁盘，并在其顶部创建了 GFS2。我在没有添加到 Pacemaker 的情况下对其进行了测试。一切正常，但为了使其自动升级，我需要通过 Pacemaker 管理这些。
问题是 Pacemaker 需要围栏来创建 DRBD 资源，但没有用于 Hyper-V 的 stonith 代理。我读到在 CentOS 6 的先前版本中可以创建 SSH stonith 代理。我尝试这样做，但 pcs 无法使用它。
现在可以在 Hyper-V 之上使用 Pacemaker 吗？或者可能存在另一种在双主中使用 DRBD 的方法？
我在 2 个服务器节点之间设置了一个 drbd 资源 - 在两者之间进行同步测试时一切正常。（我想使用 drbd、xen 和 heartbeat 创建一个 HA 集群）
但是，当我尝试使用 Centos 作为来宾操作系统创建 XEN VM 时，我进入安装时的分区屏幕，但是当我选择分区类型时，下一个屏幕显示以下错误：
“发生错误 - 未找到可在其上创建新文件系统的有效设备。请检查您的硬件以查找此问题的原因。”
这是第一次尝试创建这样的设置，搜索谷歌并没有太大帮助......
我的 DRBD 和 XEN 配置文件....
DRBD（只是相关的部分）
在 xennode0 { 设备 /dev/drbd0; 磁盘 /dev/sda5; 地址XXXX：7788；内部灵活元磁盘；}
在 xennode1 { 设备 /dev/drbd0; 磁盘 /dev/sda5; 地址XXXX：7788；元磁盘内部；}
XEN
kernel = "/boot/xeninstall/vmlinuz" ramdisk = "/boot/xeninstall/initrd.img" extra = "text" name = "VM" maxmem = 3000 memory = 3000 vcpus = 4 on_poweroff = "destroy" on_reboot = "restart " on_crash = "restart" vfb = [ …
我有两到三台较旧的 HP ProLiant DL380 G6/7 服务器，只有 x * 1 GBit 以太网，但 CPU 功率、RAM 和本地存储容量相当可观。我有兴趣构建一个由两个甚至三个节点组成的小型集群式设置，其中所有节点都提供服务，这与我目前对“超融合”流行语的理解非常相似。这些服务特别托管 VM，这些 VM 本身为不同的 Web 应用程序、一些守护程序、数据库等托管 Web 服务器。在应用程序级别上非常不同的东西，一些 I/O 绑定，一些不是。
这些服务器目前正在使用 Synology 的一些入门/中端 NAS，但事情不再那么好用了。我在让 NAS 在繁重的 I/O 负载下可靠工作时遇到了问题，除了一些基准测试之外，日常性能也不是很好。所以我正在研究不同的选项，比如集群文件系统、DRBD、即用型解决方案，比如 Proxmox 等等。
我目前问自己的主要问题是，是否有某种方法可以通过构建更喜欢本地读取和写入的“东西”来使网络成为一些可能的瓶颈。例如，DRBD 提供了复制协议 A，这正是我想到的。可能的数据丢失的时间跨度可能是某人认为可以接受的风险，查看每台服务器的冗余硬件等。此外，人们可能根本不需要在所有给定时间在所有节点上托管应用程序的可能性，但在节点更新和重启等情况下，仅在节点上移动应用程序可能是可以接受的。这样的事情可能会完成手动，经过一些准备步骤或其他什么。
重要的一点是，如果节点在大部分时间都托管自己的应用程序，则可以通过之后的异步写入通信来进行大量本地读取和写入。这也正是DRBD 文档所说的：
无论如何，在双主模式下使用 DRBD 作为 GFS 的复制存储设备是完全可能的。由于 DRBD 通常从本地存储读取和写入本地存储，而不是 GFS 通常配置为运行的 SAN 设备，因此应用程序可能会受益于减少的读/写延迟。
在块级别是否有没有 DRBD 的可比技术？也许一些集群文件系统自己已经提供了这样的东西？此外，如果所建议的内容仅适用于开箱即用的当前 Ubuntu 发行版，那将是有益的，因为这是我目前为服务器选择的操作系统。