我们目前有一个运行虚拟机的主动 – 主动2节点群集。 每个节点有两个磁盘，每个磁盘在另一个节点上镜像DRBD。 每个节点都在其主drbd设备外运行虚拟机，起搏器集群将处理故障切换（如果一个节点发生故障，另一个则成为drbd设备上的主设备并运行所有虚拟机）。 这是在一个数据中心，所以我们的成本（硬件采购除外）是由我们占用多less机架单位驱动。
当你从小处着手时，这是一个很好的解决scheme，它适合于2U的机架空间（假设以太网交换机已经在那里），它是100％冗余的。 但是，这也是一个稍微困难的pipe理设置，当I / O负载过高时（我猜这只是因为主轴数量less）而受到影响。
我想知道什么是最好的解决scheme来扩展我们的硬件容量，同时仍然具有成本效益，而且是合理的：
拆分存储/应用程序服务器似乎是我最灵活和最合理的解决scheme，我们可以在需要时轻松添加更多存储节点，并且仍然使用当前的应用程序服务器，或者在达到容量限制时采取其他方式。
你认为什么是好的/坏的select？ 你有没有更大的预算这种东西的经验（我倾向于排除光纤通道或10000欧元的存储设备）？
编辑：要明确，这个想法是，通过利用现代（和免费）软件，你可以通过增加更多的“商品”硬件来实现冗余。 它不会尖叫快速，也不会超高可用性，但是即使主板死机，只要需要备用DC并更换部件，它也能让我们的虚拟机运行。
编辑：我删除了USB提到，因为它真的不会去任何地方（和谢谢指出，在答复中）。 我真的不知道我是如何忘记SAS机箱的。 作为戴尔网站的一个例子，MD1000是带有SAS链接的2U。 两个存储设备通过SAS连接到两个存储节点，可以实现冗余并导出iSCSI。
您一定要分开磁盘和虚拟机，因为您希望虚拟机节点访问共享存储（而不是单独镜像），以便故障转移操作几乎是无缝的。 我会弃用操作系统级别的集群来支持虚拟机级别的集群，因为根据我的经验，数据存储通常比硬件和操作系统（前提是操作系统已经设置为稳定性）和操作系统级别的问题集群中的一个节点倾向于转移到另一个节点（坏的更新，networking问题等），从而导致操作系统集群无效。 虚拟机应该有本地磁盘来运行虚拟机pipe理程序，但是虚拟机磁盘应该在共享存储上（并且至less在硬件RAID5上需要共享存储）。 将VM放入一个共享资源集群（VMWare）是一条可行的路线，因为它允许您执行非常精细的自动负载平衡。 通过这种设置，向设置中添加新的硬件就成为将新的VM服务器添加到共享磁盘，将Hypervisor放入其中并将其join群集的问题。
我对共享存储的types没有任何build议，因为知道共享存储和虚拟机世界的人往往拥有非常好的数据，而且我也推迟了他们的判断。
第一个USB磁盘永远不会给你很好的性能。
你似乎想要两件事通常不会在一起。 完全冗余高度可用的解决scheme，几乎没有钱。 冗余是昂贵的，特别是更多的选项，你想要的。 在冗余解决scheme的低端，您拥有更小的EMC，NetApp和Dell Equallogic存储解决scheme。 所有的支持iSCSI和光纤通道，所以你可以连接到他们，你想如何。 他们几乎都从4-5U的尺寸开始，并从那里上升。 这些给你一个良好的存储平台，你可以build立你的虚拟集群。
将基于主机的存储复制从一个盒子上的内部磁盘复制到另一个盒子上的内部磁盘就不会很长时间。 最终，networking将耗尽带宽，或者磁盘将无法跟上您所处的负载。 而且复制基本上是磁盘上的负载的两倍，因为每次写入磁盘都要被读取，然后通过networking传输到另一个主机上写入。 加上所有必须发生的心跳stream量。
如果业务需要有一个高可用性解决scheme，那么他们应该真的计划付钱。 这样做只会在很长的时间内工作，并最终会最终咬你。
跨数据中心IO的唯一改进就是在数据中心之间投入一些疯狂的专用带宽。 集群文件系统很大程度上依赖于最小的延迟和高带宽，以便能够很好地执行。 当存在潜伏期时，IO瓶颈呈指数级恶化。 （1-10ms是好的不坏… 10-30ms不是很好… 30ms +是非常糟糕的。）
有几种方法可以帮助减轻这些开销…通过使用其他存储方法…像S3存储…或简单的复制文件系统。
不好的一面是，因为他们被复制…如果一方更新文件在几乎相同的时间作为另一方或一方更新文件太频繁…你最终与一个脱节的复制….可以一个噩梦来整理。 这些types的存储是伟大的，如果你不经常提交…和大量的读取。
试图以低廉的价格实施像亚马逊的EBS …或S3这样的东西是不太可能的。 他们有一个更大的预算和他们的数据中心之间玩大量的带宽。