云托pipe:我们需要它吗?

我们有一个服务器(4GB RAM,两个4核英特尔至强E5420)执行以下任务:

  • 网站的静态内容(目前只是一些CMS,我们计划添加一个caching反向代理)
  • 客户控制面板(基本上是Web界面到数据库)
  • 我们的桌面软件的后端脚本 – 几个执行一些数据库查询/更新的PHP脚本,但每个客户每5分钟就会被点击一次
  • 数据库存储上述两个数据

我们预计在接下来的几周内会有大量(高达数十万)用户涌入。 我的上司担心,我们目前的设置可能无法处理负载,并正在考虑转移到托pipe – 但是,我不相信这会有所帮助。 根据我对云计算的理解,除非我们能够将工作负载分散到多台机器上(除非他们的服务器比我们的function强大得多),否则虚拟化不会有什么帮助。 他们提供了MySQL集群,但后端脚本只是读取/写入一些行中的一些值,而不执行任何计算密集型的SQL查询,所以我不能确定MySQL集群与Apache / PHP开销+ MySQLnetworking延迟。 至于网站,我们也可以把大部分的静态内容转移到CDN上,因为我们有几个video剪辑可以强调我们的带宽。

那么,云托pipe会以任何方式使我们受益?

也许,也许不是。 正如你所怀疑的,除非你可以轻松地将系统工作负载分解成可以通过networking进行通信的离散单元,否则在可伸缩性方面你不会看到任何“云”提供者的好处。 有一些“云”提供商提供了更大的机器(从内存的angular度来看,无论如何 – 我怀疑你会一直得到相当于8个E5420内核),但是你可以得到更多的内存对于您现有的服务器,如果有必要的话。

我会花时间看看系统中的每个组件,评估每个组件的资源使用情况,从而评估将它们移到一个单独的盒子上的“节省”有多less。 然后,看看每个组件(从最耗费资源开始)如何聚集,以便该组件的工作可以拆分到多个机器上(称为“水平可伸缩性”)。 一旦你完成了那些有可能在你预计的负载水平上接近机器的资源价值的地方使用的所有东西,你可以向上级提出一个计划和估计的努力和成本来分配它。

没有一个是“云” – 具体,这只是基本的尽职调查调查如何应付不断增加的用户负荷。 在哪里可以开始使用“云”计算的好处是,当你需要匆匆放大时,你可以点击一个button和谁! 有更多的资源可供您使用。 不过,不要等到负载高峰期才能尝试一下,但是如果您重视正常运行时间,那么可以随时运行每个可伸缩组件中的至less两个,计算出您的扩展触发阈值将会很好提前,监视它们,并尽快产生新的实例。 然后把系统置于巨大的负载下,testing一切如你所愿。

正如Pauska所指出的那样,除了规模之外,虚拟化环境的许多价值是冗余和可用性。 假设你拥有优秀的VMWare员工,你可能需要考虑一个私有的云计算解决scheme,比如Rackspace,或者推出自己的云计算解决scheme。 这需要一些时间,因为womble的优秀post表明要正确。

如果你有一个最后期限快到了,你没有时间研究分解你的应用程序,下面的想法:

  • 尝试将Web服务移动到单独的服务器上,以便MySQL可以拥有整个8核心计算机。 这在MS环境中非常重要,但我相信它在LAMP堆栈中也有价值。
  • 给所有涉及的机器更多的RAM – RAM很便宜。 根据我的经验,研究它所花费的时间将比RAM更多,所以就这样做吧。
  • 考虑反向caching。 在所有这些之前拍摄反向caching可以缓解负载,并且在没有任何复杂情况下提高规模。
  • 阅读womble的优秀回应,并遵循他的build议。