Php + Apache + Mysql + [任何内容] 服务器集群 - 陷阱、提示和效率路线图

Php + Apache + Mysql + [任何内容] 服务器集群 - 陷阱、提示和效率路线图

我的公司需要设置集群服务器(是这么叫的吗?)。我们的主机是在国外租用的,因此实际硬件的使用有限,但我们拥有完全的自由,不受财务资源的限制(当然,前提是我们避免过度使用 - 如果 3 台服务器就能处理一切,就不需要 300 台服务器)。

我们是一家国际在线出版商,提供免费的在线可读书籍。这意味着我们拥有大量静态内容 - 主要是许多 GB 的 flash 文档。我们最近将服务器操作系统升级到 CentOS x64,并将服务器软件从 Apache 更改为 Nginx(用于静态内容)+Apache。然而,出现了一些问题,我们遇到了一些意外停机,这给我们造成了相当严重的损失,即使只有几个小时。

我对集群设置的想法如下:
- 服务器 1:我们当前的 MySQL 数据库。
- 服务器 2、服务器 3、服务器 4:我们的应用程序,即 Apache 上的 PHP 代码
- 服务器 4:仅静态内容(5kb 到 3mb 的图像、5mb 到 100MB 的 PDF、200kb 到 20MB 的 flash 文件等),由 Cherokee 提供支持

我相信这种设置可以帮助我们避免在三台应用服务器中的一台出现故障时出现停机,此外还可以在三台服务器之间分担负载,而不像现在所有内容(静态+数据库+应用程序)都在一台机器上。

我希望各位老手能提供一些关于服务器负载共享的有用链接、有关此问题以及我上面建议的设置的提示和技巧。作为一名 PHP 开发人员,我对 Apache 的经验有限,因此,如果有人能提供任何关于他们的设置或使用不同硬件/软件的经验的宝贵见解,我将不胜感激。

另外,正确的术语是什么?云?集群?还有其他我应该知道的术语吗?请温柔一点,我才刚刚开始涉足服务器世界。

谢谢

编辑:新计划如下,请告诉我您的想法:

应用程序集群

  • 3 台运行 Nginx(或 Cherokee)和 Apache(带 PHP)的服务器。Nginx 将处理同一台服务器上的静态内容请求(CSS、JS、缩略图、精灵、图像)
  • 由于我们目前有 2 个流量相当大的网站(一个数据库更新量很大,另一个静态内容服务量很大),所以我们考虑将两个网站都放在这台应用服务器上。
  • 这两个应用程序将有两个负载均衡器,用于在三台服务器之间分配流量。这些服务器将是完全相同的克隆,以后可以轻松扩展。

数据库集群

  • 两台运行 MySQL 的服务器,克隆。负载平衡器。备份将自行完成,因为两台服务器同时死机的可能性极小。App 集群上的两个应用程序都将使用此集群 - 一个将执行平均读取负载,另一个将执行高读写负载。

静态集群

  • 两台服务器专门用于存储静态内容,基本上只是存储数千个 PDF、Zip 和 Flash 文件。没有备份,无法高效运行。服务器是彼此的备份。此静态集群将为 App 集群上的两个应用程序提供更大的静态内容。

这是现实的吗?如果有的话,你会反对什么?你会补充什么?

答案1

这些年来我学到的一些常识:

  • 这个问题有关性能、扩展和高可用性站点主题的优秀书籍列表。
  • “集群”是正确的术语。您正在使用多台机器为一个站点提供服务,以期提高可用性。您还可以使用集群来指代设置的特定部分:例如,服务器 2+3+4 就是您的应用程序集群。
  • 您是否只在应用程序级别上具有冗余性?MySQL 和静态内容呢?特别是由于您的静态内容相对较大,因此请考虑在需要时可以为 N 个并发用户提供多少带宽。如果 MySQL 服务器发生故障或服务器 #4 的磁盘损坏,会发生什么情况?
  • 如果您要从一台机器上移动所有东西,请从小处着手,除非您不介意花费超过所需的费用。例如,我发现在类似情况下从 1 台服务器移动到 3 台服务器时,性能提升比预期的要大。拆分成多台服务器后,您可能会发现新的瓶颈位于不同的区域。
  • 在规划扩展时,不要完全忘记未来可能出现的扩展。现在进行一些前瞻性思考和设计可以节省您未来的时间。例如,您现在有一台静态服务器,但一年内需要多台,或者需要将多台服务器分散在不同地理位置。
  • 考虑创建脚本来帮助设置特定类型的服务器...手动操作会变得很麻烦,而且你总会忘记一个步骤。我最近这样做了,真希望我从一开始就这样做。运行一个可以在几分钟内自动完成 50 个安装步骤的脚本从长远来看可以节省大量时间。
  • 随着服务器数量的增加,出现某种硬件故障的可能性也会随之增加。为此做好计划,并玩假设游戏:如果服务器 X 上的硬盘出现故障会怎样?我们会失去什么?网站会停用多长时间?修复需要多长时间?等等...

答案2

我认为 uesp 很好地涵盖了一般内容。要决定如何处理您的案件,您需要坐下来思考以下几点:

  1. 每个组件的当前负载是多少?预计未来负载是多少?
  2. 您想要处理的故障场景有哪些?上次故障的原因是什么?

第一个问题告诉您为了运行网站在每个级别所需的最少服务器数量。

第二个问题告诉你,为了确保你的网站持续运行,你实际上需要多少硬件。当你列出故障模式时,你会发现你需要考虑的不仅仅是服务器:防火墙、上游互联网连接、发电机、物理位置等等。你还需要解决一些问题,比如让管理员随时待命处理凌晨 3 点服务器崩溃的问题,以及需要监控来唤醒管理员并让他们知道有东西崩溃了。如果你之前的故障是由于配置或编程错误造成的,请考虑在开发和生产之间建立一个临时环境,以便在程序员完成更改后和更改生效前进行测试。

相关内容