…我所说的这些问题出现的原因是，当你在NFS系统上使用S3兼容的API时，你经常是在和三个不同的供应商碰运气——你有存储设备供应商，有与S3通信的软件供应商，还有编写S3客户端库的Amazon。在我的经验中，这简直是一场兼容性问题的噩梦。Amazon改变了S3客户端库的工作方式，而这种改变没有与存储供应商的实现进行测试，结果事情就无法工作了。但你第一个电话要打给应用供应商，而他们完全不熟悉你的存储设备。:-(
源讨论我只需要简单的S3原帖 127 条评论 · 导入时统计我个人建议，最简单的S3可能是直接使用NFS。你可以用RAID实现复制。 S3对用户来说很简单，但对运维人员来说并不简单。要复制类似S3的东西，你需要管理很多部分并做出很多决策。设计空间非常大： 复制：RAID、分布式副本、分布式纠删码... 协调：集中式、带备份的集中式、分布式、客户端逻辑... 如何处理大文件：不，客户端会将它们连接起来，协调节点会将它们连接起来... 网络会是怎样的：本地网络、广域网、混合网络。是慢还是快？ 存储的性质：全天候连接还是偶尔连接。 如何处理网络分区，选择CAP的哪一边... 仅举一个例子：网络拓扑。在你自己的数据中心里，你可能认为每条连接的成本相同。在AWS中，你可能希望连接保持在同一个可用区，使用某些IP地址进行特定的源-目标连接。…
完整原文把你的经验，加入这段讨论。
> 但大多数 NFS 系统中它并不足够好。 NFS 只是一个接口。归根结底，它是在文件系统之上的。实际上有可能，有时也会实践地复制由 NFS 提供服务的底层存储。正如你所期望的，有几种方法可以做到这一点，从简单的到真正“高可用性”的都有。
完整原文你为什么要在 NFS 之上使用 S3？ 我的意思是，你可以这么做，这会简化一些锁定机制。 但如果你是在管理的网络内为应用程序进行文件共享，那就直接使用 NFS，之后再考虑锁定的问题。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。