您可能熟悉采用单个主机并能够通过在所有实例之间共享资源来“模拟”许多实例的虚拟化。您可能听说过XEN。
想象 XEN 的“对立面”是不是完全疯了：在一个运行实例中抽象多个主机的层？我相信这将允许构建不需要真正关心“集群”层本身的应用程序。
我想知道这有什么技术限制，因为我很确定有些人已经在某个地方工作了:)
目标不是实现任何类型的故障恢复。我相信这可以（而且应该？）在更高的层次上处理。例如，如果有人能够在一个巨大的实例（由 50 台主机组成）上运行 MySQL 服务器，那么可以轻松地使用 MySQL 的复制功能在类似的虚拟实例上复制数据库。
好问题。Microsoft Azure 正试图通过允许您将应用程序放在“云中”来解决这个问题，而不必担心向上/向下扩展、冗余、数据存储等问题。但这不是在管理程序级别完成的。
http://www.microsoft.com/windowsazure/
在硬件方面，让所有东西都成为一个大虚拟机而不是许多小虚拟机有一些缺点。一方面，软件并不总是了解如何处理所有资源。例如，某些应用程序仍然无法处理多个处理器内核。我已经看到非正式的基准测试表明 IIS 在多个实例而不是一个巨大的实例上分布相同资源的性能更好。
从管理的角度来看，在某些情况下拥有多个虚拟机可能会更好。想象一下，一个糟糕的部署会破坏一个节点。如果那是您唯一的（尽管是巨大的）节点，那么现在您的整个应用程序都已关闭。
您可能正在谈论Single System Image的概念。
曾经有一个 Linux 实现，openMosix，后来关闭了。我不知道有什么替代品。openMosix使得在标准 Linux 内核上创建和使用 SSI 变得非常容易；太糟糕了，它被事件超越了。
我对 Xen 的了解还不够，不知道它是否可行，但使用 VMware，您可以创建来自许多物理主机的资源池。然后，您可以将资源分配给您的虚拟机。这可能是许多 VM 或只有一个 VM。 聚合：将隔离资源转换为共享池
在多个物理内核上模拟单个内核的效率非常低。你可以做到，但它会比集群慢。两个物理核心可以近乎实时地相互通信，如果它们在不同的机器上，那么你正在做的事情就是说如果这两个物理核心（和 RAM）将你的主板速度降低 10 倍或更多甚至通过光纤网络进行通信。
双核可以比同一主板上的两个不同 CPU 进行更快的通信，如果它们在不同的机器上，那就更慢，如果有多台机器，甚至更慢。
基本上可以，但是与您希望实现的净性能提升相比，存在净性能损失。
现实生活中的例子，我在双四核服务器（~2.5Ghz/core）上有一堆虚拟机，其性能远低于它们应有的水平。仔细检查后发现，当单个 VM 上的负载超过 2.5Ghz 时，管理程序正在模拟单个 3.5-4Ghz 内核——在将每个 VM 限制为 2.5Ghz 性能回到预期之后。
我同意sayimu，你在谈论单一系统映像的概念。除了 OpenMosix 项目之外，还有几个相同想法的商业实现（一个当代的例子是 ScaleMP）。这不是一个新想法。
我只是想详细说明一下SSI的一些技术要点。
基本上，它没有完成的原因是因为性能通常是绝对不可预测或可怕的。计算机系统中有一个概念被称为 [NUMA][3]，这基本上意味着访问不同内存块的成本是不统一的。这可能适用于 CPU 可能会将一些内存访问路由到不同芯片的大型系统，或者通过网络远程访问内存的情况（例如在 SSI 中）。通常，操作系统会尝试通过在内存中布置程序和数据以使程序可以尽可能快地运行来弥补这一点。即，代码和数据都将被放置在同一个 NUMA“区域”中，并被安排在最接近的 CPU 上。
但是，如果您正在运行大型应用程序（尝试使用SSI 中的所有内存），操作系统几乎无法减少远程内存获取的影响。MySQL 不知道访问页面 0x1f3c 将花费 8 纳秒，而访问页面 0x7f46 将使其停滞数百微秒，可能是通过网络获取内存时的毫秒。这意味着非 NUMA 感知应用程序将在这种环境中像垃圾一样运行（严重，非常糟糕）。据我所知，大多数现代 SSI 产品都依赖于机器之间尽可能快的互连（例如 Infiniband）来实现甚至可以接受的性能。
这也是为什么向程序员公开访问数据的真实成本的框架（例如 MPI：消息传递接口）比 SSI 或 DSM（分布式共享内存）方法获得了更大的吸引力。事实上，程序员基本上没有办法优化应用程序以在 SSI 环境中运行，这很糟糕。