glusterfs 用于 WordPress 托管

glusterfs 用于 WordPress 托管

我看到很多教程推荐使用 glusterfs 进行分布式 Web 应用程序托管。这真的是小规模负载平衡的最佳实践吗?

当我们测试时,似乎延迟问题减慢了我们的速度。目前我们有三个节点,每个节点都运行 nginx。它们都是 glusterfs 服务器,文件系统挂载到 /var/www。我们不介意在所有服务器上都有 php 文件的副本,但也许有比 gluster 更好的同步更改的方法?

答案1

这是一个老问题,所以也许你已经解决了这个问题。如果你还没有,以下是我对这个问题的看法。

我们使用 glusterfs 运行大约 40 个网站(大部分是 Wordpress,全部基于 PHP),并且遇到了您提到的延迟问题。我们在 glusterfs 和 PHP-FPM 中都设置了积极缓存,但速度仍然很慢。与使用虚拟机磁盘的性能相比,速度非常慢。

恐怕没有灵丹妙药。不过,我们尝试过或计划尝试一些技术,这些技术可能会有所帮助:

  • 使用 Redis 作为缓存。为此,您必须安装支持它的插件,例如 Wordpress 中的 W3 Total Cache。我在我们的实验室中尝试过它,它很容易配置,但无法测试它对生产系统性能的影响。
  • 使用 Ansible、Saltstack 或类似工具在虚拟机中部署代码 [1],同时保留 glusterfs 仅用于需要共享的目录。对于 Wordpress,这可能是上传目录。此选项需要更多维护和上述软件的知识,但您可以同时获得两全其美的结果:性能(由于 PHP 是从本地磁盘读取的)和数据共享。
  • 您还可以使用 rsync 在虚拟机中部署代码。这有点原始,但有效。不过,我建议使用 Ansible/Saltstack,因为您也可以在之后执行诸如重新加载服务或使缓存无效之类的操作。
  • 使用 CDN,例如 AWS 的 Cloudfront。

我以前用过 EFS,也有同样的问题(可能没那么慢,但也没快多少)。网络文件系统总是容易出现延迟,而 PHP 框架执行的那种操作(比如在多个目录中搜索同一个文件或访问大量小文件)对它们来说很难。在几年前的一次部署中,我们最终选择了 rsync 路线,因为网站直接从 EFS 加载时非常慢。

使用混合部署(代码在虚拟机中,其他文件在共享存储中)时最大的问题是,您必须为开发人员提供一种直接的方式来自行部署代码,否则您将不得不照看每个部署。这是可以做到的,但需要做的工作比为所有内容共享文件系统要多。

抱歉,没有更直接地解决您的问题。希望这能有所帮助。

[1] Ansible 有一个使用 rsync 的模块“synchronize”,这正是您想要使用的。如果您使用“copy”,则需要更长的时间。Saltstack 也是如此:有一个“rsync”状态,它比普通的“file.managed”更快。

相关内容