在AWS上提供作为单个文件系统公开的大型,可增长的共享存储的可接受/合理/最佳方式是什么?
我们目前大约每两周制作1TB EBS卷,并使用no_subtree_check和nohide导出NFS。在此设置中,客户端上的单个安装下会出现不同的导出。这种安排不能很好地扩展。
我们考虑过的选项:
- 具有ext4的LVM2。resize2fs太慢。
- Linux上的Btrfs。显然还没有准备好黄金时间。
- Linux上的ZFS。显然还没有准备好迎接黄金时段(尽管LLNL使用了它)
- Solaris上的ZFS。这个组合的未来(对我而言)不确定,并且新操作系统混合在一起
- glusterfs。听到的大部分都是好故事,但有两个令人恐惧的故事(也许是古老的故事)。
理想的解决方案将提供共享,单个fs视图,轻松的可扩展性,快照和复制。
感谢您分享想法和经验。
2
您是否对此进行过计算?它令我感到震惊,因为它实在太贵了……
—
迈克尔·汉普顿
好问题。答案是sorta,但我们还早。我们的数据需求很高,而计算需求则是突发性的。因此,尚不清楚哪个成本更高:AWS具有昂贵的存储和廉价的峰值计算解决方案,还是本地具有昂贵的计算和廉价的存储。(我什至不相信完全加载的存储成本确实会便宜。)我们可能会将存档数据存储在Glacier中以降低成本(这些约束对我们有用)。
—
Reece 2012年
不要忘记带宽成本。
—
迈克尔·汉普顿
关于ZFS,它可以是Solaris或FreeBSD,但正如您所说,对于Solaris来说,前途未卜,开源ZFS停留在28版(无论使用哪种操作系统)。
—
Ouki,2012年