复制共享文件系统

我正在研究在AWS(EC2)基础架构上设置共享文件系统/文件服务器,该服务器提供复制和相当轻松的故障转移。 这个文件系统可能会承载数百万个大小只有几百万的文件。 这些文件将被从几个客户端虚拟机访问(读/写)。 如果主文件服务器失败,我希望客户端能够故障转移到副本文件服务器,而不会丢失任何文件(即我想复制实时)。 我看了几个选项:

  • 使用S3和s3fs。 我担心在数千个文件上执行操作时(例如,当复制/移动文件时),每个请求的延迟都会有问题。 我也听到一些报告,让我质疑s3fs的稳定性 – 不知道是否仍然如此。
  • 在EC2实例上安装NFS服务器,使用drbd在两个实例之间复制块。 缺点:
    1. 在过去,我遇到了drbd的可靠性问题,特别是高延迟链接
    2. 如果主NFS服务器出现故障,则它将取下客户端,要求系统pipe理员进行干预和/或重新启动以使其重新连接到辅助服务器。 没有自动故障切换。

有没有更好的解决scheme?

只是一些更新的信息。 如果您和我一样,并且非常非常希望使用此function,请使用Amazon Elastic File System(EFS)。 这是跨多个可用区域复制的NFS装载。

(对不起,这个问题的答案,但这个答案的谷歌排名是足够高的,有几个人可能正在寻找这个解决scheme。)

使用DRBD进行同步复制,使用Pacemaker + Corosync来设置Amazon EC2中的NFS群集(用于自动执行NFS服务和节点之间的导出故障转移(不中断客户端访问)),尽pipe不是微不足道的。

如果您计划同步复制(“实时”),则需要两个EC2实例位于同一个区域,以限制它们之间的延迟; 否则networking延迟将转化为磁盘延迟。

另外,无法在Amazon EC2实例上轻松分配/取消分配IP地址; 你需要使用他们的API(或者使用他们的web-gui)重新分配一个IP地址。 移动IP地址是客户端用于连接到活动节点的浮动IP地址所必需的。 需要对“IPaddr2”Pacemaker资源代理进行一些修改才能使其工作; 这是一个bash脚本。

鉴于设置复制的NFS服务器的复杂性,我们select使用S3。 s3fs-fuze的性能非常糟糕(对超过1000个文件的目录执行ls会花费近一分钟,因为它需要为每个文件查询元数据,caching似乎没有帮助)。 然后,我尝试了RioFS ,它为我提供了在目录操作中的即时响应,总体感觉非常快。

我仍在计划研究一些额外的选项(特别是S3QL和YAS3FS ),但到目前为止,这些选项看起来很有希望。