Intereting Posts

分布式存储文件系统 – 哪一个/有没有准备使用的产品?

随着Hadoop和CouchDB遍布博客和相关新闻什么是实际工作的分布式容错存储(引擎)。

  • CouchDB实际上并没有任何内置的分发function,据我所知,粘贴来自动分发条目,甚至整个数据库是完全没有。
  • Hadoop似乎被广泛使用 – 至less它得到了很好的新闻,但仍然有单点故障:NameNode。 另外,它只能通过FUSE安装,我知道HDFS实际上并不是Hadoop的主要目标
  • GlusterFS的确有一个共享的概念,但最近我读了几个post,导致我认为它不太稳定
  • Lustre使用专用的元数据服务器也有单点故障
  • Ceph似乎是select的球员,但主页表明它仍然处于alpha阶段。

所以问题是哪个分布式文件系统具有以下function集(没有特定的顺序):

  • POSIX兼容
  • 易于添加/删除节点
  • 无共享的概念
  • 在便宜的硬件上运行(AMD Geode或VIA Eden级处理器)
  • authentication/授权内置
  • 一个networking文件系统(我想能够在不同的主机上同时安装)

很高兴有:

  • 本地可访问的文件:我可以用一个标准的本地文件系统(ext3 / xfs / whatever …)来下载一个节点,并仍然可以访问文件

不是在寻找托pipe的应用程序,而是让我可以说我们的每个硬件盒10GB,并有我们的networking中可用的存储,可以轻松安装在多个主机上。

我认为你将不得不放弃POSIX的要求,很less有系统实现这一点 – 事实上,即使NFS并不真的(认为是锁等),也没有冗余。

任何使用同步复制的系统都会变得非常慢。 任何具有asynchronous复制(或“最终一致性”)的系统都将违反POSIX规则,而不像“传统”文件系统那样行事。

其余的我都说不完,但是你似乎在“分布式存储引擎”和“分布式文件系统”之间混淆了。 它们不是一回事,也不应该被误认为是一回事,而是永远不会是一回事。 文件系统是一种跟踪硬盘驱动器位置的方法。 像hadoop这样的存储引擎是一种跟踪由密钥标识的大块数据的方法。 从概念上讲,差别不大。 问题是一个文件系统是一个存储引擎的依赖…毕竟,它需要一种方法来写入块设备,不是吗?

除此之外,我可以将ocfs2用作生产环境中的分布式文件系统。 如果你不想要坚韧的细节,那么请停止阅读以下内容:这有点酷,但这可能意味着比你想象的更多的停机时间。

过去几年来,我们一直在生产环境中运行ocfs2。 没关系,但对于很多应用程序来说并不好。 你应该看看你的要求,弄清楚它们是什么 – 你可能会发现你有更多的自由度,比你想像的要多。

例如,ocfs2为要装入分区的群集中的每台计算机都有一个日志。 假设你有四台Web计算机,当你用mkfs.ocfs2创build这个分区的时候,你指定总共有六台机器给自己一些成长空间。 这些日志中的每一个占用空间,这会减less可以存储在磁盘上的数据量。 现在,假设您需要扩展到七台机器。 在这种情况下,您需要closures整个群集(即卸载所有ocfs2分区),并使用tunefs.ocfs2实用程序创build额外日志,前提是有可用空间。 然后才可以将第七台机器添加到群集中(除非您使用的是实用程序,否则需要将文本文件分发到群集的其余部分),将所有内容都备份完毕,然后将分区挂载到全部七个机器。

明白了吗? 这应该是高可用性,这应该是“永远在线”,但在那里,你有一堆宕机…上帝禁止你拥挤的磁盘空间。 你不想看到当你拥挤ocfs2时会发生什么。

请记住,曾经是pipe理ocfs2集群的'首选'方式的evms已经走上了渡鸦鸟的道路,转而支持clvmd和lvm2。 (还有很好的解决scheme。)另外,心跳很快就会变成僵尸项目,转而使用裸露/起搏器。 (另外:在做ocfs2的初始集群configuration时,你可以指定'pcmk'作为集群引擎,而不是心跳。不,没有logging。

对于它的价值,我们已经回到了由起搏器pipe理的nfs,因为当起搏器将nfs份额迁移到另一台机器时,几秒钟的停机时间或几个丢失的tcp数据包相对于基本的停机时间而言是微不足道的共享存储操作,如使用ocfs2时添加机器。

只要把我的0.02€在这里:不能OpenAFS做你想要的?

Lustre允许多个元数据存储在主动/被动configuration中以实现冗余,因此不存在单点故障。

OCFS2也值得一看。

请注意,切断对多个同时networking访问的要求可以切换到iSCSI或甚至cif或nfs之类的东西。 缺点是你必须把你的uberArray分割成每个需要空间的服务器。

我可能误解了你的要求,但是你看过http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

除非是为了学术/发展目的,否则应从项目的总体要求出发来处理这类事情。 大多数分布式文件系统还不够成熟,无法进行严肃的部署 – 例如,如果整个事情出现,你会怎么做。 如果是为了学术/开发目的,那么这实际上是一件好事,因为你可以学到很多东西,并修复了很多错误。

质疑你是否真的需要POSIX语义是一个好的开始。 非POSIX“文件系统”语义可以非常灵活,从而导致更可靠的系统。

如果这是一个遗留应用程序,我真的不知道为什么现代分布式文件系统可能被认为是最好的解决scheme。

不要误解我的意思 – 这些玩具是非常有趣的。 我只是不想为一个不常用的复杂的相互依赖的解决scheme负责,而当它出现时将很难修复。

Xtreemfs怎么样 ? 版本1.4(2012年11月)被视为生产质量。

它兼容POSIX,具有出色的自动容错function。

你真的,绝对肯定需要POSIX语义? 如果您可以使用自定义数据存储,生活将变得更加轻松。 我们有一个内部编写的数据存储,实际上是一个非常大的分布式键值存储。 你在其中存储一个文件,你得到一个令牌。 如果你想要回来的文件,给它你之前给的令牌。 它分布式,无共享,数据被复制三次,可以随意添加和删除节点,包括存储服务器和控制服务器。

Lustre使用专用的元数据服务器也有单点故障

Lustre旨在支持故障切换,而MDS / MDT / OSS可以有多个可以联系的地址,心跳可以用来迁移服务。

请注意,一些最近的版本有卸载似乎工作的问题,但仍有数据仍然在飞向光盘,但双重安装保护应该有帮助(除了有趣的问题)….