为什么我们不能构建在多台机器上运行的虚拟化？

Question

您可能熟悉虚拟化，它采用单个主机，并且能够通过共享所有实例之间的资源来“模拟”许多实例。您可能听说过XEN。

想象XEN的“相反”是完全疯狂的：一个在一个正在运行的实例中抽象几个主机的层？我相信这将允许构建不需要真正关心“聚类”层的应用程序。

我想知道对此有什么技术限制，因为我很确定有些人已经在某处工作了：）

目标不是实现任何类型的故障恢复。我相信这可以（并且应该？）在更高的层次上处理。例如，如果有人能够在巨大的实例（由50个主机组成）上运行MySQL服务器，那么可以轻松地使用MySQL的复制功能通过类似的虚拟实例复制数据库。

Answer 1

好问题。 Microsoft Azure试图通过允许您将应用程序“置于云中”来解决这个问题，而不必担心可扩展性上/下，冗余，数据存储等。但这不是在虚拟机管理程序级别完成的。

http://www.microsoft.com/windowsazure/

硬件方面， 一些缺点是让所有东西都成为一个大虚拟机而不是许多小虚拟机。首先，软件并不总是了解如何处理所有资源。例如，某些应用程序仍然无法处理多个处理器核心。我已经看到非正式基准测试显示IIS在多个实例上而不是一个巨型实例上更好地传播相同的资源。

从管理角度来看，在某些情况下拥有多个VM可能更好。想象一下，错误的部署会破坏节点。如果那是你唯一的（虽然是巨大的）节点，现在你的整个应用程序都已关闭。

Answer 2

你可能在谈论概念Single System Image。

自从关闭以来，曾经有一个Linux实现openMosix。我不知道有什么替代品。 openMosix使得在标准Linux内核上创建和使用SSI变得非常容易;太糟糕了，它被事件所取代。

Answer 3

我不太了解Xen知道是否可行，但使用VMware，您可以创建来自许多物理主机的资源池。然后，您可以将资源分配给VM。这可能是许多虚拟机或只有一个虚拟机。 Aggregation: Transform Isolated Resources into Shared Pools

Answer 4

在多个物理核心上模拟单个核心效率非常低。你可以做到，但它会比集群慢。两个物理内核可以近乎实时地相互通信，如果它们位于不同的机器上，那么如果这两个物理内核（和RAM）的话，你可以做一些事情，例如将主板速度提高10倍或更多甚至通过光纤网络进行通信。

双核可以在同一主板上比两个不同的CPU更快地通信，如果它们在不同的机器上，那么如果有多台机器那么速度再慢，再慢一点。

基本上你可以，但与你希望实现的净性能增益相比，有净性能损失。

现实生活中的例子，我在双四核服务器（~2.5Ghz / core）上执行了一系列虚拟机，方式低于应有的水平。经过仔细观察，结果发现，当单个VM上的负载超过2.5Ghz时，虚拟机管理程序正在模拟单个3.5-4Ghz核心 - 在将每个VM限制为2.5Ghz之后，性能又回到了预期的水平。

Answer 5

我同意sayimu，你说的是单系统映像概念。除了OpenMosix项目之外，还有一些商业实现相同的想法（一个当代的例子是ScaleMP）。这不是一个新想法。

我只是想详细说明SSI的一些技术要点。

基本上，它没有完成的原因是因为性能通常是绝对不可预测或可怕的。在称为[NUMA] [3]的计算机系统中存在一个概念，其基本上意味着访问不同存储器的成本不均匀。这可以应用于大型系统，其中CPU可能有一些存储器访问路由到不同的芯片，或者在通过网络远程访问存储器的情况下（例如在SSI中）。通常，操作系统将尝试通过以程序可以尽可能快地运行的方式在程序存储器中布置程序和数据来对此进行补偿。即，代码和数据将全部放在相同的NUMA“区域”中，并安排在最近的CPU上。

但是，在运行大型应用程序（尝试在SSI中使用 all 内存）的情况下，操作系统几乎无法减少远程内存提取的影响。 MySQL不知道访问页面0x1f3c将花费8纳秒，而访问页面0x7f46将使其停止数百微秒，可能是毫秒，同时通过网络获取内存。这意味着非NUMA感知应用程序将在这种环境中像垃圾（严重，非常糟糕）一样运行。据我所知，大多数当代SSI产品依赖于机器之间最快的互连（如Infiniband），以实现更好的性能。

这也是为什么向程序员公开访问数据的真实成本（例如MPI：消息传递接口）的框架比SSI或DSM（分布式共享内存）方法获得更多的牵引力。实际上，程序员基本上没有办法优化应用程序在SSI环境中运行，这很糟糕。