我想以高性能、低延迟的方式在多个 AWS 实例之间共享数据。为所有实例提供只读访问权限（除了一个处理写入的实例）就可以了。关于此用例有两点：
- 连接到卷的节点可能随时出现或消失（启动、停止、终止等）。
- 共享数据包括数千个潜在的小文件，需要列出并检查元数据。
因此我最初尝试了 EFS，但对于需要枚举或修改数百或数千个小文件的操作来说，它相当慢。
所以现在我正在考虑 EBS 多重附加。但是，为了防止数据损坏，AWS 建议仅使用集群文件系统，如 GFS2 或 OCFS。这两者似乎都很复杂，配置起来很繁琐，而且对于节点可能随时来去的集群用例来说也很脆弱。例如，如果节点数从超过 2 个变为正好 2 个，GFS2 要求重新启动所有节点上的集群软件；或者，添加新节点需要登录到当前节点，运行一些命令，并可能将更新的配置文件重新分发到所有其他节点。这似乎真的很不灵活，而且有很多额外的开销。
但是，如果我确定只有 1 个实例会写入磁盘（或者可能每个实例只能写入其自己的子文件夹甚至磁盘分区），我是否可以对该卷使用常规文件系统（如 XFS）并解决问题？或者，即使访问在技术上是只读的，或者写入访问仅限于特定于实例的子文件夹或分区，是否会出现细微的数据损坏问题？
或者是否存在我遗漏的完全不同的解决方案？
答案1
我已经测试过这个（XFS），但它不起作用。您需要一个集群文件系统。最好的选择是使用集群文件系统。请查看其他选项，例如 Veritas Infoscale。
答案2
共享静态卷内容似乎可以很好地与多连接和常规 XFS 配合使用。对卷的热“添加”仅对写入数据的实例可见。确定这一点后，我没有测试热“更新”或“删除”，假设它们也只能由作者看到，但可能会破坏其他实例对该数据的访问。重新启动、重启和/或重新连接的实例确实会看到最新的卷状态。因此，一个实例偶尔写入新数据并触发（例如强制重新启动）其他实例最终看到该数据的用例似乎是该技术可能支持的用例。