linux - 同时处理多个文件——复制文件还是通过 NFS 读取？

Question

我需要同时处理大量文件(数千个不同的文件，每个文件的平均大小为 2MB)。

所有信息都存储在一个(1.5TB)网络硬盘上，将由大约 30 台不同的机器处理。为了提高效率，每台机器将读取(和处理)不同的文件(有数千个文件需要处理)。

每台机器——在从 1.5TB 硬盘上的“incoming”文件夹中读取文件后——将处理信息并准备好将处理后的信息输出回 1.5TB 上的“processed”文件夹结核病驱动器。每个文件的处理信息与输入文件的平均大小大致相同(每个文件约 2MB)。

什么是更好的做法:

(1)对于每台加工机M，将所有要被M加工的文件复制到其本地硬盘中，然后在本地读取并加工这些文件机器M。

(2) 不是将文件复制到每台机器，而是每台机器直接访问“传入”文件夹(使用 NFS)，并从那里读取文件，然后在本地处理它们。

哪个想法更好？当一个人做这样的事情时，有什么“做”和“不做”吗？

我很好奇让 30 台左右的机器同时读取(或写入)信息到同一个网络驱动器是否有问题？

(注意:现有文件只会被读取，不会被追加/写入；新文件将从头开始创建，因此不存在多次访问同一文件的问题...)。是否存在任何我应该预料到的瓶颈？

(如果重要的话，我在所有机器上都使用 Linux、Ubuntu 10.04 LTS)

Answer 1

我肯定会做 #2 - 我会按如下方式做:

在您的主服务器上使用所有文件运行 Apache。 (或者其他一些 HTTP 服务器，如果你真的想要的话)。我这样做有几个原因:

1. HTTP 基本上是纯 TCP(带有一些 header )。一旦请求被发送 - 这是一个非常“单向”的协议(protocol)。低开销，不健谈。高性能和高效率 - 低开销。

2. 如果您(无论出于何种原因)决定需要移动或扩展它(例如，使用云服务)，HTTP 将是一种比 NFS 更好的在开放互联网上移动数据的方式.您可以使用 SSL(如果需要)。您可以通过防火墙(如果需要)。等等……等等……等等……

3. 根据文件的访问模式，假设需要读取整个文件 - 只需执行一个网络操作会更容易/更快 - 并将整个文件拉入一口气——而不是每次读取文件的一小部分时都不断地通过网络请求 I/O。

4. 分发和运行执行所有这些操作的应用程序可能很容易 - 并且不依赖于网络安装的存在 - 特定文件路径等。如果您有文件的 URL - 客户端可以完成它的工作。它不需要建立挂载、硬目录，也不需要成为根用户即可设置此类挂载。

5. 如果您有 NFS 连接问题 - 当您尝试访问挂载并且它们挂起时，整个系统会变得很糟糕。使用在用户空间上下文中运行的 HTTP - 您只会收到超时错误 - 您的应用程序可以采取它选择的任何操作(例如页面您 - 记录错误等)。