单个服务器或群集

一个集群可以增加冗余并提高可扩展性。 但是，它引入了复杂性。 您将需要某种forms的负载平衡（并且循环DNS不适合）。 您还需要处理服务器之间的会话共享。 您的应用程序可能会将其写入数据库，如果速度有点慢，这可能会起作用，但许多应用程序并不适用于集群环境。 您可以使用粘性会话负载平衡，或自己修改应用程序来处理群集范围的会话。

你可以看看虚拟化 – 用一两台高端服务器replace你的众多机箱，并使用VMWare，虚拟服务器等来为每台虚拟机分配适当的资源。

其他人的看法都有自己的优点。 我会争辩说，如果你的应用程序的所有（或大部分）都是LAMP stack-ish，那么我会说数据库部分（MySQL / PostGreSQL /等）的集群无论是主动 – 主动/故障切换，但是你想要的。

就应用程序性能而言，您确实需要更多的度量来certificate任何种类的聚类。 为了增加复杂性而不考虑实际测量结果，更不用说可能的可pipe理性噩梦，确保你有一些证据。

从逻辑的angular度来看，如果您只是启动新的网站/应用程序，而数据库始终是每个应用程序的一部分，那么我认为将数据库集中在一起从pipe理的angular度来看是有益的，并最终允许您虚拟化Web服务器（降低未来成本）。 保持两个层的独立性将以下列方式帮助您：

• 数据最重要的是IT。 丢失信息; 失去了导致亏损的客户。 一个集群可以提高性能/可用性/冗余性/可pipe理性，如果正确完成（并大力testing）。

• 虚拟化您的Web服务器可以提供可用性和可pipe理性。 如果虚拟服务器出现故障，networking服务器可能会迁移到另一个可用的虚拟主机，并且数据库集群可能会一直嗡嗡作响。 另外，为每个需要安装的新Web应用程序购买更less。 向虚拟主机添加更多内存而不是购买全新的服务器会不会便宜很多？

所以要直接回答你的问题。

这种情况使我想：我们不应该创build一个集群，而不是为每个应用程序添加单个服务器？

是的，在一定程度上。 除非你正在托pipe一个大的web应用程序，性能是一个主要问题（如.. facebook？），集群的web服务器，可能包括一些caching服务器（memcached）性能肯定会有所帮助。 但在你的情况，这听起来像你有很多小的或简单的网站/每个应用程序与数据库的Web应用程序。 如果负载/性能不成问题，虚拟化将有助于正常运行时间/可用性。

从正常运行时间/冗余/pipe理的angular度来看，我肯定会将数据库服务器集中在一组可靠的服务器中。 保持数据安全，并降低停机/缺失的几率。 这比网站重要得多，因为网站只是一堆使用Apache，nginx（select你的networking服务器）的文件。 拥有一个网站的备份在存储（通常）方面并不多，恢复一个网站应该相当简单和直接。 或者，您可以变得非常有创意，当所有站点都在虚拟机中运行时，备份虚拟机以便在networking服务器上进行任何更改，备份它们，如果运行/生产映像损坏或难以解决，只需从归档。 数据库集群应该仍在运行，一旦新的虚拟机启动并运行，它应该指向数据库集群。 只是一个想法。 我敢打赌，其他人有更好的想法/技术，但无论如何。 这只是一个想法。

我可以certificate，虽然有些服务器需要更好的硬件（主要是内存），但其他一些服务器已经闲置不less于三周，所以对于一个集群我们可以更好地使用这些资源。

如果你想得出结论，你需要更好的硬件，那么最好在坏的部件周围build立一个集群之前先弄清楚。 如果你遇到了许多类似的问题，那么一个集群就不会真正解决任何问题。 是的，群集将适应它所devise的问题，但首先会遇到根本问题。 为什么build立在一个糟糕的基础？ 但是，如果你的观点没有足够的硬件，这是一个不同的问题，可以从你手中。 我会仔细研究那些预算严重的人 。

同时，我不确定结果是否值得花时间和精力来组合和维护上述集群（我一直想用“上述”一词）。

除了冒泡的词汇之外，看到你至less已经意识到了你select走集群路线之前的任务重要性。 我会采取狂野的行为，并且说我认为你正在寻找“去”集群的理由，虽然这里很多人可能会同意你的意见，但只有你知道你的技术优势和弱点。 10个networking服务器并不算太坏，但是当你获得越来越多的networking服务器托pipe时，在pipe理服务器，支持服务器，处理正常运行时间/可用性和冗余性等问题之前，你需要做很多事情。 如果你现在不做点什么，那可能没问题，但我会在将来开始调查你所有的select。 谁知道？ 从现在起六个月，您将添加10个以上的应用程序，并且您的观点发生巨大变化。

根据我之前做这种冒险的经验，做研究，调查你现有的资产，制定一个战略/计划，并填写该计划的所有空白。 事实上，这是一个很好的文档，你应该开始研究集群等： http : //www.scribd.com/doc/4069180/Caching-Performance-Lessons-from-Facebook 。 当然，在一个计划中总是出错，你有更多的时间审查你的计划和修改你会发现可能的陷阱。

如果你没有看到任何单个服务器上的高负载，并且你已经有了pipe理这些服务器的程序，那么我认为你最好的办法就是看看虚拟化（我一直在问很多关于这个问题的问题）它和ESXi试验…到目前为止！）

这样，您可以保持程序的维护，简化硬件成本，简化一些备份（尽pipe在服务器和备份上需要大量的存储）杂务，并且可以更容易地推出新的或实验设置从长远来看。

听起来好像你可能把你投入服务器和电力的资金用来使用这些服务器来为VMWare购买几台服务器，并支持他们的冗余和pipe理工具，比如VMotion。

将所有网站绑定到一个网站意味着增加configuration的复杂性，并可能在您的Web服务器中存在一些相互依存关系。 它可以完成，但是在升级或更改过程中可能会使事情更容易中断; 虚拟化会增加一层让问题变得缓慢的一层，并为您提供单点故障（如果您不投资于两台服务器和VMWare的冗余解决scheme），但您仍然可以通过单独的pipe理和configuration机器获得很多收益。

testingconfiguration应该不会太困难，因为只要在要安装ESXi的兼容性列表上有一个服务器，就可以免费获得ESXi，然后运行转换器（现在可以免费用于Linux和Windows）来创build虚拟机会closures物理服务器并重新configuration虚拟机的networking设置以接pipe物理服务器的angular色。 安装一些监控软件（比如Veeam，他们有一些免费的工具，可以满足小型企业的需求，注册也是一种痛苦），并开始了解你在虚拟服务器主机上安装的是什么样的负载。 你可能会感到惊讶。

如果你在所有的服务器上工作基本上是一样的，你可以使用apache虚拟主机和多个数据库在一台服务器上提供相同的服务。

另一种解决scheme可能是使用OpenVZ设置服务器，并为每个应用程序设置一个VPS