是否有关于小型冗余 VM 基础设施的推荐?

是否有关于小型冗余 VM 基础设施的推荐?

我们目前有一个运行虚拟机的主动-主动 2 节点集群。每个节点都有两个磁盘,每个磁盘都是在另一个节点上的 DRBD 镜像。每个节点都从其主 drbd 设备运行虚拟机,而 Pacemaker 集群将处理故障转移(如果一个节点发生故障,另一个节点将成为两个 drbd 设备上的主节点并运行所有虚拟机)。它位于一个数据中心内,因此我们的成本(硬件采购除外)取决于我们占用的机架单元数。

当您从小处着手时,这是一个很好的解决方案,它适合 2U 机架空间(假设以太网交换机已经存在),并且它是 100% 冗余的。但它也是一个稍微难以管理的设置,当 I/O 负载过高时,它会受到影响(我猜那只是因为主轴数量少)。

我想知道什么可能是最好的解决方案,可以扩展我们的硬件容量,同时仍然具有成本效益并且尽可能合理地冗余:

  • 继续添加具有内部存储的双节点集群,可能使用更大的硬件(例如具有更多磁盘的 2U 服务器)
  • 仍然使用双节点集群,但使用外部直接连接存储(带有 SAS 链路的 1U 或 2U 磁盘柜等)- 请参阅下面的注释
  • 单独的存储和虚拟机(例如,一对由 DRBD 镜像的存储节点,它们通过移动 iSCSI 目标 IP 来导出 iSCSI 并管理故障转移,再加上两个或多个在静态 iSCSI 目标 IP 之外运行虚拟机的无盘节点) - 这似乎是其他人正在做的事情?
  • 在存储部分使用与标准服务器不同的东西(千兆以太网上的专用存储解决方案?)
  • 还有什么吗?

拆分存储/应用程序服务器对我来说似乎是最灵活、最合理的解决方案,我们可以在需要时轻松添加更多存储节点,同时仍然使用当前的应用程序服务器,或者在达到容量限制时反过来做。

您认为哪些是好的/坏的选择?您是否已经有过这类东西的经验,而预算又不大(我倾向于排除光纤通道或 10,000 欧元的存储设备)?

编辑:明确地说,这个想法是通过利用现代(和免费)软件,您只需添加更多“商品”硬件即可实现冗余。它不会很快,也不会有超高的可用性,但它会让我们的虚拟机即使主板坏了也能运行,只要将备件送到 DC 并更换零件即可。

编辑:我删除了 USB 的提及,因为它实际上没有任何用处(感谢您在回复中指出这一点)。我真的不知道我怎么会忘记 SAS 机箱。以戴尔网站上的一个例子为例,MD1000 是 2U,带有 SAS 链路。两个机箱通过 SAS 连接到两个存储节点,它们可以实现冗余并导出 iSCSI。

答案1

您肯定希望将磁盘和虚拟机分开,因为您希望虚拟机节点访问共享存储(而不是单独的镜像),以便故障转移操作几乎无缝。我会反对操作系统级集群,而支持虚拟机级集群,因为根据我的经验,数据存储往往比硬件和操作系统更容易受到攻击(前提是操作系统已经设置为稳定),并且影响集群一个节点的操作系统级问题往往会延续到另一个节点(错误更新、网络问题等),从而使操作系统集群无效。虚拟机应该有本地磁盘来运行虚拟机管理程序,但虚拟机磁盘应该位于共享存储上(并且您至少希望该共享存储处于硬件 RAID5 状态)。将虚拟机放入共享资源集群(a la VMWare)是可行的方法,因为它允许您进行非常精细的自动负载平衡。使用此设置,将新硬件添加到设置中就变成了将新虚拟机服务器添加到共享磁盘、将虚拟机管理程序放在其上并将其加入集群的问题。

我对共享存储的类型没有任何建议,因为了解共享存储和虚拟机世界的人往往拥有非常好的数据,我会听从他们的判断。

答案2

首先,USB 磁盘永远不会给你带来良好的性能。

您似乎想要两件通常不会同时出现的东西。一个完全冗余、高度可用的解决方案,几乎不需要花费任何费用。冗余是昂贵的,尤其是您想要的选项越多。在低端冗余解决方案中,您有较小的 EMC、NetApp 和 Dell Equallogic 存储解决方案。它们都支持 iSCSI 和光纤通道,因此您可以随心所欲地连接到它们。它们几乎都从 4-5U 大小开始,然后从那里开始增加。它们为您提供了一个良好的存储平台,然后您可以在其周围构建虚拟集群。

从一个盒子的内部磁盘到另一个盒子的内部磁盘进行基于主机的存储复制不会持续很长时间。最终,网络将耗尽带宽,或者磁盘无法跟上您施加的负载。复制基本上使磁盘负载翻倍,因为每次写入磁盘都必须读取,然后通过网络传输到另一台主机进行写入。此外,还必须进行所有心跳流量。

如果企业需要高可用性解决方案,那么他们应该真正计划好为此付费。廉价的解决方案只能维持一段时间,最终会给你带来损失。

答案3

实现数据中心间 IO 显著改善的唯一方法就是在数据中心之间投资大量专用带宽。集群文件系统严重依赖最小延迟和高带宽才能获得良好性能。当存在延迟时,IO 瓶颈会成倍增加。(1-10 毫秒还好,不算太糟……10-30 毫秒不算好……30 毫秒以上就相当糟糕了。)

有几种方法可以帮助减轻这些开销……通过使用其他存储方法...例如 S3 存储...或简单的复制文件系统。

缺点是,由于它们是复制的...如果一方在与另一方几乎相同的时间更新文件,或者一方过于频繁地更新文件...最终会导致复制脱节...这可能是一场噩梦。如果您不经常提交...但有大量读取,这些类型的存储非常有用。

尝试以低成本实现像 Amazon 的 EBS... 或 S3 这样的功能充其量也是不可能的。他们有更大的预算,并且数据中心之间有大量的带宽可供使用。

相关内容