一些同事建议采用一种 Web 负载平衡方案，其中多个 Web 服务器（IIS7）位于同一硬件上的不同虚拟机上。
这是一个真正有利的设置吗？所有机器都是 64 位的，因此内存寻址不应该成为问题。
答案1
我的看法是：通过虚拟化，你可以将一些处理资源放入沙盒中。你可以将 Web 服务器分成离散单元；你可以升级一台服务器，同时让另一台服务器接管，如果出现问题，还可以重定向请求。
您可以对虚拟机进行快照以解决生产问题。
当您获得虚拟机时，您可以更轻松地将其迁移到单独的硬件上，因此，您无需迁移裸机设置（配置全新的 Web 服务器），只需将虚拟机移动到新机器上即可，或者，如果您设置了“适当”的集群，您的虚拟机将处于良好的位置，可以直接投入生产，而不必从头开始重新配置。
如果需要，您可以为 NIC 设置单独的 VSwitches 来控制流量。
我认为它提供了更大的灵活性和选项，可以让 VM 主机上的多台机器来处理您的网站。
另一方面，如果您只有一台主机，则可能会出现故障点问题。如果您至少有两个 NIC，这有助于缓解此问题（例如，您可以根据需要和设置将 NIC 专用于特定 VM），并且根据主机的配置，某些问题会更加明显。例如，如果您的磁盘卷不是最佳的，您将因 I/O 争用而遭受性能下降，并且您的处理器当然必须在 VM 之间分配资源。
对我来说，虚拟化的优势在于以后管理和迁移路径更简单。我认为将硬件从机器中抽象出来要容易得多，这样当购买更好/更大/更快的东西时，你可以将现有的工作设置迁移到该硬件上，减少停机时间和配置麻烦。或者你可以在主机之间平衡机器。在我们的例子中，如果我们遇到问题，仍然有可能，如果我们绝对必须这么做在工作站上将服务器作为虚拟机运行，直到使用临时设置中的虚拟机管理程序为我们的主机服务器提供维修部件，而用户却真正注意到了差异。
快照（在我们的用例中）对于确保更新不会在重启时将我们的系统变成废纸堆非常有用。快照、更新（或更改配置）、重启、测试，如果一切顺利，则删除快照。
那么这样做有意义吗？如果您的网站流量很大，可能没有意义，因为您将面临 I/O 争用。如果您的网站负载较低，并且您认为将来会获得另一台主机，我会认真考虑这样做。我认为虚拟化的抽象有助于更轻松地添加机器并随时间更改配置，但如果您的性能不佳，虚拟化带来的开销可能会有点影响。
答案2
与仅运行一个实例相比，您将承担更多开销。唯一的好处是，如果一个虚拟机出现故障，您将有另一个虚拟机随时可以充当故障转移。当然，如果您拥有更多硬件，您的可靠性会更好。
这样做的一个可能的优点是，以后您可以将虚拟机移动到其他硬件上并订阅更多资源，但只需在增加容量时向负载平衡添加更多服务器即可获得同样的好处。
答案3
我认为是的，因为这也使您能够关闭其中一台虚拟机来进行一些维护，同时另一台虚拟机正常运行并向最终用户提供内容。
答案4
回答这个问题并不那么简单...它取决于成千上万个因素 ;-)
抛开所有的 IO（共享内存、磁盘、网络、CPU）瓶颈，真正精简到最后一部分：
对于您的 Apache，运行“100 个连接上的 5 个实例”可能比运行“500 个连接上的 1 个实例”更有效，但这也可能通过启动多个 Apache 来解决，或者更好地解决在那里整理 Apache 的问题，在前面放一个 nginx 或类似的（更好的连接轮询，仍然让 Apache 在后面运行您的应用程序）；-)...
除此之外：在主机节点上拥有“一个虚拟服务器”确实可以使克隆、备份和故障转移更加简单。
多个虚拟器做同样的事情很可能没有任何好处（或者你可以通过其他方式更好地存档好处）
一个例外是容错，因此在同一硬件上拥有 2 个虚拟机可以帮助防止 SoftwareFails（仅在一个 apache 上出现段错误），但这需要一个合适的设置。
--
一般的：
“活力”是的！备份、克隆、移动
“在同一硬件上多次运行同一图像” 不行（是的，在某些情况下这样做也是有道理的）
绩效：还有更好的事情要做
FaultTolerance：仅限软件故障，没有什么是我做不到的monint