我有两台或三台类似于HP ProLiant DL380 G6 / 7的稍旧的服务器，只有x * 1 GBit以太网，但CPU功率，内存相当大，并且具有相当数量的本地存储。 我感兴趣的是build立一个两个甚至三个节点的小型集群设置，其中所有这些提供服务，就像我目前对“超融合”stream行词的理解。 这些服务尤其是托pipe虚拟机，这些虚拟机本身为不同的networking应用程序，一些守护进程，数据库等提供了Web服务器。在应用程序级别上有很多不同的东西，有些是I /
目前这些服务器正在使用Synology的一些入门/中档NAS，而且现在的情况已经不再那么好了。 我有一些问题，除了一些基准testing还不是很好以外，让NAS在繁重的I / O负载和日常性能方面工作可靠。 因此，我正在研究不同的选项，如集群文件系统，DRBD，即可安装的解决scheme（如Proxmox等）。
我现在问自己的主要问题是，如果通过构build更喜欢本地读写的“某些东西”，某种方式可能使networking成为某种可能的瓶颈。 例如，DRBD提供了复制协议A ，这正是我所想到的。 可能的数据丢失的时间跨度可能是某人认为是每个服务器等冗余硬件的可接受风险。 另外，在某些特定时间，可能不需要在所有节点上托pipe应用程序，但在节点更新和重新启动等情况下，仅在节点上移动应用程序是可以接受的。手动，经过一些准备步骤或其他。
重要的一点是，如果节点大部分时间都会托pipe自己的应用程序，那么之后可能会受益于大量本地读取和写入操作的asynchronous通信。 这正是DRBD文档所说的 ：
无论如何，完全可以在双主模式下使用DRBD作为GFS的复制存储设备。 由于DRBD通常从本地存储读取和向本地存储写入这一事实，应用程序可能会因为读取/写入延迟减less而受益，与GFS通常configuration为运行的SAN设备相反。
在块级有没有DRBD的可比技术？ 也许有些集群文件系统已经提供了这些东西？ 另外，如果提供的任何东西只是简单地与当前的Ubuntu发行版一起使用，那将是有益的，因为这是当前服务器的我select的操作系统。
由于您最好提供具有本地I / O的共享存储系统，因此我build议您查看在群集主机之间进行asynchronous复制的解决scheme。 我怀疑在主动 – 被动共享存储上创build多个集群共享卷将提供所需的本地I / O。
我可以build议StarWind Virtual SAN，因为它似乎是你正在寻找的。 https://www.starwindsoftware.com/starwind-virtual-san