寻求一些意见，看看是否有人已经用他们有信心的解决方案解决了这个问题。
希望设置一个容错的 Web 环境。因此，设置是负载平衡器后面的几个节点。现在，Web 开发人员可以通过 ssh 进入 1 个服务器来编辑代码等。
我正在考虑使用 glusterfs，但将 glusterfs 文件系统作为文档根目录会导致 Web 服务器能够提供的页面数量减少约 20-30%。我预计会出现这种情况，因为我只使用以太网，而不是 infiband 或类似的东西。
所以我考虑使用 glusterfs+inotify。所以我运行了一个 inotify 脚本，它监视 docroot 和 gluster 安装的变化，并对发生更改的文件/目录执行 rsync。这样，apache 可以从本地磁盘提供服务，而不是 gluster，但它的效果是通过集群文件系统提供服务。
我唯一的问题是我需要运行 2 个 inotify 脚本，并且对于我们正在运行的文件数，以添加所有的 inotify 观察器，我将为它们使用大约 700MB 的 RAM。
那么有人有什么建议或指点吗？
谢谢！
编辑
把它想象成一个网络主机。客户端通过 ssh 连接到一台服务器，但他们创建/编辑/删除的文件位于所有其他节点上
反之亦然。如果 Web 服务器创建文件，则它们也需要位于所有节点上。
因此，由于速度太慢，因此会直接抛出 rsync。
答案1
哇哦，我回想起以前的工作，当时使用 GFS 的理由正是您所描述的。当时的情况是：超过 2000 名客户在多个大型云上运行他们的应用程序。
基本上，您无法做您想做的事情。您无法获得能够以接近本地文件系统的速度运行的集群或网络文件系统。让我强调一下：不能。如果你认为你可以，那你就是在自欺欺人。如果其他人说他们可以，那他们就是在撒谎。这是简单的数学问题：磁盘速度 + 控制器 IO + 网络延迟 + 集群性能必须大于磁盘速度 + 控制器 IO。
现在，谈谈您构建它的原因，以及为什么您想要做的事情毫无用处：
- 部署简单：部署到一台机器上并让它自动在任何地方运行并不简单，因为——明白这一点——你部署的并不是一台机器当然，您可能认为只需复制一个代码实例很方便，但在各种情况下，您需要为每个应用服务器做很多事情。在我个人不得不处理的许多情况下，安装到共享文件系统最终使部署过程变得比原来更复杂。对于“如何部署到多台机器”这个问题的正确答案是“自动部署”。
- 可靠性聚类：这对我来说简直就是个笑话。现代硬件非常可靠，而集群技术却非常不可靠，以至于集群（尤其集群文件系统）增加停机时间。我有足够的数据来写一篇关于这个主题的白皮书。现在，有些人会说“我有一个 EMC SAN 运行了四年，没有出现过生产中断”，但他们为这种可靠性付出了多少代价？我从未听说过有人以低于 7 位数的价格（以 TCO 为基础）获得这种可靠性，而且其中还有很多专业知识成本。你问这个问题的事实表明你不拥有专业知识，而且我敢打赌你也不会想投入 7 位数的资金。
- 提高容量的集群：这又回到了我的开场白——任何类型的集群文件系统都比本地文件系统慢。试图从集群或网络文件系统中提取大量性能是徒劳的。它会让你发疯（它确实对我有用）。
现在我已经在屏幕上当了一段时间的消极者，能你会吗？嗯，这基本上就是在个性化层面上帮助你的客户。
您无法构建千篇一律、千篇一律的无限规模托管基础架构。我热爱 GFS 的前雇主曾尝试这样做，但当时却行不通，我相信目前可用的开发和运营技术也无法做到这一点。
相反，花点时间评估客户的需求，帮助他们找到满足其需求的解决方案。您不必对每个客户进行全面分析；在最初几个客户之后，您（希望）会开始看到模式出现，这将指导您找到一系列“标准”解决方案。它变成了“好的，您有需求 F、P 和 Aleph-1，所以您最好使用解决方案 ZZ-23-plural-Z-alpha——这是我们关于部署此解决方案的综合文档，如果您无法自己实施，我们对此解决方案的定制咨询价格处于最低水平”。
至于具体细节，太多了，无法一一列举，但我可以给你一些提示：
- 将代码单独部署到每个应用服务器。
- 如果你真的需要共享动态资产，那么使用 NFS。它非常简单，而且损坏率是最低的。请注意，我说的是共享资产-- 不是代码，不是配置，不是日志，只是客户提供的资产。
- 不过 NFS 并不是永远可扩展的（尽管 NetApp 宣传如此）；在某些时候，你的客户将需要转向其他东西（我举的一个例子就是之前给出)，并且您可以通过良好的文档和其他现成的帮助来协助他们转向更具可扩展性的解决方案。
- 如果你认为这是一个可以一劳永逸的业务，那你就错了。你有商品网站托管（具有所有优点 - 低维护 - 和缺点 - 没有利润 - 这意味着），以及专业网站托管（这是你想要做的），后者维护成本高（但利润也相应高）。
答案2
阅读@Zypher 的评论。反复阅读，直到您理解这些话的智慧，看到光明，并将您的开发人员从生产服务器中赶出并进入适当的沙箱。
您可以借用我的尖头棍。:-)
从这个角度重新定义你的问题，“我如何保持我的网络服务器上的代码一致？”。
答案：木偶（或者厨师),radmind或任何现有的出色的配置/部署系统。
这些工具为您提供了一种更简单的方法来实现您的目标，占用更少的 RAM/CPU，并且可以设置为保证所有节点的一致性。
根据对原始问题的编辑，此部分答案被撤回
我能想到的解决办法只有一个，那就是 SAN（或通过 NFS 提供文件的 NAS 设备）。
我建议采用这种方式的原因是，您需要让每台服务器创建的文件可供所有其他服务器使用。进行大规模 N 向同步将变得笨重而缓慢。集中到 SAN 上将提供更好的性能、良好的冗余性（如果您不吝惜成本，SAN 是非常可靠的），并且能够随着需求的增加而轻松扩展。
但它也有缺点：除非你使用一对镜像、冗余的 SAN 和冗余结构，否则你将引入单点故障。SAN 也不便宜，冗余只会增加更多费用。
请注意，所有这些都不能消除让开发人员远离生产环境的需要，除非你能保证他们在出现问题时不会打电话给你。至少你应该强烈建议他们从你那里租用开发环境（显然利润合理 - 用来支付 SAN 的成本...）