s3fs 将 Amazon S3 存储桶挂载为本地目录的稳定性如何[关闭]

Question

s3fs 在 linux 中将 Amazon S3 存储桶挂载为本地目录的稳定性如何？对于高需求的生产环境是否推荐/稳定？

有没有更好/类似的解决方案？

更新：使用 EBS 并通过 NFS 将其挂载到所有其他 AMI 会更好吗？

Answer 1

There's a good article on s3fs here，看完后我求助于 EBS 分享。

它强调了使用 s3fs 时的一些重要注意事项，即与 S3 的固有限制有关：

• 文件不能超过 5GB
• 您无法部分更新文件，因此更改单个字节将重新上传整个文件。
• 对许多小文件的操作非常高效（毕竟每个都是一个单独的 S3 对象），但大文件的效率非常低
• 虽然 S3 支持部分/分块下载，但 s3fs 没有利用这一点，因此如果您只想读取 1GB 文件的一个字节，则必须下载整个 GB。

因此，s3fs 是否可行取决于您存储的内容。如果您要存储照片，您想要写入整个文件或读取整个文件永远不会增量更改文件，那么它很好，尽管有人可能会问，如果您正在这样做，那么为什么不使用 S3 API 直接？

如果您谈论的是应用程序数据（例如数据库文件、日志文件），您希望在其中进行小的增量更改，那么绝对不能 - S3 只是不能以这种方式工作，您不能增量更改文件.

上面提到的文章确实谈到了一个类似的应用程序——s3backer——它通过在 S3 上实现一个虚拟文件系统来解决性能问题。这解决了性能问题，但它本身也有一些问题：

• 由于写入延迟导致数据损坏的高风险
• 太小的块大小（例如，4K 默认值）可能会显着增加 额外费用（例如，50GB 和 4K 块的存储空间需要 130 美元）
• 过大的块大小会增加大量的数据传输和存储 费用。
• 内存使用量可能过高：默认情况下它缓存 1000 个块。
  使用默认的 4K 块大小不是问题，但大多数用户
  可能会想要增加块大小。

我求助于从 EC2 实例共享的 EBS Mounted Drived。但是您应该知道，尽管性能最高的选项有一个大问题 EBS 挂载的 NFS 共享有其自身的问题 - 单点故障；如果共享 EBS 卷的机器出现故障，那么您将失去访问该共享的所有机器的访问权限。

这是我能够承受的风险，也是我最终选择的选项。我希望这会有所帮助。

Answer 2

这是一个老问题，所以我将分享我在过去一年中使用 S3FS 的经验。

最初，它有许多错误和内存泄漏（我有一个 cron-job 每 2 小时重新启动一次），但在最新版本 1.73 中它非常稳定。

S3FS 的最大优点是您可以少操心一件事情并免费获得一些性能优势。

您的大部分 S3 请求将是 PUT (~5%) 和 GET (~95%)。如果您不需要任何后期处理（例如缩略图生成）。如果您不需要任何后处理，则不应首先访问您的 Web 服务器并直接上传到 S3（使用 CORS）。

假设您正在访问服务器可能意味着您需要对图像进行一些后期处理。使用 S3 API，您将上传到服务器，然后上传到 S3。如果用户想要裁剪，你需要从 S3 重新下载，然后重新上传到服务器，裁剪然后上传到 S3。启用 S3FS 和本地缓存后，此编排会为您处理并保存从 S3 下载的文件。

在缓存方面，如果您要缓存到 EC2 上的临时驱动器，您将获得随之而来的性能优势，并且可以清除缓存而无需担心任何事情。除非您的磁盘空间用完，否则您应该没有理由清除缓存。这使得搜索和过滤等遍历操作变得更加容易。

我希望它与 S3 完全同步（RSync 风格）。这将使其成为 DropBox 或 Google Drive for S3 的企业版，但无需应对随之而来的配额和费用。