复制共享文件系统

Question

我正在研究在 AWS (EC2) 基础设施上设置一个共享文件系统/文件服务器，该文件系统/文件服务器提供复制和相当轻松的故障转移功能。该文件系统可能会托管数百万个大小为几兆的文件。这些文件将从多个客户端虚拟机访问（读/写）。如果主文件服务器发生故障，我希望客户端能够故障转移到副本文件服务器而不会丢失任何文件（即我希望复制是实时的）。我查看了几个选项：

• 将 S3 与 s3fs 一起使用。我担心在对数千个文件执行操作时（例如复制/移动文件时），每个请求的延迟都会有问题。我还听到一些报告让我质疑 s3fs 的稳定性——不确定现在是否仍然如此。
• 在 EC2 实例上设置 NFS 服务器，使用 drbd 在两个实例之间复制块。缺点：
  1. 我过去曾遇到过 drbd 的可靠性问题，特别是在高延迟链路上
  2. 如果主 NFS 服务器发生故障，它将关闭客户端，需要系统管理员干预和/或重新启动才能让它们重新连接到辅助服务器。没有自动故障转移。

还有更好的解决方案吗？

Answer 1

只是一些更新的信息。如果您和我一样，并且非常非常长时间以来一直想要此功能，请使用 Amazon Elastic File System (EFS)。它是跨多个可用区域复制的 NFS 挂载。

（很抱歉提出这个问题，但这个答案的谷歌排名足够高，可能有一些人正在寻找这个解决方案。）

Answer 2

虽然这并不简单，但是可以在 Amazon EC2 中设置 NFS 集群，使用 DRBD 进行同步复制，并使用 Pacemaker + Corosync 自动执行 NFS 服务的故障转移并进行节点之间的导出（不中断客户端访问）。

如果您计划同步复制（“实时”），则需要两个 EC2 实例位于同一区域以限制它们之间的延迟；否则网络延迟将转化为磁盘延迟。

此外，无法轻松地在 Amazon EC2 实例上分配/取消分配 IP 地址；您需要使用他们的 API（或使用他们的 web-gui）来重新分配 IP 地址。需要移动 IP 地址，以便客户端将使用浮动 IP 地址连接到活动节点。需要对“IPaddr2”Pacemaker 资源代理进行一些修改才能使其正常工作；这是一个 bash 脚本。

Answer 3

考虑到设置复制 NFS 服务器的复杂性，我们选择使用 S3。s3fs-fuze很糟糕（对ls包含 1,000 多个文件的目录执行此操作需要将近一分钟，因为它需要查询每个文件的元数据，而缓存似乎没有帮助）。然而，我尝试了里约热内卢，它为我提供了目录操作的即时响应，总体感觉非常快。

我仍计划研究一些其他选项（3QL语言和YAS3FS) 但到目前为止，这些选择看起来很有希望。