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