文件系统冗余+速度

寻找一些意见，如果有人用他们自信的解决scheme来解决这个问题。

希望build立一个容错的networking环境。所以设置是负载平衡器后面的几个节点。现在web开发人员可以ssh到1服务器编辑代码等。

我正在考虑glusterfs，但是把一个glusterfs文件系统作为doc根导致web服务器可以服务的页面减less20-30％左右。我期待这一点，因为我只是通过以太网，而不是infiband或这样的。

所以我正在考虑使用glusterfs + inotify。所以我有一个inotify脚本运行，监视docroot和gluster挂载进行更改，并对该文件/目录进行rsync更改。这种方式Apache可以从本地磁盘服务，而不是gluster，但它给出的效果是通过一个集群文件系统。

我唯一的问题是，我需要运行2个inotify脚本和我们正在运行的filecount来添加所有使用大约700meg内存的inotify监视器。

所以任何人有任何build议或指针？

谢谢！

编辑

把它想象成一个虚拟主机。客户端ssh到1服务器，但他们创build/编辑/删除的文件在所有其他节点上

相反也需要是真实的。如果web服务器创build文件，他们也需要在所有的节点上。

所以它会抛出一个直接的rsync，因为它太慢了。

哦，哇，我正在回想一下过去的工作，那里的GFS被用来描述你的确切理由。情景：超过2000个客户在多个大型云上运行应用程序。

基本上，你不能做你认为你想做的事情。你不能得到一个集群或networking文件系统，将在任何地方接近本地文件系统的速度工作。让我强调一下：不行。如果你认为你可以的话，那么你正在欺骗你自己。如果有人说他们可以，他们在说谎。这是简单的math：磁盘速度+控制器IO +networking延迟+集群fu 必须大于磁盘速度+控制器IO。

现在，下面是你可能正在build设的原因，以及为什么你想要做的是无用的：

部署简单 ：部署到一台机器并不是一件简单的事情，它可以自动运行到任何地方，因为 – 得到这个 – 它不是一台你要部署的机器 。当然，您可能认为只需复制代码的一个实例是很方便的，但是在各种情况下，您需要执行大量的每个应用程序服务器。在很多情况下，我个人不得不处理，安装到共享文件系统上，最终导致部署过程比以前复杂。 “如何部署到多台机器”这个问题的正确答案是“自动部署”。
可靠性聚类 ：这一个为我的一个笑话。现代硬件如此可靠，集群技术如此不可靠，集群（ 特别是集群文件系统）增加了停机时间。我有足够的数据为这个话题的白皮书。现在，有些人会说：“我已经有一个运行了四年的EMC SAN，没有生产中断”，但是他们为这个可靠性付出了多less代价？我从来没有听说过任何人获得less于7位数字的可靠性（以TCO为基础），而且在那里也有大量的专业成本。事实上，你问这个问题说你没有这方面的专业知识，我敢打赌，你也不打算把7位数字降低。
容量集群 ：这回到我的开头语句 – 任何types的集群文件系统比本地文件系统慢。试图从集群或networking文件系统中提取大量的性能是一个失败的原因。这会让你发疯（这对我来说确实是个诡计）。

现在我已经是一个负面的屏幕，所以你可以做什么？那么，基本上就是帮助你的客户达到个性化水平。

你无法build立一个万能的万能托pipe基础设施。这就是我的GFS爱好的过去的雇主试图做的，口香糖没有工作，我相信目前可用的开发和操作技术无法完成。

相反，花点时间来评估客户的需求，并帮助他们find满足其要求的解决scheme。您不一定要对每个客户进行全面的分析，在最初的几个之后，你会（希望）开始看到模式的出现，这将引导你走向一系列“标准”解决scheme。它变成了“OK，你有F，P和Aleph-1的要求，所以你最好用解决schemeZZ-23-复数Z-alpha – 这里是我们全面的文档部署这个解决scheme，如果你不能自己实施这个解决scheme的定制咨询价格，我们的价格是在底部“。

就具体情况而言，列表太多了，但我会给你一些提示：

将代码分别部署到每个应用程序服务器。
如果您确实需要共享dynamic资产，请使用NFS。这很愚蠢，而且破损率也是最低的。请注意，我说共享资产 – 不是代码，不是configuration，不是日志，只是客户提供的资产。
虽然NFS并没有永远的规模（NetApp的宣传尽pipe）; 在某些时候，您的客户需要转向其他方面（我之前给出的一个例子），您可以帮助他们转向更具扩展性的解决scheme，并提供良好的文档和其他现成的协助。
如果你认为这可能是一个失败的事业，那么你错了。你有商品网站托pipe（所有的优点 – 低维护 – 坏点 – 没有利润 – 这意味着），和专门的networking托pipe（这是你正在做的），而后者是高维护（但相应的高利润率）。

阅读@ Zypher的评论。一遍又一遍地阅读，直到你理解这些单词的智慧，看到灯光，把你的开发人员从你的生产服务器中赶出来，放到合适的沙箱里。
你可以借我尖尖的棍子 🙂

~~从这个angular度重新考虑你的问题，“我如何让我的networking服务器上的代码保持一致？”。~~
~~答：傀儡（或厨师）， radmind ，或任何其他许多美妙的configuration/部署系统。~~

这些工具为您提供了一个更简单的方法来实现您的目标，占用更less的RAM / CPU，并且可以设置为保证所有节点的一致性。
这部分答案基于对原始问题的编辑撤回

实际上我只能想到一种解决scheme，那就是SAN（或通过NFS提供文件的NAS设备）。
我build议这条路线的原因是，你需要将每个服务器创build的文件提供给其他所有的服务器。做大规模的N路同步将变得笨重和缓慢。集中到SAN将会提供更好的性能和更好的冗余（如果你不便宜，SAN是非常防弹的），并且可以随着需求的增加轻松扩展。

这不是没有缺点：除非你做一对镜像，冗余光纤冗余networkingSAN，否则将引入单点故障。 SAN也不便宜，冗余只会增加更多的开销。

请注意，这些都不会使开发人员不能在生产环境中工作，除非您保证他们在破产时不会再打电话给您。至less你应该强烈build议他们从你那里租一个开发环境（显然是合理的利润 – 用来支付SAN的成本）