在我目前的工作中，我遇到这种情况：每次我们安装一些新软件时（十分之九的应用程序是用 PHP 编写的），它都安装在自己的服务器上，由 Debian OS、Apache 服务器和 PostgreSQL 组成数据库。由于这个策略，我们目前大约有 10 台服务器（注意：当我说服务器时，我说的是“没有屏幕的普通 PC”，而不是“我们在这台服务器上花了足够养活一个小国家”），其中大部分是共享的相同的软件要求。
这种情况让我思考：我们不应该创建一个集群，而不是为每个应用程序添加单独的服务器吗？我可以证明，虽然有些服务器需要更好的硬件（主要是 RAM），但有些服务器已经闲置了不少于三周，所以有了集群，我们可以更好地利用这些资源。同时，我不确定结果是否值得拼凑和维护上述集群所需的时间和精力（我一直想使用“上述”这个词）。
在所有这些介绍之后，主要问题是：在这种情况下，您会建议创建一个集群吗？或者你会保持服务器现在的样子吗？
集群将增加冗余并提高可扩展性。但是，它引入了复杂性。您将需要某种形式的负载平衡（循环 DNS 不适合）。您还需要处理服务器之间的会话共享。您的应用程序可能会将其写入数据库，如果有点慢，它会工作，但许多应用程序并非设计为在集群环境中工作。您可以使用粘性会话负载平衡，或者自己更改应用程序以处理集群范围的会话。
你可以看看虚拟化——用一个或两个高级服务器替换你的众多盒子，并使用 VMWare、Virtual Server 等为每个虚拟机分配适当的资源。
其他人的意见各有千秋。我会争辩说，如果您的所有（或大多数）应用程序都是 LAMP 堆栈式的，我会说集群数据库部分（MySQL/PostGreSQL/等）无论是主动-主动/故障转移，但您想要。
在应用程序性能方面，您确实需要更多指标来证明任何类型的集群的案例。要增加复杂性而不考虑实际测量，更不用说可能的可管理性噩梦，请确保您有一些证据。
从逻辑的角度来看，如果您只是启动新站点/应用程序，并且数据库始终是每个应用程序的一部分，我认为从管理的角度来看，将数据库集群在一起将是有益的，最终将允许您虚拟化网络服务器（降低未来成本）。保持两个层独立将通过以下方式帮助您：
数据高于一切，是 IT 中最重要的事情。丢失信息；失去客户导致亏损。如果正确完成（并经过积极测试），集群可以提高性能/可用性/冗余/可管理性。
虚拟化您的网络服务器可以提高可用性和可管理性。如果虚拟服务器出现故障，网络服务器可以迁移到另一个可行的虚拟主机，并且数据库集群可以继续运行。此外，为每个需要安装的新 Web 应用程序购买的费用更少。将更多 RAM 添加到虚拟主机而不是购买全新的服务器会不会便宜很多？
所以直接回答你的问题..
是的，在某种程度上。除非您托管一个大型 Web 应用程序并且性能是一个主要问题（例如 .. facebook？），否则集群 Web 服务器并可能包括一些缓存服务器（memcached）以提高性能肯定会有所帮助。但在你的情况下，听起来你有很多小或简单的网站/网络应用程序，每个应用程序都有数据库。如果负载/性能在这里不是问题，虚拟化将有助于提高正常运行时间/可用性。
从正常运行时间/冗余/管理的角度来看，我肯定会将数据库服务器集群在一组可靠的服务器中。确保数据安全，并降低停机/灾难的几率。这比网站重要得多，因为网站只是一堆由 apache、nginx 提供的文件（选择你的网络服务器）。就存储而言（通常），对站点进行备份并不多，并且恢复站点应该相当简单明了。或者您可以发挥真正的创造力，当您的所有站点都在虚拟机中运行时，备份虚拟机以在网络服务器上进行任何更改，备份它们，如果运行/生产映像损坏或难以修复，只需从存档中复制好的副本. 数据库集群应该仍在运行，一旦新的虚拟机启动并运行，它应该指向数据库集群。只是一个想法。我敢打赌其他人有更好的想法/技术，但无论如何。这只是一个想法。
如果您急于得出需要更好硬件的结论，那么您最好先弄清楚这一点，然后再围绕坏零件构建集群。如果您在一致的基础上遇到大量类似的问题，那么集群将无法真正解决任何问题。是的，集群会根据设计的问题进行调整，但首先要解决根本问题。为什么要建立在糟糕的基础上？但是，如果您的观点是没有足够的硬件，那就是另一个问题，您可能无法控制。我会考虑和预算重的人闲聊。
除了你冒泡的词汇之外，很高兴看到你至少意识到在你选择走集群路线之前所面临的任务的重要性。我要大胆尝试并说我认为您正在寻找“继续”使用集群的理由，虽然这里的许多人可能同意您的观点，但只有您知道您的技术优势和劣势。10 个网络服务器还不错，但不久之后，当您托管越来越多的网络服务器时，在管理服务器、备份、处理正常运行时间/可用性和冗余之间，您将不得不做一些事情。如果您现在不做某事，那可能很好，但我会开始调查您未来约会的所有选择。谁知道？六个月后你
根据我在进行任何此类冒险之前的经验，进行研究，调查您当前的资产，制定战略/计划并填补该计划中的所有空白。事实上，如果您开始研究集群等，这里有一个很棒的文档：http ://www.scribd.com/doc/4069180/Caching-Performance-Lessons-from-Facebook 。诚然，计划中总会出现问题，您需要越多的时间来审查和修改您的计划，您就会发现可能的陷阱。
如果您没有看到任何单个服务器上的高负载并且您已经制定了管理这些服务器中的每一个的程序，我认为您最好的选择是查看虚拟化（我一直在问很多关于它和 ESXi 的试验......到目前为止很好！）
这样，您就可以保留维护程序、简化硬件成本、简化一些备份（尽管您需要大量存储...在服务器上和用于备份）琐事，并且更容易推出新的或实验性设置从长远来看。
听起来您可能可以将投入服务器和电力的资金投入到使用这些服务器购买几台用于 VMWare 的服务器，并支持它们的冗余和管理工具，如 VMotion。
将所有站点捆绑在一起意味着增加了配置的复杂性，并且可能会增加 Web 服务器中的一些相互依赖性。可以做到，但它可能会使升级或更改过程中更容易破坏；虚拟化它会增加一个层，这会稍微减慢速度并给您带来单点故障（如果您不投资两台以上的服务器和 VMWare 的冗余解决方案），但您仍然可以通过单独的机器进行管理和配置来获得很多收益.
测试配置应该不会太难，因为您可以免费获得 ESXi，只要您在兼容性列表中有一个服务器可以安装它，然后运行转换器（现在可用于 Linux 和 Windows，免费）来创建然后虚拟机关闭物理服务器并重新配置虚拟机的网络设置以接管物理服务器的角色。安装一些监控软件（比如 Veeam，他们有一些免费的工具也可以满足小型企业的需求，注册有点麻烦），然后开始查看您对虚拟服务器主机施加了什么样的负载。你可能会感到惊讶。
如果您在所有服务器上的工作基本上是相同的，您可以在具有 apache 虚拟主机和多个数据库的单个服务器上提供相同的服务。
另一种解决方案可能是使用 OpenVZ 设置服务器并为每个应用程序设置 VPS